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

Hi Boris,

On May 23, 2008, at 2:54 AM, Boris Zbarsky wrote:

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

I gave an example earlier, using Charles swimming pool example. I have  
very spotty internet access where I am, so I can't even get the email  
retrieved without major headaches. Your example of HTML and XHTML was  
not convincing however since you're saying that you made it work that  
way (where the NS method works in both for element but not for  
attribute) for compatibility despite the DOM recommendations.  
Obviously the same could be done for attribute as was done for  
element. I think we're simply talking past each other now, and I don't  
know how to break the log jam.


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

My extension of Charles swimming pool example should suffice.

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

Except for authors and authoring tools dealing with an attribute  
(e.g., myattribute) from a vocabulary (e.g., myvocabulary) where the  
attribute can be placed on foreign vocabulary elements. In that case  
we get something like:

<root-element
xmlns='schema://someuri'
xmlns:my='schema://myuri'
 >
<their-element my:myattribute />
<myelement myattribute>
</root-element>

Now myattribute from myvocabulary exists in two separate namespaces —  
even though it is from the same vocabulary in both cases and its  
semantics are the same in both cases. Again, this doesn't create  
headaches for a straight client-consuming UA, but for authors and for  
authoring tools its a needless complication. It almost completely  
undermines the convenience of omitting the prefix (if not entirely).  
So my point is that the implementors (and in the end the  
recommendation drafers) lost sight of what the recommendation was for.

The claim that it cannot be fixed is not accurate either. The claim  
derives from confusing prefix and namespace and from confusing the  
scoping of attributes with needing them to be in the null namespace.

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

I've been providing examples, but no one has said why those examples  
are insufficient.

Take care,
Rob

Received on Friday, 23 May 2008 09:17:05 UTC