W3C home > Mailing lists > Public > uri@w3.org > October 2006

Re: Feedback on draft-gregorio-uritemplate-00

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 05 Oct 2006 14:24:53 -0400
Message-ID: <45254DF5.7030200@intertwingly.net>
To: James M Snell <jasnell@gmail.com>
CC: uri@w3.org

James M Snell wrote:
> The underlying question is whether the the template processor is
> responsible for performing the escaping or whether the application
> providing the values is responsible.
> The difference ends up being very important. In the current draft, a
> replacement value can span multiple segments. i.e.,
>   http://example.org/{foo}
> could expand to:
>   http://example.org/jasnell/2006/10?foo#bar

First, like Julian, I see conflicting text in the spec on this.  In 

     If the value of a template variable would conflict with a reserved
     character's purpose as a delimiter, then the conflicting data must be
     percent-encoded before substitution.

Second, how important is that requirement?

I agree with Julian:

> In general, people frequently get URI/IRI encoding wrong, so being strict here makes a lot of sense. 

What this ultimately comes down to is the following: what does "string 
value" mean in the following:

     Evaluating a URI Template consists of replacing each occurrence of a
     template variable with the string value of that variable.

Does it mean a sequence of octets?  Or a sequence of ISO/IEC 10646 

Those of you (<grin>) who program in Java would probably find it easier 
to deal with if this were mapped to java.lang.String.

My vote: specify unicode and utf-8 throughout.  And ditch the perceived 
requirement to allow template variables to optionally span multiple 
segments, depending on the data values allowed.

It would be valuable if this specification were accompanied by one or 
more conforming implementations and a small suite of test cases.  I 
would imagine that the Python implementation would make use of urlparse, 
and various values for 'safe' in calls to urllib.quote (or equivalent).

- Sam Ruby
Received on Thursday, 5 October 2006 18:25:08 UTC

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