Re: Reviewing Last Call RDFa

Tim,

You sent comments to us a few weeks ago regarding RDFa:
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0297.html

and I responded to most of them here:
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0299.html

to which you responded here:
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0317.html

I want to reiterate the points I made briefly, and complete the 
response, just to be sure we have addressed this issue fully.

Please let us know if these responses are satisfactory.

> ** Deployment path and architecture:
> 
> In general, is the deployment path for this spec that (a) it introduce  
> new attributes into the HTML namespace, and that conforming RDF-aware  
> HTML clients be expected in future to understand RDFa, or is it that  
> the GRDDL transform link from (b) the document or from (c) the HTML  
> schema?

We are adding attributes to the XHTML1 namespace, and we expect 
RDFa-aware clients to understand these as RDF. We will also be adding a 
GRDDL link in the XHTML namespace. We've left the "SHOULD" on the 
@profile, because we've been told that a number of GRDDL clients don't 
do namespace-based transformations (we haven't confirmed this, we're 
just trying to be accommodating for folks who want to choose this route.)

The Follow-Your-Nose architecture principle is fulfilled by the XHTML 
namespace document, which we are updating via the XHTML2 WG, and the 
definition of XHTML1.1+RDFa. The GRDDL pointers are there for 
convenience, but may be considered redundant.

> ** Purpose of the profile
> 
> Is the purpose of the profile to allow GRDDL engines to find RDFA, or  
> to protect against a non-RDFa document being interpreted as an RDFa  
> one, and that being taken as carrying more semantics than it actually  
> was intended to by its author?  From discussion with Ralph I  
> understand the position of this has changed since  I first looked at  
> RDFa.  I think it should be made clear how this should work.
> I don't think "you can do whichever you want" is a suitable answer, as  
> the whole point is to have a set of standards which allow any client  
> and server (well, reader and writer)  to communicate.

See above for the explanation.

> ** DTDs
> 
> 4.1   "There SHOULD be a DOCTYPE declaration in the document prior to  
> the root element."  DTDs are a an obsolete technology. Suggest the  
> spec not refer to them in any way.

You mentioned that the W3C is working on a DTD-free method of 
validation. Hopefully that will be ready in time for RDFa 1.1. For now, 
though, we have no choice but to refer to them in order to help our 
users put a "valid according to W3C" logo on their pages.

> 4.3  "A conforming RDFa Processor MAY make available additional  
> triples that have been generated using rules not described here, but  
> these triples MUST NOT be made available in the [default graph]."
> 
> I feel this is an inherently weak method of specifying the meaning of  
> an RDFa document.

We only mean this to enable RDFa processors to also process 
microformats, if they so choose. We felt that not leaving this door open 
might lead some folks to interpret RDFa as ruling out an RDF 
interpretation for microformats, which is not our intention. We could 
not find a cleaner way to phrase it without making the spec much more 
complicated.

At the same time, we feel that the specification is quite strict and 
thus strong about the [default graph], which is the whole enchilada as 
far as RDFa is concerned.

-Ben

Received on Monday, 9 June 2008 16:51:16 UTC