Reserved names and documentation

[Simon St.Laurent]

At 05:46 PM 1/5/99 -0800, Tim Bray wrote:
>There is at least an "XML Co-ordination" group whose job it is to worry
>about such things.  Simon is right that the picture is pretty complicated.

I'd love to see a set of goals from the higher level group like the working
groups below it have so successfully produced.  Right now, the emperor
himself is pretty invisible to the outside world.  There's no broad
statement of what the XML family of standards should look like when it
reaches maturity (or puberty, even.)  I think everyone on this list has
their own, usually incompatible, vision of what XML should look like.  A
statement of what it will look like might give us something better to work
with, introducing less complication in the long run.

We've also got lots of specs and no clear order on how to process them.  Do
you parse the document first and validate it, then inspect it for links,
then transform it, then format it?  Or do you parse the document, transform
it, validate it, inspect it for links, then format it?  Or do you parse the
document first and validate it, then transform it, then inspect it for
links, then format it? And where would namespace processing fit in there,
amongst the transformation (of the DTD?) or the validation?  Yikes.  

Saying you can order these things any way you want is going to explode a
lot of XML's interchangeability, damaging Paul Prescod's assertion that
"[XML] is optimized for interchange, interchange and interchange."

>>Namespace prefixes hate
>>validation.  
>
>[plausible but complex DTD transformation algorithm to accomodate
>prefixes and namespaces]
>
>Thus, I have to reject Simon's contention that namespaces are
>anti-validation.  It is true that *compound documents* pose big
>problems for document design in general and validation in 
>particular.  Compound documents, it is painfully obvious, are 
>coming at us fast, and in high volume, so it behooves us to get
>our act together on document design.  Namespaces, for the nonce, 
>allow us to have compound documents without the elements falling 
>over each other.  But in and of themselves, they don't particularly
>impair validation.

In and of themselves, they make validation far more difficult, requiring a
transformation of DTDs for which there are no standard tools.  Given that
validation is built right into the parser in many implementations, it's
kind of hard to slip in and fix the DTD after realizing that you've got a
prefix change on your hands.  Better parsers might be capable of doing
this; I'd rather see layered processing, where one layer checks syntax, and
another checks document structure.  That way we could sneak in for DTD
transformations and other weirdness.  Unfortunately, there hasn't been a
lot done in the XML 1.0 spec to accomodate or promote such a model.

(The Lark/Larval implementation that Tim's built might allow such
possibilities; I'll have to take a closer look.)

I don't think too many people are actually going to try that algorithm, and
namespaces are going to have to wait until schemas arrive that can handle
them.  (Schemas will also probably help with my layering issues described
above.)

>>XLink provides services that seem to overlap with entities, no
>>matter how much some insist that the don't
>
>Yup.  Who insists there's no overlap?  Obviously, since XLink is
>trying to be a general-purpose hypertext mechanism, and external
>entities have an obvious hypertext semantic, it would be surprising
>if there were no overlap.  So much so that some have suggested that
>once we have hyperlinks we don't need entities any more.
>I doubt that, but it's a sane premise worth considering.  But the 
>overlap doesn't feel dangerous to me; what should we be worried about?

The overlap may not feel dangerous, but the very existence of an overlap
does make people wonder - a lot.  Having multiple ways to achieve similar
goals using totally different syntax is usually not considered elegant.
Elegance may not be a design goal for XML, but it certainly would help on
the coherence issue.

>>, and the PI used for style
>>sheets provides yet another example of connecting resources using URLs.
>
>That's evidently an interim patch made necessary by the imminence
>of the R5 XML-capable browsers... the right solution is a general-purpose
>packaging mechanism so you can bundle up an instance with pointers to
>(or direct inclusion of) the stylesheet(s) and schema(s) and scriptware
>and so on.  But that's going to take some real work to build.

Glad to hear it's a temporary fix.  I hope we don't see too many more of
these temporary fixes.  XLink should be able to help with this, when it
finally arrives.

>>CSS and XSL are mutually
>>incompatible tools that do a lot of the same things.  
>
>That's a real live problem all right; but at least everyone knows
>it exists. -T.

Everyone knows it exists, but it goes on...

Coherence is important.  XML has great potential, but it also has great
potential to bury itself in complexity.  (I think) David Megginson said a
long time ago that XML would be doing well if every iteration of the spec
was smaller and simpler.  Unfortunately, that doesn't seem to be the
direction XML is heading.

Simon St.Laurent
XML: A Primer / Cookies
Sharing Bandwidth 
Building XML Applications (February)
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)