Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XHTML and the Three Namespaces
 Based on the subject line, this sounds like 'Goldilocks and the Three Bears'. I hope that we may come to a happy ending. The last two paragraphs of this posting are probably the most important part, for those who just want the conclusion. At 12:45 PM 9/21/99 -0700, Andrew Layman wrote: >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. Correct. And in the current draft of XHTML: [PR, section 3] PR>This version of XHTML provides a definition of strictly conforming XHTML PR>documents, which are restricted to tags and attributes from the XHTML PR>namespaces. Hence, for all documents that actually conform to this spec, we have a DOCTYPE declaration that tells us which DTD is appropriate. >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 is the giant leap that doesn't appear to have any substantial foundation. 1) Why would anyone want to validate XHTML fragments differently according to the strict/transitional/frameset setup? HTML already has a long tradition (noted by Tim Berners-Lee in an earlier posting) of 'leave what you don't understand alone'. If you have handlers for a particular XHTML tag, great. But does it matter which version of XHTML it came from? I seriously doubt it. 2) Why does each grammar deserve a namespace in the context which XHTML purports to be describing? The DOCTYPE declaration already provides this information. Section 3.1.2 seems to be out of whack with the rest of the document. If this document is really about what it claims in 3.1, Document Conformance, I'd suggest striking 3.1.2. >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. We already know that DTDs don't handle namespaces gracefully. So why pile in three namespaces? If for some perverse reason a developer decided to use all three varieties of XHTML, a validating parser (XML 1.0) would either choke on the clashing (or missing) namespaces, or face conflicts because all three DTDs would suddenly occupy the same (internal XML 1.0) namespace - you can't declare the same element twice... >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. Yep. It'll make writing XSL stylesheets a lot more interesting, unless the writers of XSLT add some kind of extra indirection for namespaces... >The actual difference between the elements is not sustantially their >meaning, but only their content models and attribute lists. Which raises the question, again, of why bother validating this information against any but the broadest DTD? What benefit could an application get by validating XHTML fragments, which technically aren't even described by XHTML 1.0, against three different DTDs? >[...example in different context...] >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. I don't think treating strict HTML as transitional for processing purposes is 'incorrect' in any substantial way. Nor do I think the 'relevant definitions' in this case are worth the trouble. >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. The 'sufficient information' argument seems to come from a very different valuation of that information. To me, it's much more important to know that an element is HTML than to know that it is strict, transitional, or frameset HTML. Having to work harder to find out that it is HTML in order to accomodate the useless freight of strict/transitional/frameset doesn't seem like a reasonable tradeoff. I think this differing valuation is really what lies at the bottom of the disagreement, and it shows no signs of disappearing. In the end, whatever the abstract arguments, I think the choice is going to be made based on which of these 'valuations' is deemed more important. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com 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
|
|||||||||
