W3C home > Mailing lists > Public > uri@w3.org > January 2008

Re: draft-gregorio-uritemplate-02.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 4 Jan 2008 16:36:26 +1100
Cc: "URI" <uri@w3.org>
Message-Id: <B661B807-015C-4D19-A7C4-A2EAAEB2BAD7@mnot.net>
To: "Manger, James H" <James.H.Manger@team.telstra.com>


I think we're making forward progress. A few thoughts below;


On 27/11/2007, at 1:25 PM, Manger, James H wrote:

> 3.1: Values of variables should not be restricted. They should just  
> be escaped when building the URI.

I agree, and the current text can be read both ways WRT whose  
responsibility it is to encode the text.

> 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.

Not sure I'm with you here.

> I don't think it is worth supporting percent-encoded binary blobs.

I think I agree. If people are serious about binary, base64 or similar  
is more likely...


> 3.4: &{-join|&|foo} -> & produces a poor URI. It has an unwanted  
> & at the end. This points to a limitation of the syntax.
>
> I still prefer my { prefix ^ var * separator ^ suffix | default }  
> syntax, with shortcuts. The examples from the document are rewritten  
> in this syntax below (after the original). Only #8 cannot be  
> expressed, but I don't think that is a problem as it is a very  
> contrived example. I think mine are more readable, particularly for  
> query parameters.

I like Joe's syntax, with the exception that having a few special  
operators for extremely common cases is necessary, I think.

E.g.,

http://www.example.com/foo{?arg1&arg2=default&arg3}
http://www.example.com/bar{;baz;bat=default}

This is much more readable and can be written to produce the right  
URIs (the above is just an example; I could see making it {? 
arg1,arg2,arg3} for a bit more compatibility with the current syntax).


> More importantly, we need easy support for query parameters where  
> the query name does not match the variable name.

Not sure I agree here; if we're going to add a layer of abstraction,  
let's have a good reason for it.

> In my syntax:
> 0  /find{?q=searchTerm}{&p=page}{&lang=}
> I think it is pretty obvious (even if you don't know my syntax) to  
> recognise the URIs this template can produce.

Is it desireable for the arguments to have a fixed order?


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 4 January 2008 05:36:36 GMT

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