W3C home > Mailing lists > Public > uri@w3.org > November 2006

Re: Comments about URI Templates

From: James M Snell <jasnell@gmail.com>
Date: Wed, 15 Nov 2006 10:52:21 -0800
Message-ID: <455B61E5.1000706@gmail.com>
To: Mike Schinkel <mikeschinkel@gmail.com>
CC: uri@w3.org

Mike Schinkel wrote:
> [snip]
> #1.)  I can't help but think URI Templates is incomplete. I'd like to ask
> why you didn't include something like the following three ways to extend it
> (even though I otherwise dislike regex, if only required in rare cases they
> can be a huge boon):
>     pathId= "ABC-123"
>     http://www.foo.com/{substring(pathId,3,3)}/                   -> /C-1/ 
>     http://www.foo.com/{regex(pathId):^.*-(.*)$|xyz-$1}/    -> /xyz-123/ 
>     http://www.foo.com/{javascript:DbLookupPath(pathId)}/   -> /whatever1/ 
>     http://www.foo.com/{http://example.com/foo?value={pathId}}/   ->
> /whatever2/ 
> So I'm suggesting consideration for
> 1.) a set of builtin functions for extracting substrings, etc.
> 2.) support for scoped regex, and 
> 3.) support for javascript
> 4.) support for dereferencing http

There is tension between a) making URI Templates as flexible and
expressive as possible and b) keeping URI Templates as simple as
possible.  It turns out that it's quite hard to do both.

In an earlier draft we had the notion of URI Template Profiles --
derivative specifications that described specific structure and
processing requirements for template variables.  For instance, one could
have a profile for regex-based variables (e.g. {\d4}).  This was
dropped, however, for the sake of keepings things as simple as possible.

Profiles make implementation more difficult and increases the chance of
non-interoperable implementations of the core specifications (e.g. impls
may support different profiles).

> [snip]
> =========================
> 4.1  Template Variables
>    Template variables are the parameterized components of a URI
>    Template, their representation is described below.  A template
>    variable MUST match the template-var production.
>     template-char = unreserved
>     template-name  = 1*template-char
>     template-var  = "{" template-name "}"
> =========================
> Does that mean that you can use *any* character as a template-char? IOW, you

It means you can use any character in the "unreserved" set as defined by
RFC 3986.

- James
Received on Wednesday, 15 November 2006 18:59:12 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:49 UTC