On Fri, Nov 6, 2009 at 1:44 PM, Eran Hammer-Lahav
<eran at hueniverse.com> wrote:
This subject was discussed at length this week at IIW. The strong consensus was that since the currently proposed template vocabulary isn't expressive enough, it should be made even less expressive (only define 'uri') and not more expressive (see one proposal below). The main argument were:
- A future (richer) template syntax will address empty variables and the proper assembling of URI components together. When it becomes available, host-meta could be updated to define the full set of variables to support such common transformations.
- Any vocabulary breaking the context URI into parts will need a complimentary method for applying links to resource subsets (at least based on the URI scheme). For example, it is not likely that a single template (using variables other than 'uri') will be able to properly address both 'http' and 'xmpp' URI transformation.
The second point is the most important in my view since it requires extending the proposed document format to directly support describing subsets of resources. I am more inclined to reduce the vocabulary to a single 'uri' variable than extend both the vocabulary and schema to support richer scheme or pattern specific transformation.
Since host-meta allows protocols to define their own 'rel'-specific template syntax and vocabulary, individual protocols with such needs will still be able to make use of the framework. In addition, servers can always use a simple redirection script to redirect a client to a more complex location than provided by a single 'uri' variable.
Comments?
EHL
> -----Original Message-----
> From: apps-discuss-bounces at ietf.org [mailto:apps-discuss-
> bounces at ietf.org] On Behalf Of Manger, James H
> Sent: Tuesday, October 27, 2009 3:52 PM
> To: apps-discuss at ietf.org
> Subject: RE: host-meta: template syntax hassles
>
> One solution (for simple, but correct, URI templates for common
> situations in host-meta) is to define more variables.
>
> For instance, in addition to 'scheme', 'authority', 'path', 'query'...
> offer the following variables:
>
> 'toDir' — the URI up to, but excluding, the last '/' in the path
> 'afterDir' — the URI from the last segment of the path to the end, excluding the fragment
> 'toExt' — the URI up to, but excluding, the last '.' in the last segment of the path (or to the end of the path if there is no such dot)
> 'toPath' — the URI up to the end of the path
> 'afterPath' — the URI from after the path to the end, excluding the fragment
> 'toQueryPlus' — the URI excluding any fragment, followed by '&' if there is a query string or '?' otherwise (ie ready for a new query parameter to be appended)
> 'beforeHost' — the URI up to, but excluding, the host
> 'fromHost' — the URI from the host to the end, excluding the fragment
>
> Template examples:
> {+toExt}.xrd{+afterPath} — replace, say, .html extension with .xrd to get metadata
> {+toQueryPlus}_=meta — add a query parameter named “_” with a value “meta” to get metadata
> {+toDir}/.meta/{+afterDir} — metadata is in a special .meta/ subdirectory of each directory
> {+toPath};meta{+afterPath} — append “;meta” to the path to get the metadata
> {+beforeHost}meta.{+fromHost} —metadata is hosted on a sub-domain
>
> The to/after (and before/from) pairs basically offer easy access to
> different points in the URI to insert a new element. I think these
> examples are fairly simple ways to implement common URI manipulations
> safely.
>
> James Manger
> James.H.Manger at team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
