Re: [Json] ABNF nits

[Stefan Drees <[e-mail]>]

On 2013-06-07 10:14, Martin J. Dürst wrote:
> On 2013/06/07 15:31, Stefan Drees wrote:
>
>> If defining a grammar with real case-sensitive "word"-ish tokens in it,
>> ABNF is IMO barely usable, unless you extend it with say single quotes
>> as case-sensitve string delimiters. But then dealing with two kinds of
>> strings also has it's catches =(
>
> Another way to do this is to just note that you are using ABNF *except
> that literals are case-sensitive*.

Piece of cake, if all words are case sensitive, but the devil is in the 
mix. As I stated above "with ... case-sensitive ... tokens in it" on 
purpose, and not "with ... case-sensitive ... tokens only" ;-)

That is a situation where I prefer eg. ANTLR stating an easy to parse
tokenCS: 'CaseSensitive' nicely different from the more varying
tokenCIS: [Cc][Aa][Ss][Ee][Ii][Nn][Ss][Ee][Nn][Ss][Ii][Tt][Ii][Vv][Ee]

But I think readability is in the eye of the reader and for JSON the 
grammar is set to be ABNF which is also fully sufficient.


> I'm sure there's an RFC or two which have done so. ...

To the enlightment of the readers, when feeding such a grammar into an 
ABNF tool =( I presume ...

In Open Data we settled in the ABNF URL construction rules[1] for the 
upcoming version 4 on an explicit differentiating strategy and also 
provided a tool (adaption) [2] for translating into real ABNF.



References:

[1]: 
https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/ABNF/odata-abnf-construction-rules.txt?rev=356&sc=1
[2]: https://github.com/SAP/abnf-test-tool

All the best,
Stefan.