W3C home > Mailing lists > Public > wai-xtech@w3.org > May 2008

Re: null namespace Re: Next steps for the ARIA syntax discussion

From: Robert J Burns <rob@robburns.com>
Date: Thu, 22 May 2008 18:33:44 +0000
Cc: "Aaron M Leventhal" <aleventh@us.ibm.com>, www-tag@w3.org, "public-html@w3.org Group" <public-html@w3.org>, public-xhtml2@w3.org, "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>
Message-Id: <F3D41174-01E5-47BC-B8BE-5E56C3529F47@robburns.com>
To: "Charles McCathieNevile" <chaals@opera.com>

Hi Charles,

I don't want to let this thread get out of hand, so let me just focus  
on a specific part that I think we agree on.

On May 22, 2008, at 12:08 PM, Charles McCathieNevile wrote:

> On Thu, 22 May 2008 12:38:20 +0200, Robert J Burns  
> <rob@robburns.com> wrote:
>
>
>> Yes, I understand. However, the problem is we need to read the  
>> recommendation and understand why the recommendation exists in the  
>> first place. The point is to combine disparate vocabularies into a  
>> single document. I cannot think why an author would want the same  
>> attributes (in terms of vocabulary) to appear in two different  
>> namespaces within the same document.
>
> I don't think you want the same attribute to be in two different  
> namespaces.

Agreed on this point exactly. However the introduction of the null  
namespace by implementations (and arguably that reading is easily made  
in the recommendation itself), does just that: it puts two attributes  
 both from the same vocabulary and sharing the same semantics  in  
two separate namespaces (one the null namespace). The same attribute  
from the same vocabulary  all sharing the same semantics  end up not  
being in the same namespace (because one is in the null namespace and  
the other is in a namespace declared and then specified with a  
prefix). It is completely counter to the purpose of the namespaces  
recommendation  which in my view is intended to allow authors to  
easily mix vocabularies. In some cases it prevents authors from being  
able to take advantage of the convenience of omitting the prefix.

In some authoring situations, the author may be better off to always  
include a prefix (even when it might otherwise have been omitted)  
because of this error in the spec and in the implementations.

My point is that if we introduce namespaces to text/html  and I  
definitely think we should  then we should not follow the mistake of  
XML namespaces (both mistakes in the recommendation document and in  
the implementations). I am arguing that the headaches created by that  
mistake are much greater than the headaches created by differing on  
this point with XML namespaces. To do the latter means that authors  
would first have to alter their stylesheets and DOM handlers to change  
from existing use of a null namespace to use of a namespace that maps  
one-to-one and completely with the related vocabulary.

It is also possible that someone creative may come up with a way to  
fix the XML namespaces recommendation and implementations without  
seriously breaking existing content.

Take care
Rob
Received on Thursday, 22 May 2008 18:34:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:49 GMT