RE: URI Templates - optional variables?

Stefan Eissing wrote:
> Clearly, such urls are better than the one with all empty params.  
> Perhaps this can be solved outside the spec. Your example:
> 
> http://www.example.com/?a={a}&b={b}&c={c}&d={d}&e={e}&f={f}&g={g}
> 
> could also be transformed to the template
> 
> http://www.example.com/?{params}

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.

Consider the use for URI templates in HTML forms as I proposed in January
[1].  For example (note that I used <input> instead of <select> for
simplicity):

	<form
	action="http://foo.com/?genre={genre?}&artist={artist?}"
	method="get">
	<input type="text" name="genre" />
	<input type="text" name="artist" />
	<input type="submit" />
	</form>

The above works really well with optional parameters but generates ugly URLs
w/o optional variables:

	http://foo.com/?genre=&artist=U2
	http://foo.com/?genre=rock&artist=

WITH optional parameters, things are a lot cleaner:

	http://foo.com/?artist=U2
	http://foo.com/?genre=rock


One use case that exemplifies why optional paramaters would be so useful is
OpenURL [2]. OpenURL can have many URL parameters, some of which are
optional. Here's an example from the OpenURL spec:

	http://www.example.net/menu? 
		url_ver = Z39.88-2004 
		& url_tim = 2002-03-20T08:55:12Z 
		& url_ctx_fmt = info:ofi/fmt:kev:mtx:ctx 
		& rft_id = info:doi/10.1126/science.275.5304.1320  
		& rft_id = info:pmid/9036860  
		& rft_val_fmt = info:ofi/fmt:kev:mtx:journal 
		& rft.jtitle = Science  
		& rft.atitle = Isolation of a common receptor for coxsackie
B viruses and adenoviruses 2 and 5  
		& rft.aulast = Bergelson   
		& rft.auinit = J  
		& rft.date = 1997 
		& rft.volume = 275  
		& rft.spage = 1320 
		& rft.epage = 1323 
		& rfe_id = info:doi/10.1006/mthe.2000.0239 
		& rfr_id = info:sid/elsevier.com:ScienceDirect 
		& req_id = mailto:jane.doe@caltech.edu 
		& ctx_tim = 2002-03-20T08:55:12Z  
		& ctx_enc = info:ofi/enc:UTF-8 

Let's look at it like this: Let's assume you have a URL that can accept 10
parameters, 8 of which were optional. With the spec as it is you would have
to list 36 different URL templates (=8+7+6+5+4+3+2+1) if you wanted to be
able to specify all applicable permutations where the existence of a
variable means it is required. And that assumes that parameter order doesn't
matter.  With the proposal I made all those permutations can be represented
with one URL template (in this case "a" and "j" are required, the rest are
optional):

	
http://www.example.com/?a={a}&b={b?}&c={c?}&d={d?}&e={e?}&f={f?}&g={g?}&h={h
?}&i={i?}&j={j}

> The task to make usage elegant to an application could then 
> be in the uri template resolver code. If you pass a 
> hash/dictionary/map as value for "params", the resolver could 
> build the query parameter itself.

That is directly contrary to one of the rationales for the URI Template
proposal (from [3]):

	Finally, URI Templates can be used to compose URI-centric 
	protocols without impinging on authorities' control of their 
	URIs. For example, there are many emerging conventions 
	for passing around login information between sites using 
	URIs. Forcing people to use a well-known query parameter 
	isn't good practice, but using a URI parameter allows 
	different sites to specify local ways of conveying the 
	same information;

That rationale is exactly the reason why I'm so excited about URI Templates,
but without optional parameters in a manner similar to what I proposed they
utility will have utility in only a much dimished set of use-cases.

It also goes against another of the rationales, though less critically:

	This is useful when it's necessary to convey the structure 
	of a URI in a well-defined way.  For example, documentation 
	of an interface exposed by a Web site might use a template 
	to show people how to find information about a user;

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?

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

P.S. I'm curious as to your objection to my proposal?  I know some people
approach specs with a desire to add tons of features and others approach
them from the perspective of doing their best to block features getting into
a spec, and there are good reasons for both approachs. That said, and I
don't mean to be disrespectful but your objections seems to me to be
objection for objection sake.  Is that a case?

[1]
http://blog.welldesignedurls.org/2007/01/11/proposing-uri-templates-for-webf
orms-2/
[2] http://en.wikipedia.org/wiki/OpenURL
[3]
http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-01.h
tml#rfc.section.1

Received on Wednesday, 1 August 2007 08:58:48 UTC