Lists Home |
Date Index |
- From: Murray Maloney <email@example.com>
- To: XML Dev <firstname.lastname@example.org>
- Date: Wed, 6 Jan 1999 13:03:40 -0500
At 11:12 AM 1/6/99 -0500, John Cowan wrote:
>Murray Maloney wrote:
>> Everything that follows this point is predicated on the
>> assumption that one can have such a DTD, but later Tim
>> makes it clear that it is not currently feasible to design
>> such a DTD.
>Au contraire: we of DDML (formerly XSchema) *have* designed such
>a DTD. The DDML DTD uses two namespaces, DDML and IBTWSH (which
>latter does not use prefixes, in the name of HTML compatibility,
>but is a true namespace anyway).
On what basis can you claim that IBTWSH is a *true namespace*
while also stating that it does not use prefixes AND asserting
that it is compatible with "Namespaces in XML"?
Anyway, I was not saying that it is impossible to design a DTD
that uses colons in the names of its elements and attributes.
>What we do not have is a *algorithmic* way of building such a
>DTD. I doubt we ever will, as *judgment* is required to decide
>when elements imported from other namespaces are to be allowed.
>Merging two DTDs intelligently is no easier (but no harder, IMHO) than
>designing content models in the first place: an "AI-complete" problem.
Well, based on my own experience and discussions with some of
the world's most prolific and well-respected DTD designers,
I have to say that it is a lot harder to design a DTD that
combines two DTDs, especially if you are compelled to use
"Namespaces in XML". Hopefully, one or more of my colleagues
>> >5. You preprocess the DTD, rewriting all the element & attribute
>> > declarations with the appropriate prefixes
>> Using special care to take into account the non-XML notion
>> of "global attributes".
>There is nothing particular about global attributes: from a
>purely XML 1.0 viewpoint, they are ordinary attributes that happen
>to have a ":" in their names. Their prefixes must be munged
>just like element prefixes.
Too true. The point is that there is no such thing in XML
as a "global attribute". Therefore, there should not be
"global attributes" in "Namespaces in XML". But, to the
extent that a global attribute can exist in an XML document
-- according to "Namespaces in XML" -- Tim's algorithm should
deal with them somehow. In other words, the algorithm is
not complete in this respect (and others).
>> >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
>> Of course, this will not work for instances that redeclare
>> a namespace prefix with a different URI for the purposes
>> of local scoping of namespaces. In that case, you have to
>> declare namespaces on elements as you go.
>Not at all. With appropriate renamings of prefixes, you can move
>all nested prefixes out to the outermost element.
Ok, so we never actually validate the received document instance.
Instead, we end up validating a derived document.
>> [Y]ou would have to inspect the entire document to determine
>> whether local scoping of namespaces has been applied [...].
>So you would. But nothing says Tim's algorithm can't be two-pass,
>as indeed it must be: one pass to scan for namespace declarations,
>and another pass to output the root element with all correctly
>munged declarations and then all elements and attributes with
>munged prefixes correctly applied. Given a tree API like the
>DOM, it is not necessary (though it may be preferable) to actually
>parse the instance twice.
So, I have to run several processes on the document that
I am trying to validate before I actually get to test it
against a DTD? And these processes, presumably, are guaranteed
to produce a DTD against which the instance is valid, right?
So I am never going to encounter a document that isn't valid
-- ultimately -- within this process?
What is the point in that?
>> Well, tedious enough to make it unlikely that anyone will use
>> validation on documents that utilize namespaces. It is hard.
>> It is too hard.
>It is hard until someone writes a tool to do it. I would do it
>now if I had an easy-to-use DTD analyzer in Java.
So, perhaps we should not design facilities for which it is
so hard to write tools -- especially when those facilities
break compatibility with XML validity.
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/
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)