W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2009

Re: Proposal for allowing URIs in CURIE-only attributes

From: Simon Reinhardt <simon.reinhardt@koeln.de>
Date: Fri, 10 Jul 2009 23:49:53 +0200
Message-ID: <4A57B781.70705@koeln.de>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>

Mark Birbeck wrote:
> Using Julian's example:
>   <a xmlns:urn="http://purl.org/dc/terms/"
>    rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
>    href="http://example.com/terms_of_service.html">
>   >Terms of service</a>

I have a more realistic example for a problematic prefix mapping that you might actually want to use:

<a xmlns:http="http://www.w3.org/2006/http#" rel="http:requestURI http://example.org/" href="http://www.w3.org/2006/http#asterisk">blah</a>

> However, CURIE processing evolved a little, and what effectively
> happens now is that any predefined tokens are checked for first,
> before the whole prefix-processing steps kick in. So it's actually
> possible to differentiate between a predefined token and a relative
> URI, since it's either in the list, or it's not:
>   @rel="next"
>   @rel="relative-url"

I think this is a rather wonky solution because people use all sorts of values that are not defined in any constant list - or with HTML 5 you have a dynamic list defined on some wiki page. Google's "canonical" is one example.

> Interestingly enough, it is possible to solve this problem, by simply
> saying that any string of characters that begins with a predefined
> prefix is a CURIE, and anything else is a URI.

This, as well, I find a bit wonky. You always have to keep an eye on which prefixes you defined and which not. And if, say, you can only edit some snippet of a site then you might not even see all the prefixes that are defined in the whole document unless you look at its source. Not good for people who copy and paste some code but don't know much about HTML otherwise.

Of course, we always had this hack of defining xmlns:http="http" and then you can just use absolute HTTP URIs within @rel and @rev.
On a side note: In a template system I use CURIEs to access an RDF graph (that contains the data to be put into the page). There for simplicity I just defined that everything starting with "http:" is actually a HTTP URL. All other URIs, especially relative ones, have to be escaped to "safe URIs", URIs in angle brackets.

> So to bring everything together, the proposal is:
>  (a) RDFa should add support for URIs in attributes that currently only
>      support CURIEs;
>  (b) authors should be encouraged to use safe-CURIEs in those
>      attributes;
>  (c) but since ordinary CURIEs may still be used, we should differentiate
>      by saying that anything appearing before a colon, that is not a
>      mapped prefix, is a protocol.
> (From an implementation point of view this is extremely easy to add;
> if after splitting a 'potential CURIE' you find that the prefix does
> not map to anything, then just treat the 'potential CURIE' as a URI.
> Current processing requires the 'potential CURIE' to be ignored
> altogether.)

You talk above about backwards compatibility for markup that already uses something like rel="foaf:knows". But what about backwards compatibility for existing parser implementations? Wouldn't they break on what you propose? Are you confident that all existing implementations will be updated to that behaviour (if they don't already implement it) and that deployed systems will be updated to those new versions?

Received on Friday, 10 July 2009 21:51:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:03 UTC