- From: Misha Wolf <Misha.Wolf@reuters.com>
- Date: Fri, 02 Jun 2006 22:33:23 +0100
- To: public-rdf-in-xhtml-tf@w3.org, newsml-2@yahoogroups.com
fyi -----Original Message----- From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Mark Nottingham Sent: 02 June 2006 20:58 To: www-tag@w3.org Cc: Joe Gregorio; Marc Hadley Subject: Beyond CURIEs CURIEs are a great step forward from QNames, and I like them very much. However, they limit the abbreviation that you can do to the front of the URI -- e.g., they allow abbreviation of the scheme, authority, and path together, but not just the path. Several use cases would benefit from having a standard syntax to abbreviate *any* part of a URI -- not just the front. For example, I've been experimenting with doing client-side variable interpolation into URL templates <http://www.mnot.net/javascript/ url_template.html>. Here, it's useful to vary the end, rather than the beginning, of the URL. Joe Gregorio previously published a similar article <http:// www.xml.com/pub/a/2005/04/06/restful.html> explaining how to construct URIs dynamically in Python. Mark Hadley's WADL <http://research.sun.com/techrep/2006/ abstract-153.html> would also benefit from such a shorthand syntax. In general, it seems like CURIEs are tantalisingly close, but just short, of supporting generative URIs <http://rest.blueoxen.net/cgi- bin/wiki.pl?GenerativeNaming><http://www.mnot.net/blog/2004/04/16/ generative>. By only allowing abbreviation at the front of URIs, they constrain the types of URIs that you can create; for example, if you want to have a CURIE for a particular book's author, you're forced into a URI like http://www.example.com/getAuthor?isbn=0321154991, rather than the more natural, structured http://www.example.com/0321154991/ author. In many ways, they share the limitations of other prefix mechanisms, as discussed in the background of URISpace <http:// www.w3.org/TR/urispace>. The pattern that I see very often is the use of braces -- which are not allowed in URIs (being neither reserved nor unreserved) -- to delimit a variable name, which is then interpolated from context. E.g., http://www.example.com/{isbn}/author or {book_site}0321154991 which is unambiguous (because there's no conflict with existing URI syntax) and easy to process, and only one character longer than the current CURIE. I'd very much like to see such a thing standardised, along with mechanisms to populate the context in common situations (e.g., XML). This doesn't necessarily conflict with CURIEs; indeed, they don't meet one of their primary requirements; to be backwards-compatible with QNames. CURIEs fill an important gap in the current architecture, and address a lot of the pain with QNames by offering a transition path. There are cases, however that CURIEs don't address, but some people will misuse to try to; hence this approach. The only thing I'm missing is a zippy name... -- Mark Nottingham mnot@yahoo-inc.com To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
Received on Friday, 2 June 2006 21:33:50 UTC