- From: Toby Inkster <tai@g5n.co.uk>
- Date: Mon, 12 Apr 2010 10:17:24 +0100
- To: "Ivan Herman" <ivan@w3.org>
- Cc: public-rdfa-wg@w3.org
> I appreciate that, and it might, technically, be a good idea to treat it > that way. However... doesn't that break backward compatibility? In RDFa > 1.0 that safe CURIE would definitely be ignored... It does break backwards compatibility with RDFa 1.0, yes. But if you consider my example, an RDFa 1.1 processor would alreay generate radically different triples to an RDFa 1.0 processor... >> <div profile="http://example.com/profile" >> xmlns:foaf="http://xmlns.com/foaf/0.1/"> >> <p about="#bob"> >> <span property="foaf:name">Bob</span> >> <span about="[fred:me]" property="foaf:name">Fred</span> >> </p> >> </div> Assuming that "fred" is defined by the profile, even if the profile can be resolved, then an RDFa 1.1 processor would generate: @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix fred: <something> . <#bob> foaf:name "Bob" . fred:me foaf:name "Fred" . While an RDFa 1.0 processor would generate: @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix fred: <something> . <#bob> foaf:name "Bob" , "Fred" . This is another reason why I think allowing profiles to define prefixes is not such a good idea. We'll only get close to backwards compatibility if we restrict profiles to defining terms (but not prefixes) for @typeof/@property/@rel/@rev/@datatype. -Toby
Received on Monday, 12 April 2010 09:17:59 UTC