W3C home > Mailing lists > Public > uri@w3.org > September 2008

Re: URI Templates: done or dead?

From: Joe Gregorio <joe@bitworking.org>
Date: Mon, 15 Sep 2008 23:09:08 -0400
Message-ID: <3f1451f50809152009u301ef684wd70fa74a73748873@mail.gmail.com>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: URI <uri@w3.org>, "David Orchard" <orchard@pacificspirit.com>, "Marc Hadley" <Marc.Hadley@sun.com>

On Mon, Sep 15, 2008 at 7:57 AM, Mark Nottingham <mnot@mnot.net> wrote:
> There hasn't been a lot of discussion or activity on URI Templates recently,
> which either means it's very stable, or very nearly dead.

Neither, I have a list of open issues that were raised from the last
I-D and I have yet to address them, but I do plan on addressing them,
and that plan is slowly working its way higher on my to do list.

In the interim I have been keeping track of implementations:



> If it's very stable, we should ship it and be done with it. If it's nearly
> dead (and I do get a whiff of that; while I continuously hear people
> clamouring for it to be finished, not many seem to be willing to use it in
> its current state; YMMV), we should at least try to revive it.
> My continuing concerns with the -03 draft are that it's too complex, not
> human-friendly, and it makes the common, simple use cases hard. The first
> example in the spec ( http://www.example.com/users/{userid} ) holds up well,
> but it goes quickly downhill from there; (
> http://www.example.com/?{-join|&|query,number} ) looks like line noise,
> I believe there are a few things we can do to make URI Template more broadly
> useful and useable, without sacrificing too much functionality (at least in
> the 80% case).
> 1. Reduce or drop operators.
> As mentioned above, they don't read well; they're obviously intended for
> machines, not people. The expansion for a template should be blindingly
> obvious, but the operator syntax seems to want to get in the way rather than
> help. Furthermore, the vast majority of use cases for templates are for
> simple template substitution, not operations like 'neg' and 'opt'.
> 2. Drop list values.
> Again, the majority of use cases out there have no need for list values in
> template variables, and including them in the spec significantly complicates
> things.
> 3. Make percent-encoding context-sensitive.
> There are just too many cases where the 'escape everything but unreserved'
> rule gets in the way; for example, if my template is
> "http://example.com/user/{email}", I'm going to have percent-encoded @ signs
> in my URIs whether I like it or not -- even though they're not required to
> be percent-encoded there. This is a relatively simple thing to do, as long
> as we also...
> 4. Allow exceptions to percent-encoding.
> We need a syntax that allows characters to be excepted from encoding, even
> in context. As a straw-man, I suggest preceding the expression with the
> characters that are excepted, like:
>   http://example.com/{/path}
>   http://example.com/thing{?&=query_args}
> and so forth.
> 5. If we keep operators at all, mint special ones for the common cases.
> E.g., something to handle encoded form query values "out of the box":
>  http://example.com/thing{-?a=foo&b=bar&c=baz}
> and likewise with matrix parameters.
> Let's see if that shakes things up...
> --
> Mark Nottingham     http://www.mnot.net/

Joe Gregorio http://bitworking.org
Received on Tuesday, 16 September 2008 03:09:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:12 UTC