- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Wed, 15 Nov 2006 11:57:09 -0500
- To: eric@bisonsystems.net
- Cc: uri@w3.org, Mark Nottingham <mnot@mnot.net>
- Message-id: <D874F837-116B-4636-BD48-EB1CA64FA851@Sun.COM>
Another possibility would be to use WADL[1] which allows you to add additional metadata to template variables. E.g. <resources base="http://example.com/"> <resource path="{feedID}/{startPage}"> <param style="template" name="feedID" required="true"/> <param style="template" name="startPage" required="false" type="xsd:int"/> ... </resource> </resources> You can also annotate elements of the description with textual descriptions and use XSLT to generate documentation, Mark has a good example of doing this[2]. Marc. [1] http://wadl.dev.java.net/#spec [2] http://www.mnot.net/webdesc/ On Nov 15, 2006, at 11:16 AM, Mark Nottingham wrote: > > Hi Eric, > > This kind of convention isn't actually used in template processing; > it's more in line with a "URI Schema Language." I.e., to a template > processor, the template below has a variable "startPage?" (note the > question mark's inclusion), and if there's a variable with that > name, it'll get interpolated; if not, it won't. The same behaviour > would be seen from a template named "foo", "bar" or anything else; > it's all opaque to a generic URI template processor. > > This leaves at least two paths forward for your use case; > > 1) Define the optionality in prose; e.g., > > ---8<--- > Eric's Foo Template Specification > > Eric's Foo Template is a URI Template [reference] in the following > form: > > http://example.com/{feedID}/{startPage} > > When processing a Foo template, the following variables can be > present; > * startPage: This variable indicates what page to start at; and > is optional. Its content must be an integer. > * feedID: The thing variable indicates the thing to get, and is > required. Its content must be a token. > --->8--- > > This approach pushes the information about the optionality of the > variable to its definition; as you can see, you can also put type > information, etc. there. > > 2) Define a convention for templates. > > When we were working on the URI Templates spec, we wanted to keep > it as simple as possible, but also recognised that there would be > cases where it's useful to have conventions for variable naming to > handle cases like this. If you went this route, you or someone > would need to define such a convention, which might look something > like; > > ---8<--- > Optional Template Convention > > When a URI template variable explicitly references this convention, > it will be considered optional if the last character of the > variable name is a question mark ("?"). If the last character is > not a question mark, the variable is required; i.e., it MUST be > replaced with a non-empty value during template processing. > --->8--- > > Then, your spec would look something like: > > ---8<--- > Eric's Foo Template Specification > > Eric's Foo Template is a URI Template [reference]. All variables > use the Optional Template Convention [reference]. It is in the > following form: > > http://example.com/{feedID}/{startPage?} > > When processing a Foo template, the following variables can be > present; > * startPage: This variable indicates what page to start at. Its > content must be an integer. > * feedID: The thing variable indicates the thing to get. Its > content must be a token. > --->8--- > > By using conventions, we don't constrain the syntax of every > variable; there are enough special cases out there that it would > quickly make using (and implementing) templates unwieldy. > > Make sense? > > > > > On 2006/11/14, at 11:09 PM, Eric J. Bowman wrote: > >> >> I was wondering what peoples' thoughts are about making template >> segments >> optional by ending the variable name with a "?", as defined in >> OpenSearch >> 1.1. Here's their example: >> >> "http://example.com/feed/{startPage?}" >> >> http://www.opensearch.org/Specifications/OpenSearch/ >> 1.1#OpenSearch_URL_template_syntax >> >> -Eric >> >> >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > --- Marc Hadley <marc.hadley at sun.com> CTO Office, Sun Microsystems.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Wednesday, 15 November 2006 19:59:35 UTC