OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Namespaces hate validation!

[ Lists Home | Date Index | Thread Index ]
  • From: Murray Maloney <murray@muzmo.com>
  • To: XML Dev <xml-dev@ic.ac.uk>
  • 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
will amplify.

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

Regards,

Murray


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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS