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

RE: Updated URI Template proposal

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Fri, 9 Nov 2007 10:31:16 +1100
Message-ID: <6215401E01247448A306C54F499111F20374D402@WSMSG2103V.srv.dir.telstra.com>
To: "URI" <uri@w3.org>
{-opt|?|tags,start,count}
This is a crazy way to get a “?” to mark the beginning of the query parameters. It gets worse and worse as more query parameters are defined.
Code that converts a template to a URI can know about URI syntax. It should be able to work out these sort of details itself (eg whether a leading separator should be a “?” or “&”).
It can be quite simple. When processing a “query parameter rule” (somewhat like {-join…}) prepend a “?” if there is no “?” already in the part of the URI that has been built so far (building from left to right), otherwise prepend a “&”.

{-opt|?|tags,start,count}{-listjoin|&tag=|tags}{-opt|&|start,count}{-join|&|start,count}
This is crazy. The “start” variable is included 3 times, just to specify an optional query parameter. Some people want to use URLs as variable names -- repeat a URL 3 times within a URL and image how horrid the template becomes.


Joe’s rules (excluding the new {-sub…}) basically allow a prefix, suffix, separator and default to be specified for a variable replacement -- but not all at once. The {-opt…} and {-neg…} rules work around the "not all at once" limitation.
Another way to work around that limitation is to combine all the aspects (prefix, suffix, separator, and default) into a single syntax. {-opt…} and {-neg…} theoretically allow you to include content that is not adjacent to where the variable value is substituted, but I doubt there is any practical need for that.

The major difference between Joe’s rules and one common rule (eg {prefix|var|sep|suffix|default}) is extensibility. There is an obvious way to add lots of rules like {-sub…} with Joe’s syntax. It is less obvious with one common rule. However, the obvious way to define {-sub…} is not really a good way, as it does not *combine* with the existing rules. For instance, if you want to split a “date” variable into year and month substrings, you cannot then use the {-join…} operator to format them. Its {-sub…} or {-join…}, not both.

Another alternative for substring functionality would be a convention for variable names. For instance, /user/{username.1-2}/{username.2-}. I am not sure if spec should define this, or a convention could emerge.
Received on Thursday, 8 November 2007 23:31:45 GMT

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