Re: Next steps for the ARIA syntax discussion

Hi Charles,

On Jun 3, 2008, at 9:57 PM, Charles McCathieNevile wrote:

> On Tue, 03 Jun 2008 15:52:25 -0300, Robert J Burns  
> <> wrote:
>> On Jun 3, 2008, at 7:27 PM, Charles McCathieNevile wrote:
>>> It appears we agree. The elements should be in the html namespace.  
>>> The attributes in the null namespace.
>> But only for non-XML namespace aware documents (or by extension  
>> documents unaware of other namespace recommendations). The point  
>> I'm trying to make and that I'm not sure we agree on is that  
>> recommendations such as HTML5 should not be trying to anticipate  
>> what the XML namespaces recommendation says about their attributes.  
>> It creates dependencies and undermines valuable abstractions, and  
>> we don't want to go there.
>> If that all makes sense to you and you agree, then indeed we do  
>> agree.
> Oh. Then we disagree on the outcomes :(
> I think we agree on the principle.
> Saying that the attributes in HTML are in the null namespace does  
> not anticipate anything that some future spec might say, nor does it  
> conflict with any current draft I know of, with regard to XML - it  
> is in fact perfectly in line with the specs and implementations that  
> have emerged in the 10 years of XML.
> It *also* simplifies the process of building applications, and the  
> process of explaining how to add aria to a new XML or non-XML spec.
> These two reasons are why I believe the PFWG will adopt the solution  
> I suggested above as its preferred model for both HTML and XML  
> languages.

I think we are not agreeing on principle then either. The last  
sentence where you say “both HTML and XML languages” indicates to me  
that you're not understanding what I’m saying. Since the XML  
serialization is largely the domain of the XML recommendation and  
namespaces in XML serializations are defined by the XML Namespaces  
recommendation, we should be careful not to say anything about the  
namespace of attributes for that serialization (and by extension  
namespace aware compound documents for text/html serializations  
either). These recommendations are abstracted and modularized:  
intentionally so. Repeating the information from another  
recommendation undermines that and causes potential conflicts down the  
road. Certainly implementations will place those attributes in the  
null namespace, I'm not contesting that. And certainly that makes  
things work for non-namespace aware processing in an  easier and  
better and more consistent fashion with XML namespace conforming  

Having said all that, we should make it clear that our recommendations  
only apply to the non-namespace aware documents (whether serialized as  
XML or text/html). In other words those documents not written to  
conform to any namespace recommendation (XML or otherwise). In that  
case, UAs should follow the relevant namespace recommendation or  
recommendations. It is a subtle point, but an important one.

Take care,

Received on Wednesday, 4 June 2008 09:59:29 UTC