Lists Home |
Date Index |
- From: Tim Bray <email@example.com>
- To: "Simon St.Laurent" <firstname.lastname@example.org>, <email@example.com>
- Date: Tue, 05 Jan 1999 17:46:35 -0800
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
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
>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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)