Re: Next steps for the ARIA syntax discussion

Hi Charles,

> Saying that the attributes in HTML are in the null namespace does not
> anticipate anything that some future spec might say, nor does it conflict
> with any current draft I know of, with regard to XML - it is in fact
> perfectly in line with the specs and implementations that have emerged in
> the 10 years of XML.
>
> It *also* simplifies the process of building applications, and the process
> of explaining how to add aria to a new XML or non-XML spec.
>
> These two reasons are why I believe the PFWG will adopt the solution I
> suggested above as its preferred model for both HTML and XML languages.

You've made a leap again. :) I think this is what Robert is getting at.

To say that you don't want to use an XML technique (namespaces) in
HTML is one thing, but to then have some kind of reverse feedback loop
where you say that this is therefore the preferred technique for XML
(i.e., to not use XML namespaces) is dubious.

In particular, the foundation for ARIA is the @role attribute module,
which was created precisely for solutions like ARIA, to be used in
XML-based languages. So dropping namespaces completely from ARIA is
not a good idea. (I get a sense that people think that @role was
sitting around doing nothing until some clever soul thought of using
it for ARIA--quite the contrary...it was designed first and foremost
as an accessibility hook.)

That's not to say that XML namespaces need to be taken 'as is'. I do
agree that they are a bit of a mess, but I think that this is mainly
because everyone is posturing on the subject; the W3C is defensive
about the technology, not seeming to want to admit any flaws, whilst
those who don't like it simply rubbish it without any real reference
to the problems that it tries to solve.

But there are many different ways that namespaces could evolve for the
21st century...if we have the will to sort them out.

The first thing I would do is prise apart the syntax and the infoset.
I don't see any reason why the underlying representation of a DOM
can't be taken as given, even if we fiddle around to remove the need
for prefix-explosion in the mark-up.

The second thing I'd do is make XHTML a special case; there is no
reason why XHTML as an XML-based language needs to have all of the
features, power and flexibility that 'generic XML' has. For example,
why do we care if 'xf:' is hard-coded to always refer to the XForms
namespace? Likewise, what's the big deal if 'aria:' always points to
the same namespace, too?

In fact, I wouldn't lose any sleep if we said that:

  <span @aria-banana="foo">

is a shorthand for:

  <span @aria:banana="foo" xmlns:aria="http://...">

I'm not particularly wedded to that approach either...I'm just trying
to stress that if we have the will to solve the problem, then we can
look for solutions that both maintain compatibility with the
architecture (e.g., by defining things in terms of the infoset), but
still create better and easier to use solutions for the future.

An example of this is in the latest CURIEs draft [1]; myself and Shane
added a small and probably unnoticed feature that permits host
languages that want to make use of CURIEs, to define their own values.
These strings must still 'map' to full URIs (since CURIEs are
generally used to carry RDF information), but the effect is to allow a
language to remove the need for namespaced prefixes, whilst still
being a 'good citizen' in the namespace world.

This was needed in RDFa to allow legacy mark-up like @rel="next" to
work correctly, without requiring @rel="xh:next". But it's also the
mechanism that allows @role="widget" to be defined, too. In other
words, a language can make use of a large part of @role functionality
without requiring namespace-prefixed values, simply because it uses
CURIEs.


In short, XML is very powerful, and very flexible, but it seems to me
that we could hide a lot of its complexity if we stopped polarising
the discussion. XHTML needs a lot of this power, but not all of it,
and recognising that might help us to unlock this seemingly
intractable problem.

Regards,

Mark

[1] <http://www.w3.org/TR/curie/>

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Wednesday, 4 June 2008 10:21:13 UTC