Re: [Json] Schemas & so on

Phillip Hallam-Baker <> Wed, 04 May 2016 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9E5A12D5D1 for <>; Wed, 4 May 2016 12:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E1EU_qBoj444 for <>; Wed, 4 May 2016 12:58:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72AF312D52A for <>; Wed, 4 May 2016 12:58:55 -0700 (PDT)
Received: by with SMTP id 90so29567115qgz.1 for <>; Wed, 04 May 2016 12:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=JCXk6Nf+RPHcEV69mwRn/3XxEa12bbyCyiC5SIJPlwQ=; b=kOWuqqxNfgTGj/nhkfY6NIHNKCTRc5cUxs8eLvonZnGf7cZE6Jc49TDJmPnV1hoy6a SvULrRAnoQ9b50oA6jBWncS4W09P7dlkHw/FDcOLb6Rm8ulZ5pyblaOJIpov3sbDHH9I Q2jAhqwd9Kk1bn6Tuv2oKJafg3+CuOhkUIO7OUtOV6mm/s5nLcgn8hJrI7buigTOqUaj 8MBYV0pryHI9qu7XT5d1DcfjCeMCgrRdHRwTrdJbUgomTbm8KC1AW9SZ/Y2Ia/mMRc9s YsPlR8Z+lSby0OYFEuWeOJ9H7t7zbotYd9Czhw41jytH28tkN7j89S8RYvNDShuBPiAk WjKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JCXk6Nf+RPHcEV69mwRn/3XxEa12bbyCyiC5SIJPlwQ=; b=flD1ag0Lyepgd8DtQZNXa9YWGBA8bwdPW0TLyGTgRxFr/kAQUU8BbVivOIY/8B+hIm bidHMiVgbn+vddPWge5YD6nkR2cP02EmixeFgQqJUQuhXZq7iyfwjTVVEXaJxPbi/r3Q TVIwy+53dv4fb68OiK3nHx1qHt2HRRVCcyBEGuoJyD48QL+wUO/6zH18Lp+qqn150U8s wSlyHdXQNJ/5xrU2vJVg9hbbX9we/BQRUcBVKitLf30qSTWdjeVxWPZOtBj1C7ZMUsJ1 j64xEuE2ZBtgCfuCG29kza8NF0g+NSs/46qpZLmJfpUjJwOpt2JwZaotR0mSn+nzosla d3Ww==
X-Gm-Message-State: AOPr4FXlIXsAe9+AwJG2fK6tVOPCHpMV6uBgEPm6eUXPyK5WwEhn8weGLTxSjGh28AvkXVN5OigK3MaCu6xBGg==
MIME-Version: 1.0
X-Received: by with SMTP id l17mr10328462qgd.12.1462391934550; Wed, 04 May 2016 12:58:54 -0700 (PDT)
Received: by with HTTP; Wed, 4 May 2016 12:58:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Wed, 4 May 2016 15:58:54 -0400
X-Google-Sender-Auth: m1UoF3L5AHAHFjTRFRwlS4k0B9s
Message-ID: <>
From: Phillip Hallam-Baker <>
To: John Cowan <>
Content-Type: multipart/alternative; boundary=001a11c14d10c824a8053209a787
Archived-At: <>
Cc: Mark Nottingham <>, Tim Bray <>, "" <>
Subject: Re: [Json] Schemas & so on
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 May 2016 19:59:04 -0000

While we are at it. Thinking of encoding a signed object as an array gives
me an idea.

If we take the approach of
  [ <signature header>, <signed Data>, <signature value>]

And also we are allowing a Bignum to be encoded as either a number or a
string that contains a Base63 encoded value:

MyStruct Class
   one BigNum
   two BigNum

  {"one" : 1, "two" : "AAAAAAAA2" }

The one thing I feel missing from XSD that is incredibly useful is the
ability to put in links between objects as Identifiers. Now I use this to a
vast extent in Goedel, my code synthesis system.

So right now in my JSON structures I have strings that are identifiers for
the enclosing object and I have other strings that are references to those
identifiers. But there is no information in the JSON schema to say which is
which or to impose type constraints, etc.

So lets say we have a definition as follows

MyStruct1 Class
   Inner MyStruct2

MyStruct2 Class
   Identifier ID

I can then encode in my current system as follows:

{ Inner :  { ID : "Fred"} }

But now lets say I want to refer to the same structure in another part of
the same document and I know it is already serialized. This could be
written as:

{ Inner :  "Fred" }

Now lets say that we have a child class defined

MyStruct3 Class <Inherit MyStruct2>

Encoding this requires us to tag the structure so we know what the correct
subtype is. We could use the nested approach I showed earlier. Or we could
use an array:

{ Inner :  ["MyStruct3 ", { ID : "Fred"}] }

This does seem very natural and flexible. And adding identifiers is
sufficient to make the encoding capable of being usefully self describing.