RE: draft-gregorio-uritemplate-02.txt

Rob Sanderson wrote:
> As per documentation at:
> 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'm not sure I follow your point; are you saying that that URI is unwieldy
because it's long, or something else?   

If the former, wouldn't the unwieldy part be the URL that has so many
parameters?  How would you make a URL with so many parameters less unwieldy?
Lipstick on a pig doesn't make it pretty.

BTW, using the same syntax you could instead do the following making it more
wieldy (is there such a word?):{svc}/V{ver}/{op}? appid={app}&query={q}

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

I agree here.  For example, if URI Templates were to be used for FORM
@actions then requiring the form variables to match the param names would be
too strict a requirement, IMO, and I can envision many similar use cases.

-Mike Schinkel 

Received on Friday, 4 January 2008 22:49:01 UTC