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

Re: Namespace

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 17 Jul 2007 00:10:13 -0700
Cc: HTML WG <public-html@w3.org>
Message-Id: <66CBABA7-0BFE-48A7-B6F8-B017628595E5@apple.com>
To: Robert Burns <rob@robburns.com>


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.

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.

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.

Regards,
Maciej


> 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 07:10:51 UTC

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