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 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 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. |
| 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
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.
PROBLEM ID: 8049
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
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.
ORIGINAL MESSAGE:
From: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
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
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> 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)