- From: Aristotle Pagaltzis <pagaltzis@gmx.de>
- Date: Tue, 19 May 2009 10:57:38 +0200
- To: URI <uri@w3.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 UTC