- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 7 Oct 2006 07:46:37 -0700
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Sam Ruby <rubys@intertwingly.net>, uri@w3.org
Hi Stefan, One of the things we found when talking through URI templates is that there are a a *wide* variety of use cases for annotations, conventions, etc. in template variables; e.g., whether to percent- encode, whether something is optional, constraints on the value space, whether to include the variable name in a query arg, etc. So, whatever convention you use here, it needs to be extensible. Additionally, template variable names themselves have a pretty wide range; e.g., if Semantic Web folks start to like them, they'll probably want to use a URI as a template variable name (and this might be a good idea in other situations too...). This leads to a requirement that any such conventions that are built into URI Templates itself, and not dependent on context, needs to be very distinct from the variable name. At best, I think something like this would work: http://example.com/{path<a>}/{b}?{query<c>} with a convention for naming the "functions" similar to that for Atom link relations (a registry or use a full URI for a non-registered value). However, that makes one of the big use cases -- human-readable docs -- more unlikely. Ideally, you should be able to drop URI Templates directly into developer docs (like those at developer.yahoo.com, amazon.com/webservices, dev.live.com, code.google.com, etc.), and there's a lot of line noise there. Really, this is walking down the path of designing an in-template schema language, which IMO is a *huge* rat-hole. I appreciate the attraction of putting the datatype in the template, but consider the situation if you leave it outside. Every use of URI Templates is going to have to define the semantics and processing of each variable name somewhere else anyway; they'll have to say "'a' is the username, and should be at most 8 characters long...". Since there needs to be external information like this anyway, putting the encoding information there as well is the simplest, most flexible approach that hits the 80% case. If we want percent-encoding and input hints are unattractive, I'd rather force the processor to do the right thing and automatically encode based on where the variable is in the URI. I think it would still be good to have an input-hint-shaped escape hatch then, but that can be implementation-specific. Cheers, On 2006/10/07, at 2:45 AM, Stefan Eissing wrote: > > It seems to me that the data type of uri templates parameter would > be part of the template and not part of the input. The one > designing the template should know what goes where? > > Am 07.10.2006 um 05:39 schrieb Mark Nottingham: > >> Actually, by putting what's effectively an encoding type in the >> input data structure, we *can* have both; >> >> { >> 'a': ('foo/bar', PATH_SEGMENT), >> 'b': ('foo/bar', NULL), >> 'c': ('foo/bar', QUERY_STRING), >> } >> http://example.com/{a}/{b}?{c} --> http://example.com/foo%2f/foo/ >> bar?foo/bar >> > > here you declare how the input shall be treated as attribute of the > input. What about this: > > ('foo/bar', 'foo/bar', 'foo/bar') > > http://example.com/{1ps}/{2}?{3q} --> http://example.com/foo%2f/ > foo/bar?foo/bar > > n - substitue n-th parameter unchanged > np - substitue n-th with uri escaping to make a valid path > nps - substitue n-th with uri escaping to make a valid path segment > nq - substitue n-th with uri escaping to make a valid query > > Instead of positional, numbered parameters, one can apply the same > to named parameters, as in > > http://example.com/{ps(a)}/{b}?{q(c)} > > Cheers, > > Stefan > -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 7 October 2006 14:47:00 UTC