W3C home > Mailing lists > Public > public-xhtml2@w3.org > May 2008

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

From: Steven Pemberton <steven.pemberton@cwi.nl>
Date: Wed, 28 May 2008 15:38:50 +0200
To: "Robert J Burns" <rob@robburns.com>
Cc: "Charles McCathieNevile" <chaals@opera.com>, "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: <op.ubu9i003smjzpq@acer3010>

On Wed, 28 May 2008 14:59:27 +0200, Robert J Burns <rob@robburns.com>  
wrote:

>> 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.

I think that they thought that they didn't have any control over that. It  
was already true. But I agree that the namespace spec is particularly hard  
to understand. In fact I only understood it by first reading the appendix  
on Namespace Structure in the first edition (which they expunged in the  
second edition).
http://www.w3.org/TR/1999/REC-xml-names-19990114/#Philosophy

> 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.

I personally disagree. As I said, the namespace spec is only about  
identification, and you don't need a namespace to identify an unprefixed  
attribute, just an element.

>> 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.

You misunderstand. They are saying that the two attributes can be uniquely  
identified, so all is well. Whether a markup language should allow it or  
not is up to that language. Remember that a and n1:a are two different  
attributes, one in the Global Attribute partition and one in the  
Per-element-type partition, using the language of the appendix I was  
talking about.

> 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.

That may be true, but I disagree that it is a loophole. They are different  
attributes.

> 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.

I believe that that is what the namespace spec already says.

Best wishes,

Steven
Received on Wednesday, 28 May 2008 13:41:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:48 GMT