Structuring XML Documents

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

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.

If you are developing some XML-related / based software - this book is must have. 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.

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.