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

[W. Eliot Kimber]

Ann Navarro wrote:
> 
> At 06:41 PM 8/29/99 +0100, W. Eliot Kimber wrote:
> 
> > > 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.
> 
> I didn't say they did define anything. I said they each have a namespace.
> Period. They each have a DTD. Period.

Ah, my mistake--you're right, the two are separate (and separable).

But I think it's more accurate to say:

XHTML defines three distinct (but related) document types, each with its
own DTD declarations, etc. Each of these document types *is considered
to be* the definition of the corresponding name spaces x, y, and z.

That is, it's not meaningful to say that a DTD *has* a name space,
because a name space isn't something that a DTD can have. It is only
meaningful to say that a DTD defines some or all of the vocabulary for
which a name space name is the name (remembering that as defined in the
name space recommendation, a name space is merely a name for a notional
name space--the actual vocabulary (that is, the set of names in the name
space) has no defined formal definition from the point of view of the
name space spec).

But I'm splitting hairs in order to make the point that name spaces, by
themselves, are worthless. If the XHTML spec formally defines document
types and defines the intended binding between names in a given name
space and the types defined, that's fine, because at least I will be
justified in building that binding into my programs.

But, having said that, I think that David's point is now well taken:
there is no need to conflate the *syntactic* distinctions that these
three flavors of XHTML make with the *semantic* distinctions they make.

That is, an HTML paragraph is an HTML paragraph whether its content is
restricted or unrestricted. That's why I said there are *four*
definitions, not three: one for the base semantic types and three for
the syntactic (and possibly semantic) specializations.  By using a
single name space name for all three (or four) variants, you let cheap
processors make inferences about meaning from names with a minimum of
extra effort. It's still a dangerous game, but at least the convenience
of playing it has been improved.

Note that you still have to declare in your document which variant
you're using, but that could be distinct from the base semantic
binding.  That is, you could have one name space for all flavors of
XHTML and use some other mechanism for indicating which semantic flavor
you want (e.g., a normative external DTD setup, an architecture use
declaration, a reserved attribute, etc.).

The use of name spaces is a *convenience* and the fact that name spaces
have no defined semantic implications means, in part, that there is no
necessary correlation between them. Thus, XHTML could as easily have one
name space as three--it wouldn't change the base problem of knowing
which semantic (and syntactic) variant you have.

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)