[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Stick with XML ... JSON is a minefield of securityrisks an

• From: "Ghislain Fourny" <gfourny@inf.ethz.ch>
• To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
• Date: Wed, 2 Nov 2016 13:13:24 +0000

Hi,

I think one needs to distinguish not only between accept and reject (as in: stating whether yes or no the document is well-formed) but between accept, reject or raise an error.

I understand (without claiming that I'd know the original intent of Tim Bray of course):

>> A JSON parser MUST accept all texts that conform to the JSON grammar.

as implicitly saying that a parser must accept texts conforming to the JSON grammar to the extent that it doesn't raise an error (see below), and

>> An implementation may set limits on the size of texts that it accepts.
>> An implementation may set limits on the maximum depth of nesting.
>> An implementation may set limits on the range and precision of numbers.
>> An implementation may set limits on the length and character contents of strings.

as saying that a parser may raise an error if its limits are reached -- not in the sense that it rejects the document, but in the sense that it declares its inability to tell and further process.

JSON is, I think, fully defined in the theoretical, language-theoretical sense. It is crucial to distinguish the logical language defined by JSON on the one hand from the parser implementations and capabilities on the other hand, as Mike points out. One can argue that there is a lack of interoperability because the RFC is permissive (allows to accept non-JSON input). However, there is interoperability in that any JSON document generated in the sense of the RFC (which requires strict adherence to the grammar) will not be rejected by any other parser -- but it does not exclude that a parser could throw an error rather than accept, if its limits are reached.

Both XML and JSON are limited to the memory and processing capabilities of the hardware (memory, CPU) the parser is running on. There are also XML documents that would be impossible to parse with today's possibilities. The XQuery specification explicitly mentions such limitations. Also integers and decimals have unlimited range in XML and I would expect some XML parsers to have issues as well for very large or precise numbers. XML and JSON are very alike on many aspects and have overlapping use cases.

I hope these two cents makes sense!

Kind regards,
Ghislain

• Follow-Ups:
  • Re: Stick with XML ... JSON is a minefield of securityrisks and ambiguities
    • From: John Cowan <johnwcowan@gmail.com>
  • Re: Stick with XML ... JSON is a minefield of securityrisks and ambiguities
    • From: Steve Newcomb <srn@coolheads.com>

• References:
  • Stick with XML ... JSON is a minefield of security risks andambiguities
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: Stick with XML ... JSON is a minefield of securityrisks and ambiguities
    • From: Steve Newcomb <srn@coolheads.com>