Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This note outlines the way in which the XHTML 2 Working Group has addressed comments received during the last call period against the second Last Call Working Draft of XHTML Role.
During the second last call period for XHTML Role the working group received a few comments. This document summarizes those comments and describes the ways in which the comments were addressed by the XHTML 2 Working Group.
Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the XHTML 2 Working Group elected to not change these submissions.
This document is a Note of the W3C's XHTML 2 Working Group. This Note may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Notes as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.
This document has been produced by the W3C XHTML 2 Working Group as part of the HTML Activity. The goals of the XHTML 2 Working Group are discussed in the XHTML 2 Working Group charter.
This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
| Issue | Working Group Action | Commentor Position | Change Type | Notes |
|---|---|---|---|---|
| 8038: [XHTML Role] SVG WG LC comments | Modify and Accept | None | Editorial | Sent reply and implemented change to remove vocab items from document. |
| 8041: [role module] is 'must take Curie values' a problem for WAI-ARIA embedding in HTML? | Modify and Accept | None | None | The working group recognizes that the dependency on CURIEs is a risk, but is aggressively progressing the CURIE specification and is confident that it will become a Recommendation in short order. As to what the ARIA spec should require with regard to processing role values that are CURIES (other than the pre-defined reserved values), we make no recommendation. It is entirely up to you. You could dereference the associated URI and attempt to determine the semantics by examining the RDF at the other end, for example. RichS has proposed such a thing in the past. |
PROBLEM ID: 8038
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
Sent reply and implemented change to remove vocab items from document.
ORIGINAL MESSAGE:
Date: Fri, 09 May 2008 17:24:35 +0200 From: =?iso-8859-15?Q?Erik_Dahlstr=F6m?= <ed@opera.com> Hello, The SVG WG has reviewed the XHTML Role attribute module, W3C Working Draft 7 April 2008, http://www.w3.org/TR/xhtml-role/. General comments ---------------- It's nice to see an extensible solution that allows other languages to add additional roles using the CURIE syntax. The SVG WG looks forward to working with WAI PF to define roles suitable for common types of graphics such as maps, charts, etc. It's is a pity that no RelaxNG schema is provided. Please consider adding one. Whereas XHTML typically has elements to markup text, the text elements in SVG provide no idea about their semantical meaning. Therefore it could be quite useful to have some role values for 'paragraph', 'section', etc. This is especially useful for the interpretation of documents, if there is no visual rendering available due to the capabilities either of the user or the user-agent and improves accessibility of non (X)HTML markup languages. Such attributes might help to align prose text in SVG in a better understandable way in such an additional text view. For poetry (see discussion for HTML5) in contrast to (X)HTML it is typically simple to cover the functionalities of poetry structures with or without specific requirements for graphical rendering with SVG, but for both (X)HTML and SVG there is no idea of the semantical meaning of the elements used to markup poetry (for example 'strophe', '(strophe)line'). To provide any useful functionality with role, it is important to have a larger list of predefined values either in the role specification itself or in the SVG recommendation it will be used for, else it will not be very reliable that the values of role have a meaning at all, if every group or any author has to create his own extension, it would be a big advantage to collect at least the text related things (see above) or even better the already known applications directly in the primary list: http://www.w3.org/1999/xhtml/vocab/#XHTMLRoleModule 3. The XHTML Role Attribute --------------------------- > The following list represents some of the roles defined in the default > vocabulary. They are intended to define regions of the document to help > orient the user. Either make it a complete list, or mark the section as informative. Regards /Erik, on behalf of the SVG WG -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com>
Date: Wed May 21 15:36:30 2008
Ed,
We have embedded responses to your issues below. Please confirm whether these
responses resolve your issues or not.
ed@opera.com wrote:
> Hello,
>
> The SVG WG has reviewed the XHTML Role attribute module, W3C Working Draft
> 7 April 2008, http://www.w3.org/TR/xhtml-role/.
>
> General comments
> ----------------
> It's nice to see an extensible solution that allows other languages to add
> additional roles using the CURIE syntax. The SVG WG looks forward to working
> with WAI PF to define roles suitable for common types of graphics such as
maps,
> charts, etc.
>
The XHTML 2 Working Group has relegated most of the role definition work for the
XHTML Vocabulary Space to the WAI PF. So yes, we encourage you to work with
them to define cohesive vocabulary items either for your own private space or in
the XHTML space, as appropriate. In general, we encourage all groups to define
their own vocabularies. More on this below.
> It's is a pity that no RelaxNG schema is provided. Please consider adding
one.
>
We do not yet have a RelaxNG modularization methodology. When we do, you can be
confident that each XHTML module will get such an implementation. It is
notionally on our list as part of XHTML 2 development.
> Whereas XHTML typically has elements to markup text, the text elements in
SVG
> provide no idea about their semantical meaning. Therefore it could be quite
> useful to have some role values for 'paragraph', 'section', etc. This is
> especially useful for the interpretation of documents, if there is no visual
> rendering available due to the capabilities either of the user or the
> user-agent and improves accessibility of non (X)HTML markup languages. Such
> attributes might help to align prose text in SVG in a better understandable
> way in such an additional text view.
>
We agree that there may be collections of SVG data to which people will want to
assign semantics via the role attribute. To the extend that these are
generalized concepts, you should feel free to reply upon the default collection
of roles in the XHTML vocabulary. Beyond that, we encourage you (and all
groups) to define your own vocabulary using the W3C's ontology building blocks
and make that vocabulary available to your user community. After all, that is
the whole point of the extension mechanism.
> For poetry (see discussion for HTML5) in contrast to (X)HTML
> it is typically simple to cover the functionalities of poetry structures
> with or without specific requirements for graphical rendering with SVG,
> but for both (X)HTML and SVG there is no idea of the semantical
> meaning of the elements used to markup poetry (for
> example 'strophe', '(strophe)line').
>
> To provide any useful functionality with role, it is important to
> have a larger list of predefined values either in the role
> specification itself or in the SVG recommendation it will be used for,
> else it will not be very reliable that the values of role have a meaning
> at all, if every group or any author has to create his own extension,
> it would be a big advantage to collect at least the text related things
> (see above) or even better the already known applications directly in
> the primary list:
> http://www.w3.org/1999/xhtml/vocab/#XHTMLRoleModule
>
See above. We encourage you to coordinate with the WAI PF group on roles that
you consider of general use. Beyond that, please define an SVG-specific
vocabulary. Its the best way to ensure that you control its evolution and that
it gets developed and updated at a pace that your group is comfortable with.
> 3. The XHTML Role Attribute
> ---------------------------
>
>> The following list represents some of the roles defined in the default
vocabulary. They are intended to define regions of the document to help orient
the user.
>>
>
> Either make it a complete list, or mark the section as informative.
>
We plan to remove the example entries from the Role document entirely. We will
include some informative examples and a reference to the XHTMLVOCAB document as
the place where the current list can be found.
Thanks very much for your comments!
PROBLEM ID: 8041
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
The working group recognizes that the dependency on CURIEs is a risk, but is aggressively progressing the CURIE specification and is confident that it will become a Recommendation in short order. As to what the ARIA spec should require with regard to processing role values that are CURIES (other than the pre-defined reserved values), we make no recommendation. It is entirely up to you. You could dereference the associated URI and attempt to determine the semantics by examining the RDF at the other end, for example. RichS has proposed such a thing in the past.
ORIGINAL MESSAGE:
From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Thu, 5 Jun 2008 21:12:24 -0400
[re-send. Originally mis-posted as
http://lists.w3.org/Archives/Public/www-html/2008Jun/0003.html
-Al ]
Re: http://www.w3.org/TR/2008/WD-xhtml-role-20080407/
This is a personal comment. It is a concern about a possible problem,
not the assertion of a sure problem.
WAI-ARIA has a dependency on the role attribute module, or at least
has a dependency on the host language affording a suitable @role
attribute
for which our roles are attribute values.
The Role Attribute module has been relaxed to allow a variety of ways
that the @role attribute is introduced into a host language or document.
But it appears to require that in any host language the
implementation of this
attribute takes as its value
<quote
cite="http://www.w3.org/TR/2008/WD-xhtml-role-20080407/
#s_role_module_attributes">
one or more whitespace separated CURIEs
</quote>
[CURIE] http://www.w3.org/TR/2008/WD-xhtml-role-20080407/#ref_CURIE
Curies are new and progressing down the Rec track behind the Role
Attribute
Module. This would seem to be in reverse of the dependency-induced
order
as the Role Attribute has a dependency in this way on Curies.
In addition, because of the way that WAI-ARIA roles adjust element
semantics,
role values carry a connotation of language extension; and Curies
expand to
URIs which could indicate totally uncoordinated, crowd-sourced
distributed
language extension.
The latter could be regarded as undesirable for the maintenance of
HTML, the
central format of the One Web.
I am unclear how much saying that @role is a list of Curies means
that the
processor must process in accordance with the URIs that the Curies
abbreviate.
It would seem to me that WAI-ARIA needs host languages to respect the
@role values
set out in the http://www.w3.org/1999/xhtml/vocab# vocabulary when
these values
appear un-prefixed as tokens (items in the space-separated list) in
the @role value.
What WAI-ARIA may need in terms of support for role extension is not
known at this
time. We have a working decision that role extension will not be
addressed in
WAI-ARIA 1.0.
In that sense, ARIA has a dependency on @role but does not need @role
to have
the dependency on Curies. And there is a chance that cross-host-
language support
for @role could be impeded by the dependency on curies.
That's my nervousness. We will be talking about this more as we work
to tighten up
the WAI-ARIA specification as it deals with host language insertion.
But I
was told to put it on record as a Last Call comment for the Role
Attribute Module
because it touches that specification which is already s/in/past it's
second
Last Call.
Thanks,
Al
/me
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Tue Jun 17 13:03:40 2008 Al, The working group recognizes that the dependency on CURIEs is a risk, but is aggressively progressing the CURIE specification and is confident that it will become a Recommendation in short order. As to what the ARIA spec should require with regard to processing role values that are CURIES (other than the pre-defined reserved values), we make no recommendation. It is entirely up to you. You could dereference the associated URI and attempt to determine the semantics by examining the RDF at the other end, for example. RichS has proposed such a thing in the past.