- 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>
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 so. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Monday, 29 March 2010 18:01:12 UTC