W3C home > Mailing lists > Public > uri@w3.org > August 2007

RE: URI Templates - optional variables?

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Wed, 1 Aug 2007 04:58:43 -0400
To: "'Stefan Eissing'" <stefan.eissing@greenbytes.de>
Cc: <uri@w3.org>
Message-ID: <006a01c7d41a$29cce300$2102fea9@Guides.local>

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

	<input type="text" name="genre" />
	<input type="text" name="artist" />
	<input type="submit" />

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


WITH optional parameters, things are a lot cleaner:


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:

		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


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

[2] http://en.wikipedia.org/wiki/OpenURL
Received on Wednesday, 1 August 2007 08:58:48 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:49 UTC