RE: Beyond CURIEs

Misha/Mark,

I completely agree with Mark's suggestions, and have come to exactly the
same conclusions as he has. We are working on a new type of browser, called
Sidewinder, and a number of the features you describe, Mark, are being
prototyped there. However, in terms of proposing some kind of standard, I've
been saving these suggestions for another day! There are a number of reasons
why.

The first is that we fairly urgently need something very like QNames, but
*not* QNames. There are already a number of specifications using QNames
'incorrectly', so one aim of CURIEs was to simply give another name to
QNames. But in addition, the IPTC were using what they thought were 'QNames'
to express things like this:

  iptc:00223008

Now, QNames cannot have numbers in the local name part--they are XML element
and attribute names--which seems an odd restriction to place on a taxonomy.

The second set of reasons I've held off from proposing that CURIEs is
something more like Mark's work is that I would prefer to see a generic
solution for *all* attribute values, not just URIs. The squiggly brackets
are already used in this way in AVTs in XSLT and it seems natural to extend
this to other things. It's a discussion we have fairly often in the XForms
Working Group ;) but personally I'd prefer that it was a basic DOM thing,
rather than the preserve of any one language.

So to make this more concrete, your requirement for this:

  <a href="http://www.example.com/{isbn}/author">Author</a>

could be solved by my more general requirement for this:

  <h1>My tasks</h1>
  <span class="{overdue} task">Mow the lawn</span>

Which is not to say you shouldn't propose 'generated URIs' (far be it for me
to tell people what to do!!), especially if you think that these
abbreviations are needed outside of an attribute. But from my own point of
view I feel that CURIEs handles a small task reasonably well, and I'd like
to see a separate solution for the much more general problem of assigning
attribute values based on other parts of the DOM.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/



> -----Original Message-----
> From: public-rdf-in-xhtml-tf-request@w3.org 
> [mailto:public-rdf-in-xhtml-tf-request@w3.org] On Behalf Of Misha Wolf
> Sent: 02 June 2006 22:33
> To: public-rdf-in-xhtml-tf@w3.org; newsml-2@yahoogroups.com
> Subject: FW: Beyond CURIEs
> 
> 
> 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 Monday, 5 June 2006 14:59:36 UTC