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

On Wed, 21 May 2008 22:26:25 +0200, Robert J Burns <rob@robburns.com>  
wrote:

> Hi Charles,
>
> On May 21, 2008, at 11:53 AM, Charles McCathieNevile wrote:
>
>> On Fri, 16 May 2008 12:07:43 +0200, Robert J Burns <rob@robburns.com>  
>> wrote:
>>
>>> In my view the null namespace should not exist in a
>>> namespaced document processed by a namespace aware application.
>>
>> It results from a misinterpretation. People naively assumed what you  
>> would like to have (attributes inherit the namespace of the element  
>> they are attached to unless otherwise declared), but that isn't what  
>> the spec says...
>
> The spec actually says it both ways (as null URI and according to the  
> element they are attached to).

All I can find to support a reading along those lines is section 6.2 para  
2:

[[[
A default namespace declaration applies to all unprefixed element names  
within its scope. Default namespace declarations do not apply directly to  
attribute names; the interpretation of unprefixed attributes is determined  
by the element on which they appear.
]]] - http://www.w3.org/TR/REC-xml-names/#defaulting

As far as I can tell this says what I claim, that the namespace  
declaration does not apply to the attribute. The fact that the  
interpretation of the attribute depends on its element is a way of dealing  
with collisions that can arise. For example in SVG the "fill" attribute  
can either be about a colour used to fill a graphic object, or about what  
to do once an animation has reached its defined end. If there is a fill  
attribute in the null namespace that is designed for (say)  
SwimmingPoolControlML, and you find it on the element MyPool which is in  
the SwimmingPoolControlML namespace, then that language determines what to  
do with the attribute in that case.

The attribute itself still has a null namespace - equivalent to a declared  
namespace of "", since 'Default namespace declarations do not apply  
directly to attribute names'.

See also the statement in section 6.3 that introduces the final example:

[[[
However, each of the following is legal, the second
because the default namespace does not apply to attribute names:
]]]     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  - http://www.w3.org/TR/REC-xml-names/#uniqAttrs

The original reason for my checking this so carefully originally was that  
I really badly messed it up by making the assumption I have since found is  
extremely common - that attributes inherit the namespace as elements do.  
If I really have missed something, please let me know. I have been careful  
to base my interpretations on reading the text as it is, independently  
arriving at the conclusion that was also reached by the implementations I  
know of. As far as I can tell, my conclusion is sound, and I cannot find  
another one that fits the text, although it was counter-intuitive to me as  
a way that namespace defaulting would work.

>> I do not think it is worth trying to change now - because to be honest  
>> I don't see it causing massive problems. (Yes, people make mistakes  
>> from time to time due to this - and I made mine very publicly :(, but  
>> equally they can still learn in about 3 minutes, and it seems that they  
>> do).
>
> No, I think it is a major headache for authoring situations.

If the authoring situation becomes that you never have a prefix for these  
attributes (unless you have a prefix that maps to the empty string) a la

<something xmlns:aria="">
   <foo aria:aria-describedBy="...">...

or

<svg:svg xmlns:svg="http://www.w3.org/2000/svg">
  <svg:g aria-describedBy="..." x="32" y="64" ...

or in the screw case

<aria:html xmlns:aria="http://www.w3.org/1999/xhtml">
...
   <aria:div title="some control thingy" aria-describedBy="..."

then namespace processing works consistently with what the namesace spec  
says and what the implementations do. Putting the prefix in as per the  
first example is legitimate, but most likely to cause practical problems  
with legacy software. The rest seem straightforward for authors, and mean  
in particular that using CSS or DOM/ECMAscript works exactly as one would  
expect.

I will suggest changes to the ARIA spec that would clarify this, so that  
the authoring becomes extremely simple, and so that processing for HTML,  
SVG, XHTML, and any other XML language becomes consistent. One more mail  
in this thread (directly replying to the original questions) and I will  
get to that task.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Thursday, 22 May 2008 06:29:36 UTC