Re: draft-gregorio-uritemplate-02.txt

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.


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

Received on Friday, 4 January 2008 05:36:36 UTC