Re: [Fwd: ATTN: Please comment on XHTML (before it's too late)]
Ann Navarro wrote: > > At 08:35 AM 8/29/99 -0400, Eliot Kimber wrote: > > >Namespaces were intended to solve the problem of *name collision*, which > >they do. But they explicitly do not have anything to do with binding > >names to semantics and therefore you are *never* justified in infering > >semantics from namespace use. > > This is where I think namespaces were "under-done". But I do take exception > to the statement that they "explicitly" do not have anything to do with > binding names to semantics. > > The spec does say "It is >>not a goal<< that it be > directly usable for retrieval of a schema (if any exists).", > > >>emphasis mine<< > > but it doesn't say that it *must not* be used for that purpose. My point is that *they are not capable of being used for that purpose*. That is, there is no mechanism by which, using only facilities of XML or the Namespace recommendation, you can state any explicit binding between any given namespace (or name in a name space) and any definition(s) of the semantics to which that name is bound *in the XML document that uses the name space*. Therefore, given only a namespace declaration, you can *never* infer any semantic binding with certainty. As I said in my post, the reverse is possible: a semantic definition (e.g., XLink, RDF, XHTML) can state a binding as part of its specification (which is exactly what the XLink spec does), but you have know about that statement before you start processing a document. To do that, you have to read the spec. Once you read the spec, the use or non-use of name spaces is irrelevant for the purpose of recognizing element types defined in a given spec--there are any number of ways names can be disambiguated or bound to name spaces. The namespace mechanism is only one, and it's a particularly weak one at that. [I also note that DOCTYPE declarations have the same problem: there is no defined way to map a set of declarations to the definitions of their semantics. A DTD declaration set merely defines a set of names and some (but not all possible) syntactic constraints on the use of those names. A DTD declaration set does not define semantics any more than a regular expression defines the semantics of the string it is matching. Any use of external DTD subset external identifiers for this purpose is misguided because it has no enforcable authority. Consider this document: <!DOCTYPE mybook PUBLIC "-//Hal and O'Reilly//DTD Docbook//EN" [ <!ELEMENT mybook EMPTY > ]> <mybook/> What is the semantic relationship of this document to the semantics defined by the DocBook documentation? Impossible to tell from the information provided. The fact that the external DTD subset includes all the Docbook DTD declarations is irrelevant--because the document element is not from that set, there's not even a syntactic binding to the Docbook rules. That is, an external DTD subset external ID has exactly the same value for infering semantics that a namespace identifier does, that is, none.] Thus, for purposes of binding names to semantics, name spaces add no significant value because the binding of any namespace to a given set of semantics is just a convention you have to know: there's no way for a machine to recognize or validate it. As a convention, it's useful enough--the Web has taught us that you can get a lot of mileage out of established conventions, but conventions are no substitute for solid, explicit, machine-understandable bindings, and the name space spec *does not give us any*. Whether it should have or not is another issue. My personal feeling is that without such a binding, namespaces are at best of marginal value and at worst dangerous because they lead to inappropriate or incorrect assumptions about things. XML *already provides* a mechanism for defining vocabularies of names: DTD-syntax DTDs (and, as explained above, that's *all* they do). It would have been trivial for the namespace spec to define that as the standard mechanism for defining vocabularies (while allowing the use of other, non-standard mechanisms). It would have been trivial to add a "schema binding" attribute to the name-space declaration (it doesn't matter what the form of the schema definition is, because at the end of the day it's only the prose that really matters anyway). What would have been harder would have been a per-element binding or a one-to-many element-to-namespace/schema binding. That probably would have delayed the spec indefinitely. I presume the XML schema mechanism will also provide a standardized syntax for defining vocabularies and semantics (or at least explicitly binding names to semantic definitions, whatever form they may take). When it does, that mechanism can be used in addition to or in place of DTD-syntax DTDs. The spec > was ambiguous enough in it's concrete application (beyond abstract > grouping) that the world is indeed running forward to bind things. Indeed, > there is significant disagreement even in the upper levels of W3C about > whether a namespace can bind to a schema or DTD (one to one, or even one to > many), so this question is hardly resolved. What's to disagree about? There's no mechanism there. Which is not to say that there couldn't be one, just that there isn't one now. Whether the job of binding was > something that should have been done by the namespaces spec or another spec > is a bit of a side-argument. It seems clear to me that there is a need that > is currently unfilled, so it's occurring outside the W3C recommendation space. Exactly my point: without this binding, you're building a house of cards. > >[But what is looks like to me is that the really have three different > >*DTDs* (or rather, architectures) for the same base names. If this is in > >fact the case, then the XHTML authors have inappropriately confused name > >spaces with DTDs and they should fix that. > > No, we've not confused them. We happen to have three 'flavors' of XHTML 1.0 > (the first deliverable from the XHTML project, not the end sum of our > work), that essentially map to the three flavors of HTML 4.0. Each of them > was assigned a namespace that corresponds in title to the three flavor > names. We do not mistakenly confuse their DTDs for their namespaces. (nor > are we limiting XHTML to the use of DTDs, Schemas, as has been pointed out, > 'isn't soup yet') But: name spaces do not define anything. Therefore, a namespace cannot be the *definition* of what these three flavors are. Therefore, those definitions must exist somewhere. Therefore, there must be document type *definitions* (not *declarations*) that define these flavors, separate from the names of the name spaces that map to those definitions. The syntactic form of the document type definition is irrelevant--all should be provided as a convenience to users. You can't require the use of any particular mechanism in any case (and you can't require the non-use of any mechanism either--support for DTD-syntax DTDs is not an optional feature of XML (validation against those declarations is)). That is, if XHTML (or any semantic spec) defines name spaces, it must also define what those name spaces map to. The name space is not the thing. Therefore there must be a thing. Cheers, E. 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