 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|