Structuring XML Documents

Description

64229-8

Real XML help for webmasters, developers, and publishing professionals!

Structuring XML Documents is the perfect book for you, if...

• You're tired of toy exercises and are ready to build XML/SGML DTDs for real-world document systems .
• You need to write DTDs that work both for your authors and for your computer specialists.
• You're starting with XML and want to make the most of it.
• You're migrating from SGML to XML - or thinking about it.

In this book, David Megginson shares his extensive expertise in quality structured document design and DTD development. Starting with five detailed industry-standard models, learn how to:

• Analyze DTDs and adapt them for your specific needs
• Build DTDs that are easier to learn, use, and process
• Ensure structural compatibility throughout your DTDs
• Use the new Architectural Forms standard to simplify complex DTD problems.

Whether you're a technical writer, documentation project manager, document systems implementor, or consultant, you'll refer to this book constantly.

On the CD-ROM...All these state-of-the-art model DTDs-pre-catalogued for plug-and-play parsing...

• ISO 12083 DTDs
• DocBook 3.0 DTD with documentation
• TEI P3 and TEI-Lite 1.6 DTDs
• MIL-STD-38784 DTD with Official Navy Baseline Tagset Library
• HTML 4.0

Plus...

• Ælfred-a small, fast, DTD-aware Java(tm)-based XML parser, especially suitable for use in Java applets
• SP/NSGMLS parser - source code and Windows binaries, for XML and SGML parsing and validating
• ISO character entity sets - a Web page indexing all the CD's contents, and including links to all the URLs cited in the book-sites where you can find the most up-to-date information on XML and SGML and more.

Sample Content

Table of Contents

Introduction.


XML and SGML.


The Book’s Structure.


Notations and Conventions.


Presentation of Examples.


Typographical Conventions.


Figures.

I. BACKGROUND.

Document Type Declaration. Elements. Attributes. Entities. Notations. Conditional Sections. Processing Instructions.

Reading About the Model DTDs. A Note About Using Industry-Standard DTDs. The Five Model DTDs.

II. PRINCIPLES OF DTD ANALYSIS.

DTD Size. DTD Consistency. DTD Intuitiveness.

Physical Effort. Choice. Flexibility.

Predictability. Context. DTD Analysis: Final Considerations.

III. ADVANCE ISSUES IN DTD MAINTENANCE AND DESIGN.

Structural Compatibility. Lexical Compatibility.

Editing Fragments as Stand-Alone Documents. Reparenting in a Dummy Document. Using Subdocuments.

Types of Customization. Extension Mechanisms in the Model DTDs.

IV. DTD DESIGN WITH ARCHITECTURAL FORMS.

Meta-DTDs. Documents. Practical Uses of Architectural Forms. Summary of Terminology.

Setup and Configuration. Basic Forms.

Automatic Derivation. Suppressing Architectural Processing. Architectural Attribute Values. Default Architectural Information. Meta-DTDs.

V. BACK MATTER.

Preface

Introduction

I have written this book to help you use XML and SGML to solve your document-structuring problems.
The book is a result of my experience with and opinions about document structure after seven years work with SGML (and more recently, XML), first as an academic and later as a professional document-management consultant and systems architect.

While XML and SGML DTDs provide a convenient syntax for defining a document's structure, most of the principles of document design and analysis covered in this book are not specific to any syntax. Though the book necessarily deals with some of the idiosyncracies of XML and SGML DTDs and uses XML syntax in its examples, it deals with issues such as learning, usability, and ease of processingÑthat all document designers and analysts must understand, whether or not they use XML or SGML and whether they use DTD syntax or other notations to define their structures.

By itself, this book is not a general introduction to XML, SGML, or DTD syntax: I am assuming that you already know how to create markup in a document and how to write basic DTDs (though there is a review of DTD syntax in Chapter 1 if you're a little rusty). If you are entirely new to XML, you should start with a beginner's guide or with online resources such as the ones listed on the SGML/XML Web Page .

This book concentrates on book-oriented DTDs, for applications such as technical manuals, literary texts, newspapers, magazines, advertisements, correspondence, regulations, legislation, and other material meant to be read by people rather than (or as well as) by machines. Both XML and SGML DTDs are also capable of modelling many other types of information, including commercial transactions and other types of data exchange; many of the principles described in this book can apply to database-oriented DTDs as well, but the book does not discuss that type of DTD explicitly.

In this book, I am also assuming that you already know how to collect information about the business problems you need to solve. You have to know about how people will create and process documents using your DTDs and about the projects that they will be working on.
For this book, I have divided the people you have to know about into two groups:
1. the authors, who create documents 2. the information-processing specialists, who design software to process the documents in various ways

This division is, of course, an oversimplification (there are also editors, proofreaders, fact-checkers, etc., not to mention the end users of the information), but it is a useful one for developing a methodology for DTD analysis. When I want to refer to both authors and information-processing specialists together, I simply use the term DTD users.
It is essential that you know your users' requirements, because there are few absolute rights and wrongs in document analysis design: your goal is not to come up with an abstract, ideal DTD, but rather to come up with the best practical fit for your users. In fact, as I explain in Part Two starting on page 84, often you will have to make sacrifices in one area to meet your users' needs in another. Learning how to collect this information is an important skill in itself, as is learning to document your work if you are interested in reading about good SGML (and XML) business practices, you might want to take a look at Developing SGML DTDs: From Text Model to Markup (Prentice-Hall) or any of the many software-engineering textbooks currently available.

From the perspective of document analysis and design, there are very few differences between XML and full SGML. XML DTDs can describe almost any structure that full SGML DTDs can describe (though they will sometimes present information differently); the following are the only major types of SGML structure that XML DTDs are incapable of modeling:
1. XML DTDs cannot model inclusion exceptions or exclusion exceptions 2. XML DTDs cannot model unordered content 3. XML DTDs cannot model arbitrary mixed content (only an optional and repeatable OR group is allowed).

Even when you are writing DTDs in full SGML, however, you should use inclusion and exclusion exceptions sparingly, you should usually avoid unordered content, and you should always avoid dangerous types of mixed content.
The Book's Structure
There are four parts to this book:
In Part One, you can read about the five industry-standard DTDs that this book uses as models and refresh your knowledge of XML (and SGML) DTD syntax
In Part Two, you can read about how to analyze DTDs to see if they match your specific needs this part contains many examples from the five model DTDs
In Part Three, you can read about advanced topics like document disassembly and reassembly, configurable documents, DTD compatibility, and DTD customization
In Part Four, you can learn about the important new standard for architectural forms, and see how to use them to produce simple solutions to complicated DTD problems
Notations and Conventions SGML Note: XML documents are SGML documents; however, in full SGML you can use some additional facilities that are not available in XML.
Throughout the book, I include text like this whenever I think that you need to know about a difference between full SGML and XML or whenever I want to give you some extra SGML information.

Presentation of Examples For the sake of consistency and readability, I present examples in the book (both DTD and document excerpts) using XML syntax whenever possible, even when the examples come from an SGML original. I also normalize whitespace and presentation, but preserve the name case of the original declarations.
For example, the following element type declaration appears in TEI-Lite: Original SGML declaration


Unless I am discussing SGML-specific syntax, I remove both the omitted tag minimization and the exclusion exception from the example. In this case, I also rearrange the presentation of the content model to conform to the XML constraints on mixed content:
Normalized XML-compatible declaration

Except for the absence of the exclusion exception, this is an equivalent content model; since the declaration is expressed in the subset of SGML syntax allowed by XML, however, both XML- and SGML-experienced readers should be able to read and understand it.

Typographical Conventions
When you are reading this book, you will notice different typefaces for some types of information:
nsample term
This is a specialized term at the point in the text where I define it.
nlogical unit
This is the first reference in a chapter or section to a specialized term.
nsymbol/filename/code
I use this typeface to refer to text in an example DTD or document instance (such as the SGML name of an element type, entity, attribute, notation, or document type) or to the name of a file.
Figures
Figure Intro--1 Legend for Figures--The figures in the book provide graphic representations of DTD and document instance structures.

For some examples, the book provides figures to illustrate DTD or document constructions. For an explanation of the symbols that appear in the figures, see Figure Intro-1.

Updates

Submit Errata