- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 2 Aug 2007 01:14:17 +0200
- To: Mike Schinkel <mikeschinkel@gmail.com>
- Cc: <uri@w3.org>
Am 01.08.2007 um 21:27 schrieb Mike Schinkel: > Stefan Eissing wrote: >> [...]The question remains how to best address this. When this was >> discussed initially, there had been lots of proposals for >> "operators", each with good arguments and use case. But how >> much of it needs to be part of the spec? > > I guess that begs a broader question, that being "Why do we create > specs, > anyway?" It's my understanding that we do so to encourage and > streamline > interoperability and to empower the creation of new value from > those systems > that leverage the specs. > > In that context then concepts that have a high level of > applicability to > common use cases definitely need to be in the spec. Optional > arguments are > hardly an esoteric need. It was not my intention to say that optional params are esoteric or that the use case is not a valid one. What I tried to do (and failed) was to point to a way to bring the current spec and your use case together with only minimal change to the spec. > sake, even if that may not be the case. If you have valid reasons, > and I'm > sure you do, it would help if you could explain why you think > something > shouldn't be part of a spec rather than simply say it shouldn't be, > as you > did in the example above. As I understood it, there were two cases where empty/missing parameters should require special handling: 1. params in the path, e.g. /xxx/{foo?}/yyy 2. params in the query, e.g. /xxx?foo={foo?} Case 1, i thought, could be handled by path normalisation. Turns out that uri path normalisation does not work that way. So my idea there is moot. For Case 2, I did not see the value of those template definitions. Instead of dismissing the idea, I should try to understand more your view on this. So: What is the benefit of such query termplates? Do you want to be able to take a template and generate a form for it? Then all parameters would need to be explicitly named in the template. This would make sense for me. Please elaborate a bit more on the use case. > But that begs a broad question; *should* they be inserted as is? The > outcome is less deterministic in that it allows URLs to be created > which are > not obvious at the onset. Is that good? Would that not be better to > handle > expansion of the URL in the application rather than via the value of a > template variable? What would be the use case for this? Maybe Mark can sum it up better. As I remember things, there initially was talk about defining more elaborate escaping rules. Turned out rather quickly that for every sophisticated rule, there was a use case which would not work with it. Things like: http://www.example.com/{param}/ with param=foo/bar should it be http://www.example.com/foo/bar/ or http://www.example.com/foo%2fbar/ So the spec went for the minimal escaping rules and left everything else up to the application. That was the idea as far as I understand. Of course, what you name the "atomic nature" of a template is not possible with that and out-of-band information is needed. I hope this explains things bit. Maybe you can convince the spec authors to revert that decision. (Update: just before hitting "send" I see that Roy is proposing the full-fledged version. Maybe it's just a question of organizing the work...) -- Stefan Eissing <green/>bytes GmbH Hafenweg 16 D-48155 Münster Germany Amtsgericht Münster: HRB5782
Received on Wednesday, 1 August 2007 23:15:08 UTC