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

On May 28, 2008, at 12:44 PM, Steven Pemberton wrote:

> On Thu, 22 May 2008 14:08:36 +0200, Charles McCathieNevile <chaals@opera.com 
> > wrote:
>
>> I can only speculate about whether the SVG group decided, a decade  
>> ago, not to have its attributes in a namespace, and to reduce  
>> namespace mixing as far as possible, or whether they were not clear  
>> on what the namespace spec (then in development) really meant. But  
>> they have the two different attributes, and the only way to tell  
>> them apart is by the element they are attached to.
>
> But that is how XML (and SGML) works! There is no requirement that  
> the same named attributes on different elements do the same thing.
>
> To take HTML4, look at
> 	<meta name="..."
> 	<a name="..."
> 	<param name="..."
> 	<button name="..."
> (and several others). These are all different name attributes. They  
> do different things. You use the element to identify which is which.
>
> Namespaces are about identification, and that is the reason for the  
> frequently misunderstood sentence in the namespaces spec "The  
> namespace name for an unprefixed attribute name always has no  
> value." This doesn't mean that the attribute is in the null  
> namespace; it means "you are asking the wrong question when you ask  
> which namespace an unprefixed attribute is in", because you don't  
> identify unprefixed attributes from the namespace, but from the  
> element it is on.

Well, I think that sentence and the issues surrounding it should be  
fixed in an updated spec. I agree with you partially here, but not  
entirely, though I cannot tell. I would say the spec intended to scope  
attributes to the parent element’s namespace. We all agree that the  
attribute’s parent element defines the vocabulary for the attribute,  
but I think the failure to maintain a one-to-one correspondence  
between vocabulary and namespace in the spec is what leads to all this  
confusion.

> On the other hand, a prefixed attribute is a *completely different*  
> attribute from an unprefixed one. This is why the following  
> (frequently not-understood) example from the namespaces spec is OK:
>
> 	<x xmlns:n1="http://www.w3.org"
> 	   xmlns="http://www.w3.org" >
> 	  <good a="1"     b="2" />
> 	  <good a="1"     n1:a="2" />
> 	</x>
>
> a and n1:a are two *different* attributes, and it is up to the n1  
> spec to say what n1:a means. They must be different, because the XML  
> spec doesn't allow duplication of attributes on an element.

This example should also be exorcised from the spec. The namespaces  
spec facilitates the placement of two of the same attributes from the  
same vocabulary on the same element and that cannot be good. It has  
provided a loophole aroudn the XML spec prohibiting duplication of  
attributes on an element that should be fixed by updating the spec and  
should definitely be avoided by vocabulary spec writers and vocabulary  
authors. Again, if we maintain a one-to-one correspondence between  
vocabulary and namespace and treat unprefixed attributes as scoped to  
their parent element’s namespace such a loophole would be closed.



> Everyone might reasonably be expected to understand what
>
> 	<my:foo html:href="bar"/>
>
> is mean to convey, but there is no guessing what
>
> 	<my:foo html:name="a"/>
>
> should mean. But in either case, some specification has to say what  
> they mean when used like this.
>
> So to summarise, SVG was perfectly in order using the same attribute  
> name on different elements like this.


I agree. It's is not SVG that is the problem, but the XML namespaces  
recommendation that is broken (and could be fixed in a backwards  
compatible and forward looking way).

Take care,
Rob

Received on Wednesday, 28 May 2008 13:04:15 UTC