comments from PFWG on RDFa in XHTML spec

<note
class="inTransmittal">

Thank you for letting us take a little extra time
to comment on this draft.

The following comments have been supported by a rough
consensus in the Protocols and Formats WG.

We would be glad to discuss anything here that is
unclear or not convincing with you at your convenience.

Al
/chair, PFWG

</note>

1. Potential of the technology

RDFa in XHTML (http://www.w3.org/TR/2008/WD-rdfa-syntax-20080221/)  
has potential for accessibility and Web users with disabilities by  
allowing authors to mark core information on their web pages in a  
machine-readable manner.  Assistive technology can use this  
information in their interacting with the user, and thus make access  
to information faster or possible where it would be cumbersome or  
impossible for the user otherwise.

A couple of sample use cases:

A screen reader telling the user the telephone number of an online  
shop web page when the user has problems finishing the transaction.
A schematic diagram illustration of the core content of a web page,  
for example such as offered by SWAPviews from UB Access (http:// 
www.ubaccess.com/swapviews.html).  This can be helpful for some  
people with cognitive disabilities.

2. Potential problems of the technology wrt accessibility

2.1 Processing described for static information only (section 5)

RDFa in XHTML seems to be scoped for static information only, and the  
processing model is described for a static DOM that does not account  
for dynamic changes after the document has been loaded. (Cf. first  
sentence in 5.5: “Processing would normally begin after the document  
to be parsed has been completely loaded”.)  This processing model  
seems restricted with regard to Web 2.0 applications that dynamically  
add or remove information while interacting with the user.  Has the  
use of RDFa for dynamic information in XHTML pages been considered?

2.2 Issues with @content (section 6.3.1.1)

@content may be used to indicate a plain literal which would  
overwrite the element content for RDF generation purposes.


(a) What is the rationale for having the @content value replace the  
element content in terms of RDF statements?  Why not make the  
@content value an alternative object in the statement (with the  
element content being the other alternative object)?  - This would  
give the end user the option to choose between the two alternatives.


(b) The use of @content bears the drawback that its value cannot be  
marked up.  The most prominent need for markup of text for assistive  
technology is the indication of language.  The spec addresses this  
issue (section 6.3.1.1.1) by making a sibling @xml:lang reign over  
@content.  However, this does not solve the problem of language  
changes inside the @content value (foreign words).   We propose to  
add a note that warns about the drawback of @content with regard to  
marking up foreign words within its value, and recommend using the  
(marked-up) element content instead of @content, wherever possible.

2.3 Use of <base> element

The use of an element to denote this information (a property that  
applies
"hereafter") seems to leave the end of the scope of the base information
un-marked.  This is one of the problems of "tag soup" that XML is  
supposed
to fix.

It would appear that this information should be denoted in an attribute.

Please explain why xml:base does not meet the need here.

2.4 Use of CURIEs (section 7)

While the use of CURIEs is convenient for the author, the procedure  
of resolving CURIEs to full URIs makes the code for parsing and  
generating the RDF graph more complex.  Assistive technology often is  
developed with little resources and often comes with small footprints.

2.5 RDFa in HTML documents

This specification does not address using RDFa in HTML documents  
(only for XHTML documents).  While most of the specification could  
also be applied to HTML documents, the mapping of CURIE prefixes will  
have to be rewritten for HTML documents (since there is no namespace  
concept in HTML).

This and the complexity problem mentioned in 2.4 make us wonder if  
the concept of CURIEs should be modified to not use the “xmlns: 
[prefix]” attribute for prefix mapping.  Have you considered  
alternatives that would allow a consistent use of RDFa in HTML and  
XHTML documents?  From the perspective of accessibility, consistency  
between HTML and XHTML documents should be a goal of the specification.


3. Typos

Section 3.8: “this this”
E. Acknowledgments: “This section is informative.” appears twice.

Received on Thursday, 3 April 2008 16:28:52 UTC