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

Robert J Burns wrote:
> 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

Maybe I'm missing something.  Can you give an actual XML example here to 
illustrate what you're talking about?

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

Again, example?

> It is completely counter to the purpose of the namespaces recommendation — 
> which in my view is intended to allow authors to easily mix 
> vocabularies.

The mixing thing works last I checked... if you use attributes designed 
to be used on arbitrary elements, those are always namespaced (e.g. 
xml:id).  If you use attributes that are only designed to work on some 
elements, they are not namespaced, but the element is, and the logic for 
handling the attribute needs to live in the element.

> In some cases it prevents authors from being able to take 
> advantage of the convenience of omitting the prefix.

While true, the fact that most attributes that authors use are in fact 
not namespaced right now means that this only applies to a minority of 
attributes.  I have to admit that I've not seen any markup where the 
elements _and_ the attributes had to be in the same namespace recently. 
  I suppose you could default the xlink namespace in something like SVG 
and then stick prefixes on all the elements, but this seems like a 
bigger inconvenience.  Again, maybe there's an example that illustrates 
the problem clearly?

-Boris

Received on Friday, 23 May 2008 03:07:10 UTC