RE: host-meta: template syntax hassles

[Eran Hammer-Lahav <eran at hueniverse.com>]

I agree. I will remove the '+' operator in the next draft.

EHL

> -----Original Message-----
> From: apps-discuss-bounces at ietf.org [mailto:apps-discuss-
> bounces at ietf.org] On Behalf Of Manger, James H
> Sent: Sunday, November 08, 2009 6:27 PM
> To: apps-discuss at ietf.org
> Cc: webfinger at googlegroups.com
> Subject: RE: host-meta: template syntax hassles
> 
> > 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
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss at ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss