- From: Ben Adida <ben@adida.net>
- Date: Mon, 08 Mar 2010 14:35:22 -0800
- To: Ivan Herman <ivan@w3.org>
- CC: Mark Birbeck <mark.birbeck@webbackplane.com>, W3C RDFa WG <public-rdfa-wg@w3.org>
On 3/7/10 1:52 AM, Ivan Herman wrote: > > Hm, this is not what I feel is happening. The processor is working on > some non-RDF data (XHTML+RDFa file) and, the 'vocab' graph directs this > processor on how to generate that 'target' draft. I *think* I see what you're saying Ivan, and if so I think I lean in your direction. Allow me to raise one issue that I believe is related and that I don't think has been raised yet. Given my non-attendance on calls, I'm going to try to do this rarely, so I'm raising this now because I think it may be quite important. *** Should we really allow the @vocab/@profile document to define *prefixes*, rather than just keywords? *** In other words, no doubt we want this: <div profile="http://astrology.org/vocab#"> <span property="sign">Pisces</span> </div> But do we really want this: <div profile="http://astrology.org/vocab#"> <span property="astro:sign">Pisces</span> </div> which feels odd because now we're saying that RDFa 1.1 markup is going to regularly throw CURIE resolution errors with an RDFa 1.0 parser. I understand that, from Mark's point of view and implementation proposal, there's no difference between defining a prefix and defining a keyword, but I'm not sure that's natural to most people: it requires buying into the idea that property="foo" means a "foo" *prefix* and no suffix, rather than an empty prefix and a "foo" suffix, which is the *much* more natural way to interpret how xmlns is typically handled. And it now means that @xmlns in RDFa, rather than being a simple augmentation of @xmlns in RDF/XML, is now actually quite different. All this to say: I know we *can* build a solution where prefixes are defined elsewhere... but do we want to? Do we really need to? I think if we say "use xmlns if you want to use prefixes, use vocab if you want to use bundles of keywords", we've got ourselves 90+% of the use cases, and a lot less complexity. OK, flame me :) -Ben
Received on Monday, 8 March 2010 22:35:51 UTC