Allow leading zeroes in numeric literals in Proposal A about json-path-comparison

[danielaparker]

Strongly disagree, I think leading zeros should be an error, particularly as they are in JSON proper. There is no benefit to allowing them, they add nothing, except confusion whether this represents octal notation or not.

[danielaparker]

You could always use your prerogative as owner of this site to say a resounding no! to the consensus on this:-) My own view is that the representation of numbers shouldn't differ from ECMA-404. Moreover, most of the JSONPath implementations lack a formal grammar, so it can be hard to tell whether a "feature" has been intended or merely reflects absent validation. For instance I doubt whether any implementation intended to support octal notation for array indexing, as some have. More likely the unintended consequence of using a general purpose to_integer function.

[glyn]

The JSON spec for numbers disallows leading zeroes. I'm tending towards making leading zeroes a syntax error. (This will also allow implementations to add octal support as a strict extension of Proposal A if they choose to.)

[cburgmer]

Here's the second example: https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_and_leading_zeros.html
You can see for one there's a consensus, for the other currently not.

That was I think the only motivation to currently not support it. I'll document that. As always, happy to discuss :)

[remorhaz]

I think that classic octal notation with leading zero is highly confusing for many modern users. I think that there's no reason to forbid leading zeros. My implementation fails to parse them right now, but I tend to consider it a bug.

But maybe it's wise to forbid leading zeros explicitly.

[glyn]

@danielaparker Great point about leading zeroes not being valid in JSON. Case closed?

[cburgmer]

If we say we don't support leading zeros for Proposal A, then we would have our first case where we advocate for not supporting something while the consensus offers a result.

[remorhaz]

most of the JSONPath implementations lack a formal grammar, so it can be hard to tell whether a "feature" has been intended or merely reflects absent validation

I tend to share this point of view.

I'd like to mention that some implementations allow using JSON object literals. Now let's remember that JSON scalars are also valid JSON documents; so maybe it would be convenient just to delegate JsonPath scalars to JSON spec? I mean, we can just use strict JSON syntax subset for defining JsonPath literals, including:

• strings/integers in bracket notation;
• integers in array slices;
• any valid JSON document as literal in filters.

[danielaparker]

@remorhaz Agree that wherever possible a formalization of JSONPath should refer to existing specifications.

[cburgmer]

Now let's remember that JSON scalars are also valid JSON documents; so maybe it would be convenient just to delegate JsonPath scalars to JSON spec?

Just to call out a limitation to that suggestion: we would have to separately support strings with single quotes. Some implementations even support arrays of strings with single quotes.

[remorhaz]

Dark ages of JsonPath have ruined my beautiful idea, alas. But I still think that we should keep as close to existing JSON spec as possible; something like STRING_KEY ::= JSON_STRING | SINGLE_QUOTED_STRING. And this derives another problem - of extending JSON values, like this: $.foo[?(@.bar=={"a":'b'})]. I mean, the question is: if we allow single-quoted strings in bracket-child, should we forbid them elsewere?

[danielaparker]

But I still think that we should keep as close to existing JSON spec as possible; something like STRING_KEY ::= JSON_STRING | SINGLE_QUOTED_STRING.

Agreed.

And this derives another problem - of extending JSON values, like this: $.foo[?(@.bar=={"a":'b'})]. I mean, the question is: if we allow single-quoted strings in bracket-child, should we forbid them elsewhere?

I think so, since implementations will want to use an existing JSON parser for parsing JSON values.