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

[W. Eliot Kimber]

David Megginson wrote:
> 
> Eliot Kimber writes:
> 
>  > Oren Ben-Kiki wrote:
> 
>  > > Providing three different namespaces which have the same
>  > > semantics would force application writers to abandon this
>  > > assumption. In XHTML, 'traditional:p', 'strict:p' and
>  > > 'frameset:p' are the same thing. This would seriously mess XHTML
>  > > applications up - put another way, it would cause generic XML
>  > > applications to fail on XHTML documents.
>  >
>  > Why would three name spaces cause more failures than one name space?
>  > Either you know what the names mean or you don't.
> 
> Because human beings write computer programs:
> 
> 1. It is necessary to perform three tests rather than one to identify
>    a name from XHTML: that means three separate patterns in XSL (for
>    example), three separate contexts in a context-sensitive search
>    engine, three separate XML queries, three separate XPointers,
>    etc. etc.

I think that points up a general failure with the architecture: what you
really want to do is match things based on their base semantic binding,
not on their local name. Namespaces don't (and can't) do that. If there
was an explicit ns-to-semantic-definition binding, it wouldn't be a
problem, because you could establish clear and machine-understandable
type hierarchies and process in terms of any point in the hierarchy.

But that requires a lot of machinery, which is probably beyond the W3C
to define at this point in time. 

Or maybe XHTML should wait until the schema spec is done, when
presumably such a mechanism will be provided (and if Schemas don't
provide it, we've got a real problem).

It also points up a problem with simple-minded processors that make
assumptions about local names that are not justified.  

A request like this, while probably reasonable on practical grounds
(which I don't dispute) cannot be justified on practical grounds
alone--there are clearly important architectural issues that this
problem is exposing that need to be resolved. Once those architectural
problems are resolved, then the appropriate practical solution should be
obvious (or at least easily developed).
 
>    All of this means three times the opportunity for bugs and
>    interoperability problems (and yet more accusations that the W3C
>    cannot create specs that work together).

I think it's a little too late for the last one.
 
> 2. If the intention of XHTML is to continue to create new Namespaces
>    for future versions of XHTML, you run into a serious deployment
>    problem where old software will not work properly with new
>    documents.  If you don't believe that versioning is a problem on
>    the Web, then look at the lack of even Java 1.1 applets for general
>    use (because Netscape 3.0 doesn't have a Java 1.1 VM).

I'm sure that versioning is a big problem. And I'm sure that whether you
use one ns per version or three doesn't really matter: the nature and
severity of the problem are the same. Or rather: if you can manage one
ns/version you can manage three and if you can't manage three, you
probably can't manage one.

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)