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

Namespace

From: Robert Burns <rob@robburns.com>
Date: Sun, 15 Jul 2007 18:00:55 -0500
Message-Id: <9C1DD46A-0F67-4139-A473-88DB85C48396@robburns.com>
To: HTML WG <public-html@w3.org>



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.

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 Sunday, 15 July 2007 23:01:04 UTC

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