Re: [Json] Another problematic JSON Schema use-case

Austin William Wright <aaa@bzfx.net> Fri, 27 May 2016 10:15 UTC

Return-Path: <aaa@bzfx.net>
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 2653312D630 for <json@ietfa.amsl.com>; Fri, 27 May 2016 03:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XsoEem64Wqa for <json@ietfa.amsl.com>; Fri, 27 May 2016 03:15:46 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4595D12B032 for <json@ietf.org>; Fri, 27 May 2016 03:15:45 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id y126so76056235qke.1 for <json@ietf.org>; Fri, 27 May 2016 03:15:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UFbGj9gcSaWB3lflOLVlu2FA2TRjvVE0m37aAYprbEg=; b=KCPS2qAjAW+RiiN2+/23PPdKnyPBv4TNkK/mZZlu7ldFKjzNVyHAGjBtpZNQmZqhdQ +6xs1WsNVhNbm7hOSKqsWjvQ9SZ2vab8E3+99xTkba2zkZtPLl7TqT8flqk0N32FgeSB qoPZYrHnnpc12PPSITSuIDJAniV7sWT9y/pMc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UFbGj9gcSaWB3lflOLVlu2FA2TRjvVE0m37aAYprbEg=; b=IAdi/fe/Ri57Pn02KTnreM4yh+KABuYP6U9huHJGD0YUnK5qPxlVOcK+b3RlSahFcO nivJToJUKLCC+n4XFHa7l5DrAYFa0uVMy2a1O6yqoMK5R+b+BOiAZIVOMAqpuJY5VsPp FD3qBqD2NAezd6bblZolW4TGVCKsq1BFDDtj9cLMVdfycaLh9qfC11+1kdM0wJ8ZahQA JtT7XdqY3SIuiAeX9vhWwrK/uuCg689Nj5ztZMtFgEbpH4j2lKUN3Y50VPi+poZK7h83 AsaKYiZgYSvZ+OQrUsSt1EcEYOYdv45ASn4trr1C+ifpKVXx6o/i2uo+9zw+tQ2SIJQk Rumw==
X-Gm-Message-State: ALyK8tKFOplp4oNBaHeTC5veKAHOnqyPtJ8YDovD89eyGxiof72DsiI2AYKd/F01JEtZVkjjhktGkU7/zzvANw==
X-Received: by 10.55.90.130 with SMTP id o124mr13263094qkb.178.1464344144294; Fri, 27 May 2016 03:15:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.80.85 with HTTP; Fri, 27 May 2016 03:15:29 -0700 (PDT)
In-Reply-To: <CAHBU6iv_ReUfUhP93hy9_npub4nqxoywKtVh65xbc6_DmqDMJw@mail.gmail.com>
References: <CAHBU6ivd5JJ7Hx_JtNPSnW40jXzEF1Yr7=rwuZzGnFrRoMphbg@mail.gmail.com> <CANkuk-WppF4WgeZc5OX2-tozmCd+eYtPwFgmDtoiJHxwdSjDzw@mail.gmail.com> <CAHBU6iu_nYyUBS-8PAJ3zER=RNKfiV532vEOeOnfr5eXbPv8Tw@mail.gmail.com> <CAAQiQRdu2pixrXhuqqmWGjdab6_mCMVcPTKWQQu=Oh0n3MmW0g@mail.gmail.com> <5745EE5E.5050801@tzi.org> <CAAQiQRcgKe=V1rmgZnMdQLdJEiftKP1fvbQRG15_AfdAVxqh1A@mail.gmail.com> <CAHBU6iv_ReUfUhP93hy9_npub4nqxoywKtVh65xbc6_DmqDMJw@mail.gmail.com>
From: Austin William Wright <aaa@bzfx.net>
Date: Fri, 27 May 2016 03:15:29 -0700
Message-ID: <CANkuk-Wcz6cFb3Z0f4sbfFRJsnyTaFZF+QgJo49=bey_CAagow@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary="001a114e72028ccaec0533d030bd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/44ykm401ukMOQGVms5aShi0e3g0>
Cc: Carsten Bormann <cabo@tzi.org>, json@ietf.org, Andrew Newton <andy@hxr.us>
Subject: Re: [Json] Another problematic JSON Schema use-case
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 27 May 2016 10:15:48 -0000

On Thu, May 26, 2016 at 8:56 AM, Tim Bray <tbray@textuality.com> wrote:

> So, to close the loop, here's how I worked around the problem. I
> auto-processed my large schema with a Ruby script to generate a small
> schema for each of the "Type":"Animal/Vegetable/Mineral" variations, then
> if the large schema reports any errors, I run through the objects
> validating each with the appropriate micro-schema.  This way, I almost
> always get a human-comprehensible error message.
>
> Not optimal, but better than writing a fully procedural validator by hand.
>
I now recall my earlier solution, which is similar enough to this: If two
objects carry different data, they should be described by different schemas.

Things of type "Plant" should validate against a Plant schema, which
includes (with allOf) a reference to the generic schema.

So instead of the schema I listed in my first post to the thread, you would
use a schema like:

{
    "id": "http://example.com/Plant",
    "allOf": [{"$ref":"http://example.com/Thing"}],
    "properties": {
        "Type": {"enum":["Plant]}
    },
    "required": ["Thing", "Genus", "Species"]
}

This would also go over the wire with the profile="http://example.com/Plant"
media type parameter.

Notice how the allOf acts like the "subclasses" operator in a dynamic
language (like PHP or maybe Ruby; as opposed to C++ which is static or
maybe ECMAScript which is prototypical): A Plant is also a Thing, but a
Thing doesn't necessarily have the data fields found in Plant.

Please let us know if you've considered something like this, and how such a
solution would work for you.

Digging a little more advanced into JSON Schema, there's no reason an
instance can't actually be describedby multiple schemas. A server could say
"Accept: application/json;profile=Thing" and the client could send back
"Content-Type: application/json;profile=Thing;profile=Plant". Or maybe just
"Content-Type: application/json;profile=Plant" if the server understands
the JSON Schema semantics. I'll have to do some digging and see if this
would be legal...

Thanks,

Austin.