- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 8 Oct 2006 22:12:21 -0700
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Sam Ruby <rubys@intertwingly.net>, uri@w3.org
I totally agree, and had thought that's where we ended up (we did a lot of last-minute adjustments ;). The template variable name should be able to be a full URI, with the full range of allowable characters available to it. Cheers, On 2006/10/07, at 12:27 PM, Stefan Eissing wrote: > Hi Mark, > > first of all thanks for the detailed explanation. I see now much > better what you have in mind. > > As James already wrote, simplicity (as in usability) is the goal > here and any attempt to fully describe every parameter type and > restrictions (to avoid the s-word) will kill the use of templates > on the spot. > > I still have the nagging feeling that extensions to the template, > as the bash like substitutions for defaults that Roy mentioned and/ > or unforeseen others, will one day come in handy when more > experience has been made. > > Currently the templates allow only "unreservered" chars between the > curly braces which works well for parameter names. Perhaps an > "escape hatch" would come in handy so the production could look > like this: > > template-char = unreserved > template-name = 1*template-char > ext_char = unreserved / gen-delims / sub-delims > template-var = "{" template-name [ ":" 1*ext_char ] "}" > > and uri templates would require any implementation to ignore > extensions they do not recognize (so all for now). (using ":" as > separator was just the first thing that came to mind, any not- > unreserved (ha!) uri char would do. Using just a single one makes > implementation easy.) > > Cheers, > > Stefan > > Am 07.10.2006 um 16:46 schrieb Mark Nottingham: > >> >> 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/ >> >> > -- Mark Nottingham http://www.mnot.net/
Received on Monday, 9 October 2006 05:12:35 UTC