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

[Stefan Drees <[e-mail]>]

On 2013-06-12 08:19 CEST, Carsten Bormann wrote:
> 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
>
>

I second the proposal, maybe with the last row knit slightly different.

>
> 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.)
>

or would not ;-) especially as the target language (JSON) of the grammar 
uses itself the double quote as token, it is IMO distracting to spread 
ABNF double quote tokens more than absolutely necessary.

In the cases under 2) above I see the task of the "rule spell out" as 
follows:

A) What is the rule?
B) What is that whitespace separated character token?

In random ordering I have two comments on this:

Firstly I think the cultural concept of lower and upper case in the 
realm of punctuation mixes (I presume) badly for people coming from 
other cultures where this concept of eg. 'a is somehow like A' does not 
apply and also with most keyboard layouts. Thus the rewrite of the 
rules as in 2 above may trigger extra work for the reader like:
Double quotes matches two characters per slot, ah, no this character has 
no "upper" sister.

Secondly I think that the "other" proposed form seems to transport the 
rules covering both aspects A and B clearly readable (giving the 
"printed" representation and common english name of the character in the 
comment.

All personal and opinion only, everyone will see this from a different 
angle, but that's why /I/ write it ;-)

> 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.

So I am all for the first proposed change above and at the same time 
opposed to applying the second proposed change based on the above reasoning.

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

ditto.

All the best,

Stefan.