Validity of numbers

[glyn]

The ABNF number is not currently subject to the I-JSON range restriction that applies to array indices and array slice parameters, but I don't see why it shouldn't be.

[cabo]

I don't understand -- the grammar cannot express this restriction. Indices and slice parameters are integers, not numbers, BTW.

[glyn]

I was thinking of the integer subset of number. It seems strange to have to cope with arbitrary precision integers there, but not for array indices and slices.

[glyn]

As for the grammar expressing the restriction, this is a question of validity rather than well-formedness.

[cabo]

Ah, so this would be a text fix.

[glyn]

Ah, so this would be a text fix.

Indeed. Sorry for the ABNF red herring. I was trying to be precise about which "number" I was talking about.

[glyn]

I guess we'll have to worry about decimal as well as integers in number, for consistency. I wonder if there's a suitable precedent like the I-JSON range?

[cabo]

Hmm, $[?1.000000000000000000000000000001 == 1.000000000000000000000000000002] is not really discussed in the unnumbered (argh) section "comparisons". (There is text for <.)

[glyn]

How about this text?

When any path on either side of a comparison results in a nodelist consisting of a single node, each such path is replaced by the value of its node and then:

• a comparison using the operator == yields true if and only if the comparison is between:
  • equal primitive values,

[glyn]

(and in case anyone thinks we could get away with comparing the string forms of the numbers, remember scientific notation 1e2 == 100.)

[glyn]

Oh, I see now. We should mention the I-JSON restrictions for numbers, in the comparison section. That seems like a reasonable way to fix this issue.