- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 15 Oct 2007 21:25:17 -0700
- To: Mark Nottingham <mnot@mnot.net>
- CC: "Roy T. Fielding" <fielding@gbiv.com>, URI <uri@w3.org>, Joe Gregorio <joe@bitworking.org>, Stefan Eissing <stefan.eissing@greenbytes.de>
Mark Nottingham wrote: > [snip] > > WRT "string operations": what about allowing variable values to be lists > of strings? E.g., this seems like it would be useful: > > template: http://example.org/sausage?{,&condiments} > condiments = ["tomato sauce", "chutney", "relish"] > result: > http://example.org/sausage?condiments=tomato%20sauce&condiments=chutney&condiments=relish > > > Otherwise, I've got to define condiment1, condiment2, and so on, or fall > back to simple substitution and build it myself. > Definitely useful, but brings up the question about how the client knows when to use a single value vs. a list. Not a significant issue, but definitely worth considering. > [snip] > So, I think it's worth diving into the encoding issue here again, > because we still haven't quite nailed it. If I use a generic "join" > operator, I can't get anything from reserved into the results -- even a > comma. Also, keep in mind that what needs encoding will be different > based upon where the template is in the URI, so we'll need some level of > flexibility in this. > > There are a lot of different ways we could address this. I'm thinking we > could add an optional argument (e.g., a list of characters not to > encode) to the operators; e.g., > > {,separator|var1,var2,var3,...|no_enc} > > so you might have: > > {,&|name,age,zip,location|,+} = > "name=Fred+Smith&age=41&location=Nowhere,USA" > > Alternatively, we could come up with a list of names for sets of > characters that make sense to not escape in certain contexts. > Hmmm... my first reaction is to this is not positive. I can see what you're trying to achieve, but I'm not sure the added complexity is worth it. Will have to stew on this one. - James
Received on Tuesday, 16 October 2007 04:25:44 UTC