Lists Home |
Date Index |
- From: David Megginson <firstname.lastname@example.org>
- To: "XML Developers' List" <email@example.com>
- Date: Sat, 20 Mar 1999 21:38:53 -0500 (EST)
James Robertson writes:
> But aren't you just saying: "very big jobs are a lot of work,
> and are very complex"?
> Wouldn't this be true if you were implementing DB solutions,
> or three-tier architectures, etc?
> In otherwords, why is XML any different here than SGML
> (which was the original question)?
SGML requires DTD validation, while XML and WebSGML do not.
With XML (or WebSGML), it is not necessary for the DTD designer(s) to
track the internals of the different steps in the transformation
chain, since DTD validation at each step is not required. For
example, consider this relatively simple production chain:
1. Original document (internal document type)
2. Transform #1 -- add references from database
3. Transform #2 -- remove elements that are configured out for the
current production run (for security reasons,
customer preferences, etc.)
4. Transform #3 -- add boilerplate
5. Transform #4 -- convert specialised tables to CALS tables
6. Transform #5 -- add revision markup
7. Transform #6 -- transform to industry-standard document type for
You probably have a DTD for (1), and you almost certainly have an
industry-standard DTD for (7), but the results of intermediate
transformations #1-#5 may not be valid according to either DTD.
In the SGML world, someone had to create one or more variant DTDs to
ensure that the document was valid at each stage (either through
elaborate and obfuscatory configuration with parameter entities and
marked sections, or by writing separate DTDs from scratch, both often
with liberal sprinklings of ANY). If the production engineers made
even minor changes in the system design, the DTDs would (usually)
immediately break validation and shut down the whole system -- in
other words, the system was brittle and expensive to maintain.
Sometimes, the benefit of tight validation at each step makes the
extra expense worthwhile, but as I mentioned before, XML lets you make
that decision rather than making it for you.
All the best,
David Megginson firstname.lastname@example.org
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)