Re: [apps-discuss] JSON Schema considered harmful

Erik Wilde <dret@berkeley.edu> Thu, 20 September 2012 16:26 UTC

Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C7921F8809 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Sep 2012 09:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 xupF12nSI6vD for <apps-discuss@ietfa.amsl.com>; Thu, 20 Sep 2012 09:26:33 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52A21F8804 for <apps-discuss@ietf.org>; Thu, 20 Sep 2012 09:26:33 -0700 (PDT)
Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1TEjaA-0005i9-8p; Thu, 20 Sep 2012 09:26:32 -0700
Message-ID: <505B43B3.7050503@berkeley.edu>
Date: Thu, 20 Sep 2012 09:26:27 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CAMm+LwjYj0gd3Cxjj8WFcLy-zgBwfVDCPaRGcNSgOHD9m_07yw@mail.gmail.com> <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <CAK3OfOgU-Kepre2Z2dg_S8DAVCU413SRvuWMvJcC3BmE0BjNbQ@mail.gmail.com>
In-Reply-To: <CAK3OfOgU-Kepre2Z2dg_S8DAVCU413SRvuWMvJcC3BmE0BjNbQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] JSON Schema considered harmful
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2012 16:26:36 -0000

hello all.

On 2012-09-20 09:02 , Nico Williams wrote:
> So, while I have no problem with specific complaints about
> shortcomings of one or another schema language, I do object to the
> idea that because they fail to denote semantics we should not use
> them.

that's my general feeling as well. schemas are not able to and not 
designed to completely capture protocol semantics, but they provide a 
good starting point, and allow some level of formalism which then needs 
to be augmented with documentation.

> Regarding specific complaints...  I am not very familiar with XML
> Schema, so I can't say much about it and extensibility.  ASN.1 has
> extensibility rules nowadays, and often uses of ASN.1 predating
> extensibility rules are nonetheless extensibile (sometimes we need to
> resort to negotiation of extensions, but that's OK).  I suspect that
> the situation w.r.t. XML Schema extensibility is not as dire as you
> paint it.

imho, the real challenge is to *design* a good extension model for a 
language; coding it in a schema language then is just an exercise in 
figuring out what can be done in that specific language. in XSD, all you 
can do is to use wildcards (possibly refined by namespace specifications 
for them), and then you have to add documentation saying how processors 
are supposed to handle wildcards (ignore, interpret, stop, ...). 
extension rules cannot be fully captured (such as saying that extensions 
are not allowed to change the semantics of any fields in the base 
format), but at least the schema describes the base syntax, and also 
validates instances containing extensions.

i have to admit that i am really curious why the seasoned spec writers 
that have voiced general concerns about the usefulness of schema 
languages are feeling this way, but so far i have not really understood 
what they are saying. could somebody please try again, i'd really like 
to understand why the general idea of describing protocol syntax in a 
semi-formal (as opposed to non-formal) way is considered a bad idea.

thanks a lot and kind regards,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |