Re: Next steps for the ARIA syntax discussion

Al Gilman wrote:

> WAI-ARIA could have ridden on namespaces, and *would have* if
> namespaces were ready for prime time.  But they're not.
> 

OK. Seems you are rejecting namespaces in toto because you don't like 
them. I'm not sure you're wrong about that. Namespaces are a poorly 
thought out mess. However they do work in practice, and the biggest 
problems today seem to come about when people either don't support them 
(e.g. Java's SAXParser) or assume they work in ways other than they 
actually do (DOM). That the W3C has made some pointless, backwards 
incompatible changes to namespaces without properly marking those 
changes doesn't help either.

You should be aware that if namespaces are not ready for primetime now, 
they never will be. There is *NO* effort whatsoever to improve the 
situation for namespaces in any significant way. The syntax will not 
change in XML's lifetime. There is no improvement on the horizon that 
would satisfy you.

The decision, therefore, comes down to this: how much does following the 
web architecture matter? Are the benefits of using namespaces more than 
the very real costs they impose on ARIA users and others? It might be 
time to start tallying up the costs and benefits of this proposal.

Off the top of my head the benefits are primarily in user interface. 
It's easier for authors and developers to handle aria- than aria:.

On the other side, there is also a negative user interface effect of 
using aria- for developers. Developers consistently misidentify the 
namespace of unprefixed attributes. If you go with aria-, I can promise 
you that there will be bugs when developers assume aria- is in the 
namespace of the parent element or the default namespace. On the other 
hand, if you go with aria: there will still be bugs caused by developer 
confusion, just different ones.

So for developers, it's probably a wash. The real benefit is to people 
hand-authoring documents that use ARIA. Since you want to put these 
attributes in HTML, there are a significant number of people who will do 
this. aria- makes their jobs somewhat easier.

The costs to aria- are primarily in lost support by various tools. The 
primary such tool are schemas. aria: is much easier to integrate in than 
aria- because you can write separate schemas for separate namespaces.

You also lose support in XQuery, XSLT 2, and XPath 2. In these 
increasingly important languages, it is relatively easy to dispatch or 
search based on the namespace of an attribute or element, and relatively 
hard to dispatch or search based on the first part of a local name. it's 
not impossible, mind you, but it is more complex.

There's also a cost on authors who don't want to use ARIA. They can no 
longer user aria- to name their attributes. Probably a small cost, but a 
cost nonetheless. The Web allows you to reserve URIs for your choice of 
use, but not names. There is no guarantee that any aria- names will be 
unique, nor will you ever be given such a guarantee. The chance of 
collision is small, but non-zero. If there is a collision, it's your 
problem.

Are there any costs or benefits I'm missing here?

-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Received on Friday, 30 May 2008 14:01:05 UTC