RE: URI Templates - optional variables?

Stefan Eissing wrote:
> So Mike's request to have a way to map to outcome B.) is not 
> solved by path normalization. Since both 
> "http://www.example.com/" and "http://www.example.com//" are 
> valid URIs and not equivalent under any definition, it needs 
> an extra modifier like the '?' to express the difference to a 
> template parser.
> 
> 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.

> Well, well. With due respect: you experience that a lot?

Yes, sadly I do experience that I lot. It becomes infuriating when it seems
the person who is arguing with me seems to be doing it only for argument
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.

> > According to the spec as written, the equal sign would need 
> > to be URL encoded so your suggestion of putting many 
> > parameters into one variable won't work.  And I think they 
> > made a really good call on that; it really simplifies the 
> > spec and makes it very deterministic.
> 
> I am all for deterministic, always and under any circumstance.
> 
> However, I dare to say that your reading of the spec is 
> wrong. The "=" would *not* need to be encoded.
> 
> <quote>
> During substitution, the string value of a template variable 
> MUST have any characters that do not match the reserved or 
> unreserved rules (i.e., those characters not legal in URIs 
> without percent
> encoding) percent-encoded, as per [RFC3986], section 2.1.
> </quote>
> 
> "=" is a reserved char in 3986, section 2.2.

I did misread the spec. I apologize. Actually, I misread the intention of
Mark Nottingham's post [1].

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?

> > [lots of good arguments and examples]
> > If you say that the client can determine that {params} should be 
> > "a=1&b=2&c=3" then you are violating both URI opacity and the 
> > hypermedia constraint of REST. You don't really want to do that, do 
> > you?
> 
> Whoa, that is just BS, pardon me language. Even in your 
> proposed forms example, the forms specification would have to 
> define the (obvious) connection between template parameter 
> name and input field names. It could also define that all non-empty 
> input fields go into the query part of the resulting url.  So 
> this can be solved *outside* the uri template spec.

It is *not* BS, but evidently a difference of opinion. And you obfuscate the
point by bringing up the need for the HTML spec to be updated which I'm
clearly aware of given that I presented a proposal for doing just that.  But
if the URI template can't handle optional parameters then there is no way
for an updated HTML spec to recognize optional parameters in the URI
template!  The HTML spec would have to define it outside of the URI template
spec which would be okay if it were the only use-case for optional
parameters, but it is not. It was just an easy use-case for me to reference
considering I had previously written up the proposal to add URI template
support to HTML forms.

Another use case could be a revision to the sitemap spec where optional
parameters would be defined in the URI template. The URI template defines
the interface to resource request, and the optional nature of parameters are
inexorably bound to the resource. It doesn't make sense to me to define that
information out-of-band. If so, then you loose the elegence of the atomic
nature of the template. It's like the difference between URIs and EPRs.

Speaking of which, if would be really nice if we could define the sources
for the template variables too, such as:

http://example.com/{foo:atom:http://example.net/foo-list/}?bar={bar:rss:http
://example.org/bar-list/}&baz={baz:html/dl:/bar-list/}

But I won't go there. '-)

> I think that my suggestion to use RFC 3986 path resolution on 
> uri template results is a valid proposal. And given the past 
> discussion about zillions of special parameter substitution 
> suggestions, I'd rather have a simple, deterministic uri 
> template spec than the tower of bable rebuild.

Zillions?  I think thou doth overdo, a bit?  I remember only a few. Pre
tell, mind you to recount several which you objected to? 

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
"It never ceases to amaze how many people will proactively debate away
attempts to improve the web..."


[1] http://www.mnot.net/blog/2007/07/28/more_uri_templates

Received on Wednesday, 1 August 2007 19:27:22 UTC