Re: direct link to latest version of S. Pieters' ARIA Proposal

Hi Doug,

We are actually about to release a new draft of the @role module, and
I would suggest that Simon could save himself some time and effort by
beginning with that. He could make known to the spec's authors
whatever use-cases he would like to see it support, that it currently
doesn't.

So that I can make some comments, I'll have a go at guessing what
features might be lacking, but obviously I'm hoping that there is some
feedback.

I would imagine that the first issue concerns the use of @role in
languages other than XHTML 1.x.  At the moment support is provided by
the XHTML Modularisation 1.1 framework, so any language that is built
on this can easily make use of the module. Chris Lilley said in
another discussion that M12N is only based on DTDs, but that isn't the
case, and XML Schemas are available. However, all of the M12N modules
are defined in such a way that we have the functionality and the
module declaration as two distinct parts. So there is no reason why
the module couldn't be expressed in some other schema language, for
example, RNG.

(Note that @role is not confined to XHTML 2.)

The second issue is probably to do with the values that the attribute
contains. These values are specified as CURIEs, as opposed to QNames,
and there are many reasons why this is the case--I won't go into them
here. One thing to point out though, is that CURIEs are a superset of
QNames, so they can be used safely in languages like SVG.

But one of the most significant changes that we made to CURIEs in the
last few weeks (in the course of our work on RDFa), was to define it
in non-XML terms. This was of course, the whole point of CURIEs in the
first place, but we've not made it so explicit before; doing so gives
us a lot more flexibility in how CURIEs can be used.

For example, CURIEs make use of a prefix which maps to a URI, but that
does *not* mean that the mechanism to provide that prefix has to be an
XML namespace. These mappings could be 'well known' mappings that are
provided by a host language (rather like Simon's 'wairole:' value), or
they could be provided by the author but by some other mechanism, such
as the one used in eRDF (which uses <link> and @rel).

Also, are now clearer on how the host language can decide what should
happen if no prefix is specified, with the most likely option being to
specify a default mapping.

This means that a host language could, for example, define its
CURIE-context settings in such a way that all of the following were
equivalent:

  role="wairole:checkbox"
  role=":checkbox"
  role="checkbox"

It doesn't take a great leap to see that a host language that:

 * provides no default prefix mappings;
 * provides no way to specify additional mappings;
 * and has just one, 'default' mapping

would essentially only support this syntax:

  role="checkbox"

But the key point is that this still remains a CURIE, and it therefore
means that we have consistency across specifications.

This restriction would obviously suit certain use-cases--and HTML 5
might be one of them--but the main point is that by using the core
@role spec to provide functionality in as wide a range of places as
possible, we ensure that the definitions and concepts remain in one
place, and so are easy to maintain, discuss, and of course improve on
in future versions.

So, a model for how Simon's ARIA document might specify the 'context'
for a more specific use of CURIEs is here:

  <http://www.w3.org/MarkUp/2007/ED-rdfa-syntax-20070927/#s_curies>

The forthcoming version of the @role document will be more inline with
this approach, and perhaps when that has been made available (next
week) we can discuss what tweaks are needed to allow it to be
incorporated into Simon's document.

(Note that I've said nothing about the states and properties section,
since that's nothing to do with the @role specification, as such; I'd
assume that won't be affected by any changes that might come about
from incorporating the @role document 'by reference'.)

Regards,

Mark

On 04/10/2007, Doug Schepers <schepers@w3.org> wrote:
>
> Hi, Folks-
>
> There's been talk on the public SVG list about adding the 'role'
> attribute to SVG [1], with follow-ups regarding the XHTML2 Role spec [2][3].
>
> The proposal seems to be for each language (HTML and SVG) to specify the
> 'role' attribute in their own namespace, and to reply on namespaces only
> for the ARIA attributes and taxonomy.
>
> According to Simon Pieters (on IRC), "the plan is to have the proposal
> implemented in firefox 3 and opera 9.5".  This is a pretty ambitious
> schedule... the code (and therefore the spec) would need to be done in
> days or weeks.
>
> That seems like it could be good for ARIA, but I don't want to rush to
> half-solve the problem in a way that would make later extension or
> functionality difficult.  I also don't want to ignore the research and
> hard work that went into the Role spec, particularly where it solves
> issues a simpler spec might not.  But if the spec (and subsequent
> implementations) that Simon and Aaron have put forward is a compatible
> subset of the Role spec, that would be a good first step.
>
> Please let us know what you think.
>
> [1] http://lists.w3.org/Archives/Public/www-svg/2007Oct/0012.html
> [2] http://lists.w3.org/Archives/Public/www-svg/2007Oct/0021.html
> [3] http://lists.w3.org/Archives/Public/www-svg/2007Oct/0023.html
>
> Regards-
> -Doug Schepers
> W3C Staff Contact, SVG, CDF, and WebAPI
>
>


-- 
  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, 5 October 2007 00:00:14 UTC