Re: [Json] Nudging the English-language vs. formalisms discussion forward

Using Carsten's "summary" note as an anchor, let me back up to where
this proposal came from.

I'm interested in providing a recommended way (through a non-binding,
Informational document that describes it) in which protocol elements
that are JSON things can be described in documents.  I'm hoping we can
keep this work item to that limited scope, and not go too far in
trying to devise something mega-general that does everything but
eat.[1]

That means that I'm looking for something that addresses the 90% case
nicely and cleanly.  The 10% of the messier cases should be workable,
but can be messier, I think.  As an example of what made me think
about this, look at these:
1. Section 6.1.1 of http://tools.ietf.org/html/draft-ietf-repute-media-type-12
2. Section 6.2.2 of http://tools.ietf.org/html/draft-ietf-repute-media-type-13

Note that the attempt to reproduce the JSON ABNF, in version -12, had
a number of problems.  I think the mechanism in version -13 is much
cleaner... and it's simple and easy to explain.  Nested and complex
structures can be handled as they are in ABNF, by naming the nested or
complex bit and then expanding it in another "rule".  I think this
sort of mechanism meets the "addresses the 90% case nicely" desire.  I
like it because it's easy to write and, more importantly, easy to read
and understand.

We could possibly come up with something more general; we could
consider Andy Newton's draft, or variations of that (as Andy
suggested, perhaps with changes to make it more readable).  But I'd
really like us to avoid getting so general that we end up with
something that's precise and covers everything... but is difficult to
get right and hard to read.

Barry

[1] Points to you if you know the reference:
http://mindprod.com/jgloss/debe.html

On Wed, Feb 19, 2014 at 3:02 PM, Carsten Bormann <cabo@tzi.org> wrote:
> At the danger of repeating myself and others here, I'll try to summarize:
>
> -- We have quite good experience with using a single, standard (!) ABNF in IETF protocols.
>   ABNF is a production system with well-understood semantics.
>   It is somewhat idiosyncratic in the world of EBNF, but that has caused *zero* problems in practice.
>   (People have just written ABNF parsers.  You still have the second half of the afternoon to do something else after that.)
>
> -- A production system that generates JSON (at the data model level) is easy to do.
>   (But we have to find people who have the background and can commit the time.)
>
> -- Relax NG compact is a nice existence proof that a production system like this can work and be highly usable.
>   A JSON version could be even simpler.
>
> -- Previous attempts at trying to express XML or JSON data model syntax in the formalism of XML or JSON itself provide incontrovertible proof that this approach does not work.
>   Don't do that then.
>   (It is so much easier to spend half the afternoon writing the parser for the workable syntax.
>    We can even spec it in ABNF!)
>
> -- If you want to cover 100 % of the "syntax" of an XML document, you need to add Schematron to Relax NG compact.
>   a) Don't do that then for JSON -- stay with an 80 % solution like Relax NG (which is more like 90 %) or maybe even simpler.
>   b) Choose some form of "Jpath" to complement the production system with assertions.
>
> (Note that choice b can always be added later, on a separate timeline from doing a production system.)
>
> My proposals following from this little exercise in fact finding:
>
> -- I would propose that we try to find energy for doing the production system.
> (In addition to the Web people, we may want to tap the YANG people for some recent experience in doing this kind of work.)
>
> -- I would propose that we stay open to adding a Jpath/Schematron approach (choice "b"), *if* somebody brings a credible one to the table.
>
> -- I also would propose that we collect a small number of benchmarks that we use for demonstrating that proposals for the production system are useful.
>   My first suggestion: RFC 7071.  But we need a couple of different ones.  RFC 7095?  Maybe too ambitious.
>
> Grüße, Carsten
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json