Re: URI Templates - optional variables?

Am 01.08.2007 um 21:27 schrieb Mike Schinkel:

> Stefan Eissing wrote:
>> [...]The question remains how to best address this. When this was
>> discussed initially, there had been lots of proposals for
>> "operators", each with good arguments and use case. But how
>> much of it needs to be part of the spec?
>
> I guess that begs a broader question, that being "Why do we create  
> specs,
> anyway?"  It's my understanding that we do so to encourage and  
> streamline
> interoperability and to empower the creation of new value from  
> those systems
> that leverage the specs.
>
> In that context then concepts that have a high level of  
> applicability to
> common use cases definitely need to be in the spec.  Optional  
> arguments are
> hardly an esoteric need.

It was not my intention to say that optional params are esoteric or  
that the use case is not a valid one. What I tried to do (and failed)  
was to point to a way to bring the current spec and your use case  
together with only minimal change to the spec.

> sake, even if that may not be the case.  If you have valid reasons,  
> and I'm
> sure you do, it would help if you could explain why you think  
> something
> shouldn't be part of a spec rather than simply say it shouldn't be,  
> as you
> did in the example above.

As I understood it, there were two cases where empty/missing  
parameters should require special handling:

1. params in the path, e.g. /xxx/{foo?}/yyy
2. params in the query, e.g. /xxx?foo={foo?}

Case 1, i thought, could be handled by path normalisation. Turns out  
that uri path normalisation does not work that way. So my idea there  
is moot.

For Case 2, I did not see the value of those template definitions.  
Instead of dismissing the idea, I should try to understand more your  
view on this. So:

What is the benefit of such query termplates? Do you want to be able  
to take a template and generate a form for it? Then all parameters  
would need to be explicitly named in the template. This would make  
sense for me. Please elaborate a bit more on the use case.

> But that begs a broad question; *should* they be inserted as is?  The
> outcome is less deterministic in that it allows URLs to be created  
> which are
> not obvious at the onset. Is that good? Would that not be better to  
> handle
> expansion of the URL in the application rather than via the value of a
> template variable? What would be the use case for this?

Maybe Mark can sum it up better. As I remember things, there  
initially was talk about defining more elaborate escaping rules.  
Turned out rather quickly that for every sophisticated rule, there  
was a use case which would not work with it. Things like:

http://www.example.com/{param}/ with param=foo/bar

should it be http://www.example.com/foo/bar/
or http://www.example.com/foo%2fbar/

So the spec went for the minimal escaping rules and left everything  
else up to the application. That was the idea as far as I understand.  
Of course, what you name the "atomic nature" of a template is not  
possible with that and out-of-band information is needed.

I hope this explains things bit. Maybe you can convince the spec  
authors to revert that decision.

(Update: just before hitting "send" I see that Roy is proposing the  
full-fledged version. Maybe it's just a question of organizing the  
work...)

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

Received on Wednesday, 1 August 2007 23:15:08 UTC