Re: URI Template experience

Hi Aristotle,

The complexity is only an issue while there is a lack of good library
implementations across languages.  I'm happy that Ruby has a really good one
(in addressable); I suspect that what's holding others back (it had that
effect on me for a while) is the uncertain status of URI Templates as a
standard.

As I said in my earlier post, the prefix and join operators are useful, but
that's not so say that the syntax couldn't be improved - in fact I once
bemoaned the inability to distinguish mandatory parameters, though the
prefix operator kinda means the latter to me now.  That said, a change of
syntax would for me mean merely plugging in an alternate or upgraded
library; I suggest that this is what we all need to be aiming for.
Encapsulate!

Regards,
Mike
mjb@asplake.co.uk
http://positiveincline.com
http://twitter.com/asplake


2009/5/19 Aristotle Pagaltzis <pagaltzis@gmx.de>

> Hi Joe,
>
> I always thought the proposed syntax was too complex: it caters
> to very unlikely use cases at the cost of high cognitive overhead
> in common ones. I suspect this is the reason that the more
> powerful features have not seen any adoption.
>
> So I signed up to propose a much simplified syntax, but I see Roy
> had previously already made much the same proposal in
> http://www.w3.org/mid/07109D44-233D-42F3-ACB0-56B4A6562903@gbiv.com
>
> I had in mind some further simplifications, though. Mainly, I
> would like the output of expansions to be more invariant so that
> it’s easier to use mixed static and interpolated query strings.
>
> Specifically, I would suggest the same syntax as Roy, but with an
> expansion operator `&` instead of `?`, which never produces a
> leading question mark itself. Then I would declare bare `?`, `&`,
> and `;` (outside of expansions) primary operators (like `{}`),
> whose trivial effect is to output themselves – unless they’d end
> up as the last character in the expanded URI, in which case they
> produce *no* output. (Of course if several such optional
> characters bunch up at the end, they’re *all* dropped.)
>
> So a template for a typical query URI would be written something
> like
>
>    /articles?{&tag,per_page,q}
>
> which would just Do The Right Thing. If needs later changed and
> you wanted to include a static parameter, it might become eg.
>
>    /articles?style=summary&{&tag,per_page,q}
>
> and would still DTRT.
>
> I find that having those URI meta characters be look like part of
> the static template makes for a more readable syntax, and in this
> way the writer also doesn’t need to pay such close attention to
> the ordering of components in a template while the implementation
> can provide this flexibility with very little conditional logic.
>
> While this proposal means a small increase in conceptual
> entities, I believe the result significantly benefits both
> language implementors and language users. If you were to try
> to cram these smarts into the expansion operators, the
> implementation would have to keep track of the same state to
> implement them as in my proposal, but it would be much trickier
> to get right, and template writers would still be forced to pay
> attention to the ordering of static parts vs expansions.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>
>
>