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

Re: Feedback on draft-gregorio-uritemplate-00

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 10 Oct 2006 10:03:55 +0200
Message-Id: <5BECEC14-F67C-4E50-A62D-7235F11613D1@greenbytes.de>
Cc: Mark Nottingham <mnot@mnot.net>, Sam Ruby <rubys@intertwingly.net>, uri@w3.org
To: James M Snell <jasnell@gmail.com>

James,

SPACE (if it is what i think it is) seems like a bad idea. The  
whitespace-ness of URI endings is very dear to me. I would like to  
see that extended in templates.

Cheers,

Stefan

Am 09.10.2006 um 19:01 schrieb James M Snell:

>
>
> 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 Tuesday, 10 October 2006 08:04:16 UTC

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