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

Re: draft-gregorio-uritemplate-02.txt

From: James M Snell <jasnell@gmail.com>
Date: Mon, 26 Nov 2007 11:34:50 -0800
Message-ID: <474B1FDA.2050705@gmail.com>
To: Joe Gregorio <joe@bitworking.org>
CC: URI <uri@w3.org>


Joe Gregorio wrote:
> [snip]
> 
>> 2. Did you decide against introducing cardinality indicators?
>>    e.g., {-list|&|foo+,bar}.
> 
> I haven't decided against them, just waiting for more feedback,
> particularly weighing cardinality  vs. required/optional
> vs can-be-a-list indicators.
> 

Ok. I'm not convinced they're absolutely necessary within the template
syntax, especially since we've left it up to external context to define
everything else about the template variable.

>> 3. For -join, you need to specify what happens if the value is a list.
>>    e.g., foo = ['a','b'] would expand to foo=a&foo=b
> 
> Yeah, I'd like to hear more opinions about using
> lists in operators outside '-listjoin'.
> 

In join, lists are fine, we just need to indicate that the name=value
pair will be repeated for each member of the list.

In prefix and append, see #4 below.  Allowing values to be lists does
not add significant complexity to the implementation but it does cause
some overlap with listjoin.

>> 4. There are interesting things that could be done if we allow prefix
>>    and append to use list values.  The prefix or postfix would be
>>    applied to each item  in the list. e.g., when foo = ['a','b'],
>>    {-prefix|/|foo} would expand to "/a/b" and {-append|/|foo} would
>>    expand to "a/b/".
>>
>>    http://example.org{-opt|/-|categories}{-prefix|/|categories}
>>
>>    http://example.org/-/a/b/c
>>
>>    http://example.org{-opt|/-/|categories}{-append|/|categories}
>>
>>    http://example.org/-/a/b/c/
> 
> I worry about introducing that level of complexity into the
> specification/implementation.
> 
> 
>> 5. We need to decide whether or not "extension operations" are going to
>>    be allowed, and if so, how are they to be handled.  Should an
>>    template processor signal an error if an unknown operation is used?
>>    Should the processor replace the unknown token with an empty string?
> 
> I am leaning towards a 'must ignore' stance with respect to
> unknown operators, i.e. replace the expansion with the empty string.
> 

The challenge with must-ignore in this context is that it can lead to
undesirable results.

e.g., http://example.org{-opt|/|user}{-sub|0-1|user}{-opt|/|user}{user}

since sub is now undefined, with must-ignore, this would expand to:

  http://example.org//joe

I'm not certain must-ignore buys us anything.

>> 6. We should include a section on IRI Templates. I'll volunteer to write
>>    it up if you'd like.  An IRI template is generally identical to the
>>    URI Template with the exception of the characters allowed in varname,
>>    arg and the replacements.  The following is taken from my expanded
>>    ABNF:
> 
> So in the IRI case any characters outside ( iunreserved / pct-encoded )
> in a variable value need to be percent-encoded, and we skip the UTF-8
> encoding?
> 

Yes to the first part. I still think UTF-8 encoding SHOULD be used.

- James

>    -joe
> 
Received on Monday, 26 November 2007 19:35:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:37 GMT