why distinctions within XHTML?

[Hunter, David]

> From: Mark Birbeck [mailto:Mark.Birbeck at iedigital.net]
> Sent: Wednesday, September 01, 1999 9:42 PM

<snip/>

> My argument is that in the future, version >1 of XHTML will be
> modularised and so you will actually do this:
> 
> <order xmlns="myorderstuff" xmlns:bl="xhtml.block.text.module">
>   <customer>Fred Jones</customer>
>   <comments>
>     <bl:p>Bought <bl:em>500</bl:em> units!</bl:p>
>   </comments>
> </order>
> 
> Note that I've moved the namespace definition down a level from
> 'comments' because you wouldn't put it there. All you would need to do
> would be to define in your schema that 'comments' can have 
> children from
> the 'XHTML block text module'. (Quite why David M thinks each new
> namespace should be at the 'comments' level is baffling me. A million
> namespaces!?!) In other words, you won't be using 'strict',
> 'transitional', or anything. In terms of post-parsing processing, in
> this scenario a 'p' is a 'p' is a 'p' (as everyone wants, 
> albeit a bl:p
> now, instead of a generic html:p). However, at the moment none of this
> exists, although it is a stated goal of XHTML. (If you 
> haven't already,
> have a look at the modularization document - it's very impressive.)

<snip/>

Mark, 

We're still in total agreement, except for the
xmlns:bl="xhtml.block.text.module" piece.

What I (and others) are saying is that the "xhtml.block.text.module" should
be a *single* XHTML namespace right from the get-go; one single string, that
any XML parser from now unto eternity can look at and say "this is XHTML".
It can then, if it wishes, pass the XHTML pieces to an XHTML-specific
application for rendering or whatever.  If XHTML 1 brings three namespaces,
then there are three strings we have to look for to determine if this is
XHTML.  If XHTML 1.1 or 2 brings XHTML back to just one flavour, then a new
namespace will have to be introduced; now we have 4 namespaces that we'll
have to look for.  (One we'll be expecting, and two that are deprecated, but
we'll still have to look for them just in case.)  Even this wouldn't be
<em>too</em> bad.

<speculation inside-knowledge='none'>But I don't think that we'll end up
with 4 namespaces.  Unfortunately, as people keep pointing out, this is all
PURE guesswork, but it looks like the XHTML group is leaning towards a
namespace for every "module".  (Say, one for XHTML tables, and one for XHTML
frames, and one for XHTML paragraphs, and one for XHTML divs?...)  This gets
worse when things change; what if an element name in XHTML tables changes
from XHTML 2 to XHTML 3?  Well, *another* namespace will get invented, for
the new version.</speculation>

I understand the reasoning behind the XHTML group wanting three versions, to
mirror the three versions of HTML 4.  But I would like them to start, from
the very beginning, to treat XHTML as various parts (modules) of *one
vocabulary*.  A vocabulary that could be identified by a single namespace,
so that in the future, when integration of XHTML and other XML vocabularies
is possible, it will also be easy to identify the XHTML pieces, so that they
can be processed by our XHTML applications.

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)