[Json] Parsers

Jacob Davies <jacob@well.com> Thu, 06 June 2013 17:19 UTC

Return-Path: <cromis@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4670F21F99DC for <json@ietfa.amsl.com>; Thu, 6 Jun 2013 10:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCQE7Vy4VDMH for <json@ietfa.amsl.com>; Thu, 6 Jun 2013 10:19:35 -0700 (PDT)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7C21F9339 for <json@ietf.org>; Thu, 6 Jun 2013 10:19:35 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id 6so2106510qeb.3 for <json@ietf.org>; Thu, 06 Jun 2013 10:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=t+pcPp15povZ4j7vzC3kajk2SFp9taejU0xjFbhGxPA=; b=XeiH4uagHNuY4mV5m3IxxuPJxXygy/0AJ65eF1k7GBoccESHK/zz338h2yJ2gszoO2 lsmvqiAWerDqQbQszPyqan11JnFOP5iS21bm3GuwMYTKZU6vV106NkxVEZomO41dD7JG MVwtSnFTaeq2L+z4P4NQM7tt6KuTYHhkqD96xz4+Z2B3j/ERYTaQ3FaIUesM97r15ebj iLuhYb7pzqMfKMGg/e5aH6PCOkbjtq3lCTKXvNEVf8uRzPyxIU2/NqJp9htx5JHD5dzF QPVJpCjSHiwVvdLo4q3NAyqhFPtj+oX+/b2SIeEYw2XOnZzMRjbOF+SNy/sOj6rRp6+9 Up+A==
X-Received: by 10.49.58.97 with SMTP id p1mr15994394qeq.59.1370539170894; Thu, 06 Jun 2013 10:19:30 -0700 (PDT)
MIME-Version: 1.0
Sender: cromis@gmail.com
Received: by 10.49.106.228 with HTTP; Thu, 6 Jun 2013 10:19:10 -0700 (PDT)
From: Jacob Davies <jacob@well.com>
Date: Thu, 06 Jun 2013 10:19:10 -0700
X-Google-Sender-Auth: RawxgAcIuKKQbGm0NiueSAqolp4
Message-ID: <CAO1wJ5RPc09UcdSaA4y6eraVhExBDEmiWUSrR4n39zjgfn778A@mail.gmail.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [Json] Parsers
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 17:19:40 -0000

RFC 4627 text:

4.  Parsers

   A JSON parser transforms a JSON text into another representation.  A
   JSON parser MUST accept all texts that conform to the JSON grammar.
   A JSON parser MAY accept non-JSON forms or extensions.

   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 of numbers.
   An implementation may set limits on the length and character contents
   of strings.
--

1) It seems to me that "A JSON parser MUST accept all texts that
conform to the JSON grammar" is both impossible and immediately
contradicted in the next paragraph. No parser accepts all texts in the
sense of faithfully processing them into another representation
without error, because the entire text is of indefinite length, as are
many of its components, and

I think this is intending to say something about not inventing your
own subset of JSON. Maybe there is another way of expressing the
intent of this sentence.

2) I think there was also earlier discussion about whether the
acceptance of non-JSON forms or extensions is desirable. It seems
undesirable to me.

3) It is not stated that implementations may limit the number of
elements in arrays or objects. Perhaps that whole paragraph could be
something like: "Implementations may vary in their handling of the
size of texts, the maximum depth of nesting of arrays and objects, the
number of elements in arrays or objects, the range of numbers, and the
length and character contents of strings."

4) It might also suggest what parsers should do when they encounter
texts they cannot faithfully represent. Some extant implementations
truncate numbers larger than those they can faithfully represent, for
instance, which is bad. I think parsers should be strongly encouraged
to produce an error and no representation when they read a text they
cannot faithfully represent, rather than no error and a partial,
non-verisimilar representation.

-Jacob