W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2011

Re: RDFa Core Review: Versioning

From: Toby Inkster <tai@g5n.co.uk>
Date: Mon, 3 Jan 2011 23:45:05 +0000
To: Jeni Tennison <jeni@jenitennison.com>
Cc: public-rdfa-wg@w3.org
Message-ID: <20110103234505.486f68c8@miranda.g5n.co.uk>
On Mon, 3 Jan 2011 20:37:51 +0000
Jeni Tennison <jeni@jenitennison.com> wrote:

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

Hi, these are my initial thoughts on your e-mail. This is not an
official WG reply.

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

There are others actually:

  * case insensitivity of prefix mappings

  * when an XML literal is parsed, in RDFa 1.0, child elements are
    not checked for further triples; in RDFa 1.1, they are.

  * the pre-defined rel/rev keywords in RDFa 1.0 will also work in
    other attributes in XHTML+RDFa 1.1 (that perhaps isn't a Core
    comment though)

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

Make sure you don't use any prefixes that differ in case only; use an
explicit datatype for XML Literals; don't use RDFa inside XML Literals.

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

Abide by the guidelines in my answer to previous question; don't use
@prefix; don't use profiles.

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

If you hope to offer both, then the divergent code paths are not too
many. However, I can't remember exactly how we resolved this issue, but
it might be non-conformant with regards to 1.1 for your parser to
automatically switch to a 1.0 mode based on the @version attribute.

With one exception, which will be fixed in the next release, I'm pretty
sure my RDFa parser handles both versions correctly.

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

I'm not sure this is necessary. With the exception of the XMLLiteral
stuff, an RDFa 1.1 processor can operate on RDFa 1.0 documents pretty
safely. The only other places differences would creep in are fairly

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

A future version of RDFa could use something like:


to mark a document, or even a subtree as 2.0-only. An RDFa 1.1
processor would ignore the document/subtree as it would be unable to
dereference the profile.

Toby A Inkster
Received on Monday, 3 January 2011 23:45:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:50 UTC