I think the general reasoning behind xml-data and XSL (shiver of horror)
is that if we settle on a uniform representation for graph-structured data
in transit then we can (soon) live in a world where nobody has to write a
parser for the stuff ever again. I mean, a scheme parser isn't exactly
brain surgery so I'm less inclined to enjoy this argument when used in
favour of XSL, but XSL has other reasons for existing. writing a DTD
parser with architectural forms support is just another stumbling block to
wide deployment of XML, and xml-data nicely circumvents the question. You
can just write an XML parser (in a shoddy one-off proof of concept as many
people are busy writing) and write your validator in terms of the objects
the tried and true parser hands you. Given that those objects have really
simple property-querying methods, it makes your code better encapsulated,
less likely to mix validating with the parsing of architectural forms.
at least that's the principal advantage I see.
cool side note: you can use a DSSSL engine to customize an XML-DATA grove
and dump out a new document type ;) or at very least typeset the metadata
in a nice way..
-graydon <graydon@pobox.com>
______________________
peccatum poena peccati