RE: URI Templates - optional variables?

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.

Accepted. Often the situations is having multiple use cases but not having
the time to explain them all in depth. So I present one and you offer a
workaround but it doesn't necessarily work for the others, which I belatedly
tried to explain.

> > 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?}

There's a 3rd which is a variant of #2:

3.) /xxx?foo={foo?}&bar={bar?}

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

Thanks.  The use case is general. IOW, I'm looking to empower URLs to be
designed as the URI Authority would prefer in whatever contexts where a URI
template could be used instead of having a contrained set of uses that only
apply to a subset of the valid ways in which a URL are typically formed.  So
REST-based hypermedia would be a use case, in whatever hypermedia form the
URL could be presented. This might be HTML forms, or it might be in AtomPub,
or it might be in LINK elements in HTML head, and so on.  But the important
part is to gain control off cleaner URLs for human understandability and
also to minimize the arbitraily different number of URLs, i.e.
http://example.com// vs. http://example.com/ and http://example.com/?foo=
vs. http://example.com/

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

Yes, I remember that.  Question is, do we need to be able to insert a slash
into a URL via a template variable?  I'll turn the tables and ask the
community, what's the use case?  And could it not be better handled with
explicit optional parameters? (that said I can envision it would be useful
in some cases, but ideally we'd have a special syntax for that, maybe:
http://www.example.com/{@param}/ 

> 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 don't follow. Why is out of band info need?  Do you mean to populate the
values of variables?

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

Yes I see, and plan to really read through his proposal.  Thanks for
acknowledging my position. If my prior emails we a bit testy, I apologize.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us

Received on Wednesday, 1 August 2007 23:45:09 UTC