Re: draft-gregorio-uritemplate-02.txt

Just to dive in at the deep end, as two of the projects that I
collaborate on are looking seriously at URI templates...

On Fri, 2008-01-04 at 16:36 +1100, Mark Nottingham wrote:

> > §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. 
> 
> I like Joe's syntax, with the exception that having a few special  
> operators for extremely common cases is necessary, I think.

The main issue that I see with the current draft's syntax, as opposed to
the more concise form of Dewitt (plus suggestions made by James) or the
prefix^variable form, is that it becomes extremely unwieldy when applied
to long URIs with many optional variables, as discussed.

For example, the full template for the Yahoo search API is long in the
concise form and Extremely Long in Joe's form with all of the separators
needing to check the existence of so many optional variables.

As per documentation at:
   http://developer.yahoo.com/search/web/V1/webSearch.html

http://search.yahooapis.com/{service}/V{version}/{operation}?
appid={userId}&query={query}{&region=x_region}{&type=queryType}
{&results=count}{&start=startPosition}{&format=q_fileType}
{&adult_ok=q_adultFlag}{&similar_ok=q_similarFlag}{&language=q_lang}
{&country=q_country}{&site=q_website}{&subscription=q_subscription}
{&license=q_license}{&output=format}{&callback=x_callback}

[I leave it up to your imaginations as to the length of the {-opt...}
form!]


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

As you will no doubt note in the above example, I've used some q_foo and
x_bar names.  This is the same as Dewitt's yahoo:appid form, but with a
less XML namespace centric style of x_(param) and q_(queryParam) for
parameters that don't share semantics with other services.

The idea being (as per OpenSearch) to reuse the variables (eg
queryType), but not necessarily the parameter names (eg type, queryType,
qType, qtype, style, method, ...).

I appreciate the desire for ease of distinction between name=variable
and variable=default, however not having the ability to have
name=variable would be a showstopper for our applications, as it would
be for OpenSearch as well, I'm sure.


Rob Sanderson
Dept of Computer Science
University of Liverpool

Received on Friday, 4 January 2008 15:00:39 UTC