Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XHTML and the Three Namespaces
 On Tue, 21 Sep 1999, Andrew Layman wrote: > There is a vocabulary and syntax called "Strict". There is another > called "Transitional", [...] There is also a third grammar called > "Frameset" having a similar, superset relation to Transitional. As a formal spec, HTML arrived at its present state by agglomeration and accretion. Practically all of "HTML as an SGML application" has been a more or less inspired process of retro-fitting. At some point, trying to smooth out all the lumps in a single bag of potatoes proved too scholastic for anyone's taste, so Where There Was One There Became Three. The fact remains that for Joe HomePager there's still only one HTML as a concept, and the browser(s) that are -ahem- installed on JHP's computer system have yet to show any sign of disagreeing with that common sense notion. > 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. Syntax is already taken care of by the DTDs (to the extent that anyone could care when it comes to HTML.) So these "rules" must be different. If they're semantic in nature, then again the original point applies: as far as the HTML spec goes, HTML is for all practical, sensible, and widely accepted purposes a "single language" semantically. > 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 not a statement about documents. It begs the question of how "elements in each namespace" came to co-exist to begin with, and is thus an implicit assertion about "rules applied to fragments", quite in contrast to the first sentence of the same paragraph, repeated here: > 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. The relation between 'set of rules' and 'the document' is singular to singular. Especially in view of: > This avoids having namespace transitions within a document (as would > presumably occur if the Transitional namespace contained only those > elements additive to Strict). How did we suddenly leap into a world of "namespace transitions"? > 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? What's wrong with a distinguished attribute? For instance, this is precisely the mechanism invoked for CSS, insofar as CLASS is "special". (The HTML-CSS nexus would be more solid if there were a machine-readable way to indicate that the name of the "CSS-special" attribute is indeed "CLASS" rather than "FOO", but even without this the fact remains that processing distinctions on the basis of an asserted attribute value are *already* proven current practice.) I might add that if *this* is indeed the statement of the problem, then David Durand's attribute-based proposals to the SIG completely solved it. > <a:X> <Y/> <Z/> </a:X> > [vs] > <b:X> <Y/> <Z/> </b:X> > > [...] We intend that, in nearly all respects, a:X and b:X are processed > as equivalent. This is an assertion about semantic intent. Nothing prevents an application from treating, by design, an element type "FOO" and another element type "BAR" equivalently, whether across the board or contextually constrained. > 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. Why does this have any bearing on the first decision to treat FOO (read a:X) and BAR (read b:X) equivalently? Either the application (as an instantiation of a designer/programmer's intent) knows *why* it's doing what it's doing, or it doesn't. > >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. Why wouldn't the optionality of W in the content model for BAR (read b:X - I'm resisting the "persuasive definition" impact of the syntax actually used here) express the constraints completely? > 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, For now, simply avoid statements about namespaces altogether. Arjun 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
|
|||||||||
