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: Tue, 10 Oct 2006 08:51:45 -0700
Message-ID: <452BC191.8030608@gmail.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
CC: Mark Nottingham <mnot@mnot.net>, Sam Ruby <rubys@intertwingly.net>, uri@w3.org

I'd prefer to have SPACE in there but I can definitely live without it.
 The reasons for not allowing it are definitely quite valid.

- James

Stefan Eissing wrote:
> 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 15:52:07 UTC

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