W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: A rose by any other name is just as thorny...

From: Toby Inkster <tai@g5n.co.uk>
Date: Mon, 29 Mar 2010 19:00:31 +0100
To: Shane McCarron <shane@aptest.com>
Cc: Mark Birbeck <mark.birbeck@webbackplane.com>, Ivan Herman <ivan@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Message-ID: <1269885632.3257.19.camel@ophelia2.g5n.co.uk>
On Mon, 2010-03-29 at 09:13 -0500, Shane McCarron wrote:
> Actually, I disagree.  The current discussion was around ensuring this
> is backward compatible for existing documents.  If I reference a new 
> 'default vocabulary' then I have switched contexts.  Clearly I am not 
> writing an RDFa 1.0 document, I am working in the context of RDFa 1.1.
> New rules apply.  Backward compatibility has to be our first priority.
> But as soon as a document switches contexts, I think the author has
> chosen to by in an RDFa 1.1 world where 'CURIES with no prefix' are
> interpreted as 'terms' in some other vocabulary. 

There are two types of compatibility at stake here:

1. Do RDFa 1.0 documents work in RDFa 1.1 processors?
2. Do RDFa 1.1 documents work in RDFa 1.0 processors?

Clearly this issue doesn't affect compatibility #1 as no RDFa 1.0
conformant document will contain the @vocab attribute necessary to
switch default prefix.

However, it does affect compatibility #2. Of course we can't expect RDFa
1.0 processors to fully understand RDFa 1.1 - that would mean that the
revision of RDFa would have to essentially be a no-op. But we can design
RDFa 1.1 such that any new features will be entirely ignored by an RDFa
1.0 processor - that is, the RDFa 1.0 processor sees a subset of the
default graph produced by an RDFa 1.1 processor.

Allowing the RDFa 1.0 keywords to be redefined by @vocab or @profile
does affect compatibility between RDFa 1.0 and RDFa 1.1. I'm not saying
that it mustn't be done, but merely that we should be careful in doing

Toby A Inkster
Received on Monday, 29 March 2010 18:01:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:17 UTC