[Json] About JSON equality

Francis Galiegue <fgaliegue@gmail.com> Tue, 19 February 2013 22:55 UTC

Return-Path: <fgaliegue@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 975D621F88EA for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 14:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eqkWvAdZc3v for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 14:55:26 -0800 (PST)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id A633C21F88E8 for <json@ietf.org>; Tue, 19 Feb 2013 14:55:25 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id b47so3676852eek.15 for <json@ietf.org>; Tue, 19 Feb 2013 14:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Z0X1EC3b1oi8N0M4xpl+Mg2ZAnBqD322tbirtBTIFo8=; b=ux6B7Ed5CIjM4uMJFhpn02ggdXMHTViyL6atP9Qo654QTaR1c84dFekOjmFCc1SluY h/cbM0SZjh+8NsqrWHjNRUkZVS8BnqbaKuIfLV6QLQf+adH7rg/gEsHmFJRX/9AuQz2U TzLDu5w4cnM95QHtDqX3i/+ve4xfePzs8av+no2m55neRnkKEcz5l+R/ohu3y6ywckh0 Ixhe/fcTtdAgIkg8a/RSfv36OXlgxSgNLkQ1ybIrkGzutmKxJUOXOtFDLLcDBx1ppRxp UXvTaJNYtpEi8leqBq5vIuxqylR1JG85Ru8/a1ZHDlqTzNvgIiDGl2O9dNpjARQOD4b0 VkDw==
MIME-Version: 1.0
X-Received: by 10.14.175.129 with SMTP id z1mr62304265eel.7.1361314524889; Tue, 19 Feb 2013 14:55:24 -0800 (PST)
Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:55:24 -0800 (PST)
Date: Tue, 19 Feb 2013 23:55:24 +0100
Message-ID: <CALcybBAqONQ+UAzcnJFkphsQk=qSpLwdEoYR-6YETY2GP_EN6w@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: json@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: [Json] About JSON equality
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <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: Tue, 19 Feb 2013 22:55:26 -0000

The subject has been brought, even though somewhat indirectly, in
another thread on this list, so here I will give a digest of what JSON
Schema came up with.

The definition of JSON value equality, as defined by the core
specification, is as such (link:
http://tools.ietf.org/html/draft-zyp-json-schema-04#section-3.6):

----
Two JSON values are said to be equal if and only if:

      both are nulls; or

      both are booleans, and have the same value; or

      both are strings, and have the same value; or

      both are numbers, and have the same mathematical value; or

      both are arrays, and:

         have the same number of items; and

         items at the same index are equal according to this definition;
         or

      both are objects, and:

         have the same set of property names; and

         values for a same property name are equal according to this
         definition.
----

This definition is only lacking for strings. On some other draft which
I cannot remember off the top of my head, two JSON String values are
to be considered equal if, position wise, their Unicode code points
are the same (and THAT INCLUDES \u0000).

Now, what is the value of defining equality of two JSON values in the
general case (see also my mail about why having to restrict JSON
representations to container instances)?

Of course, there is also the problem that for numeric instances, some
programming languages/parsers cannot guarantee that, since they cannot
reliably represent said instances in a reliable manner, but then this
is why the validation spec explicitly mentions this:
http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.2

About strings and the famous "zero character", this same specification
also says: http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.1

Yes, nothing forbids "\u0000" in a JSON string.

All this to say, should an equality definition find its place in a
potentially revised JSON RFC? Personally, I'm not so sure...

--
Francis Galiegue, fgaliegue@gmail.com
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com