Re: Feedback on draft-gregorio-uritemplate-00

Stefan Eissing wrote:
> 
> It seems to me that the data type of uri templates parameter would be 
> part of the template and not part of the input. The one designing the 
> template should know what goes where?

Exactly.

To use the popular terms of the day, I'm advocating being opinionated. 
I'm advocating convention over configuration.  Most of all, I'm arguing 
simplicity - where in this case, I'm trying to optimize first for the 
people creating the input data structures (the ones most likely to get 
things wrong), then for the template designers, and finally for the 
people who implement the code that converts templates into URI/IRIs.

I'm claiming that in 99.9999% of the time, one has all the information 
one needs in the template itself:

>> from urlparse import urlparse
>>> urlparse('http://www.example.com/{a}')
('http', 'www.example.com', '/{a}', '', '', '')
>>> urlparse('http://www.example.com/foo?path={a}')
('http', 'www.example.com', '/foo', '', 'path={a}', '')

My feeling is that we should go character by character and decide what 
gets escaped and what does not.  Example rules (the spec should pick one):

  * slashes get escaped everywhere, independent of where they appear
    in the URI
  * slashes get escaped in the (x,y,z) portions of the URI, but not
    in the (a,b,c) portions {where we debate what the appropriate
    values of x, y ,z ,a ,b, and c are.}
  * the last variable in the path is treated special...

Once the basics are nailed down, we can discuss whether there is a need 
for overrides.  If so, it could be described as an optional feature that 
templating implementation can provide.  It wouldn't surprise me if a 
number of templating libraries implemented this, if it were spec'ed. 
For example, I'm sure that James Snell would.

What would surprise me would be to find many who would use such an 
interface in the presence of an alternative which accepts a 
java.util.Map of simple name/value pairs.

- Sam Ruby

Received on Saturday, 7 October 2006 11:46:09 UTC