Customer Reviews

Structuring XML Documents

5 star:		(5)
4 star:		(4)
3 star:		(0)
2 star:		(1)
1 star:		(1)

 

 

This book is not meant to be a tutorial or a programming guide. All of the programming books in the world could not save you if your DTDs are not well designed. A DTD needs to be both constrained enough to be learnable and usable, and flexible enough to accommodate different and unexpected information structures. This book does a great job of expressing the underlying conceptual issues such as logical units, hierarchical information relationships, and modularity and reusability. Information architects and designers, technical writers and editors, people in the information science field who are studying XML, and anyone who's already learned their way around XML and want to go to a deeper level will find this book valuable. I'm giving it 4 stars instead of 5 because I would have liked to see more about how to analyze the inherent data structures in your documents in order to build the best DTDs - but it still gives you enough to chew on in that area.

This book delivers exactly what it says it will: the _whole_ gist on the technical aspects of drafting a Document Type Definition and on the theoretical aspects of defining an optimal way of structuring information. The author dominates his subject and his discussion on the fine points of information structuring is clever and challenging.

The only thing that is keeping me from giving it an otherwise well-deserved five-star is the utterly meagre index, a surprising fact in such a book!

It is said (with some validity) that XML will save the web. In particular, it will make it possible to present data in useful forms, along with tools to manipulate it. This book is specifically about using XML with *documents*, however. SGML is rooted in document production, and XML shows those roots clearly. However, there are many non-document oriented applications of XML, which are outside the scope of this book.

Instead, if you are using XML for document production, or are developing a new document handling system and are considering XML, this book contains many valuable lessons. It presents a number of design principles, in the context of five widely used DTDs: Docbook, CALS, TEI, EPSIG, and HTML.

It is *particularly* enlightening to see the comparisons with HTML. point by point, the author shows convincing DTD design creteria, demonstrates how they affect ease of use and ease of maintenance... and then casually shows just how poor HTML is as an example of! these principals. The other DTDs are not, of course, perfect, but they *do* show design skill and suitability for document use; HTML completely fails to. After reading this analysis, you will be left wondering why you ever thought HTML was "structured" in any way.

The author covers his ground with extreme thoroughness. He makes it very clear where he is going at all times, what he expects you to learn, and what pitfalls arise directly from poor design. The book is well structured, and gives evidence of a single very organized mind, in its construction, even down to the introduction to the last chapter where the author warns that you might want to "stop now and try applying" the techniques covered, before exploring certain more advanced and subtle areas. The consistent quality of delivery (including excellent use of a graphical notation to express measurable complexity of a DTD structure) makes this book a pleasure to read and study, especially when ! contrasted with other titles in the series (Designing XML I! nternet Applications, reviewed elsewhere, uses the same typographic style but manages a poor presentation due to other inconsistencies.)

All in all, if you are actually constructing DTDs for XML documents, this could be the most important book you might ever read on the subject. The author shares his experience very effectively, and makes subtle and advanced concepts seem intuitive.

This book is great if you are looking on how to design DTDs. For that you need to already know about XML. It is not a "software" book in the sense that it does not have a line of code and it does not explain to you how to "program" XML. I have already read some books about XML and how to program it. I wanted a book which could explain to me how to design a DTD so I could create my own XML application. I found that book! However, before you buy this book, make sure that it really corresponds to what you are looking for.

This is an excellent book for someone who is responsible for creating and maintaining dtds for large projects. The purpose of the book is not to teach the beginner what a dtd is. Rather it is meant to teach you to tell the difference between good dtd design and bad. The emphasis is on dtds that are for complex documents rather than those that are for transmission of database records. None the less, some of the material applies to both types of dtds. The author does not tell you what to do. Rather he tells you what issues you need to consider. There is a section that warns you of the problems that may arrise during the maintenance phase of a project. When a change is made to a dtd, there may be a backlog of legacy documents that were valid according to the old dtd but are no longer valid with the new one. I think this section of the book is a bit too methodical and long-winded. Even so the issue is crucial and needs some treatment.

This is not a book for beginners. There's a brief introduction to XML, but you need a fairly good grounding there before picking this book up. The author uses five industrial-strength model DTDs for documents as a basis for discussing the analysis and design of DTDs. These are briefly introduced, compared and contrasted. HTML is one of the five, not so much because it's a good example, but because it's widely known and used. The heart of the book is devoted to principles for analysis and design. These focus on the user -- ease of learning, of use, and of processing. Some desirable features tend to conflict, for example, there's a trade-off between simplicity and providing sufficient features to meet authors needs. Throughout the model DTDs are used to illustrate principled (or unprincipled) desgin. All in all, the book provides a good basis for reading, writing and understanding non-trivial, real-world DTDs.

The best book available... it covers everything you need to know about DTDs.

I guess this book may have originated as an SGML book so has examples oriented more towards SGML authors. These examples are not oriented towards Internet Programmers.

Still, the author did a pretty good job at seperating XML and SGML specific details.

Simply put, If you need to design a DTD then you need this book.

If you are developing some XML-related / based software - this book is <B>must have</B>. You'l find a lot of ideas that you'l never find on the web. David's experience comes from real life. It is a pleasure to read this book.

The first 1/3 defines DTD syntax. This section is horrible unless you already know it. It briefly mentions a topic and regurgitates a definition and then fails to explain the syntax and intricasies. The 2nd 1/3 covers some examples. However, this is done at a very high level. It explains almost nothing about how they work. The last 1/3 is worthwhile and covers some interesting advanced topics. This book is only worth something to someone who is not interested in hands-on XML development. Also, it was confusing how it kept describing SGML-only features and mixing these with the SGML/XML features.

I don't use XML very often. When I come back to it, it's like learning XML all over again. That's why I like Megginson's book. It's clear, detailed and gives all the basics needed for competent, flexible data design.

I said "data design," not "document design" as some might have expected. Although XML grew out of SGML, a document markup system, it's used for lots more than just text formatting. That's why Megginson focusess so heavily on the DTD, the "data type definition" for any XML application. Any one document uses XML commands to organize a specific set of data, and the DTD specifies a well-formed organization. It's the grammar of the document, like a database's schema. It's what defines the principles used to organize the data. Best of all, Megginson describes DTDs in terms of five well-known and freely available DTDs.

This book is old by internet standards, however. DTDs are being supplanted by XML schemas, which are not mentioned. Conversions between formats are now managed by XSLT most often, not "architectural forms." The DocBook standard has moved to the Oasis consortium (oasis-open.org). The XML standards family has grown, but this book is locked to the time in which it was written.

Even then, I had one real complaint about this book. Megginson took great care to distinguish XML from its SGML parent, giving detailed descriptions of SGML features not present in XML. It was sometimes confusing to read around the discussions of features that aren't there. If necessary at all, the information would have been better placed in footnotes, appendices, or some text typographically set off from the main discussion.

I'll have to replace this book sooner or later, but I haven't found anything that discusses newer XML usages and still meets this standard of clarity. In the mean time, I can keep puttering along with this book - it's old, but hardly obsolete.

//wiredweird