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

Re: Telecon Agenda - 4th March 2010, 1500 UTC

From: Shane McCarron <shane@aptest.com>
Date: Thu, 04 Mar 2010 06:05:23 -0600
Message-ID: <4B8FA203.5000107@aptest.com>
To: Ivan Herman <ivan@w3.org>
CC: Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>

Ivan Herman wrote:
> On 2010-3-4 04:07 , Manu Sporny wrote:
>> The default may even be to never follow-your-nose. For example, Google
>> may hard code their vocabulary prefixes in their RDFa processors -
>> giving processor writers this flexibility may be okay as long as we're
>> clear that the triples that an RDFa processor generates must always be
>> generated as if the @profile/@vocab document were de-referenced and the
>> prefixes loaded out of the @profile/@vocab document.
> That I think I would not like (or I misunderstand you). This would mean
> that an RDFa document, when interpreted via Google, would yield a
> different set of triples than when run through, say, the distiller. In
> effect, that would mean that google would control what other
> implementations would have to use to make it interoperable and I do not
> think that is o.k.

I am pretty sure Manu just means that it is permissible to cache the 
contents of the vocabulary definition, and that it is also permissible 
to hard code the contents.  So if we (or Google or whomever) define a 
vocabulary at a well known URI and commit to never changing that vocab 
at that URI, it is permissible to hard code it in an implementation.  I 
personally have no problem with that, nor do I have a problem with 
caching (although we should probably ensure that the HTTP cache-control 
header is used).

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Thursday, 4 March 2010 12:06:13 UTC

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