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.