- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 10 Oct 2006 14:15:08 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Sam Ruby <rubys@intertwingly.net>, uri@w3.org
My preference would be to allow all characters allowed in URIs in
template names; that way, it's easy to describe and understand what
their range is, and we already know how useful URIs are...
On 2006/10/10, at 8:51 AM, James M Snell wrote:
> 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.
>>>
>>
>>
--
Mark Nottingham http://www.mnot.net/
Received on Tuesday, 10 October 2006 21:15:58 UTC