|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Namespaces hate validation!
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








