xml-dev - RE: Reserved names and documentation

[Tim Bray <tbray@textuality.com>]

At 04:55 PM 1/5/99 -0500, Simon St.Laurent wrote:
>There are a lot of potential conflicts between assorted XML technologies,
>and rumor has it that the W3C is aware of them.  

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.

>Namespace prefixes hate
>validation.  

Those who've heard my argument on this subject can tune out now.
Here goes, again.  Namespaces create two problems; an easy syntactic
problem, and a hard design problem.  The syntactic problem is that
of validation, but there is a clean algorithmic solution:

1. You have a DTD that contains elements from different namespaces 
   and you know what the URIs are for those namespaces.
2. You have a document that has tags from different namespaces, and
   you know what those namespaces are.
3. You want to validate the document against the DTD.
4. You make a list of all the namespace URIs that are in play via the
   DTD.  For each you generate a unique prefix.
5. You preprocess the DTD, rewriting all the element & attribute
   declarations with the appropriate prefixes
6. You preprocess the instance, making all namespace prefixes
   explicit (no defaulting), declaring all the namespaces on the root 
   element, and using the same set of prefixes you used in the DTD
7. You validate

OK, this is a bit tedious but contains NO ROCKET SCIENCE.  The 
syntactic problems of validating in the presence of namespaces are
just not that hard.

Now, on to the difficult problem: how do you go about making that
DTD I mentioned in step 1, that has the combined elements?  Right now
we have little in the way of technology or automated procedures or even 
industry experience to aid us in designing that compound DTD in a good,
clean, and efficient way.  That's a hard problem and one that some
of the schema proposals are feeling toward a solution for.  But we're
nowhere near knowing the answer.

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.

>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?

>, 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.

>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.


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