Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS

[Carsten Bormann <[e-mail]>]

The efforts to real-world-test the ABNF are ongoing; so far everything looks fine (unsurprisingly).

From a stylistic point of view, I have two comments on the ABNF:


1) the production for char relies on the operator precedence, i.e., concatenation binds closer than alternative.

      char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

This is nicely layed out to suggest this priority, and given the precedence defined in 5234, it *is* unambiguous.

Still, section 3.10 of 5234 rightly notes:

   Use of the alternative operator, freely mixed with concatenations,
   can be confusing.

      Again, it is recommended that the grouping operator be used to
      make explicit concatenation groups.

So the canonical form of writing this might be:

      char = unescaped / (
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              (%x75 4HEXDIG) ) )  ; uXXXX                U+XXXX



2) the character literals use hex in favor of "x" notation.

begin-array = ws "[" ws
begin-object = ws "{" ws
end-array = ws "]" ws
end-object = ws "}" ws
name-separator = ws ":" ws
value-separator = ws "," ws

would generally be considered slightly more readable.
Productions like minus, zero, plus, would not really be needed.
(Hex notation is indeed needed for quotation-mark, for case-sensitive productions like false, and for the ranges, so using just that instead of a mix with quoted "char-val"s is a simplification for people new to ABNF.)



Now, changing the ABNF even on a stylistic level could make it look like something changed syntactically between 4627 and 4627bis.
On the other hand, I'm not aware of any problems that have been caused by the two stylistic peculiarities.

So I'm not actually proposing to make any of these changes now, but I would like to make sure the WG considered and consciously decided against them because they will inevitably come up at IESG review time.

(If we do decide to change the ABNF for other reasons, these items might be reconsidered.)

Grüße, Carsten