Lists Home |
Date Index |
I work for fairly large company in the Knowledge Management department.
Basically, we manage all of the engineering documents (with very few
exceptions). We started out using DTDs, but I am planning to implement XML
Schema in the next year or so. Here is the logic behind this decision:
1) Support for namespaces
Our documents have lots of equations, but the original creator of the DTD
decided not to use MathML because there was no tool support (we are using
XMetal 3.1, but have upgraded to 4.5/4.6 and have purchased Design Science
Mathflow). We are now finding that MathML is essential. I know you can
use the MathML DTD and included in our existing one, but I find it easier
just to import it in a schema. And our DTD contains two elements with that
have the same name as elements in the MathML DTD. Some tools complain
about this (I can't recall if XMetal does, but I know XMLSpy points it
2) Restrict what text content appears inside elements
All of our documents have dates in them, usually issue date, revision date,
and approval date. These elements all contain year, month, and day
elements in their content model. In the DTD system, people can (and do)
put anything in these elements (for example "Mar" in the month element
instead of "03", which is the standard here). We do have guidelines and
the people in my department tend to follow them, but we plan to start
letting the end user create their own XML documents. I know from
experience that they don't always 'play by the rules'. Using schema
validation is a good way to enforce content consistency.
Those are my two biggest reasons for using schemas. However, there is one
big drawback: no entity support. We have a lot of standard text in
documents such as legal statements, addresses, and other text. Legal
statement can (and probably should) be standardized at the stylesheet
level, but things like an address that may or may not appear in the
document can't be. I am unsure yet how I will tackle this problem.
In summation, schema can be very useful in publishing, but the lack of
entity support is a huge drawback.
I guess I should copy and paste this in word and send it to the W3C!
<firstname.lastname@example.org To: XML Developers List <email@example.com>
Subject: Re: [xml-dev] Document oriented experience reports anyone?
Does "I know of almost no large uses of XSD for documents" count? A
The crowd I come in contact with (mostly the kinds of users who used
SGML before: military,
legal, pharmeceutical) are very conservative as far as editing
environments: if they are using
FrameMaker they are stuck with DTDs, if they are using text editors or
markup editors (like
Topologi's) they usually want to have character entity references and so
keep with DTDs,
if they are using Word->XML conversion they hard code some schema
(usually a DTD)
into the converter code, and so on.
Furthermore, document-oriented systems very often have large files that
(such as those that use XML Schemas) often won't open successfully.
Furthermore, the large companies tend to have evolving systems and
so they don't get much value from switching from one grammar to
another. And, where
they do want more modeling power, RELAX NG is more powerful than XSD. (And
if the site has no tools for applying default values from a XSD, it
again loses out to DTDs
and is on par with RELAX NG.)
The trouble with moving to XML Schemas is that it may involve
For example, the recent release of Epic editor supports XML Schemas:
users who have
a small number of document types expressed in XML Schemas but many
DTDs have to figure out whether it is more practical to convert the XML
DTDs or upgrade their editing/production environments. (Or just to avoid
Finally, publishing data is rife with co-occurrence constraints: serious
be more interested at implement Schematron.
So, realistically, I only expect to see widespread XML Schemas adoption for
documents piggybacking on the release of new industry standards:
S-1000D and DITA
for examplein the short-term. These don't come out very often, compared
to data-oriented standards,
and the promulgators of these may decide to put out DTD or RELAX NG
versions just to
In the long-term, retooling and upgrades will make XSD-using tools more
available, and it
will make XSD much more viable, though still not particuarly interesting.
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription