Re: [Json] Generators

[Tatu Saloranta <[e-mail]>]

On Mon, Jun 10, 2013 at 5:20 AM, Marcos Caceres <[e-mail]> wrote:

> Hi Stefan,
>
> On Monday, June 10, 2013 at 11:59 AM, Stefan Drees wrote:
>
> > On 2013-06-10 12:10 CEST, Marcos Caceres wrote:
> > > On Monday, 10 June 2013 at 10:49, Markus Lanthaler wrote:
> > > > On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote:
> > > > > 5. Generators
> > > > >
> > > > > A JSON generator produces JSON text that MUST strictly conform to
> > > > > the JSON grammar.
> > > >
> > >
> > >
> > >
> > > Please try to avoid "wish list" style conformance requirements. If you
> > > want "strictly" conforming documents generated (whatever that may
> mean),
> > > then please write the algorithm to produce such documents. For example:
> > >
> > > "When generating JSON, as JSON generator MUST run the steps to
> generate JSON text.
> > >
> > > The steps to generate JSON text are given by the following algorithm:
> > > 1. …
> > > 2. …
> > > "
> >
> >
> >
> > if I only once had the power to write my wish lists that strong and
> > concise, I would be a very happy man I guess :-)
> >
> > We will not have a conformance section and we had until now no step by
> > step description but only an "integral" check, where the result had to
> > conform to the ABNF grammar of JSON.
> > So the following message is the best we can state:
> > If you are a wannabe X generator, ensure your output strictly conforms
> > to our X grammar.
> >
> > Retro-inventing of stepwise solutions/recipes simply not having been
> > around for all these years and then acting as if they had, to me
> > personally gives a strong smell and is far off the charter, isn't it?
>
> I haven't read the charter, tbh … I literally stumbled onto this list
> yesterday :)


Make sure you then read preceding discussions. Many of the concerns have
been discussed in considerable length. It appears bit arrogant to start
commenting on "should leave all these loopholes" when there are solid
reasons for not mandating things that various implementation can not
support in practice. Practice based on existing significant use cases, as
discussed on the list.


> However, I'm worried that overly simplistic or optimistic conformance
> requirements will just force people to go and look at ES6 to actually write
> the parsing and generation algorithms (or worst, they will just find some
> other random implementation out there and copy that). That could greatly
> diminish the value of this specification as it will leave implementers
> scratching their heads about how to implement either a parser or a
> generator.
>
> Also, given the legacy of JSON, it should be possible to see which parser
> behavior "won" (e.g., Doug's original JSON.js?) - and model this spec off
> that.
>
>
Which is what has been discussed in detail as well; and is what lead to
current proposal of "if only one of duplicate values used, it shall be the
last one".


> Additionally, I suspect few people actually implement an ABNF parser -
> whatever is expressed in ABNF will have to be translated into code for a
> specific implementation. You can essentially shortcut that by specifying
> the algorithm and making implementer's lives easier.  That's not to say
> that the ABNF should not be there (it helps the reader understand
> components of the JSON grammar) - but the reality of the situation should
> be acknowledged (ABNF is an editorial aid, but rarely, AFAIK, a tool used
> in implementations in it's pure form to do syntactical checking).
>
> > > > > Generators MUST NOT duplicate names in objects if they can avoid or
> > > > > detect such duplication.
> > > > >
> > > > > """
> > > > [...]
> > > > > This "MUST NOT duplicate ... if" reads pretty soft for
> implementers,
> > > > > but should be the only consensual non-breaking way out of the
> > > > > historical dilemma of not enforcing it for generators in the first
> place.
> > > >
> > >
> > >
> > >
> > > I agree. The above "if they can avoid [it]" if pretty lousy spec text.
> > > Please define the algorithm instead to produce the results you want.
> >
> >
> >
> > I might be tempted to change the sequence to a more natural looking one
> > "detect before avoid" but then, if an implementation is not able to
> > avoid it, why should it bother to detect or not detect? So the strongest
> > excemption is noted first: A policy or a use case hinders me in ensuring
> > the "uniqueness wish" for names in objects.
> >
> > On a personal note: If we avoid wordings like "pretty lousy spec text"
> > in situations where many people are trying to retrofit best possible
> > constraints into an area where these completely missed for years, to
> > avoid further future "leakage" and without breaking reality that would
> > be surely helpful, wouldn't it?
>
> Yes, I'm sorry; I didn't mean any offense. I just meant that it was a
> conditional MUST, and that's not how MUST should be used (as it means one
> parser can do one thing and another can do another thing … which is an
> interoperability anti-pattern). This would, obviously, be bad if I'm
> sending one JSON representation from the client and it gets transformed
> into a different one on the server and the spec says that this behavior is
> ok.
>


But this is reality: the only way to guarantee, for example, uniqueness of
keys leads to constraints that make it impossible to process JSON content
without tracking all names of currently open JSON objects in memory. In
worst case this is comparable to just holding on to the whole logical JSON
tree representation.


>
> On the other hand, if the spec has to say, "well, that's the reality right
> now… and here are some guidance on how to avoid that problem without
> breaking clients and servers:" that might have to do.
>
>
which is what I understand specification tries to say.

-+ Tatu +-