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

Re: ISSUE-1: Status of RDFa Profiles

From: Ben Adida <ben@adida.net>
Date: Thu, 11 Mar 2010 15:39:02 -0800
Message-ID: <4B997F16.5030403@adida.net>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: RDFa WG <public-rdfa-wg@w3.org>
On 3/11/10 9:01 AM, Manu Sporny wrote:
> * The profile document can specify both tokens and prefixes

I'm still worried about inheriting prefixes from @profile, so I'm not 
sure we have consensus just yet. I think we still have an issue 
resolving both backwards compatibility and copy-and-paste'ability if we 
allow for profiles to define prefixes. I don't think Mark and Ivan's 
responses have resolved this.

Let me restate the issue I'm worried about: Google offers a wizard that 
lets you create a rich snippet chunk that you paste into your page, with 
@profile importing a "product" prefix.

  <div profile="http://rdf.google.com/rich-snippets">
    <span property="product:name">Canon Digital Rebel XTi</span>
    <span property="product:type">Camera</span>
    <span property="product:price">$500</span>

Now you paste that into your page, but you forget that somewhere higher 
up in the DOM, you declared a conflicting @xmlns:

  <div xmlns:product="http://rdf.yahoo.com/product#">

     ... stuff you paste ...


Given this situation, we have the following choices:

(1) @profile overrides parent @xmlns ==> RDFa 1.0 generates triples that 
are different from those defined by RDFa 1.1.

(2) @profile never overrides parent @xmlns ==> @profile is incompatible 
with copy-and-paste.

Given that we agree that @profile can appear anywhere, I don't see 
another option, and both suck.

Mark's solution of keeping different prefix lists generated by @xmlns 
and @profile is equivalent to solution (2), which kills copy-and-paste 
when we precisely want users of @profile to not have to worry about 
complexity and @xmlns.

Ivan's point that we have the same situation with keywords is 
interesting, but I think not quite right, because

(a) the number of default keywords is small and predictable, unlike the 
number of possible @xmlns prefixes declared in a random user's page

(b) web sites preparing copy-and-pasteable chunks of HTML+RDFa can thus 
take care not to override existing HTML4/5 keywords.

I understand that, if @profile does not include prefixes, then we're not 
providing the convenience function that Ivan wants for RDF-community 
authors. But I think the potential confusion / loss of copy-and-paste is 
too high a price to pay for this convenience.

> * Are we limiting next/prev/index/license/etc to @rel/@rev or allowing
>    them everywhere?

I think that, in RDFa 1.0, they are limited to just @rel and @rev, 
right? So that's actually nice because it means that the copy-and-paste 
keyword confusion between RDFa 1.0 and RDFa 1.1 is limited to just 
@rel/@rev, which makes it, once again, an even smaller problem.

I think it's okay for us to say that new @profile's can define keywords 
for all attributes.

> * What is the mental model are tokens/prefixes two different concepts
>    in RDFa or are they the same thing?

I don't think we'll be able to convince the average user that they are 
the same thing. I appreciate the elegance of Mark's proposal, but that 
elegance is at a level of abstraction that I think most HTML authors are 
not familiar with.

Received on Thursday, 11 March 2010 23:39:34 UTC

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