Lists Home |
Date Index |
- From: "Sebastian Schnitzenbaumer" <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 9 Sep 1999 19:10:50 +0200
> > 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
An application processing a specific XHTML document instance
has no indication to which kind of XHTML this document instance
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
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.
Stack Overflow AG
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)