W3C home > Mailing lists > Public > uri@w3.org > May 2009

Re: URI Template experience

From: Aristotle Pagaltzis <pagaltzis@gmx.de>
Date: Tue, 19 May 2009 10:57:38 +0200
To: URI <uri@w3.org>
Message-ID: <20090519085738.GA31895@klangraum.plasmasturm.org>
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/>
Received on Tuesday, 19 May 2009 10:20:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:42 GMT