- From: Ben Adida <ben@adida.net>
- Date: Wed, 07 May 2008 21:46:25 -0700
- To: Al Gilman <Alfred.S.Gilman@IEEE.org>
- CC: public-rdf-in-xhtml-tf@w3.org, wai-liaison@w3.org
Al, In a comment on April 3rd [1], you said ======= 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. ======= In last week's telecon, we agreed that this point needs to be made clearer in the specification. The issue is inescapable: the point of @content is to override the rendered text. But we should encourage people to use @content only when necessary. Thus our resolution, that we "note that the use of @content prohibits the inclusion of rich markup in your content. If the inline content of an element is what you are trying to convey, then documents should rely upon that rather than duplicating that content using the @content attribute." Let us know if this is an acceptable resolution to this portion of your comments. Thanks! -Ben Adida Chair, RDFa Task Force. [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Apr/0031.html
Received on Thursday, 8 May 2008 04:47:05 UTC