Re: Meeting with SVG, XHTML, WAI people to move forward on ARIA as a cross cutting technology

Hi Henri,

On 19/10/2007, Henri Sivonen <hsivonen@iki.fi> wrote:
>
> On Oct 19, 2007, at 12:46, T.V Raman wrote:
>
> > I dont believe we need go down the ugliness of inventing a second
> > namespacing mechanism because some dont like the current one;
>
> I agree we shouldn't invent a second namespacing mechanism. I think
> we should do ARIA without a technical namespacing mechanism at all
> and only use a naming convention for spec organization without the
> parsing and DOM layers knowing anything about it.

I know this is controversial, but I'm not sure I agree. Or perhaps
'namespacing mechanism' is the the wrong phrase to use for what I
would like to see. Whatever it is, I would like to see something
'consistent' documented.

A good parallel example is in the world of XForms; there are new CSS
pseudo-classes and psuedo-elements that support some of the new
features of XForms. However, they have never been implemented in any
of the browsers. No surprise there, but the interesting thing is that
nearly all of the XForms processors out there use ordinary class
values to achieve the same purpose.

For example, we (i.e., formsPlayer) used to support .disabled and
.enabled in order to provide ::enabled and ::disabled. But then we
changed it to .pc-disabled, etc., so as to convey they idea that this
was a pseudo-class. Similarly, elements like xf:help acquired a class
of .xf-help, in order to make them easier to style.

Other implementers have done something similar, perhaps using a
slightly different naming convention.

As you can see, you quickly start to create 'namespaces' in the
ordinary, computer science sense of the term. Obviously no 'mechanism'
has been added here, but it certainly wouldn't hurt to have some short
document that indicates that 'xf-', 'pc-', 'aria-', and
'whateverelse-' are being created in order to solve the same problem.


> [snip]

> No actual technical doom or gloom in Web UAs will arise from putting
> the ARIA attributes in the per-element no-namespace partition of
> elements on the XML side. We know that XHTML and SVG don't have pre-
> existing attributes that start with "aria-", so there won't be actual
> collisions as far as Web languages are concerned. In theory, a non-
> Web language out there could collide with this scheme if you tried to
> use the "aria-" naming scheme on a theoretical non-Web language.
> However, since we are working on Web specs, I think we should
> optimized for actual Web language usage instead of theoretical non-
> Web language usage.

Right. But this is where I think we need to be thinking of a different
way of creating documentation. Take the @role documentation; all we
need to do there is document what it does, and the concepts it
represents, and perhaps give it some kind 'identifier', like:

  <http://www.w3.org/1999/xhtml/vocab#role>

It doesn't matter what the identifier is, but essentially we are
saying that there is a 'concept' of @role, that can be used in various
types of documents. The point is in the specification of @role, to not
get bogged down in how the attribute is used at a syntactic level.
Once the 'concept' is defined it could be used in *any* of the
following ways (and maybe others):

  <xyz role="r">...</xyz>

  <xyz xh:role="x">...</xyz>

  <xyz xh-role="x">...</xyz>

The first useages would be appropriate for a language that actually
modifies its schemas to 'include' the concept of @role. (It doesn't
matter how the schemas are defined--XML Schema, RELAX NG,
DTDs...whatever.) The latter two uses would be much more useful in
more 'dynamic' environments such as web-pages.

So to recap; you might not call this a new 'namespace mechanism', but
certainly some kind of consistent way at arriving at a self-contained
group of new CSS class names, style properties, attributes and
elements would be really useful when creating dynamic web
applications. (The validation question can be solved in various ways,
and is not really relevant to this.)


> (This is exactly where xml:id went wrong. The practical approach
> would have been declaring that the attribute id is always and ID and
> if someone out there had a non-Web problem with that, it would have
> been a non-Web problem. Now the fallout from xml:id is seen in Web
> specs and implementations.)

It is true--the difference between XML at a kind of 'infoset' level
and XML as a usable, coded language has never really been properly
made.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Friday, 19 October 2007 13:04:43 UTC