- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 11 Aug 2007 14:26:41 +1000
- To: Mike Schinkel <mikeschinkel@gmail.com>
- Cc: <uri@w3.org>
On 11/08/2007, at 1:39 PM, Mike Schinkel wrote: > In the abstract, that sounds incredibly complicated. Well, it's not a simple problem. > Would the method to invoke this convention be inband (inside the > braces) or out of > band (outside the braces, or worse outside the string?) Out of band. See <http://www.w3.org/mid/D9FFFFB6- F734-48BE-9D39-23541A38F844@mnot.net> for an example that might help (indirectly). > Wouldn't it be > easier to simply say something like "If it starts with a single > specific > indicator character (colon, equal sign, other?) (i.e. '{:xxxxxx}', > '{=xxxxxx}') then past that character for formating info, otherwise > not. And > parsers can choose not to support the extension." Or maybe that's > what you > mean? That's the other approach that's being discussed. The problem here is that there's a potentially large set of such transformation functions that you need to identify; I don't have much confidence that we'll be able to identify all of the useful functions in one go. For example, Roy gives a good start, but we'll also need ways to indicate how to handle encoding. And, what if you want to use (for example) a hash-to- query-string mapping as well as a particular style of encoding? As such, I'm suspecting that there'll need to be an answer for extensibility here. That means that we can't enumerate all of the beginning characters that one has to look out for in template variable names; some more general convention is necessary. > That said, I do think you planted a seed for an excellent idea, and > that is > to define a "template variable definition language" that is > separate from > URI Template. That could mean we split the current spec in two and > assign > basic templates as per the 1.1 URI Template spec to be TVDL 1.0 > after which > we can immediately start working on TVDL 1.1. That would certain > follow the > principle of "separation of concerns." If you buy into that, why not put all of this type of metadata (types, optionality, formatting, encoding, etc.) into the variable definition, and leave it out of the variable names altogether? That's my (somewhat weak) preference. -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 11 August 2007 04:26:46 UTC