- From: Dr R. Sanderson <azaroth@liverpool.ac.uk>
- Date: Sun, 6 Jan 2008 22:37:42 +0000 (GMT)
- To: Mike Schinkel <mikeschinkel@gmail.com>
- cc: uri@w3.org
On Fri, 4 Jan 2008, Mike Schinkel wrote:
> Rob Sanderson wrote:
>> 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}{®ion=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?
No no, I'm saying that this is fine in this more compressed form, but
would be unusably unwieldy if you had to spell out all of the &s with
-opt as per Joe's current draft. Especially with the (IMO ver valid)
criticism that you need to have all of the following optional variable
names for each &.
>>>> 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.
>> 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.
Yes.
For example using javascript to rewrite a standard template before
sending based on form params?
Rob
Received on Sunday, 6 January 2008 22:38:02 UTC