Re: What's the problem? "Reuse of 1998 XHTML namespace is potentially misleading/wrong"

Larry Masinter wrote:
> The fact that one language makes <title>abc</title> equivalent 
> to <meta property="title" content="Document Title"/> and the other 
> does not does mean the languages are incompatible. But the elements 
> "title" and "meta" have the same meaning as vocabulary items, their 
> usage is different in the two languages.

I mentioned many more issues other than that one, and I didn't say all 
of them had namespace incompatibilities.  That one, at least in theory, 
may not have a direct impact on the namespace.  But it has other issues, 
like interacting with the DOM (document.title), and lack of defined 
processing requirements.  This would create significant problems for 
implementations, which makes it effectively incompatible anyway.

But these are some of the elements that are not backwards compatible and 
cause namespace conflicts:

* <label>
   - Used as both a list label and, although the spec isn't entirely
     clear about this, an XForms control label.

* <input>, <select>, <textarea>
   - Uses the XForms processing and content models. This is a very major
     incompatibility relating to both DOM APIs, processing and authoring
     requirements.

* <object src=""> vs. <object data="">
   - Unnecessarily changes the attribute, and fails to define processing
     requirements. e.g. What happens with <object data="..." src="...">?
     How does that affect UA processing, and what effect does that have
     on the DOM API?

* Renaming <script> to <handler>
   - Unnecessarily renaming, effectively introduces a second element for
     exactly the same purpose.

I believe there are others, but I'd have to go hunting through the spec 
to find them.

>> Basically, the only solution to this issue that should be considered is 
>> that we continue using the namespace and the XHTML2 WG use a different 
>> namespace.
> 
> It is not a useful style of argument to assert that the only 
> solution that should be *considered* is the one you favor. 
> Certainly there are other solutions that should be considered, 
> such as using the same namespace and resolving any compatibility 
> issues that might otherwise arise.

It wasn't an argument.  It was a conclusive statement based on prior 
arguments raised in previous discussions, some of which I linked to, and 
the fact that there is no technical justification for us to even 
consider changing our namespace.  (Though I'm not really all that 
concerned about what the XHTML2 WG does.)

>> Otherwise, I will propose closing the issue.
> 
>> Absolutely, keeping this issue open is unnecessary.  The issue is 
>> entirely political, with no technical justification for us to keep it 
>> open.  It should be closed immediately.  At most, a separate issue 
>> should be raised with the XHTML2 WG to make them use an alternative 
>> namespace.
> 
> That isn't what I propose, actually; what I propose is continuing 
> to use the same namespace, but resolving any vocabulary incompatibilities, 
> (not language or processing rule incompatibilities, note) either 
> by changing XHTML5 or XHTML2 to remove the vocabulary incompatibility, 
> or renaming the element or attribute name in one or the other to 
> remove the vocabulary incompatibility.

Considering that work on HTML5 initially started in part because the 
XHTML2 WG failed to address the many issues, including the compatibility 
issues, that isn't really going to be a viable option.  If it were, it 
would have been done years ago.  For now, the quickest option is for us 
to keep using the namespace as we always have and close the issue.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Wednesday, 11 February 2009 23:57:20 UTC