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

Re: Feedback on draft-gregorio-uritemplate-00

From: James M Snell <jasnell@gmail.com>
Date: Mon, 09 Oct 2006 10:01:26 -0700
Message-ID: <452A8066.5050505@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
CC: Stefan Eissing <stefan.eissing@greenbytes.de>, Sam Ruby <rubys@intertwingly.net>, uri@w3.org



Mark Nottingham wrote:
> 
> I totally agree, and had thought that's where we ended up (we did a lot
> of last-minute adjustments ;). The template variable name should be able
> to be a full URI, with the full range of allowable characters available
> to it.
> 

Nope. When we cut back template-name to just the unreserved set we
eliminate the possibility that a template variable could be a full URI.

I think Stefan's suggestion of a two part definition is very good so
long as the template variable is still considered opaque to the template
processing code.

I would only make a couple of edits to Stefan's suggested ABNF

  template-char = unreserved
  template-name  = 1*template-char
  ext_char = unreserved / reserved / pct-encoded /
             SPACE / "|" / "\" / "^" / "`"
  template-ext = 1*ext_char
  template-var  = "{" template-name [ ":" template-ext ] "}"

Examples:

  Simple: {foo}
  Bash-style parameter expansion: {foo:=bar}
  URI: {foo:http://example.org/defs#Foo}
  Regex {foo:\d+}
  XPath: {foo:/a/b/c/@d}
  ABNF: {foo:1*unreserved}

In other words, this definition would give us a great deal of optional
flexibility while keeping the template-name itself very simple and
predictable.

It would not be that difficult* for uri template library code to provide
generic resolvers capable of supporting a variety of template-ext
vocabularies.  However, I anticipate that the vast majority of users
wouldn't use anything more complicated than a simple Map.

- James

* The only thing that becomes difficult is determining which
template-ext vocabulary is being used so that an appropriate resolver
can be selected.
Received on Monday, 9 October 2006 17:01:40 UTC

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