[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] XHTML and the Three Namespaces
Here is my understanding of the XHTML namespace problem and its proposed solution: There is a vocabulary and syntax called "Strict". There is another called "Transitional", and it includes elements and attributes with the same names as those in strict, plus some additional elements and/or attributes, and the content models and attribute lists of Transitional are such that any document valid under "Strict" is also valid under "Transitional". There is also a third grammar called "Frameset" having a similar, superset relation to Transitional. One thing that people would like is to be able to clearly define which documents are valid per the Strict, Transitional and Frameset rules. This is currently done via three DTDs. Another thing people would like is to be able to indicate in a document which set of rules the document is intended to conform to. This is done by giving each of the three grammars a namespace, and saying that the elements in each namespace are to be validated against the syntax in the DTD corresponding to that namespace. This avoids having namespace transitions within a document (as would presumably occur if the Transitional namespace contained only those elements additive to Strict). This approach also permits each grammar/syntax to be described by a DTD, because we know that DTDs do not handle mixing of namespaces gracefully. Finally, it allows that existing HTML documents without any indication of namespaces, and consequently no namespace transitions, may be interpreted according to the broadest grammar. But it has the drawback that an element name from Strict and the matching element name from Transitional have different URIs, so a namespace-capable processor will treat them as of different element types. The actual difference between the elements is not sustantially their meaning, but only their content models and attribute lists. That is, the intention of the three definitions of various elements is that the more elaborate definition permits more elaborate content, but that an element conforming to Strict would have the same processing consequences as one conforming to Traditional, excepting only that a slightly different validation test would have been performed. Browsers, and other software specifically designed to deal with XHTML, could deal with this fairly easily by hard-coding the relationship between the definitions attending the three namespaces. However, generic software would find no machine-readable connection between the namespaces, and this would lead to awkwardness. For example, a search for documentw with "A" tags that specified the Strict namespace would miss all documents containing Transitional "A" tags. Are three namespaces the right answer? Here is a provisional phrasing of the problem we need to solve: How can we reliably distinguish elements requiring slightly different processing, while at the same time permitting them to be processed similarly to the degree that the differences do not matter? Let us look an an example to clarify the issue. Generalizing, suppose we have an element such as <a:X> <Y/> <Z/> </a:X> in one instance, and an element such as <b:X> <Y/> <Z/> </b:X> in another. Although 'b' might permit additional subelements in the content, they are not in fact there in this instance. We intend that, in nearly all respects, a:X and b:X are processed as equivalent. At the same time, b:X in another instance document could appear as <b:X> <Y/> <Z/> <W/> </b:X> The content model of b:X permits subelements not permitted in a:X. So I ask myself "Is this problem unique to XML, or has it appeared in other contexts, and if so, how was it solved there?" What I notice is that a very similar issue appears in languages such as Java or C++, and is solved in the following manner: Package A; Class X { Object Y; Object Z; } Package B; Class Y extends A.X { Object W; } >From this I conclude that if we had a way to declare the extended content model of B as an extension of that of A, then we would be able to express, in a machine-readable form, the relation between b:X and a:X. Given that, it would be proper to have three namespaces, each designating a slightly different set of validation rules. So our present difficulty appears to be a timing problem: the three namespaces distinguish the different validation rules of the three categories of elements, but there is at present no machine-readable way to express their relationship. What we have now is readable by humans, but not by validation programs, and what we will have eventually that is machine readable is still under design by the Schemas working group. Three namespaces, and the consequent mapping and other conversion processing is certainly more expensive than if we had only one namespace, yet that expense must be compared against other alternatives that actually solve the problem we set out to address: How to reliably distinguish elements requiring slightly different processing, while at the same time permitting them to be processed similarly to the degree that the differences do not matter? Certainly, interpreting a document incorrectly because we did not read the relevant definitions and mappings is not attractive. Nor is it attractive to label different element types indistinguishably so that the relevant definitions cannot be determined. Of the alternatives that I have seen, only the proposal for three distinct namespaces seems to have sufficient information in it. Perhaps I have overlooked a proposal that also works, but at this point I conclude that the burden of proof should rest with those who assert that the three namespace approach is faulty, and any such proof should include a demonstration of a workable, better alternative approach that actually solves the same problem. 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/ and on CD-ROM/ISBN 981-02-3594-1 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
|