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

[Stefan Drees <[e-mail]>]

On 2013-06-11 19:32 CEST, Paul Hoffman wrote:
> ...
> JSON-text = object / array
>
> begin-array     = ws %x5B ws  ; [ left square bracket
> begin-object    = ws %x7B ws  ; { left curly bracket
> end-array       = ws %x5D ws  ; ] right square bracket
> end-object      = ws %x7D ws  ; } right curly bracket
> name-separator  = ws %x3A ws  ; : colon
> value-separator = ws %x2C ws  ; , comma
>
> ws = *(
>       %x20 /              ; Space
>       %x09 /              ; Horizontal tab
>       %x0A /              ; Line feed or New line
>       %x0D                ; Carriage return
>       )
> ...

allthough I am used to ABNF stanzas like the above, as a grammar, it is 
only "paper ware" (IMO not useful for an optimal parser generator) and I 
would like to hereby ask all participants in this endeavour if it is 
possible to list the allowed "white space" without defining such a mad 
token like "ws" is defined above. (I think a grammar should clearly 
focus on real tokens and not name "nothing")

Why now and not earlier? Well, as Carsten in a separate sub thread (of 
this "ABNF nits last proposal" thread) suggested a better readable ABNF 
of this part and I opposed to it, I went back and looked at the above 
proposed version again and of course disliked the "ws"'s sprinkled all 
over the place that are in fact optional (zero or more) but which is 
buried inside the ws rule.

Wouldn't it be better to explicitely state the following:

"""
JSON-text = object / array

begin-array     = *ws %x5B *ws  ; [ left square bracket
begin-object    = *ws %x7B *ws  ; { left curly bracket
end-array       = *ws %x5D *ws  ; ] right square bracket
end-object      = *ws %x7D *ws  ; } right curly bracket
name-separator  = *ws %x3A *ws  ; : colon
value-separator = *ws %x2C *ws  ; , comma

ws =  (
       %x20 /              ; Space
       %x09 /              ; Horizontal tab
       %x0A /              ; Line feed or New line
       %x0D                ; Carriage return
       )
"""

instead of the grammar part cited on top of this mail?

Then a "ws" truly would be a single white space.
Also the optionality (zero or more) of this white space surrounding the 
punctuation tokens would clearly stand out.

What do you think? Based on that, would it be helpful, to deliver a 
complete new proposal? I thought yes, and thus integrated Carstens first 
partial proposal on better grouping on the right hand side of the "char" 
rule.

So **this** below is my proposal unification effort. (I named it 
proposal 2, as I did not see another complete proposal. If I overlooked 
one, please excuse and renumber the below one accordingly.)

Proposal 2
==========

JSON-text = object / array

begin-array     = *ws %x5B *ws  ; [ left square bracket
begin-object    = *ws %x7B *ws  ; { left curly bracket
end-array       = *ws %x5D *ws  ; ] right square bracket
end-object      = *ws %x7D *ws  ; } right curly bracket
name-separator  = *ws %x3A *ws  ; : colon
value-separator = *ws %x2C *ws  ; , comma

ws = (
      %x20 /              ; Space
      %x09 /              ; Horizontal tab
      %x0A /              ; Line feed or New line
      %x0D                ; Carriage return
      )

value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65   ; false
null  = %x6e.75.6c.6c      ; null
true  = %x74.72.75.65      ; true

object = begin-object [ member *( value-separator member ) ]
          end-object
member = string name-separator value

array = begin-array [ value *( value-separator value ) ] end-array

number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E       ; .
digit1-9 = %x31-39         ; 1-9
e = %x65 / %x45            ; e E
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
int = zero / ( digit1-9 *DIGIT )
minus = %x2D               ; -
plus = %x2B                ; +
zero = %x30                ; 0

string = quotation-mark *char quotation-mark

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

escape = %x5C              ; \
quotation-mark = %x22      ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

HEXDIG = DIGIT / %x41-46 / %x61-66   ; 0-9, A-F, or a-f
        ; HEXDIG equivalent to HEXDIG rule in [RFC5234]
DIGIT = %x30-39            ; 0-9
       ; DIGIT equivalent to DIGIT rule in [RFC5234]


""" end of proposal 2.


Thanks a lot,
Stefan.