- From: Ben Adida <ben@adida.net>
- Date: Thu, 11 Mar 2010 15:39:02 -0800
- 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>
</div>
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 ...
</div>
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.
-Ben
Received on Thursday, 11 March 2010 23:39:34 UTC