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

Hi Robin,

On Feb 12, 2009, at 4:48 AM, Robin Berjon wrote:

>
> Hi Robert,
>
> On Feb 12, 2009, at 11:12 , Robert J Burns wrote:
>> On Feb 12, 2009, at 3:15 AM, Robin Berjon wrote:
>>> I really don't understand your point? Are you saying that elements  
>>> with different semantics with the same fully qualified name are  
>>> always bad? So long as they can be distinguished by context, it  
>>> really doesn't matter. The only thing it breaks is DTD validation  
>>> and no one sane would ever care about that.
>>
>> I'm not sure I disagree with what you're saying in terms of reusing  
>> the same name in different contexts. However, there's no reason to  
>> expect that two separate elements with the same name will only be  
>> used in different contexts. For example, imagine that XHTML2 adds  
>> an element 'small' that means the text is smaller than the  
>> surrounding text (visually only). However, HTML5 introduces a  
>> 'small' element where the element means specific legal  
>> disadvantages or caveats. Imagine another meaning of 'small'  
>> element is as a small thought not directly relevant to the main  
>> topic of the document. I'm not sure how context gets us out of the  
>> name collision problem. Unless you mean that a heuristic reading by  
>> an intelligent  human can always discern what all the text in a  
>> document is about, but then we could just name every element in the  
>> XHTML namespace 'small' from the root element on down the list. So  
>> if a new semantic is worth introducing, I think it is worth  
>> introducing a new name for that semantic instead of overloading  
>> existing names. If its not worth introducing a new name it probably  
>> is not worth introducing the new semantic.
>
> To be fair in the case of 'small' I think the name is poorly chosen  
> anyway, but for other reasons. It should be 'smallprint' (even when  
> the style sheet renders it big on screen media) or something  
> similar. I reckon 'proviso' might be a good pick.

I agree. My main point is that we should not be claiming the same  
namespace, but reusing the same name for different semantics which as  
you add, can appear in the same context.

> For certain the case of two elements carrying different semantics  
> that may appear in the same context is undesirable (see 'input' for  
> precedent).

Well 'input' is not a problem as serious as 'small'. The 'input'  
element has differing semantics distinguished by another attribute. No  
such attribute is proposed to differentiate the two meanings of 'small'.

> But I was thinking *within a single language*, if you recall I was  
> pushing back on your claim that HTML5 conflicted with itself. The  
> case of two languages sharing the same namespace is another issue  
> with a totally different entertainment value.

Well HTML5 by using the same namespace as XHTML1.0 with no versioning  
is in a sense conflicting with itself. I just used the example of  
XHTML2 to make it more relevant to the current discussion. But the  
example I gave applies to the HTML namespace when only considering the  
current draft of HTML5 (even if the XHTML2 WG did not exist).

>>> What matters is if a v1 implementation cannot do anything useful  
>>> with a v2 document (and worse, vice-versa) or if an implementation  
>>> cannot usefully distinguish between two incompatible languages  
>>> sharing the same language.
>>
>> Which can be completely avoided by avoiding name collisions. With  
>> no name collisions, its possible to allow an implementation to  
>> distinguish among every semantics in the namespace even if they  
>> come from two or ten different WGs
>
> No, I'm afraid that to ensure compatible versioning you need a fair  
> bit more than avoiding name collisions :)

I'm not clear what you're saying here. In terms of sharing a  
namespace, the only things we need to do is ensure our names do not  
collide with those of any other recommendation sharing the namespace.  
My point here has been to say that our current draft already  
introduces name collisions with ourselves (as you say) even before we  
consider cooperation with the XHTML2 WG. The goal for HTML5 is to not  
do any versioning. So the namespace is an unversioned namespace. And  
compatibility is a separate issue entirely (with two different common  
uses, legacy content compatibility and legacy UA compatibility).

> My only push-back here is in using pseudo-technical arguments  
> (vocabulary clashes, term reuse, etc.) to point fingers when what is  
> really needed is someone with a little time to either resolve the  
> differences or at the very least document them.


Here too, I'm not sure what you're getting at. Perhaps it is pseudo- 
technical to speak about vocabulary clashes and term reuse. However,  
I'm not pointing fingers. I'm suggesting there aren't any serious  
problems between the two WGs.  If you want some sense you might take a  
look at the HTML4all analysis that pulls together both vocabularies. 
[1] It doesn't address the DOM methods and attributes, but there I  
think there's even less concern for name collisions (since most of the  
DOM attributes come from the content attributes). The point is though  
that without name collisions there is no incompatibility. An  
implementation can simultaneously implement XHTML2 and HTML5 and  
there's no problem. That's not to say there are no problems at all,  
but that there are no problems with the two sharing the same namespace.

Take care,
Rob

[1]: <http://html4all.org/wiki/index.php/HTML#Current_HTML_Efforts>

Received on Thursday, 12 February 2009 11:11:04 UTC