Re: comments from PFWG on RDFa in XHTML spec

Dear PFWG,

Thanks very much for these comments, which are quite insightful and 
useful. I'll answer the already-resolved issues below, and enter the 
remaining issues into our Issue Tracker at [1].

> Has the use of RDFa for 
> dynamic information in XHTML pages been considered?

We have not done so officially, though it's interesting to note that 
some RDFa parsers, e.g. Operator, do track document changes and update 
their RDF graph accordingly. Because RDFa is defined with respect to the 
DOM, DOM changes can be processed relatively easily, even if we haven't 
specified the details.

I'll add this to our list of discussion topics.

> 2.2 Issues with @content (section 6.3.1.1)
> 
> (a) What is the rationale for having the @content value replace the 
> element content in terms of RDF statements?

When the rendered text is not easily machine readable, e.g.:

  <span property="cal:dtstart" content="20080403T1600Z">
    today at 10am
  </span>

We left open the possibility that the content "today at 10am" might be 
interpreted as having some value, e.g. the human readable version of the 
value. But we felt that the exact way in which this will be done will 
require more time "in the wild," so we chose not to specify it yet.

> 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.

That would make the above use case particularly difficult: we do need 
@content to override the rendered text for a number of use-cases.

> (b) [...] 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.

I like the idea of emphasizing this point, that @content should be used 
as a "last resort," and we'll discuss it in the group.

> 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.

On principle, we agree, but in practice we have to go with our "host" 
language XHTML 1.1, and its use of base. Specifically, browsers will 
resolve @href and @src according to the base element, so we have no 
choice but to follow their lead.

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

Because XHTML 1.1 specifically ignores it for purposes of resolving URIs 
in @href and @src. We can't go beyond our host language, or we would be 
incompatible with existing browsers.

[...]

> 2.5 RDFa in HTML documents
> 
> This specification does not address using RDFa in HTML documents (only 
> for XHTML documents).

Indeed, it does not. That was not part of our scope. We *do* want to 
make RDFa work in HTML documents, too. The PFWG's support for RDFa in 
HTML5 would be *super*. Please let the HTML WG know that this is an 
important use case for RDFa :)

>  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).

Yes, we generally agree (though we haven't officially resolved this.)

> 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.

We have discussed it unofficially for HTML documents, specifically 
mentioning that the prefix-mapping process may well be different based 
on the host language. I will add your point about how they should be the 
same for HTML and XHTML to our issue tracker.

Thanks again for these very helpful comments! Full responses to each 
point will follow after group discussion.

-Ben


[1] http://www.w3.org/2006/07/SWD/track/products/2

Received on Thursday, 3 April 2008 17:10:25 UTC