RE: Namespaces hate validation!
At 01:51 PM 1/6/99 -0500, Tim Bray wrote: >At 12:39 PM 1/6/99 -0500, Murray Maloney wrote: >>Easy enough to write a DTD that matches an instance. Just inspect >>the instance and generate a DTD that captures its models. >>The trick is to be able to write a DTD that encompasses >>a class of documents that might be validated by it. > >Exactly. Of course, in historical practice, we kind of did this >with well-known external entities such as %ISOLat1; and CALS tables >and so on - this had two big problems: first, there was no way to >ensure avoidance of name collisions, and second, there was no >generally agreed upon way of resolving the PUBLIC identifiers. >Namespaces would allow creation of a solution that would avoid both >those problems. Two big problems. Problem 2. Well, I don't understand your point about the PUBLIC ids because XML relies on SYSTEM ids and not on PUBLIC ids. Besides, the SGML Open catalog specification handles PUBLIC ids. Problem 1. Name collision. We agree that this can be ameliorated by using prefixes. This introduces new big problems. Prefixes do not exist in flat "Namespace in XML" documents. That is, the namespace of an element or attribute may be the current default namespace, and any element can establish the default. Furthermore, the binding of a namespace prefix to URI can be locally scoped. Thus validation depends on the existence of a namespace-aware processor that can rewrite an XML document as an equivalent document with all namespaces declared on the root element and with no use of default namespaces or local scoping of prefixes. And, that processor is undefined and unimplemented. "Namespaces in XML" does not clearly define the relationship between itself and XML 1.0 validity. In technical specs, where one measure of friendliness toward a given topic is the sufficiency of coverage, I have to say that the absence of a clear definition of this relationship is tantamount to hate. ------------- >... Once you've written your compound DTD, the idea is that >the algorithm uses it to validate documents that may or may >not conform to it. Once the hard part - writing the compound >DTD - is done, the algorithm does the rest, hands-off. This I have to see. And when I see it, I may come to believe. But in the meantime, my skepticism is at perigee. Oh, by the way, what do you do about any entities you encounter? I mean, when I combine an HTML DTD with a graveyard DTD, how do I avoid name collision between general text entities? agrave, egrave, igrave, ograve, ugrave Now I assume that you will tell me that there is a *simple* algorithm for transforming the DTD and/or the instance to deal with name collisions. ------------- >DCD was certainly 100% explicitly namespace-aware, and had >facilities for including foreign-namespace elements in >content models and attribute lists. You may disagree with >aspects of that design, but a flat statement of "I do not see >how to integrate namespaces with schemas" is not useful. While I do disagree with certain aspects of the design of DCD, it is also true that SOX was informed by many of the other schema languages (DCD, XML-Data, XSchema, EXPRESS, XML DTDs). So, if I give the impression that I completely dislike DCD, please accept my apology. What I actually said was: >As a co-author of one of the schema submissions, I have to say >that I do not see how to integrate "Namespaces in XML" -- as >it is currently proposed -- with an XML Schema language. Perhaps >someone will show me the error of my ways in the fullness of time, >but I am skeptical. That statement was useful if only to encourage you and others to "show me the error of my ways." But so far I am not seeing thing much different. I do acknowledge that it is theoretically (and maybe even practically) possible to create processors that prepare a namespace-aware XML document for validation. But I have serious doubts about when such a processor will be standardized. I believe strongly in the "no harm, no foul" principle. That is, so long as a design characteristic or feature causes no harm to any other part of the system, then there is no reason to cry "Foul!". I find that the proposed "Namespaces in XML" is harmful to validation because it establishes a dependency on an un-defined, un-developed and non-standard class of XML processor. And it is harmful to XML schema languages by denying the use of name collision facilities for entities, notations and processing instructions. > >>So, DCD does not integrate with "Namespaces in XML". > >DCD has one missing piece: the syntax for prefix/URI mapping. That >was deliberate, because that ball was still in play when DCD was >being written. This is not a credible technical objection. -Tim Huh? Even XML DTDs can use prefixes without any help at all. Any schema language that does not have prefix/URI mapping, would seem to be incomplete with respect to "Namespaces in XML". The point is, there is not a single schema language in play that fully addresses its relationship to "Namespaces in XML". There are all kinds of questions that remain either unanswered or untried. Regards, Murray Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@m... Pickering, Ontario Email: murray@y... Canada, L1W 3K6 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