RE: host-meta: template syntax hassles

["Manger, James H" <James.H.Manger at team.telstra.com>]

> the currently proposed template vocabulary..
> should be made even less expressive (only define 'uri')

I (somewhat reluctantly) agree, as long as the '+' operator (don't %-escape reserved chars) is removed as well.

A decent aim is to support just the simplest case now (eg <URITemplate>http://example.com/meta?u={uri}</URITemplate>), and try to be compatible with a future fully-developed URI template spec. The behaviour with unrecognised variables, and unexpected syntax is more important than the list of variables defined.

The '+' operator should NOT be defined in hostmeta (if the only variable is 'uri'). It is not necessary for the simplest case. I don't think it can be used safely with the 'uri' variable. A template like "{+uri};by" almost looks sensible, but it isn't. The ";by" suffix may be appended to the path (if there are no query params), to the last query parameter value, to the top-level domain (if the path is empty) etc.

hostmeta-02 says to ignore <Link>s containing templates with unrecognised variables, eg {blurg}. A future template spec is more likely to say to substitute an empty string "" in this situation.
Ignoring <Link>s with unrecognised variables is ok in host-meta, though just giving them a lower priority than <Link>s with known variables may be better (substituting an empty string for the unrecognised variables). Priorities add a bit more complexity, and you can have any number of <Link>s with a given relation in host-meta, so I ignoring the whole <Link> is ok.

hostmeta-02 says to ignore <Link>s containing templates with an unexpected syntax (ie containing chars not allowed in a variable name, eg {/blurg}). I agree with this (it is unclear what a future template spec will say in this case). Since I think the '+' operator does not need to be defined at this point, any link with {+uri} would also be ignored.


James Manger