Re: RDFa Core Review: Versioning

Having implemented a processor that does attempt to parse both 1.0 and 1.1 RDFa (RdfContext and rdf-rdfa), I can address some points.

The fact that @version is removed is, I believe, unfortunate. Since, without this, a processor needs a priori information about what it's processing, and this cannot be uniformly determined by a simple examination of the document in advance. In my case, a specific flag needs to be passed to the processor to set "1.0 mode". That said, the differences aren't too bad, as they typically result in more triples being generated, meaning that information is not lost, but extra information may be added.

Regarding prefix case-insensitve mapping, I seem to recall a discussion where @xmlns prefixes would continue to be matched case-sensitvely, as the few areas where information can be lost or changed. However, I don't see any provision for this in either the RDFa 1.1 core or XHTML+RDFa 1.1 documents. My processor does not downcase @xmlns prefix definitions, but does downcase a CURIE prefix, so this would result in triples that were previously generating not generating any output. There also aren't any tests for this in the test suite one way or the other. However, these are corner cases that are really represent bad RDFa style, it's not good form to rely on the case sensitivity of prefixes to make them distinct (although this is allowed for terms with a fallback to case-insensitive matching).

Good form, even in 1.0, would be to tag XMLLiterals with @datatype=rdf:XMLLiteral, which would avoid this incompatibility. However, you're correct that this will result in different data output.

Other than prefixes and XMLLiterals, 1.1 processors should be backwards compatible with 1.0, except that they will generate extra triples. As you note, 1.0 processors are not forward compatible with 1.1 documents, and may not generate any triples at all. It is certainly possible to write a 1.0 document that will operate predictively with a 1.1 processor, but legacy documents may not parse properly.

Note that another potential source of authoring problems may be masked in 1.1, as URI definitions are much more liberal: For example, without defining a prefix for "foaf", "foaf:name" will resolve to <foaf:name>. This wasn't as much of a problem 1n 1.0, as there was greater distinction between URIs, CURIEs and URIorSafeCURIE.

Gregg

On Jan 3, 2011, at 12:37 PM, Jeni Tennison wrote:

> 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 23:49:36 UTC