- From: James M Snell <jasnell@gmail.com>
- Date: Fri, 30 Nov 2007 17:07:58 -0800
- To: "Manger, James H" <James.H.Manger@team.telstra.com>
- CC: URI <uri@w3.org>
Manger, James H wrote: > Suggested changes to draft-gregorio-uritemplate-02.txt > > §3, 1st sentence: Allow a template to have no expansions (ie just be a URI). > < “contains one or more embedded template expansions” >> “contains any number of embedded template expansions” > I see no harm in this. A URI template is just a listing of literal strings and attribute references. It should not matter how many of each there are, the processing model remains the same. > §3.1: Values of variables should not be restricted. They should just be escaped when building the URI. The simplest model is to say each variable value is a list of (Unicode) strings. An empty list is treated as if the variable was undefined. I think I agree with this. Defining every replacement value as a list does not cause any significant additional complexity and avoids having to treat each replacement separately. I mentioned in another note that it can also be used to eliminate the listjoin operation completely. a = ["1","2"] b = ["3"] c = ["4","5","6"] d = ["7","8"] e = ["9"] f = ["11","12"] {-prefix|/|a}{-prefix|/|b}{-prefix|/|c}{-opt|?|d,e}{-join|&|d,e}{-opt|#|f}{f} Expands to: /1/2/3/4/5/6?d=6&d=7&d=8#1112 The current alternative using listjoin and non-list values for prefix would be: {-opt|/|a}{-listjoin|/|a}{-prefix|/|b}{-opt|/|c}{-listjoin|c|}{-opt|?|d,e}{-join|&|d,e}{-opt|#|f}{-listjoin||f} Which is quite a bit more complex and significantly less intuitive > [snip] > §3.4: A zero-length string should be a legitimate value. It should not be treated as undefined. It is not necessary to make a zero-length string a special case. Perhaps a user interface might translate an empty text input box into an undefined variable, instead of a zero-length string, but the URI template processor API should not force that arrangement. +1. Zero-length is not the same as undefined. > More importantly, we need easy support for query parameters where the query name does not match the variable name. We need easy support for the leading '?' or '&'. Just for comparison sake, here's how it would look with the current approach... /foo{-opt|?|b,d}{-prefix|a=|b}{-opt|&|b,d}{-prefix|c=|d} - James
Received on Saturday, 1 December 2007 01:08:10 UTC