Re: @role in SVG

Doug,

Personally, I vote for Option 1 - in which case nothing need change in
any specification.  We're already using multiple namespaces in
non-trivial SVG documents (xlink for one, events for another in SVGT
1.2).

But I don't understand what "Rec-Track exit criteria" means, so if you
could clarify that it would be great.

Thanks,
Jeff

On 10/9/07, Doug Schepers <schepers@w3.org> wrote:
>
> Hi, SVG community-
>
> The SVG WG likes the functionality and extensibility that the 'role
> attribute affords, and the potential for increased accessibility, so we
> do want to include it in SVG (and to see it implemented as soon as
> possible, so authors can use it right away).  We've talked about how
> best to do so, and we'd like to solicit opinions from interested
> parties, including the other Working Groups involved, implementors, and
> authors.
>
> To summarize the options, we can include the 'role' attribute in the
> XHTML namespace, or as a native null-namespace attribute.  Each approach
> has benefits and problems.
>
> 1) XHTML Namespace
> <svg
>    xmlns="http://www.w3.org/2000/svg"
>    xmlns:xlink="http://www.w3.org/1999/xlink"
>    xmlns:xhtml="http://www.w3.org/1999/xhtml"
>    xmlns:aaa="http://www.w3.org/2005/07/aaa">
>    <g xhtml:role="checkbox" aaa:checked="true">...</g>
> </svg>
>
> Pros:
> * does not require any changes to SVG syntax... automatically available
> via XML's innate extensibility mechanism
> * conforms to current version of the Role spec [1]
>
> Cons:
> * is slightly harder to author (requires working knowledge of
> namespaces, or good voodoo skills)
> * differs in syntax from how it would work in XHTML and HTML5 (so may be
> harder to learn, and possibly to implement)
> * more verbose
>
>
> 2) Native Non-Namespaced Attribute
> <svg
>    xmlns="http://www.w3.org/2000/svg"
>    xmlns:xlink="http://www.w3.org/1999/xlink"
>    xmlns:aaa="http://www.w3.org/2005/07/aaa">
>    <g role="checkbox" aaa:checked="true">...</g>
> </svg>
>
>
> Pros:
> * more similar in syntax to XHTML and HTML5 (easier to use and maybe
> implement)
> * less verbose
> * maybe less error-prone for authoring, mash-ups, compound documents
>
> Cons:
> * would require a change to SVG (see details below)
> * would require change to Role spec to allow "host language" (SVG) to
> incorporate it into its own language (note that there is precedent for
> this in the previous version of the Role spec [2], not sure why it was
> changed)
>
> Neutral:
> * still requires knowledge of namespaces, but only for including ARIA
>
>
> Changes Required to SVG Specifications
>
> As mentioned, including 'role' via the XHTML namespace requires no
> changes to SVG (though would benefit from a Note on the details), but I
> understand that some might not find it the cleanest or most
> author-friendly solution.  So, the SVG WG is open to include it directly
> in the SVG language, if that's the solution the community feels is best
> (and if it is allowed by the Role spec).
>
> If we are to include it in the language, just how we do so depends on
> which version of SVG.  We can't add it as a feature to SVG 1.1 or before
> (adding features that change conformance to a past version is not
> allowed in the W3C Process), but we could do so for SVG 1.2 Full with
> few or no problems.  There is a chance we could do it for SVG 1.2 Tiny,
> because it's not yet in PR, but adding features at this late stage might
> not sit well with the standards community (though the implementors on
> the WG assure us that merely adding an attribute is trivial).  We would
> like to do it, but not if it's seen as unacceptable by the standards
> community.
>
> Another factor is that we don't want to be dependent upon the Role
> Attribute  and the CURIE specs for our Rec-Track exit criteria.  But
> neither do we want to specify it separately (or differently) than that
> spec.  A possible solution is that, for SVG 1.2 Tiny, we would include
> it as an attribute whose value is a space-separated list of strings, and
> when the Role and CURIE specs are more mature, in the SVG 1.2 Full
> timeframe, we would change the specification of 'role' to refer to those
> specs.  This is not a very clean solution, but it would get the 'role'
> attribute out there, and let authors create content now in as easy a
> manner as possible.
>
>
> Changes Required to Role Attribute Specification
>
> As mentioned before, for this to happen, the Role Attribute spec would
> need to explicitly allow SVG to do it.  We'd like feedback from the
> XHTML2 WG on this.  It would be ideal, perhaps, if the Role spec
> optionally allowed the values to be strings instead of CURIEs (as
> specified in a host language), but that may be a bridge too far.
>
>
> Prompt feedback on this issue would be greatly appreciated.
>
>
> [1] http://www.w3.org/TR/xhtml-role/
> [2] http://www.w3.org/TR/2006/WD-xhtml-role-20060725/#docconf
>
> Regards-
> -Doug Schepers
> W3C Staff Contact, SVG, CDF, and WebAPI
>
>
>
>

Received on Wednesday, 10 October 2007 10:46:25 UTC