RFP: Namespace URI for HTML

[Sebastian Schnitzenbaumer]

> > I'm very surprised that the list does not include the current
> > approach taken by the HTML WG. This poll seems to suggest that
> > one namespace for every flavor of XHTML is the only right choice. I
> > agree with Tony and others who consider 3 namespaces as a
> > possible solution.
> 
> I think a lot of folk are still waiting to hear a good reason
> why more than one is needed ... given that the vocabulary (HTML)
> is distinct from the rules (transitional/strict/frameset) that
> may be used to assemble them, both now and in the future.

Okay - here we go.

The namespaces concept, at least in the view-point of some 
individuals, is a very abstract concept. The namespace is a 
collection of names, regardless of document type. 

Given that theory, we could think of the HTML vocabulary as a 
single namespace. Every flavor or variant of XHTML belongs to the 
single XHTML namespace.

Namespaces are also used for identification, especially, the value 
of the xmlns attribute is to indicate to which namespace this 
document instance, fragment or element belongs.

If there is no indication of the flavor of XHTML, we come out with 
the following scenario:

Strict, Transitional and Frameset may all have the same <p> and 
the same <h1>, but that alone does not imply that it is all the 
same thing. In fact there are substantial differences between these 
three variants.

An application processing a specific XHTML document instance 
has no indication to which kind of XHTML this document instance 
belongs.

Why is this important? The major HTML browsers don't care, they 
can process any HTML regardless of type. This will change in the 
future. In fact, we have an array of specialized user agents coming 
up. If we talk about the future of HTML, keep in mind that we will 
see HTML in many different environments. XHTML is not designed 
to make life better for heavy user agents, moreover, XHTML is the 
key for the web to rapidly expand to other devices than the desktop 
PC.

A heavy user agent might not care, but for a microbrowser in a cell 
phone, there is a huge difference between strict and frameset.

Why not introduce a custom "variant indentification system" for 
XHTML? Possible solution: re-introduce the version attribute on the 
HTML root element specifying the XHTML variant. The problem here 
are fragments. I want to include a piece of XHTML in a document 
instance other than XHTML. Again, for many user agents, there is 
big difference between allowing a <frameset> to be included 
anywhere in an XML document instance or just basic, strict XHTML 
that is much cleaner and requires less resources and 
implementation costs. The version attribute on the HTML root 
element is not there when any xhtml element is included 
somewhere in another XML document instance, the only thing we 
have for identification is the value of the xmlns attribute.

Unfortunately, I must stop here. There are more reasons why the 
HTML WG has chosen 3 namespaces. I'll be happy to continue 
this conversation later.

Best regards,

Sebastian Schnitzenbaumer



---
Stack Overflow AG
Phone: +49-89-767363-70

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)