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

HI Charles and Aaron,

On May 22, 2008, at 6:28 AM, Charles McCathieNevile wrote:
>>
>> 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.

Yes, I understand. However, the problem is we need to read the  
recommendation and understand why the recommendation exists in the  
first place. The point is to combine disparate vocabularies into a  
single document. I cannot think why an author would want the same  
attributes (in terms of vocabulary) to appear in two different  
namespaces within the same document. Yet that's where your  
interpretation leads us. To use your example of a  
SwimmingPoolControlML vocabulary, the "fill" attribute on the MyPoo  
element will be in the null namespace, while the "spcml:fill"  
attribute on the DIV element will be in the http://SwimmingPoolControlML.com/ 
  (to coin the uri) namespace.  From the authors perspective, these  
are the exact same attributes. However, the work for the author is now  
doubled because they appear in two different namespaces. Sure, authors  
learn to cope with this error (both in the spec and in the reading and  
implementation of the spec), but they shouldn't have to. I've asked  
this in other fora before, but I have never heard anyone explain the  
necessity for a null namespace.

Again the problem here is a narrow and often rote reading of a  
recommendation without considering how it will effect authors and  
users. Rather than simply trying to make sense of the text by  
disregarding its purpose, it would have been far better for the  
implementors to report the discrepancy to the recommendation authors  
and find out how they thought a null namespace might be used (if  
that's what they even had in mind).

Charles McCathieNevile wrote:
> 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.

Those are some good examples. My concern is when attributes (unlike  
aria) can belong to elements in their own namespace. This is where the  
headaches for authoring arise. I would really like to see us bring  
namespaces to the text/html serialization. However, I would rather not  
repeat the mistake of the null namespace in doing so. Once a document  
uses namespaces, I see no reason that everything in the document  
shouldn't be in one or another namespace. While this would create a  
minor inconsistency with XML namespaces it is an inconsistency that  
would be welcomed by authors because their doubled effort in XML would  
still work in text/html and for the attribute only vocabularies (like  
aria), the document could easily be converted either way (between XML  
and text/html.

On May 22, 2008, at 7:41 AM, Julian Reschke wrote:

> For the record: I don't think there's any agreement in the XML  
> community that there is something wrong with respect to what  
> namespace non-prefixed attributes live in.
>
> It was one of several possible choices, and I haven't seen any  
> evidence it's harmful. People learn how it works and that's it.
>
> Introducing something that looks similar but behaves differently  
> probably would make things worse, not better.

Could you give an example of how it would make things worse?

Julian Reschke wrote:
> How is it a "major headache"? And how exactly would it help authors  
> if the behavior would differ in different serializations?

Again, the problem arises where elements exist both on elements from  
foreign vocabularies and on elements from their own vocabulary. In  
this case authors of compound documents end up with attributes from  
the same vocabulary in two different namespaces. This may seem like a  
minor issue, except I can't imagine why anyone would want that to  
happen or what could possibly be gained by having a null namespace in  
a compound document?

Again this may be because my understanding of namespaces is different  
than yours. I see them as a way to mix vocabularies (nearly synonymous  
in this sense). So I feel the mapping in a compound document should be  
one-to-one between namespace and vocabulary. The issue of leaving off  
prefixes — from this reading — is merely a convenience for authors and  
not meant to introduce an entirely new namespace in the document (in  
other words the null namespace).

Take care,
Rob

Received on Thursday, 22 May 2008 10:39:06 UTC