Re: [Json] Seeking more input on draft-ietf-json-text-sequence

[Stefan Drees <[e-mail]>]

On 2014-05-18 10:56 +01:00, Stefan Drees sent during streaming read 
session of draft-02:
> On 2014-05-14 20:32 +01:00, Paul Hoffman wrote:
>> Greetings again. Wearing my chair hat, I encourage people in the
>> group(especially you quiet types) to review this WG draft and let the
>> WG know
>> what you think. The idea of JSON text sequences has many applications,
>> and folks have invented things like this in the past for their own
>> internal purposes. We would like to make sure that this document covers
>> as many use cases as possible.
>>
>> --Paul Hoffman
>
> I like to understand grammars also bottom up - which might qualify as a
> lexer's perspective - overlapping rules like the one for ws1 and ws2 in
> the suggested grammar do not really make things clearer for me.
> Additionally the reader will benefit from the expressed clear
> assumption, how these ws(''|1|2) relate to each other.
>
> So, I suggest to change (as found in draft-02):
>
> # --- 8< ----
> 2.  JSON Text Sequence Format
>
>     The ABNF [RFC5234] for the JSON text sequence format is as follows:
>
>       JSON-sequence = *ws1 *(JSON-text *ws2 %x0A *ws1)
>       ws1 = %x20 / %x09 / %x0A / %x0D
>       ws2 = %x20 / %x09 / %x0D
>       JSON-text = <given by RFC7159>
>
>                       Figure 1: JSON text sequence ABNF
>
> # --- 8< ----
>
> into either:
>
> # --- 8< ----
> 2.  JSON Text Sequence Format
>
>     The ABNF [RFC5234] for the JSON text sequence format is as follows:
>
>       JSON-sequence = *(ws-no-nl
>                         / nl) *(JSON-text *ws-no-nl nl *(ws-no-nl / nl))
>       nl = %x0A
>       ws-no-nl = ( %x20 / %x09 / %x0D )
>       JSON-text = <given by RFC7159>
>
>                       Figure 1: JSON text sequence ABNF
>
>     When combining the grammars, the rule for ws in the JSON-text is
>     therefore equivalent to *( ws-without-newline / newline )
>
> # --- 8< ----
>
> or less cryptic but wrapped some more:
>
> # --- 8< ----
> 2.  JSON Text Sequence Format
>
>     The ABNF [RFC5234] for the JSON text sequence format is as follows:
>
>       JSON-sequence = *(
>          ws-without-newline /
>          newline ) *( JSON-text *ws-without-newline newline *(
>              ws-without-newline / newline ) )
>       newline = %x0A
>       ws-without-newline = ( %x20 / %x09 / %x0D )
>       JSON-text = <given by RFC7159>
>
>                       Figure 1: JSON text sequence ABNF
>
>     When combining the grammars, the production for ws in the JSON-text
>     is therefore equivalent to *( ws-without-newline / newline )
>
> # --- 8< ----

*preferred* (cf. below)

>
>   ... but I am *not* passionate about this.

Given the short length, focused style of the document, I think these 
changes do form a good contribution towards clarity and readability.

>
> It is just that the mix of optional sets, where one is a proper subset
> of the other to me smells very implicit, where being explicit (choosing
> a direct decomopsition like "X/x and x" to me reads well and is not that
> much longer.
>
> What do the others think?
>
> PS: If the parentheses in the simple rules do not match our current
> styleguide, just remove them, it is the decomposition I am interested in.

and of course adapt accordingly figure 2 located in section "3.  Use for 
Logfiles, or How to Resynchronize Following Truncated entries"

from the current:

# --- 8< ----
     boundary = endchar *ws2 %0xA *ws1 startchar
     endchar = ( "}" / "]" / %x22 / "e" / "l" / DIGIT )
     startchar =  ( "{" / "[" / %x22 / "t" / "f" / "n" / "-" / DIGIT )
# --- 8< ----

to the (short version):
# --- 8< ----
     boundary = endchar *ws-no-nl nl *(ws-no-nl / nl) startchar
     endchar = ( "}" / "]" / %x22 / "e" / "l" / DIGIT )
     startchar =  ( "{" / "[" / %x22 / "t" / "f" / "n" / "-" / DIGIT )
# --- 8< ----

or *preferred* (more explicit version):
# --- 8< ----
     boundary = endchar *ws-without-newline newline *(
                    ws-without-newline / newline) startchar
     endchar = ( "}" / "]" / %x22 / "e" / "l" / DIGIT )
     startchar =  ( "{" / "[" / %x22 / "t" / "f" / "n" / "-" / DIGIT )
# --- 8< ----

Note: Aliasing %0xA with a readable term lke newline to me shines as a 
service to the reader, emphasizing the special role this token has in 
the recommendation which is so nicely stated in:

# --- 8< ----
    Requirements:

    o  JSON text sequence encoders MUST emit a newline after any JSON
       text.
# --- 8< ----

So the longer versions presented above are the ones, I would prefer.
(those with "newline" instead of "nl").

Sorry for streaming feedback mode,
Stefan.

> All the best,
> Stefan
>
>> On May 9, 2014, at 10:31 AM, [e-mail] wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the JavaScript Object Notation Working
>>> Group of the IETF.
>>>
>>>         Title           : JavaScript Object Notation (JSON) Text
>>> Sequences
>>>         Author          : Nicolas Williams
>>>     Filename        : draft-ietf-json-text-sequence-02.txt
>>>     Pages           : 10
>>>     Date            : 2014-05-09
>>>
>>> Abstract:
>>>    This document describes the JSON text sequence format and associated
>>>    media type.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-json-text-sequence-02
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-02
>>
>>
>> _______________________________________________
>> json mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/json
>>
>
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json