- From: Niklas Lindström <lindstream@gmail.com>
- Date: Mon, 16 Nov 2009 13:46:58 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: Ben Adida <ben@adida.net>, RDFa <public-rdf-in-xhtml-tf@w3.org>
Hi! On Mon, Nov 16, 2009 at 1:03 PM, Ivan Herman <ivan@w3.org> wrote: > Still following up on this... > [...] > - I actually did an implementation on my machine, reasonably tested. The > algorithm is fairly simple (unless I miss an elephant in the room): > > 1. check whether the value is of the 'a:b' form and 'a' is defined CURIE > prefix > 2. if yes, return the URI as defined by the CURIE > 3. if not, do a urljoin of the base URI and the value. Per definition of > that join, if the value is an absolute URI, that will prevail, otherwise > the urljoin rules will dictate the behaviour. (eg, Python has just > method as part of its standard library...) > > The only difference between the old and new version is entries #1 and > #2, #3 was the behaviour as of RDFa 1.0. > > Actually, the same steps could also be used for @rel/@rev/@typeof, ie, > allowing relative URIs for those attributes as well! Which might > simplify everything: all RDFa attributes would behave similarly. (Again, > we should not touch @href and @src.) > > So is there an elephant?:-) I haven't followed this discussion to closely, so I want to check if this the following is considered: This usage will "muddle the waters" in cases when the relative URI:s contain colon, and there is a prefix with the same name as the leading part before that, right? Concrete (but contrieved) example: Given: - base URI: <http://en.wikipedia.org/wiki/> - prefix Talk: <http://example.org/schema/talk#> When: @resource="Talk:Linked_Data" Then: - URI becomes < http://example.org/schema/talk#Linked_Data>, instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is might be expected? (Don't mind the malpractise of using a "Title-cased" prefix here, I just picked the first real-word relative URL with colon in it I found..) Best regards, Niklas
Received on Monday, 16 November 2009 12:57:57 UTC