W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Namespace

From: Robert Burns <rob@robburns.com>
Date: Tue, 17 Jul 2007 12:57:00 -0500
Message-Id: <26AD850A-A77E-4337-804D-B3E225236789@robburns.com>
To: HTML WG <public-html@w3.org>

On Jul 17, 2007, at 2:10 AM, Maciej Stachowiak wrote:
>
> On Jul 15, 2007, at 4:00 PM, Robert Burns wrote:
>
>>
>>
>>
>> On Jul 15, 2007, at 5:39 PM, Robert Burns wrote:
>>>
>>>
>>> On Jul 15, 2007, at 5:20 PM, Smylers wrote:
>>>
>>>>
>>>> However, HTML5 does note:
>>>>
>>>>  XHTML2 and this specification use different namespaces and  
>>>> therefore
>>>>  can both be implemented in the same XML processor.
>>>>
>>>> So at least from the point of view of using XHTML5 and XHTML2  
>>>> together
>>>> they are compatible.
>>>
>>> I think that's an error in the current draft. XHTML2 uses the  
>>> same namespace as XHTML1 and XHTML 1.. My understanding is that  
>>> XHTML5 also aims to use that same namespace. It's probably best  
>>> for us to assume they will be using the same namespace.
>>
>> I want to add too that I think using a namespace brings with it  
>> some responsibility. It's not clear exactly what that  
>> responsibility is (perhaps we need more guidance from TAG on  
>> this), but to me it relates to maintaining the semantics of names  
>> (whether element names, attribute names or attribute values in the  
>> namespace).  Just as an example, let me list some possible  
>> namespace violations from most important to least important.
>
> I would replace all your theoretical criteria with a single,  
> operational one:
>
> 1) Given a typical document in namespace Foo authors to Foo version  
> A (as informed by action use of Foo), what is the likelihood that  
> it will be interpreted and presented as intended by an  
> implementation of Foo version B? This is the practical degree of  
> namespace compatibility between A and B.

I don't know why you would say it's arbitrary. That's simply what a  
namespace is. You're trying to describe something else inductively  
(with the term likelihood in there) that has more to do with  
measuring compatibility. You may be on to something regarding  
compatibility, but it has little to do with namespace.

And I can assure you that violating a namespace (in other words  
causing name collisions) will be very likely to be interpreted and  
presented incorrectly. Earlier I gave the example of changing the  
semantics  of <small>  from meaning "presentationally small text" to  
meaning "legal descriptions and other disadvantages" With that, "the  
likelihood that it will be interpreted and presented as intended by  
an implementation" falls dramatically. In other words you have what  
amounts to two elements (presentational small text and legal mumbo  
jumbo) that each share the same name. That's guaranteed to lead to  
compatibility issues.  From my earlier example, a UA that strips out  
<small> elements and converts them to CSS will be stripping meaning  
out of a document. You may say, well no tool should be stripping out  
<small> because it has a special meaning in HTML5. Well this tool did  
not know about HTML5 and even if it did, it cannot distinguish an  
HTML5 <small> element from an HTML4.01 <small> element (those are two  
different elements now). It is a nifty little trick to get these new  
elements to have a reasonable default rending in some exiting UAs.  
However, this is just like the author who picks an element to get it  
to look correct rather than using CSS and selecting the element that  
means what the author intends. Except, in my view this is even worse,  
because we should know better. We shouldn't be changing the meaning  
of elements (or creating new elements with the same names as old  
elements which is really what this amounts to) simply because it will  
tend to render correctly in some visual UAs. It is a nifty  
compatibility trick, but that's all it is and it means we are either  
in a new namespace or we've undermined the existing HTMl namespace.

> By this definition, changing the attribute names, attribute values,  
> and DOM APIs for a commonly used element and replacing them with  
> something incompatible is a much more serious violation than  
> slightly changing the defined abstract meaning of an element  
> without affecting behavior or rendering. The former is much more  
> likely to cause a Foo version A document to fail in a version B  
> processor.

In the UAs that you're targeting, yes introducing new attributes and  
values will create new named facilities that existing UAs will not be  
familiar with. However, there are all sorts of UAs (and I'm using  
user agent in the broadest possible way) that we are not even aware  
of and cannot take those into account. The makers of these tools have  
been told there is an HTML namespace. And to them they assumed the  
stewards of that namespace would take their stewardship seriously:  
i.e., not deliberately create name collisions.

Again, you're operational definition is much more about compatibility  
generally: not about namespace preservation. However, the current  
HTML5 draft violates the HTML namespace in order to get some nifty  
default rendering compatibility with certain selected UAs. Much of  
HTML5 does not rely on undermining the namespace: there are only a  
few areas that do (mostly in changing element and attribute names).

This is not only about current UAs, but future UAs. Authors too  
expect the namespace to be maintained. In that way they can author a  
document in 1995 and the elements, attributes and APIs used in that  
document will have the same meaning in 2095. Sure it may be rendered  
with 3D holographic browsers, but the meaning will remain the same.  
If we don't preserve the  integrity of the namespace and also don't  
add versioning (which we would need to do if we violate the  
namespace), then there's no way to discern which of the two elements  
the element named "small" actually is.

> I think defining namespace violations only in terms of the abstract  
> meaning ascribed to elements, and almost completely ignoring  
> attributes and APIs, is completely arbitrary.

It is not arbitrary to define terms abstractly: that's they way terms  
are always defined. Also, I did not ignore attributes nor APIs at  
all. Attributes are discussed in my initial post and I thought I  
didn't also need to mention APIs. Both attributes and APIs too fall  
into the types I delineated. Creating a new API, but using name for  
an existing API would also be a namespace violation. Even character  
references could be included here. We should not define &minus to  
mean a hyphen simply because it renders roughly like a hyphen. Yes  
the rendering will work. However, the underlying semantics will be lost.

Let me just underscore that this namesapce issue is not the same  
thing as backwards compatibility (though ti is related). XHTML2 may  
have horrible backwards compatibility issues that they may never  
recover from (I don't believe that, but I'll just grant that for the  
sake of argument). However, they do not have the serious type 1  
namespace name collisions that our current draft introduces.

> On Jul 15, 2007, at 4:00 PM, Robert Burns wrote:
>> 1) meaning: and this relates not only to UA treatment, but also  
>> the meaning ascribed by previous recommendations.
>> (In other words the visual UAs (or even the subset of all UAs we  
>> may be aware of) may only treat certain semantics as meaningful  
>> (like adding the title element's contents to the windows title  
>> bar). Other UAs may rely on the meaning of <small> to be small  
>> print in only the presentational sense. For example, they may make  
>> assumptions that <small> can be stripped and replaced with some  
>> CSS. So changing the meaning of <small> has serious namespace  
>> consequences.)
>> 2) subtracting from the content model: i.e.,
>> 	content model for elements
>> 	making data type more restrictive for attributes
>> 3)removing names from the namespace
>> 4) adding to the content model: i.e.,
>> 	content model for elements
>> 	making data type less restrictive for attributes
>> 5) adding names to the namespace
>>
>> There may be other issues, I'm not thinking of right now with  
>> respect to name changes.
>>
>> Particularly  for the first issue, its hard to imagine how we can  
>> adhere to a namespace if a name now means something else. To me  
>> the very idea of namespace is a commitment that there will not be  
>> name clashes within that namespace. In other words if a new  
>> semantic is required it will be accomplished through a new name.  
>> Especially if we do not provide versioning information along with  
>> the namespace (though even that seems like a hack since we should  
>> simply declare a different namespace). I'm very much in favor of  
>> HTML5 maintaining the same HTML namespace in the XML  
>> serialization. It completely fits with our other design  
>> principles. However, I think we need to consider what  
>> responsibilities and requirements that adds to our project.


Take care,
Rob
Received on Tuesday, 17 July 2007 17:57:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:47 UTC