RFP: Namespace URI for HTML
Marc.McDonald at Design-Intelligence.com
Marc.McDonald at Design-Intelligence.com
Fri Sep 10 00:08:10 BST 1999
But an HTML processor is supposed to accept a well-formed document and
gracefully ignore unknown elements (actually treat them as text). So, what
happens when your cellphone microbrowser gets a frameset document instead of
a strict document? Does it just put up an error box and show nothing? How
does a non-validating parser ensure a document is frameset or strict?
Namespaces do not define the set of valid names, they only allow
differentiation. Without validation there is no enforcement that a document
is strict, frameset or transitional. Since the namespace declaration has no
enforced meaning, why bother with it?
The only reason I've seen presented is fragments. BUT, there is a fragments
working group, why not let them find a general solution to the problem? Why
are you usurping their authority?
Marc B. McDonald
Principal Software Scientist
Design Intelligence, Inc.
1111 Third Avenue, Suite 1500
Seattle, WA 98101
marc.mcdonald at design-intelligence.com
> From: Sebastian Schnitzenbaumer[SMTP:schnitz at overflow.de]
> Sent: Thursday, September 09, 1999 10:10 AM
> To: xml-dev at ic.ac.uk
> Cc: David Brownell; abcoates at TheOffice.net
> Subject: Re: RFP: Namespace URI for HTML
> > > 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
> 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.
> 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
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev