Subject: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"

From: Mark Nottingham <[email-masked]>
Date: Sat, 29 Dec 2012 11:29:51 +1100

From <https://github.com/json-patch/json-patch-tests/issues/5>.

We currently use this language to describe the array index in a pointer:

>          characters that represent an unsigned base-10 integer value
>          (possibly with leading zeros), making the new referenced value
>          the array element with the zero-based index identified by the
>          token, or

But, as discussed, this is too loose.

I propose:

characters comprised of digits ("\d+", as per [RFC5234]) that represent ...

Thoughts?

--
Mark Nottingham   http://www.mnot.net/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 29 Dec 2012 03:15:32 +0100

>characters comprised of digits ("\d+", as per [RFC5234]) that represent ...

That does not look like RFC 5234 syntax to me, it would be more like
`1*DIGIT`. That aside, 'stating "/+7", "/007", "/ 7", and "/7.0" are
example of pointers that MUST NOT be accepted as array indices' is
much more likely to have the desired effect than offering some formal
syntax.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Matthew Morley <[email-masked]>
Date: Sat, 29 Dec 2012 23:45:57 -0500

I replied on the github link, but I think it bears repeating if this
audience is different enough....

My thoughts:

The syntax for a json-pointer should not require sub-expression parsing.

/a/b/c/1 should not resolve to the same path as /a/b/c/1.000, or /a/b/c/1e0
for that matter.  The later 2 should not be resolvable at all when c is an
array, even though they are a valid json-pointer path syntax.

For an object this is clear.... for any array, if these were considered
equal in resolving, you could not confirm identity based solely on json
pointer path comparisons at the string level.

On Fri, Dec 28, 2012 at 7:29 PM, Mark Nottingham <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

-- 
Matthew P. C. Morley

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 31 Dec 2012 13:14:22 +1100

And, that's what I get for doing spec work on holiday. 1*DIGIT is indeed what I meant.

MUST NOT be accepted seems strong to me; many languages will just use parseInt() or similar, and I don't think that's really that horrific. What must be clear is that people producing pointers can't rely upon that, and making the syntax clear does that. 

So, I'd be OK with prose, but think that a MUST NOT goes too far.

Cheers,

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Dec 2012 19:10:49 -0800

There would be a clear deliniation in the grammar if arrays were made
distinct from objects.

- Rob

On Sunday, December 30, 2012, Mark Nottingham wrote:

> MUST NOT be accepted seems strong to me; many languages will just use
> parseInt() or similar, and I don't think that's really that horrific. What
> must be clear is that people producing pointers can't rely upon that, and
> making the syntax clear does that.
>
> On 29/12/2012, at 1:15 PM, Bjoern Hoehrmann <[email-masked]<javascript:;>>
> wrote:
>
> > * Mark Nottingham wrote:
> > Björn Höhrmann · mailto:[email-masked] <javascript:;> ·
> http://bjoern.hoehrmann.de
> [email-masked] <javascript:;>

---

From: James M Snell <[email-masked]>
Date: Mon, 31 Dec 2012 07:35:51 -0800

+1 for 1+DIGIT with a statement that leading zeros SHOULD not be used and
MUST be ignored if they are present when evaluating an array. Nothing more
than that is required.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 31 Dec 2012 16:44:09 +0100

On Dec 31, 2012, at 16:35, James M Snell <[email-masked]> wrote:

>  1+DIGIT with a statement that leading zeros SHOULD not be used and MUST be ignored if they are present when evaluating an array

No, make that "MUST NOT be sent", "MUST be handled as an error" *).
The other way is the recipe for soup.

Grüße, Carsten

*) (If you do this in Javascript, that already happens automatically.)

---

From: Matthew Morley <[email-masked]>
Date: Mon, 31 Dec 2012 22:15:43 -0500

On Mon, Dec 31, 2012 at 10:44 AM, Carsten Bormann <[email-masked]> wrote:

> >  1+DIGIT with a statement that leading zeros SHOULD not be used and MUST
> be ignored if they are present when evaluating an array
>
Stricter wording makes the most sense to me. The behavior should be one of
non-resolution in the context of an array, which should translate into
either errors or failure.

The english to describe the correct value set seems to be `zero and
positive whole numbers`. I would have said 'whole numbers' off hand, but
perhaps `non-negative integers` is the most concise.
http://en.wikipedia.org/wiki/Natural_number

Leading zeros should not be allowed in that definition, as such numbers are
not really natural numbers.

An an aside, JSON doesn't use indexes.... it implies them via the base
languages as a means of access access. Depending on character set support,
and the systems in play, I could see this needing to be expand down the
road. Again, only if wider language support is expected as part of pointer
resolution... (ie. http://en.wikipedia.org/wiki/Japanese_numerals)

-- 
Matt (MPCM)