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

On Fri, 05 Oct 2007 01:59:59 +0200, Mark Birbeck <mark.birbeck@x-port.net>  
wrote:

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

The reasons why I started writing this spec are threefold:

   1. I wanted to write test cases for ARIA but couldn't because the specs
      didn't have sufficient conformance criteria for UAs:

         http://lists.w3.org/Archives/Public/public-pfwg-comments/2007JulSep/0000.html

   2. What was implemented in Firefox 2 didn't seem to match the
      specifications and there was content that relied on it (in particular
      the role attribute in the http://www.w3.org/TR/xhtml2 [sic]
      namespace, which isn't defined anywhere).

   3. The proposal of simplifying the ARIA syntax had to be specced
      somewhere in order to get interoperable implementations.


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

If SVG wants to support role, it seems that there are two options:

   1. Use the role attribute in no namespace on SVG elements.

   2. Use the role attribute in the http://www.w3.org/1999/xhtml
      namespace on SVG elements.

The proposal previously defined the latter and now instead defines the  
former.


> (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,

I've updated the spec to allow CURIEs instead of prefixed names.


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

Is the new text ok?


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

-- 
Simon Pieters
Opera Software

Received on Saturday, 6 October 2007 15:54:35 UTC