- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 26 Feb 2010 18:22:56 -0800
- To: mjb@asplake.co.uk
- Cc: URI <uri@w3.org>
On Feb 25, 2010, at 11:53 PM, Mike Burrows wrote: > Um, don't the values come from the client? As the spec stands the client has no clue about which variables are mandatory and which are optional. To be honest though, I can live without this as I already hold externally the information on whether variables are mandatory or optional. I won't mention it again, but it does still seem to me sensible change to make though. The client can't invent values out of thin air, or at least if they do so then the only way to know what the result should be is to check with the server. The context of use (e.g, WADL) can also limit them to specific valid values or define the value constraints (like variable types) for the client to check. In general, there are no mandatory variables because there are no invalid IRI references (unless the server says so). E.g., the path//path examples you gave are not inherently invalid even if this template says they are not, since there is no guarantee that the template reflects all valid names within that server space. > Sorry, one last thing. Not that I have a use case for reserved expansion, but should it allow {var,+hello}, i.e it works as a per-variable modifier? Achieving reliable comma-separation in the presence of optional variables would be difficult otherwise. I would think that the way to achieve reliable comma separation is to not allow commas in the values when using reserved substitution, since that can be enforced by whatever is providing the values. > And it is understood that there are significant limits to what default values could be specified for reserved expansion (I assume they're allowed, though there are no examples)? Reserved characters are not currently allowed in defaults, though I was tempted to allow '=' for the empty keys case. Perhaps we could make an unrestricted default for use only within reserved expansions, but that would make the grammar ambiguous. I think the reason we are avoiding reserved insertion is because almost everyone does it wrong if given the chance. The only use cases I know of where it works well, and is really necessary, are for the beginning of a reference (for substituting a base URI to make all references absolute) and at the end of a reference (for passing another URI at the path end or within a query). I don't know of any other common use cases that aren't already handled by the various operator delimiters. Let me know if you think of one. ....Roy
Received on Saturday, 27 February 2010 02:23:25 UTC