W3C home > Mailing lists > Public > public-html@w3.org > February 2009

What's the problem with Reuse of 1998 XHTML namespace?

From: Robert J Burns <rob@robburns.com>
Date: Mon, 16 Feb 2009 17:33:08 -0600
Message-Id: <59088A53-710A-4805-8824-BA28D695BDA0@robburns.com>
To: HTML WG <public-html@w3.org>

No one has really answered this question (in the subject). Before  
engaging in lengthy discussions about how to solve the namespace  
issue, it would be a useful exercise to determine where the name  
collisions exist.

I've pointed out the problem with HTML5 redefining the 'small' element  
before. This also goes for the 'strong' element and several other  
presentationally related elements. Lachy claims, but has not yet  
demonstrated, XHTML2 has name collisions with XHTML1. Though he has  
failed to demonstrate any, lets take that as a given.  Those two  
problems represent namespace issues within each project and not  
between both projects.

So first and foremost, each project needs to fix the namespace name  
collisions within its own draft. Secondly, we may require some  
coordination to avoid name collisions between XHTML2 and HTML5, though  
I've yet to see anyone provide an example. So as far as I'm concerned  
we haven't really identified a problem regarding namespace to solve yet.

As an aside, some mention irretrievably irreparable DOM issues that  
XHTML2 has with itself. This claim usually goes along with some  
considerable hand waving, and no elaborated details whatsoever. So it  
is difficult o determine what it refers to. However, since XHTML2 has  
very little to say about DOM, I assume this is mostly related to the  
globalization of attributes. While XHTML2 should probably say  
something about this, it still doesn't constitute a name collision  
problem. If the 'href' DOM attribute is directly defined as a  
DOMString attribute on the HTMLAnchorElement or on the HTMLElement  
interface and inherited, does not constitute a name collision. In fact  
HTML5 could define it in the latter way and XHTML2 could define it in  
the former way, an implementation could implement it in the XHTML2  
way; and HTML5 authors would never notice the difference (except  
through some inconsequential error). Like other namespace issues DOM  
namespace issues would have to be a name collision where a DOM  
attribute or DOM method of the same name returned different data or  
even the same data of a different type. A DOM issue cannot be simply  
based on the class hierarchical factoring of the interfaces.

So before we write endless diatribes about which project needs to give  
up on the namespace, let's first identify some real problems with name  
collisions between the two projects (as opposed to the name collisions  
within each project that each project needs to fix anyway).

Take care,
Received on Monday, 16 February 2009 23:33:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC