I'd propose to at least fix the duplicate key validation. Duplicate keys are not defined in any way and could result in strange behaviour when the parser is changed.
A strict validator for the trailing seperators would also be nice, but following the argumentation it shouldn't be mandatory. Regards, Dominik On Sat, Mar 28, 2009 at 6:50 PM, Carsten Ziegeler <[email protected]>wrote: > Jim White wrote: > > The best approach is generally to be liberal with what is accepted and > > very strict with what is generated. That is the recommended philosophy > > of the IETF for example, and is arguably an important part of the > > Internet's success. > > > > http://www.postel.org/postel.html > > > > While it may seem like being strict in what is accepted would promote > > others to fix their bugs, whatever benefit that may have is vastly > > outweighed by the loss of greater interoperablity. > > > > Naturally you don't want to accept stuff so loosely that it constitutes > > a security hole, but for simple stuff like format/syntax that shouldn't > > be an issue (as long as the parser is robust in the face of all inputs, > > as it should be). > > > Yes, I agree with this; now actually I mixed two concerns, but didn't > realize it :) I added the validation of json files to the maven sling > plugin. This feature validates all json files which are added to the > bundle as resources. I think this validation should be as strict as > possible. The plugin uses our json commons bundle and there I detected > that the usual json parsing we do is very liberal. So my initial thought > was that this should be strict :) (therefore my mail). > > But as you clearly explain these are exactly the two different cases: > accepting something and "generating" - I consider static resources as a > kind of json generation. So it makes totally sense to distinguish > between the two. > > I think we can solve this by adding a strict validator to the json > bundle - and keep the rest as is. > > Carsten > -- > Carsten Ziegeler > [email protected] >
