URI Templates - ORing variables, literals, and meta variables?

Hi all:	

As I've been trying to work through some use cases for URI Template I've
found some other functionality that I could really use:

1.) ORing variables:

I've found numerous cases where I would like to be able to specify that a
template where there is a placeholder for multiple values, i.e.

	http://example,com/{foo|bar}/

2.) This of course begs the need for Literals:

	http://example,com/{foo|bar|'baz'}/

Actually, the use cases where I've envisioned need for this is when using
the URI templates for specifying a fragement, i.e:

	http://example,com/#{foo|bar}

For example, if I wanted to have a page on a homebuilder's showing one of
the plans he can build. The plan page would have a floorplan, an elevation,
photos of an example unit, and a list of homes currently available for that
plan. Here is a URL template that allows for fragments IDs for each of those
sections of the page and for each available home:

	
http://example,com/plans/empire/#{'floorplan'|'elevation'|'photos',available
-id}

This would be especially useful for RDF...

3.) The other use-case of concern is when there are numerous templates with
a lot of similar groups of parameters. Consider a set of URLs for a new
article website where many different URL templates could be filtered by
volume, author, and section:

	params: volume={volume?}&author=(author?}&section=(section?}

So here are some hypothetical URLs that could benefit from this meta
functionality, where the resource would be assumed to return a list of
matching articles:

	http://example,com/?{{params}}
	http://example,com/2007/?{{params}}
	http://example,com/2007/07/?{{params}}
	http://example,com/volumes/?{{params}}

Of course to avoid violating URL opacity and REST's hypermedia constraint
both the URL template and the variable assignment would need to be "seen" by
any clients that would process them as this meta functionality implies a
relationship between the template and the variable. Of course this third
requirement is greater in scope than #1 and #2, but might be something to
consider for a v2 of the spec after we get some more real world experience
with implementation.

However, I think #1 and #2 (as well as optional parameters) are very useful
and should be seriously considered before any draft becomes a standard.

-- 
-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 09:28:12 UTC