XML, the Extensible Markup Language, is a simple dialect of SGML. In the words of the XML specification, "the goal [of XML] is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML."
Are DocBook SGML instances valid XML instances?
Can the DocBook DTD be made into a valid XML DTD?
If you have an existing SGML system, and your primary goal is to serve DocBook documents over the Web as XML, only the first of these issues is relevant. As the popularity of XML grows, we will see more and more XML-aware tools that don't implement full ISO 8879 SGML. If your goal is to author DocBook documents with one of this new generation of tools, you will only be able to achieve validity with an XML DocBook DTD.
Although not yet officially adopted by the OASIS DocBook Technical Committee, an XML version of DocBook is available now and provided on the CD-ROM.
Most DocBook documents can be made into well-formed XML documents very easily. With few exceptions, valid DocBook SGML instances are also well-formed XML instances. The following areas may need to be addressed.
If you're used to using catalog files to resolve system identifiers, you may be dismayed to learn that system identifiers are required. Because most tools favor system identifiers over public identifiers, all of the portability that was gained by the use of catalog files seems to have been lost. In the long run, it'll be regained by the fact that XML system identifiers can be URNs, which will have a resolution scheme like catalogs, but what about the short run?
to your catalog files. Alternatively, you can remap system identifers with the SYSTEM catalog directive. If you are faced with documents that don't use public identifiers at all, this is probably your only option.
Requires that all attribute values be quoted.
Does not allow short tag minization.
XML also forbids tag omission, and there are probably a half dozen or so more exotic examples of minimization that you have used. They're all illegal. The easiest way to remove these minimizations is probably with a tool like sgmlnorm (included in the SP and Jade distributions, on the CD-ROM).
Address expresses that its content is line-specific with an attribute.
The DocBook DTD defines all of the standard ISO entities automatically, but the ISO definitions use SDATA, which is not allowed in XML. Eventually, ISO (or someone else) will release official ISO standard entity sets that make reference to the appropriate Unicode character for each entity. Until then, DocBk XML DTD is distributed with an unofficial set.
If you use entities in your document, it may be wise to put declarations for them in the internal subset of each instance, because some XML browsers are going to parse the internal subset but not the external subset. If the entity declarations are in your DTD, and the browser does not parse the external subset, the browser won't know how to display the entities in your document.
With the standard DocBook SGML declaration, DocBook instances are not case-sensitive with respect to element and attribute names. XML is always case-sensitive. As long as you have used the same case consistently, your XML instances will be well-formed, but it may still be advantageous to do some case-folding because it will simplify the construction of stylesheets.
Keywords in XML are case-sensitive, and must be in uppercase.
The name declared in the document type declaration, like all other names, is case-sensitive.
Start and end tags must use the same case.
In XML, Para is not the same as PARA. Note that this is a validity error (against the DocBk XML DTD), but it is not an XML well-formedness error. The use of para and PARA as distinct names is as legitimate as using foo and bar, as long as they are properly nested.
The StartRef attribute on indexterm and the OtherTerm attribute on GlossSee and GlossSeeAlso are #CONREF attributes.
In SGML terms, this means that when these attributes are used, the content of the tag is taken to be the same as the content of the tag pointed to by the attribute.
If you have used these attributes, your instance will contain both empty and non-empty versions of these tags.
Your best bet is to transform the #CONREF version into an empty tag and let your stylesheet deal with it appropriately.
Parameter entities are not allowed in the body of XML documents (they are allowed in the internal subset).
XML instances cannot contain IGNORE, INCLUDE, TEMP, or RCDATA marked sections.
CDATA marked sections must use the "CDATA" keyword literally because parameter entities are not allowed.
XML instances cannot use CDATA or SUBDOC external entities. One option for integrating external CDATA content into a document is to employ a pre-processing pass that inserts the content inline, wrapped in a CDATA marked section.
SUBDOC entities may be more problematic. If you do not require validation, it may be sufficient to simply put them inline. XML namespaces may offer another possible solution.
They're not allowed in XML, so don't add any.
Most of them have been moved to comment declarations preceding the markup declaration that used to contain them. A few small, inline comments that seemed like they would be out of context if moved before the declaration were simply deleted.
The small number of places in which DocBook uses name groups have been expanded.
There's one downside: DocBook uses %admon.class; in a name group to define the content model, and attribute lists for elements in the admonitions class. In DocBk XML DTD, this convenience cannot be expressed. If additional admonitions are added, the element and attribute list declarations will have to be copied for them.
Graphic and InlineGraphic have been made EMPTY. The content model for SynopFragmentRef, the only RCDATA element in DocBook, has been changed to (arg | group)+.
They had to be removed.
Ubiquitous elements (indexterm and BeginPage) from a number of contexts in which they should not occur (such as metadata, for example).
Formal objects from Highlights, Examples, Figures and LegalNotices.
Formal objects and InformalTables from tables.
Admonitions, EntryTbls, and Acronyms from themselves.
Removing these exclusions from DocBk XML DTD means that it is now valid, in the XML sense, to do some things that don't make a lot of sense (like put a Footnote in a Footnote). Be careful.
Inclusions in DocBook are used to add the ubiquitious elements (indexterm and BeginPage) unconditionally to a large number of contexts. In order to make these elements available in DocBk XML DTD, they have been added to most of the parameter entities that include #PCDATA. If new locations are discovered where these terms are desired, DocBk XML DTD will be updated.
Elements with mixed content must have #PCDATA first.
The content models of many elements have been updated to make them a repeatable OR group beginning with #PCDATA.
They have all been replaced by NMTOKEN or CDATA.
The #CONREF attributes on indexterm, GlossSee, and GlossSeeAlso were changed to #IMPLIED. The content model of indexterm was modified so that it can be empty.