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