Re: [Json] Generators

[Stefan Drees <[e-mail]>]

Sorry, waited for the URL to be defined by IETF mail archiving, but then 
eventually hit send before entering the reference mentioned in the 
message below. Now here it is:

References:
[1]: http://www.ietf.org/mail-archive/web/json/current/msg00706.html

Stefan.
Am 10.06.13 13:26, schrieb Stefan Drees:
> On 2013-06-10 11:49 CEST, 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.
>>>
>>>      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.
>>
>> The "if" makes the MUST NOT conditional which is at odds with its
>> definition
>>
>> """
>> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>>     definition is an absolute requirement of the specification.
>> """
>
> that depends. If we act with care, we have to respect many boundary
> conditions. One is: There is only one term Generators in the spec we
> update minimally, but in reality many polarizing use cases drove
> implementations of such generators into existence (please also cf. [1]
> esp. where listing some of these and further motivate the concurrently
> proposed "UPPERCASE lowercase" selection).
> So the if effectively offers a subclassification we are not allowed to
> enforce by say inventing a second class citizen like eg. a
> DupesGenerator ...
>
>> I would suggest to just drop the if-statement but can see why people
>> would
>> disagree with that. ...
>
> I personally would really wish to allow for trailing commas in arrays
> and objects, but our job - as I understand it - is to update the JSON
> RFC **and** keep the grown ecosystem intact thus defend the RFCs
> coolness, brevity and embracing functionality for all existing
> implementations of Generators, Parsers and combinations thereof. Some of
> these terms may not appear in the charter of the json wg, but might
> match those actually in there ;-) ...