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

On May 22, 2008, at 10:26 AM, Robert J Burns wrote:

> 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:37:24 UTC