W3C home > Mailing lists > Public > uri@w3.org > August 2011

RE: URI templates: comma-separated variable lists

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Thu, 25 Aug 2011 10:08:38 +1000
To: Joe Gregorio <joe@bitworking.org>, "uri@w3.org" <uri@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E1128B7F9FB1@WSMSG3153V.srv.dir.telstra.com>
On Wed, Aug 24, 2011 at 9:50 AM, James Manger <James@manger.com.au> wrote:
>> draft-gregorio-uritemplate-06.txt allows a comma-separated list of variables in any expression, regardless of the expression operator.
>>
>> However, a list should not be used with 5 of the 8 operators (+ # . / and no operator) because an expansion will be ambiguous if any variable in the list is undefined. The server cannot tell which value goes with which variable.

Joe Gregorio responded
> URI Templates are for expansion and not parsing, so the use case of
> trying to figure out which value goes with which variable is not a
> supported use case.

The server will almost always want to parse a URI built from a template.
That doesn't mean the template has to provide *instructions* on how to parse.
The spec correctly notes that regular expressions are generally better
suited as parsing instructions.

The problem with {alpha,beta,gamma} as a template is that NOTHING
(not even a regex) can be used to parse the expansion.
That should be a huge warning sign that this construct is not useful.

The URI templates spec shouldn't go to heroic efforts to try to prevent
template authors from writing templates whose expansions cannot be parsed.
It should not, however, offer constructs that will NEVER be parseable,
despite servers wanting to parse out variable values in 99.9% of cases.


> If it were then there would be more problems than with just lists. For
> example, how would the template
>
>  "{a}{b}"

This is clearly an unusual template because you can immediately see that
parsing is ambiguous. If you see such a template your first thought is that
the template author has made a mistake.
The spec doesn't have to forbid this template as in limited circumstances
it might be reasonable. Perhaps the author knows 'a' will be a 4-digit year
so it can parse the result with the regex "(\d\d\d\d)(.*)".
The parser could be fooled by unexpected 'a' and 'b' values but in some
limited context that might not be an important risk
(eg author, user, processor, and server are mutually trusting).


I don't want "{a,b}" allowed in templates given that it triggers the
same reaction as "{a}{b}": it is probably an mistake by the author.

--
James Manger
Received on Thursday, 25 August 2011 00:09:13 UTC

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