RDFa Core Review: Versioning

Hi,

Manu asked me to do a review of the RDFa Core Last Call Working Draft at:

  http://www.w3.org/TR/2010/WD-rdfa-core-20101026/

I'm going to use separate emails for major points for easier tracking but may combine more minor points into larger mails. I'll caveat my comments by saying that I haven't been following discussions on this list or in WG minutes, so may well cover things that have already been discussed to death, in which case I apologise.

So to the first, large, technical point: the lack of information about versioning. Having read through the RDFa Core LC WD and the XHTML+RDFa LC WD, I can't see anything that addresses versioning except for the removal of the version attribute (which was the mechanism for indicating the version of RDFa being used provided by RDFa 1.0). 

There are a number of backwards-incompatible changes in RDFa 1.1, some of which are called out in Appendix C.1 [1], such as:

  * the introduction of the prefix attribute
  * the introduction of terms and profiles
  * the interpretation of complex content lacking an explicit datatype as a plain literal rather than an XML literal

As someone managing a large site that produces RDFa, the questions I need answered are:

  1. What are the minimal steps I need to take to ensure that my RDFa 1.0 site continues to be interpreted in the same way by an RDFa 1.1 processor?
  2. When I move to using RDFa 1.1, how do I ensure that my site is interpreted in the same way by an RDFa 1.0 processor as it is by RDFa 1.1 processors?

As a developer of an RDFa processor, the questions I need answered are:

  3. Can my processor be both a conformant RDFa 1.0 processor and a conformant RDFa 1.1 processor?
  4. If not, what modes of processing do I have to offer in order to best enable users of the processor to correctly interpret RDFa 1.0 and RDFa 1.1 web pages in the way their authors intended?

The only answer that I think that I know is to Question 3: "no", a processor cannot be both a conformant RDFa 1.0 processor and a conformant RDFa 1.1 processor.

[In my opinion, the fact that this new version of RDFa is not backwards compatible with RDFa 1.0 really should mean that it is numbered as 2.0.]

I think it's absolutely necessary that a section on backwards compatibility is created that answers the above questions.

I would suggest that you try hard to make it possible for RDFa processors to be both conformant RDFa 1.0 processors and conformant RDFa 1.1 processors, as I think not doing so will make it harder for both those managing RDFa websites and those creating RDFa processors. You could do this by introducing a notion of a 'backwards-compatible mode' that is triggered by the presence of the version="XHTML+RDFa 1.0" attribute that SHOULD be present in RDFa 1.0 documents. The processing of RDFa 1.1 would be dependent on this mode; for example, when in 'backwards-compatible mode', the object of a triple created for an element with complex content and no datatype attribute would be an XML literal rather than a plain literal. (The approach of having a 'backwards-compatible mode' has worked fairly well for XSLT 1.0/2.0.)

I would also like to see something that will provide a method for the next version of RDFa (should there be one) to be backwards compatible with this one. Deprecating @version because it 'doesn't scale well as a language announcement mechanism' (and I'm not sure what that means) is fine, but I can't see what you've actually replaced it with?

Cheers,

Jeni

[1]: http://www.w3.org/TR/2010/WD-rdfa-core-20101026/#major-differences-with-rdfa-syntax-1.0
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Monday, 3 January 2011 20:38:27 UTC