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

On Thu, 22 May 2008 12:38:20 +0200, Robert J Burns <rob@robburns.com>  
wrote:


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

I don't think you want the same attribute to be in two different  
namespaces. That is what I am arguing against for ARIA. However, in a  
world where anyone can make an attribute and it might be useful, if two  
people chose the same name for their attribute that does different things  
then I definitely want a way to distinguish them, and namespaces provide  
that.

Let's look at the very concrete SVG case. There are two "fill" attributes,  
that mean very different things. One comes from SMIL, and one from SVG.

I can only speculate about whether the SVG group decided, a decade ago,  
not to have its attributes in a namespace, and to reduce namespace mixing  
as far as possible, or whether they were not clear on what the namespace  
spec (then in development) really meant. But they have the two different  
attributes, and the only way to tell them apart is by the element they are  
attached to.

Now suppose that I want to mix SVG in my swimmingPoolControlML (say, as a  
way of showing on the control panel what the pool is doing), and that it  
has an spcml:fill attribute. Being able to mix these with no *further*  
messiness seems useful to me. That's the point of namespaces - in XML,  
where there is an expectation that you can mix and re-use stuff from  
anywhere, you want a way to disambiguate things that come from authors who  
never had th chance to talk to each other.

There is a far more important case though, RDF - one of the first major  
users of the namespaces spec. There it is really really really important  
to be able to mix the namespaces of attributes.

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

I believe the implementors (and the spec writers themselves, a group with  
very significant overlap) *did* think about the issues, and decided that  
thy were doing the right thing. Since fundamentally it works, I think  
their decision wasn't incredibly bad. I don't think that changing that bit  
of history would have a material impact on ARIA or what it is trying to  
achieve, so I don't see a reason to try and do so.

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

No, this is incorrect. If we bring namespaces to HTML we still have the  
legacy issue of attributes in the null namespace. (Every attribute in HTML  
is in the null namespace. Every attribute in XHTML is in the null  
namespace. Try to shift them, and you create huge problems). Bringing  
non-null namespaces into HTML caused a few practical problems the first  
time we tried it in Opera - great swathes of pages stopped working,  
because authors hadn't figured it out at all.

We are now hoping to do something far more limited, and recognise a couple  
of namespaces in a couple of places, so we can properly delimit SVG and  
MathML content included in text/HTML. We believe that the problems that  
might produce are less than the benefits that it brings. ut in that case  
you will still have the null namespace being recognised, since SVG  
attributes are mostly in the null namespace.

However, I don't think this is relevant to ARIA. In order for ARIA to work  
in SVG, in HTML, and in XHTML, the attributes need to have the null  
namespace if any. In order for them to work in generic XML they need to  
have a namespace, and fortunately there is a null namespace that works.

> On May 22, 2008, at 7:41 AM, 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.

No they don't, because each attribute has exactly one namespace. If you  
want Xlink attributes in SVG, they have the xlink namespace. If you want  
aria attributes in FooML they have the null namespace. This is independent  
of the namespace of the element they are attributes of. Attributes do not  
inherit a namespace, they have to have one explicitly declared (otherwise  
it is null).

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

The ability to use attributes that are known and useful and happen to have  
been defined in the null namespace.

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

Except that leaving off prefixes *does* introduce a new namespace. It is  
hard to say, at this distance, what was "meant" to happen. I agree that  
what happens seems counter-intuitive. On the other hand, the more I have  
thought about it, the more it makes it easier to mix vocabularies in clear  
ways, and make the Web actually work as simply as possible (but no  
simpler).

Anyway, I fear general discussions of how namespaces ought to be are not  
material to the specific topic of how to make ARIA work best. I'll stop  
involving my self in such discussions now.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Thursday, 22 May 2008 12:09:57 UTC