Subject: [apps-discuss] Question about URI template and expansion of an empty list

From: Francis Galiegue <[email-masked]>
Date: Fri, 5 Apr 2013 20:39:54 +0200

Hello,

Let us say that there is a variable called "list", whose value is an empty list:

list = []

Now let us have this template:

X{.list}

Should the expansion be "X" or "X."? And, more importantly, why?

--
Francis Galiegue, [email-masked]
JSON Schema in Java: http://json-schema-validator.herokuapp.com

---

From: Francis Galiegue <[email-masked]>
Date: Sun, 7 Apr 2013 22:38:53 +0200

> Should the expansion be "X" or "X."? And, more importantly, why?

Any insights? I have read the spec by and large (RFC 6570) and still
cannot figure it out...

---

From: Erik Wilde <[email-masked]>
Date: Sun, 07 Apr 2013 22:41:04 -0700

hello francis.

> Any insights? I have read the spec by and large (RFC 6570) and still

https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json 
(line 234) says it's "X", but i am really interested in the "why" 
explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5 
says that "for each defined variable in the variable-list, append '.' to 
the result string and then perform variable expansion", and i cannot 
find any text saying that an empty list is considered to be undefined. i 
have read the spec recently and never looked at this particular case, 
but without looking at the test cases i would have said it has to be 
expanded to "X." and not "X".

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Apr 2013 23:55:26 -0700

I'm inclined to think it's "X." for the same reason "X{.empty}" is "X.",
which is to say that an empty list, like an empty string, isn't undefined,
but there is indeed nothing to expand.

Either way, there may be grounds for an erratum here.  The RFC does talk
about handling empty strings, but not empty lists.  The closest is Section
3.2.1 which talks about "expansion of a defined, non-empty value", meaning
defined, empty values aren't explicitly covered in the prose as far as I
can see.

-MSK

On Sun, Apr 7, 2013 at 10:41 PM, Erik Wilde <[email-masked]> wrote:

> https://github.com/dret/**uritemplate-test/blob/master/**
> spec-examples-by-section.json<https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json>(line 234) says it's "X", but i am really interested in the "why"
> explanation as well. http://tools.ietf.org/html/**rfc6570#section-3.2.5<http://tools.ietf.org/html/rfc6570#section-3.2.5>says that "for each defined variable in the variable-list, append '.' to
> the result string and then perform variable expansion", and i cannot find
> any text saying that an empty list is considered to be undefined. i have
> read the spec recently and never looked at this particular case, but
> without looking at the test cases i would have said it has to be expanded
> to "X." and not "X".
>
> cheers,
>
> dret.
>
> --
> ______________________________**_________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: Francis Galiegue <[email-masked]>
Date: Mon, 8 Apr 2013 14:54:34 +0200

On Mon, Apr 8, 2013 at 8:55 AM, Murray S. Kucherawy <[email-masked]> wrote:
> defined, empty values aren't explicitly covered in the prose as far as I can
> see.
>

Similarly, it doesn't talk about extending empty maps.

---

From: James M Snell <[email-masked]>
Date: Mon, 8 Apr 2013 06:37:37 -0700

Am I missing something subtle about the question? The examples in Section
3.2.5 show "X{.empty_keys}" where empty keys = [], expands to "X". Given
that the list is empty, there's nothing to expand it into.
 On Apr 8, 2013 5:54 AM, "Francis Galiegue" <[email-masked]> wrote:

> can
> _______________________________________________
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Apr 2013 06:53:49 -0700

empty_keys (defined in 3.2) is an empty associative array, not an empty
list.  So we have:

- an undefined value produces "X"
- a defined-but-empty string produces "X."
- a defined-but-empty associative array produces "X"

It's not clear to me that there's a pattern here yielding an obvious answer
for which of the two a defined-but-empty list should produce.

---

From: James M Snell <[email-masked]>
Date: Mon, 8 Apr 2013 07:50:45 -0700

"empty_keys" is not defined explicitly as an empty associative array.
The only definition given for "empty_keys" in section 3.2 is
"empty_keys := []" which is semantically and structurally identical to
an empty list. So to amend your rules, we have:

- an undefined value produces "X"
- a defined-but-empty string produces "X."
- a defined-but-empty list/associative-array produces "X"

- James

---

From: Erik Wilde <[email-masked]>
Date: Mon, 08 Apr 2013 09:02:08 -0700

hello james.

> - a defined-but-empty list/associative-array produces "X"

i agree that since JSON doesn't have associative arrays, [] as a value 
has to be read as just being an empty array/list. but i am still 
wondering about francis' "why" question: if we did not have that test 
case and simply had to reason based on the spec test, how would i end up 
with "X" instead of "X."? when i am just reading the text as somebody 
trying to write code implementing it, i read the spec as telling me "X." 
is what should be the result of expansion.

cheers,

dret.

---

From: Francis Galiegue <[email-masked]>
Date: Mon, 8 Apr 2013 18:30:02 +0200

On Mon, Apr 8, 2013 at 6:02 PM, Erik Wilde <[email-masked]> wrote:
[...]
>
> i agree that since JSON doesn't have associative arrays, [] as a value has
> to be read as just being an empty array/list.

It does have a "limited" form of it, however: consider a JSON object
where member values are primitives, which can be coerced to strings.

> but i am still wondering about
> francis' "why" question: if we did not have that test case and simply had to
> reason based on the spec test, how would i end up with "X" instead of "X."?
> when i am just reading the text as somebody trying to write code
> implementing it, i read the spec as telling me "X." is what should be the
> result of expansion.
>

That was my thought as well. More generally, the text is very complex
to follow :/ I've had the devil's own job trying to figure it out.

---

From: James M Snell <[email-masked]>
Date: Mon, 8 Apr 2013 09:33:44 -0700

I agree that the text in the spec is certainly not clear in this. In
my implementation, I've had to fall back to recreating the behavior
shown in the examples. So to answer the question "why", I just fall
back to my original answer: That's what the example shows.

---

From: Erik Wilde <[email-masked]>
Date: Mon, 08 Apr 2013 09:46:22 -0700

hello james.

> back to my original answer: That's what the example shows.

that raises one of the interesting questions in test-driven development: 
if a test fails and you check and still think that you've implemented 
what the spec text asks you to implement, how do you reconcile? 
special-casing just for tests probably isn't the way to go, so how 
exactly did you tweak the code (or your interpretation of the spec 
resulting in code) to satisfy the test?

i am really interested, because i'll be implementing it as well and i am 
pretty sure that i'll run into the exact same issue.

thanks and cheers,

dret.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Apr 2013 13:40:11 -0700

> - a defined-but-empty list/associative-array produces "X"

Everywhere else in the document refers to a list as (value[, value[,
...]]).  So it seems to me "()" is the empty list, while "[]" is not.

---

From: Francis Galiegue <[email-masked]>
Date: Thu, 11 Apr 2013 15:53:58 +0200

On Mon, Apr 8, 2013 at 10:40 PM, Murray S. Kucherawy
<[email-masked]> wrote:
[...]
>
> Everywhere else in the document refers to a list as (value[, value[, ...]]).
> So it seems to me "()" is the empty list, while "[]" is not.
>

Then what would it be? There is no empty list defined at all in the
RFC examples.

I agree that there should be an errata, defining expansion behaviour
for all of these corner cases. Right now, only the tests at
https://github.com/uri-templates/uritemplate-test make any mention of
it and there seems to be a disagreement on how these should be
handled.

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 16 Apr 2013 00:59:46 +0200

On Thu, Apr 11, 2013 at 3:53 PM, Francis Galiegue <[email-masked]> wrote:
[...]
> it and there seems to be a disagreement on how these should be

Ping?

My opinion is that this is of fundamental importance if RFC 6570 has
to have any impact over already existing uses of "poorer" forms of
this RFC. Right now, the RFC is unambiguous, and more worryingly, I
see no way out of it, since there is no clear, definite answer to my
initial question.

I have a pretty complete RFC 6570 implementation, but these corner
cases are what prevent me from arguing that "yes, it obeys the RFC",
especially since some advanced tests out there seem to disagree with
my, and others', interpretation of this RFC.

Please share your thoughts,
--
Francis Galiegue, [email-masked]
JSON Schema in Java: http://json-schema-validator.herokuapp.com

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 16 Apr 2013 01:05:45 +0200

On Tue, Apr 16, 2013 at 12:59 AM, Francis Galiegue <[email-masked]> wrote:

[...]
> Right now, the RFC is unambiguous

I meant "ambiguous" here, sorry for the confusion.

---

From: Erik Wilde <[email-masked]>
Date: Mon, 15 Apr 2013 16:08:47 -0700

hello.

> my, and others', interpretation of this RFC.

i just want to add my support for francis' question. i am not as far 
down the line implementing the spec, but i see myself asking the same 
question once i am. and i am still interested how james (snell) solved 
this riddle when adding support for the test case (where the test case 
behavior is hard to explain from the spec language).

http://code.google.com/p/uri-templates/wiki/Implementations lists a 
number of implementations, and it would be interesting to know what they 
have been doing, and how they handle the test case in question.

thanks and cheers,

dret.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Apr 2013 16:10:28 -0700

I emailed the authors several days ago.  None replied.

Unless one of our ADs thinks it's a bad idea (and hopefully they're
watching), I would post an erratum.

-MSK

On Mon, Apr 15, 2013 at 4:08 PM, Erik Wilde <[email-masked]> wrote:

> i just want to add my support for francis' question. i am not as far down
> the line implementing the spec, but i see myself asking the same question
> once i am. and i am still interested how james (snell) solved this riddle
> when adding support for the test case (where the test case behavior is hard
> to explain from the spec language).
>
> http://code.google.com/p/uri-**templates/wiki/Implementations<http://code.google.com/p/uri-templates/wiki/Implementations>lists a number of implementations, and it would be interesting to know what
> they have been doing, and how they handle the test case in question.
>
> thanks and cheers,
>
>
> dret.
>
> --

---

From: James M Snell <[email-masked]>
Date: Mon, 15 Apr 2013 21:48:45 -0700

My apologies, I've been tied up in a number of other tasks and forgot
to respond further on this thread. Posting errata for the spec is
likely a good idea. When I implemented this, whenever I came up
against something that was ambiguous, I simply referred to the
examples given in the spec for guidance. There is no *normative* text
in the draft that describes this issue but there is a non-normative
example that illustrates, what I suspect, is the author's intent.
That, obviously, cannot be verified without the authors speaking up
and responding to the inquiry.

On Mon, Apr 15, 2013 at 4:08 PM, Erik Wilde <[email-masked]> wrote:
> http://code.google.com/p/uri-templates/wiki/Implementations lists a number
> of implementations, and it would be interesting to know what they have been
> doing, and how they handle the test case in question.
>
> thanks and cheers,
>
>
> dret.
>
> --

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 17 Apr 2013 10:03:19 -0400

Sorry for the delay in responding.

On Mon, Apr 8, 2013 at 1:41 AM, Erik Wilde <[email-masked]> wrote:
> explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5 says
> that

The answer is in the text you quote:

"for each defined variable in the variable-list, append '.' to the
result string and then perform variable expansion"

The set of variables in the variable list is the empty set, so no '.'
is appended.

I agree that if this is confusing an addendum is in order.

  -joe

>, and i cannot find any
> text saying that an empty list is considered to be undefined. i have read
> the spec recently and never looked at this particular case, but without
> looking at the test cases i would have said it has to be expanded to "X."
> and not "X".
>
> cheers,
>
> dret.
>
> --

--
Joe Gregorio        http://bitworking.org

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 17 Apr 2013 16:31:14 +0200

On Wed, Apr 17, 2013 at 4:03 PM, Joe Gregorio <[email-masked]> wrote:
[...]
> The set of variables in the variable list is the empty set, so no '.'

Is it really the case? I don't see an empty list as an undefined variable.

Or it would mean that the first thing which needs to be done is expand
variable values (scalars, lists, associative arrays) before "grouping"
them.

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 17 Apr 2013 10:41:35 -0400

On Wed, Apr 17, 2013 at 10:31 AM, Francis Galiegue <[email-masked]> wrote:
> Is it really the case?

Yes.

> I don't see an empty list as an undefined variable.

Which is why an addendum should be added to the spec.

---

From: Erik Wilde <[email-masked]>
Date: Fri, 26 Apr 2013 10:20:31 -0700

hello joe.

thanks for the response!

> I agree that if this is confusing an addendum is in order.

... and just when i wanted to submit an erratum and searched for the 
best place where to put clarifying text, i ran into the last paragraph 
of http://tools.ietf.org/html/rfc6570#section-2.3 :

"A variable defined as a list value is considered undefined if the list 
contains zero members. A variable defined as an associative array of 
(name, value) pairs is considered undefined if the array contains zero 
members or if all member names in the array are associated with 
undefined values."

while still being a bit of an unintuitive definition for me, it seems as 
if this particular paragraph was never mentioned in previous 
discussions, and indeed clarifies that an empty array should be 
considered as an "undefined variable". for now, i'll assume that this 
settles things and will not file an erratum. but if people think 
(fracis? james?) that this still isn't good enough, then please speak up.

thanks and cheers,

dret.

---

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 10:27:58 -0700

Nope, it works. I've maintained that the spec is fine like it is ;-)
Honestly, I never really saw where the confusion was.

On Fri, Apr 26, 2013 at 10:20 AM, Erik Wilde <[email-masked]> wrote:
>>> says
> ... and just when i wanted to submit an erratum and searched for the best
> place where to put clarifying text, i ran into the last paragraph of
> http://tools.ietf.org/html/rfc6570#section-2.3 :
>
> contains zero members. A variable defined as an associative array of (name,
> value) pairs is considered undefined if the array contains zero members or
> if all member names in the array are associated with undefined values."
>
> while still being a bit of an unintuitive definition for me, it seems as if
> this particular paragraph was never mentioned in previous discussions, and
> indeed clarifies that an empty array should be considered as an "undefined
> variable". for now, i'll assume that this settles things and will not file
> an erratum. but if people think (fracis? james?) that this still isn't good
> enough, then please speak up.
>
> thanks and cheers,
>
>
> dret.
>
> --