[Fwd: ATTN: Please comment on XHTML (before it's too late)]

[W. Eliot Kimber]

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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)