- 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