Re: Uri Templates: Questions on draft-gregorio-uritemplate-06

On 09-09-11 22:29, Roy T. Fielding wrote:
> On Sep 8, 2011, at 11:34 PM, Marc Portier wrote:
>> Can't say I have a problem with it, but surely the current approach has a very logic reason of existence, no?
>
> The original was a bit of a coin toss.  Although it looks more consistent with
> forms syntax to do
>
>> {?list}    ?list=red,green,blue'
>> {?list*}   ?list=green&list=red&list=blue
>
> the reality is that most forms-processing libraries assume that
> the names are unique.  They are usually processed as an associative
> array or hash, so what happens is that the last parameter named
> "list" wins.  That's why my first try at this pattern appended
> a number to the subsequent names.
>

Which I think is a neat idea in fact.  I don't want to rewind all done 
work, but is there any history on why it was dropped?

> At this point, I am just going to say that if an application
> actually wants the above, then it should supply an associative
> array itself and not rely on funky list magic.  Also, someone

hm,

I understand (and agree on) what you say about the list magic, but I'm 
underwhelmed at yet another push off to context-values-pre-processing 
(as we had with the defaults)

In general terms it feels like the slippery slope from effectiveness 
versus efficiency (As a wise man once told me: "In your strive for 
efficiency you should watch out not to become ineffective")
Or put bluntly: if all is done in context-pre-processing, then all what 
remains to be done is string-concatenation... (I know I'm stretching it, 
just wanting to make it extreme to get the argument across.)

Might be just me, but I like to think about the 'context' as rather 
close to a business object in an application.  The more we need to tweak 
it before being 'useable' in uri-templates, the lesser value remains to 
using the uri-templates, no?

> else requested the ability to define query parameters without
> any =value, as in
>
>     foo?a=c&d
>
> which is possible (in the editor's draft) if we have
>
>     a := "c"
>     b := [ "d" ]
>

Which triggers Tom's remark about the 'type' of value driving the naming 
or not, rather then the template declaring it.

>     {?a,b}
>

and adding e:= [('f','g')]
then (surprisingly?) explodes {?a,b,e} to ?a=c&d&f=g

>> So why not think about having both just more explicit by declaring two kinds of 'explodes' one 'named' (*), the other 'unnamed' (% maybe?)
>
> Modifiers like explode effectively double the complexity of expansion,
> so I am reticent to add any more unless there is a proven need.
>

Ok, I buy that.

But.
I don't think I was adding an aspect to what uri-templates is trying to 
do: Deciding between 'named' versus 'unnamed' is already in there, some 
of it rather implicit, but still.


Dunno if below helps, if not just ignore, I know I have a natural reflex 
towards consensus, but I do know howto value clear (even limiting) 
decisions.


Taking a step back, maybe we should first agree on the aspects 
uri-templates should cover?  For each part of the uri to be expanded, 
what are the decisions to be taken?
   * what prefix-char to use
     * and should it be present or not if no remainder follows
   * following-join-char to use
     * and should it be used between empty values
   * add or not the context-name as used in the template
     * or silence/drop it, and
     * should that be driven by the types of the context values itself?
   * add or not a member name
     (like the dropped sequence-number suffix,
      or the associative array explosion where keys are promoted to )
     * in which cases? for which
   * explode arrays and hashmaps to follow up values
   * truncate the value to its first N chars
   * binding char between name and value (=)
     * and if it should be or not present in absence of the value
   * way of encoding (allow reserved or not)
     * for both names and values ?
   * (no longer) provide a default for undefined values

(miss any?)


If I look at my implementation and the suggestion stemming from the 
table in appendix A. Then the current operators are pretty much somewhat 
a short-hand notation, each of them implying some of the above decisions.

Yet with every iteration of those implied decisions there seems to be a 
side stepping up and not finding their use-case or preferred set of 
decisions?

Can/should we silence those discussions by offering an 
explicit/canonical syntax (through a new 'elaborate' operator) that 
allows for a very clear, explicit, unambiguous expression that is 
capable of catching all aspects?


regards,
-marc=

> ....Roy
>
>

Received on Monday, 12 September 2011 14:37:44 UTC