This note outlines the way in which the XHTML 2 Working Group has addressed comments received during the second last call period against the Last Call Working Draft of the XHTML Role Attribute Module.
During the second last call period for the XHTML Role Attribute module 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 email@example.com. 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 firstname.lastname@example.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.|
|8049: XML CG comments on XHTML Role Attribute Module last-call draft of 7 April 2008||Modify and Accept||None||Editorial||Implemented some editorial changes to help clarify some issues. Responded in detail in http://lists.w3.org/Archives/Public/www-html-editor/2008OctDec/0000.html.|
PROBLEM ID: 8038
STATE: Approved and Implemented
RESOLUTION: Modify and Accept
USER POSITION: None
Sent reply and implemented change to remove vocab items from document.
Date: Fri, 09 May 2008 17:24:35 +0200 From: =?iso-8859-15?Q?Erik_Dahlstr=F6m?= <email@example.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
From: Shane McCarron <firstname.lastname@example.org> 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. email@example.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
RESOLUTION: Modify and Accept
USER POSITION: 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.
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
From: Shane McCarron <firstname.lastname@example.org> 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.
PROBLEM ID: 8049
STATE: Approved and Implemented
RESOLUTION: Modify and Accept
USER POSITION: None
Implemented some editorial changes to help clarify some issues. Responded in detail in http://lists.w3.org/Archives/Public/www-html-editor/2008OctDec/0000.html.
From: "C. M. Sperberg-McQueen" <email@example.com> Date: Mon, 4 Aug 2008 15:16:24 -0600 Dear colleagues: The XML Coordination Group has reviewed the Last-Call draft of "XHTML Role Attribute Module A module to support role classification of elements" (http://www.w3.org/TR/2008/WD-xhtml-role-20080407/) and congratulates the XHTML Working Group on its work. We realize that the Last-Call comment period has expired, but we notice that the document has not yet been republished and we venture to hope these comments may be useful in any case. We believe the role attribute module described in this spec is for the most part described clearly and well. We have a number of more specific comments, which are given below. Comments (1) through (3) below are generic technical comments on areas where the XML Coordination Group and the Working Groups represented on it have no special responsibility or authority; they are intended to call your attention, as one technical colleague to another, to points you should probably consider in revising the document. If upon consideration, you find you disagree with us on them, then we expect to defer to your judgement (even if we privately disagree). Comments (4) through (9), on the other hand, relate to areas where the Working Groups of the XML Activity have particular responsibility and competence. If upon consideration you find you disagree with us on them, then we have a cross-domain coordination issue that requires attention. (For the record it should be noted that the XML Coordination Group reviewed a draft of these comments and gave instructions for revisions. The CG has not reviewed the revised form of these comments and will surely disavow any errors I have introduced during the revision.) (1) First, we congratulate the XHTML Working Group for providing a useful and clear namespace document for the namespace http://www.w3.org/1999/xhtml/vocab/ We wish more groups responsible for namespace did so well by the users of their namespaces. (2) That said, we think the namespace document could be improved by the addition of some more information. A document date would be helpful, and the identity of those responsible for the text of the document, and for the namespace, could be stated more explicitly. (From the fact that "The XHTML specifications are developed by the W3C XHTML 2 Working Group as part of the W3C HTML Activity", it may be thought to follow that it is the XHTML 2 Working Group which is responsible both for the namespace document and for the namespace. But at least this reader thought it might usefully be clearer; there are cases where more than one group is involved.) It might also be desirable to provide hyperlinks from the namespace document into the main documentation for the XHTML vocabulary (possibly in multiple versions). (3) The namespace document also needs a reference to a namespace change policy. At least, that is our reading of the following passage from the document "URIs for W3C Namespaces" (13 July 1005, rev. 25 April 2006) at http://www.w3.org/2005/07/13-nsuri : The TAG finding titled The Disposition of Names in an XML Namespace explains how the use of a particular namespace may evolve over time. At the W3C, it is important for a group to state clearly its expectations for how use of the namespaces it controls will or will not change over time. Groups SHOULD document those expectations in [or clearly linked from] the Namespace Document. (4) Our first concern is with the spec's reliance on CURIEs, which are not as well defined and not as well integrated with other XML technologies as one might wish. That is perhaps a comment better raised against CURIEs themselves than against this specification. It suffices here to notice that if the role attribute were defined as a list of QNames, existing XSD-based technology would provide convenient access to the namespace names of the individual tokens in the value of the 'role' attribute; this is not the case with CURIES. We note that as far as we can tell from the namespace document, everything currently defined in the XHTML namespace is in fact an NCName, so that QNames could be used in lieu of CURIES, without loss of functionality as regards the items in the XHTML namespace -- and, for software working with standard schema-aware infrastructure, some substantial gain in functionality. (5) If it's desired to provide the better validation and easier access to the namespace binding which would be provided by using the xsd:QName type, but nevertheless not to rule out the use of CURIEs which are not QNames, then we suggest the best way to define the role attribute right now would be to define (1) a union of QName and CURIE (in that order), and (2) a list of values from that union, and to make the latter the type of the role attribute. That would ensure that XSD-aware software would provide access to the namespace names when possible, and leave the task to the application only when necessary. (6) A second concern is that we are unable to locate an XSD definition of the datatype xh11d:CURIEs. In general, the documentation for the namespace <http://www.w3.org/1999/xhtml/datatypes/> falls, we regret to say, somewhat short of the standard you set with your namespace document for <http://www.w3.org/1999/xhtml/vocab/>. Because we have not been able to find the XSD definition, we have not been able to evaluate the XSD implementation of the role attribute. What's present in appendix B.1 looks fine as far as it goes, but the utility of the module really depends on the definition of the datatype xh11d:CURIEs. If you can point us to the XSD schema document which contains the definition of that datatype, we will be happy to review it. (7) We note that unprefixed names in the value of the 'role' attribute effectively default to the XHTML namespace. The first paragraph of section 3 says in part: Any non-qualified value MUST be interpreted as being from the XHTML vocabulary at http://www.w3.org/1999/xhtml/vocab#. We are of mixed mind about this; the longer we have thought about the matter, the less certain we are that we have understood just what the sentence is intended to say, and the more likely it seems that it touches on important fundamental design issues for the use of namespaces in XML. On the one hand, this rule seems parallel to the rule in XPath 2.0 and related specifications that there is a separate default namespace for function names, which means that a call to count(), for example, need not be qualified even if a default namespace in the context in which it occurs. Since the XML Query and XSL Working Groups provided a specialized default namespace in this way, it would seem inconsistent to object to your making a somewhat similar rule for the role attribute. On the other hand, the specialized rule for the default function namespace was forced upon XPath 2.0 by the requirement for compatibility with XPath 1.0, and might well have been avoided had compatibility not made it necessary. Do similar compatibility issues arise for the role attribute? The biggest problem is just that the existing xsd:QName datatype, and datatypes constructed from it in the usual ways, already provide a rule for deciding how to interpret unprefixed names in a context where namespace prefixes (e.g. as part of QNames or CURIES) can appear: they are assigned to the default namespace. There is no general-purpose mechanism for changing the default namespace just for the value of a single attribute. Either the idiom you seem to be proposing is a good one, and the definer of an attribute or element or type should be able, as a general principle, to specify that what namespace bindings should apply, or at least what the default namespace should be, in values of that attribute or element or type, or else the idiom is not a good one, no general mechanism is needed, and you need to be persuaded that the idiom you seem to be proposing is not a good idea. For a mixture of technical and aesthetic reasons, we lean toward the latter view. The aesthetic reasons are simple: there are already too many different rules for interpreting unprefixed names (in the default namespace, for elements and QName values; in no namespace, for attribute names; in the default function namespace, for function calls), and adding new ones will not make the world a better place. The technical reasons are also simple: we see no prospect of being able to support this kind of mechanism in the generic XML tool stack; it raises too many issues, and introduces too many incompatibilities with the existing XML infrastructure. (8) On yet another hand, we note with a mixture of relief and anxiety that we were obliged to speak above about "the idiom you seem to be proposing" -- it's not entirely clear what you are proposing, and so it's possible that we have misinterpreted it. Since it is usual for XHTML documents to use <http://www.w3.org/1999/xhtml> as the default namespace, it will normally be the case that unprefixed names in the value of the role attribute are asigned by the usual rules for interpreting namespace prefixes to the XHTML namespace. If the remark Any non-qualified value MUST be interpreted as being from the XHTML vocabulary at http://www.w3.org/1999/xhtml/vocab#. refers only to this fact, then we suggest only that it be rephrased. If, on the other hand, it is intended to mean that any token in the value which has no namespace prefix and no colon is to be assigned to the XHTML namespace, then we think that this is inconsistent with the normal rules of namespaces (see point (7) above). (9) In point (8) we took the sentence Any non-qualified value MUST be interpreted as being from the XHTML vocabulary at http://www.w3.org/1999/xhtml/vocab#. to be referring to tokens in the value which lack namespace prefix and colon. Strictly speaking, though, the usual terminology for such tokens calls them "unprefixed", not "unqualified" -- unprefixed names are in fact namespace-qualified if they are assigned to the default namespace. So a third interpretation of the sentence is possible, namely that it is intended to be read as speaking not about unprefixed tokens but about unqualified tokens, and as saying about them, in effect, that if the normal rules for resolving namespace prefixes leave a token unqualified, then (since the namespace rules have NOT assigned the token to a namespace) an application-specific rule associated with the role attribute specifies that they should be interpreted as belonging to the XHTML namespace. This interpretation relies crucially on the subtle point that unqualified names are not assigned by the namespace specification to a magic or default or anonymous namespace, and similarly are NOT said by the Namespaces Rec to be in no namespace at all (although this paraphrase is frequently encountered); they are simply not assigned to a namespace by the Namespace Rec. There seems no reason that they could not be assigned to a namespace by an application-level convention. But we note that this area is rife with confusion, and we suggest that if you intend this interpretation, you explain it very carefully. No matter which interpretation of this passage you intend, it probably should be recast to make the meaning clearer. As indicated above, the interpretation outlined in comment (7) would cause us grave misgivings; that in (8) no misgivings at all; that in (9) would give food for thought. In any case, we believe that this point in your design requires careful coordination between the XHTML Working Group and the Working Groups in the XML Activity, and we invite you to a dialog about the relevant issues. --C. M. Sperberg-McQueen on behalf of the XML Coordination Group
From: Shane McCarron <firstname.lastname@example.org> Date: Sat Oct 18 18:10:16 2008 I noticed with some chagrin that our response to this issue was not sent via the issue tracking system. This is a "Formal" reply through that system. The actual formal reply was sent in http://lists.w3.org/Archives/Public/www-html-editor/2008OctDec/0000.html Please have your group review that response and indicate whether those comments address your concerns. Shane McCarron (on behalf of the XHTML 2 Working Group)