From paul.hoffman@vpnc.org Fri Feb 7 14:32:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF55E1A0449 for ; Fri, 7 Feb 2014 14:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 t2-Cen_S9tng for ; Fri, 7 Feb 2014 14:32:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ABA371A0514 for ; Fri, 7 Feb 2014 14:32:46 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s17MWjsv031774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Feb 2014 15:32:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <52D9B39C.5020102@cisco.com> Date: Fri, 7 Feb 2014 14:32:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> References: <52D9B39C.5020102@cisco.com> To: IETF JSON WG X-Mailer: Apple Mail (2.1827) Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Feb 2014 22:32:47 -0000 First off: I dropped the ball on this one. I told Matt I would follow = up, and now I am doing so, but terribly late. People felt that our two work items didn't match what we had discussed = over the past few months. Below is another run at the proposed wording. --Paul Hoffman -----BEGIN CHARTER----- Javascript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard and was published in RFC 4627, an Informational document. JSON has come into very broad use, often instead of or in addition to XML. The JSON WG has already published a standards-track update to RFC 4627. The WG will work on two items: - a restricted profile of JSON designed to maximize interoperability; the starting point will be draft-bray-i-json - a standardized nomenclature for referring to the constructs in a JSON text, for use by those specifying protocols with JSON payloads Milestones: May 2014: WG LC on a restricted profile of JSON May 2014: WG LC on a standardized nomenclature for JSON June 2014: IETF LC on a restricted profile of JSON June 2014: IETF LC on a standardized nomenclature for JSON -----END CHARTER----- From hallam@gmail.com Fri Feb 7 14:53:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C438A1AD669 for ; Fri, 7 Feb 2014 14:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 HM9ygs8e-zyQ for ; Fri, 7 Feb 2014 14:53:28 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CD26E1AD66B for ; Fri, 7 Feb 2014 14:53:27 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id p9so3134812lbv.20 for ; Fri, 07 Feb 2014 14:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BLlkST/cKfzxNrZt3qZZBqN7fVcLBN/4pypZebZEkAY=; b=Tiegrr0Sh0hlR1VoeO6JHsj1EPgoZq7k/wuMhRMsfqGLxwFqB2nasqrtdR9+7fFcl0 EZ9O4jXacxFsnIuiQb+F94BFyelVZG2KvonZhwMsN3GqG6kPW3kJoxOqxswmwVFR1bg5 nDB+sVmV+XBh7XEsnkU6JLmYB2Nz/NYNjTsZgrfhbtw/DEgmFASAB6hXQeArCFW6q2ul +/sbZdmDlVI7GS/TYovWcr3pFUCpO2c7rpYwBgL/uK+20lyQIHVq98gSWnnZUk/pYjsA I2KIQSCK20jwLuQJZanDZbB7Ah03Rz9eTKhuoe5UuHzKwBUPXOXPnMeY6JJkAn/qwBCi 2PXw== MIME-Version: 1.0 X-Received: by 10.153.9.97 with SMTP id dr1mr3220601lad.45.1391813606914; Fri, 07 Feb 2014 14:53:26 -0800 (PST) Received: by 10.112.37.168 with HTTP; Fri, 7 Feb 2014 14:53:26 -0800 (PST) In-Reply-To: <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Fri, 7 Feb 2014 17:53:26 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11381b4ea240ca04f1d8dbea Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Feb 2014 22:53:30 -0000 --001a11381b4ea240ca04f1d8dbea Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 7, 2014 at 5:32 PM, Paul Hoffman wrote: > First off: I dropped the ball on this one. I told Matt I would follow up, > and now I am doing so, but terribly late. > > People felt that our two work items didn't match what we had discussed > over the past few months. Below is another run at the proposed wording. > > --Paul Hoffman > > -----BEGIN CHARTER----- > > Javascript Object Notation (JSON) is a lightweight, text-based, > language-independent data interchange format. It was derived from the > ECMAScript Programming Language Standard and was published in RFC 4627, > an Informational document. JSON has come into very broad use, often > instead of or in addition to XML. The JSON WG has already published > a standards-track update to RFC 4627. > > The WG will work on two items: > > - a restricted profile of JSON designed to maximize interoperability; > the starting point will be draft-bray-i-json > > - a standardized nomenclature for referring to the constructs in a > JSON text, for use by those specifying protocols with JSON payloads > > Milestones: > > May 2014: WG LC on a restricted profile of JSON > May 2014: WG LC on a standardized nomenclature for JSON > June 2014: IETF LC on a restricted profile of JSON > June 2014: IETF LC on a standardized nomenclature for JSON > Does a 'standardized nomenclature for JSON' mean formal languages are in or out of scope? If schemas are in scope then I can't see us completing by May 2014. My schema tool now allows the specification to be defined in a very clean syntax that is similar to python (no braces, indentation denotes block structure). It generates xml2rfc, C# and now C code to implement a client and server stub library. Runs on all major platforms. OK the C library needs more work, the parser is fine but its not got the Web service wrapper yet. If all we are doing is specifying how to describe the JSON elements in a spec then I will simply wait for the output and then make my specification generator write conforming text. Some issues that have come up recently are how to manage NaN values for numeric fields. I think the only clean way to do this in JSON is with the null lexeme -- Website: http://hallambaker.com/ --001a11381b4ea240ca04f1d8dbea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 7, 2014 at 5:32 PM, Paul Hoffman <= paul.hoffman@vpn= c.org> wrote:
First off: I dropped the ball on this one. I told Matt I w= ould follow up, and now I am doing so, but terribly late.

People felt that our two work items didn't match what we had discussed = over the past few months. Below is another run at the proposed wording.

--Paul Hoffman

-----BEGIN CHARTER-----

Javascript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from the
ECMAScript Programming Language Standard and was published in RFC 4627,
an Informational document. JSON has come into very broad use, often
instead of or in addition to XML. The JSON WG has already published
a standards-track update to RFC 4627.

The WG will work on two items:

- a restricted profile of JSON designed to maximize interoperability;
=A0 the starting point will be draft-bray-i-json

- a standardized nomenclature for referring to the constructs in a
=A0 JSON text, for use by those specifying protocols with JSON payloads

Milestones:

May 2014: =A0 =A0WG LC on a restricted profile of JSON
May 2014: =A0 =A0WG LC on a standardized nomenclature for JSON
June 2014: =A0 IETF LC on a restricted profile of JSON
June 2014: =A0 IETF LC on a standardized nomenclature for JSON

Does a 'standardized nomenclature for JSON'= mean formal languages are in or out of scope?

If schemas are in scope then I can't see us completing by May 2014= .

My schema tool now allows the specification to b= e defined in a very clean syntax that is similar to python (no braces, inde= ntation denotes block structure).

It generates xml2rfc, C# and now C code to implement a = client and server stub library. Runs on all major platforms.

=
OK the C library needs more work, the parser is fine but its not= got the Web service wrapper yet.


If all we are doing is specifying how to= describe the JSON elements in a spec then I will simply wait for the outpu= t and then make my specification generator write conforming text.

Some issues that have come up recently are how to manag= e NaN values for numeric fields. I think the only clean way to do this in J= SON is with the null lexeme



--
Website: http://hallambake= r.com/
--001a11381b4ea240ca04f1d8dbea-- From paul.hoffman@vpnc.org Fri Feb 7 15:13:13 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5358E1A0444 for ; Fri, 7 Feb 2014 15:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 vWdotE9xuh7h for ; Fri, 7 Feb 2014 15:13:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4151A042B for ; Fri, 7 Feb 2014 15:13:12 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s17ND8uL032712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Feb 2014 16:13:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Fri, 7 Feb 2014 15:13:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1827) Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Feb 2014 23:13:13 -0000 On Feb 7, 2014, at 2:53 PM, Phillip Hallam-Baker = wrote: > Does a 'standardized nomenclature for JSON' mean formal languages are = in or out of scope? Neither in or out of scope yet. There has only been lightweight = discussion in the WG so far. > If schemas are in scope then I can't see us completing by May 2014. Schemas are *not* in scope. In Vancouver, I proposed that the WG look at = requirements for schema, and the WG was nearly-universally against it. > My schema tool now allows the specification to be defined in a very = clean syntax that is similar to python (no braces, indentation denotes = block structure). >=20 > It generates xml2rfc, C# and now C code to implement a client and = server stub library. Runs on all major platforms. >=20 > OK the C library needs more work, the parser is fine but its not got = the Web service wrapper yet. >=20 >=20 > If all we are doing is specifying how to describe the JSON elements in = a spec then I will simply wait for the output and then make my = specification generator write conforming text. Maybe add the nomenclature to your tool as the WG develops the = nomenclature. Your tool will be a good sanity check about whether the = nomenclature is sane and complete. Edge cases will certainly be welcome. --Paul Hoffman= From tbray@textuality.com Fri Feb 7 15:17:00 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916151A0444 for ; Fri, 7 Feb 2014 15:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 HMd-tpARBzsF for ; Fri, 7 Feb 2014 15:16:57 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 934441A042B for ; Fri, 7 Feb 2014 15:16:57 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so3385372veb.0 for ; Fri, 07 Feb 2014 15:16:57 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=z2TQSw+bHouTtwzHcAKnnZxn2or+LEy4V6y3pzq0dcA=; b=MmxQkaseqNELS+HvthoWiu/PEDMqyD2UJ1wnnb81WNMZ/BfjSixjUYlp2LqSH0oGiy lri1vw2KK432q6cHTUjTOuYt/lGjDUdB4DJdQfhkSUhBpQB/2kzuRkN0AgzHB7E0XBzQ 0U/8kqXUFA0jYKhZY7uXZ9nnlmQiW9vQW08X8oPlxsw2ffLLm2BZBgLLRSiAXwArHByQ ENskWp7FgjIkAl9NR8Bx0R7htParAfd4aq9sOkIs8lFtTiHm4clOENzh/LJAD1Rmfgfm 3VdZFDrg1SKiGQtd9pXl0Sy5uMai/v64YWol+vykJqroHbfpdH5+yk//IMkPcLmeJ0de gTYA== X-Gm-Message-State: ALoCoQk8grZpWmoUgeFtVUA+fEqXBtdSQzp+RAzDcVHvqkHAqueFqyXjxDwzWbig56A8tmHjFnmf MIME-Version: 1.0 X-Received: by 10.52.164.203 with SMTP id ys11mr2212434vdb.37.1391815017040; Fri, 07 Feb 2014 15:16:57 -0800 (PST) Received: by 10.220.98.73 with HTTP; Fri, 7 Feb 2014 15:16:56 -0800 (PST) X-Originating-IP: [24.114.79.168] Received: by 10.220.98.73 with HTTP; Fri, 7 Feb 2014 15:16:56 -0800 (PST) In-Reply-To: <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Fri, 7 Feb 2014 15:16:56 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2cc40afe79204f1d92f4d Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Feb 2014 23:17:00 -0000 --001a11c2cc40afe79204f1d92f4d Content-Type: text/plain; charset=UTF-8 Works for me On 7 Feb 2014 17:32, "Paul Hoffman" wrote: > First off: I dropped the ball on this one. I told Matt I would follow up, > and now I am doing so, but terribly late. > > People felt that our two work items didn't match what we had discussed > over the past few months. Below is another run at the proposed wording. > > --Paul Hoffman > > -----BEGIN CHARTER----- > > Javascript Object Notation (JSON) is a lightweight, text-based, > language-independent data interchange format. It was derived from the > ECMAScript Programming Language Standard and was published in RFC 4627, > an Informational document. JSON has come into very broad use, often > instead of or in addition to XML. The JSON WG has already published > a standards-track update to RFC 4627. > > The WG will work on two items: > > - a restricted profile of JSON designed to maximize interoperability; > the starting point will be draft-bray-i-json > > - a standardized nomenclature for referring to the constructs in a > JSON text, for use by those specifying protocols with JSON payloads > > Milestones: > > May 2014: WG LC on a restricted profile of JSON > May 2014: WG LC on a standardized nomenclature for JSON > June 2014: IETF LC on a restricted profile of JSON > June 2014: IETF LC on a standardized nomenclature for JSON > > -----END CHARTER----- > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c2cc40afe79204f1d92f4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Works for me

On 7 Feb 2014 17:32, "Paul Hoffman" &l= t;paul.hoffman@vpnc.org> wr= ote:
First off: I dropped the ball on this one. I told Matt I would follow up, a= nd now I am doing so, but terribly late.

People felt that our two work items didn't match what we had discussed = over the past few months. Below is another run at the proposed wording.

--Paul Hoffman

-----BEGIN CHARTER-----

Javascript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from the
ECMAScript Programming Language Standard and was published in RFC 4627,
an Informational document. JSON has come into very broad use, often
instead of or in addition to XML. The JSON WG has already published
a standards-track update to RFC 4627.

The WG will work on two items:

- a restricted profile of JSON designed to maximize interoperability;
=C2=A0 the starting point will be draft-bray-i-json

- a standardized nomenclature for referring to the constructs in a
=C2=A0 JSON text, for use by those specifying protocols with JSON payloads<= br>
Milestones:

May 2014: =C2=A0 =C2=A0WG LC on a restricted profile of JSON
May 2014: =C2=A0 =C2=A0WG LC on a standardized nomenclature for JSON
June 2014: =C2=A0 IETF LC on a restricted profile of JSON
June 2014: =C2=A0 IETF LC on a standardized nomenclature for JSON

-----END CHARTER-----


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--001a11c2cc40afe79204f1d92f4d-- From tbray@textuality.com Fri Feb 7 15:20:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DA81A0508 for ; Fri, 7 Feb 2014 15:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 9D3cSdiM-_fw for ; Fri, 7 Feb 2014 15:20:03 -0800 (PST) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 126A51AD67C for ; Fri, 7 Feb 2014 15:20:02 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id o7so951383vbn.29 for ; Fri, 07 Feb 2014 15:20:02 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=T002RVq7mI8jQr5Eo+PxYzeI4Ma2gNoRzfsNSeLwV4A=; b=LGA3fn2shsUNZOp62VXygzNrI8khSPzAf5Tdh9WatA26mb+hduGOfmHdl7W9YITFIv DRBGPhVVVPftvpDZloL7n1zAuUFkgF/bkk2OyCmGu5rodYWdtOlx5Am+6sZ7497pr7/C jwvy+wTetC3/f44h5XvBz+5kP9ytFyQnL0GruIJIT/pyd0rwJ6/KvcUw+MTLxBhzZVHO GwCVb4KWH2+vomyvst7irsSVmejxNJ7fEti70/8nS+JZT1uq/DdS4SEL5KxSG9tg+5XB SUBlOGmRY8pfkQNiIkjuumZYq/7/KimOwtP1+I0xIbVipiCNJJY1kAS6Fzn16LGW8i+V gwtw== X-Gm-Message-State: ALoCoQlTcKFU+1KtVyokCchzFjD4nE57Co3B6C9ikB/HXOj8amQIVR840/L//QNVeaQUb13mca7q MIME-Version: 1.0 X-Received: by 10.52.118.33 with SMTP id kj1mr6780819vdb.33.1391815202253; Fri, 07 Feb 2014 15:20:02 -0800 (PST) Received: by 10.220.98.73 with HTTP; Fri, 7 Feb 2014 15:20:02 -0800 (PST) X-Originating-IP: [24.114.79.168] Received: by 10.220.98.73 with HTTP; Fri, 7 Feb 2014 15:20:02 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Fri, 7 Feb 2014 15:20:02 -0800 Message-ID: From: Tim Bray To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e01295338bf786904f1d93a76 Cc: Paul Hoffman , json@ietf.org Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Feb 2014 23:20:11 -0000 --089e01295338bf786904f1d93a76 Content-Type: text/plain; charset=UTF-8 On 7 Feb 2014 17:54, "Phillip Hallam-Baker" wrote: > > > > Does a 'standardized nomenclature for JSON' mean formal languages are in or out of scope? Don't know what you mean by Formal Languages in this context, but schemas are clearly out of scope. > > If schemas are in scope then I can't see us completing by May 2014. > > My schema tool now allows the specification to be defined in a very clean syntax that is similar to python (no braces, indentation denotes block structure). > > It generates xml2rfc, C# and now C code to implement a client and server stub library. Runs on all major platforms. > > OK the C library needs more work, the parser is fine but its not got the Web service wrapper yet. > > > If all we are doing is specifying how to describe the JSON elements in a spec then I will simply wait for the output and then make my specification generator write conforming text. > > Some issues that have come up recently are how to manage NaN values for numeric fields. I think the only clean way to do this in JSON is with the null lexeme > > > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e01295338bf786904f1d93a76 Content-Type: text/html; charset=UTF-8


On 7 Feb 2014 17:54, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
>
>
>
> Does a 'standardized nomenclature for JSON' mean formal languages are in or out of scope?

Don't know what you mean by Formal Languages in this context, but schemas are clearly out of scope.

>
> If schemas are in scope then I can't see us completing by May 2014.
>
> My schema tool now allows the specification to be defined in a very clean syntax that is similar to python (no braces, indentation denotes block structure).
>
> It generates xml2rfc, C# and now C code to implement a client and server stub library. Runs on all major platforms.
>
> OK the C library needs more work, the parser is fine but its not got the Web service wrapper yet.
>
>
> If all we are doing is specifying how to describe the JSON elements in a spec then I will simply wait for the output and then make my specification generator write conforming text.
>
> Some issues that have come up recently are how to manage NaN values for numeric fields. I think the only clean way to do this in JSON is with the null lexeme
>
>
>
> --
> Website: http://hallambaker.com/
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--089e01295338bf786904f1d93a76-- From hallam@gmail.com Fri Feb 7 16:57:55 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A83D1AD8EE for ; Fri, 7 Feb 2014 16:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GpxMi3iFzmGL for ; Fri, 7 Feb 2014 16:57:53 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 40E5E1A01E6 for ; Fri, 7 Feb 2014 16:57:53 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so3260171lbv.10 for ; Fri, 07 Feb 2014 16:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kCG2b/KezJjzntGwh2qqndaVT1agVHNi2cnckc8jM88=; b=iNHl6ycXWBquGSFXDQPeAOvwKsLpnbreo3w8CibyMHqkslZqXUlzvWMGzJdt8a/Pr4 lJmRwmGPggB8zYPvWpx0YL9+lSE6za8AQ5dU57ZcCxHYpaTsSx0WVaqWHqdxJQXxFoqQ +dT8uOH8GLDcBEVprigwmIo2XJQnVvmZey6dn7FjRFzOvSRo1PYkkwK0l52zfVvHFzzJ tlme8w9xMyKBbYeJWEjMNiTh3aKwGxgd+fChVIrzEsaVNWJnwpo0NdulOQ3LZoAFTLzY ebkaAWskwgYmPMKFIIdGa+VdUZs1deSi28aGX5g0ek/gqhMNQBON+HSvxBR6anj9IHap tgYw== MIME-Version: 1.0 X-Received: by 10.152.120.201 with SMTP id le9mr32696lab.68.1391821072255; Fri, 07 Feb 2014 16:57:52 -0800 (PST) Received: by 10.112.37.168 with HTTP; Fri, 7 Feb 2014 16:57:52 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Fri, 7 Feb 2014 19:57:52 -0500 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=089e012278449a4dfb04f1da984f Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 00:57:55 -0000 --089e012278449a4dfb04f1da984f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray wrote: > > On 7 Feb 2014 17:54, "Phillip Hallam-Baker" wrote: > > > > > > > > Does a 'standardized nomenclature for JSON' mean formal languages are in > or out of scope? > > Don't know what you mean by Formal Languages in this context, but schemas > are clearly out of scope. > By formal language I mean a machine readable description of the data structure that specifies the tag names and the set of corresponding values. http://sourceforge.net/p/prismproof/code/ci/master/tree/PrismProof/Registration/KeyFile.protocol Protocol Goedel.KeyFile KeyStore Structure KeyEntry Structure Key Inherits KeyEntry String KeyID Description |Key Identifier in text form. Struct Certificate SelfCertificates Multiple Description -- Website: http://hallambaker.com/ --089e012278449a4dfb04f1da984f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray <tbray@textuality.com<= /a>> wrote:


On 7 Feb 2014 17:54, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
>
>
>
> Does a 'standardized nomenclature for JSON' mean formal langua= ges are in or out of scope?

Don't know what you mean by Formal Languages in th= is context, but schemas are clearly out of scope.

By = formal language I mean a machine readable description of the data structure= that specifies the tag names and the set of corresponding values.




Protocol Goedel.KeyFile KeyStore

	Structure KeyEntry

	Structure Key
		Inherits			KeyEntry
		String				KeyID
			Description
				|Key Identifier	in text form.		=09
		Struct Certificate	SelfCertificates
			Multiple
			Description

--
Website: http://hallambaker.com/
--089e012278449a4dfb04f1da984f-- From nico@cryptonector.com Fri Feb 7 17:03:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F591AD8F5 for ; Fri, 7 Feb 2014 17:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 FdLUQ7FasaNv for ; Fri, 7 Feb 2014 17:03:04 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2922F1AD8EE for ; Fri, 7 Feb 2014 17:03:04 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id F1A2F286058 for ; Fri, 7 Feb 2014 17:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=u4CZHU9Wnu7bdSZxeS0l HpCYOds=; b=BVeS11ziUOETVDji8+cRsLEaLstzeWwQ73xW3u22uxNRWxdw/L7s 71MiT2Oo3Fra4RAfLBjXswQFg/9lV7v+NG8VovcwsImFLVjsISFU3pMsP4j/Nd5m CosN8o9Tkf3pRV0BvVQ70ncS9125kpRsLTSZKJ0kZmawuxHMX9qaPM8= Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id D297228600C for ; Fri, 7 Feb 2014 17:03:03 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id kp14so3899974pab.9 for ; Fri, 07 Feb 2014 17:03:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pPecX+0yTAhcN0ZvrblVvFTxGgWZNrw4BcqW7t1QaL4=; b=Hcl1OP/Yjhgr2BtXEyESXnQryYZSZZNXxrlbaXG12F+VEvSlCijcsQTOT/9D/Fzdq/ seyIrsBfLO2dkoXPNrtA5DUCOy0hadD4YMCifU8EdXW0qVrZYRuiKahjaRFhFn+fu9/e PrS1ARZ0+WCTFsQAqpJs6252nz9GtAhSFwqO8YMqzU5d4gwiNQLd4JJv9JBlDv1ah1ii A3N9tPIXg6C2dXFpmhKp3bKKvdOYr1LyacwULvvFY50LWE7MntWiCV/u9xr+ghpZed7z N91P3HTHMmR7QlUiA7FSqSe2GZcCI0b3b8jJVdhgNzFtDw1yAKvhhXZNA0Y0vWESSxrd RtuQ== MIME-Version: 1.0 X-Received: by 10.66.194.2 with SMTP id hs2mr11228671pac.79.1391821382237; Fri, 07 Feb 2014 17:03:02 -0800 (PST) Received: by 10.68.36.164 with HTTP; Fri, 7 Feb 2014 17:03:02 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Fri, 7 Feb 2014 19:03:02 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 01:03:05 -0000 On Fri, Feb 7, 2014 at 6:57 PM, Phillip Hallam-Baker wrote: > On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray wrote: >> On 7 Feb 2014 17:54, "Phillip Hallam-Baker" wrote: >> > Does a 'standardized nomenclature for JSON' mean formal languages are in >> > or out of scope? >> >> Don't know what you mean by Formal Languages in this context, but schemas >> are clearly out of scope. > > By formal language I mean a machine readable description of the data > structure that specifies the tag names and the set of corresponding values. That's schema. One (or more) schema representations for JSON would be nice, yes. Note that ABNF is a formal language, but not what you're after, which is why I would have asked the question Tim asked. Nico -- From tbray@textuality.com Fri Feb 7 17:14:51 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98311AD73F for ; Fri, 7 Feb 2014 17:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 mGbw4w0NXPd1 for ; Fri, 7 Feb 2014 17:14:50 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id F3DDB1A01E6 for ; Fri, 7 Feb 2014 17:14:49 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so3355230veb.14 for ; Fri, 07 Feb 2014 17:14:49 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=9tsuDwfZdRhcBFg3dVvMC3J8P4ON3rZTUhEGxPt/xTA=; b=liBex6476vWDNZH2UlDlyA1RpEipHS79YXD2slYoUrjGxJp1sqU+jFIKThYBQxAhpH +hm5pPkbH3C48SAckZ79flM9qKD69x50wqesR+aBugGltPo+LWBLgkS+1meRCI6NUzgc B7wbk4v8CDfpyC0DI3hXeynPiqhMbQ+/qCY5hGRImu4u04QiBqG1pPo3wqsruXvhlnSk jXlKXUudDYgQvWE6hCI6kO1FYA5zlGfmFhwhA4Oy/EoU7yFxJl+0nTwlAicTfPbGyt8h cUzFR6dKjDRcx//LbfEZuq8slzJmDqnL6wA+i0fuFkRgce7Gpek2A1luoDsDF2B5Thmp VT4Q== X-Gm-Message-State: ALoCoQlwoZPZXato7MRdSYjYUWTcwzG3PJnuPSyjev4krIV0d3A3NxvrePuhvbLhc4wg2+uCxcAO MIME-Version: 1.0 X-Received: by 10.221.29.137 with SMTP id ry9mr12883170vcb.6.1391822089603; Fri, 07 Feb 2014 17:14:49 -0800 (PST) Received: by 10.220.98.73 with HTTP; Fri, 7 Feb 2014 17:14:49 -0800 (PST) X-Originating-IP: [24.114.79.168] Received: by 10.220.98.73 with HTTP; Fri, 7 Feb 2014 17:14:49 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Fri, 7 Feb 2014 17:14:49 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=001a1133935c3de20504f1dad54f Cc: Phillip Hallam-Baker , Paul Hoffman , json@ietf.org Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 01:14:52 -0000 --001a1133935c3de20504f1dad54f Content-Type: text/plain; charset=UTF-8 I really want to stay away from the slippery schema slope. So I do not think we're trying to be ABNF for JSON, because that is in fact a simple lexical schema. In a spec sentence like this: The value of the "size" member of the top level "buffer" item MUST be a non-negative integer. I think nomenclature means having a uniform standardised way to express the meaning of the words between "value of" and "MUST". Perhaps something like XPath for JSON. Disclosure: I'm not convinced this is necessary or even useful. On 7 Feb 2014 20:03, "Nico Williams" wrote: > On Fri, Feb 7, 2014 at 6:57 PM, Phillip Hallam-Baker > wrote: > > On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray wrote: > >> On 7 Feb 2014 17:54, "Phillip Hallam-Baker" wrote: > >> > Does a 'standardized nomenclature for JSON' mean formal languages are > in > >> > or out of scope? > >> > >> Don't know what you mean by Formal Languages in this context, but > schemas > >> are clearly out of scope. > > > > By formal language I mean a machine readable description of the data > > structure that specifies the tag names and the set of corresponding > values. > > That's schema. One (or more) schema representations for JSON would be > nice, yes. > > Note that ABNF is a formal language, but not what you're after, which > is why I would have asked the question Tim asked. > > Nico > -- > --001a1133935c3de20504f1dad54f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I really want to stay away from the slippery schema slope. S= o I do not think we're trying to be ABNF for JSON, because that is in f= act a simple lexical schema.=C2=A0 In a spec sentence like this:

The value of the "size" member of the top level &= quot;buffer" item MUST be a non-negative integer.

I think nomenclature means having a uniform standardised way= to express the meaning of the words between "value of" and "= ;MUST".=C2=A0 Perhaps something like XPath for JSON.

Disclosure: I'm not convinced this is necessary or even = useful.

On 7 Feb 2014 20:03, "Nico Williams" &= lt;nico@cryptonector.com> w= rote:
On Fri, Feb 7, 2014 at 6:57 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray <tbray@textuality.com> wrote:
>> On 7 Feb 2014 17:54, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
>> > Does a 'standardized nomenclature for JSON' mean form= al languages are in
>> > or out of scope?
>>
>> Don't know what you mean by Formal Languages in this context, = but schemas
>> are clearly out of scope.
>
> By formal language I mean a machine readable description of the data > structure that specifies the tag names and the set of corresponding va= lues.

That's schema. =C2=A0One (or more) schema representations for JSON woul= d be
nice, yes.

Note that ABNF is a formal language, but not what you're after, which is why I would have asked the question Tim asked.

Nico
--
--001a1133935c3de20504f1dad54f-- From stefan@drees.name Sat Feb 8 03:41:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FE21A1E0D for ; Sat, 8 Feb 2014 03:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 tTWE2VKuChvR for ; Sat, 8 Feb 2014 03:41:37 -0800 (PST) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id E643F1A00C4 for ; Sat, 8 Feb 2014 03:41:36 -0800 (PST) Received: from newyork.local.box ([80.187.101.162]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MDgDS-1VzTEH36Tu-00H9AV for ; Sat, 08 Feb 2014 12:41:35 +0100 Message-ID: <52F617ED.2060605@drees.name> Date: Sat, 08 Feb 2014 12:41:33 +0100 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Hoffman , IETF JSON WG References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> In-Reply-To: <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1lfNEbRZAw67HqcmQxvtqR46IIiuYz8zuGSiNnRf9Y7hMMBS3AN i4PP+35Gk4L2YT2wuFoFDid4QDbZdyOZCbJ85wQy7ncGfyqIoEU+n7mPFwgcNKV39STdXGU x92ylQ2A/AohD9DHNXcNgiKJYr6xhVtUD3Bx+UENolHr4kRYulx1NqIwRjYd+B3/0KNh54s 2O/yDoZh8LNxDnfDPAomg== Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 11:41:38 -0000 On 2014-02-07 23:32 +01:00, Paul Hoffman wrote: > First off: I dropped the ball on this one. I told Matt I would follow up, and now I am doing so, but terribly late. > > People felt that our two work items didn't match what we had discussed over the past few months. Below is another run at the proposed wording. > > --Paul Hoffman > > -----BEGIN CHARTER----- > > Javascript Object Notation (JSON) is a lightweight, text-based, > language-independent data interchange format. It was derived from the > ECMAScript Programming Language Standard and was published in RFC 4627, > an Informational document. JSON has come into very broad use, often > instead of or in addition to XML. The JSON WG has already published > a standards-track update to RFC 4627. > > The WG will work on two items: > > - a restricted profile of JSON designed to maximize interoperability; > the starting point will be draft-bray-i-json > > - a standardized nomenclature for referring to the constructs in a > JSON text, for use by those specifying protocols with JSON payloads > > Milestones: > > May 2014: WG LC on a restricted profile of JSON > May 2014: WG LC on a standardized nomenclature for JSON > June 2014: IETF LC on a restricted profile of JSON > June 2014: IETF LC on a standardized nomenclature for JSON > > -----END CHARTER----- +1 from me as long as we stay away far enough from any schema "death star" and most of us interpret "standardized nomenclature" as """In a spec sentence like this: The value of the "size" member of the top level "buffer" item MUST be a non-negative integer. I think nomenclature means having a uniform standardised way to express the meaning of the words between "value of" and "MUST". Perhaps something like XPath for JSON. """ (citing Tim Bray, who put it that way) {"Stefan": true} From nico@cryptonector.com Sat Feb 8 14:50:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC14B1A0630 for ; Sat, 8 Feb 2014 14:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 9vUa1E_yOQvL for ; Sat, 8 Feb 2014 14:50:15 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1181E1A0631 for ; Sat, 8 Feb 2014 14:50:14 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 408252005D105 for ; Sat, 8 Feb 2014 14:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dLg5XYFrBVAq0o26tlWz Ep2Kstk=; b=bXUf2tjY8Xx8sCTF6I50qb5X4o8hMeoCPtDVG6l6ODb5us3E0g47 am+Q+k6b0JbU0s0uJb44lXpVzviTuNt38OOcxKk1NWoFyUcJr9Xz7pOoUle0QIGj D4WGPdP1geXBK3rTMxGG0/6E14Gbe5He376B4ryCbPhRBASlOmo7jEk= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id E9EFA2005D100 for ; Sat, 8 Feb 2014 14:50:14 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id q58so3205445wes.21 for ; Sat, 08 Feb 2014 14:50:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+kmp0wWbDsnGN/tWeb/JI0h45ZM6XzqsKrXieqKd2dM=; b=Kz/Pz+FI9iEdnLTJ9MCsRNMQxh2nASvUNaJokepjap1bIQaDOaXVgTjmnC17PZMJPu Zzojb2+oBDB1ITLuUNjg/HZhukTiGZpMZ5FQ8mVzUUvM5s4FRSFpYw6mAiIsYJICGP8W X5tZMktBU44c7ds8OaN13L/6WEbqZbVx+IYyL93KSQwQYiALFQtB2N4f29OTTax5pUd9 FwlHsbvEfNPn9Yqp+j/dQ03+zLTapJwyL3KAZPNnDAVwRzGGGOi6fQEzrgi6bCLAyEm+ hOnSIVwpVqDWe0GHheMrCRcMbCRursdhybLf2yFb3ugtbulMJwehWTvabF17h6V9KEdc X09g== MIME-Version: 1.0 X-Received: by 10.180.108.199 with SMTP id hm7mr4881738wib.1.1391899813257; Sat, 08 Feb 2014 14:50:13 -0800 (PST) Received: by 10.227.198.69 with HTTP; Sat, 8 Feb 2014 14:50:13 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Sat, 8 Feb 2014 16:50:13 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 22:50:18 -0000 On Fri, Feb 7, 2014 at 7:14 PM, Tim Bray wrote: > I really want to stay away from the slippery schema slope. [...] > > I think nomenclature means having a uniform standardised way to express the > meaning of the words between "value of" and "MUST". Perhaps something like > XPath for JSON. An XPath/XSLT for JSON would be good. There's a great candidate for that: http://stedolan.github.io/jq . But I don't propose standardizing such a thing. > Disclosure: I'm not convinced this is necessary or even useful. Schemas help document protocols. They are as useful as ABNF, ASN.1, and so on. In practice we can't get to where we have 100% formal descriptions of everything relevant to interop, but a total lack of formality isn't exactly a good thing either. In absence of a JSON schema language (or three) we'll have to resort to showing examples and English prose for the rest. Nico -- From tbray@textuality.com Sat Feb 8 15:10:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C231A063D for ; Sat, 8 Feb 2014 15:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 acQ7dcH-Dbb7 for ; Sat, 8 Feb 2014 15:10:26 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7C50F1A0639 for ; Sat, 8 Feb 2014 15:10:26 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id g10so3808225vbg.0 for ; Sat, 08 Feb 2014 15:10:26 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=aBhMa+TAAp7XdkTkn6Hib1vdKylRZQa64KLesU31THM=; b=aZN4H91TjofuiAWXky4CggCt+1KZL1rbOaChUEvJiz53sCEwy85o4Jgus8YNKoFThf c/yuGTU1uTY+UzdN5lxvvNDhp8Y1hRud9X4C2xZxocUjuntAINpGTWy6NdX3plnYLUyx 1wq/T8XjOtnbPtxGHZuubvDs6NNR41BWAh4uYrnNN/ej5IYLIefjbK7Cw5eudRITAjMc m67yFW8duXUsfdnYKOlQsy2HSVoJjuNa2hMjV/hPxSAgOG6FO8HRpz7aHjpWTwt003ZX V5a9SyswAvM8E1UfJ0SDPDIJmg5aVFgW0bBq1cgnWgBCdbl8lrXxUqPqGM06dRU/qQYH j0Kg== X-Gm-Message-State: ALoCoQlj+oGdRPjMdq1xsyG2Abr5GF6X9e2i9qLTz1rmvrSe2Zi/eGdScBtvgVnw3eWINvWv/L6B MIME-Version: 1.0 X-Received: by 10.52.121.113 with SMTP id lj17mr14377777vdb.21.1391901026661; Sat, 08 Feb 2014 15:10:26 -0800 (PST) Received: by 10.220.98.73 with HTTP; Sat, 8 Feb 2014 15:10:26 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Sat, 8 Feb 2014 15:10:26 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=089e0122f1ca41cba104f1ed3647 Cc: Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 23:10:29 -0000 --089e0122f1ca41cba104f1ed3647 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams wrote: > In absence of a JSON > schema language (or three) we'll have to resort to showing examples > and English prose for the rest. > Another excellent reason not to have a JSON schema language. I think that the very best protocol specs center around clear English prose and well-chosen illustrative examples, and schema cleverness is often a distraction from getting that right. > > Nico > -- > --089e0122f1ca41cba104f1ed3647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Feb 8, 2014 at 2:50 PM, Nico Williams <nico@cryptonector.com&g= t; wrote:
=C2=A0
=C2=A0In absence of a JSON<= br> schema language (or three) we'll have to resort to showing examples
and English prose for the rest.

Another= excellent reason not to have a JSON schema language. =C2=A0I think that th= e very best protocol specs center around clear English prose and well-chose= n illustrative examples, and schema cleverness is often a distraction from = getting that right.
=C2=A0

Nico
--

--089e0122f1ca41cba104f1ed3647-- From nico@cryptonector.com Sat Feb 8 15:52:27 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243901A0646 for ; Sat, 8 Feb 2014 15:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 1EKQwML_95jZ for ; Sat, 8 Feb 2014 15:52:25 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C6ECB1A041B for ; Sat, 8 Feb 2014 15:52:25 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 7080D40122130 for ; Sat, 8 Feb 2014 15:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Bq4MthAn8dZRHrRrvIy1 e1DMj5Y=; b=QoyND2I3tBC74tDlw/hsLwdjt9S755r0fyhvL7bDmbZgGtYFVstN hbYwfvZgNnQR83R6o+++of//U7x54lFfS5HYjVP6ZCAuRvhP1GA1TS1D4gKPNEyb JVacTJM+ziTUQavy3ND9h6dvWjXsJHy/n4zVaQyKf1vnKN4ZewNJsXg= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 1B14D4012210B for ; Sat, 8 Feb 2014 15:52:24 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so3182452wgg.1 for ; Sat, 08 Feb 2014 15:52:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ceLS2r6RhOvhls5rpyl+SzG69EAHSF2R7ma68BaILHI=; b=IGjCVaMSOXrqol8w0kwe7Rv0dJaRzjDT3PrhiZr2Vz3DLgqsXcXnEWJ9Pw7x4sOahZ lEN4elw8cxnF1CJKPHitF3u63vt0W3sAqEiwEN39+yyncZa9WfgVP2xp9S8p4qZgGIST qBbbb/h5Zj2/Kcp8hSvCgksf3CaXe0tjEKZxzxzNVCsEG0AwwHvXS6QuH/GN4YE2+63A 79QnA5ek9abp5x1/Tocaf/10kU60ngwpnsGQf84pDPrnLglRp+gqI+h4jTBkQXoOpiv2 lA2p4SYiJlHDxiv3f/7jwgIVBUpn5tVA9rMGji1vnMQc0AhdMAbYtW6J7q4IyPTj3+Ik Je/g== MIME-Version: 1.0 X-Received: by 10.180.108.199 with SMTP id hm7mr5009210wib.1.1391903543492; Sat, 08 Feb 2014 15:52:23 -0800 (PST) Received: by 10.227.198.69 with HTTP; Sat, 8 Feb 2014 15:52:23 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Sat, 8 Feb 2014 17:52:23 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 23:52:27 -0000 On Sat, Feb 8, 2014 at 5:10 PM, Tim Bray wrote: > On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams wrote: >> In absence of a JSON >> schema language (or three) we'll have to resort to showing examples >> and English prose for the rest. > > Another excellent reason not to have a JSON schema language. I think that > the very best protocol specs center around clear English prose and > well-chosen illustrative examples, and schema cleverness is often a > distraction from getting that right. It depends on whether the schema language is easy to build tools for or not. ASN.1 (with all its complexity, including its encoding rules, the IOS and the related SDL) is an example of a language which is not easy to build tools for. We're in a much simpler space here, not because we lack schema for JSON but because we'd not port all the complexity of ASN.1 to a JSON schema. We know better. Also, for a great many implementors the JSON tools at their disposal (e.g., ECMAScript) make it easy to write schema-based tools, such as code generators and schema validators. Besides that, English prose is difficult to write in such a way that it will be understood clearly by the many readers for whom English is not a native/first language. I don't ever stop to think about non-native English readers of my prose and I'm not a native English speaker. I can see that English convenient for those of us who've mastered it well enough, and it is today's lingua franca, but I'd rather have a bit of formalism to go with the text. Also, I personally find some entirely-prose RFCs (like RFC4422) to be difficult to read -- think of formalism as a crutch if you like, but it's a very convenient crutch, helping readers, implementors, and the authors themselves. Nico -- From tbray@textuality.com Sat Feb 8 15:52:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2051A0641 for ; Sat, 8 Feb 2014 15:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 oRPDS8L7z42n for ; Sat, 8 Feb 2014 15:52:47 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 842FD1A041B for ; Sat, 8 Feb 2014 15:52:47 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hu8so3827704vcb.29 for ; Sat, 08 Feb 2014 15:52:47 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=b1J9eT2IFbkw8bxkNMyZPVjJ8DTW0DyWoGMQ7QRjKXI=; b=Hc4EIr36eCQ+Z2ZtY8ez1DUYL6cwwsAJatTvx9DQEBFWYSN8J4rBM4fAxRj+sYq3Q0 VThpRNvb+HCQZOo0cV+GpcCmuTHR66Z5+V9xNV5la9HpnhmKlneot1Yu7KdSSxe5u9x0 ZnhY9kOw9ygpPBT/DDEziJpBdfrqidD0bD3kV/OINcJMUUGVZ2Y6ht7OG9xt6rqVtGV9 xGmqwQmoqSqE5p5FY0O03Ml7/CWR7J2wL1qkltgWV12AoX7wf5Jx5zxs3OFvlmmHWXh4 EM8phdrwdJ4FGa+7p7XPVGIfTca7JZ94mgE4vBGtdD4D9AdK+9dKLPB5DHjzvwbrgd4l 65HA== X-Gm-Message-State: ALoCoQlgsB03FnbCUw9OjFY5Qe4GPpJUtBmaA0iB5jk2w9fF+uCK6kxsCCpM9PH6Xxpds/cVap/y MIME-Version: 1.0 X-Received: by 10.58.169.7 with SMTP id aa7mr2753vec.24.1391903567606; Sat, 08 Feb 2014 15:52:47 -0800 (PST) Received: by 10.220.98.73 with HTTP; Sat, 8 Feb 2014 15:52:47 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Sat, 8 Feb 2014 15:52:47 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b6dcf42b58a0d04f1edcda6 Cc: Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 23:52:49 -0000 --047d7b6dcf42b58a0d04f1edcda6 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams wrote: > > An XPath/XSLT for JSON would be good. There's a great candidate for > that: http://stedolan.github.io/jq . jq seems like overkill. Wow, would it ever be easy to do a JSON path selector. They practically read themselves "buffer"/"size" //"size" //"buffers"/./"size" //"buffers"/0/"size" //"buffers"/-1/. "buffer"/./"key" But I don't propose > standardizing such a thing. > > > Disclosure: I'm not convinced this is necessary or even useful. > > Schemas help document protocols. They are as useful as ABNF, ASN.1, > and so on. In practice we can't get to where we have 100% formal > descriptions of everything relevant to interop, but a total lack of > formality isn't exactly a good thing either. In absence of a JSON > schema language (or three) we'll have to resort to showing examples > and English prose for the rest. > > Nico > -- > --047d7b6dcf42b58a0d04f1edcda6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Feb 8, 2014 at 2:50 PM, Nico Williams <nico@cryptonector.com&g= t; wrote:

An XPath/XSLT for JSON would be good. =C2=A0There's a great candi= date for
that: http://ste= dolan.github.io/jq . =C2=A0

jq seems li= ke overkill. Wow, would it ever be easy to do a JSON path selector. =C2=A0 = They practically read themselves

"buffer"/"size"
//"s= ize"
//"buffers"/./"size"
//&q= uot;buffers"/0/"size"
//"buffers"/-1/.
"buffer"/./"key"

But I don't propose
standardizing such a thing.

> Disclosure: I'm not convinced this is necessary or even useful.
Schemas help document protocols. =C2=A0They are as useful as ABNF, AS= N.1,
and so on. =C2=A0In practice we can't get to where we have 100% formal<= br> descriptions of everything relevant to interop, but a total lack of
formality isn't exactly a good thing either. =C2=A0In absence of a JSON=
schema language (or three) we'll have to resort to showing examples
and English prose for the rest.

Nico
--

--047d7b6dcf42b58a0d04f1edcda6-- From nico@cryptonector.com Sat Feb 8 16:22:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330811A0658 for ; Sat, 8 Feb 2014 16:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 HAVEqyLnQ_cX for ; Sat, 8 Feb 2014 16:22:24 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CFFFD1A0655 for ; Sat, 8 Feb 2014 16:22:24 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 5C227264057 for ; Sat, 8 Feb 2014 16:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=syHs4mD25vkHssodr/e5 vB+xobs=; b=yIxi0YuR7ZqNHwxNPohQLZ8UwL8Tnj5q8dTlwy5e1+Lac7Gs2CE1 U8vVyxxYx2BZ/dAsfunILnlOufk+WRnrQ4y9wjtzjVpqQdSiNzFBjWQIvCO8rzaR MzEldplAYdAskmUUDDyh5Yu80BbQwWENQC1u8l/3fnK8JtAu26f2H/Q= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 0EF4B264058 for ; Sat, 8 Feb 2014 16:22:24 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hi5so1787207wib.3 for ; Sat, 08 Feb 2014 16:22:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9sQr5r/O2zFWaUQQ602MJpWTdaKtapBAufZZbmYBxQs=; b=RlqC6hKdGwGraVAE+Z+CwW8ezsQDvRjgeuOzhOQUEQ+SuBmeCIbrSEUa4WCYVsa6dN RPoS4AxQyYhszIGfFW13geFi4V+uDeTtgSW/RPm85FHI8soWSsbVczg+xkAz3gxVrPpa yT2ark8Yi7CZp21YgiVJCXI/aUbaleJOu02OjPawIan/FqAKTbrJeUiIhw8o0gidKr20 Dal4SvV41xXJfhnkblQzRaRD0k9tohnOnAOLl45fld9c3lNvY2CmzdvvmpV5es+puac4 jZz62cpZ6hnIMBlRnV2BTuUvQ5ZW+U0o8f7sgZwZ8PUxPPJcKTTumAm3xUJ8yioVaO/x O0zA== MIME-Version: 1.0 X-Received: by 10.180.96.102 with SMTP id dr6mr4886523wib.61.1391905343332; Sat, 08 Feb 2014 16:22:23 -0800 (PST) Received: by 10.227.198.69 with HTTP; Sat, 8 Feb 2014 16:22:23 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Sat, 8 Feb 2014 18:22:23 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 00:22:26 -0000 On Sat, Feb 8, 2014 at 5:52 PM, Tim Bray wrote: > On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams wrote: >> An XPath/XSLT for JSON would be good. There's a great candidate for >> that: http://stedolan.github.io/jq . > > jq seems like overkill. Wow, would it ever be easy to do a JSON path > selector. They practically read themselves jq let's you do exactly that, and more too (just like XPath, and especially XSLT). It is missing an operator that trivially allows writing things like //"buffer"/"size", but it's not hard to write a utility function that allows it, and the manual has examples of this sort of thing using the recurse built-in. (I'll probably end up contributing such a thing; it'd make sense to parse ..buffer.size and turning it into a search for objects with a buffer name whose value is an object with a size name.) Nico -- From mnot@mnot.net Sat Feb 8 18:37:55 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D961A0678 for ; Sat, 8 Feb 2014 18:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 s9R_-8QX_hik for ; Sat, 8 Feb 2014 18:37:53 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9C1A0673 for ; Sat, 8 Feb 2014 18:37:53 -0800 (PST) Received: from [192.168.1.57] (unknown [118.209.70.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DECBD509B5; Sat, 8 Feb 2014 21:37:48 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: Date: Sun, 9 Feb 2014 13:37:41 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> To: Tim Bray X-Mailer: Apple Mail (2.1827) Cc: Nico Williams , Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 02:37:56 -0000 +1 I=92d be more comfortable if the charter were more explicit about this; = e.g., =93A set of natural-language terms and/or phrases for use in = future specifications that use JSON. This explicitly excludes schema = languages and similar formalisms.=94=20 On 8 Feb 2014, at 12:14 pm, Tim Bray wrote: > I really want to stay away from the slippery schema slope. So I do not = think we're trying to be ABNF for JSON, because that is in fact a simple = lexical schema. In a spec sentence like this: >=20 > The value of the "size" member of the top level "buffer" item MUST be = a non-negative integer. >=20 > I think nomenclature means having a uniform standardised way to = express the meaning of the words between "value of" and "MUST". Perhaps = something like XPath for JSON. >=20 > Disclosure: I'm not convinced this is necessary or even useful. >=20 > On 7 Feb 2014 20:03, "Nico Williams" wrote: > On Fri, Feb 7, 2014 at 6:57 PM, Phillip Hallam-Baker = wrote: > > On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray = wrote: > >> On 7 Feb 2014 17:54, "Phillip Hallam-Baker" = wrote: > >> > Does a 'standardized nomenclature for JSON' mean formal languages = are in > >> > or out of scope? > >> > >> Don't know what you mean by Formal Languages in this context, but = schemas > >> are clearly out of scope. > > > > By formal language I mean a machine readable description of the data > > structure that specifies the tag names and the set of corresponding = values. >=20 > That's schema. One (or more) schema representations for JSON would be > nice, yes. >=20 > Note that ABNF is a formal language, but not what you're after, which > is why I would have asked the question Tim asked. >=20 > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From hallam@gmail.com Sat Feb 8 19:01:06 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476811A0673 for ; Sat, 8 Feb 2014 19:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Qdhcg6f3F6vj for ; Sat, 8 Feb 2014 19:01:02 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 82DFD1A0678 for ; Sat, 8 Feb 2014 19:01:02 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so3882344lbd.9 for ; Sat, 08 Feb 2014 19:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=06rdTVZUNoOYoju1zeNyB+Iwwa07nTlnNxLsHMb9CbU=; b=venOEnTLCGQneS8EDnxA6NvBo/qUXhA6w+OFzvY5LBN7Y2LeP6Q8udVOZWIbBgkaR7 0FlceiuYG5zaT/itMZBNnLK2Toy6bLnDKfBPXcf/tzi552A0/RuEJVYHcDqZpq+Xyt/0 /owUjrcaCVLHJ/CLXnqV7WWEhmSMShQQ1Xp7McD5ocIyHGQDnVp2rlwF7pdQkvN9iUN/ UEvdNs4MSOCAL5BGpGriUkxV70u4NiBXo8eRF/ci3lTgWTCfTUa8uHVuskQQEWgv9kRG 5A35m/8akmXZ4rYEqqXqfMC/UAnyjIhkVeMNS56QRUf1zYFvt+jngeoJSnJY79Q0/HPp f1MA== MIME-Version: 1.0 X-Received: by 10.152.2.169 with SMTP id 9mr17388lav.48.1391914862203; Sat, 08 Feb 2014 19:01:02 -0800 (PST) Received: by 10.112.37.168 with HTTP; Sat, 8 Feb 2014 19:01:02 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Sat, 8 Feb 2014 22:01:02 -0500 Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: multipart/alternative; boundary=047d7ba9719aeb57bd04f1f06ea4 Cc: Nico Williams , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 03:01:06 -0000 --047d7ba9719aeb57bd04f1f06ea4 Content-Type: text/plain; charset=ISO-8859-1 Me too. I was asking if schema was in scope. I have no particular interest in having a committee redesign a tool that works perfectly well as it is. On Sat, Feb 8, 2014 at 9:37 PM, Mark Nottingham wrote: > +1 > > I'd be more comfortable if the charter were more explicit about this; > e.g., "A set of natural-language terms and/or phrases for use in future > specifications that use JSON. This explicitly excludes schema languages and > similar formalisms." > > > On 8 Feb 2014, at 12:14 pm, Tim Bray wrote: > > > I really want to stay away from the slippery schema slope. So I do not > think we're trying to be ABNF for JSON, because that is in fact a simple > lexical schema. In a spec sentence like this: > > > > The value of the "size" member of the top level "buffer" item MUST be a > non-negative integer. > > > > I think nomenclature means having a uniform standardised way to express > the meaning of the words between "value of" and "MUST". Perhaps something > like XPath for JSON. > > > > Disclosure: I'm not convinced this is necessary or even useful. > > > > On 7 Feb 2014 20:03, "Nico Williams" wrote: > > On Fri, Feb 7, 2014 at 6:57 PM, Phillip Hallam-Baker > wrote: > > > On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray wrote: > > >> On 7 Feb 2014 17:54, "Phillip Hallam-Baker" wrote: > > >> > Does a 'standardized nomenclature for JSON' mean formal languages > are in > > >> > or out of scope? > > >> > > >> Don't know what you mean by Formal Languages in this context, but > schemas > > >> are clearly out of scope. > > > > > > By formal language I mean a machine readable description of the data > > > structure that specifies the tag names and the set of corresponding > values. > > > > That's schema. One (or more) schema representations for JSON would be > > nice, yes. > > > > Note that ABNF is a formal language, but not what you're after, which > > is why I would have asked the question Tim asked. > > > > Nico > > -- > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham http://www.mnot.net/ > > > > -- Website: http://hallambaker.com/ --047d7ba9719aeb57bd04f1f06ea4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Me too.

I was asking if schema was in s= cope. I have no particular interest in having a committee redesign a tool t= hat works perfectly well as it is.

On Sat, Feb 8, 2014 at 9:37 PM, Mark Notting= ham <mnot@mnot.net> wrote:
+1

I’d be more comfortable if the charter were more explicit about this;= e.g., “A set of natural-language terms and/or phrases for use in fut= ure specifications that use JSON. This explicitly excludes schema languages= and similar formalisms.”


On 8 Feb 2014, at 12:14 pm, Tim Bray <tbray@textuality.com> wrote:

> I really want to stay away from the slippery schema slope. So I do not= think we're trying to be ABNF for JSON, because that is in fact a simp= le lexical schema.  In a spec sentence like this:
>
> The value of the "size" member of the top level "buffer= " item MUST be a non-negative integer.
>
> I think nomenclature means having a uniform standardised way to expres= s the meaning of the words between "value of" and "MUST"= ;.  Perhaps something like XPath for JSON.
>
> Disclosure: I'm not convinced this is necessary or even useful. >
> On 7 Feb 2014 20:03, "Nico Williams" <nico@cryptonector.com> wrote:
> On Fri, Feb 7, 2014 at 6:57 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> > On Fri, Feb 7, 2014 at 6:20 PM, Tim Bray <tbray@textuality.com> wrote:
> >> On 7 Feb 2014 17:54, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
> >> > Does a 'standardized nomenclature for JSON' mean= formal languages are in
> >> > or out of scope?
> >>
> >> Don't know what you mean by Formal Languages in this cont= ext, but schemas
> >> are clearly out of scope.
> >
> > By formal language I mean a machine readable description of the d= ata
> > structure that specifies the tag names and the set of correspondi= ng values.
>
> That's schema.  One (or more) schema representations for JSON= would be
> nice, yes.
>
> Note that ABNF is a formal language, but not what you're after, wh= ich
> is why I would have asked the question Tim asked.
>
> Nico
> --
> __________________________________________= _____
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham   h= ttp://www.mnot.net/






--
Website: http://hallambaker.com/
--047d7ba9719aeb57bd04f1f06ea4-- From paul.hoffman@vpnc.org Sat Feb 8 19:13:20 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0701A0679 for ; Sat, 8 Feb 2014 19:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 jM-zbF6shMQA for ; Sat, 8 Feb 2014 19:13:19 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 944121A060B for ; Sat, 8 Feb 2014 19:13:19 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s193DHiA012464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Feb 2014 20:13:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Sat, 8 Feb 2014 19:13:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> To: JSON WG X-Mailer: Apple Mail (2.1827) Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 03:13:21 -0000 On Feb 8, 2014, at 6:37 PM, Mark Nottingham wrote: > I=92d be more comfortable if the charter were more explicit about = this; e.g., =93A set of natural-language terms and/or phrases for use in = future specifications that use JSON. This explicitly excludes schema = languages and similar formalisms.=94=20 Do the folks who earlier +1'd the proposed text like Mark's = reformulation? --Paul Hoffman= From tbray@textuality.com Sat Feb 8 19:40:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F971A0680 for ; Sat, 8 Feb 2014 19:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Px2DjmxsvEah for ; Sat, 8 Feb 2014 19:40:14 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 096CE1A067D for ; Sat, 8 Feb 2014 19:40:13 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id oz11so3935825veb.21 for ; Sat, 08 Feb 2014 19:40:14 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=cn6/VoZg2Lm95pv4ZTlaukaJ3aEfp10uIzJEcOcXd2k=; b=ZYUH//wImpvA5YSAiM/fxiBf7U1vbDzqaMj4G1E+XVWKRwjtznFpX+6jIVGu/5PEjI N+Oerx1LKK07kK7IrDyKaO64wFDsTvC41kgfUUOJF1Vxd9XlFOWXHEgr9q+euXHiwyi8 ofeCpv2/J+HJs0gSjVN/E5M5IbBz/HmiHXqLaENt3UaR2oEPUoqvU4KXoGuI42AkvMhR tKzKwu8A8PWENTb15hqv6pz8EF3DBOAE1nLf/fk2KaP9gd9uN+2oZ8eDiSNtf8ZSdeTx yxpVVJKj3WX3dIVNr9GGkYHbo6kDi99VURr1Y6+m9jPg0KahSLpx6hNpoSv9ovv1R7Wz YrlQ== X-Gm-Message-State: ALoCoQmVwGlxDgVFPP1lVaQ4ArwlVhtzP2O+aW0k/sHoWcrqG0z6gHXg+Mr+/jZGFxzChjgZi3qR MIME-Version: 1.0 X-Received: by 10.58.200.168 with SMTP id jt8mr281667vec.30.1391917213912; Sat, 08 Feb 2014 19:40:13 -0800 (PST) Received: by 10.220.98.73 with HTTP; Sat, 8 Feb 2014 19:40:13 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> Date: Sat, 8 Feb 2014 19:40:13 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7bd6bd7617a29304f1f0fbdb Cc: JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 03:40:16 -0000 --047d7bd6bd7617a29304f1f0fbdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Partly. I don=E2=80=99t see why we have to write natural-language into the = charter, maybe we should do XPath-ish. So how about leaving it the way it was with =E2=80=9Cnomenclature=E2=80=9D and add on Mark=E2=80=99s =E2=80=9CThis expl= icitly excludes schema languages and similar formalisms.=E2=80=9D On Sat, Feb 8, 2014 at 7:13 PM, Paul Hoffman wrote: > On Feb 8, 2014, at 6:37 PM, Mark Nottingham wrote: > > > I=E2=80=99d be more comfortable if the charter were more explicit about= this; > e.g., =E2=80=9CA set of natural-language terms and/or phrases for use in = future > specifications that use JSON. This explicitly excludes schema languages a= nd > similar formalisms.=E2=80=9D > > Do the folks who earlier +1'd the proposed text like Mark's reformulation= ? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7bd6bd7617a29304f1f0fbdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Partly. I don=E2=80=99t see why we have to write natural-l= anguage into the charter, maybe we should do XPath-ish. =C2=A0So how about = leaving it the way it was with =E2=80=9Cnomenclature=E2=80=9D and add on Ma= rk=E2=80=99s=C2= =A0=E2=80=9CThis explicitly excludes schema languages and similar formalism= s.=E2=80=9D


On Sat, F= eb 8, 2014 at 7:13 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Feb 8, 2014, at 6:37 PM= , Mark Nottingham <mnot@mnot.net>= ; wrote:

> I=E2=80=99d be more comfortable if the charter were more explicit abou= t this; e.g., =E2=80=9CA set of natural-language terms and/or phrases for u= se in future specifications that use JSON. This explicitly excludes schema = languages and similar formalisms.=E2=80=9D

Do the folks who earlier +1'd the proposed text like Mark's r= eformulation?

--Paul Hoffman
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7bd6bd7617a29304f1f0fbdb-- From cyrus@daboo.name Sun Feb 9 08:09:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E7D1A03B3 for ; Sun, 9 Feb 2014 08:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 4joc9kme8OgW for ; Sun, 9 Feb 2014 08:09:52 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 258341A017E for ; Sun, 9 Feb 2014 08:09:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7F3A75C16240; Sun, 9 Feb 2014 11:09:50 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzM7XKzoN9Re; Sun, 9 Feb 2014 11:09:49 -0500 (EST) Received: from [10.251.51.14] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 5DC295C16236; Sun, 9 Feb 2014 11:09:49 -0500 (EST) Date: Sun, 09 Feb 2014 11:09:47 -0800 From: Cyrus Daboo To: Paul Hoffman , JSON WG Message-ID: <8AA70C014EEED3158A177F1C@cyrus.local> In-Reply-To: <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1175 Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 16:09:54 -0000 Hi Paul, --On February 8, 2014 at 7:13:16 PM -0800 Paul Hoffman=20 wrote: >> I=E2=80=99d be more comfortable if the charter were more explicit about = this; >> e.g., =E2=80=9CA set of natural-language terms and/or phrases for use in >> future specifications that use JSON. This explicitly excludes schema >> languages and similar formalisms.=E2=80=9D > > Do the folks who earlier +1'd the proposed text like Mark's = reformulation? > Would that rule out something like:=20 ? I have=20 found that extremely useful in a couple of specs I have used. It focusses=20 the spec developer on enumerating the structure and set of members etc in a = JSON document. It helps developers by making clear all the possible options = (something examples are not good at). I am not sure a "natural-language" formalism is sufficient because that is=20 not as expressive as a "structured" formalism for describing things like=20 hierarchy, e.g.: A contains B contains C vs A : { B : { C } } Even with "natural language" I suspect people will introduce lists, indents = etc leading to something more structured. --=20 Cyrus Daboo From cabo@tzi.org Sun Feb 9 08:32:36 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8871A03BF for ; Sun, 9 Feb 2014 08:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 koSN_mrbZFKM for ; Sun, 9 Feb 2014 08:32:35 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 66E601A03BB for ; Sun, 9 Feb 2014 08:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s19GWPx8007942; Sun, 9 Feb 2014 17:32:25 +0100 (CET) Received: from [192.168.217.101] (p548937B5.dip0.t-ipconnect.de [84.137.55.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4D09EFA7; Sun, 9 Feb 2014 17:32:25 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <8AA70C014EEED3158A177F1C@cyrus.local> Date: Sun, 9 Feb 2014 17:32:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85017697-48CF-420F-9935-B78193953493@tzi.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> To: Cyrus Daboo X-Mailer: Apple Mail (2.1827) Cc: JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 16:32:37 -0000 Those schema scars must be deep, because Cyrus of course is right. Having a minimal parseable description technique for JSON-based = protocols would save us from tedium such as in RFC 7071 section 6.2.2. (Not needing something like that ever again*) in the future is my = personal benchmark for what we need to achieve here.) The important thing**) here is the 80-20 rule =97 we don=92t need to = make this thing powerful or perfect, because we can always fall back to = English. But we shouldn=92t always have to, even for the most basic purposes. (draft-newton looks like an 85 % solution to me; maybe this can be even = simpler.) Gr=FC=DFe, Carsten *) Yes, I know why it was done, and I agree that it had to be done at = the time. **) The other important thing is that a JSON description technique = doesn=92t have to be parse as JSON, just as an XML schema does not have = to be parse as XML. Why are people falling into this trap again and again... From stefan@drees.name Sun Feb 9 09:01:20 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8F41A01DE for ; Sun, 9 Feb 2014 09:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 9PtJvF9Wf50i for ; Sun, 9 Feb 2014 09:01:18 -0800 (PST) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 8236B1A03CC for ; Sun, 9 Feb 2014 09:01:18 -0800 (PST) Received: from newyork.local.box ([80.187.101.30]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MQvkQ-1Vmjg3499y-00UGEA for ; Sun, 09 Feb 2014 18:01:18 +0100 Message-ID: <52F7B45C.80401@drees.name> Date: Sun, 09 Feb 2014 18:01:16 +0100 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Hoffman , JSON WG References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> In-Reply-To: <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:kDLnMPSo1zUAQXPLzjOgwRQxMHiX0boV76ioEJQ3+Za49dVOpbq 4NmWnKh8esMFVY3boZDJE2Q2U7k3lBOZlbV/0tY5xUDtyGLt5QnW3c65jy42V8Q5nSozXsY KUORWFHxdut2MXpazD9n3/wEbVKnMk1MO1OmR+kxi4jVEkRbfm6Lrlvy6mhYhE8h0ethvzG WgRbBXt68v0l6dV/hj5BA== Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 17:01:20 -0000 Am 09.02.14 04:13, schrieb Paul Hoffman: > On Feb 8, 2014, at 6:37 PM, Mark Nottingham wrote: > >> I’d be more comfortable if the charter were more explicit about >> this; >> e.g., “A set of natural-language terms and/or phrases for use in future >> specifications that use JSON. This explicitly excludes schema languages >> and similar formalisms.” > > Do the folks who earlier +1'd the proposed text like Mark's reformulation? ... +1 and yes, absolutely - from my side! {"Stefan": true} From hallam@gmail.com Sun Feb 9 10:15:42 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C942A1A0412 for ; Sun, 9 Feb 2014 10:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 4TiiY3roI8Yf for ; Sun, 9 Feb 2014 10:15:39 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5771A040F for ; Sun, 9 Feb 2014 10:15:39 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id c11so4222870lbj.30 for ; Sun, 09 Feb 2014 10:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OPQkPdYue9dH/hgBGONRY2VP923BG7zVax0Of9vnncU=; b=jv1VXrIMqssYehZZrfmoVLJwDnpeSqFX/zRm0AMr+PRehiVeEXOMLRbQstYJys87LG c+zGMZ3kIMnKUlD2wOJmcJajx7j3X7Xcan9EOBAaoZX6oqDdvq/uQ8koV/goVLmb2xCp 70wGodrmenBUXlmLiSP8vpygV8xrwndGU4UGNuxgWoO/DF2j0M0LpuAkv3un3mlnPpQ+ qcfQdgaQNJ/Pbodv+c9vVlHkSalpil5C0CgY3FaG6nW0bsCBeuqt77XPgUXYYA3y1HEL XQy81vc9Mv7z86DqOmF2bVcqS4vYenu3OfNMuH5CBHKU9R4TnKK+pY5+hm0jFvMVbnEp VSfg== MIME-Version: 1.0 X-Received: by 10.112.204.104 with SMTP id kx8mr17800203lbc.12.1391969738827; Sun, 09 Feb 2014 10:15:38 -0800 (PST) Received: by 10.112.37.168 with HTTP; Sun, 9 Feb 2014 10:15:38 -0800 (PST) In-Reply-To: <85017697-48CF-420F-9935-B78193953493@tzi.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org> Date: Sun, 9 Feb 2014 13:15:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c3c7f0d22de204f1fd356c Cc: Cyrus Daboo , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 18:15:43 -0000 --001a11c3c7f0d22de204f1fd356c Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 9, 2014 at 11:32 AM, Carsten Bormann wrote: > Those schema scars must be deep, because Cyrus of course is right. > > Having a minimal parseable description technique for JSON-based protocols > would save us from tedium such as in RFC 7071 section 6.2.2. > (Not needing something like that ever again*) in the future is my personal > benchmark for what we need to achieve here.) > A machine readable specification supported by tools is very useful. But how many people are writing tools? Are we at a stage where it is helpful to converge on one tool? https://sourceforge.net/projects/jsonschema/ My view is that it would be a very bad idea to design such a tool in committee and that there would be negligible value from having the format be declared a standard prematurely. A better way forward would be to publish proposals for schema formats as INFORMATIONAL RFCs and see which get used. **) The other important thing is that a JSON description technique doesn't > have to be parse as JSON, just as an XML schema does not have to be parse > as XML. > Why are people falling into this trap again and again... For SAML I generated all my XML schemas using another tool written using Goedel. If I was going to write another XML spec I would extend the generator to dump XML schema. I have an ASN.1 parser as well so I could provide a tool that generated code for ASN.1, XML and JSON. -- Website: http://hallambaker.com/ --001a11c3c7f0d22de204f1fd356c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Feb 9, 2014 at 11:32 AM, Carsten Bormann <cabo@tzi.org> wrot= e:
Those schema scars must be deep, because Cyrus of course is right.

Having a minimal parseable description technique for JSON-based protocols w= ould save us from tedium such as in RFC 7071 section 6.2.2.
(Not needing something like that ever again*) in the future is my personal = benchmark for what we need to achieve here.)

A machine readable specification supported by tools is very useful. B= ut how many people are writing tools? Are we at a stage where it is helpful= to converge on one tool?

https://sourceforge.net/projects/jsonschema/

My view is that it would be a very bad idea to desig= n such a tool in committee and that there would be negligible value from ha= ving the format be declared a standard prematurely. 

A better way forward would be to publish proposals for = schema formats as INFORMATIONAL RFCs and see which get used.

=

**) The other important thing is that a JSON description technique doesn&rs= quo;t have to be parse as JSON, just as an XML schema does not have to be p= arse as XML.
Why are people falling into this trap again and again...
<= br>
For SAML I generated all my XML schemas using another tool wr= itten using Goedel. If I was going to write another XML spec I would extend= the generator to dump XML schema.

I have an ASN.1 parser as well so I could provide a too= l that generated code for ASN.1, XML and JSON. 



--
Website: http://hallambaker.com/
--001a11c3c7f0d22de204f1fd356c-- From tbray@textuality.com Sun Feb 9 11:10:27 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8091A1A050F for ; Sun, 9 Feb 2014 11:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 tVfFHYEwVmEA for ; Sun, 9 Feb 2014 11:10:25 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 15C491A03E6 for ; Sun, 9 Feb 2014 11:10:25 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so4200001vcb.13 for ; Sun, 09 Feb 2014 11:10:25 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=UfIeZ5XMnq860khCoxcq0WIL1TdzjxNJIwIIaqL+Gjg=; b=PyYa5gpU/ZtrX4OH1Pls1nPz6Ea5hGGhGB+bcG02/sUMrSbDzGZBf63G56o3O1IksG FP1GHzHqncZW9U6oOkPDOd5lx5kKF2AmFB3KOodlovzvDxFXKl0EdBX8bJ2SYiSFNxK0 iXsST66B6EyzRZAwLzzx7PcAVhoR1W8sMkt769Rweltj7FRleufOzGzZv2W9owv6vKcs B6m5SKUOqigJXiYdT1o7roLsQmg4FVKUOGlUn/Rl6qI0mJs9Var/Ylsw7VKcfNSGgmHq 9HxRjJsSZQR6v8xy1M9nn/0/2I1YQPoX4VVPxFulssJayqZKWqSl2id4jISsOZqLb66o BvoA== X-Gm-Message-State: ALoCoQncODSjTqf6OD8RGft1E9Qf70j4Hc9RBK23lajaPWGSWEGF/PjsXIfOFEfV9aW5GBE8P5fM MIME-Version: 1.0 X-Received: by 10.58.49.129 with SMTP id u1mr20897906ven.0.1391973024960; Sun, 09 Feb 2014 11:10:24 -0800 (PST) Received: by 10.220.98.73 with HTTP; Sun, 9 Feb 2014 11:10:24 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <85017697-48CF-420F-9935-B78193953493@tzi.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org> Date: Sun, 9 Feb 2014 11:10:24 -0800 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e013c7136b0adc304f1fdf933 Cc: Cyrus Daboo , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 19:10:27 -0000 --089e013c7136b0adc304f1fdf933 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Feb 9, 2014 at 8:32 AM, Carsten Bormann wrote: > Having a minimal parseable description technique for JSON-based protocols > would save us from tedium such as in RFC 7071 section 6.2.2. > (Not needing something like that ever again*) in the future is my persona= l > benchmark for what we need to achieve here.) > Hm, I just went and looked at http://tools.ietf.org/html/rfc7071#section-6.2.2 - it reads like a perfectly sensible piece of specification-ware to me. Looks to me like it leaves implementors very little uncertainty, and it=E2=80=99s easy to under= stand. It all fits on a couple of screens on my laptop. The dorky ALL_CAPS makes it typographically ugly, but it=E2=80=99s hard to imagine a formalism that = would make it dramatically shorter, or more useful. I actually thought what we were talking about was something to replace 6.2.1 in that spec, so people don=E2=80=99t ever need to write an =E2=80=9C= Imported JSON terms=E2=80=9D section again. > > The important thing**) here is the 80-20 rule =E2=80=94 we don=E2=80=99t = need to make this > thing powerful or perfect, because we can always fall back to English. > But we shouldn=E2=80=99t always have to, even for the most basic purposes= . > > (draft-newton looks like an 85 % solution to me; maybe this can be even > simpler.) > > Gr=C3=BC=C3=9Fe, Carsten > > *) Yes, I know why it was done, and I agree that it had to be done at the > time. > > **) The other important thing is that a JSON description technique doesn= =E2=80=99t > have to be parse as JSON, just as an XML schema does not have to be parse > as XML. > Why are people falling into this trap again and again... > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e013c7136b0adc304f1fdf933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Feb 9, 2014 at 8:32 AM, Carsten Bormann <cabo@tzi.org> wrot= e:
=C2=A0
Having a minimal parseable description technique for JSON-based protocols w= ould save us from tedium such as in RFC 7071 section 6.2.2.
(Not needing something like that ever again*) in the future is my personal = benchmark for what we need to achieve here.)

Hm, I just went and looked at http://tools.ietf.org/html/rfc7071#section-6.2.2 = - it reads like a perfectly sensible piece of specification-ware to me. Loo= ks to me like it leaves implementors very little uncertainty, and it=E2=80= =99s easy to understand. =C2=A0It all fits on a couple of screens on my lap= top. The dorky ALL_CAPS makes it typographically ugly, but it=E2=80=99s har= d to imagine a formalism that would make it dramatically shorter, or more u= seful.=C2=A0

I actually thought what we were talking about was somet= hing to replace 6.2.1 in that spec, so people don=E2=80=99t ever need to wr= ite an =E2=80=9CImported JSON terms=E2=80=9D section again.

<= /div>
=C2=A0

The important thing**) here is the 80-20 rule =E2=80=94 we don=E2=80=99t ne= ed to make this thing powerful or perfect, because we can always fall back = to English.
But we shouldn=E2=80=99t always have to, even for the most basic purposes.<= br>
(draft-newton looks like an 85 % solution to me; maybe this can be even sim= pler.)

Gr=C3=BC=C3=9Fe, Carsten

*) Yes, I know why it was done, and I agree that it had to be done at the t= ime.

**) The other important thing is that a JSON description technique doesn=E2= =80=99t have to be parse as JSON, just as an XML schema does not have to be= parse as XML.
Why are people falling into this trap again and again...

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e013c7136b0adc304f1fdf933-- From andy@hxr.us Sun Feb 9 11:11:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB44D1A03E6 for ; Sun, 9 Feb 2014 11:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 qtCjbd7cJp3L for ; Sun, 9 Feb 2014 11:11:10 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 25FF81A050F for ; Sun, 9 Feb 2014 11:11:09 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id kl14so5278845pab.29 for ; Sun, 09 Feb 2014 11:11:09 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=I3NXPnrfY2SQnscwPRzyJ8/U/WtZNhKlC6Yjvdh168U=; b=aDWBwaUa4i4sMXmnNSdNEFhHudOqDqdd/Btx/4YgAXCMHb+KJnPLKg2X+FceKEjG4g WNjYSfeBA4GXzEd+/Lz+JUwQzO56fV9DddyuvryWf6AeBJgwWiljpe61hdAu0iX4klWd GO22AgWk0kLsCUj6t4h1BWMPtLWYwikU4qkmMiEF8vV10+A8XYBAwtqHeS/uw36jQnSI FY8UC2SYrhZunYaoRF1Mz0tPtFq2hWJzZoRngn5zSKWSv8l9iWYkjChLOOXyu8pQImHs uSERNc/5aTMc0nXX/lnFuXhiQ8Quv/xtK6ohFQF8y0Nq7MWwILuRdrqVSNXy1R5XV7I1 TLNA== X-Gm-Message-State: ALoCoQn6sFM9G4QkOLqaaCI3wn/8+Bc9RTOKkbCHza0MBq4HLcz3DLTazVfOlNezzr5XUEaMwC21 MIME-Version: 1.0 X-Received: by 10.68.98.3 with SMTP id ee3mr33313811pbb.31.1391973069425; Sun, 09 Feb 2014 11:11:09 -0800 (PST) Received: by 10.68.143.4 with HTTP; Sun, 9 Feb 2014 11:11:09 -0800 (PST) X-Originating-IP: [108.45.162.177] In-Reply-To: <85017697-48CF-420F-9935-B78193953493@tzi.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org> Date: Sun, 9 Feb 2014 14:11:09 -0500 Message-ID: From: Andrew Newton To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: Cyrus Daboo , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 19:11:12 -0000 On Sun, Feb 9, 2014 at 11:32 AM, Carsten Bormann wrote: > The important thing**) here is the 80-20 rule -- we don't need to make this thing powerful or perfect, because we can always fall back to English. > But we shouldn't always have to, even for the most basic purposes. > > (draft-newton looks like an 85 % solution to me; maybe this can be even simpler.) The intent of the draft was to find a way to document JSON. It probably got too formal and could use some thoughtful reduction plus use of english words instead of symbols to ease readability. As for the backlash against schema languages, there are some lessons to be learned. After all, DTDs and XSDs do not a standard make. The sweet spot is probably not just a common notation or language to describe the use of JSON in a standard but also some guidelines regarding the other information necessary for a good specification. -andy From mnot@mnot.net Sun Feb 9 14:29:08 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269271A0614 for ; Sun, 9 Feb 2014 14:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aM0S7EEiS0Ns for ; Sun, 9 Feb 2014 14:29:05 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 64D761A04CA for ; Sun, 9 Feb 2014 14:29:05 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.16.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EB3C2509B5; Sun, 9 Feb 2014 17:28:59 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: Date: Mon, 10 Feb 2014 09:28:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1827) Cc: Cyrus Daboo , Carsten Bormann , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 22:29:08 -0000 On 10 Feb 2014, at 5:15 am, Phillip Hallam-Baker = wrote: > A machine readable specification supported by tools is very useful. = But how many people are writing tools? Are we at a stage where it is = helpful to converge on one tool? >=20 > https://sourceforge.net/projects/jsonschema/ >=20 > My view is that it would be a very bad idea to design such a tool in = committee and that there would be negligible value from having the = format be declared a standard prematurely.=20 >=20 > A better way forward would be to publish proposals for schema formats = as INFORMATIONAL RFCs and see which get used. What Phillip said. -- Mark Nottingham http://www.mnot.net/ From nico@cryptonector.com Sun Feb 9 14:57:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9B1A061B for ; Sun, 9 Feb 2014 14:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 aR_ckMuG9nzR for ; Sun, 9 Feb 2014 14:57:50 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id DDCE21A0561 for ; Sun, 9 Feb 2014 14:57:50 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id E574A2005D106 for ; Sun, 9 Feb 2014 14:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Dy5dTOm41ZQFaxWB1k3R +u485Pw=; b=y+zK1kfLPmXkMMHDNkbyk+Y19TUGM10Eu/lXFQVdU4p14eRGJS2m XSY1rPKB3PwarX4+aUlkIK6djLzoRF4cX4CMurjsCDUY+4NzAlzMkVYxNSjuyiUz shgOoPTPEoLXlJp1UcMsZ4hTKY61KLrTjfJQJZ1mhlg1eg9HCE8QrsM= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 8CECF2005D105 for ; Sun, 9 Feb 2014 14:57:50 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id t61so3615103wes.8 for ; Sun, 09 Feb 2014 14:57:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oQPKyl08c07O/nO9UOdlgshYhM3Gz1RC+MAa/cGerUw=; b=Q3mXjQuufI43nvON5VQ/OTli0xhJ7KVq8b6W0bNXdw2qV8jxatwM0tcxBbHRyoifUC slORyCcCqY7QktmWSQhHvTLHC3pVz99UweP5QdTA/KMX/riHGOeZ+EeY5aiZLBYGzqE+ +bkmcxTJNYbEc+FnSz9USAt02OklyKSbSct+ePuXvMUAQeweb4rDjoxWGPIRCSI21El7 jAs4YuGCl8FSmOKfPToGwIf+zicdl3irydaaF6wb4hZSLmRv75mrvdUTep5QjMyO9s+u 3y5Vy/2hsv00Uis9H0YYjq6lnXb4IF0oXhGPuXzswz5BbHHDdd3bUmytCH2Tm8KZVlc0 S3PA== MIME-Version: 1.0 X-Received: by 10.180.160.206 with SMTP id xm14mr7995107wib.25.1391986669027; Sun, 09 Feb 2014 14:57:49 -0800 (PST) Received: by 10.227.198.69 with HTTP; Sun, 9 Feb 2014 14:57:48 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org> Date: Sun, 9 Feb 2014 16:57:48 -0600 Message-ID: From: Nico Williams To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: Cyrus Daboo , Carsten Bormann , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Feb 2014 22:57:52 -0000 There's no reason that we should have a single schema language, and for any document it should suffice to use whichever schema language (if any), is most appropriate. Therefore I wouldn't suggest that the WG have a [single] standard schema as a work item, but I'm not sure what we stand to gain from having only Informational schema languages -- they can't be used to specify Standards-Track protocols. If there's no appetite for working on one or more schema languages, so be it. Nico -- From hallam@gmail.com Sun Feb 9 16:06:39 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CEC1A062A for ; Sun, 9 Feb 2014 16:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7aE3paFLzOVT for ; Sun, 9 Feb 2014 16:06:37 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 84C481A0628 for ; Sun, 9 Feb 2014 16:06:37 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so4334445lab.9 for ; Sun, 09 Feb 2014 16:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Uqh1nQyqEP10GCpCAWxguQuqBKmY5luBXE48kwJFoeQ=; b=iQBBCtFD8mFqjmfDnHtbmg31FVCG09zs5tEtIf7FfEHaTlpYTltvypy9Ba0BbI1SAc RS5FDvmNG7YMCiwgQtVniOdTKHFqzTgJuRVY/3kegJu+Mcs610beIxMoVqYNrvqo4CIH iRq7Yx7DPbyyR2HSmtE3mtzo9yUprTG6NvHWiLcHFbVkZOc0HC1ZpCR4YV8hJhRY/knK DVuFl1smPSr1RCJACYUiCNNF2/aUOrRe9JjdWWYClIKsWPBWhRPcLJF3bkdbDXQvV3Ry r1eaU0ok48jMmnvlKmOR782L1WrP56aFDxEJ5YViRXkrR5o+obfQfjVRXFrjQb2NPLqD 8V0A== MIME-Version: 1.0 X-Received: by 10.112.138.233 with SMTP id qt9mr3345221lbb.34.1391990796761; Sun, 09 Feb 2014 16:06:36 -0800 (PST) Received: by 10.112.37.168 with HTTP; Sun, 9 Feb 2014 16:06:36 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org> Date: Sun, 9 Feb 2014 19:06:36 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=089e01229710f8c0c504f2021cd1 Cc: Cyrus Daboo , Mark Nottingham , Carsten Bormann , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 00:06:39 -0000 --089e01229710f8c0c504f2021cd1 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 9, 2014 at 5:57 PM, Nico Williams wrote: > There's no reason that we should have a single schema language, and > for any document it should suffice to use whichever schema language > (if any), is most appropriate. Therefore I wouldn't suggest that the > WG have a [single] standard schema as a work item, but I'm not sure > what we stand to gain from having only Informational schema languages > -- they can't be used to specify Standards-Track protocols. If > there's no appetite for working on one or more schema languages, so be > it. > This is no longer the case. Internet Standards have been allowed to down-reference Informational for a long time now. There are some additional steps but they are minor. Since the schema itself only describes the data format, it does not even need compliance language. -- Website: http://hallambaker.com/ --089e01229710f8c0c504f2021cd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Feb 9, 2014 at 5:57 PM, Nico Williams <nico@cryptonector.com&g= t; wrote:
There's no reason that we should have a = single schema language, and
for any document it should suffice to use whichever schema language
(if any), is most appropriate. =A0Therefore I wouldn't suggest that the=
WG have a [single] standard schema as a work item, but I'm not sure
what we stand to gain from having only Informational schema languages
-- they can't be used to specify Standards-Track protocols. =A0If
there's no appetite for working on one or more schema languages, so be<= br> it.


This is no longer th= e case.

Internet Standards have been allowed to do= wn-reference Informational for a long time now. There are some additional s= teps but they are minor.
=A0

Since the schema itself only descri= bes the data format, it does not even need compliance language.=A0

--
Website: http://hall= ambaker.com/
--089e01229710f8c0c504f2021cd1-- From paul.hoffman@vpnc.org Mon Feb 10 08:36:48 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7233E1A06DC for ; Mon, 10 Feb 2014 08:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=no 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 0I5wNh2Hp5fr for ; Mon, 10 Feb 2014 08:36:47 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6AA1A07EE for ; Mon, 10 Feb 2014 08:36:47 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1AGaj3O071003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Feb 2014 09:36:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8E389E26-99CC-4B3D-AC7B-3FBB9DD459C6@vpnc.org> Date: Mon, 10 Feb 2014 08:36:45 -0800 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [Json] Proposed agenda for London meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 16:36:48 -0000 http://www.ietf.org/proceedings/89/agenda/agenda-89-json Matt and I would love to see the nomenclature/not-really-schema = discussion continue to happen in the coming weeks, but it feels like a = face-to-face meeting might be valuable for it as well. --Paul Hoffman= From nico@cryptonector.com Mon Feb 10 08:41:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB61A06F2 for ; Mon, 10 Feb 2014 08:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 MF9qL2Y0frZT for ; Mon, 10 Feb 2014 08:41:06 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFD31A06E5 for ; Mon, 10 Feb 2014 08:41:06 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 12B742C806C for ; Mon, 10 Feb 2014 08:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UyM6uRzg/5dxqa9h4EHK YoLrEvg=; b=BfSe9H01Z2W+rID6EKht9OIn8VqXJrHTXpdIwc35plnTiDqg+DTY K3I/K0PctrNNkd82efFJvh11aSdntfzmvo0YdxLYtT39QNH4VDW7BBUpc3G/M7Wl P0P6tpmFYBhKcMobEr7Xb/Qv9llENKJolU0W6fpn7ACcUUF/Jxr2J3k= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id B8E202C806B for ; Mon, 10 Feb 2014 08:41:05 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so3008291wib.12 for ; Mon, 10 Feb 2014 08:41:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CwJsd4iaMTdhjW6Nin0nB4wzo+LT9GiO7vtxIn1jP4U=; b=Xc3ujk1vExBCB0nMpJhrB+djrh82XQlEh2oCy/qR+FcxWDbFInD9MYU8mdhGKWky9d PjemdIyjbpP2xR4/kMs9DKbFdKve+B1fOHgXXT3zgCgS6Z+rYriBTm5Usq1Ku0pP47VC 4a96Doqor/a6JHPQWp3ad5zWbUnQO2zhie60FQ9leeRGDbQPJ1eBZ70zWDGuF8JnoRaa NKi99cj2mF4xk2gmymoy5ZMByXqaoNJb731fZHLZ3WVRR4YqkXZ+dfjE4DorM87p52Ig 8l8b4WUTFFySCPBUCzXNMtYxn35G3UBxabGotV8S32mqORIYRInCEyl8BYHlcG9+lhXW XXtw== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr22515071wjc.31.1392050464366; Mon, 10 Feb 2014 08:41:04 -0800 (PST) Received: by 10.217.108.132 with HTTP; Mon, 10 Feb 2014 08:41:04 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org> Date: Mon, 10 Feb 2014 10:41:04 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: Cyrus Daboo , Mark Nottingham , Carsten Bormann , JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 16:41:07 -0000 On Sun, Feb 9, 2014 at 6:06 PM, Phillip Hallam-Baker wrote: > On Sun, Feb 9, 2014 at 5:57 PM, Nico Williams wrote: >> >> There's no reason that we should have a single schema language, and >> for any document it should suffice to use whichever schema language >> (if any), is most appropriate. Therefore I wouldn't suggest that the >> WG have a [single] standard schema as a work item, but I'm not sure >> what we stand to gain from having only Informational schema languages >> -- they can't be used to specify Standards-Track protocols. If >> there's no appetite for working on one or more schema languages, so be >> it. > > This is no longer the case. > > Internet Standards have been allowed to down-reference Informational for a > long time now. There are some additional steps but they are minor. > > Since the schema itself only describes the data format, it does not even > need compliance language. Then I'm happy with all JSON schema docs being Informational (and not even WG work items). Nico -- From hallam@gmail.com Mon Feb 10 09:12:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9831A03A5 for ; Mon, 10 Feb 2014 09:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1bi2B7hDpGvm for ; Mon, 10 Feb 2014 09:12:02 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B07901A01DA for ; Mon, 10 Feb 2014 09:12:01 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id hr13so5073047lab.1 for ; Mon, 10 Feb 2014 09:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PMDC4E+WOIAtaIy/tGhAtcUmLu3gjQCVJoNPHTAuTuM=; b=YRR/BBoV6z7s1UKwjrKpO88AlFDZhTDMrAZHGiMFgzBjpRUpAC3HsLrO2rIw/lM+Nh jz7bsmbx+L2GIlTbLwxQxtfaW7IfzTLup93Ss+E3ii2iT0O2K2xi2QCCr1U/JOfsVIPF ZWHMwvORI3fk8Z/8m0IeVSELQr/MY4UEnBEQ10xUI7HrpSGP54VZgzDW+mFa2cG5Y7O1 HAc/wQp2Hn6QEiSpRSJlOPff+vUgNfb7QvrOhW8WuWSuXIznw63Rnj4Bpwejb55E/UR9 75NovdAq4M47DGYdzMLyLS3HDW/8MqGN+ONs6tkJW1hLbnRgw65EhglLLRe12CbdUKu7 e2ow== MIME-Version: 1.0 X-Received: by 10.153.3.2 with SMTP id bs2mr22630948lad.5.1392052320796; Mon, 10 Feb 2014 09:12:00 -0800 (PST) Received: by 10.112.37.168 with HTTP; Mon, 10 Feb 2014 09:12:00 -0800 (PST) In-Reply-To: <8E389E26-99CC-4B3D-AC7B-3FBB9DD459C6@vpnc.org> References: <8E389E26-99CC-4B3D-AC7B-3FBB9DD459C6@vpnc.org> Date: Mon, 10 Feb 2014 12:12:00 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1136c7421704c704f21070ef Cc: JSON WG Subject: Re: [Json] Proposed agenda for London meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 17:12:04 -0000 --001a1136c7421704c704f21070ef Content-Type: text/plain; charset=ISO-8859-1 I think it will also be an xml2rfc issue or at least the RFC discussions will gate it. The reason for having a better RFC format in my view is so that machine readable parts of specs such as schemas and EBNF can be embedded in a form that allows tools to extract them and use them. So we could have a system where you can take an RFC, press a button and generate an implementation. We are actually very close to that point already. I just do it in the opposite direction, I generate the spec from the schema. But there is no reason that we shouldn't be able to round trip. On Mon, Feb 10, 2014 at 11:36 AM, Paul Hoffman wrote: > http://www.ietf.org/proceedings/89/agenda/agenda-89-json > > Matt and I would love to see the nomenclature/not-really-schema discussion > continue to happen in the coming weeks, but it feels like a face-to-face > meeting might be valuable for it as well. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- Website: http://hallambaker.com/ --001a1136c7421704c704f21070ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think it will also be an xml2rfc issue or at least the R= FC discussions will gate it.

The reason for having a bet= ter RFC format in my view is so that machine readable parts of specs such a= s schemas and EBNF can be embedded in a form that allows tools to extract t= hem and use them.

So we could have a system where you can take an RFC, pr= ess a button and generate an implementation.

We ar= e actually very close to that point already. I just do it in the opposite d= irection, I generate the spec from the schema. But there is no reason that = we shouldn't be able to round trip.



On Mon, Feb 10, 2014 at 11:36 AM, Paul Hoffman &l= t;paul.hoffman@v= pnc.org> wrote:
http://www.ietf.org/proceedings/= 89/agenda/agenda-89-json

Matt and I would love to see the nomenclature/not-really-schema discussion = continue to happen in the coming weeks, but it feels like a face-to-face me= eting might be valuable for it as well.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



-- Website: http://hallambaker.com/<= br>
--001a1136c7421704c704f21070ef-- From tbray@textuality.com Mon Feb 10 09:24:46 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156CE1A0874 for ; Mon, 10 Feb 2014 09:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 6yOwhX8Td6Ov for ; Mon, 10 Feb 2014 09:24:42 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id E22101A0835 for ; Mon, 10 Feb 2014 09:24:40 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id oy12so5125254veb.23 for ; Mon, 10 Feb 2014 09:24:40 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=rgre+N/XapoC3uhpGeG8XcyHAVVr8qcvMhmCgP6RZPg=; b=kk3LzwvGfpsUBvCSzfmZ66D1I+a2y3lHR/ch+qi4Y/U5w5lVP2mUTfPyuGGBAHETKw dxDkwTMOAzc+GywRXDbGhLpWVE3+nxB0e84MZFEP9WYhljmdAc7OqErrLAzV13sIQ6dd 2Twy9ncWsy8ygN+tl0ROSQLGV0IFspCN3ll3+YaM2PIJ8MEC3TcCH3FjLB8i3yUb5EDf Xkq1HrLN202ozc9R71p80NoWxQl90Vk62O63VO+/gAKwpdPWc3TYbyNyQP5YjDfslO9s 2OKt4BlSXN5pp/BDc20rrXu+DKGy3c8zuq84GCNGnrk5vdXtlZrntcW7UoOIL9jACxI8 3HRw== X-Gm-Message-State: ALoCoQlIfJcvRh8JAZreI0J5d9G7DwgtA+VSx7LOpGzNuhY+eww9SARcJ4r2PkdP5pfx0ZU8+0sB MIME-Version: 1.0 X-Received: by 10.220.53.66 with SMTP id l2mr644354vcg.33.1392053080609; Mon, 10 Feb 2014 09:24:40 -0800 (PST) Received: by 10.220.98.73 with HTTP; Mon, 10 Feb 2014 09:24:40 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <8E389E26-99CC-4B3D-AC7B-3FBB9DD459C6@vpnc.org> References: <8E389E26-99CC-4B3D-AC7B-3FBB9DD459C6@vpnc.org> Date: Mon, 10 Feb 2014 09:24:40 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2b8da60e8c804f2109d69 Cc: JSON WG Subject: Re: [Json] Proposed agenda for London meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 17:24:46 -0000 --001a11c2b8da60e8c804f2109d69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I sincerely apologize to the WG, but family commitments have me on a plane out of London as the WG will be meeting. Between now and the meeting I=E2=80=99ll pull together some I-JSON talking = points, and make myself available in London. On Mon, Feb 10, 2014 at 8:36 AM, Paul Hoffman wrote= : > http://www.ietf.org/proceedings/89/agenda/agenda-89-json > > Matt and I would love to see the nomenclature/not-really-schema discussio= n > continue to happen in the coming weeks, but it feels like a face-to-face > meeting might be valuable for it as well. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c2b8da60e8c804f2109d69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I sincerely apologize to the WG, but family commitments ha= ve me on a plane out of London as the WG will be meeting. =C2=A0

Between now and the meeting I=E2=80=99ll pull together some I-JSON= talking points, and make myself available in London.


On Mon,= Feb 10, 2014 at 8:36 AM, Paul Hoffman <paul.hoffman@vpnc.org><= /span> wrote:
http://www.ietf.org/proceedings/= 89/agenda/agenda-89-json

Matt and I would love to see the nomenclature/not-really-schema discussion = continue to happen in the coming weeks, but it feels like a face-to-face me= eting might be valuable for it as well.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c2b8da60e8c804f2109d69-- From nico@cryptonector.com Mon Feb 10 09:43:46 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073871A0386 for ; Mon, 10 Feb 2014 09:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 HxEDI2UZHpjk for ; Mon, 10 Feb 2014 09:43:44 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4D1A0405 for ; Mon, 10 Feb 2014 09:43:44 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 4B036B8079 for ; Mon, 10 Feb 2014 09:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=K2d24X3tB9IbxlXaovPN Th5WvXk=; b=s7Q3ApBFPIcvQYd2qPLdxiB64ORAASFa8Qr4aPTJXpMJSf+Jb5fl ZsxwBOwU3xqUbVjNpQxDnIGlCD9DsXQLYldfXjZq8qHNEOSuyRbTBgSYTqAuENli /MgIA2QkFodtao7hquKRkEoj4azg4zdL61EitVWPpvLKZ4SJ2yB77S8= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id EED12B8057 for ; Mon, 10 Feb 2014 09:43:43 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id cc10so3077710wib.11 for ; Mon, 10 Feb 2014 09:43:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00aDRjXPL9GBciQqSQLZosMGl1VfsmA6BZXze5q9rcs=; b=LVqoaWOPSN1yYYg8l2qOeu0aGUvKafrYjxDTw2zrDvLWUoq09H903o54/veIqdnO8V tAlKtbIvSF5xWF0KzeLx4bl4frNVFPa08NPVKkuaFlQNEsqq1cS32N4Ii1UCgo1CImol 4mZvT4kL9VaxOvlK+wdY3RQQr9u4oTxKC2I1ZINcEYJCHeNISziIxX5Hs0PdYfepA/Qd of+re13G+w7/Y+ld+lgcvcKy934mbulMNdyy1mXW+pRzYdaa5rLgpNUYbuDR22mLVt7m zQq39NgkUMlkbMAv0oB3At08oYEfHqvKpSCMSKvo76olFw/ND2wJ35nr2VNTHrXjZSPT +FNA== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr3890029wib.5.1392054222343; Mon, 10 Feb 2014 09:43:42 -0800 (PST) Received: by 10.217.108.132 with HTTP; Mon, 10 Feb 2014 09:43:42 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Mon, 10 Feb 2014 11:43:42 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 17:43:46 -0000 On Sat, Feb 8, 2014 at 5:52 PM, Tim Bray wrote: > On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams wrote: >> >> >> An XPath/XSLT for JSON would be good. There's a great candidate for >> that: http://stedolan.github.io/jq . > > > jq seems like overkill. Wow, would it ever be easy to do a JSON path > selector. They practically read themselves > > "buffer"/"size" FYI: .buffer.size > //"size" recurse(.[]).size > //"buffers"/./"size" recurse(.[]).buffers[].size > //"buffers"/0/"size" recurse(.[]).buffers[0].size The .name syntax is a bit to type-strong and so you get spurious error messages (safely ignored). I think the right thing to do here is to make .name act like 'empty' when . is not an object, or if name is an integer, when . is not an array (but .[number] needs to continue to produce warnings if . is not an array). That and add ..name syntax, then '..buffers.0.size' should do what you want without spurious error messages. I'll defer to Stephen either way. BTW, I've needed // in XPath very often. But I've never needed it when dealing with JSON data. The JSON data I've dealt with never had more than one layer of structure repetition, while XML data I've dealt with had many. > //"buffers"/-1/. This one's a pain as jq doesn't do negative indices, so you have -1 the length. > "buffer"/./"key" See above. Nico -- From hallam@gmail.com Mon Feb 10 10:10:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220FB1A00EE for ; Mon, 10 Feb 2014 10:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 WNEIqQIs_8gq for ; Mon, 10 Feb 2014 10:10:23 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id A431E1A01E8 for ; Mon, 10 Feb 2014 10:10:21 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so5056219lbi.35 for ; Mon, 10 Feb 2014 10:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IxUWioZxS29ArwWM9iUdBOk25nuJI0BIJORdvoeDG/o=; b=oIfR5BODtS0xT5hm6XCl9SoJwTsNjyM7Xj932a/akzVHbYIQX3BNq2tizpd5yucN69 HLY1fC3m3BRJHsArLS1jCoTjiwVKm6NzafxvPOGLAfO0CVW/qn6/9555VnU4e9zE/zpO l/DaxNswyQIrZxbv0vYyfdexkka+176Fbjpuj0GGohOF+b7c2MV7aCyLJQ7muzWAwLkk HqOa3Fy+2GvR8E6N+iDH4Pi5NT6Ef8xosTHD2MtIyKw82RTKg0ILpApkA17rOyqkRzU4 loc/i6jzeyladsqlbamfDsn5pNi2hKw3AMAMwCStnqqpFhmVRoewgRcJNhq6vhfz8T+X 5ogQ== MIME-Version: 1.0 X-Received: by 10.112.171.194 with SMTP id aw2mr2400264lbc.46.1392055820731; Mon, 10 Feb 2014 10:10:20 -0800 (PST) Received: by 10.112.37.168 with HTTP; Mon, 10 Feb 2014 10:10:20 -0800 (PST) In-Reply-To: References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> Date: Mon, 10 Feb 2014 13:10:20 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c36e84b3cc1704f21140a6 Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 18:10:26 -0000 --001a11c36e84b3cc1704f21140a6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 12:43 PM, Nico Williams wrote: > On Sat, Feb 8, 2014 at 5:52 PM, Tim Bray wrote: > > On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams > wrote: > >> > >> > >> An XPath/XSLT for JSON would be good. There's a great candidate for > >> that: http://stedolan.github.io/jq . > > > > > > jq seems like overkill. Wow, would it ever be easy to do a JSON path > > selector. They practically read themselves > > > > "buffer"/"size" > > FYI: > > .buffer.size > > > //"size" > > recurse(.[]).size > > > //"buffers"/./"size" > > recurse(.[]).buffers[].size > > > //"buffers"/0/"size" > > recurse(.[]).buffers[0].size > > The .name syntax is a bit to type-strong and so you get spurious error > messages (safely ignored). I think the right thing to do here is to > make .name act like 'empty' when . is not an object, or if name is an > integer, when . is not an array (but .[number] needs to continue to > produce warnings if . is not an array). That and add ..name syntax, > then '..buffers.0.size' should do what you want without spurious error > messages. I'll defer to Stephen either way. > > BTW, I've needed // in XPath very often. But I've never needed it > when dealing with JSON data. The JSON data I've dealt with never had > more than one layer of structure repetition, while XML data I've dealt > with had many. > > > //"buffers"/-1/. > > This one's a pain as jq doesn't do negative indices, so you have -1 the > length. > > > "buffer"/./"key" > One area I would very much like to standardize on is limits like the above. I write my code so that the decoder can cope with messages of any size and arbitrary depth, up to the maximum that the machine can take. But that is obviously neither needed nor acceptable for a production machine. Someone writing a JSON spec should specify what their limits are so that a parser implementation can reject DoS attacks early and block future requests from that IP. It is also an efficiency consideration in C. If I know that no request will ever be more than 64KB long or be nested more than 10 deep, I can pre-allocate all the necessary structures along with the socket and they can be cleared and reused or freed as one unit depending on the load of the server at the time. Avoiding multiple malloc calls is a good way to make a server fly. -- Website: http://hallambaker.com/ --001a11c36e84b3cc1704f21140a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 10, 2014 at 12:43 PM, Nico Williams &= lt;nico@cryptone= ctor.com> wrote:
On Sat, Feb 8, 2014 at 5:52 = PM, Tim Bray <tbray@textuality.c= om> wrote:
> On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams <nico@cryptonector.com> wrote:
>>
>>
>> An XPath/XSLT for JSON would be good. =A0There's a great candi= date for
>> that: h= ttp://stedolan.github.io/jq .
>
>
> jq seems like overkill. Wow, would it ever be easy to do a JSON path > selector. =A0 They practically read themselves
>
> "buffer"/"size"

FYI:

.buffer.size

> //"size"

recurse(.[]).size

> //"buffers"/./"size"

recurse(.[]).buffers[].size

> //"buffers"/0/"size"

recurse(.[]).buffers[0].size

The .name syntax is a bit to type-strong and so you get spurious error
messages (safely ignored). =A0I think the right thing to do here is to
make .name act like 'empty' when . is not an object, or if name is = an
integer, when . is not an array (but .[number] needs to continue to
produce warnings if . is not an array). =A0That and add ..name syntax,
then '..buffers.0.size' should do what you want without spurious er= ror
messages. =A0I'll defer to Stephen either way.

BTW, I've needed // in XPath very often. =A0But I've never needed i= t
when dealing with JSON data. =A0The JSON data I've dealt with never had=
more than one layer of structure repetition, while XML data I've dealt<= br> with had many.

> //"buffers"/-1/.

This one's a pain as jq doesn't do negative indices, so you have -1= the length.

> "buffer"/./"key"


One area I would very much like to standardize on is limi= ts like the above. I write my code so that the decoder can cope with messag= es of any size and arbitrary depth, up to the maximum that the machine can = take. But that is obviously neither needed nor acceptable for a production = machine.

Someone writing a JSON spec should specify what their l= imits are so that a parser implementation can reject DoS attacks early and = block future requests from that IP.

It is also an = efficiency consideration in C. If I know that no request will ever be more = than 64KB long or be nested more than 10 deep, I can pre-allocate all the n= ecessary structures along with the socket and they can be cleared and reuse= d or freed as one unit depending on the load of the server at the time. Avo= iding multiple malloc calls is a good way to make a server fly.


--
Website: http://hallambaker.com/
--001a11c36e84b3cc1704f21140a6-- From cowan@ccil.org Mon Feb 10 10:13:30 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056251A01E8 for ; Mon, 10 Feb 2014 10:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 KDk7sdjwVjHw for ; Mon, 10 Feb 2014 10:13:28 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5F81A00EE for ; Mon, 10 Feb 2014 10:13:28 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WCvMA-0005xD-FU; Mon, 10 Feb 2014 13:13:22 -0500 Date: Mon, 10 Feb 2014 13:13:22 -0500 From: John Cowan To: Nico Williams Message-ID: <20140210181322.GA21888@mercury.ccil.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Phillip Hallam-Baker , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 18:13:30 -0000 Nico Williams scripsit: > > "buffer"/"size" > > .buffer.size Not very general. What happens when the key is ".foo"? -- Normally I can handle panic attacks on my own; John Cowan but panic is, at the moment, a way of life. http://www.ccil.org/~cowan --Joseph Zitt From nico@cryptonector.com Mon Feb 10 10:29:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB641A01F1 for ; Mon, 10 Feb 2014 10:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 H_a0zqs_XSOg for ; Mon, 10 Feb 2014 10:29:04 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 852141A00EE for ; Mon, 10 Feb 2014 10:29:04 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 7C9CF674058 for ; Mon, 10 Feb 2014 10:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UFJAg5aJGbabSxNwuG0q AVzNUNQ=; b=OYi0fmJR1a1/3DKo5Bk8u6uUqGPEqBW0bZgkZiRLSLpHwy7/vtoe Nz1qn4SsIUgEntPnNUma8oZwDSriyqG3+qVO6UH+k+TiaaBfeh/OFUAKRlmjgIHu n3v3qQzo0qWhfc+JBLDgRRyCicqPDuP1UjGFZuL0OIKJ5fIvWZCKTjg= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 14DC9674057 for ; Mon, 10 Feb 2014 10:29:03 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id n12so4407286wgh.0 for ; Mon, 10 Feb 2014 10:29:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MoXkkOO40UgNq3rJxvgy8+GKjjnlwXHva3TDH7AxXn8=; b=LO4OI1A4GWcNHoeolKulf+FE18TcF/kDd7A+dI3aEGK1ukaNfOdcIbdu7JJX2rUhX0 Au9INmpWaQg1Fs/2C6ZRnCW5uckeySrOTvhb8N/wDhyF6rLd8aAlfs8C2Aj89ZRsVOl1 cL1GvtMQqJb0F66ijgl5Cie+3XepXZmSez6mSZhm2WCBhA7V1CtePw1b9FRyPWrcPUAj de1L3EBCKqbLrAsyonRzKqMUCSwVZfaPZ3MY3w0ac/D8qEpPrsDYFxJp3chQvF9ZKUYW /Up574JkIGF/QmSQIAcLbckJXj67DLM3zf+MgUPtHN6HHVACh2AH4uYflEIpZ1K+xhEM F7gg== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr6893040wjq.40.1392056942079; Mon, 10 Feb 2014 10:29:02 -0800 (PST) Received: by 10.217.108.132 with HTTP; Mon, 10 Feb 2014 10:29:01 -0800 (PST) In-Reply-To: <20140210181322.GA21888@mercury.ccil.org> References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <20140210181322.GA21888@mercury.ccil.org> Date: Mon, 10 Feb 2014 12:29:01 -0600 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Phillip Hallam-Baker , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed rechartering for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 18:29:06 -0000 On Mon, Feb 10, 2014 at 12:13 PM, John Cowan wrote: > Nico Williams scripsit: > >> > "buffer"/"size" >> >> .buffer.size > > Not very general. What happens when the key is ".foo"? [This is an FAQ for jq.] Then you use .[".foo"]. .name is convenient when name is identifier-like, else you must use .[value], where value would be a string. Nico -- From nobody Mon Feb 17 16:23:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4E71A0422 for ; Mon, 17 Feb 2014 16:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no 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 kR3NuxXR2aeo for ; Mon, 17 Feb 2014 16:23:49 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2E91A0291 for ; Mon, 17 Feb 2014 16:23:49 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1I0NixQ021635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Feb 2014 17:23:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> Date: Mon, 17 Feb 2014 16:23:43 -0800 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/json/88En0ST2V6rNqJ9Nt6qpdRXbq40 Subject: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 18 Feb 2014 00:23:50 -0000 It's been a week, and yet I can't imagine that everything has been said = with respect to our proposed charter item that now stands at: A set of natural-language terms and/or phrases for use in future = specifications that use JSON. This explicitly excludes schema languages and similar = formalisms. After that, a bunch of people started talking about formalisms and = actual schemas again. In order to get this decided, we need more = discussion and then agreement. To that end, and to put our 90 minutes on = Friday afternoon in London to best use, I will ask for at least three = people to present their views in 10-minute presentations at the meeting. = However, in order to cause this to not be the normal IETF "let's wait = for the meeting" game, the presentations need to be done by next Monday, = Feb. 24. That gives people on the list a preview of what will be said, = time to argue about it, and time for the presenters to hone their slides = if they want. Let me know online or offline if you want to do a presentation. If = you're not going to be at the meeting but want to say something, you = need to find some like-minded soul with whom to work on the = presentation. --Paul Hoffman= From nobody Mon Feb 17 16:59:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37441A0422 for ; Mon, 17 Feb 2014 16:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aXQn5vu_Y38F for ; Mon, 17 Feb 2014 16:59:12 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EF1DE1A02BD for ; Mon, 17 Feb 2014 16:59:11 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so11923644lbj.3 for ; Mon, 17 Feb 2014 16:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tJsQqvHQJlHr/cEAaUhuJFawmBEHFDeUrDgmnOzF2Bk=; b=KpIYtvTGURnEMy5H6M3mlNny/rVeRAYm42lvL+uF/LSpJ4+LpTkeOFXc2BJHIXO8Jt AZuFMkhyWr7pRaUeY2wetu8lJb7D0/MkxPmmm4+yUDyd4+teEnIW6I6y7hWnmmvsRmbG WpfjXD3itJq5ckDSDlQy4pqTbqDM+YNKY4kPgksB4mfSkipkFqRFor9JZMCYcoHLvOXt bqestJ/6UJeSUVzAeM/+GpRkL+Ro/Ipg4YAG5r5RVqXB6YUGcvWGqP+G8/DSLjTLhKE0 +YkRsrRFosNWfGoY2W/C6Ojg1Y0zBCYLhsmEo0Jp1lAFw04SK9/NBiyqU2/FnD+LYuUv snzQ== MIME-Version: 1.0 X-Received: by 10.152.5.136 with SMTP id s8mr24379las.55.1392685148382; Mon, 17 Feb 2014 16:59:08 -0800 (PST) Received: by 10.112.37.168 with HTTP; Mon, 17 Feb 2014 16:59:08 -0800 (PST) In-Reply-To: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> References: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> Date: Mon, 17 Feb 2014 19:59:08 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b8743a48dab2304f2a3c74f Archived-At: http://mailarchive.ietf.org/arch/msg/json/61Dqpo50PJQsLQiNJaBOtL2TQI4 Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 18 Feb 2014 00:59:15 -0000 --047d7b8743a48dab2304f2a3c74f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 17, 2014 at 7:23 PM, Paul Hoffman wrote: > It's been a week, and yet I can't imagine that everything has been said > with respect to our proposed charter item that now stands at: > > A set of natural-language terms and/or phrases for use in future > specifications > that use JSON. This explicitly excludes schema languages and similar > formalisms. > > After that, a bunch of people started talking about formalisms and actual > schemas again. In order to get this decided, we need more discussion and > then agreement. To that end, and to put our 90 minutes on Friday afternoon > in London to best use, I will ask for at least three people to present > their views in 10-minute presentations at the meeting. However, in order to > cause this to not be the normal IETF "let's wait for the meeting" game, the > presentations need to be done by next Monday, Feb. 24. That gives people on > the list a preview of what will be said, time to argue about it, and time > for the presenters to hone their slides if they want. > > Let me know online or offline if you want to do a presentation. If you're > not going to be at the meeting but want to say something, you need to find > some like-minded soul with whom to work on the presentation. > I have a tool that I would like to present. The input to the tool is an abstract description of a data structure, the output is code that generates JSON serializer and deserializer code from the description and xml2rfc or html text that describes the interpretation of the data structure. All the code and reference material in the following document were generated with the tool http://tools.ietf.org/search/draft-hallambaker-wsconnect-05 The advantage of working this way is that if a change is made to the specification it will automatically make its way into the examples and the reference material. So if someone decides that the tag should be "DateTime" rather than "Date" you can edit one field in one file and be confident that the changes are reflected through all the examples. No more hunting through the examples to make sure that all the changes were made consistently. The code is on SourceForge and an update I am working on provides code in C as well as C#. The abstract description is not in JSON. This is deliberate, I find JSON to be rather noisy as a text entry format. Plus you might face what we saw in the KEYPROV working group where the core spec was in one format (XML) but another group of people wanted to do ASN.1 because thats what the rest of crypto is done in. It would be very easy to dump out ASN.1 and XML schemas from the same tool. All that is required is a new output script to generate the other schema language. I do however have a flight out of LHR at 16:00 so I have constraints.. -- Website: http://hallambaker.com/ --047d7b8743a48dab2304f2a3c74f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 17, 2014 at 7:23 PM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
It's been a week, and yet I can't imagine that eve= rything has been said with respect to our proposed charter item that now st= ands at:

=A0 =A0A set of natural-language terms and/or phrases for use in future spe= cifications
=A0 =A0that use JSON. This explicitly excludes schema languages and similar= formalisms.

After that, a bunch of people started talking about formalisms and actual s= chemas again. In order to get this decided, we need more discussion and the= n agreement. To that end, and to put our 90 minutes on Friday afternoon in = London to best use, I will ask for at least three people to present their v= iews in 10-minute presentations at the meeting. However, in order to cause = this to not be the normal IETF "let's wait for the meeting" g= ame, the presentations need to be done by next Monday, Feb. 24. That gives = people on the list a preview of what will be said, time to argue about it, = and time for the presenters to hone their slides if they want.

Let me know online or offline if you want to do a presentation. If you'= re not going to be at the meeting but want to say something, you need to fi= nd some like-minded soul with whom to work on the presentation.

I have a tool that I would like to present.
<= br>
The input to the tool is an abstract description of a data st= ructure, the output is code that generates JSON serializer and deserializer= code from the description and xml2rfc or html text that describes the inte= rpretation of the data structure.

All the code and reference material in the following do= cument were generated with the tool


The advantage of working this way is that if a ch= ange is made to the specification it will automatically make its way into t= he examples and the reference material. So if someone decides that the tag = should be "DateTime" rather than "Date" you can edit on= e field in one file and be confident that the changes are reflected through= all the examples. No more hunting through the examples to make sure that a= ll the changes were made consistently.

The code is on SourceForge and an update I am working o= n provides code in C as well as C#.

The abstract d= escription is not in JSON. This is deliberate, I find JSON to be rather noi= sy as a text entry format. Plus you might face what we saw in the KEYPROV w= orking group where the core spec was in one format (XML) but another group = of people wanted to do ASN.1 because thats what the rest of crypto is done = in. It would be very easy to dump out ASN.1 and XML schemas from the same t= ool. All that is required is a new output script to generate the other sche= ma language.

I do however have a flight out of LHR at 16:00 so I hav= e constraints..

--
Website: http://hallambaker.com/
--047d7b8743a48dab2304f2a3c74f-- From nobody Mon Feb 17 17:16:24 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4441A01E7 for ; Mon, 17 Feb 2014 17:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 b2pJ-YZCvq5u for ; Mon, 17 Feb 2014 17:16:21 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC561A00EA for ; Mon, 17 Feb 2014 17:16:21 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 68C51508064 for ; Mon, 17 Feb 2014 17:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=GAqM4t/EcdPSLKE9Cn8A NJnGXlg=; b=oW2n9K+n4F6rtwel+HK1FiJdmUH5uYt1iw0KLSg5UCw4CbxFsEf7 V0ps3Sv8pBXONo9z634KlUR1msMo5oZGAuU/yKlXmbOFJ9qANzQl4q3/VQTI3/e4 0zowIulPpIvhDWIUpiNFi4iBA3SwH6niMsm48Mz6y1+voXLd7GxIzUQ= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id F2AB650805F for ; Mon, 17 Feb 2014 17:16:17 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id a1so2758000wgh.15 for ; Mon, 17 Feb 2014 17:16:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9aWF78QL9FHKy9MYureBT47NqA/NLFTW0/vG+zTXIoE=; b=VZK94feaSsnAuaxGIa1uhqkjm2v3d1CFw8Dfpd/dScE+56UZ7WN3fhidcZz5I3R/69 wLwIDnota68CcU2G6BiMG5NLN6KDzdDO55TS11zN0pZCpabmQCjKTIbqbQg4Ep6SSK0s gdOZaBLRY1PnO7UdGoCCO7wiTgf7Rv4/BgxV1lleS0f1UUzm9ppCjRJZ77oe0D/y0Yor JUe5MmKSeE3jhS0umjxV60dKRSCkpmxCnNLs9GcMdA9OVX3Br4hWI3OBltYbymXDMamN lAUoYsYv+GoJAh1eNZePY/SKKDVrsECEviVQjcL8zL3/uHr/L/YHjbHDNMPVWqNhsKhx p27w== MIME-Version: 1.0 X-Received: by 10.195.13.164 with SMTP id ez4mr20064211wjd.11.1392686176280; Mon, 17 Feb 2014 17:16:16 -0800 (PST) Received: by 10.217.108.132 with HTTP; Mon, 17 Feb 2014 17:16:15 -0800 (PST) In-Reply-To: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> References: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> Date: Mon, 17 Feb 2014 19:16:15 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/TibSi9MyGvmcD0Lds8X6cNmfnv8 Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 18 Feb 2014 01:16:22 -0000 My advice: a) welcome WG work items for specifying one or more Informational JSON schemas, b) recommend (not RFC2119 RECOMMEND) the use of a JSON schema when specifying applications using JSON, if appropriate -- a schema of the application spec authors' choosing. Nico -- From nobody Mon Feb 17 17:36:39 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382731A0280 for ; Mon, 17 Feb 2014 17:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 xFSv4Mos218U for ; Mon, 17 Feb 2014 17:36:37 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EE20B1A01E7 for ; Mon, 17 Feb 2014 17:36:36 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1I1aUiO023417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 18:36:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Mon, 17 Feb 2014 17:36:29 -0800 Content-Transfer-Encoding: 7bit Message-Id: <19DB0F90-A3DC-4458-907C-21F160E30401@vpnc.org> References: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/json/PA6KGGWyFhJZ977cHM8IO_vYq70 Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 18 Feb 2014 01:36:38 -0000 On Feb 17, 2014, at 4:59 PM, Phillip Hallam-Baker wrote: > I have a tool that I would like to present. > . . . > I do however have a flight out of LHR at 16:00 so I have constraints.. Thanks for volunteering, and we'll put you first. --Paul Hoffman From nobody Mon Feb 17 18:10:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345FF1A057F for ; Mon, 17 Feb 2014 18:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 epMnsLQROXl0 for ; Mon, 17 Feb 2014 18:10:21 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 18C831A0567 for ; Mon, 17 Feb 2014 18:10:20 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id y1so11909216lam.13 for ; Mon, 17 Feb 2014 18:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ytWonV2UuWI88A12LD9S7guzOdmx0AhJDcoaEAqvWQ4=; b=n4T5KwTPLsEvpilejUK4q9BWoXWSyT0x0YPEhldIF+aX4ZjSMNNuYZ4Oi9q5oj+ljx ABc6EjxKxEZ2jHZS/OoUQ/jlfpmCf9HxB3w9hAcvDNyE6vbq/6OBn+v17E2UX9YjOjG8 lcJw79CcKzyYBCMpeam5mtsxkfszNP+adhBChsMPQEcNYYhKzl7oaY/4mkxkgn2qg/Fl XGTyaXp4SnbYjOdhxvqUHnA78podfiX5YsUB0oeUawzPzNad/d4zfOPyV+PL1cKPrJ/o D1oqcSD5B9tLJ9hgG2x2MNvaOONMXJLw5k8PR8a3Y5E0LQzqVuQnltl5aI0PHdUnHir7 X3mQ== MIME-Version: 1.0 X-Received: by 10.112.170.234 with SMTP id ap10mr18650596lbc.23.1392689417663; Mon, 17 Feb 2014 18:10:17 -0800 (PST) Received: by 10.112.37.168 with HTTP; Mon, 17 Feb 2014 18:10:17 -0800 (PST) In-Reply-To: References: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> Date: Mon, 17 Feb 2014 21:10:17 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c373ec05b7de04f2a4c6e3 Archived-At: http://mailarchive.ietf.org/arch/msg/json/VneamqBt8voEHIC52EvaB_NH5Dc Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 18 Feb 2014 02:10:26 -0000 --001a11c373ec05b7de04f2a4c6e3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 17, 2014 at 8:16 PM, Nico Williams wrote: > My advice: > > a) welcome WG work items for specifying one or more Informational JSON > schemas, > > b) recommend (not RFC2119 RECOMMEND) the use of a JSON schema when > specifying applications using JSON, if appropriate -- a schema of the > application spec authors' choosing. > +1 I would prefer standards track to be limited to actual protocols and mandatory to implement features of protocols. We don't need to agree on the schema unless it goes over the wire. I really want to avoid getting to the point where we pass JSON schemas or references to schema over the wire like we do with .xsd. That does absolutely no good in any situation I am aware of. One other point, I was needing a quick HTTP client for a part of an app so I just realized I can adjust my JSON schema tool to generate code to parse headers in a HTTP response. It is a little messier than JSON parsing as HTTP headers are not quite as regular as JSON. But it is quite easy to avoid messing with EBNF with a few hints to give the variant of the encoding. [Of course I since my Web Services are JSON data in a HTTP wrapper, having JSON data in a JSON wrapper is quite attractive. More attractive still is JSON-C encoding on the inner and outer wrappers. Thus finessing both HTTP/2.0 and CORE] -- Website: http://hallambaker.com/ --001a11c373ec05b7de04f2a4c6e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 17, 2014 at 8:16 PM, Nico Williams &l= t;nico@cryptonec= tor.com> wrote:
My advice:

a) welcome WG work items for specifying one or more Informational JSON sche= mas,

b) recommend (not RFC2119 RECOMMEND) the use of a JSON schema when
specifying applications using JSON, if appropriate -- a schema of the
application spec authors' choosing.

+1

I would prefer standards track to be limited t= o actual protocols and mandatory to implement features of protocols. We don= 't need to agree on the schema unless it goes over the wire.

I really want to avoid getting to the point where we pa= ss JSON schemas or references to schema over the wire like we do with .xsd.= That does absolutely no good in any situation I am aware of.=A0


One other point, I was needing a quick HTTP c= lient for a part of an app so I just realized I can adjust my JSON schema t= ool to generate code to parse headers in a HTTP response. It is a little me= ssier than JSON parsing as HTTP headers are not quite as regular as JSON. B= ut it is quite easy to avoid messing with EBNF with a few hints to give the= variant of the encoding.

[Of course I since my Web Services are JSON data in a H= TTP wrapper, having JSON data in a JSON wrapper is quite attractive. More a= ttractive still is JSON-C encoding on the inner and outer wrappers. Thus fi= nessing both HTTP/2.0 and CORE]

--
Website: ht= tp://hallambaker.com/
--001a11c373ec05b7de04f2a4c6e3-- From nobody Wed Feb 19 07:31:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920DC1A0206 for ; Wed, 19 Feb 2014 07:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 OyxK1nXjl3qz for ; Wed, 19 Feb 2014 07:31:51 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 268CE1A015B for ; Wed, 19 Feb 2014 07:31:51 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1JFVkLU017234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Feb 2014 08:31:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 19 Feb 2014 07:31:49 -0800 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/json/Flf6J75_vwhxpacdqhyaCN_Pb7c Subject: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 15:31:52 -0000 [[ Phill is the only one who has responded with a proposal to speak. = Hearing whether others want to would be useful. --Paul Hoffman ]] It's been a week, and yet I can't imagine that everything has been said = with respect to our proposed charter item that now stands at: A set of natural-language terms and/or phrases for use in future = specifications that use JSON. This explicitly excludes schema languages and similar = formalisms. After that, a bunch of people started talking about formalisms and = actual schemas again. In order to get this decided, we need more = discussion and then agreement. To that end, and to put our 90 minutes on = Friday afternoon in London to best use, I will ask for at least three = people to present their views in 10-minute presentations at the meeting. = However, in order to cause this to not be the normal IETF "let's wait = for the meeting" game, the presentations need to be done by next Monday, = Feb. 24. That gives people on the list a preview of what will be said, = time to argue about it, and time for the presenters to hone their slides = if they want. Let me know online or offline if you want to do a presentation. If = you're not going to be at the meeting but want to say something, you = need to find some like-minded soul with whom to work on the = presentation. --Paul Hoffman _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json From nobody Wed Feb 19 07:49:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFA51A01D5 for ; Wed, 19 Feb 2014 07:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 OxqinQi9Psnt for ; Wed, 19 Feb 2014 07:49:34 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2850D1A0324 for ; Wed, 19 Feb 2014 07:49:11 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id la4so563430vcb.21 for ; Wed, 19 Feb 2014 07:49:07 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=bokxqedkMGSccuXB+MePph+Z/EwxzsnzLjnDhctF7ec=; b=lRG+DGRJDJuSaim7WPjQnsdPv2uv2v4biMSnku9oKtPP/WzksYQqX5sC6/8PJpUucp EQcotmvkcEdI4ZCD63I3OtHYBrZOtkd2HWx8823VeHcKNusonn8kiR234o3aTWT1Xp1y s2thIId4eC3wHbLutG4jNK/W7sHDN/IA6+1RK2GWgEBbnDqwabzQl+Kuhdo2CJkAIQBt pD2rQ9jY2h6ikCnU4Wf/D2CKe31X3dROnwXQt4QwmddFf8tpR10yfMSob5QvRSLx9HBR OyC7ykGXOvrwqRXmJG8vEgxFpkY3x85eakZBdxiR/UxRVNyHeTbY9cidXGDlXtnevkL9 qfCw== X-Gm-Message-State: ALoCoQmwP2zVdhGF+Q27nB8QX0K/RoK6SOEzRn2uUBDzzjW/tMJHC6EopwOy9+ZjmvjrQNSxVOGr MIME-Version: 1.0 X-Received: by 10.221.66.73 with SMTP id xp9mr21657487vcb.27.1392824947706; Wed, 19 Feb 2014 07:49:07 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 19 Feb 2014 07:49:07 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 19 Feb 2014 07:49:07 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a113642e63e207b04f2c454da Archived-At: http://mailarchive.ietf.org/arch/msg/json/57ZHG-mynnEEhXQRqbeMzfkPRBU Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 15:49:44 -0000 --001a113642e63e207b04f2c454da Content-Type: text/plain; charset=UTF-8 For the record, I think the draft language is clear and correct and we should move forward with it. On Wed, Feb 19, 2014 at 7:31 AM, Paul Hoffman wrote: > [[ Phill is the only one who has responded with a proposal to speak. > Hearing whether others want to would be useful. --Paul Hoffman ]] > > It's been a week, and yet I can't imagine that everything has been said > with respect to our proposed charter item that now stands at: > > A set of natural-language terms and/or phrases for use in future > specifications > that use JSON. This explicitly excludes schema languages and similar > formalisms. > > After that, a bunch of people started talking about formalisms and actual > schemas again. In order to get this decided, we need more discussion and > then agreement. To that end, and to put our 90 minutes on Friday afternoon > in London to best use, I will ask for at least three people to present > their views in 10-minute presentations at the meeting. However, in order to > cause this to not be the normal IETF "let's wait for the meeting" game, the > presentations need to be done by next Monday, Feb. 24. That gives people on > the list a preview of what will be said, time to argue about it, and time > for the presenters to hone their slides if they want. > > Let me know online or offline if you want to do a presentation. If you're > not going to be at the meeting but want to say something, you need to find > some like-minded soul with whom to work on the presentation. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a113642e63e207b04f2c454da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For the record, I think the draft language is clear and co= rrect and we should move forward with it.
<= br>
On Wed, Feb 19, 2014 at 7:31 AM, Paul Hof= fman <paul.hoffman@vpnc.org> wrote:
[[ Phill is the only one who has responded w= ith a proposal to speak. Hearing whether others want to would be useful. --= Paul Hoffman ]]

It's been a week, and yet I can't imagine that everything has been = said with respect to our proposed charter item that now stands at:

=C2=A0 A set of natural-language terms and/or phrases for use in future spe= cifications
=C2=A0 that use JSON. This explicitly excludes schema languages and similar= formalisms.

After that, a bunch of people started talking about formalisms and actual s= chemas again. In order to get this decided, we need more discussion and the= n agreement. To that end, and to put our 90 minutes on Friday afternoon in = London to best use, I will ask for at least three people to present their v= iews in 10-minute presentations at the meeting. However, in order to cause = this to not be the normal IETF "let's wait for the meeting" g= ame, the presentations need to be done by next Monday, Feb. 24. That gives = people on the list a preview of what will be said, time to argue about it, = and time for the presenters to hone their slides if they want.

Let me know online or offline if you want to do a presentation. If you'= re not going to be at the meeting but want to say something, you need to fi= nd some like-minded soul with whom to work on the presentation.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a113642e63e207b04f2c454da-- From nobody Wed Feb 19 07:56:46 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C504B1A022C for ; Wed, 19 Feb 2014 07:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 xPPfryu3pyi4 for ; Wed, 19 Feb 2014 07:56:42 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9271A0203 for ; Wed, 19 Feb 2014 07:56:42 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so423584lan.40 for ; Wed, 19 Feb 2014 07:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BXOHhEz9/RFTYdNR+nTlKo3BXchZr4w0mU62Hzv9aio=; b=ur4YKEFnRMPfgFvhDgKRnpeGMIl3Lif6DrmvDqouEhvClvrlc5wdk+rVNiOHxsE7Wv YI9NRMQhkUkzPsCEKKb5qIgDcYlbzzz4jOlulGc4beXiDkkHU9BwLmQCepMIYVyHOfKy VdIfgvPnDVWhZqrI1e76/ffF6q6iXXyUqhxEK8qaEq1chxkTwrAbu55WGJvWp4QntDo9 +qZTrnccSCw4R2WpQas9KwvRri0DePcNGeJntHvB+qf1DHO0Fs2Uad84RWlMC8BvIfIQ TzWtTReAB2ZmTdX1wEDhX5cxFZnFfUIJUTVeidLKlKxuxXcxFZ6Hd35N5fv27HNKJfpr +bzA== MIME-Version: 1.0 X-Received: by 10.153.9.97 with SMTP id dr1mr2376886lad.45.1392825398442; Wed, 19 Feb 2014 07:56:38 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 07:56:38 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 10:56:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11381b4e1bc08f04f2c46f7f Archived-At: http://mailarchive.ietf.org/arch/msg/json/TYHPNVJdtHmdtYu6Cim-8jNgIp8 Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 15:56:46 -0000 --001a11381b4e1bc08f04f2c46f7f Content-Type: text/plain; charset=ISO-8859-1 Perhaps we could do it a different way What features/non features would people like from a formalism for describing protocols of which JSON is at least one example? If people want a feature and it is compatible with other feature proposals then I can add it to my open source tool. However it must be noted that the strongest feature request is 'simplicity'. Are people writing tools because they want to write tools or because they want a feature in a tool? If that feature can be described as a requirement rather than an implementation, that is even easier. Since my JSON Web Service has a HTTP binding, I have to have a minimal HTTP client in the library as an option. While knocking up a simple HTTP header parser, I suddenly discovered that the HTTP headers are regular enough that they can be described using the same schema as JSON. When we did the KEYPROV working group, the main spec is in XML but a group said 'all our stuff is in ASN.1, we want a version in that' since the group in question were the IETF Chair and a Security AD, this was a pretty strong request. So even though my view is that JSON is the data model I intend to use for all future protocols (unless something else comes along), It seems to me that if we design a formal documentation/prototyping tool we should have it be capable of dumping out the equivalent XML and ASN.1 schemas. But since the capabilities of XML and ASN.1 schema are a superset of the capabilities of JSON, this is pretty easy to do. On Wed, Feb 19, 2014 at 10:31 AM, Paul Hoffman wrote: > [[ Phill is the only one who has responded with a proposal to speak. > Hearing whether others want to would be useful. --Paul Hoffman ]] > > It's been a week, and yet I can't imagine that everything has been said > with respect to our proposed charter item that now stands at: > > A set of natural-language terms and/or phrases for use in future > specifications > that use JSON. This explicitly excludes schema languages and similar > formalisms. > > After that, a bunch of people started talking about formalisms and actual > schemas again. In order to get this decided, we need more discussion and > then agreement. To that end, and to put our 90 minutes on Friday afternoon > in London to best use, I will ask for at least three people to present > their views in 10-minute presentations at the meeting. However, in order to > cause this to not be the normal IETF "let's wait for the meeting" game, the > presentations need to be done by next Monday, Feb. 24. That gives people on > the list a preview of what will be said, time to argue about it, and time > for the presenters to hone their slides if they want. > > Let me know online or offline if you want to do a presentation. If you're > not going to be at the meeting but want to say something, you need to find > some like-minded soul with whom to work on the presentation. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- Website: http://hallambaker.com/ --001a11381b4e1bc08f04f2c46f7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Perhaps we could do it a different way

= What features/non features would people like from a formalism for describin= g protocols of which JSON is at least one example?

If people want a feature and it is compatible with other feature proposals = then I can add it to my open source tool. However it must be noted that the= strongest feature request is 'simplicity'.

Are people writing tools because they want to write tools or because t= hey want a feature in a tool? If that feature can be described as a require= ment rather than an implementation, that is even easier.


Since my JSON Web Service has a HTTP binding, I h= ave to have a minimal HTTP client in the library as an option. While knocki= ng up a simple HTTP header parser, I suddenly discovered that the HTTP head= ers are regular enough that they can be described using the same schema as = JSON.

When we did the KEYPROV working group, the main spec is= in XML but a group said 'all our stuff is in ASN.1, we want a version = in that' since the group in question were the IETF Chair and a Security= AD, this was a pretty strong request.


So even though my view is that JSON is t= he data model I intend to use for all future protocols (unless something el= se comes along), It seems to me that if we design a formal documentation/pr= ototyping tool we should have it be capable of dumping out the equivalent X= ML and ASN.1 schemas. But since the capabilities of XML and ASN.1 schema ar= e a superset of the capabilities of JSON, this is pretty easy to do.



On Wed, Feb 19, 2014 at 10:31 AM, Paul Hoffman &l= t;paul.hoffman@v= pnc.org> wrote:
[[ Phill is the only one who has responded w= ith a proposal to speak. Hearing whether others want to would be useful. --= Paul Hoffman ]]

It's been a week, and yet I can't imagine that everything has been = said with respect to our proposed charter item that now stands at:

=A0 A set of natural-language terms and/or phrases for use in future specif= ications
=A0 that use JSON. This explicitly excludes schema languages and similar fo= rmalisms.

After that, a bunch of people started talking about formalisms and actual s= chemas again. In order to get this decided, we need more discussion and the= n agreement. To that end, and to put our 90 minutes on Friday afternoon in = London to best use, I will ask for at least three people to present their v= iews in 10-minute presentations at the meeting. However, in order to cause = this to not be the normal IETF "let's wait for the meeting" g= ame, the presentations need to be done by next Monday, Feb. 24. That gives = people on the list a preview of what will be said, time to argue about it, = and time for the presenters to hone their slides if they want.

Let me know online or offline if you want to do a presentation. If you'= re not going to be at the meeting but want to say something, you need to fi= nd some like-minded soul with whom to work on the presentation.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--
Website: http://hallambaker.com/
--001a11381b4e1bc08f04f2c46f7f-- From nobody Wed Feb 19 08:05:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F4E1A04FD for ; Wed, 19 Feb 2014 08:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 ycPltYkSLDA9 for ; Wed, 19 Feb 2014 08:05:22 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81D341A04F7 for ; Wed, 19 Feb 2014 08:05:22 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so603175vcb.17 for ; Wed, 19 Feb 2014 08:05:19 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=B3VXUmSmLtXp/bb9atWyD6qJe1Q4vVVO9EbYoXuJVrc=; b=Oc64S39TmrWbjn4AlRThz4z6tr20TI9eejRXLWXdhhkdJhkq3Mweyk0plSE8ajT46C R9ZURj9nlL4LcCPWDNLlCfLjru4yF/QSgIMde7aQ/S89UsaJ3Devr+4fFq/++rFJFefJ e3cTwy2IfKOBN8hSRznx3nVOKIui6ITR+Fya9VsPe7IuW0MljpLO2n0vtofVkCgbroPR P9Dtm5LYZwPmgRfqndkv9kZt6FJD+e5Y4nmgY/tD2KitwJt/Ws+VZ2HPQMWPkenCk3u4 fCYLSNFITmPce1Llun6iZUYwbX85UFESIT9UGS3Nq//8zsQLM5/T1dY2dwX/LeuBffcB Z7cQ== X-Gm-Message-State: ALoCoQkgDo+/Em++27kxXH4KkLohecIL3f8JEaUNkxIA1ov2+dm2Cq8cOV76OF9pQ+5+LDQ0aL0L MIME-Version: 1.0 X-Received: by 10.52.188.41 with SMTP id fx9mr21522539vdc.19.1392825917874; Wed, 19 Feb 2014 08:05:17 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 19 Feb 2014 08:05:17 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 19 Feb 2014 08:05:17 -0800 Message-ID: From: Tim Bray To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=bcaec5485ca011b86d04f2c48e1c Archived-At: http://mailarchive.ietf.org/arch/msg/json/liS2-iJuiwVoAMKxmY-XwjF5kyc Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 16:05:25 -0000 --bcaec5485ca011b86d04f2c48e1c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I feel that successful Internet interoperation is achieved at the level of syntax; clear specification of which bytes should be sent and which returned. Many times over the years I=E2=80=99ve heard assertions that if = you get the data model right, then the syntax is ephemeral: JSON or XML or ASN.1, who cares? I=E2=80=99ve never found that notion remotely plausible, as ther= e always impedence mismatches. You end up having to fight over another syntax to describe the model before you can fight about the syntax you=E2=80=99re goi= ng to send over the wire. This is why I deplored the recent (but vanishing, thank goodness) trend to offer APIs in XML-or-JSON-take-your-pick. So, I find Phil=E2=80=99s arguments here (as with most schema-centric argum= ents) entirely unpersuasive. On Wed, Feb 19, 2014 at 7:56 AM, Phillip Hallam-Baker wro= te: > Perhaps we could do it a different way > > What features/non features would people like from a formalism for > describing protocols of which JSON is at least one example? > > If people want a feature and it is compatible with other feature proposal= s > then I can add it to my open source tool. However it must be noted that t= he > strongest feature request is 'simplicity'. > > Are people writing tools because they want to write tools or because they > want a feature in a tool? If that feature can be described as a requireme= nt > rather than an implementation, that is even easier. > > > Since my JSON Web Service has a HTTP binding, I have to have a minimal > HTTP client in the library as an option. While knocking up a simple HTTP > header parser, I suddenly discovered that the HTTP headers are regular > enough that they can be described using the same schema as JSON. > > When we did the KEYPROV working group, the main spec is in XML but a grou= p > said 'all our stuff is in ASN.1, we want a version in that' since the gro= up > in question were the IETF Chair and a Security AD, this was a pretty stro= ng > request. > > > So even though my view is that JSON is the data model I intend to use for > all future protocols (unless something else comes along), It seems to me > that if we design a formal documentation/prototyping tool we should have = it > be capable of dumping out the equivalent XML and ASN.1 schemas. But since > the capabilities of XML and ASN.1 schema are a superset of the capabiliti= es > of JSON, this is pretty easy to do. > > > > On Wed, Feb 19, 2014 at 10:31 AM, Paul Hoffman wro= te: > >> [[ Phill is the only one who has responded with a proposal to speak. >> Hearing whether others want to would be useful. --Paul Hoffman ]] >> >> It's been a week, and yet I can't imagine that everything has been said >> with respect to our proposed charter item that now stands at: >> >> A set of natural-language terms and/or phrases for use in future >> specifications >> that use JSON. This explicitly excludes schema languages and similar >> formalisms. >> >> After that, a bunch of people started talking about formalisms and actua= l >> schemas again. In order to get this decided, we need more discussion and >> then agreement. To that end, and to put our 90 minutes on Friday afterno= on >> in London to best use, I will ask for at least three people to present >> their views in 10-minute presentations at the meeting. However, in order= to >> cause this to not be the normal IETF "let's wait for the meeting" game, = the >> presentations need to be done by next Monday, Feb. 24. That gives people= on >> the list a preview of what will be said, time to argue about it, and tim= e >> for the presenters to hone their slides if they want. >> >> Let me know online or offline if you want to do a presentation. If you'r= e >> not going to be at the meeting but want to say something, you need to fi= nd >> some like-minded soul with whom to work on the presentation. >> >> --Paul Hoffman >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --bcaec5485ca011b86d04f2c48e1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I feel that successful Internet interoperation is achieved= at the level of syntax; clear specification of which bytes should be sent = and which returned. =C2=A0Many times over the years I=E2=80=99ve heard asse= rtions that if you get the data model right, then the syntax is ephemeral: = JSON or XML or ASN.1, who cares? I=E2=80=99ve never found that notion remot= ely plausible, as there always impedence mismatches. =C2=A0You end up havin= g to fight over another syntax to describe the model before you can fight a= bout the syntax you=E2=80=99re going to send over the wire.=C2=A0

This is why I deplored the recent (but vanishing, thank goodness) = trend to offer APIs in XML-or-JSON-take-your-pick.

So, I= find Phil=E2=80=99s arguments here (as with most schema-centric arguments)= entirely unpersuasive.


On Wed, Feb 19, 2014 at 7:56 AM, Phillip Hallam-Baker <hallam@gmail.co= m> wrote:
Perhaps we could do it a di= fferent way

What features/non features would people like= from a formalism for describing protocols of which JSON is at least one ex= ample?

If people want a feature and it is compatible with other feature proposals = then I can add it to my open source tool. However it must be noted that the= strongest feature request is 'simplicity'.

Are people writing tools because they want to write tools or because t= hey want a feature in a tool? If that feature can be described as a require= ment rather than an implementation, that is even easier.


Since my JSON Web Service has a HTTP binding, I h= ave to have a minimal HTTP client in the library as an option. While knocki= ng up a simple HTTP header parser, I suddenly discovered that the HTTP head= ers are regular enough that they can be described using the same schema as = JSON.

When we did the KEYPROV working group, the main spec is= in XML but a group said 'all our stuff is in ASN.1, we want a version = in that' since the group in question were the IETF Chair and a Security= AD, this was a pretty strong request.


So even though my view is that JSON is t= he data model I intend to use for all future protocols (unless something el= se comes along), It seems to me that if we design a formal documentation/pr= ototyping tool we should have it be capable of dumping out the equivalent X= ML and ASN.1 schemas. But since the capabilities of XML and ASN.1 schema ar= e a superset of the capabilities of JSON, this is pretty easy to do.


=
On Wed, Feb 19, 2014 at 10:31 AM, Paul Hoffm= an <paul.hoffman@vpnc.org> wrote:
[[ Phill is the only one who has responded w= ith a proposal to speak. Hearing whether others want to would be useful. --= Paul Hoffman ]]

It's been a week, and yet I can't imagine that everything has been = said with respect to our proposed charter item that now stands at:

=C2=A0 A set of natural-language terms and/or phrases for use in future spe= cifications
=C2=A0 that use JSON. This explicitly excludes schema languages and similar= formalisms.

After that, a bunch of people started talking about formalisms and actual s= chemas again. In order to get this decided, we need more discussion and the= n agreement. To that end, and to put our 90 minutes on Friday afternoon in = London to best use, I will ask for at least three people to present their v= iews in 10-minute presentations at the meeting. However, in order to cause = this to not be the normal IETF "let's wait for the meeting" g= ame, the presentations need to be done by next Monday, Feb. 24. That gives = people on the list a preview of what will be said, time to argue about it, = and time for the presenters to hone their slides if they want.

Let me know online or offline if you want to do a presentation. If you'= re not going to be at the meeting but want to say something, you need to fi= nd some like-minded soul with whom to work on the presentation.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--
Website: http://hallambaker.com/

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--bcaec5485ca011b86d04f2c48e1c-- From nobody Wed Feb 19 08:06:24 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5751A055A for ; Wed, 19 Feb 2014 08:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 9KcL8I2CPrWo for ; Wed, 19 Feb 2014 08:06:21 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id C9FA21A04F7 for ; Wed, 19 Feb 2014 08:06:21 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 9167426C078 for ; Wed, 19 Feb 2014 08:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Yn5sPIYFcYDR/qFKUSvt yED7+2E=; b=wEOQ/yLG9C8WaQoYUSoqdPzDSaZw2CTyRtAwd0bwNjiK9huFSpe7 EYSaah/T8Vu+ZYQmKLFQWMy8DahCoVaP4IQcu5PT8v7ih251WcTCLMyJ2RFltn3w Fg3Fr27sGdUu9PTZirhpYSBuax6BWOWg28sdsA/bOBYgFaOYLytuMQ0= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 2964A26C05E for ; Wed, 19 Feb 2014 08:06:17 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id y10so493903wgg.4 for ; Wed, 19 Feb 2014 08:06:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3DU6dn0kE1miCjvkk794GbYIYWGc0aZzrboMe68Ac+s=; b=kEHlVoauVq1ivdZE8o2EtzE9JOUZ4v8t9xipICBP2gGkjjWSdne++WC9M+HBVxYMIw pIijdfq/ULO9UjuWdiGW2d2GZYy2teGomarDUwfxKr2xhxr7mlb1+XAZtSDrMR3xrEtd nXbrm74W3wVyvfuZ7GebwIt5Z3Gm+nDqzDb/YYLdxHVdZBe3KDcy3y9sgXQvd/BgXaSV chR4J5RTTAeq8L6ebHQp9nHkT8+zUAtTWp2ndbprCX0fUcfpe6/nSTXp9PLLaqUwDR+o u+48FKQeizkrBQVAvxElhNBiUbefRukkToDXwQIQYGECbUxOHpINkwgDuyhOqqzvoiAQ h9pA== MIME-Version: 1.0 X-Received: by 10.194.185.165 with SMTP id fd5mr1762863wjc.95.1392825976330; Wed, 19 Feb 2014 08:06:16 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 08:06:16 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 10:06:16 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/6At4bIKi28Bs7_WWiJXj3ULyFrA Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 16:06:23 -0000 On Wed, Feb 19, 2014 at 9:56 AM, Phillip Hallam-Baker wrote: > So even though my view is that JSON is the data model I intend to use for > all future protocols (unless something else comes along), It seems to me > that if we design a formal documentation/prototyping tool we should have it > be capable of dumping out the equivalent XML and ASN.1 schemas. But since > the capabilities of XML and ASN.1 schema are a superset of the capabilities > of JSON, this is pretty easy to do. Sure that's doable. Quick question: should a JSON schema also follow the model of defining "types", like ASN.1? Or do you have something else in mind? Nico -- From nobody Wed Feb 19 08:31:10 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F43E1A0249 for ; Wed, 19 Feb 2014 08:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 5pfSCBgYc0VT for ; Wed, 19 Feb 2014 08:31:06 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id EE4CB1A01CE for ; Wed, 19 Feb 2014 08:31:05 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WGA31-0005R1-5w; Wed, 19 Feb 2014 11:30:59 -0500 Date: Wed, 19 Feb 2014 11:30:59 -0500 From: John Cowan To: Tim Bray Message-ID: <20140219163059.GA18485@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/8AKNbdVPrUDYk4_gP9zy7YIOvOc Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 16:31:09 -0000 Tim Bray scripsit: > I feel that successful Internet interoperation is achieved at the level of > syntax; clear specification of which bytes should be sent and which > returned. It took me years to realise how deep and important the divide is between wanting an SDK and wanting to know the underlying protocol. Too much of our biz can only see one of these realities. I grew up with networked minicomputers and (mostly) Unix, and maybe that's why, in the final analysis, I always want to see the bits on the wire, because in the final analysis, given any programmable device, I can work with them. --Tim Bray, some time before 2001 -- All Gaul is divided into three parts: the part John Cowan that cooks with lard and goose fat, the part http://ccil.org/~cowan that cooks with olive oil, and the part that cowan@ccil.org cooks with butter. --David Chessler From nobody Wed Feb 19 08:52:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEBA1A05E1 for ; Wed, 19 Feb 2014 08:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 OmWVIFvCdb2Y for ; Wed, 19 Feb 2014 08:52:21 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 291BF1A05CF for ; Wed, 19 Feb 2014 08:52:20 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id c11so483245lbj.2 for ; Wed, 19 Feb 2014 08:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Txo5Nn8IOIYDlPY9KaV8od0HdNNHDs/mNFjhwV6RA1s=; b=VKyR9EcXu0HFW88+kpjgMFVaAt3oE2V4CfC4hHmKqqAZ1DHbVuQJrq1tkG+wWtJZOd Zdu49zrLaTZG8HO8X0eHCkxtiz1Cp0zmxN2fC2AYpO1scICUvQutusbHXN6equ6oX+GR Ne+152CBsddBZeu2y2IFZpSqeqdhArjW6/HzVtJseiVKDm8MEzFBa7riKrwxETOQM2qm 1oAfjg/GBOk9loVnUholQUScq9hWwBAYEXi8FYIh2bPe/9u4WZ1PTlsfAlubTAOXmnXW MCnY1+Dq5VgZMkA3IyF202wlC7NUBnAGi3b9Hb4KsqCUYFCrQ1JRmJyTljAVhkDOQGKq gyDg== MIME-Version: 1.0 X-Received: by 10.152.25.165 with SMTP id d5mr1005914lag.89.1392828737175; Wed, 19 Feb 2014 08:52:17 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 08:52:17 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 11:52:17 -0500 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=089e0160bbe21cc47104f2c53656 Archived-At: http://mailarchive.ietf.org/arch/msg/json/wiEgvgqlOV4J3R6zlMegCus-exI Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 16:52:25 -0000 --089e0160bbe21cc47104f2c53656 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 11:05 AM, Tim Bray wrote: > I feel that successful Internet interoperation is achieved at the level of > syntax; clear specification of which bytes should be sent and which > returned. Many times over the years I've heard assertions that if you get > the data model right, then the syntax is ephemeral: JSON or XML or ASN.1, > who cares? I've never found that notion remotely plausible, as there always > impedence mismatches. You end up having to fight over another syntax to > describe the model before you can fight about the syntax you're going to > send over the wire. > The point is to focus the discussion on the data going over the wire rather than the syntax. When the discussion is about syntax, that is usually a specification smell. Take HTTP's weak e-tags ETag: W/"who/ordered/this" Now syntax is the very least of the issues that ETags raise. But the resort to this particular syntax should have at least been a hint of the problems to come. Another peculiarity of the HTTP spec, there are two encodings for dates that parsers must support. Both contain completely useless information (why does a machine need to know the day of the week anyway). Both are needlessly verbose but we are talking about compressing headers rather than not sending irrelevant data. If people had not got into the weeds on syntax we might have come up with a better caching model. I don't see the value in having multiple encodings for a Web Service. But I would much rather do that than end up with two separate specifications because one group wanted ASN.1 and the other XML or some people want JSON and others must have XML. XML Web services have a whole ecology that some people are very heavily bought into. They really can't use a specification that doesn't play nice with that system. JSON is the future for new work. But just as the PKIX people had a point when they asked for an ASN.1 version of KEYPROV, there are going to be people whose existing infrastructure is XML who want to make use of work being done by a WG producing a JSON spec. The point is that the function of this group and any other platform level group is to support the work of the IETF WGs and the other groups that want to build on top. If we can provide them with a mechanism that allows them to provide a smooth transition path to the common encoding syntax, that helps them meet their goals. -- Website: http://hallambaker.com/ --089e0160bbe21cc47104f2c53656 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 19, 2014 at 11:05 AM, Tim Bray <tbray@textuality.co= m> wrote:
I feel that successful Inte= rnet interoperation is achieved at the level of syntax; clear specification= of which bytes should be sent and which returned.  Many times over th= e years I’ve heard assertions that if you get the data model right, t= hen the syntax is ephemeral: JSON or XML or ASN.1, who cares? I’ve ne= ver found that notion remotely plausible, as there always impedence mismatc= hes.  You end up having to fight over another syntax to describe the m= odel before you can fight about the syntax you’re going to send over = the wire. 

The point is to focus the discussion on th= e data going over the wire rather than the syntax.


When the discussion is about syntax, that is usually a spec= ification smell. Take HTTP's weak e-tags

ETag: W/"who/ordered/this"

Now syntax is the very least of the issues that ETags raise. But the= resort to this particular syntax should have at least been a hint of the p= roblems to come.

Another peculiarity of the HTTP spec, there are two enc= odings for dates that parsers must support. Both contain completely useless= information (why does a machine need to know the day of the week anyway). = Both are needlessly verbose but we are talking about compressing headers ra= ther than not sending irrelevant data. If people had not got into the weeds= on syntax we might have come up with a better caching model.


I don't see the value in havin= g multiple encodings for a Web Service. But I would much rather do that tha= n end up with two separate specifications because one group wanted ASN.1 an= d the other XML or some people want JSON and others must have XML.

XML Web services have a whole ecology that some people = are very heavily bought into. They really can't use a specification tha= t doesn't play nice with that system. 

JS= ON is the future for new work. But just as the PKIX people had a point when= they asked for an ASN.1 version of KEYPROV, there are going to be people w= hose existing infrastructure is XML who want to make use of work being done= by a WG producing a JSON spec.


The point is that the function of this g= roup and any other platform level group is to support the work of the IETF = WGs and the other groups that want to build on top. If we can provide them = with a mechanism that allows them to provide a smooth transition path to th= e common encoding syntax, that helps them meet their goals.


--
Website: http://hallambaker.com/
--089e0160bbe21cc47104f2c53656-- From nobody Wed Feb 19 09:19:06 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AA21A04FF for ; Wed, 19 Feb 2014 09:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 QwO1e7UWyUQV for ; Wed, 19 Feb 2014 09:19:03 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 850041A04CC for ; Wed, 19 Feb 2014 09:19:03 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id jx11so689599veb.35 for ; Wed, 19 Feb 2014 09:19:00 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=s8tox5puk05bqL6zkjchOW5OiIAXX08+7LOFlWnLK34=; b=bejxtKKBuYiqV2UCvRFifaPdQkBQ9tqlwXXC+v9xlcNTatY1mS+gbGdsNZH8c1W1Ge 8dl1IbBCd8ixVAR5/XbWWefJzqGPLQ7ugfzouWbWnMdRxwwpSCXj0D9+SeIzuwN5SuDU LpE1HeWDP//tEbJ3gZdL2wylx2MMtpmROxEJwG1pk2oI3kM1rgJfqoL0chxCDRgao+Ea wT0Y3oQunMQzdtY7hy9g/rlFrai/rJTbGW1vmuicsn7d197i003/y0dwfls6GSKeHjrN 3HhT0ubr1jaw3fnjXf3uFTrnvARM9A8LNw7XB03xxmvr+OzYq/nus9gewYPfiiEc28+I B86w== X-Gm-Message-State: ALoCoQmTqifjam1cjOFv+jbcP7GprYxsnUgWhIn2HZXxrHzxvlp0j74XQWjLGz54Fo4WvfZFfZBZ MIME-Version: 1.0 X-Received: by 10.220.71.20 with SMTP id f20mr1147249vcj.70.1392830339995; Wed, 19 Feb 2014 09:18:59 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 19 Feb 2014 09:18:59 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 19 Feb 2014 09:18:59 -0800 Message-ID: From: Tim Bray To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7b33dc44a5dc3504f2c59529 Archived-At: http://mailarchive.ietf.org/arch/msg/json/o_buNlu3rWKcP0KH8ezFwcpySEY Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:19:06 -0000 --047d7b33dc44a5dc3504f2c59529 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 19, 2014 at 8:52 AM, Phillip Hallam-Baker wrote: > > The point is to focus the discussion on the data going over the wire > rather than the syntax. > > > When the discussion is about syntax, that is usually a specification > smell. Take HTTP's weak e-tags > > ETag: W/"who/ordered/this" > > Now syntax is the very least of the issues that ETags raise. But the > resort to this particular syntax should have at least been a hint of the > problems to come. > > Another peculiarity of the HTTP spec, there are two encodings for dates > that parsers must support. Both contain completely useless information (why > does a machine need to know the day of the week anyway). Both are > needlessly verbose but we are talking about compressing headers rather than > not sending irrelevant data. If people had not got into the weeds on syntax > we might have come up with a better caching model. > > > I don't see the value in having multiple encodings for a Web Service. But > I would much rather do that than end up with two separate specifications > because one group wanted ASN.1 and the other XML or some people want JSON > and others must have XML. > > XML Web services have a whole ecology that some people are very heavily > bought into. They really can't use a specification that doesn't play nice > with that system. > > JSON is the future for new work. But just as the PKIX people had a point > when they asked for an ASN.1 version of KEYPROV, there are going to be > people whose existing infrastructure is XML who want to make use of work > being done by a WG producing a JSON spec. > > > The point is that the function of this group and any other platform level > group is to support the work of the IETF WGs and the other groups that want > to build on top. If we can provide them with a mechanism that allows them > to provide a smooth transition path to the common encoding syntax, that > helps them meet their goals. > > > -- > Website: http://hallambaker.com/ > --047d7b33dc44a5dc3504f2c59529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 19, 2014 at 8:52 AM, Phillip Hallam-Baker <hallam@gmail.com>= wrote:
=
The point is to focus the di= scussion on the data going over the wire rather than the syntax.


When the discussion is about synta= x, that is usually a specification smell. Take HTTP's weak e-tags

ETag: W/"who/ordered/this"

Now syntax is the very least of the issues that ETags raise. But the= resort to this particular syntax should have at least been a hint of the p= roblems to come.

Another peculiarity of the HTTP spec, there are two enc= odings for dates that parsers must support. Both contain completely useless= information (why does a machine need to know the day of the week anyway). = Both are needlessly verbose but we are talking about compressing headers ra= ther than not sending irrelevant data. If people had not got into the weeds= on syntax we might have come up with a better caching model.


I don't see the value in havin= g multiple encodings for a Web Service. But I would much rather do that tha= n end up with two separate specifications because one group wanted ASN.1 an= d the other XML or some people want JSON and others must have XML.

XML Web services have a whole ecology that some people = are very heavily bought into. They really can't use a specification tha= t doesn't play nice with that system.=C2=A0

JS= ON is the future for new work. But just as the PKIX people had a point when= they asked for an ASN.1 version of KEYPROV, there are going to be people w= hose existing infrastructure is XML who want to make use of work being done= by a WG producing a JSON spec.


The point is that the function of this g= roup and any other platform level group is to support the work of the IETF = WGs and the other groups that want to build on top. If we can provide them = with a mechanism that allows them to provide a smooth transition path to th= e common encoding syntax, that helps them meet their goals.


--
Website: http://hallambaker.com/

--047d7b33dc44a5dc3504f2c59529-- From nobody Wed Feb 19 09:20:15 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61FC1A0249 for ; Wed, 19 Feb 2014 09:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 n18MIRPL_cyS for ; Wed, 19 Feb 2014 09:20:12 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3494D1A0241 for ; Wed, 19 Feb 2014 09:20:12 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id C701A778082 for ; Wed, 19 Feb 2014 09:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=+0lUpLsQEICxtk+wJ9DqviSODWM=; b=F+HoKovTPr3 I3aKphCUlApXDgVoqCYcLasDoeQcf8JrOVrbKGQcznTWGA2kMAcRcGI3N8FSvjB+ bW7QB6qPHBcyq1e4YkDDc19moJSwGykECdsUScm5HTWpM6yPUOFnv6sg4VzS/CHu yJM9tgK3kQrneLngUAmtn67K2RliwS6A= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 66BD1778077 for ; Wed, 19 Feb 2014 09:20:06 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id e4so4950770wiv.5 for ; Wed, 19 Feb 2014 09:20:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SOmBjzFIijnjOa3mBMobZZtXr/Pj2LeGDQDOjFN+xWI=; b=SR7AJfb+/3zvKdd6UkXY9Qqo5CsKEncgwpCOqDrEtHGB7aifcDdJiGdS+qCSbc4rop ADJURhjNH9l2NZw/lyQfNZTIbkqV98Q5Tt4rOtBl1qLbFQXaKUboBW/SQ1wKkdNf8Uvw v9g22FVWPNzS3ViT3g190GuAWTKeQY7thSQ+iBGZCpIUw8/YvuPJbjS37AVDfDD+clkc vkTBbMDO9wtQga4euYXZp0R2THjSCrA2LqIcTZgtsSUtUaBK2s8eCzPBhe7CWH1WiQuW axyyBspBdvtshXnl17zoS4uN2gU1o3+4QLyyTfUW1Pw1BH0Qibe53hEYPPNwd9PYk4DG mR2A== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr2597771wib.39.1392830403980; Wed, 19 Feb 2014 09:20:03 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 09:20:03 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 11:20:03 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/Kc_U1NZJ9myRr97ic0t8f-idoLQ Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:20:14 -0000 On Wed, Feb 19, 2014 at 10:05 AM, Tim Bray wrote: > This is why I deplored the recent (but vanishing, thank goodness) trend t= o > offer APIs in XML-or-JSON-take-your-pick. First this objection: indeed, no one should want that. The only such conversion that makes sense is JSON->HTML for BUIs, and that should happen mostly on the client side (except for dumb clients, if the service wants to reach them). Even if the conversion can be completely automatic. Why would anyone want to burn cycles/energy running such conversions (except perhaps for the JSON->HTML for dumb clients case)? > I feel that successful Internet interoperation is achieved at the level o= f > syntax; clear specification of which bytes should be sent and which > returned. Many times over the years I=E2=80=99ve heard assertions that i= f you get > the data model right, then the syntax is ephemeral: JSON or XML or ASN.1, > who cares? I=E2=80=99ve never found that notion remotely plausible, as th= ere always > impedence mismatches. You end up having to fight over another syntax to > describe the model before you can fight about the syntax you=E2=80=99re g= oing to > send over the wire. The syntax is no more ephemeral than the RFC is (where there's an RFC). Sometimes there's just no need for an RFC. Most services out there that define HTTP+JSON APIs don't bother publishing I-Ds for them, much less RFCs, _even when then promise API stability_. Yet even then, syntax can help others implement clients for those APIs -- that's the point of publishing an API: to help others implement clients for them, to increase the popularity of the service. > So, I find Phil=E2=80=99s arguments here (as with most schema-centric arg= uments) > entirely unpersuasive. Phil proposed that conversions to ASN.1 be feasible to please certain people, not to allow services to serve JSON-or-DER or anything of the sort. Your argument about the latter is therefore a non-sequitur. My proposal is that the WG take all comers for JSON schema languages as Informational and leave it at that (well, all proposals for which there's enough authors and reviewers, enough interest). That can't even be an irritant for you: you can ignore them... ...unless you think that formal languages used by others will impair your ability to understand their specs, unless you really prefer English prose to the max. That'd be an argument I'd want to hear, if you were making it. I'm prepared to buy into a strong such argument, even though you can probably tell that biased in favor of simple schema languages. Nico -- From nobody Wed Feb 19 09:22:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299641A0249 for ; Wed, 19 Feb 2014 09:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Kx_cUaL7tN0f for ; Wed, 19 Feb 2014 09:22:34 -0800 (PST) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2B61A04E7 for ; Wed, 19 Feb 2014 09:22:34 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id c14so690186vea.6 for ; Wed, 19 Feb 2014 09:22:31 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=k8ZX4oQFJQeOSr8X+w6Yp4ZeLvkzzZ+FB3Dz73sXPj0=; b=iy0N2oANKAS0CNullMDn+vBWzaqeW9sxlVFfEucPsXzJYUIwXLGjZCX5a780Fec2Uo G4nbwv2RKjd8oLqt6fKfvM3BIxbfI2BgAjvvGuGwUos8z6hUdfYsx7rtFrKmrlSJpdck PON6urT4nMFDRYwwCTv3Kd1t/MDOYBdbXNKeH9tY0wM/MZNQD4pN7g4Xp3uyQt2a4lbc tzpDpc3hVJ+S3Ep/EACuwzUmfqtROX2igb05sKNXJxYulIVdVp+Hf9mscXP5a/G18dkx c63DKCawcAu3lqO+XY2Jl8v3V3aN25eh/oa0PxdIlpNt6RljwiKr3JxtvLZqS3CPNBk5 2FcQ== X-Gm-Message-State: ALoCoQm0NvoqsmjHS1R3wF0fgc2BAHl2INGAwnk9ffV8bAFZzUE5ey92nlieWZZUxoju8cGXEJnN MIME-Version: 1.0 X-Received: by 10.52.77.9 with SMTP id o9mr955879vdw.82.1392830550996; Wed, 19 Feb 2014 09:22:30 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 19 Feb 2014 09:22:30 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 19 Feb 2014 09:22:30 -0800 Message-ID: From: Tim Bray To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=bcaec50160c1397f7804f2c5a2ed Archived-At: http://mailarchive.ietf.org/arch/msg/json/EF5Z7sGhr4EXM6AtK08NA9p6kKk Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:22:36 -0000 --bcaec50160c1397f7804f2c5a2ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [pardon the mangled email. Blame my cat] On Wed, Feb 19, 2014 at 8:52 AM, Phillip Hallam-Baker wro= te: > > The point is to focus the discussion on the data going over the wire > rather than the syntax. > Here is where we disagree absolutely. The point is to specify the syntax clearly and unambiguously, and the semantics of its payload. Trying to come at it from the other direction (specifying data structures and then extracting syntax) leads to huge mistakes like CORBA and WS-*. You go on to provide examples of badly-designed protocol syntax. I don=E2= =80=99t think we have any disagreement that bad design is possible and should be avoided. > > --bcaec50160c1397f7804f2c5a2ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[pardon the mangled email. Blame my cat]

On Wed, Feb 19, 2014 at 8:52 AM, Ph= illip Hallam-Baker <hallam@gmail.com> wrote:
=

The po= int is to focus the discussion on the data going over the wire rather than = the syntax.

Here is where we disagre= e absolutely. The point is to specify the syntax clearly and unambiguously,= and the semantics of its payload. =C2=A0Trying to come at it from the othe= r direction (specifying data structures and then extracting syntax) leads t= o huge mistakes like CORBA and WS-*.

You go on to provide examples of badly-designed protoco= l syntax. =C2=A0I don=E2=80=99t think we have any disagreement that bad des= ign is possible and should be avoided.
=C2=A0

--bcaec50160c1397f7804f2c5a2ed-- From nobody Wed Feb 19 09:25:20 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93811A022F for ; Wed, 19 Feb 2014 09:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 h9guGtFX0mwJ for ; Wed, 19 Feb 2014 09:25:17 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06E1A00B8 for ; Wed, 19 Feb 2014 09:25:17 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WGAtT-0002h7-Ma; Wed, 19 Feb 2014 12:25:11 -0500 Date: Wed, 19 Feb 2014 12:25:11 -0500 From: John Cowan To: Tim Bray Message-ID: <20140219172511.GA8132@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/hmgFfcRUbittmYq2ALqIxSID38g Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:25:18 -0000 Tim Bray scripsit: > > The point is to focus the discussion on the data going over the wire > > rather than the syntax. > > Here is where we disagree absolutely. The point is to specify the syntax > clearly and unambiguously, and the semantics of its payload. Trying to > come at it from the other direction (specifying data structures and then > extracting syntax) leads to huge mistakes like CORBA and WS-*. I agree absolutely with Tim, if it wasn't clear before. Semantics is vague and fuzzy (my semantics of your JSON may consist solely in counting the number of fields in the top-level object, for example). Syntax is not. Agreement on syntax promotes interoperation; agreement on semantics takes forever, pushing syntax to the rear, thus tending to create bad syntax. -- What asininity could I have uttered John Cowan that they applaud me thus? http://www.ccil.org/~cowan --Phocion, Greek orator From nobody Wed Feb 19 09:30:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D370E1A0249 for ; Wed, 19 Feb 2014 09:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 YE913fIT_6CI for ; Wed, 19 Feb 2014 09:30:24 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7424A1A00B2 for ; Wed, 19 Feb 2014 09:30:24 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id la4so712740vcb.35 for ; Wed, 19 Feb 2014 09:30:21 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=pDoyI7XU6BY8qSTthXj7GgnHoEDMJACwJ3UoT/z7SEY=; b=JUu6gweQZ3zK1n9t2n+0NmZ3Vl+NMeAU1Pz+UuLGnarACGQW+Gpv7qZpkCF5HGXCLN S9rfeVT2IrOgxLcmpOFPmwURUWcBGNVbgD8HcNrwPyBl7D6m6ha88oXICQbwJks2/Rvn zVpQB6gXWSWz7VE+KgGwVeByzgWG0ka5CoBoGRja8jvOS9huS4lIjDyxaO5plMqjWskS KASoRNwumlNbs65YrmrDpWOZ1hZd2yeSfCVERSR89u3xwj0DjZkGFv0sUbDLQOaX1aJF aGc9aDnPrHnFzbt5SCoabV9oD9Am1wqWx+462DlrrOhKQcTdKUUEIA+MZdGdAS5AC+qq UeAQ== X-Gm-Message-State: ALoCoQk43VZZRkusCNNUPHbJ9i6qbp1UtPLzoFEYJ2N7RDwrE+EAYQCUYXWzRKJk9r/22+FN4jI6 MIME-Version: 1.0 X-Received: by 10.52.63.233 with SMTP id j9mr988607vds.69.1392831020806; Wed, 19 Feb 2014 09:30:20 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 19 Feb 2014 09:30:20 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 19 Feb 2014 09:30:20 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=001a11369b043a49d604f2c5be02 Archived-At: http://mailarchive.ietf.org/arch/msg/json/_EKGe0AXv_mUOur6e-qH2bBuPsc Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:30:27 -0000 --001a11369b043a49d604f2c5be02 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 19, 2014 at 9:20 AM, Nico Williams wrote: My proposal is that the WG take all comers for JSON schema languages > as Informational and leave it at that (well, all proposals for which > there's enough authors and reviewers, enough interest). That can't > even be an irritant for you: you can ignore them... > No harm in that, although I also perceive little benefit. > ...unless you think that formal languages used by others will impair > your ability to understand their specs, unless you really prefer > English prose to the max. That'd be an argument I'd want to hear, if > you were making it. I think schemas can be useful (but designing good schema languages is horribly hard, and so easy to get wrong). I think clear English prose is *essential*, the one thing a specification must have. Thus, schemas can be actively harmful if arguing over them distracts attention from crafting the prose properly. This is particularly the case when the schema language is a flawed tool, which so many of them are. I also think that for most protocols, an open-source validator is immensely more useful than a schema. Validators can check semantic constraints that are in principle inaccessible to schema languages, especially simple ones. --001a11369b043a49d604f2c5be02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 19, 2014 at 9:20 AM, Nico Williams <nico@cryptonector.com&= gt; wrote:

My proposal is that the WG take all comers for JSON schema languages
=
as Informational and leave it at that (well, all proposals for which
there's enough authors and reviewers, enough interest). =C2=A0That can&= #39;t
even be an irritant for you: you can ignore them...
No harm in that, although I also perceive little benefit.
=C2=A0
...unless you think that formal languages used by others will impair
your ability to understand their specs, unless you really prefer
English prose to the max. =C2=A0That'd be an argument I'd want to h= ear, if
you were making it.

I think schemas can be = useful (but designing good schema languages is horribly hard, and so easy t= o get wrong). =C2=A0

I think clear English prose i= s *essential*, the one thing a specification must have. Thus, schemas can b= e actively harmful if arguing over them distracts attention from crafting t= he prose properly. =C2=A0This is particularly the case when the schema lang= uage is a flawed tool, which so many of them are.

I also think that for most protocols, an open-source va= lidator is immensely more useful than a schema. Validators can check semant= ic constraints that are in principle inaccessible to schema languages, espe= cially simple ones.


--001a11369b043a49d604f2c5be02-- From nobody Wed Feb 19 09:31:03 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7C1A0249 for ; Wed, 19 Feb 2014 09:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 4lD6r49AMfLY for ; Wed, 19 Feb 2014 09:30:58 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1AC1A040C for ; Wed, 19 Feb 2014 09:30:58 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id B22402AC09C for ; Wed, 19 Feb 2014 09:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dK4IrUbExbmWpQbN6l0b AYWGFPA=; b=poOb535JU79bIzF3iFW5H2l1xcMmf+f+AB57+28pgoMLXkCnWQGf e7yE215d4GDkzbjov/eJnhDuIOgN4BDcCrBEu0MP+D0L30ooU0mq+aOYmiwRbhnf AtnRU7MuWFcdt4uQmA4eistpFOLDrK32/wtLVSj5xu3dIlUgvctHDXs= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 409DE2AC093 for ; Wed, 19 Feb 2014 09:30:52 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so871782wib.7 for ; Wed, 19 Feb 2014 09:30:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9OAICQIEDEMZOk6+/q9w1jIiriZC3+U996be/XUh14g=; b=HHmqPmoycgetWahm2dvHyYM0gmqg1JyTHgSZ7wQ+VPkiIM5ZKAI1SgR8xzcaxwEvOL HpEXwSFZlYNcLfcXJI9O371SvOSn1ord+oHzNrNQp0S4Ql9NWKtVyiRahZJA3hmeSrP8 Ey5KI6kCcqADIRy/W07sGbixsxRPZQkf2iGzLm/LD0Yj9qyy+2A7MVmKZxF09qFx35XH 3LpQSUg8YWbRpEHaSnneE3dnRTgEcvuTsWu3dAUDOD4dVfIZ1O3XMcIW8y6dAyex+vOS 98INioqO+TqVqI+pPqpARNikjRpGTp4H+54bpHzHUhBJcoNat7K6op0S7hr/yyEser0H vKrA== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr2653724wib.39.1392831050275; Wed, 19 Feb 2014 09:30:50 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 09:30:50 -0800 (PST) In-Reply-To: <20140219163059.GA18485@mercury.ccil.org> References: <20140219163059.GA18485@mercury.ccil.org> Date: Wed, 19 Feb 2014 11:30:50 -0600 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/l_ADydc39ZaDwBryXEedUrC9XX0 Cc: Phillip Hallam-Baker , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:31:00 -0000 On Wed, Feb 19, 2014 at 10:30 AM, John Cowan wrote: > Tim Bray scripsit: > >> I feel that successful Internet interoperation is achieved at the level of >> syntax; clear specification of which bytes should be sent and which >> returned. > > It took me years to realise how deep and important the divide is between > wanting an SDK and wanting to know the underlying protocol. Too much of > our biz can only see one of these realities. I grew up with networked > minicomputers and (mostly) Unix, and maybe that's why, in the final > analysis, I always want to see the bits on the wire, because in the > final analysis, given any programmable device, I can work with them. > --Tim Bray, some time before 2001 I'll grant that SDK-only protocols are bad in this context: because the protocols then are proprietary (whereas we're the IETF, and we do open protocols). I don't see what the problem is with open protocols with abstract APIs... or, for that matter, message descriptions in some formal (or even ad-hoc but not just English prose) syntaxes. Nor do I see the relevance of the above quote to this thread: it's yet another non-sequitur. I get that some don't want any JSON schemas, to which my answer is: so don't use them. But please refrain from fallacious arguments. Nico -- From nobody Wed Feb 19 09:40:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2379C1A00B8 for ; Wed, 19 Feb 2014 09:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 4Op07ikhPRw7 for ; Wed, 19 Feb 2014 09:40:17 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 403E71A01CE for ; Wed, 19 Feb 2014 09:40:16 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id C6940318097 for ; Wed, 19 Feb 2014 09:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=exGObXQR4v53TxHcvTOE ESuAItM=; b=EAZsKLCC1+Y1ndOk3wZa+eLHoyRc5y0JIzUWTSVC9G9uiB/t92KY TibkOe9gmUUEMZXUDw5i0QPfO01hkvU6t8p9cGlNzGilpp8/Oa0Al6WU83JhPlfy 2nzD+kNRzqpeJCTGMk3Jsjk/UG0BzZg0BZtdlEzFxcJVeJ7pBJtjhb0= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 35F08318096 for ; Wed, 19 Feb 2014 09:40:08 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id t61so590679wes.22 for ; Wed, 19 Feb 2014 09:40:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hFsVvs1nzHe8U450NobvaARpImQuCAX6SXafE6EfymY=; b=XOQnYwRiZwL/hKIEa9nOWF116ZetYBy/Kv6ZsXOaWU+JCASM5CJ9xFc/we6VFbqBr9 chYrn65jtPsFviETpxD12xVIYpr/4TVd6L2mjAGZcDjL9TX+qb3g7eqNuqvEQTkoZFh3 iEdME20xDFiVfFuywZkiwTIKDS7inrKmYGRFTjWqybRkO3FIj2IIhn5mdTu9paNmTW2m LDByHrmUW3+dORTdsunnFvTlez4iIyeUevW2WLjmPiUbCL47Bx2jkiQoVOqNjGpltHNt 4LMKAL7xThVTZIfSlTAb+v4y77MeqsPmvC7phpdTamCNWrjzDJPgae3aazxnA64LTol7 moZA== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr2697759wib.39.1392831605824; Wed, 19 Feb 2014 09:40:05 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 09:40:05 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 11:40:05 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/70yy8L9YsLHKf3McLJipOj92Jcg Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:40:20 -0000 On Wed, Feb 19, 2014 at 11:30 AM, Tim Bray wrote: > On Wed, Feb 19, 2014 at 9:20 AM, Nico Williams > wrote: >> My proposal is that the WG take all comers for JSON schema languages >> as Informational and leave it at that (well, all proposals for which >> there's enough authors and reviewers, enough interest). That can't >> even be an irritant for you: you can ignore them... > > No harm in that, although I also perceive little benefit. So ignore them. Advise against their use even. > I think schemas can be useful (but designing good schema languages is > horribly hard, and so easy to get wrong). Hard? Nah, it's just an exercise in re-inventing the same wheel again. XDR is really a subset of ASN.1, with different syntax, but clearly it's possible to map XDR on ASN.1 trivially. Ditto DCE RPC's IDL. And so on. I really want any JSON schema to be expressed in JSON itself: we all have JSON parsers, so at least the first step is done and we won't have to worry about how difficult it is to write LALR(1) grammars for ASN.1 or whatever. > I think clear English prose is *essential*, the one thing a specification > must have. Thus, schemas can be actively harmful if arguing over them > distracts attention from crafting the prose properly. This is particularly > the case when the schema language is a flawed tool, which so many of them > are. English prose cannot be avoided. For me it's about finding the sweet-spot between formal language and English prose. We could publish code (remember SDL?) as a specification, but no one seriously proposes _that_ (certainly not I). > I also think that for most protocols, an open-source validator is immensely > more useful than a schema. Validators can check semantic constraints that > are in principle inaccessible to schema languages, especially simple ones. What do you want to validate? Form? Then use schema; a form validator not based on schema... is still a schema of sorts. Or do you want to validate semantics? That requires test-suites. Perhaps we should publish test-suites, yes -- not a bad idea, except for the enormous impact I think that would have on RFC authoring costs and publication timelines. Nico -- From nobody Wed Feb 19 09:49:30 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3591A04FF for ; Wed, 19 Feb 2014 09:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 umEe-NgOoyZY for ; Wed, 19 Feb 2014 09:49:24 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 222D71A03CE for ; Wed, 19 Feb 2014 09:49:23 -0800 (PST) Received: (qmail 22681 invoked from network); 19 Feb 2014 17:48:39 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 19 Feb 2014 17:48:37 +0000 Message-ID: <5E152E5A0BE944F09ED6F96884E3D7F9@codalogic> From: "Pete Cordell" To: "Tim Bray" , "Nico Williams" References: X-Unsent: 1 X-Vipre-Scanned: 01B182F100680C01B1843E Date: Wed, 19 Feb 2014 17:49:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/u4P0TL9ixtJHAxyMRYMYW6oovPg Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 17:49:27 -0000 If the IETF does choose to promote JSON schemas I recommend that such languages be designed with the knowledge that their principle use is likely to be in RFCs (or similar) documents. Hence they need to be able to be interleaved in with narrative text without limiting the structure of the text. This can be achieved in ways similar to how PHP is included in HTML. For example you could do something like: ------------Example start-------------------- 2.3.2 Connection Address Type The ConnectionAddressType represents an IP address and port part that can be used to create an IP connection. - address specifies the IP4 address of the connection. - port specifies the 16-bit port of the connection - protocol specifies whether the connection should be made over UDP or TCP. ------------Example end--------------------- This fixes the problem of having narrative and protocol description separated by a long way. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Tim Bray" To: "Nico Williams" Cc: "Phillip Hallam-Baker" ; "Paul Hoffman" ; "JSON WG" Sent: Wednesday, February 19, 2014 5:30 PM Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward > On Wed, Feb 19, 2014 at 9:20 AM, Nico Williams > wrote: > > My proposal is that the WG take all comers for JSON schema languages >> as Informational and leave it at that (well, all proposals for which >> there's enough authors and reviewers, enough interest). That can't >> even be an irritant for you: you can ignore them... >> > > No harm in that, although I also perceive little benefit. > > >> ...unless you think that formal languages used by others will impair >> your ability to understand their specs, unless you really prefer >> English prose to the max. That'd be an argument I'd want to hear, if >> you were making it. > > > I think schemas can be useful (but designing good schema languages is > horribly hard, and so easy to get wrong). > > I think clear English prose is *essential*, the one thing a specification > must have. Thus, schemas can be actively harmful if arguing over them > distracts attention from crafting the prose properly. This is > particularly > the case when the schema language is a flawed tool, which so many of them > are. > > I also think that for most protocols, an open-source validator is > immensely > more useful than a schema. Validators can check semantic constraints that > are in principle inaccessible to schema languages, especially simple ones. > -------------------------------------------------------------------------------- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Feb 19 10:04:15 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2AA1A01FB for ; Wed, 19 Feb 2014 10:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 iAI7hR57lpDO for ; Wed, 19 Feb 2014 10:04:12 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 4E34F1A04B8 for ; Wed, 19 Feb 2014 10:04:12 -0800 (PST) Received: (qmail 25666 invoked from network); 19 Feb 2014 18:03:27 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 19 Feb 2014 18:03:26 +0000 Message-ID: <0581F38DEFEA4660B6A071986B0B235B@codalogic> From: "Pete Cordell" To: "Nico Williams" , "Tim Bray" References: X-Unsent: 1 X-Vipre-Scanned: 01BEFCE400680C01BEFE31 Date: Wed, 19 Feb 2014 18:04:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/zRLfP7pyVy4GND2KDnHcTB_zrYU Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 18:04:14 -0000 ----- Original Message From: "Nico Williams" > I really want any JSON schema to be expressed in JSON itself: we all > have JSON parsers, so at least the first step is done and we won't > have to worry about how difficult it is to write LALR(1) grammars for > ASN.1 or whatever. Personally I think it's more important that the schemas are easier to read and write by a human. Compare: int<0..65535>? port; to: [ { "name": "port", "type": "int", "minOccurs": 0, "maxOccurs": 1, "minInclusive": 0, "maxInclusive": 65535 } ] Comments are also nice in schema! An important consideration in designing a schema like the above is to have some kind of 'escape' mechanism for extending the definition such as attributes and annotations in C# and Java. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Wed Feb 19 10:10:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4681A00B8 for ; Wed, 19 Feb 2014 10:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 xuEX6Kl1DXJR for ; Wed, 19 Feb 2014 10:10:36 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 20C3E1A04B8 for ; Wed, 19 Feb 2014 10:10:36 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so754279vcb.25 for ; Wed, 19 Feb 2014 10:10:32 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=nlC1HgHAbcMOR6ZYd12Iy+BFdDU0w79mUZvQbHnqAek=; b=XTlaLvrmG9TYUNPdQ3Yu679LuL/DJyaZngPWubb5It9LQj6AKrJC0Il5wX0fKZ5t69 N+j3OvJ4Capl0LRiQWSk+GNi7GTONdZnOizRYG8covtzpdLzHZDNiSl3qPU6Umhd40Ow qEcThQeVdrl2ziRMCW20DOrzgsOsto0K59m9HWO+5Hl8oIFQvSliuMpfhW7c+3pv7wVd MKGBsZYBZq1VLCe3tuvqK7JxNhEtAozzjr//RzkkFrLhdkPPtyDdYELpT5YDs+Hwi71G /IwUGLh98wk80WeUppS09pyeltPJieQ3rn5DTvjgLj0DWwpmVP9lkLjYqhCVw6uaGB0h EHAg== X-Gm-Message-State: ALoCoQkHNnsc6W7vfMqtUkk/kY749pcxIokOcCBcO4o74uDw65yK6g7Vy+I330M3XqfIv838TvN0 MIME-Version: 1.0 X-Received: by 10.221.55.133 with SMTP id vy5mr26262167vcb.17.1392833432625; Wed, 19 Feb 2014 10:10:32 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 19 Feb 2014 10:10:32 -0800 (PST) X-Originating-IP: [172.19.244.31] In-Reply-To: References: Date: Wed, 19 Feb 2014 10:10:32 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=001a113376fefbb90604f2c64d92 Archived-At: http://mailarchive.ietf.org/arch/msg/json/e-BLhG3SB-aJENGAK1Db8WNoFNc Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 18:10:38 -0000 --001a113376fefbb90604f2c64d92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 19, 2014 at 9:40 AM, Nico Williams wrote= : > I really want any JSON schema to be expressed in JSON itself Reasonable sounding, but the resounding success of RelaxNG=E2=80=99s non-XM= L syntax (which surprised me, for one) makes this sort of idea less self-evidently true. --001a113376fefbb90604f2c64d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 19, 2014 at 9:40 AM, Nico Williams <nico@cryptonector.com&= gt; wrote:
=C2=A0
I really want any JSON schema to be expressed in JSON itself

Reasonable sounding, but the resounding success of RelaxN= G=E2=80=99s non-XML syntax (which surprised me, for one) makes this sort of= idea less self-evidently true.


--001a113376fefbb90604f2c64d92-- From nobody Wed Feb 19 10:23:48 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B131A0510 for ; Wed, 19 Feb 2014 10:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 7Z_j3NucUC2a for ; Wed, 19 Feb 2014 10:23:45 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id C23411A050D for ; Wed, 19 Feb 2014 10:23:44 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 0E4969409D for ; Wed, 19 Feb 2014 10:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=2jydkh/5uyI99n+ShgQ/I7g8/G4=; b=NuyQXUnDt/Y oIWpRgmWXgwaveQehSr/XTueXrfwEOLGKYMz5iTonMXROZAPu8OJUH4ON7IY/S+Q Jomn9SRik1s7VqUkOj5apzIIRsKWgn3+IbjhMBwbzDCENaXeBvHBiZ1wDLR5cQm4 Zm9DQ9g87cJwDY6Rt9cUMjnzIXba46e8= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 4315B94085 for ; Wed, 19 Feb 2014 10:22:14 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so4340054wgh.1 for ; Wed, 19 Feb 2014 10:22:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5A3O1mQ4ZkU9oaklszoaorhnurLcxtAvARI/03uUb/0=; b=ShSl6LnD5ByrzCNzlcMB/FzfzxfzP1AkC2oeeIedP10b1/tuCaLfF0aCj0BTZcLAza uOVMh9xF9SfEkqPTJ6fz6NbzSnx2qFAaSm03ttflb+cZJgqDavxu8iGCIY4l7kfsI8Px FBXVBP+oYydvUQUQwTZCRAIhDTlxQTqm+0fEnWMsegl97Wtr7faAWGXx4j9YVzH3EY8V ktunZg+T7oRF7FHrYN304U1tlaNTvEF8BlMH0jn7xOdySuO0RB9JotVrIVbnqDN3wywK e9DT16qaX74GlChWlPnsgrCksy1AeP5A3O1zIBpt0ucpl1+ysGeW5Uxt67Sp9K+mktbm z39A== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr2882047wiw.39.1392834125028; Wed, 19 Feb 2014 10:22:05 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 10:22:04 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 12:22:04 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/4z1l091e8yHLssACQtx_nyRoRVs Cc: Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 18:23:46 -0000 On Wed, Feb 19, 2014 at 12:10 PM, Tim Bray wrote: > On Wed, Feb 19, 2014 at 9:40 AM, Nico Williams > wrote: >> I really want any JSON schema to be expressed in JSON itself > > Reasonable sounding, but the resounding success of RelaxNG=E2=80=99s non-= XML syntax > (which surprised me, for one) makes this sort of idea less self-evidently > true. It's compact form, but yes, yours and Pete Cordell's are great points. Fair enough. I'd be fine with any syntax that maps onto JSON (like RNG compact onto XML) and is easy to write LALR(1) grammars for. Nico -- From nobody Wed Feb 19 10:43:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8C1A0238 for ; Wed, 19 Feb 2014 10:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 keQRxX8xiiRM for ; Wed, 19 Feb 2014 10:43:38 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 31C421A00FB for ; Wed, 19 Feb 2014 10:43:37 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id p9so587413lbv.6 for ; Wed, 19 Feb 2014 10:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qZnl2hSl3BSS3MYBHW2niZi71qdmJGr1iW6ZMjyAD5I=; b=l84m5DPX3LjFSfPgfIGU8L6wiezTUaSSPka+hZbaPYB8kHi2z6ugdV9jErkMm3001E rqWMRU7t4yhr/HKvbpJol0f3yXAQZ0kpK5pMsrSuyArUnJyn7odEAEqkR39VLqwPokgq BxRK8NaW4uDJwopYPeaRwLLfzb5hsTFZiuTiq+gSrOlmePzFzdolhnGENidnMI8O2zO0 tc8BbR4ni3DfTsLTP4s0hZ7CswoS2GdAZMqBejrdCDr+tqDJ0FQcbrHao+TFnRA741P0 Mafp0nW32JHOUUKyskDDaeUb/JlCEWjGHoILGhKckjDijFQnrJ22pbkc2ic2v1N1o6Fq YG5Q== MIME-Version: 1.0 X-Received: by 10.112.72.40 with SMTP id a8mr1870084lbv.68.1392835414080; Wed, 19 Feb 2014 10:43:34 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 10:43:33 -0800 (PST) In-Reply-To: <20140219172511.GA8132@mercury.ccil.org> References: <20140219172511.GA8132@mercury.ccil.org> Date: Wed, 19 Feb 2014 13:43:33 -0500 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a11c23e2e16433604f2c6c421 Archived-At: http://mailarchive.ietf.org/arch/msg/json/hsJxX1F3DhV870GSfvicpIlYLxs Cc: Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 18:43:41 -0000 --001a11c23e2e16433604f2c6c421 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 12:25 PM, John Cowan wrote: > Tim Bray scripsit: > > > > The point is to focus the discussion on the data going over the wire > > > rather than the syntax. > > > > Here is where we disagree absolutely. The point is to specify the syntax > > clearly and unambiguously, and the semantics of its payload. Trying to > > come at it from the other direction (specifying data structures and then > > extracting syntax) leads to huge mistakes like CORBA and WS-*. > They are only mistakes because they are huge. Microsoft and IBM wanted to build a consulting business which meant that they liked a specification that was overly complex. The whole ProtoGen system is less than about 5,000 lines of code and it has equivalent functionality to the WS-* stack. XML isn't the farce that SGML was and JSON is even simpler than XML without loss of power (though it does not make a very good document markup). C# and Java are not the screwups that C++ was either. And C is not ADA. The fact that the B-crew has botched a job in the past does not mean the approach is wrong. The collapse of ADA did not prove that high level languages were a bad idea. Though there were folk on USENet making that argument at the time. My college tutor was known for having walked out of the ADA design meetings but he still worked on many other programming languages afterwards. > I agree absolutely with Tim, if it wasn't clear before. Semantics is vague > and fuzzy (my semantics of your JSON may consist solely in counting the > number of fields in the top-level object, for example). Syntax is not. > Agreement on syntax promotes interoperation; agreement on semantics > takes forever, pushing syntax to the rear, thus tending to create bad > syntax. > JSON has no semantics, All the JSON syntax has is a mapping to an implicit data model. Semantics can be defined very precisely and most modern computer science courses teach methods of doing that Z, VDM and the rest are all very precise ways of specifying the behavior of a protocol with as high a degree of precision as LR(0) parsers allow for syntax. What I have found is that making use of syntax to encode semantics is always a mistake. For example we might have a specification that says that a Date field can either be an RFC3337 DateTime or an integer giving the offset in seconds from the current time. That is certainly possible but we now require the parser to be able to recognize the format of the data and select the representation appropriately. Maybe 95% of people will do that right but at least 5% will do it wrong and if one of those implementations becomes popular we end up with a specification that now has three different cases to code, the two in the spec and the real life situation that isn't documented. Using different tags for "DateTime" (=String) and "DeltaTime" (=Integer) avoids that whole business. When people reach for Regular Expressions they are almost always doing something that is better done without. -- Website: http://hallambaker.com/ --001a11c23e2e16433604f2c6c421 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 19, 2014 at 12:25 PM, John Cowan <= cowan@mercury.c= cil.org> wrote:
Tim Bray scripsit:

> > The point is to focus the discussion on the data going over the w= ire
> > rather than the syntax.
>
> Here is where we disagree absolutely. The point is to specify the synt= ax
> clearly and unambiguously, and the semantics of its payload. =A0Trying= to
> come at it from the other direction (specifying data structures and th= en
> extracting syntax) leads to huge mistakes like CORBA and WS-*.

They are only mistakes because they are = huge. Microsoft and IBM wanted to build a consulting business which meant t= hat they liked a specification that was overly complex.

The whole ProtoGen system is less than about 5,000 line= s of code and it has equivalent functionality to the WS-* stack.=A0

XML isn't the farce that SGML was and JSON is even si= mpler than XML without loss of power (though it does not make a very good d= ocument markup).

C# and Java are not the screwups that C++ was either. A= nd C is not ADA.

The fact that the B-crew has botc= hed a job in the past does not mean the approach is wrong. The collapse of = ADA did not prove that high level languages were a bad idea. Though there w= ere folk on USENet making that argument at the time. My college tutor was k= nown for having walked out of the ADA design meetings but he still worked o= n many other programming languages afterwards.

=A0
I agree absolutely with Tim, if it wasn't clear before. =A0Semant= ics is vague
and fuzzy (my semantics of your JSON may consist solely in counting the
number of fields in the top-level object, for example). =A0Syntax is not. Agreement on syntax promotes interoperation; agreement on semantics
takes forever, pushing syntax to the rear, thus tending to create bad synta= x.

JSON has no semantics, All the JSON = syntax has is a mapping to an implicit data model.

Semantics can be defined very precisely and most modern computer scien= ce courses teach methods of doing that Z, VDM and the rest are all very pre= cise ways of specifying the behavior of a protocol with as high a degree of= precision as LR(0) parsers allow for syntax.


What I have found is that making use of = syntax to encode semantics is always a mistake. For example we might have a= specification that says that a Date field can either be an RFC3337 DateTim= e or an integer giving the offset in seconds from the current time. That is= certainly possible but we now require the parser to be able to recognize t= he format of the data and select the representation appropriately. Maybe 95= % of people will do that right but at least 5% will do it wrong and if one = of those implementations becomes popular we end up with a specification tha= t now has three different cases to code, the two in the spec and the real l= ife situation that isn't documented.

Using different tags for "DateTime" (=3DStrin= g) and "DeltaTime" (=3DInteger) avoids that whole business.
=


When people reach for Regular Expression= s they are almost always doing something that is better done without.
=A0

--
Website: http://hallambaker.com/
--001a11c23e2e16433604f2c6c421-- From nobody Wed Feb 19 10:48:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200641A0505 for ; Wed, 19 Feb 2014 10:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aRkBKDTcoFp9 for ; Wed, 19 Feb 2014 10:48:01 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 476DC1A015E for ; Wed, 19 Feb 2014 10:48:01 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id x48so662576wes.18 for ; Wed, 19 Feb 2014 10:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mMzjtcqPxaED6xlWV5pm5hLEY6sDZnt7Qrpbp0QjHVg=; b=ZxC/VzNvzC9WUJtpfCdYbx6p64mmTY4C84FJq7VvEc84wUKhpn7pPmLHgeaH5BMMhY eh3FRyw6aQUSTcX14DN/Bf+Bhz/ReyThkSks5jbz7NHX/Iwpb5UjliMYkbuoXrR9sMvF q9rsZ6ckFcQzf9bFoIZjiKKusYtbdNCiBSBidIm07X7+iZel3c0mGUcbL6ExwHuhyvql V4XdW+mgvpqma5MyFzE+IdQ6Yc7966kDl3T3gbGYnuidTSDwadXgfh6+X+xO7Y4pPDZZ dPch7gRqDXm0jnIuJ2Ub1Kgz+JjZ5N632KN8aYXtMeAEfBpsrN8OMwV/BmHuXQSGQy3v L4RQ== MIME-Version: 1.0 X-Received: by 10.194.90.144 with SMTP id bw16mr29463930wjb.1.1392835677450; Wed, 19 Feb 2014 10:47:57 -0800 (PST) Received: by 10.227.77.3 with HTTP; Wed, 19 Feb 2014 10:47:57 -0800 (PST) In-Reply-To: References: <20140219172511.GA8132@mercury.ccil.org> Date: Wed, 19 Feb 2014 10:47:57 -0800 Message-ID: From: Tatu Saloranta To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7bfcf35cc8f67004f2c6d3b6 Archived-At: http://mailarchive.ietf.org/arch/msg/json/GVlWl4-cVgBQDq5YJEBQbQcHwmk Cc: Tim Bray , John Cowan , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 18:48:04 -0000 --047d7bfcf35cc8f67004f2c6d3b6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 10:43 AM, Phillip Hallam-Baker wrote: > > > On Wed, Feb 19, 2014 at 12:25 PM, John Cowan wrote: > >> Tim Bray scripsit: >> >> > > The point is to focus the discussion on the data going over the wire >> > > rather than the syntax. >> > >> > Here is where we disagree absolutely. The point is to specify the syntax >> > clearly and unambiguously, and the semantics of its payload. Trying to >> > come at it from the other direction (specifying data structures and then >> > extracting syntax) leads to huge mistakes like CORBA and WS-*. >> > > They are only mistakes because they are huge. Microsoft and IBM wanted to > build a consulting business which meant that they liked a specification > that was overly complex. > > The whole ProtoGen system is less than about 5,000 lines of code and it > has equivalent functionality to the WS-* stack. > > XML isn't the farce that SGML was and JSON is even simpler than XML > without loss of power (though it does not make a very good document markup). > > C# and Java are not the screwups that C++ was either. And C is not ADA. > > The fact that the B-crew has botched a job in the past does not mean the > approach is wrong. The collapse of ADA did not prove that high level > languages were a bad idea. Though there were folk on USENet making that > argument at the time. My college tutor was known for having walked out of > the ADA design meetings but he still worked on many other programming > languages afterwards. > > > >> I agree absolutely with Tim, if it wasn't clear before. Semantics is >> vague >> and fuzzy (my semantics of your JSON may consist solely in counting the >> number of fields in the top-level object, for example). Syntax is not. >> Agreement on syntax promotes interoperation; agreement on semantics >> takes forever, pushing syntax to the rear, thus tending to create bad >> syntax. >> > > JSON has no semantics, All the JSON syntax has is a mapping to an implicit > data model. > > Semantics can be defined very precisely and most modern computer science > courses teach methods of doing that Z, VDM and the rest are all very > precise ways of specifying the behavior of a protocol with as high a degree > of precision as LR(0) parsers allow for syntax. > > > What I have found is that making use of syntax to encode semantics is > always a mistake. For example we might have a specification that says that > a Date field can either be an RFC3337 DateTime or an integer giving the > offset in seconds from the current time. That is certainly possible but we > now require the parser to be able to recognize the format of the data and > select the representation appropriately. Maybe 95% of people will do that > right but at least 5% will do it wrong and if one of those implementations > becomes popular we end up with a specification that now has three different > cases to code, the two in the spec and the real life situation that isn't > documented. > > Using different tags for "DateTime" (=String) and "DeltaTime" (=Integer) > avoids that whole business. > > > When people reach for Regular Expressions they are almost always doing > something that is better done without. > > I agree completely with above. -+ Tatu +- --047d7bfcf35cc8f67004f2c6d3b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 19, 2014 at 10:43 AM, Phillip Hallam-Baker <ha= llam@gmail.com> wrote:


On Wed, Feb 19, 2014 at = 12:25 PM, John Cowan <cowan@mercury.ccil.org> wrote:
Tim Bray scripsit:

> > The point is to focus the discussion on the data going over the w= ire
> > rather than the syntax.
>
> Here is where we disagree absolutely. The point is to specify the synt= ax
> clearly and unambiguously, and the semantics of its payload. =A0Trying= to
> come at it from the other direction (specifying data structures and th= en
> extracting syntax) leads to huge mistakes like CORBA and WS-*.

They are only mistakes because the= y are huge. Microsoft and IBM wanted to build a consulting business which m= eant that they liked a specification that was overly complex.

The whole ProtoGen system is less than about 5,000 line= s of code and it has equivalent functionality to the WS-* stack.=A0

XML isn't the farce that SGML was and JSON is even si= mpler than XML without loss of power (though it does not make a very good d= ocument markup).

C# and Java are not the screwups that C++ was either. A= nd C is not ADA.

The fact that the B-crew has botc= hed a job in the past does not mean the approach is wrong. The collapse of = ADA did not prove that high level languages were a bad idea. Though there w= ere folk on USENet making that argument at the time. My college tutor was k= nown for having walked out of the ADA design meetings but he still worked o= n many other programming languages afterwards.

=A0
I agree absolutely with Tim, if it wasn't clear before. =A0Semant= ics is vague
and fuzzy (my semantics of your JSON may consist solely in counting the
number of fields in the top-level object, for example). =A0Syntax is not. Agreement on syntax promotes interoperation; agreement on semantics
takes forever, pushing syntax to the rear, thus tending to create bad synta= x.

JSON has no semantics, All the= JSON syntax has is a mapping to an implicit data model.

Semantics can be defined very precisely and most modern computer scien= ce courses teach methods of doing that Z, VDM and the rest are all very pre= cise ways of specifying the behavior of a protocol with as high a degree of= precision as LR(0) parsers allow for syntax.


What I have found is that making use of = syntax to encode semantics is always a mistake. For example we might have a= specification that says that a Date field can either be an RFC3337 DateTim= e or an integer giving the offset in seconds from the current time. That is= certainly possible but we now require the parser to be able to recognize t= he format of the data and select the representation appropriately. Maybe 95= % of people will do that right but at least 5% will do it wrong and if one = of those implementations becomes popular we end up with a specification tha= t now has three different cases to code, the two in the spec and the real l= ife situation that isn't documented.

Using different tags for "DateTime" (=3DStrin= g) and "DeltaTime" (=3DInteger) avoids that whole business.
=


When people reach for Regular Expression= s they are almost always doing something that is better done without.
=A0

<= div>I agree completely with above.

-+ Tatu +-

--047d7bfcf35cc8f67004f2c6d3b6-- From nobody Wed Feb 19 12:02:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C46E1A05CC for ; Wed, 19 Feb 2014 12:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 tvjI6AtTPc6g for ; Wed, 19 Feb 2014 12:02:49 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 689D41A04F7 for ; Wed, 19 Feb 2014 12:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1JK2i1h028985 for ; Wed, 19 Feb 2014 21:02:44 +0100 (CET) Received: from [192.168.217.106] (p5489165F.dip0.t-ipconnect.de [84.137.22.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DF2E1E12; Wed, 19 Feb 2014 21:02:43 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Feb 2014 21:02:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: JSON WG X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/json/fYV_23SCbvO6pSwRXNzq1SaQ870 Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 20:02:51 -0000 At the danger of repeating myself and others here, I=92ll try to = summarize: =97 We have quite good experience with using a single, standard (!) ABNF = in IETF protocols. ABNF is a production system with well-understood semantics. It is somewhat idiosyncratic in the world of EBNF, but that has caused = *zero* problems in practice. (People have just written ABNF parsers. You still have the second = half of the afternoon to do something else after that.) =97 A production system that generates JSON (at the data model level) is = easy to do. (But we have to find people who have the background and can commit the = time.) =20 =97 Relax NG compact is a nice existence proof that a production system = like this can work and be highly usable. A JSON version could be even simpler. =97 Previous attempts at trying to express XML or JSON data model syntax = in the formalism of XML or JSON itself provide incontrovertible proof = that this approach does not work. Don=92t do that then. (It is so much easier to spend half the afternoon writing the parser = for the workable syntax. We can even spec it in ABNF!) =97 If you want to cover 100 % of the =93syntax=94 of an XML document, = you need to add Schematron to Relax NG compact. a) Don=92t do that then for JSON =97 stay with an 80 % solution like = Relax NG (which is more like 90 %) or maybe even simpler. b) Choose some form of =93Jpath=94 to complement the production system = with assertions. (Note that choice b can always be added later, on a separate timeline = from doing a production system.) My proposals following from this little exercise in fact finding: =97 I would propose that we try to find energy for doing the production = system. (In addition to the Web people, we may want to tap the YANG people for = some recent experience in doing this kind of work.) =97 I would propose that we stay open to adding a Jpath/Schematron = approach (choice =93b=94), *if* somebody brings a credible one to the = table. =97 I also would propose that we collect a small number of benchmarks = that we use for demonstrating that proposals for the production system = are useful. My first suggestion: RFC 7071. But we need a couple of different = ones. RFC 7095? Maybe too ambitious. Gr=FC=DFe, Carsten From nobody Wed Feb 19 12:06:21 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607281A04F4 for ; Wed, 19 Feb 2014 12:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 VSEGS6cMND77 for ; Wed, 19 Feb 2014 12:06:17 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69A1A04F7 for ; Wed, 19 Feb 2014 12:06:16 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WGDPG-0002Vs-2l; Wed, 19 Feb 2014 15:06:10 -0500 Date: Wed, 19 Feb 2014 15:06:10 -0500 From: John Cowan To: Nico Williams Message-ID: <20140219200609.GB8132@mercury.ccil.org> References: <20140219163059.GA18485@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/7ylH64PTLRycDQPWTN5GfM4V1VE Cc: Phillip Hallam-Baker , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 20:06:19 -0000 Nico Williams scripsit: > I get that some don't want any JSON schemas, to which my answer is: so > don't use them. But please refrain from fallacious arguments. We tried not using XSD schemas. Didn't work. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I am surrounded by dwarves. --Murray Gell-Mann From nobody Wed Feb 19 12:47:20 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F8E1A04C1 for ; Wed, 19 Feb 2014 12:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 o0o7g-p9zlah for ; Wed, 19 Feb 2014 12:47:15 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 796871A01DB for ; Wed, 19 Feb 2014 12:47:15 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WGE2u-0006ad-JF; Wed, 19 Feb 2014 15:47:08 -0500 Date: Wed, 19 Feb 2014 15:47:08 -0500 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20140219204708.GF8132@mercury.ccil.org> References: <20140219172511.GA8132@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/wcFVWWTppv0h5XAFEdgvxUVEHcE Cc: Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 20:47:18 -0000 Phillip Hallam-Baker scripsit: > Semantics can be defined very precisely and most modern computer > science courses teach methods of doing that Z, VDM and the rest are > all very precise ways of specifying the behavior of a protocol with as > high a degree of precision as LR(0) parsers allow for syntax. That's behavioral semantics (what to do), not document semantics (what is meant). It is impossible to define document semantics without reference to the recipient: indeed, as a member of the pragmaticist tradition I define the semantics of a document as its effect on the recipient. A book written in Georgian has no semantics to me, for I cannot understand a single word of it. > What I have found is that making use of syntax to encode semantics is > always a mistake. See, if I didn't know that you were talking about behavioral semantics, that would be incomprehensible. This very email uses syntax (English syntax) to encode the semantics of what I am (I hope) communicating to you. Indeed, there is no other way for me to communicate it. > Using different tags for "DateTime" (=String) and "DeltaTime" > (=Integer) avoids that whole business. That is, of course, a syntactic distinction. > When people reach for Regular Expressions they are almost always doing > something that is better done without. "I have a problem. I know! I'll use a computer. Now I have 100,000 problems." --me -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Historians aren't constantly confronted with people who carry on self-confidently about the rule against adultery in the sixth amendment to the Declamation of Independence, as written by Benjamin Hamilton. Computer scientists aren't always having to correct people who make bold assertions about the value of Objectivist Programming, as examplified in the HCNL entities stored in Relaxational Databases. --Mark Liberman From nobody Wed Feb 19 14:04:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E611A0272 for ; Wed, 19 Feb 2014 14:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 BwzK9qYMrdss for ; Wed, 19 Feb 2014 14:04:39 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A743B1A02B9 for ; Wed, 19 Feb 2014 14:04:38 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so1088642vcb.33 for ; Wed, 19 Feb 2014 14:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=1kajKPjRj2jVAL0czkFxXYTyddza84ev6pDj1p0oQo8=; b=KwDapa9uJP30s4KnUF47KMXqXVnjR2G9UuJ054pMDu/8Hg1Es+ERLZHO16AcrR788n 7NNsqcC5V8bTMHTlTWXylxYdYOOTDsY8eOrm3v8FlYxbYPgyWd2xPHfD6Tw+B4JSStPj XNWn8tevQXEu0VEo0GSUj0O18KdvQq1jScHFl57WyTRk4c84j49bK9dPZh8E5qcsCat5 Efq/ikINqDwYb1HmoKspGxv4U9m4O3bkcU3Vx/G+Y/19w5cHEUekUWKiE+Ex6wru6O+x PQchikkDSQNqBpllYNzut0dB2EDAOWH0hY3gbUejpNhguRxyzm5IPxadxtrVgtkMdCg8 fPxQ== MIME-Version: 1.0 X-Received: by 10.221.2.138 with SMTP id nu10mr2004963vcb.52.1392847475160; Wed, 19 Feb 2014 14:04:35 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.19.104 with HTTP; Wed, 19 Feb 2014 14:04:35 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 17:04:35 -0500 X-Google-Sender-Auth: 5M9tMmdKS0qSECJ40QIatYZuncg Message-ID: From: Barry Leiba To: JSON WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/M3qcFVwm4uqWQMVW3ewaiiX8U4I Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:04:43 -0000 Using Carsten's "summary" note as an anchor, let me back up to where this proposal came from. I'm interested in providing a recommended way (through a non-binding, Informational document that describes it) in which protocol elements that are JSON things can be described in documents. I'm hoping we can keep this work item to that limited scope, and not go too far in trying to devise something mega-general that does everything but eat.[1] That means that I'm looking for something that addresses the 90% case nicely and cleanly. The 10% of the messier cases should be workable, but can be messier, I think. As an example of what made me think about this, look at these: 1. Section 6.1.1 of http://tools.ietf.org/html/draft-ietf-repute-media-type= -12 2. Section 6.2.2 of http://tools.ietf.org/html/draft-ietf-repute-media-type= -13 Note that the attempt to reproduce the JSON ABNF, in version -12, had a number of problems. I think the mechanism in version -13 is much cleaner... and it's simple and easy to explain. Nested and complex structures can be handled as they are in ABNF, by naming the nested or complex bit and then expanding it in another "rule". I think this sort of mechanism meets the "addresses the 90% case nicely" desire. I like it because it's easy to write and, more importantly, easy to read and understand. We could possibly come up with something more general; we could consider Andy Newton's draft, or variations of that (as Andy suggested, perhaps with changes to make it more readable). But I'd really like us to avoid getting so general that we end up with something that's precise and covers everything... but is difficult to get right and hard to read. Barry [1] Points to you if you know the reference: http://mindprod.com/jgloss/debe.html On Wed, Feb 19, 2014 at 3:02 PM, Carsten Bormann wrote: > At the danger of repeating myself and others here, I'll try to summarize: > > -- We have quite good experience with using a single, standard (!) ABNF i= n IETF protocols. > ABNF is a production system with well-understood semantics. > It is somewhat idiosyncratic in the world of EBNF, but that has caused = *zero* problems in practice. > (People have just written ABNF parsers. You still have the second half= of the afternoon to do something else after that.) > > -- A production system that generates JSON (at the data model level) is e= asy to do. > (But we have to find people who have the background and can commit the = time.) > > -- Relax NG compact is a nice existence proof that a production system li= ke this can work and be highly usable. > A JSON version could be even simpler. > > -- Previous attempts at trying to express XML or JSON data model syntax i= n the formalism of XML or JSON itself provide incontrovertible proof that t= his approach does not work. > Don't do that then. > (It is so much easier to spend half the afternoon writing the parser fo= r the workable syntax. > We can even spec it in ABNF!) > > -- If you want to cover 100 % of the "syntax" of an XML document, you nee= d to add Schematron to Relax NG compact. > a) Don't do that then for JSON -- stay with an 80 % solution like Relax= NG (which is more like 90 %) or maybe even simpler. > b) Choose some form of "Jpath" to complement the production system with= assertions. > > (Note that choice b can always be added later, on a separate timeline fro= m doing a production system.) > > My proposals following from this little exercise in fact finding: > > -- I would propose that we try to find energy for doing the production sy= stem. > (In addition to the Web people, we may want to tap the YANG people for so= me recent experience in doing this kind of work.) > > -- I would propose that we stay open to adding a Jpath/Schematron approac= h (choice "b"), *if* somebody brings a credible one to the table. > > -- I also would propose that we collect a small number of benchmarks that= we use for demonstrating that proposals for the production system are usef= ul. > My first suggestion: RFC 7071. But we need a couple of different ones.= RFC 7095? Maybe too ambitious. > > Gr=FC=DFe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Wed Feb 19 14:12:24 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5522B1A050D for ; Wed, 19 Feb 2014 14:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YgBVthbAQAi8 for ; Wed, 19 Feb 2014 14:12:19 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EF7181A0226 for ; Wed, 19 Feb 2014 14:12:18 -0800 (PST) Received: from [10.204.61.243] (unknown [110.145.144.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6FF8622E1F4; Wed, 19 Feb 2014 17:12:08 -0500 (EST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-D4BF696C-42C0-4211-89AF-1702373DE6D8 Content-Transfer-Encoding: 7bit Message-Id: <6A1B3E19-9A19-4B20-9E00-125522476711@mnot.net> X-Mailer: iPhone Mail (11B554a) From: Mark Nottingham Date: Thu, 20 Feb 2014 09:12:00 +1100 To: Tim Bray Archived-At: http://mailarchive.ietf.org/arch/msg/json/Ido9J67w5nTkFPUa8swjaDTx9mQ Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:12:22 -0000 --Apple-Mail-D4BF696C-42C0-4211-89AF-1702373DE6D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Agreed.=20 Sent from my iPhone > On 20 Feb 2014, at 2:49 am, Tim Bray wrote: >=20 > For the record, I think the draft language is clear and correct and we sho= uld move forward with it. >=20 >=20 >> On Wed, Feb 19, 2014 at 7:31 AM, Paul Hoffman wro= te: >> [[ Phill is the only one who has responded with a proposal to speak. Hear= ing whether others want to would be useful. --Paul Hoffman ]] >>=20 >> It's been a week, and yet I can't imagine that everything has been said w= ith respect to our proposed charter item that now stands at: >>=20 >> A set of natural-language terms and/or phrases for use in future specif= ications >> that use JSON. This explicitly excludes schema languages and similar fo= rmalisms. >>=20 >> After that, a bunch of people started talking about formalisms and actual= schemas again. In order to get this decided, we need more discussion and th= en agreement. To that end, and to put our 90 minutes on Friday afternoon in L= ondon to best use, I will ask for at least three people to present their vie= ws in 10-minute presentations at the meeting. However, in order to cause thi= s to not be the normal IETF "let's wait for the meeting" game, the presentat= ions need to be done by next Monday, Feb. 24. That gives people on the list a= preview of what will be said, time to argue about it, and time for the pres= enters to hone their slides if they want. >>=20 >> Let me know online or offline if you want to do a presentation. If you're= not going to be at the meeting but want to say something, you need to find s= ome like-minded soul with whom to work on the presentation. >>=20 >> --Paul Hoffman >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >>=20 >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --Apple-Mail-D4BF696C-42C0-4211-89AF-1702373DE6D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Agreed. 

Sent from my iPhone

On 20 Feb 2014, at 2:49 am, Tim Bray <tbray@textuality.com> wrote:

For the record, I think the draft language is clear and correct and we should move forward with it.


On Wed, Feb 19, 2014 at 7:31 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
[[ Phill is the only one who has responded with a proposal to speak. Hearing whether others want to would be useful. --Paul Hoffman ]]

It's been a week, and yet I can't imagine that everything has been said with respect to our proposed charter item that now stands at:

  A set of natural-language terms and/or phrases for use in future specifications
  that use JSON. This explicitly excludes schema languages and similar formalisms.

After that, a bunch of people started talking about formalisms and actual schemas again. In order to get this decided, we need more discussion and then agreement. To that end, and to put our 90 minutes on Friday afternoon in London to best use, I will ask for at least three people to present their views in 10-minute presentations at the meeting. However, in order to cause this to not be the normal IETF "let's wait for the meeting" game, the presentations need to be done by next Monday, Feb. 24. That gives people on the list a preview of what will be said, time to argue about it, and time for the presenters to hone their slides if they want.

Let me know online or offline if you want to do a presentation. If you're not going to be at the meeting but want to say something, you need to find some like-minded soul with whom to work on the presentation.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--Apple-Mail-D4BF696C-42C0-4211-89AF-1702373DE6D8-- From nobody Wed Feb 19 14:23:53 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337AC1A0405 for ; Wed, 19 Feb 2014 14:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 mK0pp8NncUxx for ; Wed, 19 Feb 2014 14:23:48 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83F1A0226 for ; Wed, 19 Feb 2014 14:23:47 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id y1so754323lam.22 for ; Wed, 19 Feb 2014 14:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RMOKI0uIn/d2bZBJdRAH9o/LJN9XzQn/lvoYftaUyBo=; b=zNoDX/DcsXZ7tDRiiyNXpuPUdAl8r+EoYF/fUDbMOxqJG7mVeRc8wvwjks/VgBnVE4 sYd8Iswyi8zr/m+eme5FmC4c14PwvsuHhOCDlSspNG0qeW4mxPNWY9uciR8HTNTuHh5r U9elWeZy6jTwtqkb4+/lLitChc7IVXYUf1eWhjKVHTo03LSqCabMFP3doXgyQL2SR2qZ 4efPlAoVX6pwuWunIiT+UUzSiesZnZiCxARJTS4QhtRdhayfb3E0YJ+uoMVL3AZdfwyG eTmSGGfxTrvTNHDm1OkOC02N7jlfax/UOh4GkzlPCiM3jZDj6Pzq6e+kQWwKErp/zrvH HUnQ== MIME-Version: 1.0 X-Received: by 10.112.39.167 with SMTP id q7mr1690379lbk.82.1392848623979; Wed, 19 Feb 2014 14:23:43 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 14:23:43 -0800 (PST) In-Reply-To: <20140219200609.GB8132@mercury.ccil.org> References: <20140219163059.GA18485@mercury.ccil.org> <20140219200609.GB8132@mercury.ccil.org> Date: Wed, 19 Feb 2014 17:23:43 -0500 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a1134d7ae75511704f2c9d7e4 Archived-At: http://mailarchive.ietf.org/arch/msg/json/QhYcWbdraufjScVCZBcBjXej_AA Cc: Nico Williams , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:23:51 -0000 --001a1134d7ae75511704f2c9d7e4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 3:06 PM, John Cowan wrote: > Nico Williams scripsit: > > > I get that some don't want any JSON schemas, to which my answer is: so > > don't use them. But please refrain from fallacious arguments. > > We tried not using XSD schemas. Didn't work. > That is because XML markup requires the schema to be specified in the document because the extensibility scheme depends on it (i.e. the mechanism is bust) What I hate about XML is that schemas don't compose properly. If I have a schema that imports definitions from XMLSignature and XMLEncryption, this is going to be visible in the final spec. Like Frankenstein's monster, the stitching is always visible. This might make sense in a world where a program could see that XMLSignature was being loaded and hand off security decisions to the relevant module but that is not something I could expect to work. The problem with XML is that it was designed to be a less awful version of SGML while allowing the HTML document markup that already existed to be supported which meant support for most existing DTDs. So XML Schema has to have a lot of features that are unnecessary and complex so that all the horrors of SGML could be supported. ASN.1 has a similar problem, it is not really as abstract as the title suggests. Instead of accepting the fact that there would be some overhead due to encoding, the BER encoding tries to avoid using more bytes than necessary with horrors like IMPLICIT tags and bit fields and the rest. Both are cases of someone or rather a committee trying to define a specification for mapping bits on the wire to the abstract data model rather than mapping the abstract data model to bits on the wire. If we do the first then we have ASN.1 people saying 'hey, why do I need this type tag here when I know that the optional tag X will always have an integer field? And then what could have been a very easy to parse data encoding suddenly becomes a very complicated one because the decoder now has to know the schema to map the data on the wire to an abstract data structure. Doing things the second way round is much more regular. We decide that we have an API that has to pass three bits of data in a message (in or out, does not matter), one is a Boolean, another is an Integer, another is a string: Message Test Integer ANumber Boolean TruthValue String SomeText The obvious way to map these to the bits on the wire are to use a JSON number value, true/false/null literals and a string value. And that is just how the tool works. But give that same problem to some people to solve with ABNF and they will produce a syntax 42+. Which is why I don't like giving people ABNF to work with. Leaving aside the fact that there are umpteen internal representations of numbers, I can't think of an intrinsic type that isn't a boolean, a number or a string. And as far as bits on the wire goes, there are no sets or bags either, there are only structures and lists. Where schemas get into trouble is trying to define features to support ad-hoc sub-syntax that isn't actually an interesting general case. I have added DateTime, DNS labels and URIs to my schema as intrinsic types because those are existing sub-types that are very general occurring in most network protocols and have very distinct semantics that are best handled by a single encoder/decoder rather than have multiple handlers throughout the code. But thats where I see the 90/10 rule cutting in. -- Website: http://hallambaker.com/ --001a1134d7ae75511704f2c9d7e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 19, 2014 at 3:06 PM, John Cowan <cowan@mercury.ccil.org= > wrote:
Nico Williams scripsit:

> I get that some don't want any JSON schemas, to which my answer is= : so
> don't use them. =A0But please refrain from fallacious arguments.
We tried not using XSD schemas. =A0Didn't work.
<= div>
That is because XML markup requires the schema to be spe= cified in the document because the extensibility scheme depends on it (i.e.= the mechanism is bust)

What I hate about XML is that schemas don't compose= properly. If I have a schema that imports definitions from XMLSignature an= d XMLEncryption, this is going to be visible in the final spec. Like Franke= nstein's monster, the stitching is always visible. This might make sens= e in a world where a program could see that XMLSignature was being loaded a= nd hand off security decisions to the relevant module but that is not somet= hing I could expect to work.

The problem with XML is that it was designed to be a le= ss awful version of SGML while allowing the HTML document markup that alrea= dy existed to be supported which meant support for most existing DTDs. So X= ML Schema has to have a lot of features that are unnecessary and complex so= that all the horrors of SGML could be supported.

ASN.1 has a similar problem, it is not really as abstra= ct as the title suggests. Instead of accepting the fact that there would be= some overhead due to encoding, the BER encoding tries to avoid using more = bytes than necessary with horrors like IMPLICIT tags and bit fields and the= rest.


Both are cases of someone or rather a co= mmittee trying to define a specification for mapping bits on the wire to th= e abstract data model rather than mapping the abstract data model to bits o= n the wire.

If we do the first then we have ASN.1 people saying = 9;hey, why do I need this type tag here when I know that the optional tag X= will always have an integer field? And then what could have been a very ea= sy to parse data encoding suddenly becomes a very complicated one because t= he decoder now has to know the schema to map the data on the wire to an abs= tract data structure.


Doing things the second way round is muc= h more regular. We decide that we have an API that has to pass three bits o= f data in a message (in or out, does not matter), one is a Boolean, another= is an Integer, another is a string:

Message Test
=A0 =A0 Integer =A0 =A0ANumber
=A0 =A0 Boolean =A0 TruthValue
=A0 =A0 String =A0 =A0 = =A0SomeText

The obvious way to map these to the bi= ts on the wire are to use a JSON number value, true/false/null literals and= a string value. And that is just how the tool works. But give that same pr= oblem to some people to solve with ABNF and they will produce a syntax 42+&= lt;Betcha can't guess what the false value would be>. Which is why I= don't like giving people ABNF to work with.

Leaving aside the fact that there are umpteen internal = representations of numbers, I can't think of an intrinsic type that isn= 't a boolean, a number or a string. And as far as bits on the wire goes= , there are no sets or bags either, there are only structures and lists.=A0=


Where schemas get into trouble is trying= to define features to support ad-hoc sub-syntax that isn't actually an= interesting general case. I have added DateTime, DNS labels and URIs to my= schema as intrinsic types because those are existing sub-types that are ve= ry general occurring in most network protocols and have very distinct seman= tics that are best handled by a single encoder/decoder rather than have mul= tiple handlers throughout the code. But thats where I see the 90/10 rule cu= tting in.

--
Website: ht= tp://hallambaker.com/
--001a1134d7ae75511704f2c9d7e4-- From nobody Wed Feb 19 14:24:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0B91A0524 for ; Wed, 19 Feb 2014 14:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 DYQ9AXFcl4dq for ; Wed, 19 Feb 2014 14:23:58 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id BBFE31A0516 for ; Wed, 19 Feb 2014 14:23:58 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so947124pde.34 for ; Wed, 19 Feb 2014 14:23:55 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=3zD2fn1xzfy7dFQiXhB+8B0PRLCqTtsnLzO0/BMrde4=; b=NDnVL3oIGacc+FUETa1Ug9mFND8PVa0LP+BANpvp2FmSj5fNKYgVZEydAvanEtBfKm /2YMFnXDfm0RARqO62Z1z7OeJDf6AnoHZypvz8wg3z/xOMLrrQ29+EA5va+oOjlWcSZC q1gDg27gXeNnAMYNIAZap6j36pA0F6VSLaWU/VLDnTQcVCvx5Ik4j8gCsiGJa/W9grP2 DbtZCnQvMR1KHybMAp6g47etQtKcjjCVs9bc97zteswtH35OkdJtI5xLACxC+lBj/W4M IQ0Hwz+QLbusHUD9iYIOp6Cm29iGpjtyixDJGv+oeb1YAwgCOFKwtu/PKhL8pVqngvlp j1XA== X-Gm-Message-State: ALoCoQkxCRMwxat8YdxoblxMZdqIzfgXcalIcyKHQuMpodX+76u0aAG8E/RzSCMyQZUJSoSZtsPH MIME-Version: 1.0 X-Received: by 10.66.139.169 with SMTP id qz9mr43110909pab.16.1392848635512; Wed, 19 Feb 2014 14:23:55 -0800 (PST) Received: by 10.68.143.4 with HTTP; Wed, 19 Feb 2014 14:23:55 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Wed, 19 Feb 2014 17:23:55 -0500 Message-ID: From: Andrew Newton To: Tim Bray Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/json/4EswvC9XDGi6qrNLvob1dk4gGl8 Cc: Nico Williams , Phillip Hallam-Baker , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:24:00 -0000 On Wed, Feb 19, 2014 at 12:30 PM, Tim Bray wrote: > I think clear English prose is *essential*, the one thing a specification > must have. Thus, schemas can be actively harmful if arguing over them > distracts attention from crafting the prose properly. This is particularly > the case when the schema language is a flawed tool, which so many of them > are. I agree, clear English prose are essential. At the moment, I am evaluating two competing security protocols, both open standards specified with XML Schema of which one is the product of an IETF working group. The IETF standard is much clearer to understand because it offers prose on top of the XSD. I cannot help but think that the reason the IETF standard stands out is simply because it is an IETF standard; along the way to RFC it was reviewed and reviewed and people simply would not have let it pass had it been only an XSD. Therefore I do not think we need to worry about IETF specifications being harmed by schemas. -andy From nobody Wed Feb 19 14:28:23 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3191A025C for ; Wed, 19 Feb 2014 14:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 AKGQmbdvqrbE for ; Wed, 19 Feb 2014 14:28:21 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 961011A0226 for ; Wed, 19 Feb 2014 14:28:20 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id q8so784599lbi.0 for ; Wed, 19 Feb 2014 14:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WBkYow+FcKosRECdfMFy+lY1EI1BfKyflycRkK2kwMM=; b=pzGcFm/r6UqS/7LmX4T8nt4dLbBrQVfi2Eht7W+X5nRkLUZsCH4g9OlH1EcYvRsCWk WxB3A0JUgpDEJyfR0G6+MyPhWrIeCdIjihcqgEgGHDX2bfLluoo3LXEKMd2CxtHUcVax pdNWSnyaqR6AaCeMRZuU7BM5Eh21IvGZ5iua2lciq7UALFDYbliAF3YTMXtEep0uHXNW Q6NDMO9atsrQeyRzbSsOkwBoPieVUSzTQNU7Lqj6hj3PghHWBM5EcBk10yFdOLkM1Y4H YuxTorCCuo7Ra2XE4OcgxfLRUA+qq19SeAHCEIjDweRY//+awfNSaO60LMAE8Kg0pGV0 bP3Q== MIME-Version: 1.0 X-Received: by 10.112.72.40 with SMTP id a8mr2344418lbv.68.1392848896514; Wed, 19 Feb 2014 14:28:16 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 14:28:16 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 17:28:16 -0500 Message-ID: From: Phillip Hallam-Baker To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c23e2eb3e24404f2c9e795 Archived-At: http://mailarchive.ietf.org/arch/msg/json/OXEvLkaafSX4rbpVQ_wxozc-nAA Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:28:23 -0000 --001a11c23e2eb3e24404f2c9e795 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 5:04 PM, Barry Leiba wrote: > Using Carsten's "summary" note as an anchor, let me back up to where > this proposal came from. > > I'm interested in providing a recommended way (through a non-binding, > Informational document that describes it) in which protocol elements > that are JSON things can be described in documents. I'm hoping we can > keep this work item to that limited scope, and not go too far in > trying to devise something mega-general that does everything but > eat.[1] > > That means that I'm looking for something that addresses the 90% case > nicely and cleanly. The 10% of the messier cases should be workable, > but can be messier, I think. As an example of what made me think > about this, look at these: > 1. Section 6.1.1 of > http://tools.ietf.org/html/draft-ietf-repute-media-type-12 > 2. Section 6.2.2 of > http://tools.ietf.org/html/draft-ietf-repute-media-type-13 > > Note that the attempt to reproduce the JSON ABNF, in version -12, had > a number of problems. I think the mechanism in version -13 is much > cleaner... and it's simple and easy to explain. Nested and complex > structures can be handled as they are in ABNF, by naming the nested or > complex bit and then expanding it in another "rule". I think this > sort of mechanism meets the "addresses the 90% case nicely" desire. I > like it because it's easy to write and, more importantly, easy to read > and understand. > It is obviously possible to create an ABNF description of JSON (call this X) It is thus possible to create an ABNF description of a Web Service message as an ABNF description. (Call this Y) What I think is going to be very hard is proving that a given Y is a subset of X. And if we do that we risk having specifications that are not actually JSON but only JSON-like. Unless that is we start off with a tool that generates Y in a fashion that makes it easy to check that it is a subset of X. -- Website: http://hallambaker.com/ --001a11c23e2eb3e24404f2c9e795 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 19, 2014 at 5:04 PM, Barry Leiba <= barryleiba@com= puter.org> wrote:
Using Carsten's "summary" note= as an anchor, let me back up to where
this proposal came from.

I'm interested in providing a recommended way (through a non-binding, Informational document that describes it) in which protocol elements
that are JSON things can be described in documents. =A0I'm hoping we ca= n
keep this work item to that limited scope, and not go too far in
trying to devise something mega-general that does everything but
eat.[1]

That means that I'm looking for something that addresses the 90% case nicely and cleanly. =A0The 10% of the messier cases should be workable,
but can be messier, I think. =A0As an example of what made me think
about this, look at these:
1. Section 6.1.1 of http://tools.ietf.org/html/draft-ietf-rep= ute-media-type-12
2. Section 6.2.2 of http://tools.ietf.org/html/draft-ietf-rep= ute-media-type-13

Note that the attempt to reproduce the JSON ABNF, in version -12, had
a number of problems. =A0I think the mechanism in version -13 is much
cleaner... and it's simple and easy to explain. =A0Nested and complex structures can be handled as they are in ABNF, by naming the nested or
complex bit and then expanding it in another "rule". =A0I think t= his
sort of mechanism meets the "addresses the 90% case nicely" desir= e. =A0I
like it because it's easy to write and, more importantly, easy to read<= br> and understand.

It is obviously possibl= e to create an ABNF description of JSON (call this X)

<= div>It is thus possible to create an ABNF description of a Web Service mess= age as an ABNF description. (Call this Y)


What I think is going to be very h= ard is proving that a given Y is a subset of X. And if we do that we risk h= aving specifications that are not actually JSON but only JSON-like.

Unless that is we start off with a tool that generates = Y in a fashion that makes it easy to check that it is a subset of X.
<= div>
--
Website: http://ha= llambaker.com/
--001a11c23e2eb3e24404f2c9e795-- From nobody Wed Feb 19 14:29:56 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465A91A025C for ; Wed, 19 Feb 2014 14:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.752 X-Spam-Level: **** X-Spam-Status: No, score=4.752 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] autolearn=no 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 nM4FMXvNLYqF for ; Wed, 19 Feb 2014 14:29:51 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id DEFBF1A0226 for ; Wed, 19 Feb 2014 14:29:50 -0800 (PST) Received: (qmail 23300 invoked from network); 19 Feb 2014 22:28:50 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 19 Feb 2014 22:28:45 +0000 Message-ID: <357740A8AA0F4316BE630917321FAB4D@codalogic> From: "Pete Cordell" To: "Carsten Bormann" , "JSON WG" References: X-Unsent: 1 Date: Wed, 19 Feb 2014 22:29:32 -0000 X-Vipre-Scanned: 02B1FAA400681402B1FBF1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/63buFQWqMAsVI-06dCIbZvMnuy4 Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:29:54 -0000 I agree with Carsten's suggestion of looking for something to do the 80%. The JSON group's biggest blessing might be that it dissolves before it can add sufficient esoterica to the schema to make it useless. Things I've learnt while working with schema is that a schema needs to: - Be able to be explicit about which one (or many) constructs serve as the top-level construct, - Expecting a 'schema' processor to miraculously import stuff over the network is hard, - Being able to extend a schema via a third-party document is important (especially for the IETF). Also, cardinality and integer ranges, and string lengths are 80% of constraints a schema needs on types. I thought I'd throw down n gauntlet as a baseline for something to be beat. So I started with something C like, and stole stuff from other languages and came up with the following import "something.jsc" // import just tells the schema processor to issue a warning if // the specified filename does not appear on the command-line. // It's not a directive to find the specified file. namespace com.ietf.person; // Namespaces are handy for composing vocabularies across // multiple domains. Switching to another namespace then output // a new namespace directive. start struct com.ietf.person // The 'start' keyword marks one or more root constructs // struct maps to an object of unordered members { string<1..255> name; // Constraints on a type are in angled brackets. In the case // of a string it is the string length, here 1 to 255 characters. string<1..255>[?] alias; // Cardinality is expressed in square brackets. The Kleene // operators are used for the common cases. More complex // cases might be [5], [1..2], [1..*] ShortString[?] maidenName; int[1..10] scores; // Constraints on integers are the number range. Inclusive // range might be <0..65535>, exclusive ranges bool isEligible; Car[1..*] cars; House[*] houses; Sport[*] sports; com.ietf.other.job job; // Referring to a type in another namespace }; string<1..255> ShortString; // Defining a simple type struct Car // Defining a compound type { string make; string model; int<1900..9999> year; }; struct House { string name; string street; string town; string country; }; union Sport { null track; null racket; null water; null water; null motor; }; // Allow extensions that can plug components into // type defined elsewhere plug into Car, House { float[?] cost; }; plug into Sport { null insane; }; // If required to return to the global namespace: namespace ; In many respects I think the problem we will have is not that the problem is too hard, but that it is too easy and we all have an opinion on it, making hard to come to agreement! Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Carsten Bormann" To: "JSON WG" Sent: Wednesday, February 19, 2014 8:02 PM Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward At the danger of repeating myself and others here, I’ll try to summarize: — We have quite good experience with using a single, standard (!) ABNF in IETF protocols. ABNF is a production system with well-understood semantics. It is somewhat idiosyncratic in the world of EBNF, but that has caused *zero* problems in practice. (People have just written ABNF parsers. You still have the second half of the afternoon to do something else after that.) — A production system that generates JSON (at the data model level) is easy to do. (But we have to find people who have the background and can commit the time.) — Relax NG compact is a nice existence proof that a production system like this can work and be highly usable. A JSON version could be even simpler. — Previous attempts at trying to express XML or JSON data model syntax in the formalism of XML or JSON itself provide incontrovertible proof that this approach does not work. Don’t do that then. (It is so much easier to spend half the afternoon writing the parser for the workable syntax. We can even spec it in ABNF!) — If you want to cover 100 % of the “syntax” of an XML document, you need to add Schematron to Relax NG compact. a) Don’t do that then for JSON — stay with an 80 % solution like Relax NG (which is more like 90 %) or maybe even simpler. b) Choose some form of “Jpath” to complement the production system with assertions. (Note that choice b can always be added later, on a separate timeline from doing a production system.) My proposals following from this little exercise in fact finding: — I would propose that we try to find energy for doing the production system. (In addition to the Web people, we may want to tap the YANG people for some recent experience in doing this kind of work.) — I would propose that we stay open to adding a Jpath/Schematron approach (choice “b”), *if* somebody brings a credible one to the table. — I also would propose that we collect a small number of benchmarks that we use for demonstrating that proposals for the production system are useful. My first suggestion: RFC 7071. But we need a couple of different ones. RFC 7095? Maybe too ambitious. Grüße, Carsten _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json From nobody Wed Feb 19 14:32:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0C51A02A1 for ; Wed, 19 Feb 2014 14:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 L0gHTPTOtWQa for ; Wed, 19 Feb 2014 14:32:19 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3581A0239 for ; Wed, 19 Feb 2014 14:32:18 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so1685825qaq.20 for ; Wed, 19 Feb 2014 14:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1aPL24EUUT9qBcePOeNirGtvp1/nYYx+01lgNIm+bbc=; b=DW16DxFWUoVcSjqTMOkNBWHTQfEVPMqkimguQme8/NtP0V743TcY2VD9fVN5BekCGj tTTpHxc64MoDiKQwy1k2oRPiyb6sP2yIvkzeixrAWtQMhtGO/YV91flhcfkmNyPOFIO6 M3xUF4wmob0Wz8DZTOvGwdp+Z2MEz+NInjfJEujs3F8E1H5OLcEetX9KJiCX5FAg1uLn hrKixYAXSYjAlDe935GQE2U7YWibnp1w1mVroe2myOGvvVTO5QASo07jfHzGmlWYWu5N hWPKelhES0Zmq7d3sFTQ1nxetEBPMGnvp25L/B8zEDnGtwMRW2gRylFqNndOiNgfLYUo Gg8A== MIME-Version: 1.0 X-Received: by 10.229.98.129 with SMTP id q1mr54077829qcn.3.1392849135602; Wed, 19 Feb 2014 14:32:15 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.26.11 with HTTP; Wed, 19 Feb 2014 14:32:15 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 17:32:15 -0500 X-Google-Sender-Auth: T4lSnAhikoynh9RajRK96AUuxK0 Message-ID: From: Barry Leiba To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/json/tovYNN4LNa1EgN8QCExfLA1j3oo Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:32:20 -0000 > What I think is going to be very hard is proving that a given Y is a subset > of X. And if we do that we risk having specifications that are not actually > JSON but only JSON-like. > > Unless that is we start off with a tool that generates Y in a fashion that > makes it easy to check that it is a subset of X. Oh, I absolutely think that tools to support this are a big help! Barry From nobody Wed Feb 19 14:57:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9D1A0516 for ; Wed, 19 Feb 2014 14:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 GnVBHEWEQyVu for ; Wed, 19 Feb 2014 14:57:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2F1A02A1 for ; Wed, 19 Feb 2014 14:57:18 -0800 (PST) Received: from netb ([178.13.213.98]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LeeNW-1X4OPv31Be-00qSLb for ; Wed, 19 Feb 2014 23:57:14 +0100 From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Wed, 19 Feb 2014 23:57:19 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:u2VwoWq5lKbBTPMJoA1MoHQ+zsGsNij7S3MlZMXCQGrSJlHmZ7G 7Vkcv6cH9KrH7fzsNCutmGWYO3jMrblMSsCsUfxq2ltLNR/LG76JzqdTuU3fbrdgcDLQBu3 oU8Cmx+cBK1hrl3d75ZiX5f0lw1fhQbQ8OccKTIO5/Agv+dXsEis9IcU3xbiZ9xbYlz8lMP v6kYtKDM/21+77ZPVTxFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/json/jtJtsScpSprJrAU0XAFEitdipWg Cc: Barry Leiba , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:57:21 -0000 * Phillip Hallam-Baker wrote: >It is obviously possible to create an ABNF description of JSON (call this X) > >It is thus possible to create an ABNF description of a Web Service message >as an ABNF description. (Call this Y) > >What I think is going to be very hard is proving that a given Y is a subset >of X. And if we do that we risk having specifications that are not actually >JSON but only JSON-like. > >Unless that is we start off with a tool that generates Y in a fashion that >makes it easy to check that it is a subset of X. The main problem with using ABNF for Y is that it is tedious to write it out properly, they want to write "example" and not a complex grammar for all possible "\uXXXX" escape sequences. This is a common problem with URI scheme specifications, for instance. Beyond that it is not really a problem for a tool to compare two grammars as would be needed here (the problem is undecidable in the most general case, but even then a regular approximation could be used; I will probably release a tool later this year that does something like this). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Wed Feb 19 15:04:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752A41A051C for ; Wed, 19 Feb 2014 15:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 Zw0pDGrhvURf for ; Wed, 19 Feb 2014 15:04:55 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C820C1A02B9 for ; Wed, 19 Feb 2014 15:04:55 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WGGC9-0004tf-A5; Wed, 19 Feb 2014 18:04:49 -0500 Date: Wed, 19 Feb 2014 18:04:49 -0500 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20140219230449.GB12169@mercury.ccil.org> References: <20140219163059.GA18485@mercury.ccil.org> <20140219200609.GB8132@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/W1aaKbqchdaEymADQb3XAoiU50A Cc: Nico Williams , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 23:04:57 -0000 Phillip Hallam-Baker scripsit: > That is because XML markup requires the schema to be specified in the > document Not so, unless you mean DTDs. > because the extensibility scheme depends on it (i.e. the mechanism > is bust) Not so. > The problem with XML is that it was designed to be a less awful version of > SGML while allowing the HTML document markup that already existed to be > supported Not so. > which meant support for most existing DTDs. Not so. > So XML Schema has to > have a lot of features that are unnecessary and complex so that all the > horrors of SGML could be supported. Not so. > Both are cases of someone or rather a committee trying to define a > specification for mapping bits on the wire to the abstract data model > rather than mapping the abstract data model to bits on the wire. Not so. > I can't think of an intrinsic type that isn't a boolean, a number > or a string. And as far as bits on the wire goes, there are no sets or bags > either, there are only structures and lists. All I can say is, your imagination appears deficient. -- Verbogeny is one of the pleasurettes John Cowan of a creatific thinkerizer. http://www.ccil.org/~cowan --Peter da Silva From nobody Wed Feb 19 15:15:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201E41A02B9 for ; Wed, 19 Feb 2014 15:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 8BlDprGCMFI2 for ; Wed, 19 Feb 2014 15:15:13 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 76FD41A0296 for ; Wed, 19 Feb 2014 15:15:13 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 4F2092005D90E for ; Wed, 19 Feb 2014 15:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VwBFM4r/UZ5HuAykRESB FlnH1dw=; b=dP1ar23ExVTKKGbiNbxsTtHnr6wtF63MONOY0Ui0lSkIFURHjp+S up/LwDChqSf3yZPwTs0UPQDoweihWg+VAzHW4aqSabDGwVobgEHEHbMNBn4egG6Y yIvCOYWRo+f471X0ouFxYamOPYhNln3JmmmBXM8UYb0c5PBAIY+Nn6k= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id D3FD72005D909 for ; Wed, 19 Feb 2014 15:15:09 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so878861wes.23 for ; Wed, 19 Feb 2014 15:15:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V9T+m3LXVi+QxrPY5m/0RgaDeXJsHPmqehgymED/q3c=; b=YZvxBrk3Hio4QpIhdEQWxNW34WDc60TvpEPmcQ4r9e3UMocNzYXdDi+FSMEe4YPdjl JAcgqT/sfyVbq7jtglBiNbS59gQOsK15P84OVW+X27sl5XIQsvyxwY6gvo3llLWQeyPf 7m5w1/a+RixRY+hDXDo097FH9m5qEEM2vOBPlCIw0pXxXkEaZEuDSjBiwSWzG90waA26 kQTAu2wAVv16kDoP8I3e0t7WGVA1HzWRkBZSZJ9RGd7bdORO9yvM7uY0biF8ei8NQ52v VH3IsGTQvu9bdMgKKlrlwq+ahHk+xff+MXcU0S1izPj8qnm85kKW0vPjEqjlmE1ggEZs we3A== MIME-Version: 1.0 X-Received: by 10.194.104.39 with SMTP id gb7mr4576263wjb.69.1392851708220; Wed, 19 Feb 2014 15:15:08 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 15:15:08 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 17:15:08 -0600 Message-ID: From: Nico Williams To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Y7JuNkj9Ic5aEleCyVSpRBAXN-c Cc: Phillip Hallam-Baker , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 23:15:15 -0000 On Wed, Feb 19, 2014 at 4:23 PM, Andrew Newton wrote: > On Wed, Feb 19, 2014 at 12:30 PM, Tim Bray wrote: >> I think clear English prose is *essential*, the one thing a specification >> must have. Thus, schemas can be actively harmful if arguing over them >> distracts attention from crafting the prose properly. This is particularly >> the case when the schema language is a flawed tool, which so many of them >> are. > > I agree, clear English prose are essential. At the moment, I am > evaluating two competing security protocols, both open standards > specified with XML Schema of which one is the product of an IETF > working group. The IETF standard is much clearer to understand because > it offers prose on top of the XSD. I cannot help but think that the > reason the IETF standard stands out is simply because it is an IETF > standard; along the way to RFC it was reviewed and reviewed and people > simply would not have let it pass had it been only an XSD. Therefore I > do not think we need to worry about IETF specifications being harmed > by schemas. So you agree that prose is needed (no one here yet disagrees), but you don't think schemas are harmful because we generally require prose (which we do) and that's good. Good! We do need prose-mostly descriptions of protocols. We need formal languages to avoid accidents and to convey concisely and precisely things that can be difficult to do in prose (in any natural language). Prose is needed for semantics -- formal alternatives for that (e.g., SDL) so far haven't worked well. What I want to avoid: - TLS-style tool-less inconsistent ad-hoc syntaxes - SSHv2-style tool-less inconsistent ad-hoc syntaxes - 100% prose-only (e.g., SASL) I also do not want an ASN.1 where the only way to implement is either a) spend years building tools first, or b) ad-hoc manual coding based off a syntax that's full of nuances (since this leads to accidents). Whatever schema(s) we go with has to be simple enough that ad-hoc manual coding off of the syntax is less likely to cause accidents than ad-hoc manual coding off of prose, while also being usable with automatic tooling. Since we're talking about JSON we don't need to worry about silly warts like DER/BER/CER tagging. No need to mention such nastiness :) Things I'd consider, and maybe propose: - just pattern-matching validation rules (e.g., using the jq or other similar language that can do pattern matching); - a schema with describe-by-example-mostly metaschema, with special names denoting "types" defined separately, something like: { "message": { "sender": "_sender_type, "receiver": "_receiver_type", "payload": "_json_string"} "sender": { ... }, ... } - a schema like compact RelaxNG that can be parsed and converted into one of the above; or anything else that's relatively simple and from which code can be generated (or which can be interpreted) to at least do validation (for testing, not necessarily at run-time in production), and preferably more (e.g., RPC-like stubs, programming language types, ...). Nico -- From nobody Wed Feb 19 15:20:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A501A02E5 for ; Wed, 19 Feb 2014 15:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 tMiNZgRMlyt9 for ; Wed, 19 Feb 2014 15:20:07 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0301A02BE for ; Wed, 19 Feb 2014 15:20:07 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 325261E064 for ; Wed, 19 Feb 2014 15:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=K3yMKdAJrfZJzFRUe7vA RQBWyqc=; b=Ugyj2niCPXewGM+CkyJ3sqbVxHaa2FhceElPfCLvEd6MpOoXMpF5 F2VKDBEHjfhxx5XYCPg5E+JO1lctsKSte8K8+EAmVfjOXm9kSKCjJ9HdH87FY/RN rgyQ9gOhTxfJWMO0hnLUCZ3ragfUKaF+AekEhRGZECGRyvwfAwyFlSw= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id B83C31E05C for ; Wed, 19 Feb 2014 15:20:03 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so885253wgg.13 for ; Wed, 19 Feb 2014 15:20:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=igj8xoDjfOFg3bcgoIs/CH/1dsWia+xEVxK7mITLVXE=; b=E2ZoYBEoA9RWnVXFFeLM9Ct7tD+Pzd2adsheAk2pjKygi+G5edVGaqLBnsizHZr6sy jM2EvzDURWAvNQhFnJApSOSyQf8UYlhUIV16gzVEq6HXfanux8NNM5zqHh9PIgvcKo4N aQuAuCnBgidWfxXHT/CH5JMv368++CitzqMyF/JwyHBpDSqDkHEk8jPmHMfAzxcY7vLq qzkGqFhPfH+h+CDRQ4HEYa8o4MQH7O7wiF3/fW0nbA5W53h6hK0AiJsxuuU9sqDHeLxb PEIaiEkEniqgTnOCjniFDaRKp7ym+Cta8A8AXFNhpMfhFbQVLiKtMMigpHwLze4t14By 1LOg== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr4041782wib.42.1392852002367; Wed, 19 Feb 2014 15:20:02 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 15:20:02 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 17:20:02 -0600 Message-ID: From: Nico Williams To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/fgqK6kHf-fR7if63PiNy8tjhcog Cc: Barry Leiba , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 23:20:08 -0000 On Wed, Feb 19, 2014 at 4:57 PM, Bjoern Hoehrmann wrote: > The main problem with using ABNF for Y is that it is tedious to write it > out properly, [...] Some problems with ABNF beyond the ones you mention: - ABNF is a grammar for strings, but we're dealing with already-parsed (notionally) JSON texts. Augmenting the JSON ABNF to specify a JSON message sounds painful. - Generating anything more than a recognizer/validator from ABNF is difficult or difficult to use the results. ABNF has its uses; this isn't one of them. Nico -- From nobody Wed Feb 19 16:18:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6AF1A05D2 for ; Wed, 19 Feb 2014 16:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 u6I8u63XN_Y9 for ; Wed, 19 Feb 2014 16:18:49 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id C2D8B1A054D for ; Wed, 19 Feb 2014 16:18:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,508,1389704400"; d="scan'208";a="184513354" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 Feb 2014 11:18:44 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7354"; a="194825846" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccvi.tcif.telstra.com.au with ESMTP; 20 Feb 2014 11:18:44 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Thu, 20 Feb 2014 11:18:43 +1100 From: "Manger, James" To: JSON WG Date: Thu, 20 Feb 2014 11:18:42 +1100 Thread-Topic: [Json] Nudging the English-language vs. formalisms discussion forward Thread-Index: Ac8tySf98BiS6ALPTPCf+5GGVQoPZAABCPAQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1153B778363@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/hj5wT_iAMf7zWe0TRpsuhQN1Y-Y Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 00:18:51 -0000 T25lIG1vcmUgZXhhbXBsZSBvZiBhbiBleGlzdGluZyBwcmFjdGljZSBmb3IgZGVzY3JpYmluZyBK U09OIHZhbHVlcyBhcHBlYXJzIGluIHJlY2VudCBkcmFmdCBzcGVjcyBmcm9tIHRoZSBGSURPIEFs bGlhbmNlIDxodHRwOi8vZmlkb2FsbGlhbmNlLm9yZy9zcGVjaWZpY2F0aW9ucy9kb3dubG9hZD4u IEl0IHNlZW1zIHRvIGJlIGJhc2VkIG9uIFdlYiBJREwgd2l0aCBFQ01BU2NyaXB0IGJpbmRpbmdz IDxodHRwOi8vd3d3LnczLm9yZy9UUi9XZWJJREwvI2VjbWFzY3JpcHQtYmluZGluZz4uICBUaGUg Zm9sbG93aW5nIGV4YW1wbGUgY29tZXMgZnJvbSBmaWRvLXVhZi1wcm90b2NvbC12MS4wLXJkLTIw MTQwMjA5LnBkZjoNCg0KZGljdGlvbmFyeSBWZXJzaW9uIHsNCiAgaW50IG1qOyAvLyBNYW5kYXRv cnkuDQogIGludCBtbjsgLy8gTWFuZGF0b3J5Lg0KfQ0KDQpkaWN0aW9uYXJ5IE9wZXJhdGlvbkhl YWRlciB7DQogIFZlcnNpb24gdXB2OyAvLyBNYW5kYXRvcnkuDQogIERPTVN0cmluZyBvcDsgLy8g TWFuZGF0b3J5LiBNdXN0IGJlIOKAnFJlZ+KAnSwg4oCcQXV0aOKAnSBvciDigJxEZXJlZ+KAnQ0K ICBET01TdHJpbmcgYXBwSUQ7IC8vIE1hbmRhdG9yeS4gc3RyaW5nWzEuLjUxMl0uDQogIERPTVN0 cmluZyBzZXJ2ZXJEYXRhOyAvLyBPcHRpb25hbCwgc3RyaW5nWzEuLjE1MzZdDQogIEV4dGVuc2lv bltdIGV4dHM7IC8vIE9wdGlvbmFsLg0KfQ0KDQpkaWN0aW9uYXJ5IEV4dGVuc2lvbiB7DQogIERP TVN0cmluZyBpZDsgLy8gTWFuZGF0b3J5LiBzdHJpbmdbMS4uMzJdLg0KICBET01TdHJpbmcgZGF0 YTsgLy8gTWFuZGF0b3J5LiBiYXNlNjR1cmwoYnl0ZVsxLi44MTkyXSkuDQogIGJvb2xlYW4gZmFp bF9pZl91bmtub3duOy8vIE1hbmRhdG9yeS4NCn0NCg0KDQpJIGRvbuKAmXQgcGFydGljdWxhcmx5 IGxpa2UgaXQ7IGl0IGRvZXNu4oCZdCBmZWVsIGxpa2UgSlNPTiAoZWcgImRpY3Rpb25hcnkiIHZz ICJvYmplY3QiKTsgY29uc3RyYWludHMgYXJlIGFsbCBpbiBjb21tZW50czsgYW5kIElETCBpcyBh aW1lZCBhdCBBUElzIGFzIG9wcG9zZWQgdG8gcHJvdG9jb2wgbWVzc2FnZXMuIEJ1dCBpdCBzb3J0 LW9mIHdvcmtzOiBpdCBpcyBmYWlybHkgZWFzeSB0byBndWVzcyB3aGF0IHRoZSBKU09OIGhhcyB0 byBsb29rIGxpa2UuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From nobody Wed Feb 19 16:24:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64CD1A0538 for ; Wed, 19 Feb 2014 16:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 y1FJVM0fqGos for ; Wed, 19 Feb 2014 16:24:55 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 08A6D1A0467 for ; Wed, 19 Feb 2014 16:24:54 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so1190699vcb.39 for ; Wed, 19 Feb 2014 16:24:51 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=S5TkTdJMEe4R7ErHcO5f/GK4nsJK9uWLByEi6q0Lzag=; b=hZlXJjgGxHCiPgE720+Jl/d/m1Ejd1RkSRDoOyDyqMxdGcN2Ru1ow2ycTXgMIaJTMA CBYmneVBeGnh21aG2Z+amam8vpfRo7tqubNka3XI2EJMkMbg7J+XAv2RmOJfln00JPv0 SLp5NUJC9t4w3T3l27uB+CFT+D9/eP88LZoCbJUkKVudu3O8q5s2oRAKXYfNlocwvIAq 30vUj7e/9A2/SlzpIGKAkWWQ/2LwnzLM71kBcgOwVT3d+xm0dftU0lOxqrjwRzW1K2TV Ej76C1cMv7kDo21DOf+fPK8XOce/O2C3Du5AEYeKGVml4gob7oM+0FEnh98wZ7Y8VIlX ondw== X-Gm-Message-State: ALoCoQn1pQRZ1S5MzDA7XKiwg3Fq6lU88zQa4a2M+iOyxm9lE9fW6TVj/wKrnk+HoLvbhq1Frgha MIME-Version: 1.0 X-Received: by 10.52.63.233 with SMTP id j9mr1914495vds.69.1392855891403; Wed, 19 Feb 2014 16:24:51 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 19 Feb 2014 16:24:51 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1153B778363@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1153B778363@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 19 Feb 2014 16:24:51 -0800 Message-ID: From: Tim Bray To: "Manger, James" Content-Type: multipart/alternative; boundary=001a11369b04a17fc304f2cb8828 Archived-At: http://mailarchive.ietf.org/arch/msg/json/0QPQ-9hCrqUtcO0vNYjqHuaKkDQ Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 00:24:57 -0000 --001a11369b04a17fc304f2cb8828 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, obvious when you think about it, since JSON=E2=80=99s roots are in Java= Script and JSON docs are parseable as such, a bagful of JS assertions (yeah, I know JS doesn=E2=80=99t have an =E2=80=9Cassert=E2=80=9D primitive, but sti= ll) could be a not-terrible stand-in for a schema. Sort of Schematron-like. On Wed, Feb 19, 2014 at 4:18 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > One more example of an existing practice for describing JSON values > appears in recent draft specs from the FIDO Alliance < > http://fidoalliance.org/specifications/download>. It seems to be based on > Web IDL with ECMAScript bindings < > http://www.w3.org/TR/WebIDL/#ecmascript-binding>. The following example > comes from fido-uaf-protocol-v1.0-rd-20140209.pdf: > > dictionary Version { > int mj; // Mandatory. > int mn; // Mandatory. > } > > dictionary OperationHeader { > Version upv; // Mandatory. > DOMString op; // Mandatory. Must be =E2=80=9CReg=E2=80=9D, =E2=80=9CAut= h=E2=80=9D or =E2=80=9CDereg=E2=80=9D > DOMString appID; // Mandatory. string[1..512]. > DOMString serverData; // Optional, string[1..1536] > Extension[] exts; // Optional. > } > > dictionary Extension { > DOMString id; // Mandatory. string[1..32]. > DOMString data; // Mandatory. base64url(byte[1..8192]). > boolean fail_if_unknown;// Mandatory. > } > > > I don=E2=80=99t particularly like it; it doesn=E2=80=99t feel like JSON (= eg "dictionary" > vs "object"); constraints are all in comments; and IDL is aimed at APIs a= s > opposed to protocol messages. But it sort-of works: it is fairly easy to > guess what the JSON has to look like. > > -- > James Manger > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11369b04a17fc304f2cb8828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm, obvious when you think about it, since JSON=E2=80=99s = roots are in JavaScript and JSON docs are parseable as such, a bagful of JS= assertions (yeah, I know JS doesn=E2=80=99t have an =E2=80=9Cassert=E2=80= =9D primitive, but still) could be a not-terrible stand-in for a schema. So= rt of Schematron-like.


On Wed, Feb 1= 9, 2014 at 4:18 PM, Manger, James <James.H.Manger@team.telst= ra.com> wrote:
One more example of an existing practice for= describing JSON values appears in recent draft specs from the FIDO Allianc= e <http://fidoalliance.org/specifications/download>. It seems = to be based on Web IDL with ECMAScript bindings <http://www.w3.org/TR= /WebIDL/#ecmascript-binding>. =C2=A0The following example comes from= fido-uaf-protocol-v1.0-rd-20140209.pdf:

dictionary Version {
=C2=A0 int mj; // Mandatory.
=C2=A0 int mn; // Mandatory.
}

dictionary OperationHeader {
=C2=A0 Version upv; // Mandatory.
=C2=A0 DOMString op; // Mandatory. Must be =E2=80=9CReg=E2=80=9D, =E2=80=9C= Auth=E2=80=9D or =E2=80=9CDereg=E2=80=9D
=C2=A0 DOMString appID; // Mandatory. string[1..512].
=C2=A0 DOMString serverData; // Optional, string[1..1536]
=C2=A0 Extension[] exts; // Optional.
}

dictionary Extension {
=C2=A0 DOMString id; // Mandatory. string[1..32].
=C2=A0 DOMString data; // Mandatory. base64url(byte[1..8192]).
=C2=A0 boolean fail_if_unknown;// Mandatory.
}


I don=E2=80=99t particularly like it; it doesn=E2=80=99t feel like JSON (eg= "dictionary" vs "object"); constraints are all in comm= ents; and IDL is aimed at APIs as opposed to protocol messages. But it sort= -of works: it is fairly easy to guess what the JSON has to look like.

--
James Manger
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11369b04a17fc304f2cb8828-- From nobody Wed Feb 19 16:31:23 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974201A02D8 for ; Wed, 19 Feb 2014 16:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 Fjm1_zeJbdcB for ; Wed, 19 Feb 2014 16:31:21 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4831A02AE for ; Wed, 19 Feb 2014 16:31:21 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 05C912C806B for ; Wed, 19 Feb 2014 16:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kdiuU/RjLfc4el4EJYJWQMMcZXY=; b=SRXCb34dxfT hspEjapUEPuZ8UPJ5i17Buyh+0kOGITha7crciVq5G+OSp91IRSAThG/bFWAzxXm 5LDQE9nOOjN9nA40h3ZZRIa24NI/74d2I1FzazOeVihuMcDBp9tH3Ri7l0iyA3br gJ1I+R2nSf8X3tKVb1DESlFZHS6kPBxM= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id A85A12C806D for ; Wed, 19 Feb 2014 16:31:17 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so97103wiv.2 for ; Wed, 19 Feb 2014 16:31:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xJkfbys78o8wvtgWPq3lxmCvM36qoCr8AnAlwYufKAE=; b=T9Efd+LI2Uw5X0H6ur69cZfD9p0y0P8rD8s8IIWhLttId/tgdBmGyh+0Ty2B2oOtqi FzGHu201vWyMGXsKuEQNMoHBnekzJE7tgrHSagIW1UsLXZmYAAcfALniZbMGlb00lm10 rUslg4bTJztNH8gxgtrQWMq1lqbm0ordeJcRCh8dMdYGDFbgTsUNIhwV8W5FuD/eem0u ZdsBKJMXViwiyJZQgs+hVzjts4HwTRsodsNJvj0VpFJTFS2nU0aHkfTnRRbj0mLxjOtN tsXxIxInrmpd+Q8rSwQhUlToeeSpuEY6fS9EUTkYYcsi38qZ1LoWy2n1T9XvzR2SBedc C09Q== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr4222238wib.42.1392856275831; Wed, 19 Feb 2014 16:31:15 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 16:31:15 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153B778363@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 19 Feb 2014 18:31:15 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/lEGZZy8kuVNX8i0x44kdTBt2Oyg Cc: "Manger, James" , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 00:31:22 -0000 On Wed, Feb 19, 2014 at 6:24 PM, Tim Bray wrote: > Hm, obvious when you think about it, since JSON=E2=80=99s roots are in Ja= vaScript > and JSON docs are parseable as such, a bagful of JS assertions (yeah, I k= now > JS doesn=E2=80=99t have an =E2=80=9Cassert=E2=80=9D primitive, but still)= could be a not-terrible > stand-in for a schema. Sort of Schematron-like. Yes, pattern matching type rules would WFM as one option. Note that the stuff you're responding to here looks not too unlike... XDR, or even ASN.1. The metaphor seems to be: named types. Nico -- From nobody Wed Feb 19 17:21:39 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7871A05FB for ; Wed, 19 Feb 2014 17:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 wFqtIr5r0KIP for ; Wed, 19 Feb 2014 17:21:35 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7A11A0216 for ; Wed, 19 Feb 2014 17:21:35 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id q8so872313lbi.14 for ; Wed, 19 Feb 2014 17:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dubm8JMErUvKymWeqLogrcb4/+dO1Y7gW5LC2pqbj38=; b=lvrA+x5WmzAYNQG6TSXK3PBxvTgKs+bfk2gu6XTURkRDM95dLk/gYHyKHclc2aDDQt IsDcdNbdRkyxJxl/TaITvE52Eip79OPO4xF1jq4vSs3eaDBgyDijnGnxvisTG22cuTjD qma6XlAzw739d9c1wVhra5Ea0zXDyDblh7lbiMEO8JYlKWeaCmumnj37jLV2zdW4qJJp xedPY/OaRdvut8EzKntPVN+jh5AjoRtyjCjkgnQu/HXoSsmN6dAvHAFmgBoU2dyR/Y7P jYNYusv1HkxJHDTKBWId6frL9v/5f8LL0CGlX5s9Suuw9QcSK7VVWFfwMXO/v6pm9JL4 2MIA== MIME-Version: 1.0 X-Received: by 10.152.219.97 with SMTP id pn1mr28152370lac.9.1392859291266; Wed, 19 Feb 2014 17:21:31 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 17:21:31 -0800 (PST) In-Reply-To: <20140219230449.GB12169@mercury.ccil.org> References: <20140219163059.GA18485@mercury.ccil.org> <20140219200609.GB8132@mercury.ccil.org> <20140219230449.GB12169@mercury.ccil.org> Date: Wed, 19 Feb 2014 20:21:31 -0500 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a1137f67c47322804f2cc538c Archived-At: http://mailarchive.ietf.org/arch/msg/json/efQd197NzOPC-mxVkbDyK0D3o2E Cc: Nico Williams , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 01:21:38 -0000 --001a1137f67c47322804f2cc538c Content-Type: text/plain; charset=ISO-8859-1 This is what I was referring to: https://idp.example.org/SAML2 ... Interpreting those namespaces correctly requires a huge amount of complex logic that is completely unnecessary. Since we had Eve Maler on the TC, I think we were doing the XML schema right the second time round... If XML Schema had been better designed the namespaces would never appear on the wire Though since the post had no content other than 'oh no it isn't' the poster might have had a different idea. Clearly composition of schema specs is hard. Does it have to be solved? On Wed, Feb 19, 2014 at 6:04 PM, John Cowan wrote: > Phillip Hallam-Baker scripsit: > > > That is because XML markup requires the schema to be specified in the > > document > > Not so, unless you mean DTDs. > > > because the extensibility scheme depends on it (i.e. the mechanism > > is bust) > > Not so. > > > The problem with XML is that it was designed to be a less awful version > of > > SGML while allowing the HTML document markup that already existed to be > > supported > > Not so. > > > which meant support for most existing DTDs. > > Not so. > > > So XML Schema has to > > have a lot of features that are unnecessary and complex so that all the > > horrors of SGML could be supported. > > Not so. > > > Both are cases of someone or rather a committee trying to define a > > specification for mapping bits on the wire to the abstract data model > > rather than mapping the abstract data model to bits on the wire. > > Not so. > > > I can't think of an intrinsic type that isn't a boolean, a number > > or a string. And as far as bits on the wire goes, there are no sets or > bags > > either, there are only structures and lists. > > All I can say is, your imagination appears deficient. > > -- > Verbogeny is one of the pleasurettes John Cowan > of a creatific thinkerizer. http://www.ccil.org/~cowan > --Peter da Silva > -- Website: http://hallambaker.com/ --001a1137f67c47322804f2cc538c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is what I was referring to:

<saml:Assertion
   xmlns:saml=3D"urn:oasis:names:tc:SAML:2.0:assertion"
   xmlns:xs=3D"http://www.w3.o=
rg/2001/XMLSchema"
   xmlns:xsi=3D"http:=
//www.w3.org/2001/XMLSchema-instance"
   ID=3D"b07b804c-7c29-ea16-7300-4f3d6f7928ac"
   Version=3D"2.0"
   IssueInstant=3D"2004-12-05T09:22:05">
   <saml:Issuer>https://idp.exam=
ple.org/SAML2</saml:Issuer>
   <ds:Signature
     xmlns:ds=3D"http://ww=
w.w3.org/2000/09/xmldsig#">...</ds:Signature>
   <saml:Subject>


Interpreti= ng those namespaces correctly requires a huge amount of complex logic that = is completely unnecessary.

Since we ha= d Eve Maler on the TC, I think we were doing the XML schema right the secon= d time round...


If XML Schema had been better designed= the namespaces would never appear on the wire


Though since the post had no content other than 'oh no it isn't&= #39; the poster might have had a different idea.


<= div class=3D"gmail_extra">Clearly composition of schema specs is hard. Does= it have to be solved?




On = Wed, Feb 19, 2014 at 6:04 PM, John Cowan <cowan@mercury.ccil.org&= gt; wrote:
Phillip Hallam-Baker scripsit:

> That is because XML markup requires the schema to be specified in the<= br> > document

Not so, unless you mean DTDs.

> because the extensibility scheme depends on it (i.e. the mechanism
> is bust)

Not so.

> The problem with XML is that it was designed to be a less awful versio= n of
> SGML while allowing the HTML document markup that already existed to b= e
> supported

Not so.

> which meant support for most existing DTDs.

Not so.

> So XML Schema has to
> have a lot of features that are unnecessary and complex so that all th= e
> horrors of SGML could be supported.

Not so.

> Both are cases of someone or rather a committee trying to define a
> specification for mapping bits on the wire to the abstract data model<= br> > rather than mapping the abstract data model to bits on the wire.

Not so.

> I can't think of an intrinsic type that isn't a boolean, a num= ber
> or a string. And as far as bits on the wire goes, there are no sets or= bags
> either, there are only structures and lists.

All I can say is, your imagination appears deficient.

--
Verbogeny is one of the pleasurettes =A0 =A0John Cowan <cowan@ccil.org>
of a creatific thinkerizer. =A0 =A0 =A0 =A0 =A0 =A0 http://www.ccil.org/~cowan
=A0 =A0--Peter da Silva



-- Website: http://hallambaker.com/<= br>
--001a1137f67c47322804f2cc538c-- From nobody Wed Feb 19 17:32:24 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1091A060C for ; Wed, 19 Feb 2014 17:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1I_6I3918_fp for ; Wed, 19 Feb 2014 17:32:21 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id CF1561A0423 for ; Wed, 19 Feb 2014 17:32:21 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.8.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9E39C509B5; Wed, 19 Feb 2014 20:32:12 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: Date: Thu, 20 Feb 2014 12:32:11 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <45357ADE-75B2-4D9D-AFEC-66B84E5D2320@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E1153B778363@WSMSG3153V.srv.dir.telstra.com> To: Tim Bray X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/json/8xa6Z7gmJ9993V9mVNXVkOd_4d4 Cc: "Manger, James" , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 01:32:24 -0000 +1 to the hm. ;) I wouldn't object if someone wanted to establish a WebIDL profile, etc., = or just refer to it in their spec. I would have a problem if we started requiring people to use it. Cheers, On 20 Feb 2014, at 11:24 am, Tim Bray wrote: > Hm, obvious when you think about it, since JSON=92s roots are in = JavaScript and JSON docs are parseable as such, a bagful of JS = assertions (yeah, I know JS doesn=92t have an =93assert=94 primitive, = but still) could be a not-terrible stand-in for a schema. Sort of = Schematron-like. >=20 >=20 > On Wed, Feb 19, 2014 at 4:18 PM, Manger, James = wrote: > One more example of an existing practice for describing JSON values = appears in recent draft specs from the FIDO Alliance = . It seems to be based = on Web IDL with ECMAScript bindings = . The following = example comes from fido-uaf-protocol-v1.0-rd-20140209.pdf: >=20 > dictionary Version { > int mj; // Mandatory. > int mn; // Mandatory. > } >=20 > dictionary OperationHeader { > Version upv; // Mandatory. > DOMString op; // Mandatory. Must be =93Reg=94, =93Auth=94 or =93Dereg=94= > DOMString appID; // Mandatory. string[1..512]. > DOMString serverData; // Optional, string[1..1536] > Extension[] exts; // Optional. > } >=20 > dictionary Extension { > DOMString id; // Mandatory. string[1..32]. > DOMString data; // Mandatory. base64url(byte[1..8192]). > boolean fail_if_unknown;// Mandatory. > } >=20 >=20 > I don=92t particularly like it; it doesn=92t feel like JSON (eg = "dictionary" vs "object"); constraints are all in comments; and IDL is = aimed at APIs as opposed to protocol messages. But it sort-of works: it = is fairly easy to guess what the JSON has to look like. >=20 > -- > James Manger > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From nobody Wed Feb 19 17:39:15 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B484C1A0610 for ; Wed, 19 Feb 2014 17:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 jk6x7hdEDbtq for ; Wed, 19 Feb 2014 17:39:12 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0C1A060C for ; Wed, 19 Feb 2014 17:39:12 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2A3EA508072 for ; Wed, 19 Feb 2014 17:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=52S7ZEXWOF853yMv8h3n 0UNx6yQ=; b=E3r1EGCsYQTvdLQb8SoxuSQTB4q1xgkT/26YczyLAXwG7d4XVyWV 1ElS1Agmy/1sf5x2wV7XjF0Mf8R5j870S3rQVeUlpoZufO7vfs0uXnhrHcZ03Fsz x2EubmjtbY1cHXK7hwRLbnsjytb+Cfrm2FO8mNUOpTbkGBKqg3FKhME= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id C3EDD508064 for ; Wed, 19 Feb 2014 17:39:08 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so976235wgh.19 for ; Wed, 19 Feb 2014 17:39:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9Nq95Zl7+z88K45oee5S/WoDnN9wK3hNoKy4py7BzdE=; b=jOP+9bByxyD2IJ6yXb0Fue998qUUFuMRyqFh/eym88/t19X61oCcO36K4V2KNMD8rk QwSSEyYBjdM+YMQ+G9TYF9zQo0CYmysB6602xXg3X2+LidU1x9XDrLqbzV5ut+orrf5+ MGfJYzBXMtrH5OU+axR25o0oNApCrA0pMWNevZOtH6B86pRysqsTXxulCbskwzHX6xZW 1wKrrBPfjOpm2jgonM07IWJe4KrH6wgxxM0CwU9LumG9kHjBpj725wC+k13WypJsHVdy cW6u0qnE3jqw7KXVWKIe5l3H2axS27bzsmkNH+RPENFNdtKXFoIsyv//3TtbZzQl04HR Kxdg== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr4387101wij.42.1392860347299; Wed, 19 Feb 2014 17:39:07 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 17:39:07 -0800 (PST) In-Reply-To: <45357ADE-75B2-4D9D-AFEC-66B84E5D2320@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E1153B778363@WSMSG3153V.srv.dir.telstra.com> <45357ADE-75B2-4D9D-AFEC-66B84E5D2320@mnot.net> Date: Wed, 19 Feb 2014 19:39:07 -0600 Message-ID: From: Nico Williams To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/WJvaowlpVJMuhq98ncgeEyXiP1w Cc: "Manger, James" , Tim Bray , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 01:39:13 -0000 On Wed, Feb 19, 2014 at 7:32 PM, Mark Nottingham wrote: > +1 to the hm. ;) > > I wouldn't object if someone wanted to establish a WebIDL profile, etc., or just refer to it in their spec. > > I would have a problem if we started requiring people to use it. Absolutely, there should be no requirement that people use it (or any alternative). I don't think anyone has proposed such a requirement. The only proposal is that the WG charter permit the WG to take on work items for schema documents. Nico -- From nobody Wed Feb 19 18:06:06 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03341A0636 for ; Wed, 19 Feb 2014 18:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 wF5SFvWUyIEY for ; Wed, 19 Feb 2014 18:05:59 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id C785D1A063A for ; Wed, 19 Feb 2014 18:05:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3DB8E5D3D27A; Wed, 19 Feb 2014 21:05:51 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWvA98MU4ril; Wed, 19 Feb 2014 21:05:50 -0500 (EST) Received: from [10.0.1.22] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id D7EF75D3D26F; Wed, 19 Feb 2014 21:05:49 -0500 (EST) Date: Wed, 19 Feb 2014 21:05:47 -0500 From: Cyrus Daboo To: Pete Cordell , Carsten Bormann , JSON WG Message-ID: In-Reply-To: <357740A8AA0F4316BE630917321FAB4D@codalogic> References: <357740A8AA0F4316BE630917321FAB4D@codalogic> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1091 Archived-At: http://mailarchive.ietf.org/arch/msg/json/QJ9h_kCA-c1xYSZ2gahZgLHyi3o Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 02:06:04 -0000 Hi Pete, --On February 19, 2014 at 10:29:32 PM +0000 Pete Cordell wrote: > I thought I'd throw down n gauntlet as a baseline for something to be > beat. So I started with something C like, and stole stuff from other > languages and came up with the following > Please take a look at Andrew Newton's spec (). I have used that in two specs of my own: Appendix B I found it to be easy to use and provide the necessary "commentary" for the JSON format chosen for those specs. I know several others who have implemented the timezone service protocol and we had no issues with interoperability related to the JSON format (beyond some poor text descriptions on my part). As Andrew noted earlier, his spec could probably be simplified some more - but we certainly don't need anything more complicated than what is there now. -- Cyrus Daboo From nobody Wed Feb 19 18:39:33 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4348D1A0627 for ; Wed, 19 Feb 2014 18:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 HePMgQw0k-3l for ; Wed, 19 Feb 2014 18:39:30 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3189D1A0636 for ; Wed, 19 Feb 2014 18:39:30 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so1257023pab.35 for ; Wed, 19 Feb 2014 18:39:26 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pbAwuKkmLmWN7CSDcil9xIKwoFclFXKgFfa9F6p9tQM=; b=BmrjhSQq3Rl6Cb36K3AOyohmWxCqtzENkm1KMkgYQ7xx9F07nA6A3tbFx5VSRgNSkx j+rMB2ccWyRtU1snlYXPIRkK6sswTH4KS7NBtohMkaRfvXWHcoXNCuf1F/bnrloHT8At on9T8oqWRxC2a5FvgmaM1jhTsPf+crQQW8JmlaNoS9W4nTDqVFYxaR3n4nHrYvZGaGKX DOALrTcsNa1K9Xd90rCWty2JB0atOb0c/y0gnyfs7Tsh6Ay0TsiaJuYN0rauGWfU65y8 JMo93LtFSo6VxUFyxHMQjDL6YY1N1XQSOBJZ2MggyIbUh0RwxOafKJYjTDvw2/lF08tV XVsw== X-Gm-Message-State: ALoCoQlU8uFadkjS6HOnaWfxmdssv6DoPcgQk9+ldbCfKKVV8nADoE/zpuhWE+yyyr99m87CSan0 MIME-Version: 1.0 X-Received: by 10.66.232.68 with SMTP id tm4mr6019870pac.114.1392863966891; Wed, 19 Feb 2014 18:39:26 -0800 (PST) Received: by 10.68.143.4 with HTTP; Wed, 19 Feb 2014 18:39:26 -0800 (PST) X-Originating-IP: [108.45.162.177] In-Reply-To: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> References: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> Date: Wed, 19 Feb 2014 21:39:26 -0500 Message-ID: From: Andrew Newton To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/t_uZp2DfFE772iIQZxGwAFYKz3w Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 02:39:32 -0000 I wouldn't mind 10 minutes to explain the motivations behind the JSON Content Rules draft, many of which parallel some of the excellent points that have been made in this thread. -andy On Mon, Feb 17, 2014 at 7:23 PM, Paul Hoffman wrote= : > It's been a week, and yet I can't imagine that everything has been said w= ith respect to our proposed charter item that now stands at: > > A set of natural-language terms and/or phrases for use in future speci= fications > that use JSON. This explicitly excludes schema languages and similar f= ormalisms. > > After that, a bunch of people started talking about formalisms and actual= schemas again. In order to get this decided, we need more discussion and t= hen agreement. To that end, and to put our 90 minutes on Friday afternoon i= n London to best use, I will ask for at least three people to present their= views in 10-minute presentations at the meeting. However, in order to caus= e this to not be the normal IETF "let's wait for the meeting" game, the pre= sentations need to be done by next Monday, Feb. 24. That gives people on th= e list a preview of what will be said, time to argue about it, and time for= the presenters to hone their slides if they want. > > Let me know online or offline if you want to do a presentation. If you're= not going to be at the meeting but want to say something, you need to find= some like-minded soul with whom to work on the presentation. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Wed Feb 19 19:11:32 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DE71A03CF for ; Wed, 19 Feb 2014 19:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 nlia1NkNfl9Y for ; Wed, 19 Feb 2014 19:11:29 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 25AF31A00F5 for ; Wed, 19 Feb 2014 19:11:29 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1K3BJ9I048586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Feb 2014 20:11:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Wed, 19 Feb 2014 19:11:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D584FB2-134A-4D0F-8636-4521CE7B7FA0@vpnc.org> To: Andrew Newton X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/json/9NcvI5OZZlcXeu1QzDQ2zl0Zmbc Cc: JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 03:11:30 -0000 On Feb 19, 2014, at 6:39 PM, Andrew Newton wrote: > I wouldn't mind 10 minutes to explain the motivations behind the JSON > Content Rules draft, many of which parallel some of the excellent > points that have been made in this thread. Excellent, thanks! This discussion is getting fairly wide-ranging, so = have one or two more short presentations in London might help people in = the room catch up with some of the high points. --Paul Hoffman= From nobody Thu Feb 20 05:02:50 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3291A014F for ; Thu, 20 Feb 2014 05:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 jYT6w8FaFlQc for ; Thu, 20 Feb 2014 05:02:45 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id AC5201A0155 for ; Thu, 20 Feb 2014 05:02:41 -0800 (PST) Received: (qmail 6067 invoked from network); 20 Feb 2014 13:01:23 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 13:01:21 +0000 Message-ID: <47BB9131737D42218A6382DEF45BBE2C@codalogic> From: "Pete Cordell" To: "Cyrus Daboo" , "Carsten Bormann" , "JSON WG" References: <357740A8AA0F4316BE630917321FAB4D@codalogic> X-Unsent: 1 Date: Thu, 20 Feb 2014 13:01:54 -0000 X-Vipre-Scanned: 00EA2BEF00682600EA2D3C MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/6NrKgLwnM9vcEFhBjaFGDAC0t08 Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 13:02:47 -0000 ----- Original Message From: "Cyrus Daboo" > Please take a look at Andrew Newton's spec > (). Thanks Cyrus. It certainly looks like another option. I would suggest that the authors could look at the following to improve it: - It doesn't seem to have much in the way of supporting modularity. It would be attractive if a schema could pull in and use definitions defined in other documents. Many IETF protocols consist of suites of components and support for that would be handy. - It doesn't seem to support third-party extensions to a core protocol. For example, HTTP and SIP are defined in a core RFC but there are then a number of additional RFC that define extensions. Support for expressing how a new extension can extend an existing external extension would be good. (Just about every schema language I've seen fails miserably at this!) - The plethora of data types are a problem for schema languages. I've come to the conclusion that the best option is to declare a "microformat" pseudo-type that basically says this is a string encoded in a particular way. The 'particular way' can then be defined in narrative form as required (80-20 etc). This avoids having to define the kitchen sink of data types up front. e.g.: struct Asset { GPSLocation location; }; microformat GPSLocation; // A GPSLocation is a pair of comma separated floating-point // numbers representing longitude and latitude. // e.g. "location": "0.0,51.5" - Does it allow multiple roots to be defined? Many protocols have request/response type pairs so it's nice to define a protocol that has the form: "request": {...} and "response": {...} Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Cyrus Daboo" To: "Pete Cordell" ; "Carsten Bormann" ; "JSON WG" Sent: Thursday, February 20, 2014 2:05 AM Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward > Hi Pete, > > --On February 19, 2014 at 10:29:32 PM +0000 Pete Cordell > wrote: > >> I thought I'd throw down n gauntlet as a baseline for something to be >> beat. So I started with something C like, and stole stuff from other >> languages and came up with the following >> > > Please take a look at Andrew Newton's spec > (). > > I have used that in two specs of my own: > > > > Appendix B > > I found it to be easy to use and provide the necessary "commentary" for > the JSON format chosen for those specs. I know several others who have > implemented the timezone service protocol and we had no issues with > interoperability related to the JSON format (beyond some poor text > descriptions on my part). > > As Andrew noted earlier, his spec could probably be simplified some more - > but we certainly don't need anything more complicated than what is there > now. > > -- > Cyrus Daboo > From nobody Thu Feb 20 06:36:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF1F1A016F for ; Thu, 20 Feb 2014 06:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 ZYp7Nx17dj2z for ; Thu, 20 Feb 2014 06:36:22 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 212791A0199 for ; Thu, 20 Feb 2014 06:36:21 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so1389938lan.12 for ; Thu, 20 Feb 2014 06:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c2Q+VjgGyAvNnEYk1I4HzWSNFmBtWefPXSptP+vhmBE=; b=RZgDzS7X+hAV2dH6BwcNCIsWrjhbOwkE0ztfFEyPiN4UbvbBg0nDjt6d8ELgbSJx74 sa2D9PMPCS3VE3bwyaDSAc3PVNNt2Sk8ScCIrMEHDYhrMFlZYKlJyc+m7c4U8dcQEbD2 7kDNaQXQQq2sO4eeBZrWPDa9CM4xr1/ePepZ5LwhQm0Jsp3EyoWS984gXgBMsA1m1UaO K5UgR3RkF/axu2GOZPX/gU7CU17ecl1Pq4RqwWx2xaAO6WcLuPUD9obHcbd7lXIC/eoW mvJGZmpD6/8YKv3k41qDNlDRLnLd3V8CgqBjc9edFb1EMWlu8/TfqcCSu0cy+CYX//xL 9AwA== MIME-Version: 1.0 X-Received: by 10.112.39.167 with SMTP id q7mr1278957lbk.82.1392906977704; Thu, 20 Feb 2014 06:36:17 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 20 Feb 2014 06:36:17 -0800 (PST) In-Reply-To: <47BB9131737D42218A6382DEF45BBE2C@codalogic> References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> Date: Thu, 20 Feb 2014 09:36:17 -0500 Message-ID: From: Phillip Hallam-Baker To: Pete Cordell Content-Type: multipart/alternative; boundary=001a1134d7ae9c7e7b04f2d76dfa Archived-At: http://mailarchive.ietf.org/arch/msg/json/FiGcMBQSDM6U4oE0xGAthau2Opg Cc: Cyrus Daboo , Carsten Bormann , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 14:36:26 -0000 --001a1134d7ae9c7e7b04f2d76dfa Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 8:01 AM, Pete Cordell wrote: > ----- Original Message From: "Cyrus Daboo" > > Please take a look at Andrew Newton's spec (> org/doc/draft-newton-json-content-rules/>). >> > > Thanks Cyrus. It certainly looks like another option. I would suggest > that the authors could look at the following to improve it: > > - It doesn't seem to have much in the way of supporting modularity. It > would be attractive if a schema could pull in and use definitions defined > in other documents. Many IETF protocols consist of suites of components > and support for that would be handy. > That is probably the right decision at this point. IETF has not decided how to make JSON protocols composable. We have JOSE but that may be a poor example because signature and encryption are wrappers rather than composition. JOSE does not actually encrypt JSON, it encrypts an octet stream that may contain JSON which is a different thing entirely. Now that might in part be due to lack of having a schema so it is not currently possible to say 'structure X from RFC9666 goes here'. But what does modularity look like? Is it importing structures defined in one spec into another? There are bad precedents here. QNames in XML exist in the ABNF but using them in schemas has some very odd and unexpected effects that we only discovered after trying to use them. It seems obvious that if you have then you can have attribute values but this requires the application to be aware of the namespace fiasco that is usually hidden from view in platforms like .NET etc. So just pointing to a syntactic production in another spec and making use of it may not be acceptable because there may be a subtle change in context. I certainly don't want anything as broken as XML Namespaces in JSON. Nor can I see a need for them. > - It doesn't seem to support third-party extensions to a core protocol. > For example, HTTP and SIP are defined in a core RFC but there are then a > number of additional RFC that define extensions. Support for expressing > how a new extension can extend an existing external extension would be > good. (Just about every schema language I've seen fails miserably at this!) > Also true and again this may be the right choice in this case. But remember than in JSON, every structure can be extended just by adding a tag. > - The plethora of data types are a problem for schema languages. I've > come to the conclusion that the best option is to declare a "microformat" > pseudo-type that basically says this is a string encoded in a particular > way. The 'particular way' can then be defined in narrative form as > required (80-20 etc). This avoids having to define the kitchen sink of > data types up front. e.g.: > I disagree, I don't think the schema should address sub-syntax at all except for a small number of encodings that are RFCs such as RFC3339 timestamps, URIs and DNS labels. > struct Asset > { > GPSLocation location; > }; > > microformat GPSLocation; > // A GPSLocation is a pair of comma separated floating-point > // numbers representing longitude and latitude. > // e.g. "location": "0.0,51.5" > These can and should be encoded in JSON: Structure GPSLocation Float X Float Y Message Foo GPSLocation location "location" : {"X" 0.0, "Y", 51.5} Parsing floating point numbers is complicated. I want that complexity to be in the JSON parser and nowhere else. Though this example is possibly a sign that decimal fractions should be an intrinsic type since we use decimal fractions in protocols but floats very rarely. Perhaps I will add a Decimal type to my schema that would map to a INT64 structure with a multiplier of 1,000,000,000. That would allow for numbers up to 17,000,000,000 with nine digits of decimal precision. They would map to JSON decimal fractions. When people reach for regular expressions it is almost always a sign that they are doing something that they should not. This is also a problem for my binary version of JSON (and I suspect CBOR). I added the binary float values to JSON-B because changing from binary to decimal fractions results in a loss of precision. Here we have a decimal fraction being forced to binary. This is a big problem for currency transactions and spatial coordinates. Right now the encoding scores are Microformat - 10 bytes JSON - 18 bytes JSON-C - 21 bytes The compressed JSON encoding actually requires more bytes because the only encoding for floats is Real64 (8bytes). And despite the number of bits we have a precision loss because of a decimal->binary fraction conversion. Adding a decimal fraction tag allows the number of bytes for each number to be reduced to 3 and the locations would only require 8 bytes each. Though this is very much a corner case, the text tags are short so we don't get any leverage from compression and real GPS coordinates would have far more decimal places. In most real world examples you are going to get far more leverage by sticking to only encoding in JSON data model and then finding an efficient way to encode JSON rather than inventing ad-hoc microformats that are neither JSON nor JSON data model, are going to require a custom parser and are not going to compress. -- Website: http://hallambaker.com/ --001a1134d7ae9c7e7b04f2d76dfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 8:01 AM, Pete Cordell <= ;petejson@codal= ogic.com> wrote:
----- Original Message From: "Cyrus Daboo"

Please take a look at Andrew Newton's spec (<ht= tps://datatracker.ietf.org/doc/draft-newton-json-content-rule= s/>).

Thanks Cyrus. =A0It certainly looks like another option. =A0I would suggest= that the authors could look at the following to improve it:

- It doesn't seem to have much in the way of supporting modularity. =A0= It would be attractive if a schema could pull in and use definitions define= d in other documents. =A0Many IETF protocols consist of suites of component= s and support for that would be handy.

That is probably the right decision at thi= s point.

IETF has not decided how to make JSON pro= tocols composable. We have JOSE but that may be a poor example because sign= ature and encryption are wrappers rather than composition. JOSE does not ac= tually encrypt JSON, it encrypts an octet stream that may contain JSON whic= h is a different thing entirely.

Now that might in part be due to lack of having a schem= a so it is not currently possible to say 'structure X from RFC9666 goes= here'.

But what does modularity look like? Is= it importing structures defined in one spec into another?

There are bad precedents here. QNames in XML exist in t= he ABNF but using them in schemas has some very odd and unexpected effects = that we only discovered after trying to use them. It seems obvious that if = you have <prefix:tag prefix2:attr=3D"foo"> then you can hav= e attribute values <tag attr=3D"prefix:foo"> but this requi= res the application to be aware of the namespace fiasco that is usually hid= den from view in platforms like .NET etc.

So just pointing to a syntactic production in another s= pec and making use of it may not be acceptable because there may be a subtl= e change in context.

I certainly don't want an= ything as broken as XML Namespaces in JSON. Nor can I see a need for them.<= /div>

=A0
- It doesn't seem to support third-party extensions to a core protocol.= =A0For example, HTTP and SIP are defined in a core RFC but there are then = a number of additional RFC that define extensions. =A0Support for expressin= g how a new extension can extend an existing external extension would be go= od. =A0(Just about every schema language I've seen fails miserably at t= his!)

Also true and again this may be the right = choice in this case.

But remember than in JSON, ev= ery structure can be extended just by adding a tag.=A0

=A0
- The plethora of data types are a problem for schema languages. =A0I'v= e come to the conclusion that the best option is to declare a "microfo= rmat" pseudo-type that basically says this is a string encoded in a pa= rticular way. =A0The 'particular way' can then be defined in narrat= ive form as required (80-20 etc). =A0This avoids having to define the kitch= en sink of data types up front. =A0e.g.:

I disagree, I don't think the schema s= hould address sub-syntax at all except for a small number of encodings that= are RFCs such as RFC3339 timestamps, URIs and DNS labels.


=A0
struct Asset
{
=A0 =A0GPSLocation location;
};

microformat GPSLocation;
=A0 =A0// A GPSLocation is a pair of comma separated floating-point
=A0 =A0// numbers representing longitude and latitude.
=A0 =A0// e.g. "location": "0.0,51.5"
<= div>
These can and should be encoded in JSON:

<= /div>
Structure GPSLocation
=A0 =A0 Float X
=A0 =A0= Float Y

Message Foo
=A0 =A0 GPSLocation location

"location" : {"X" 0.0, "Y&quo= t;, 51.5}

Parsing floating point numbers is compli= cated. I want that complexity to be in the JSON parser and nowhere else. Th= ough this example is possibly a sign that decimal fractions should be an in= trinsic type since we use decimal fractions in protocols but floats very ra= rely.

Perhaps I will add a Decimal type to my schema that wou= ld map to a INT64 structure with a multiplier of 1,000,000,000. That would = allow for numbers up to 17,000,000,000 with nine digits of decimal precisio= n. They would map to JSON decimal fractions.

When people reach for regular expressions it is almost = always a sign that they are doing something that they should not.


This is also a problem for my binary version= of JSON (and I suspect CBOR). I added the binary float values to JSON-B be= cause changing from binary to decimal fractions results in a loss of precis= ion. Here we have a decimal fraction being forced to binary. This is a big = problem for currency transactions and spatial coordinates.

Right= now the encoding scores are

Microformat - 10 bytes
JSON =A0 - 18 bytes
JSON-C =A0- 21 bytes

The compressed JSON encoding actu= ally requires more bytes because the only encoding for floats is Real64 (8b= ytes). And despite the number of bits we have a precision loss because of a= decimal->binary fraction conversion.

Adding a de= cimal fraction tag allows the number of bytes for each number to be reduced= to 3 and the locations would only require 8 bytes each. Though this is ver= y much a corner case, the text tags are short so we don't get any lever= age from compression and real GPS coordinates would have far more decimal p= laces.

In most rea= l world examples you are going to get far more leverage by sticking to only= encoding in JSON data model and then finding an efficient way to encode JS= ON rather than inventing ad-hoc microformats that are neither JSON nor JSON= data model, are going to require a custom parser and are not going to comp= ress.


-= -
Website: http://hallambaker.com/<= /a>
--001a1134d7ae9c7e7b04f2d76dfa-- From nobody Thu Feb 20 06:53:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723F91A01E4 for ; Thu, 20 Feb 2014 06:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 Ol5Nib_Jru4J for ; Thu, 20 Feb 2014 06:53:02 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 81C471A01E5 for ; Thu, 20 Feb 2014 06:52:55 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WGUzZ-0004tA-IS; Thu, 20 Feb 2014 09:52:49 -0500 Date: Thu, 20 Feb 2014 09:52:49 -0500 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20140220145249.GB11488@mercury.ccil.org> References: <20140219163059.GA18485@mercury.ccil.org> <20140219200609.GB8132@mercury.ccil.org> <20140219230449.GB12169@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/oO16-3-Lny3qeCXtLduC89Rizf0 Cc: Nico Williams , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 14:53:10 -0000 Phillip Hallam-Baker scripsit: > Interpreting those namespaces correctly requires a huge amount of > complex logic that is completely unnecessary. That is untrue (just to vary myself a bit). > Since we had Eve Maler on the TC, I think we were doing the XML schema > right the second time round... Well, your snippet of an *instance* document contains a declaration of the XSD *schema* namespace, which makes no sense whatever. I don't know who wrote that instance (which appears in Wikipedia and elsewhere), but I doubt it was Eve. > If XML Schema had been better designed the namespaces would never > appear on the wire Namespaces long predated XML Schema. > Though since the post had no content other than 'oh no it isn't' the > poster might have had a different idea. My point was that you were defending an argument I consider to be incorrect using claims that any XML Schema user (certainly including Eve) would certainly know were false, but which the present audience might not recognize as such. I am not attacking JSON or defending XML Schema. I'm attacking the claim of "semantic-first" designs to be the obviously Right Thing. Indeed, XML Schema itself is a magnificent example of just such a semantics-first design, with the result that it is damned hard for mere mortals to decipher actual schemas without tools. -- John Cowan http://ccil.org/~cowan cowan@ccil.org 'My young friend, if you do not now, immediately and instantly, pull as hard as ever you can, it is my opinion that your acquaintance in the large-pattern leather ulster' (and by this he meant the Crocodile) 'will jerk you into yonder limpid stream before you can say Jack Robinson.' --the Bi-Coloured-Python-Rock-Snake From nobody Thu Feb 20 07:23:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B1E1A01C0 for ; Thu, 20 Feb 2014 07:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 UnLnIkNhZz5T for ; Thu, 20 Feb 2014 07:22:59 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4AE1A01B3 for ; Thu, 20 Feb 2014 07:22:58 -0800 (PST) Received: (qmail 30039 invoked from network); 20 Feb 2014 15:22:14 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 15:22:14 +0000 Message-ID: From: "Pete Cordell" To: "Phillip Hallam-Baker" References: <357740A8AA0F4316BE630917321FAB4D@codalogic><47BB9131737D42218A6382DEF45BBE2C@codalogic> X-Unsent: 1 X-Vipre-Scanned: 016B397900682A016B3AC6 Date: Thu, 20 Feb 2014 15:22:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/E28bm9hRRd0_o4PfTsPT7W1VcfU Cc: Cyrus Daboo , Carsten Bormann , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 15:23:03 -0000 ----- Original Message From: "Phillip Hallam-Baker" >> Thanks Cyrus. It certainly looks like another option. I would suggest >> that the authors could look at the following to improve it: >> >> - It doesn't seem to have much in the way of supporting modularity. It >> would be attractive if a schema could pull in and use definitions defined >> in other documents. Many IETF protocols consist of suites of components >> and support for that would be handy. >> > > That is probably the right decision at this point. I'm not sure what "That" refers to here. > IETF has not decided how to make JSON protocols composable. Isn't that why we're here? > We have JOSE > but that may be a poor example because signature and encryption are > wrappers rather than composition. JOSE does not actually encrypt JSON, it > encrypts an octet stream that may contain JSON which is a different thing > entirely. > > Now that might in part be due to lack of having a schema so it is not > currently possible to say 'structure X from RFC9666 goes here'. > > But what does modularity look like? Is it importing structures defined in > one spec into another? > > There are bad precedents here. QNames in XML exist in the ABNF but using > them in schemas has some very odd and unexpected effects that we only > discovered after trying to use them. It seems obvious that if you have > then you can have attribute values attr="prefix:foo"> but this requires the application to be aware of the > namespace fiasco that is usually hidden from view in platforms like .NET > etc. Yes, QNames are broken, so don't do that. Think more packages in Java, namespaces in C#. As simple as doing something like: int port; com.ietf.sip.contact contact; yields JSON of: "port": 25, "contact": "...whatever..." We don't have to make things complicated! > So just pointing to a syntactic production in another spec and making use > of it may not be acceptable because there may be a subtle change in > context. > > I certainly don't want anything as broken as XML Namespaces in JSON. Nor > can I see a need for them. Be assured that XML Namespaces are irrelevant to the discussion. >> - It doesn't seem to support third-party extensions to a core protocol. >> For example, HTTP and SIP are defined in a core RFC but there are then a >> number of additional RFC that define extensions. Support for expressing >> how a new extension can extend an existing external extension would be >> good. (Just about every schema language I've seen fails miserably at >> this!) >> > > Also true and again this may be the right choice in this case. > > But remember than in JSON, every structure can be extended just by adding > a > tag. Yes. The question is, how do we exploit that in the schema language? >> - The plethora of data types are a problem for schema languages. I've >> come to the conclusion that the best option is to declare a "microformat" >> pseudo-type that basically says this is a string encoded in a particular >> way. The 'particular way' can then be defined in narrative form as >> required (80-20 etc). This avoids having to define the kitchen sink of >> data types up front. e.g.: >> > > I disagree, I don't think the schema should address sub-syntax at all > except for a small number of encodings that are RFCs such as RFC3339 > timestamps, URIs and DNS labels. > > > > >> struct Asset >> { >> GPSLocation location; >> }; >> >> microformat GPSLocation; >> // A GPSLocation is a pair of comma separated floating-point >> // numbers representing longitude and latitude. >> // e.g. "location": "0.0,51.5" >> > > These can and should be encoded in JSON: > > Structure GPSLocation > Float X > Float Y > > Message Foo > GPSLocation location > > "location" : {"X" 0.0, "Y", 51.5} I disagree with this. Dates alone illustrate that there are 'microformats' that can result in a much more compact, meaningful and useful format than say: { "date": 25, "month": 12, "year": 2015, "hour": 12, "min": 0 } Another location format might be: 56°14'23.45"N,18°5'16.65"W Forcing such formats to be JSONified may cause as much error as forcing IEEE 754 numbers to be decimalised. So let's learn from the past and recognise that we can't build them all in upfront and design our format accordingly. > Parsing floating point numbers is complicated. I want that complexity to > be > in the JSON parser and nowhere else. Though this example is possibly a > sign > that decimal fractions should be an intrinsic type since we use decimal > fractions in protocols but floats very rarely. > > Perhaps I will add a Decimal type to my schema that would map to a INT64 > structure with a multiplier of 1,000,000,000. That would allow for numbers > up to 17,000,000,000 with nine digits of decimal precision. They would map > to JSON decimal fractions. > > When people reach for regular expressions it is almost always a sign that > they are doing something that they should not. > > > This is also a problem for my binary version of JSON (and I suspect CBOR). > I added the binary float values to JSON-B because changing from binary to > decimal fractions results in a loss of precision. Here we have a decimal > fraction being forced to binary. This is a big problem for currency > transactions and spatial coordinates. > > Right now the encoding scores are > > Microformat - 10 bytes > JSON - 18 bytes > JSON-C - 21 bytes > > The compressed JSON encoding actually requires more bytes because the only > encoding for floats is Real64 (8bytes). And despite the number of bits we > have a precision loss because of a decimal->binary fraction conversion. > > Adding a decimal fraction tag allows the number of bytes for each number > to > be reduced to 3 and the locations would only require 8 bytes each. Though > this is very much a corner case, the text tags are short so we don't get > any leverage from compression and real GPS coordinates would have far more > decimal places. > > In most real world examples you are going to get far more leverage by > sticking to only encoding in JSON data model and then finding an efficient > way to encode JSON rather than inventing ad-hoc microformats that are > neither JSON nor JSON data model, are going to require a custom parser and > are not going to compress. I'm not interested in compression beyond zip and co. It may sound harsh of me, but my feeling is if this or the errors in floating point numbers is critical to you, then use something else. We don't need something that is all things, to all people. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Thu Feb 20 08:06:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35D11A01EF for ; Thu, 20 Feb 2014 08:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 odBTIk9cr8wT for ; Thu, 20 Feb 2014 08:06:30 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 101B01A01DA for ; Thu, 20 Feb 2014 08:06:29 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id b8so1473970lan.19 for ; Thu, 20 Feb 2014 08:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YzBMCZg9Cln0Fe9Gyzt8Lpa9jUNlHA5hToZ2cyezWgY=; b=kyOcSNXbEK28c9KFGvP/du1GeWtjaITwVhi2e1Ob+2wqwbTWNvKOcjxfK2r1L94tuu EM1OM9XVUPlwiGI3l5pfeiBK60hDTdjNwnWLz415EVRj6s/rpv5ycDGNRPpFBPcCSKke W3StKgW9PV/YpRBJAefHHWU46g75aPCPvsBxjW451TrqzlX1SYlnjmt/71yBupLMpGV5 dnjLBldDuK3T7Uoh86AGgXlgq5/Hs4+q6oGdLXp2RHcuJmVa1COSDvcEmF5HacmAnBsM MCcafRmhUDmSl+d4ikugu6MJya8HiamKwImCGjmsg8LmAFW1t06Nxlgc9/zOSi6URAEk Jj7A== MIME-Version: 1.0 X-Received: by 10.112.138.233 with SMTP id qt9mr1578460lbb.34.1392912385711; Thu, 20 Feb 2014 08:06:25 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 20 Feb 2014 08:06:25 -0800 (PST) In-Reply-To: References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> Date: Thu, 20 Feb 2014 11:06:25 -0500 Message-ID: From: Phillip Hallam-Baker To: Pete Cordell Content-Type: multipart/alternative; boundary=089e01229710f4243804f2d8afe0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/FpJli4Mv0PJAa2dm8HG1_25ufFA Cc: Cyrus Daboo , Carsten Bormann , JSON WG Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 16:06:33 -0000 --089e01229710f4243804f2d8afe0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (trimmed) On Thu, Feb 20, 2014 at 10:22 AM, Pete Cordell wrot= e: > ----- Original Message From: "Phillip Hallam-Baker" > > > IETF has not decided how to make JSON protocols composable. >> > > Isn't that why we're here? It is why the group is here. But my point is that the group should decide how to compose protocols and the people developing schemas should support those tropes that are chosen. So it is a separate problem. If people decide on how to do this, I will be happy to extend my tool. But I don't think how this problem is solved should be a way to decide between tools. Yes, QNames are broken, so don't do that. Think more packages in Java, > namespaces in C#. As simple as doing something like: > > int port; > com.ietf.sip.contact contact; > > yields JSON of: > > "port": 25, "contact": "...whatever..." > > We don't have to make things complicated! That is a model that I could very easily support as my tool is written in C#. In fact it already supports that kind of type label. All I would have to do is add in 'Using' specifiers at the top. The only thing it doesn't support are those semicolons. I find a carriage return is enough. Incidentally, this is what I meant when I said that discussion of the schema ideas and merger might be more useful than more proposals. > I disagree, I don't think the schema should address sub-syntax at all >> except for a small number of encodings that are RFCs such as RFC3339 >> timestamps, URIs and DNS labels > > > I disagree with this. Dates alone illustrate that there are > 'microformats' that can result in a much more compact, meaningful and > useful format than say: > > { "date": 25, "month": 12, "year": 2015, "hour": 12, "min": 0 } > But we already have an RFC for Date - RFC 3339. (Actually we have others but we will forget those). So this is one of the microformats that I define in the tool as intrinsic. This also allows for the use of Integer encodings for DateTimes using seconds since the start of some epoch. > Another location format might be: > > 56=B014'23.45"N,18=B05'16.65"W > { [56,14,23,45], [-18,-5,-16,-65]} Forcing such formats to be JSONified may cause as much error as forcing > IEEE 754 numbers to be decimalised. > It is certainly possible to do the job wrong but the above does not result in any loss of precision. The only case where I would feel comfortable with the microformat above is if the protocol was interfacing to some application where that format was already defined and translation between the formats would be needed. So let's learn from the past and recognise that we can't build them all in > upfront and design our format accordingly. There may be a need for a microformat. But that should be rare and should probably be specified in ABNF rather than the JSON schema. In most real world examples you are going to get far more leverage by >> sticking to only encoding in JSON data model and then finding an efficie= nt >> way to encode JSON rather than inventing ad-hoc microformats that are >> neither JSON nor JSON data model, are going to require a custom parser a= nd >> are not going to compress. >> > > I'm not interested in compression beyond zip and co. It may sound harsh > of me, but my feeling is if this or the errors in floating point numbers = is > critical to you, then use something else. We don't need something that i= s > all things, to all people. If someone is saying 'I only want text, space isn't important' then fine, just use text. But if someone is saying 'lets use JSON but then lets avoid making it too verbose using these microformats to shave a few bytes' then I would much prefer to just use an efficient encoding. Unless dealing with text documents, LZ compression of an inefficient encoding is not as effective as an efficient encoding in the first place. If the threat of a binary encoding causes someone to withdraw an ad-hoc microformat then its done its job... --=20 Website: http://hallambaker.com/ --089e01229710f4243804f2d8afe0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(trimmed)


On Thu, Feb 20, 2014 at 10:22 AM, Pete Cordell <pe= tejson@codalogic.com> wrote:
----- Original Message From: "Phillip H= allam-Baker"


IETF has not decided how to make JSON protocols composable.

Isn't that why we're here?

It is wh= y the group is here. But my point is that the group should decide how to co= mpose protocols and the people developing schemas should support those trop= es that are chosen.=A0

So it is a separate problem. If people decide on how to= do this, I will be happy to extend my tool. But I don't think how this= problem is solved should be a way to decide between tools.

Yes, QNames are broken= , so don't do that. =A0Think more packages in Java, namespaces in C#. = =A0As simple as doing something like:

=A0 =A0int port;
=A0 =A0com.ietf.sip.contact contact;

yields JSON of:

=A0 =A0"port": 25, "contact": "...whatever..."= ;

We don't have to make things complicated!

That is a model that I could very easily support as my tool is written i= n C#. In fact it already supports that kind of type label. All I would have= to do is add in 'Using' specifiers at the top.

The only thing it doesn't support are those semicol= ons. I find a carriage return is enough.

Incidenta= lly, this is what I meant when I said that discussion of the schema ideas a= nd merger might be more useful than more proposals.
=A0
I disagree, I don't think the schema should address sub-syntax at all except for a small number of encodings that are RFCs such as RFC3339
timestamps, URIs and DNS labels

=A0
I disagree with this. =A0Dates alone illustrate that there are 'microfo= rmats' that can result in a much more compact, meaningful and useful fo= rmat than say:

=A0 =A0{ "date": 25, "month": 12, "year": 201= 5, "hour": 12, "min": 0 }

But we already have an RFC for Date - RFC 3339. (Actually we have ot= hers but we will forget those).

So this is one of the microformats that I define in the= tool as intrinsic. This also allows for the use of Integer encodings for D= ateTimes using seconds since the start of some epoch.

=A0
Another location format might be:

=A0 =A056=B014'23.45"N,18=B05'16.65"W

{ [56,14,23,45], [-18,-5,-16,-65]}

Forcing such formats to be JSONified may cause as much error as forcing IEE= E 754 numbers to be decimalised.

It is = certainly possible to do the job wrong but the above does not result in any= loss of precision.

The only case where I would feel comfortable with the m= icroformat above is if the protocol was interfacing to some application whe= re that format was already defined and translation between the formats woul= d be needed.


So let's learn from the past and recognise that we can't build them= all in upfront and design our format accordingly.

There may be a need for a microformat. But that should be rare and = should probably be specified in ABNF rather than the JSON schema.

In most real world examples you are going to get far more leverage by
sticking to only encoding in JSON data model and then finding an efficient<= br> way to encode JSON rather than inventing ad-hoc microformats that are
neither JSON nor JSON data model, are going to require a custom parser and<= br> are not going to compress.

I'm not interested in compression beyond zip and co. =A0It may sound ha= rsh of me, but my feeling is if this or the errors in floating point number= s is critical to you, then use something else. =A0We don't need somethi= ng that is all things, to all people.

If someone is saying 'I only want text, space= isn't important' then fine, just use text.

But if someone is saying 'lets use JSON but then lets avoid making it= too verbose using these microformats to shave a few bytes' then I woul= d much prefer to just use an efficient encoding.

Unless dealing with text documents, LZ compression of a= n inefficient encoding is not as effective as an efficient encoding in the = first place.=A0

If the threat of a binary encoding= causes someone to withdraw an ad-hoc microformat then its done its job...<= /div>

--
Website: http://h= allambaker.com/
--089e01229710f4243804f2d8afe0-- From nobody Thu Feb 20 08:55:27 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA361A0212 for ; Thu, 20 Feb 2014 08:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.994 X-Spam-Level: *** X-Spam-Status: No, score=3.994 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=no 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 DGgWLw1mojuq for ; Thu, 20 Feb 2014 08:55:22 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id CDC131A0205 for ; Thu, 20 Feb 2014 08:55:21 -0800 (PST) Received: (qmail 22663 invoked from network); 20 Feb 2014 16:54:35 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 16:54:35 +0000 Message-ID: From: "Pete Cordell" To: "Phillip Hallam-Baker" References: <357740A8AA0F4316BE630917321FAB4D@codalogic><47BB9131737D42218A6382DEF45BBE2C@codalogic> X-Unsent: 1 X-Vipre-Scanned: 01BF98E600682C01BF9A33 Date: Thu, 20 Feb 2014 16:55:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/YtFvpz7xUwp16suaJnkOibvtWFA Cc: Carsten Bormann , JSON WG Subject: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 16:55:25 -0000 ----- Original Message From: "Phillip Hallam-Baker" > On Thu, Feb 20, 2014 at 10:22 AM, Pete Cordell > wrote: > >> ----- Original Message From: "Phillip Hallam-Baker" >> >> >> IETF has not decided how to make JSON protocols composable. >>> >> >> Isn't that why we're here? > > > It is why the group is here. But my point is that the group should decide > how to compose protocols and the people developing schemas should support > those tropes that are chosen. > > So it is a separate problem. If people decide on how to do this, I will be > happy to extend my tool. But I don't think how this problem is solved > should be a way to decide between tools. As it's framed at the moment, nobody has to decide between tools (at least not in the JSON working group). > Yes, QNames are broken, so don't do that. Think more packages in Java, >> namespaces in C#. As simple as doing something like: >> >> int port; >> com.ietf.sip.contact contact; >> >> yields JSON of: >> >> "port": 25, "contact": "...whatever..." >> >> We don't have to make things complicated! > > > That is a model that I could very easily support as my tool is written in > C#. In fact it already supports that kind of type label. All I would have > to do is add in 'Using' specifiers at the top. > > The only thing it doesn't support are those semicolons. I find a carriage > return is enough. The details of how it's done are not important right now. I only presented an example syntax as a way of illustrating what I'm proposing. > Incidentally, this is what I meant when I said that discussion of the > schema ideas and merger might be more useful than more proposals. > > >> I disagree, I don't think the schema should address sub-syntax at all >>> except for a small number of encodings that are RFCs such as RFC3339 >>> timestamps, URIs and DNS labels >> >> > > >> I disagree with this. Dates alone illustrate that there are >> 'microformats' that can result in a much more compact, meaningful and >> useful format than say: >> >> { "date": 25, "month": 12, "year": 2015, "hour": 12, "min": 0 } >> > > But we already have an RFC for Date - RFC 3339. (Actually we have others > but we will forget those). > > So this is one of the microformats that I define in the tool as intrinsic. > This also allows for the use of Integer encodings for DateTimes using > seconds since the start of some epoch. My position is that, having recognised that Dates represent a case where microformats are useful, perhaps we should not assume that these are the only cases. IP addresses? Crypto OIDs? Dates on Mars? >> Another location format might be: >> >> 56°14'23.45"N,18°5'16.65"W >> > > { [56,14,23,45], [-18,-5,-16,-65]} > > Forcing such formats to be JSONified may cause as much error as forcing >> IEEE 754 numbers to be decimalised. >> > > It is certainly possible to do the job wrong but the above does not result > in any loss of precision. > > The only case where I would feel comfortable with the microformat above is > if the protocol was interfacing to some application where that format was > already defined and translation between the formats would be needed. Exactly. That's the use-case - where the format is already standard for the domain in question. > So let's learn from the past and recognise that we can't build them all in >> upfront and design our format accordingly. > > > There may be a need for a microformat. But that should be rare and should > probably be specified in ABNF rather than the JSON schema. Exactly. It's saying there's something special here that is beyond my (the JSON schema's) ability to define. It's also admitting that it's a rare case and the JSON schema doesn't want to be able to define it. However, just because it doesn't want to do it, doesn't mean it wants to prevent you from defining something if it's useful to you. EBNF with narrative in an RFC would be a suitable way to define it's format. > In most real world examples you are going to get far more leverage by >>> sticking to only encoding in JSON data model and then finding an >>> efficient >>> way to encode JSON rather than inventing ad-hoc microformats that are >>> neither JSON nor JSON data model, are going to require a custom parser >>> and >>> are not going to compress. >>> >> >> I'm not interested in compression beyond zip and co. It may sound harsh >> of me, but my feeling is if this or the errors in floating point numbers >> is >> critical to you, then use something else. We don't need something that >> is >> all things, to all people. > > > If someone is saying 'I only want text, space isn't important' then fine, > just use text. > > But if someone is saying 'lets use JSON but then lets avoid making it too > verbose using these microformats to shave a few bytes' then I would much > prefer to just use an efficient encoding. Microformats are nothing to do with minimising byte count. They are about representing data in a natural form for the application domain. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Thu Feb 20 09:03:21 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0FA1A021E for ; Thu, 20 Feb 2014 09:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 lLQ2L_Xeuw6S for ; Thu, 20 Feb 2014 09:03:14 -0800 (PST) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5FA1A01EE for ; Thu, 20 Feb 2014 09:03:13 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id m10so788872eaj.5 for ; Thu, 20 Feb 2014 09:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JbzMUy8wZFfDrIG6998yh0dSzvB+3I49kgZa/tGH3Vs=; b=dZKeR1snW+Ww3Bl1ta2UE/T5tNgpXhviCJvGQBXS5E3lAo9xLq2Konajs+1lBKBSNx h+XlwR7bijuXO1qiBYHpH4SYdws0HfupHHnykFLKMtK2oyMppnnO3BGyhCYg6H5FWRZx Uxwn3BYrLnjbNH0omIPO3e74ODlbYU6qXEXCaclG31qS7aatj5ddGRLjHelWdziT9tUm XuFWaYLVGTlDGSJRyxeCB73n9eVqR6sa+Cq/N27KFRk4+RR1Nz9ExS+bz5o1ZWYmJbod YwC1KHUM0h0Hp7tDKrXTqxvcMq/7utu7FX9HFlohUzSbkVEZ7KbtjZHONZQRzMN9SWsY 2/1A== MIME-Version: 1.0 X-Received: by 10.15.82.193 with SMTP id a41mr3041416eez.110.1392915789587; Thu, 20 Feb 2014 09:03:09 -0800 (PST) Received: by 10.14.223.132 with HTTP; Thu, 20 Feb 2014 09:03:09 -0800 (PST) Date: Thu, 20 Feb 2014 18:03:09 +0100 Message-ID: From: Francis Galiegue To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/tL_7knoRqB10n0ZQwZAAQZ2eBVI Subject: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:03:19 -0000 Hello, Something makes me really uneasy when I read these two documents side by side. RFC 4627bis (even though only a draft at the moment), section 4, reads: "When the names within an object are not unique, the behavior of software that receives such an object is unpredictable". RFC 6902, section 4, reads: "Operation objects MUST have exactly one "op" member". The latter makes sense on the _producer_ of a patch operation; however, on the parser side, should a parser receive a "malformed" (f.e duplicated "op") operation, it seems to me that RFC 6902 expects the parser to raise an error -- which RFC 4627bis does not mandate. What are your thoughts? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nobody Thu Feb 20 09:23:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB92B1A0222 for ; Thu, 20 Feb 2014 09:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 OKYQhsvZYfx6 for ; Thu, 20 Feb 2014 09:23:24 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id D2FEE1A021B for ; Thu, 20 Feb 2014 09:23:23 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id 10so1505134lbg.22 for ; Thu, 20 Feb 2014 09:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CpaqKoavXoxjmfbpNNAg6Sn0cRyBxBAs62SoH5aSfP8=; b=ngMtb0h7TdXIhHX9HHacdZLbwtFmOR0VUt9A0nFGZAJLKbmidmqluQ7eKavP61DASJ mXTxlJTY4uQ1xQIKiQnTRRLt41LPPjpurPU7RyTzre0UMUDuFrW+yVl1uV9brgZU/1/U /G59x6df1IZLE3jp9zcq0G0ZZMTf4KCMWz4iVevgXC+IXt5rLieaK/MUIhqYS2FlClFg Xg+aqbPBWOVf4i9wnSm5mPUIXj7IGOfevdAkIGuqt+x4H/zSLs8ygZg7/ts1b6P9fqd0 spYO76g3SFrEpd+bVLI2o2NSEVeTM9uAxwJ/HXbVCQ30n1C2Dwapp/u2Wzzo81p2dbBC i5PA== MIME-Version: 1.0 X-Received: by 10.112.129.168 with SMTP id nx8mr1718423lbb.37.1392916999470; Thu, 20 Feb 2014 09:23:19 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 20 Feb 2014 09:23:19 -0800 (PST) In-Reply-To: References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> Date: Thu, 20 Feb 2014 12:23:19 -0500 Message-ID: From: Phillip Hallam-Baker To: Pete Cordell Content-Type: multipart/alternative; boundary=047d7b343d68f4854d04f2d9c204 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ibQ1ysI9bSLK226edlZ5lvYECvI Cc: Carsten Bormann , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:23:27 -0000 --047d7b343d68f4854d04f2d9c204 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 11:55 AM, Pete Cordell wrote: > My position is that, having recognised that Dates represent a case where > microformats are useful, perhaps we should not assume that these are the > only cases. IP addresses? Crypto OIDs? Dates on Mars? > All I am saying is that it is a slippery slope. There are two ways to go down a slippery slope, not at all or on skis. Skis: I will add a new type, 'Format ' that declares a string with the named sub-format which can be documented elsewhere in ABNF. This also solves my 50 shades of yuck problem trying to parse HTTP headers with all the mindboggling syntax baroqueness. Sometimes a label has quotes, sometimes not, sometimes angle braces. There is no logic at all just like there is no logic to the choice of attributes or elements in XML2RFC format. Exactly. It's saying there's something special here that is beyond my (the > JSON schema's) ability to define. It's also admitting that it's a rare > case and the JSON schema doesn't want to be able to define it. However, > just because it doesn't want to do it, doesn't mean it wants to prevent you > from defining something if it's useful to you. EBNF with narrative in an > RFC would be a suitable way to define it's format. > Or a reference to some other spec where it was predefined. That would also provide a way to deal with enumerations which I have currently punted on. -- Website: http://hallambaker.com/ --047d7b343d68f4854d04f2d9c204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 11:55 AM, Pete Cordell <petejson@codalogic.com> wrote:
My position is that, having recognised that = Dates represent a case where microformats are useful, perhaps we should not= assume that these are the only cases. =A0IP addresses? =A0Crypto OIDs? =A0= Dates on Mars?

All I am saying is that it is a slippery s= lope.

There are two ways to go down a slippery slo= pe, not at all or on skis.

Skis: I will add a new = type, 'Format <Name>' that declares a string with the named s= ub-format which can be documented elsewhere in ABNF.


This also solves my 50 shades of y= uck problem trying to parse HTTP headers with all the mindboggling syntax b= aroqueness. Sometimes a label has quotes, sometimes not, sometimes angle br= aces. There is no logic at all just like there is no logic to the choice of= attributes or elements in XML2RFC format.


Exactly. =A0It= 's saying there's something special here that is beyond my (the JSO= N schema's) ability to define. =A0It's also admitting that it's= a rare case and the JSON schema doesn't want to be able to define it. = =A0However, just because it doesn't want to do it, doesn't mean it = wants to prevent you from defining something if it's useful to you. =A0= EBNF with narrative in an RFC would be a suitable way to define it's fo= rmat.

Or a reference to some other spec where it= was predefined.



--
Website: http://hallambaker.com/
--047d7b343d68f4854d04f2d9c204-- From nobody Thu Feb 20 09:28:51 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7121A025E for ; Thu, 20 Feb 2014 09:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 GVSfoHaLUH_y for ; Thu, 20 Feb 2014 09:28:48 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D92C1A0252 for ; Thu, 20 Feb 2014 09:28:48 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id B10392AC07A for ; Thu, 20 Feb 2014 09:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3KWUvowvE7IsRnzMt2Tl tbaQrLM=; b=FqoSPtAsX3iGOiEi8v3JTBco68HQyLh74vNie22/nXgS30VPNOvH eilhhw1WqK6LY/ERPKrUEm3lP4Q0xVu6+gtDMfl4S9GI6tsXpymnmsMfftMw3obQ ICQ71ggmThclDktx358HD3bgvEqfBKDH/A1hbMlIsoY80qOa/OBOnng= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 34FD82AC079 for ; Thu, 20 Feb 2014 09:28:43 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id t61so1726876wes.36 for ; Thu, 20 Feb 2014 09:28:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QCpVaRRIevoM1nZF0SZvMU8Q0715HohjdMXShhhtvsM=; b=GLpvZtywarPMgvEVcSznm77jz/0txDJxpOgpyFOMJaAvxUJjzDIY22VKNKbAkqP9ui xcBxSQXzEJj6kwRcUihRpa2+riankpk19gEOZrXrguPrlUbhFF9a/uf4r10+wabg1L3w bB4J2hFUC47vIZ25586Ewxe00MN45LkO7TOz8AtNsIRqkl/ThDZ7eoz6BVmwBAKo+g5b 99c2AA8E4c13ceBhTYpQuP50JXaYAPO0rE0vsErc2dWwCX8erh+9Gq1MrdCDhDytKOWh s2THc7DyJ5Qh6VdAg8ZLdRxscKe2/ZqOHZqOkLKJ/0+Qp6l+XvCLHdNFVQjm/gAwtHac BY9Q== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr8135016wib.39.1392916932524; Thu, 20 Feb 2014 09:22:12 -0800 (PST) Received: by 10.217.108.132 with HTTP; Thu, 20 Feb 2014 09:22:12 -0800 (PST) In-Reply-To: References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> Date: Thu, 20 Feb 2014 11:22:12 -0600 Message-ID: From: Nico Williams To: Pete Cordell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/YVhx-iwCMjqa9PVUOS6wLTbXPnI Cc: Carsten Bormann , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:28:50 -0000 On Thu, Feb 20, 2014 at 10:55 AM, Pete Cordell wrote: > My position is that, having recognised that Dates represent a case where > microformats are useful, perhaps we should not assume that these are the > only cases. IP addresses? Crypto OIDs? Dates on Mars? There are two ways to deal with alternative representations: - convert to/from a canonical representation and use that one for interchange - use a discriminated union (XDR) / CHOICE (ASN.1, same thing) I think any decent schema will need to allow for the latter, and not just because of types that have multiple possible representations. As for the former, it's always an option, schema or not. And it's more efficient to have receiver-makes-right in this case (dates & timestamps), though that does require having a fixed set of representations that can be sent, else a negotiation would be required. This seems obvious enough that we shouldn't dwell on it. The real question is: which schema(s) should we be copying/learning from? So far the answer seems to be down to: - Schematron - RelaxNG compact - Web IDL I think that's a fine starting point. If you want to talk about requirements, I think we should consider things like: - which grammar parsing algorithms we want to support: LR, LALR(1), LALR(k), GLR, ... - the basic metaphor: - types! (a-la ASN.1, only without the tags, no IOS, ...) - pattern matching rules! (something like collections of XPath-like expressions) - something else The metaphor thing gets to, in part, the purpose of the schema: - documentation for sure, validation no doubt, but, code generation (into C, Java, JS, C#, ...)? (IMO: yes) Finally: - extensibility (meta: to have it or not; if yes, how) - modularity (meta: to have it or not; if yes, how) Oh, and: - one schema language, or more? (IMO: inevitably we'll end up with more) I may have missed some things. But I think that's a decent set of attributes from which to start a schema requirements discussion. Nico -- From nobody Thu Feb 20 09:31:14 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9D81A025D for ; Thu, 20 Feb 2014 09:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 j-RmL-Br04_e for ; Thu, 20 Feb 2014 09:31:10 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B96221A0252 for ; Thu, 20 Feb 2014 09:31:10 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id if11so2117560vcb.22 for ; Thu, 20 Feb 2014 09:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XMwoBb9T//p5JCC8QwHKWPiKzxm6JSAHR69cLxNYLzA=; b=I6BsiHw3FD02efD4JJuTdos+Id69T1es+FZ/0uM2Cb8oT0UnhIj5yggcvHO0bM0V8H EJkf3zs5l6K9YDASK9VI1mqjy2MtCnDfY1Nu7GcWywQDAzY45/GiyTr0YnCyHEv0udIu WYoNlDLbGatVOxL/uxHMz/vXcvZE+lvqvcVpch+Xo9fc0uSWqbzB04sMopHHRKovClPY uadySGcHulI9kWh5kDxaZxtuRZrZv/M0zcgmJIz7K34/NMHRhGaQzBmLCVC+1du/8BEf wIOtSyCDfeSEJSApmpf6HrnR//TZY5Ry3XAHKtqyxZ+YHME15dUyShsnyMzPcVnrFove jJgg== MIME-Version: 1.0 X-Received: by 10.52.246.227 with SMTP id xz3mr1391596vdc.95.1392917466977; Thu, 20 Feb 2014 09:31:06 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.19.104 with HTTP; Thu, 20 Feb 2014 09:31:06 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 12:31:06 -0500 X-Google-Sender-Auth: 5QcOXAWoLygQMyLq7v1s6zLUShk Message-ID: From: Barry Leiba To: Francis Galiegue Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/json/hfuqXQcFz0zu6KTGvujbv1b63b8 Cc: "json@ietf.org" Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:31:12 -0000 > The latter makes sense on the _producer_ of a patch operation; > however, on the parser side, should a parser receive a "malformed" > (f.e duplicated "op") operation, it seems to me that RFC 6902 expects > the parser to raise an error -- which RFC 4627bis does not mandate. What do you see as a conflict? The JSON spec gives general parameters for JSON, and allows duplicates. The JSON Patch spec gives specific parameters for a specific use of JSON. For that use, duplicates are not allowed. That all looks just fine to me, and absolutely consistent. Barry From nobody Thu Feb 20 09:36:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABD81A0047 for ; Thu, 20 Feb 2014 09:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 fU75w_vzRzf0 for ; Thu, 20 Feb 2014 09:36:01 -0800 (PST) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9913A1A0074 for ; Thu, 20 Feb 2014 09:36:01 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id h10so1064024eak.0 for ; Thu, 20 Feb 2014 09:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3mwsAsZU3bnNHUSmNsl2hDxLCccplScJHiw1/IPzg08=; b=nf6z0V/MXDfv3DmqioP6CUq8O9G8cXOG0NshgjfAMhnXve5n/dgcfWkcw0dAqL+kri Sr00tHoT2X1MPSJwIDzqjpJTPYvnvJphnk9zLk+gndk5+o2rBIHNFd3olS/WMO37alDb 63gMtYgh3clxTzC5xDDc8xviqO9deaEraUOpfftATI8cYNxpjqDlzrYlz7smnQGwYLYC gv0IPv4NOWH9e0dh6NEGO+S+I0FpKPiy6EwX95oYQ1mrSc4WRBOPPJMUo8C7Bw9VMUsz xMLxwQtO5ESLNQdKAHVDdJbRpnGsJluBllmKXBOh0nCHI9mfwIz/Pd1VVhy/EQxvbYQm +Jyg== MIME-Version: 1.0 X-Received: by 10.15.93.203 with SMTP id w51mr3180104eez.33.1392917757529; Thu, 20 Feb 2014 09:35:57 -0800 (PST) Received: by 10.14.223.132 with HTTP; Thu, 20 Feb 2014 09:35:57 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 18:35:57 +0100 Message-ID: From: Francis Galiegue To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/xevKGVJGpXiVlPpgoY3Bt-DDlHk Cc: "json@ietf.org" Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:36:04 -0000 On Thu, Feb 20, 2014 at 6:31 PM, Barry Leiba wrote: >> The latter makes sense on the _producer_ of a patch operation; >> however, on the parser side, should a parser receive a "malformed" >> (f.e duplicated "op") operation, it seems to me that RFC 6902 expects >> the parser to raise an error -- which RFC 4627bis does not mandate. > > What do you see as a conflict? > > The JSON spec gives general parameters for JSON, and allows duplicates. > > The JSON Patch spec gives specific parameters for a specific use of > JSON. For that use, duplicates are not allowed. > > That all looks just fine to me, and absolutely consistent. > Not to me. As I see it, 75+% of JSON parsers on the "market" just cannot parse JSON Patch correctly because of the restrictions imposed by RFC 6902. Note: parse, not emit (or "consume, not produce" -- or whatever metaphor suits you). IOW: I don't see "MUST have a unique member named 'foo'" and "behaviour is unpredictable" as being consistent with one another. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nobody Thu Feb 20 09:44:43 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7961A0053 for ; Thu, 20 Feb 2014 09:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 rC9zt1FvgUcW for ; Thu, 20 Feb 2014 09:44:40 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2672E1A01AF for ; Thu, 20 Feb 2014 09:44:40 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id B19682F4075 for ; Thu, 20 Feb 2014 09:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UysC+H3MAshMARjT5uq8 3mGeV/U=; b=MzX1LpcJRMwH8dMz2eTj+QQULAY2QQs8gpGSiktEWRsXKHOCh99e l3wA1yDVHueS1nVR4Kt+hEaAyz9G8447cqyAlDR84khz7i5hZx0G4626zUGgSPcg +ptSiDKVwGeFpRK9XWk9C2zKcb+HA9NjWNJYtJYuOZQUEH7obIIX5JM= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 57B7E2F406D for ; Thu, 20 Feb 2014 09:44:36 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so1673497wes.26 for ; Thu, 20 Feb 2014 09:44:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C1AGKpVjzEFodxtJHIm82OOim0HIP185IYAcucajlGY=; b=eKkBlSO/qsIeoyb7B18EgS7FbxxMkE7cquG7EZbrbcyNI2gCOrsQkbOnoi1IglMOZ8 yDKP7qVHwYiC6wdVd9j4OOHgfGkHPDTr1NRoWjGOc4E6Fv06rRuVCZdQ992pGfRcazCi VdSWhVeQrFpbTKaotzhsDYH+0xlYg3YXUJYr7nWsnCQ0r1wtRsObYgFs94YLnAMGYNaR q2WUG63ztmA7vjvE1WXk6GYta3bdcC1B0yeWs+V+lSge8rFXEoCtmMtA3/gDrdWLhoSE d7ad5tiooOrl3cQYRsGrsKFBC3bDPXvIFkBXeknw18H1Ji29Ea+gmoXXW15hzT7SpVNC BAiQ== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr8225665wib.39.1392918274992; Thu, 20 Feb 2014 09:44:34 -0800 (PST) Received: by 10.217.108.132 with HTTP; Thu, 20 Feb 2014 09:44:34 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 11:44:34 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ZImRIp5k-4K3WqJ0V-fgJUeJ9hE Cc: Barry Leiba , "json@ietf.org" Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:44:41 -0000 On Thu, Feb 20, 2014 at 11:35 AM, Francis Galiegue wrote: > On Thu, Feb 20, 2014 at 6:31 PM, Barry Leiba wrote: >>> The latter makes sense on the _producer_ of a patch operation; >>> however, on the parser side, should a parser receive a "malformed" >>> (f.e duplicated "op") operation, it seems to me that RFC 6902 expects >>> the parser to raise an error -- which RFC 4627bis does not mandate. >> >> What do you see as a conflict? >> >> The JSON spec gives general parameters for JSON, and allows duplicates. >> >> The JSON Patch spec gives specific parameters for a specific use of >> JSON. For that use, duplicates are not allowed. >> >> That all looks just fine to me, and absolutely consistent. >> > > Not to me. As I see it, 75+% of JSON parsers on the "market" just > cannot parse JSON Patch correctly because of the restrictions imposed > by RFC 6902. Note: parse, not emit (or "consume, not produce" -- or > whatever metaphor suits you). JSON Patch predates the discussions as to RFC4627bis, so a bit of mismatch is to be expected. JSON Patch says "objects MUST have exactly one ..." but parser behavior is not specified, so it's unclear if that's a requirement for encoders or parsers. Even if you interpret that as a requirement for parsers, the requirement may be met by the application rather than the parser (e.g., when the application uses an online JSON parser). We had very many very lengthy threads on subjects like this in the JSON WG, and I'm pretty sure that we discussed JSON Patch in particular as well. You might want to look at the archives. > IOW: I don't see "MUST have a unique member named 'foo'" and > "behaviour is unpredictable" as being consistent with one another. The former is insufficiently prescriptive, therefore ill-defined, therefore consistent with the latter. FWIW, the JSON WG had proposals to improve this and other aspects of JSON, but it was heavily constrained by _actual_ practice in the wild. Nico -- From nobody Thu Feb 20 09:51:03 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB091A023E for ; Thu, 20 Feb 2014 09:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 sRnDmp-2NfO8 for ; Thu, 20 Feb 2014 09:50:55 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0401A0235 for ; Thu, 20 Feb 2014 09:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1KHomLV001416; Thu, 20 Feb 2014 18:50:49 +0100 (CET) Received: from [192.168.217.106] (p54891BBF.dip0.t-ipconnect.de [84.137.27.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2241C365; Thu, 20 Feb 2014 18:50:47 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: Date: Thu, 20 Feb 2014 18:50:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C987A55-8D98-469F-A35A-6CC4D73F79FA@tzi.org> References: To: Francis Galiegue X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/json/6vx964Dk6r1bJ4eCeVhQIRNkjo4 Cc: Barry Leiba , "json@ietf.org" Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:50:56 -0000 On 20 Feb 2014, at 18:35, Francis Galiegue wrote: > Not to me. As I see it, 75+% of JSON parsers on the "market" just > cannot parse JSON Patch correctly because of the restrictions imposed > by RFC 6902. Note: parse, not emit (or "consume, not produce" -- or > whatever metaphor suits you). =93cannot parse=94? I don=92t think so. I think what you are trying to achieve is =93reliably detect and reject = input that causes unpredictable behavior=94. This is a quality-of-implementation expectation for a parser that is = often traded for performance, and rightly so. Instead, the behavior is indeed unpredictable, just as the specification = says. I=92m with Barry on this one: This is completely consistent. (Except that I wouldn=92t summarize 4627bis as =93allows duplicate = keys=94. =20 Sure, it also =93allows" hitting yourself on the head with a hammer. But here, it explicitly warns that its sole objective, interoperability, = is not achievable if you do that.) Gr=FC=DFe, Carsten From nobody Thu Feb 20 09:52:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DED1A0053 for ; Thu, 20 Feb 2014 09:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 4oo9KhtK5ugm for ; Thu, 20 Feb 2014 09:52:10 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AF9041A021D for ; Thu, 20 Feb 2014 09:52:08 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 36E7C5407C for ; Thu, 20 Feb 2014 09:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=o6Xzxl/BLjYtSbukdLJG FfPOMuQ=; b=sT9iJYCN3beTae6qKFQaE0fKvYLOyWYtxyc0aE5R4MGp1ybGTfVA UFnYl6X4q05OMr3rK4qDU9rNnqiOEWADoudTNXoWCsnZPLU1t8Ygapj+k6d8u8h6 JlfgNrVDg0ACodyWkm+uwGvnaNyG6f1gk+OWpcj4oJD9ZR8AsQ7QZjo= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id DD4615407A for ; Thu, 20 Feb 2014 09:52:04 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id y10so1706602wgg.4 for ; Thu, 20 Feb 2014 09:52:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hFydLdH/MDOayLOsav7eAUnOpEKkCtm8WUlRZR5rxgk=; b=CjF7bymaSnqHhe/X+uDFMkENNCaCM6pkkPAvlDKdF9scaRUYw98w40rVFVY2P+OkdZ WQ0xpHxs+NRPplIQCuQZm8BqymwOBl/l/p35VQ4I2w8iiA2s0N90YPiwt0La8n4vd46Q L3cLvCCRt+oMGODRpf6qS65BHcM2snInJFxo7QFhjOyiT6qoLJApg/XTGFWCtIWCJPGC Ha7QRzVBaOxQ15a/+7nRDzrutZcrt0a/fStDfFGpUpcSqMZVv9qEP6Q0opQChHa/BYZB jasp1PPenbBSbKQxQGJghoXUpyyO8AHzaD9FyHJly5ZFsevcEgzIqMmB+wHIXLZCCPlu cKFQ== MIME-Version: 1.0 X-Received: by 10.194.104.39 with SMTP id gb7mr3221395wjb.69.1392918723491; Thu, 20 Feb 2014 09:52:03 -0800 (PST) Received: by 10.217.108.132 with HTTP; Thu, 20 Feb 2014 09:52:03 -0800 (PST) In-Reply-To: References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> Date: Thu, 20 Feb 2014 11:52:03 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/OE0wZ1UX4kLFqzpc3WmDZDuGnhE Cc: Carsten Bormann , Pete Cordell , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 17:52:11 -0000 On Thu, Feb 20, 2014 at 11:23 AM, Phillip Hallam-Baker wrote: > On Thu, Feb 20, 2014 at 11:55 AM, Pete Cordell > wrote: >> My position is that, having recognised that Dates represent a case where >> microformats are useful, perhaps we should not assume that these are the >> only cases. IP addresses? Crypto OIDs? Dates on Mars? > > All I am saying is that it is a slippery slope. > > There are two ways to go down a slippery slope, not at all or on skis. This sounds to me like an argument about how to handle extensibility. We should first consider whether we want schema extensibility and if we do, whether we want it to be explicit (like the ... extensibility marker in ASN.1) or implicit (like implicit ... ASN.1 extensibility markers in every type). My position: we should want extensibility, and it should be explicit (because having every type be implicitly extensible is a PITA for code generation). Nico -- From nobody Thu Feb 20 10:19:33 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8771E1A0053 for ; Thu, 20 Feb 2014 10:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 9r4zN1NIF6Ur for ; Thu, 20 Feb 2014 10:19:29 -0800 (PST) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9911A0047 for ; Thu, 20 Feb 2014 10:19:29 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id c41so256707eek.39 for ; Thu, 20 Feb 2014 10:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mu6ulQVWZh+kboxPY3ToKygVbZLTLy3mQUn0pyHsEdc=; b=YtRenY9vDKtIHxHzVY+9OENTUNkcMRAQFmhaoqta0iKUKK8vsaoL4qSCQ3iv2fsHzi Oo5YiqQNKs4Gtc+J0lHpR/OJWfwm7nNw5KqFnsoxs+BvF++xowfnb7FOfPe0oPEXBO+j dq5+4UINgNnMrdusVJ2hEaPO9YqpPW871taeH7JYt2id5o3C9Vb0A/NCozYad1iutQn0 1mQM1FupxTOexC7JNRJFPC1LmDzf3rScSSk+w/ilQ5gsm7tEME6KSy75Mb2iJan6HyhT J42V7tVLuaFlSZ4agt+VKD0cBOQMaZ7Cavue/k8IrqpbIXywlHZNc488tC8c8EscHrCW bGYw== MIME-Version: 1.0 X-Received: by 10.15.56.130 with SMTP id y2mr3405204eew.17.1392920365198; Thu, 20 Feb 2014 10:19:25 -0800 (PST) Received: by 10.14.223.132 with HTTP; Thu, 20 Feb 2014 10:19:25 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 19:19:25 +0100 Message-ID: From: Francis Galiegue To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/RhRGsrV0mguOfP6KA85wPHlJBmo Subject: [Json] Fwd: RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 18:19:31 -0000 Sorry, user error, didn't find its way to the list ---------- Forwarded message ---------- From: Francis Galiegue Date: Thu, Feb 20, 2014 at 7:17 PM Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) To: Nico Williams On Thu, Feb 20, 2014 at 6:36 PM, Nico Williams wrote: [...] >> >> What are your thoughts? > > I don't see the conflict. > > FYI, text in RFC4627bis was arrived at after very many and lengthy > (well over 1,000 posts) threads on the JSON WG list. I'd summarize > the part about duplicate names as: > > The nature of JSON as it is used in the wild is such that RFC4627bis > couldn't require any specific parser behavior as to duplicate names -- > the canonical example is online parsers, whose very purpose is to keep > minimal state while parsing, which means that they can't detect > duplicate names, which means that specific parser behavior regarding > duplicate names could not be REQUIRED. (There was also a question of > whether specific behavior could be required of the parser _and_ > application together, and the conclusion was also "no".) > OK, then what about constraints on JSON emission instead? RFC 4627bis section 10 does mention that any emitted JSON must be conform to the grammar; can't a condition be added that in the case of JSON objects, they SHOULD ensure about the uniqueness of member names? Admittely, I can live with the texts as they currently stands; it is just that this shadowy area leaves an acrid aftertaste in my mouth, that's all ;) -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nobody Thu Feb 20 10:31:08 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DD21A0224 for ; Thu, 20 Feb 2014 10:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 UjsT2gGpgLRd for ; Thu, 20 Feb 2014 10:31:04 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 044A31A01AF for ; Thu, 20 Feb 2014 10:31:03 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id hr13so1604675lab.29 for ; Thu, 20 Feb 2014 10:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0q+hzyTzJBWKUHJQ+VizAjrUnzfX+bZt5eJ2JwneFMc=; b=rZjvFjyxD4roBCaXumoH1HBWCsyQ5WkREJ2NepK1288Kn4Pv165ZGRL9UW2ltE7Ijp jSNi6azSxqDaceFisGev2vqNsdeIcraWeFW1uurzXsNQ2+B/bFxsG+QiYgWfre8PZR8b F66Ee0ntpDejIuGBWdpXxyzoGdq81szOyCB/XJ+1O/UPQn4N5xfb86wI9HGMUahD8JH7 BfXbnE59Bumsv5lVicn/kKJjpYTUhlxZmGW6DVBh5kv8fRc46EoReHKdQSQPD3/CVC7m g+jrdW5oMP21Ve+4qCTkkioMexXixC2N4CN4rBvphJGqeCeV1+WaWzKppaQ5SqkXkbcf EUnw== MIME-Version: 1.0 X-Received: by 10.152.203.193 with SMTP id ks1mr2085669lac.0.1392921059573; Thu, 20 Feb 2014 10:30:59 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 20 Feb 2014 10:30:59 -0800 (PST) In-Reply-To: References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> Date: Thu, 20 Feb 2014 13:30:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a113470d2f4ce3f04f2dab481 Archived-At: http://mailarchive.ietf.org/arch/msg/json/kfELKdN3qXfFB2lMkwN_xPP_brA Cc: Carsten Bormann , Pete Cordell , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 18:31:07 -0000 --001a113470d2f4ce3f04f2dab481 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 12:22 PM, Nico Williams wrote: > On Thu, Feb 20, 2014 at 10:55 AM, Pete Cordell > wrote: > > My position is that, having recognised that Dates represent a case where > > microformats are useful, perhaps we should not assume that these are the > > only cases. IP addresses? Crypto OIDs? Dates on Mars? > > There are two ways to deal with alternative representations: > > - convert to/from a canonical representation and use that one for > interchange > - use a discriminated union (XDR) / CHOICE (ASN.1, same thing) > > I think any decent schema will need to allow for the latter, and not > just because of types that have multiple possible representations. > In the code as it is right now it is possible to specify different formats as different tags: ConvolutedTime Structure DateTime Date Format RFC1123 Date1 Format RFC822 Date2 Would allow for any of the following: {"Date":"2002-10-02T10:00:00Z"} {"Date1":"Thursday, 20 Feb 2014 18:14:16 GMT"} {"Date2":"Thu, 20 Feb 2014 18:14:16 GMT"} What I don't support at the moment is a constraint that says that only one of the "Date", "Date1" and "Date2" tags is permitted. This could be specified as: ConvolutedTime Choice DateTime Date Format RFC1123 Date1 Format RFC822 Date2 [Protogen does allow braces to be used instead of indentation to denote blocks but does not need end of statement or statement separators. If people really insist on semicolons I can add a production to the lexer so they are just treated like whitespace.] - which grammar parsing algorithms we want to support: LR, LALR(1), > LALR(k), GLR, ... > I would hope we make the syntax so simple that we don't need the power of LR parsers. They are models of human languages rather than computer languages. > - the basic metaphor: > - types! (a-la ASN.1, only without the tags, no IOS, ...) > - pattern matching rules! (something like collections of > XPath-like expressions) > - something else > Since the target languages are likely to be C#, JS and Java, I suggest that we use dot separated tags and array indexes as path extractors. Given: {"first" : {"second" : {"third" : [{ "fourth": 1}, { "fourth": 42}, { "fourth": 666}]}}} first.second.third[1].fourth = 42 > The metaphor thing gets to, in part, the purpose of the schema: > > - documentation for sure, validation no doubt, but, code generation > (into C, Java, JS, C#, ...)? (IMO: yes) > I have code generation for C# and C. I can add Java without difficulty. It is not clear to me that code generation is necessary or particularly useful for scripting languages with late binding like JS. In those situations you can just say X = JSON_Parse (text) Answer = first.second.third[1].fourth > Finally: > > - extensibility (meta: to have it or not; if yes, how) > Hopefully formats are enough. - modularity (meta: to have it or not; if yes, how) > I am adding a Using directive right now. It seems to do the trick. > Oh, and: > > - one schema language, or more? (IMO: inevitably we'll end up with more) > There will be multiple schemas. I think the progression will work like it did for JSON itself. People will choose the one they like and there will eventually be a convergence. -- Website: http://hallambaker.com/ --001a113470d2f4ce3f04f2dab481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 12:22 PM, Nico Williams &= lt;nico@cryptone= ctor.com> wrote:
On Thu, Feb 20, 2014 at 10:55 AM, Pete Cor= dell <petejson@codalogic.com> wrote:
> My position is that, having recognised that Dates represent a case whe= re
> microformats are useful, perhaps we should not assume that these are t= he
> only cases. =A0IP addresses? =A0Crypto OIDs? =A0Dates on Mars?

There are two ways to deal with alternative representations:

=A0- convert to/from a canonical representation and use that one for interc= hange
=A0- use a discriminated union (XDR) / CHOICE (ASN.1, same thing)

I think any decent schema will need to allow for the latter, and not
just because of types that have multiple possible representations.

In the code as it is right now it is possible t= o specify different formats as different tags:

ConvolutedTime Structure
=A0 =A0 DateTime =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0Date
=A0 =A0 Format RFC1123 =A0 =A0 Date1
=A0 = =A0 Format RFC822 =A0 =A0 =A0 Date2

Would allow fo= r any of the following:
=A0 =A0 {"Date":"2002-10-02T10:00:00Z"}
=A0 =A0 {"Date1":"<= span style=3D"line-height:14.654545783996582px">Thursday, 20 Feb 2014 18:14= :16 GMT"}
=A0 =A0 {"Date2":"Thu, 20 Feb 2014 18:1= 4:16 GMT"}

What I don't support at the moment is a constraint = that says that only one of the "Date", "Date1" and &quo= t;Date2" tags is permitted. This could be specified as:

ConvolutedTime Choice
=A0 =A0 DateTime =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Date
=A0 =A0 Format RFC1123 =A0 =A0 Da= te1
=A0 =A0 Format RFC822 =A0 =A0 =A0 Date2
=A0
[Protogen does allow braces to be used instead of indentation to d= enote blocks but does not need end of statement or statement separators. If= people really insist on semicolons I can add a production to the lexer so = they are just treated like whitespace.]

=A0- which grammar parsing algorithms we wa= nt to support: LR, LALR(1),
LALR(k), GLR, ...

I would hope we make = the syntax so simple that we don't need the power of LR parsers. They a= re models of human languages rather than computer languages.

=A0
=A0- the basic metaphor:
=A0 =A0 - types! (a-la ASN.1, only without the tags, no IOS, ...)
=A0 =A0 - pattern matching rules! (something like collections of
XPath-like expressions)
=A0 =A0 - something else

Since the targ= et languages are likely to be C#, JS and Java, I suggest that we use dot se= parated tags and array indexes as path extractors.

Given:

{"first" : {"second" : = {"third" : [{ "fourth": 1}, { "fourth": 42}, = { "fourth": 666}]}}}

first.second.third[= 1].fourth =3D 42

=A0
The metaphor thing gets to, in part, the purpose of the schema:

=A0- documentation for sure, validation no doubt, but, code generation
(into C, Java, JS, C#, ...)? =A0(IMO: yes)

<= div>I have code generation for C# and C. I can add Java without difficulty.=


X =3D JSON_Parse (text)

Answer= =3D first.second.third[1].fourth

=A0
Finally:

=A0- extensibility (meta: to have it or not; if yes, how)
<= div>
=A0- modularity (meta: to have it or not; if yes, how)


Oh, and:

=A0- one schema language, or more? =A0(IMO: inevitably we'll end up wit= h more)

There wi= ll be multiple schemas. I think the progression will work like it did for J= SON itself. People will choose the one they like and there will eventually = be a convergence.

--
Website: http://h= allambaker.com/
--001a113470d2f4ce3f04f2dab481-- From nobody Thu Feb 20 10:37:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49361A022D for ; Thu, 20 Feb 2014 10:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 YY0s7JTEWxck for ; Thu, 20 Feb 2014 10:37:09 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id F08871A019F for ; Thu, 20 Feb 2014 10:37:08 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 1D2E83B80A8 for ; Thu, 20 Feb 2014 10:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=e3f4+jFxUb2V20BFCTvw KIapWF0=; b=nDmvzenxuhdDYv1vX+p7geWFl3gRIg9vvZZoBcngp7fI1dzcAePI GOPBsU/pjmSBccLUA9szB6tj2xGr2/KQ8WrGbFmQPgxTwovillNWcIKco5cDYVeB 4QrqxJq75vasyn8nufN25wBnX7ezWmIBmbDAMga6FyrlpeAF7PG0oLg= Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 2CBB53B8099 for ; Thu, 20 Feb 2014 10:31:05 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id hz1so2243354pad.36 for ; Thu, 20 Feb 2014 10:30:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vCMZm5GEfzkbGs9gy5rRBhRD4zvwMYeljhtlasfEjsU=; b=MG/wCJ68JNf4o8/NWn0/Ud/6BZPMPu17M2vglWSqBa0tpsltoGFcbFoHG25yH1RtyW 57wIRyeyez1NgimGPZrAsMPOVpQsmJlsJ4/9Ahn5QheV5ZnFVLRX5WncXHv2woT9gjuj 8/ZXSzRv7IzVz82ZlgCZw27W58+nex2feS/o5Ks5yh+un5aMAu1XaPhCnJ+3mxvPWhpu hqAMHO680K5Mb3qdR3ihr0ohGTMIBayoibh6qRKISkiR8XQNyf6OA6Ppb2jGwaKB5jfd xOzFYgQ9iIeDgv0yF1eyDsMir2MBb6au84gINNvnjb03b6jvxIceIgpHA+CSBf+kzJqZ o1Cg== MIME-Version: 1.0 X-Received: by 10.69.19.139 with SMTP id gu11mr3692402pbd.149.1392921037340; Thu, 20 Feb 2014 10:30:37 -0800 (PST) Received: by 10.68.36.164 with HTTP; Thu, 20 Feb 2014 10:30:37 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 12:30:37 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/MNVSejnp8L-_HKamfAuMhCcplUY Cc: "json@ietf.org" Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 18:37:11 -0000 On Thu, Feb 20, 2014 at 12:17 PM, Francis Galiegue wrote: > OK, then what about constraints on JSON emission instead? RFC 4627bis > section 10 does mention that any emitted JSON must be conform to the > grammar; can't a condition be added that in the case of JSON objects, > they SHOULD ensure about the uniqueness of member names? The same issues apply here. For example, online encoders by definition don't keep sufficient state. Also, the > Admittely, I can live with the texts as they currently stands; it is > just that this shadowy area leaves an acrid aftertaste in my mouth, > that's all ;) If you even skim the list archives you'll find you're not alone. You'll also find why RFC4627bis had to end up the way it did. Nico -- From nobody Thu Feb 20 10:38:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FB41A0232 for ; Thu, 20 Feb 2014 10:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 aoDPlqv5znGb for ; Thu, 20 Feb 2014 10:38:55 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id AEFEC1A019F for ; Thu, 20 Feb 2014 10:38:55 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id D697521DE83 for ; Thu, 20 Feb 2014 10:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pB6kMzM0S0twO3e898dS 0Zn7KCM=; b=k0DEQgjSezLrxmlRYHzyC1InHcAU4ntpk33xbXe/KtA/xIG5p0ry wSmaXEawf13WnXLDqhLbbRDT+edFuXo+IKADAxAH7mVUrqOUHibS4gurnRXbeSFw BaOG6YiY0RU3VnctVHlhgkDtP9aXwuCVixRr+CP/2Ftg5l6NnQyteQc= Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id D350521DE71 for ; Thu, 20 Feb 2014 10:38:24 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp16so2273606pbb.20 for ; Thu, 20 Feb 2014 10:38:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f8vnFPVCYW+fbn1lFDODBaesO+vT+7c4JIJCawpSU54=; b=NVcFayvXXkSL4tiZc86KBIzf4M28QhiUWejskEpwoMmm/Ft35F//wr7vsGjE+3TjjU fHUIALXqZwPzPUK9TKBHtV2iMcUUqbsmbRMl/xfeonbF9gg7kuHWXCsPsMKw/FAII8gv UgTtPyZhfyDbI/nD4HZoVeXtFDCtRyf+/0QmMgWTyOklya+R3kGFR6ihEabSD0/htq1i BoWhftu4DfHCI5IMQ/Vy5xA9uvxS5jCR9fa2YWn9su/NYMtpssKni9axa04oWN7fokmr rBuT0TO4HT9BU3Sw56hGJa8tDu0WwXnsD41fvC92Ls84FdprqOX2MWWPcL+MuUH08yfY cpwg== MIME-Version: 1.0 X-Received: by 10.68.242.68 with SMTP id wo4mr3980752pbc.32.1392921503461; Thu, 20 Feb 2014 10:38:23 -0800 (PST) Received: by 10.68.36.164 with HTTP; Thu, 20 Feb 2014 10:38:23 -0800 (PST) In-Reply-To: References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> Date: Thu, 20 Feb 2014 12:38:23 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/o2TbW4ZW6_yDXHw24e0750L6TBc Cc: Carsten Bormann , Pete Cordell , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 18:38:57 -0000 On Thu, Feb 20, 2014 at 12:30 PM, Phillip Hallam-Baker wrote: > On Thu, Feb 20, 2014 at 12:22 PM, Nico Williams > wrote: >> - which grammar parsing algorithms we want to support: LR, LALR(1), >> LALR(k), GLR, ... > > I would hope we make the syntax so simple that we don't need the power of LR > parsers. They are models of human languages rather than computer languages. Oops, I meant left recursive, not LR. Apologies for the thinko. > Since the target languages are likely to be C#, JS and Java, I suggest that > we use dot separated tags and array indexes as path extractors. > > Given: > > {"first" : {"second" : {"third" : [{ "fourth": 1}, { "fourth": 42}, { > "fourth": 666}]}}} > > first.second.third[1].fourth = 42 Sure, where rules need to be expressed, using something XPath-like for expressing paths would be nice. >> The metaphor thing gets to, in part, the purpose of the schema: >> >> - documentation for sure, validation no doubt, but, code generation >> (into C, Java, JS, C#, ...)? (IMO: yes) > > I have code generation for C# and C. I can add Java without difficulty. > > It is not clear to me that code generation is necessary or particularly > useful for scripting languages with late binding like JS. In those > situations you can just say For them the important thing may be to have XPath-like facilities. >> Finally: >> >> - extensibility (meta: to have it or not; if yes, how) > > Hopefully formats are enough. I'm not sure what you mean. >> - modularity (meta: to have it or not; if yes, how) > > I am adding a Using directive right now. It seems to do the trick. What about namespacing? Nico -- From nobody Thu Feb 20 11:14:18 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6B1A0243 for ; Thu, 20 Feb 2014 11:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no 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 1OdgzgcfoLv5 for ; Thu, 20 Feb 2014 11:14:16 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 19A591A0249 for ; Thu, 20 Feb 2014 11:14:13 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b15so1162635eek.29 for ; Thu, 20 Feb 2014 11:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lEZBoudCdam8MMd3d/gHfj8Sn3AkdesL+9fpV3E66hk=; b=gR4Lq/arrLfBWGe6kW+iYhHDTw/qKM38shpBO9jPyBj9z5BxDK9AX/gNcvJ/YW0Z92 0iJFE+l0T5PfDSSuKAxTSjQYVsP/oaoG3403m883oG8Xz5R6/iwJ+ha3TxZbo9p/bIOC D1bghb0r6iQKTiYJlwQTO42GDJ/YGoiJe8nkJxY7q7z+Ov6+zPeQaUNfDZNGZSBw403M M9xqqwzCzI7AvcQCwotrtNl5r2b1RFZbNYlrJspx5llRPZEMBB9zxHBYRFE0b4gWeaNe csIu3197cYZGUOqbsForHwX5Rxyt0NGB54Pff31r0A1ZhA0QUiLfvi8vVTEvM+TKj9/9 EGlQ== MIME-Version: 1.0 X-Received: by 10.15.56.130 with SMTP id y2mr3671680eew.17.1392923649986; Thu, 20 Feb 2014 11:14:09 -0800 (PST) Received: by 10.14.223.132 with HTTP; Thu, 20 Feb 2014 11:14:09 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 20:14:09 +0100 Message-ID: From: Francis Galiegue To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/wiWMQ5G7litHCeBbqjtyL284i7U Cc: "json@ietf.org" Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 19:14:17 -0000 On Thu, Feb 20, 2014 at 7:30 PM, Nico Williams wrote: > On Thu, Feb 20, 2014 at 12:17 PM, Francis Galiegue wrote: >> OK, then what about constraints on JSON emission instead? RFC 4627bis >> section 10 does mention that any emitted JSON must be conform to the >> grammar; can't a condition be added that in the case of JSON objects, >> they SHOULD ensure about the uniqueness of member names? > > The same issues apply here. For example, online encoders by > definition don't keep sufficient state. > Sorry, but how is that a reason? If [we|the IETF|John Doe](1) were to care about online services and all their technical deficiencies to push changes forward, would the Internet even move forward? (1) remove unused mention(s) -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nobody Thu Feb 20 11:18:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D681A0238 for ; Thu, 20 Feb 2014 11:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 KBYZ9M3W_KEx for ; Thu, 20 Feb 2014 11:18:56 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 59F851A0247 for ; Thu, 20 Feb 2014 11:18:50 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id CB5092005D106 for ; Thu, 20 Feb 2014 11:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Rb006zAxYZ4PDC9laGu2 n+XqlI8=; b=nI7UAqnXYzX41LtDReSDAtMaPS+XBEfyWGv850ndUsUclIozNts1 AUYc0rWsf6frOrKmiIfhChUO6yKhXkQNOIT3ExrFF6hTFwou+Nm1JUH8XBxsAw7a Vv3IzdohvRbWN2+pO8JVLdRensRRbaWYb0AoOwlt47HUyTNt+ANGsAM= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 6B10E2005D107 for ; Thu, 20 Feb 2014 11:18:46 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hi5so44108wib.15 for ; Thu, 20 Feb 2014 11:18:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hQ2yXu9zygCZeFLolwB10k1GboQITFUc5Ra/cjGJBrM=; b=BGBTYa/B91WafX91Sai8bnRueYdefhwNKBdCPjjlHs+5VHtHDzR5aRGIfeq2EdOBI/ G4BPFbPQ9vZEPKiVwZnucB0dQRa3pA0SxzgxUgoPNUQlEh6g2IGqWbt7kIrIYN5T3moc lwCSjZchIY1VPDPihs+EdGBxrx5dctPKkq7krvNIr/sTvYiUFNXncikpDlAsCYxqdVQ9 UsFNW7A/AwB1sed3dwdkcpe4ZlJGO9AhyyJKa1WSUxtA4C6u3L3VQLT/qmjiOoj1ndBa ycLceo6dlLf1RCZUfIBIV3gLszC6xq5mlCIGCHS7JvQG2Xfrd116vBx+y827hwe8TYMA Nu0g== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr8621404wib.39.1392923924648; Thu, 20 Feb 2014 11:18:44 -0800 (PST) Received: by 10.217.108.132 with HTTP; Thu, 20 Feb 2014 11:18:44 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 13:18:44 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/YZQbp1K3sngE3BkxzmJXH2PkcPI Cc: "json@ietf.org" Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 19:18:57 -0000 Why retread when the WG did so *many* times on the list? You should read the list archives. Nico -- From nobody Thu Feb 20 11:42:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BE21A0176 for ; Thu, 20 Feb 2014 11:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001] autolearn=no 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 DfT-zg2RSjDN for ; Thu, 20 Feb 2014 11:41:53 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4E1A0235 for ; Thu, 20 Feb 2014 11:41:53 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so1639484lan.26 for ; Thu, 20 Feb 2014 11:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=knB/+lBNLdDWFSxDmyrTxrcuDCqvI3koggIzR8z1Q/I=; b=kv5biq1eFIGjgXzUBwJiJXnXECbrNStLFJ35ETZ9yGK3E/QCyFbfyd0czXVshnbc+h tv0YX6O/DwPLj9WJtKcTWCs3G5EXlIWomi4lRIb2pksqKj65Pe0o72fba0hsiLICcgxN 8JMCBc1knsLgjr2XYLDHyKDEY3sIOeUyugol6Brch8ksVWUuKN4HDzq2ZNLLiyrKtQNP L6VDduGe6Nz1lsoABVc+r3zxd/YQm3Tge6yZHwS8NlBCoZlKpznxya3xHUfA5U+F8Qiw hNQ3O4xxM44jrGvi+CLfd3itQoX+zDyPqHh6cWsqdDg26jjPKFOOC/uhmm6rkLLLDoqm aKWA== MIME-Version: 1.0 X-Received: by 10.112.138.233 with SMTP id qt9mr2099094lbb.34.1392925309172; Thu, 20 Feb 2014 11:41:49 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 20 Feb 2014 11:41:49 -0800 (PST) Date: Thu, 20 Feb 2014 14:41:49 -0500 Message-ID: From: Phillip Hallam-Baker To: JSON WG Content-Type: multipart/alternative; boundary=089e0122971040807a04f2dbb263 Archived-At: http://mailarchive.ietf.org/arch/msg/json/J_rt_GKpA2rp1yrErnV8d8fWMEg Subject: [Json] Namespacing and avoiding pathologies X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 19:41:56 -0000 --089e0122971040807a04f2dbb263 Content-Type: text/plain; charset=ISO-8859-1 How the system currently works for ASN.1 OIDs and used to work for RFC-822 headers (remember X-headers?) 1) Group of independent developers create a spec 2) Spec gets used in practice 3) They decide to take it into the IETF 4) Someone suggests putting the OIDs under the IETF arc (e.g. under PKIX) 5) Implementations now need to track two identifiers for everything Trying to short circuit the process is worse. I have been waiting on some PKIX OIDs for 18 months now. And every time I ask the answer is 'yes'. So here is what I propose: 1) There is no JSON or IETF root to the arc. Each project builds its own arc with itself as the root 2) The root of a JSON namespace is registered as a .well-known service regardless of whether it is a Web Service with a HTTP binding or not. All that matters is that there are no collisions. So here is how it would work for OmniConnect * Well Known service code point is JsConnect (say) * Root of the name space is JsConnect * A transaction is Open with messages OpenRequest and OpenResponse If there is another protocol making use of JsConnect, they might have their own Open transaction that builds off the JsConnect protocol Protocol Foo NewNamespace Import JsConnect Transaction Open JsConnect.OpenRequest OpenResponse Structure OpenRequest Inherits JsConnect.OpenRequest String ExtraData Behind the scenes an implementation is likely to want to take the namespaces defined in the protocol and shuffle them down a level. So I actually declare JsConnect as being in the Goedel.JsConnect namespace. But this is something that is an implementation dependent issue that can and should be handled separately. I have always found the way XML Schema works by trying to pull in documents via URIs to be bogus and the hardcoded files to be worse. It should be possible to have a command line to kick the translator that reads something like: protogen project.protogen -settings mysettings.protogen -cs -c -h Which means 'read in the source file from project.protogen, apply the namespace mappings described in mysettings.protogen and write the code for C#, C and C header file into project.cs, project.c and project.h' mysettings.protogen might contain a declaration like Mapping Root Comodo.Open Language C Prefix JSX_ String CharZ Stubs Language C# Stubs What this says is that in C# and other languages that support namespaces, prefix the namspaces with Comodo.Open so generate Comodo.Open.NewNamespace rather than just Namespace. This also allows someone to support two different versions of the same spec using code in different namespaces. The 'Stubs' directive says to write out some dummy code stubs for testing. And in C we are spcifying a prefix to be added to the front of every identifier and that we want to use null terminated strings. We might also have a directive to choose the memory allocation model. I don't do Java but it is obviously an important language people would want supported. If someone could take one of my C# output files and convert it to Java, I can reverse engineer the changes back into the tool. It is almost certainly close as it is. The main challenge with Java is that every class has to be its own file and partial classes are not supported. Which is rather a horrorshow for code synthesis tools. C# makes it easy to separate the machine generated and synthesized code, Java was written by people who had been burned by C++. -- Website: http://hallambaker.com/ --089e0122971040807a04f2dbb263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How the system currently works for ASN.1 OIDs and used to = work for RFC-822 headers (remember X-headers?)

1) Group = of independent developers create a spec
2) Spec gets used in prac= tice
3) They decide to take it into the IETF
4) Someone suggests = putting the OIDs under the IETF arc (e.g. under PKIX)
5) Implemen= tations now need to track two identifiers for everything

Trying to short circuit the process is worse. I have be= en waiting on some PKIX OIDs for 18 months now. And every time I ask the an= swer is 'yes'.


So here is w= hat I propose:

1) There is no JSON or IETF root to the arc. Each proje= ct builds its own arc with itself as the root

2) T= he root of a JSON namespace is registered as a .well-known service regardle= ss of whether it is a Web Service with a HTTP binding or not. All that matt= ers is that there are no collisions.=A0

So here is how it would work for OmniConnect=A0

* Well Known service code point is JsConnect (say)
<= div>* Root of the name space is JsConnect
* A transaction is Open= with messages OpenRequest and OpenResponse

If there is another protocol making use of JsConnect, t= hey might have their own Open transaction that builds off the JsConnect pro= tocol

Protocol Foo NewNamespace
=A0 =A0 = Import JsConnect

=A0 =A0 Transaction Open JsConnect.OpenRequest =A0OpenR= esponse

=A0 =A0 Structure OpenRequest=A0
=A0 =A0 =A0 =A0 Inherits JsConnect.OpenRequest=A0
=A0 =A0 =A0 = =A0 String ExtraData


Behind the scenes an implementation is likely= to want to take the namespaces defined in the protocol and shuffle them do= wn a level. So I actually declare JsConnect as being in the Goedel.JsConnec= t namespace. But this is something that is an implementation dependent issu= e that can and should be handled separately. I have always found the way XM= L Schema works by trying to pull in documents via URIs to be bogus and the = hardcoded files to be worse.=A0

It should be possible to have a command line to kick th= e translator that reads something like:

protogen p= roject.protogen -settings mysettings.protogen -cs -c -h

Which means 'read in the source file from=A0project.protogen, appl= y the namespace mappings described in mysettings.protogen and=A0write the c= ode for C#, C and C header file into project.cs, project.c and project.h= 9;

mysettings.protogen might contain a declaration like

Mapping
=A0 =A0 Root =A0 Comodo.Open
=
=A0 =A0=A0
=A0 =A0 Language C
=A0 =A0 =A0 =A0 Pref= ix JSX_
=A0 =A0 =A0 =A0 String CharZ
=A0 =A0 =A0 =A0 Stubs

=A0 =A0 Language C#
=A0 =A0 =A0 =A0 Stubs

What this says is tha= t in C# and other languages that support namespaces, prefix the namspaces w= ith Comodo.Open so generate Comodo.Open.NewNamespace rather than just Names= pace. This also allows someone to support two different versions of the sam= e spec using code in different namespaces.

The 'Stubs' directive says to write out some du= mmy code stubs for testing. And in C we are spcifying a prefix to be added = to the front of every identifier and that we want to use null terminated st= rings. We might also have a directive to choose the memory allocation model= .


I don't do Java but it is obviously = an important language people would want supported. If someone could take on= e of my C# output files and convert it to Java, I can reverse engineer the = changes back into the tool. It is almost certainly close as it is. The main= challenge with Java is that every class has to be its own file and partial= classes are not supported. Which is rather a horrorshow for code synthesis= tools. C# makes it easy to separate the machine generated and synthesized = code, Java was written by people who had been burned by C++.

--
Website: http://h= allambaker.com/
--089e0122971040807a04f2dbb263-- From nobody Thu Feb 20 11:42:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFA11A0255 for ; Thu, 20 Feb 2014 11:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 xeclUjQtrxlu for ; Thu, 20 Feb 2014 11:42:44 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB341A0176 for ; Thu, 20 Feb 2014 11:42:43 -0800 (PST) Received: (qmail 17544 invoked from network); 20 Feb 2014 19:41:57 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 19:41:55 +0000 Message-ID: <7B10598788A345A4A13093E4CE09E8A5@codalogic> From: "Pete Cordell" To: "Nico Williams" , "Phillip Hallam-Baker" X-Unsent: 1 References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> X-Vipre-Scanned: 02591DAE00683002591EFB Date: Thu, 20 Feb 2014 19:42:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/VaD9TKbVGxxMqjLLokm8a6RCcwo Cc: JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 19:42:46 -0000 ----- Original Message From: "Nico Williams" > This sounds to me like an argument about how to handle extensibility. > We should first consider whether we want schema extensibility and if > we do, whether we want it to be explicit (like the ... extensibility > marker in ASN.1) or implicit (like implicit ... ASN.1 extensibility > markers in every type). I assume you're taling about extensibility of the vocabularies defined by a schema rather than extensibility of the schema language itself? > My position: we should want extensibility, and it should be explicit > (because having every type be implicitly extensible is a PITA for code > generation). What aspect do you find a PITA? Supporting both implicit extensibility and explicit extensibility is surely harder than just supporting implicit extensibility? Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Thu Feb 20 11:55:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C558D1A01D6 for ; Thu, 20 Feb 2014 11:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 uviJ6-AiYZgf for ; Thu, 20 Feb 2014 11:55:08 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6311A01FB for ; Thu, 20 Feb 2014 11:55:07 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id y1so1630251lam.41 for ; Thu, 20 Feb 2014 11:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=18qy2Al9lwSBToIHkoZZRB8y6zBdrT184OuBWO+qhtA=; b=Htn4mJvB10W2aIgVpIFDlW3n9gb4oFBdOzujLSzzRmjKRf+v0eDSkvQFBQHj5FK0fK /htj/Me4dq2i++xuBrS4DrAEbTkS8RsfRPHkXIejAFTia8txJs5d0hxsUNLa1KEIm8xM ywi7moLroPMoGIZ1Qv4O2AvSbcuExticQIrZyIlKUi3RWVEt4MsFQ3n4HD0MujZhdKX9 RnyseZPcaFBlhxbhmDJRflvB0YRVmFLa2Ihj9uak4SB1P1ZWHONw3MWc2fLg9JqL8Jt9 df5s/GzIGhoy/YI+O6ytfVvS+NnMhX3CyxIhpYBe6jRURzY4W+KnxksYYdfhNc7gUNHF 9QgQ== MIME-Version: 1.0 X-Received: by 10.112.129.168 with SMTP id nx8mr2059823lbb.37.1392926103252; Thu, 20 Feb 2014 11:55:03 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 20 Feb 2014 11:55:03 -0800 (PST) In-Reply-To: <7B10598788A345A4A13093E4CE09E8A5@codalogic> References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> <7B10598788A345A4A13093E4CE09E8A5@codalogic> Date: Thu, 20 Feb 2014 14:55:03 -0500 Message-ID: From: Phillip Hallam-Baker To: Pete Cordell Content-Type: multipart/alternative; boundary=047d7b343d6895457f04f2dbe19f Archived-At: http://mailarchive.ietf.org/arch/msg/json/111CzTdjuPyhB3rZUxo0zyME6tQ Cc: Nico Williams , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 19:55:11 -0000 --047d7b343d6895457f04f2dbe19f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 2:42 PM, Pete Cordell wrote: > ----- Original Message From: "Nico Williams" > > My position: we should want extensibility, and it should be explicit >> (because having every type be implicitly extensible is a PITA for code >> generation). >> > > What aspect do you find a PITA? Supporting both implicit extensibility > and explicit extensibility is surely harder than just supporting implicit > extensibility? The elephant in this room is the X.509 CRITICAL flag. The idea of the critical flag is that if there is a certificate extension that an RP MUST understand to understand the certificate correctly it can be marked critical and processors will reject the certificate rather than accept it and do the wrong thing. The problem came when people mistakenly interpreted CRITICAL as being 'important' rather than 'so important that if it is not understood you should break backwards compatibility'. So right now there is an X.509 extension that the PKIX specification says MUST be marked critical and the CABForum certificate specification explicitly states MAY be marked critical or not critical at the discretion of the issuing CA. I faced the same problem in the design of TASS which became the SAML assertion format with only minor changes. Since I knew that I would not get people to agree to a critical flag I instead introduced an element and the rule that an RP MUST understand every condition to rely on the assertion. It is the exact same mechanism but has not created any problems as far as I know. So what I would suggest for JSON is that we apply the same approach: Anyone can add tags into any structure they like and tags that are not understood are ignored unless the structure is tagged 'Splunge' in the schema. Splunge can be any word people like except 'Critical'. Right now the metaschema says splunge. -- Website: http://hallambaker.com/ --047d7b343d6895457f04f2dbe19f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 2:42 PM, Pete Cordell <petejson@codalogic.com= > wrote:
----- Original Message From: "Nico Will= iams"

My position: we should want extensibility, and it should be explicit
(because having every type be implicitly extensible is a PITA for code
generation).

What aspect do you find a PITA? =A0Supporting both implicit extensibility a= nd explicit extensibility is surely harder than just supporting implicit ex= tensibility?

The elephant in this roo= m is the X.509 CRITICAL flag.

The idea of the critical flag is that if there is a cer= tificate extension that an RP MUST understand to understand the certificate= correctly it can be marked critical and processors will reject the certifi= cate rather than accept it and do the wrong thing.

The problem came when people mistakenly interpreted CRI= TICAL as being 'important' rather than 'so important that if it= is not understood you should break backwards compatibility'.

So right now there is an X.509 extension that the PKIX = specification says MUST be marked critical and the CABForum certificate spe= cification explicitly states MAY be marked critical or not critical at the = discretion of the issuing CA.


I faced the same problem in the design o= f TASS which became the SAML assertion format with only minor changes. Sinc= e I knew that I would not get people to agree to a critical flag I instead = introduced an element <Conditions> and the rule that an RP MUST under= stand every condition to rely on the assertion. It is the exact same mechan= ism but has not created any problems as far as I know.=A0

So what I would suggest for JSON is that we apply the s= ame approach:

Anyone can add tags into any structu= re they like and tags that are not understood are ignored unless the struct= ure is tagged 'Splunge' in the schema.

Splunge can be any word people like except 'Critica= l'. Right now the metaschema says splunge.

--
Website: http://hallambak= er.com/
--047d7b343d6895457f04f2dbe19f-- From nobody Thu Feb 20 13:41:02 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16231A0213 for ; Thu, 20 Feb 2014 13:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 VNM0aJujE1fy for ; Thu, 20 Feb 2014 13:40:58 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 4236A1A02F1 for ; Thu, 20 Feb 2014 13:40:57 -0800 (PST) Received: (qmail 23283 invoked from network); 20 Feb 2014 21:39:58 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 21:39:54 +0000 Message-ID: <8D06B5A0FB0D415C8B5AC2D00B55C658@codalogic> From: "Pete Cordell" To: "Phillip Hallam-Baker" X-Unsent: 1 References: X-Vipre-Scanned: 02C51D1400683402C51E61 Date: Thu, 20 Feb 2014 21:40:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/GLJKwtDlLboYI22aheB0P4SkYVI Cc: Nico Williams , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 21:41:01 -0000 ----- Original Message From: "Phillip Hallam-Baker" > On Thu, Feb 20, 2014 at 2:42 PM, Pete Cordell : > >> ----- Original Message From: "Nico Williams" >> >> My position: we should want extensibility, and it should be explicit >>> (because having every type be implicitly extensible is a PITA for code >>> generation). >>> >> >> What aspect do you find a PITA? Supporting both implicit extensibility >> and explicit extensibility is surely harder than just supporting implicit >> extensibility? > > > The elephant in this room is the X.509 CRITICAL flag. > > The idea of the critical flag is that if there is a certificate extension > that an RP MUST understand to understand the certificate correctly it can > be marked critical and processors will reject the certificate rather than > accept it and do the wrong thing. > > The problem came when people mistakenly interpreted CRITICAL as being > 'important' rather than 'so important that if it is not understood you > should break backwards compatibility'. Sadly I don't think you can write an RFC to prevent stupid people being stupid! > So right now there is an X.509 extension that the PKIX specification says > MUST be marked critical and the CABForum certificate specification > explicitly states MAY be marked critical or not critical at the discretion > of the issuing CA. > > > I faced the same problem in the design of TASS which became the SAML > assertion format with only minor changes. Since I knew that I would not > get > people to agree to a critical flag I instead introduced an element > and the rule that an RP MUST understand every condition to > rely on the assertion. It is the exact same mechanism but has not created > any problems as far as I know. > > So what I would suggest for JSON is that we apply the same approach: > > Anyone can add tags into any structure they like and tags that are not > understood are ignored unless the structure is tagged 'Splunge' in the > schema. > > Splunge can be any word people like except 'Critical'. Right now the > metaschema says splunge. I like SIP's "Require" header, and have used the scheme in a number of protocols. The advantage is that you can get that basic level of compatibility testing out the way in the early stages of processing. An example in a JSON message might be: "Require": [ "TLS", "deferal#higson|standard" ] The other benefit is that can be handled at the protocol design level and doesn't impact the schema language! Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Thu Feb 20 13:54:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8711A0337 for ; Thu, 20 Feb 2014 13:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 pwfjoPsguvV0 for ; Thu, 20 Feb 2014 13:54:01 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 26EC21A032F for ; Thu, 20 Feb 2014 13:54:00 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 88D321E05C for ; Thu, 20 Feb 2014 13:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=y/Xx3wZ6CeTFlMHk6/3P 7//44o8=; b=T8wAiRqh0MdMF5VEbr9+f+bdv0zR1cnIUn22x1Sfl12Q9b16KJP4 yDAR9Om2FQ3g6xATLYzuYT5/O2vNltah3X3Vi8WguWScbsDb6gL4j6J/SjRiO0f8 8iJcP0lvAFQzvI41w1QC81JwPJ9JgTd1zzstTwNdJNWArMJui26TAbA= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id C7F971E059 for ; Thu, 20 Feb 2014 13:53:55 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id f8so181140wiw.13 for ; Thu, 20 Feb 2014 13:53:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ThnpQXXlXXg8hMzGwJgqHetUHZZxyfn160LNCUwBY2s=; b=AO3dpS28QV1GjZAMOdOE0Ohgwbbroesrh9eYM5yNNM2PuBa0Z/jKADrMnQM+LftARS pNoRN1r3I6GLUqV+dRqv+JX4yFZS+4izblNjDcciT3JDvYTdz7Mb+O2yGCB0Hfk3zZ2f n6AskhwneQEppXfjRI77YQU9JiFO58ZKMkvP2P42yPC5BSopIX2DyEbNx8J4JPE+RqK4 Yp0XzLs3ebBwbBLigxC8/pKNkCqEvG9flwy/ujyqMQ2ZlitEl05MKhnSkyMw1f41Aznz naWaIi0xt8oi+a00JRkkflbFP4c9fWjM7Nul7AD8vGT4QeWbMNBaD8MKQCABZHqwP+QP fsRA== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr399812wib.5.1392933231781; Thu, 20 Feb 2014 13:53:51 -0800 (PST) Received: by 10.217.108.132 with HTTP; Thu, 20 Feb 2014 13:53:51 -0800 (PST) In-Reply-To: <7B10598788A345A4A13093E4CE09E8A5@codalogic> References: <357740A8AA0F4316BE630917321FAB4D@codalogic> <47BB9131737D42218A6382DEF45BBE2C@codalogic> <7B10598788A345A4A13093E4CE09E8A5@codalogic> Date: Thu, 20 Feb 2014 15:53:51 -0600 Message-ID: From: Nico Williams To: Pete Cordell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/eNVGnmPxTBz8ptXa8gxFNuCmlz4 Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 21:54:03 -0000 On Thu, Feb 20, 2014 at 1:42 PM, Pete Cordell wrote: > ----- Original Message From: "Nico Williams" >> This sounds to me like an argument about how to handle extensibility. >> We should first consider whether we want schema extensibility and if >> we do, whether we want it to be explicit (like the ... extensibility >> marker in ASN.1) or implicit (like implicit ... ASN.1 extensibility >> markers in every type). > > I assume you're taling about extensibility of the vocabularies defined by a > schema rather than extensibility of the schema language itself? Yes. See ASN.1's extensibility marker. Briefly, if you end a structure/set/choice type with '...' then decoders are supposed to not fail just because unknown fields are included in the input; the decoders. (There's more to it, but I'm simplifying.) >> My position: we should want extensibility, and it should be explicit >> (because having every type be implicitly extensible is a PITA for code >> generation). > > What aspect do you find a PITA? Supporting both implicit extensibility and > explicit extensibility is surely harder than just supporting implicit > extensibility? Let's say you're generating C structs from the schema, and a given type is intended to be extensible, that it's an object. So now you need to decide what your parser will do when faced with names in this object that were not known when the C code was generated. There's two options: ignore them, or make them available as a C representation of an object with all the unexpected names. The latter can be important at times (e.g., when you're eventually going to re-encode the inputs and you want to preserve those unknown bits). So far so good. But if you make every type extensible by default, then you're polluting those C structs and the generated code even if mostly you don't need extensibility -- this is the PITA. IMO extensibility needs to be requested explicitly, but then the problem you run into is people forgetting to do so. Nico -- From nobody Thu Feb 20 14:25:02 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA251A031E for ; Thu, 20 Feb 2014 14:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 VXKKOshp7vCB for ; Thu, 20 Feb 2014 14:24:58 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 63FE41A0272 for ; Thu, 20 Feb 2014 14:24:58 -0800 (PST) Received: (qmail 2475 invoked from network); 20 Feb 2014 22:24:13 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 22:24:13 +0000 Message-ID: <7ADB5F59D5FC475CB251FF58797A873A@codalogic> From: "Pete Cordell" To: "Nico Williams" References: Date: Thu, 20 Feb 2014 22:24:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original X-Unsent: 1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Vipre-Scanned: 00088B8F00683400088CDC X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/z-6B5oSSzp6OH1C2ln7swQlz1Ao Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 22:25:00 -0000 ----- Original Message From: "Nico Williams" >> What aspect do you find a PITA? Supporting both implicit extensibility >> and >> explicit extensibility is surely harder than just supporting implicit >> extensibility? > > Let's say you're generating C structs from the schema, and a given > type is intended to be extensible, that it's an object. So now you > need to decide what your parser will do when faced with names in this > object that were not known when the C code was generated. There's two > options: ignore them, or make them available as a C representation of > an object with all the unexpected names. The latter can be important > at times (e.g., when you're eventually going to re-encode the inputs > and you want to preserve those unknown bits). > > So far so good. But if you make every type extensible by default, > then you're polluting those C structs and the generated code even if > mostly you don't need extensibility -- this is the PITA. IMO > extensibility needs to be requested explicitly, but then the problem > you run into is people forgetting to do so. A PITA, true, but not as big a PITA as when somebody forgets it or convinces themselves that they're never going to need it. In my experience change is the only constant in data structures! Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Thu Feb 20 14:28:55 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F281A032E for ; Thu, 20 Feb 2014 14:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 zA1HTfXE6YQo for ; Thu, 20 Feb 2014 14:28:51 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 908E61A0328 for ; Thu, 20 Feb 2014 14:28:49 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id F3E4A2AC06E for ; Thu, 20 Feb 2014 14:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=RD3i3OHADkum4PQemwqR m0DsSLM=; b=bY4HjyqzXUmDAtn3WCwRWwcZkgJzqMi8IX5zOwutyJ/YvhJAgQQ4 7MIjjS7L8GBWxxmuHlvRcHEqj1hxRv4OCpzNEWXpxpXAc4ZMa6hA8lMFwdbRXvUF kpR1jnRNyCXenoBt4dLI4ZgCUyl+7RFXXuvVDeMZboM02LVndeKUnXk= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 9AF7E2AC06A for ; Thu, 20 Feb 2014 14:28:45 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id l18so1970803wgh.12 for ; Thu, 20 Feb 2014 14:28:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p1BfWtZSA88RzQ0k36YjHei2zKEvw5f67qJw+Vw4PFU=; b=ikv+NjA0H39LJZR0UAfVKiePXeCf4MlOjgJBQGLdi11Gf5/TmZ93vY918XG4UYxWrP /pDHz+wT6yUGheadtVXsh/bALoOOKV17G66Rj+/TN+/fL5MMiaHt0sBQmpOL8vdAaFri OGXpq7tLBY2sXbGIJJwN+aQKiD3LBa0w6pozbTErrXgw6x+pru6N7U3uUqE7qwPQGQ8R sinbg1AFA64j6fu+2AkEJudKxZv2wIz/a4s/NniHG7jvRfCJNKcU/TuscvZpAhiIgB+d G83arK6NKjD6zJDOX2Zx22639dv/8PvkxkLalOrq62Er+VAn4s12Dn4ZLw4LceS0I3aK ACfw== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr495368wib.5.1392935324034; Thu, 20 Feb 2014 14:28:44 -0800 (PST) Received: by 10.217.108.132 with HTTP; Thu, 20 Feb 2014 14:28:43 -0800 (PST) In-Reply-To: <7ADB5F59D5FC475CB251FF58797A873A@codalogic> References: <7ADB5F59D5FC475CB251FF58797A873A@codalogic> Date: Thu, 20 Feb 2014 16:28:43 -0600 Message-ID: From: Nico Williams To: Pete Cordell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/3urVNP9EJKnkBbGt57prItL251s Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 20 Feb 2014 22:28:53 -0000 On Thu, Feb 20, 2014 at 4:24 PM, Pete Cordell wrote: >> So far so good. But if you make every type extensible by default, >> then you're polluting those C structs and the generated code even if >> mostly you don't need extensibility -- this is the PITA. IMO >> extensibility needs to be requested explicitly, but then the problem >> you run into is people forgetting to do so. > > A PITA, true, but not as big a PITA as when somebody forgets it or convinces > themselves that they're never going to need it. In my experience change is > the only constant in data structures! Maybe so, but then you need to make sure that people don't extend structures and expect extensions to be critical. One way or another you depend on ppl knowing what they're doing when they extend protocols. Anyways, I'm convincing myself that this (extensibility, explicit or implicit) is a minor detail. Nico -- From nobody Fri Feb 21 04:06:36 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8BE1A053A for ; Fri, 21 Feb 2014 04:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 RgYpRLrwndyH for ; Fri, 21 Feb 2014 04:06:33 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB641A0538 for ; Fri, 21 Feb 2014 04:06:32 -0800 (PST) Received: (qmail 4104 invoked from network); 21 Feb 2014 12:05:47 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 21 Feb 2014 12:05:47 +0000 Message-ID: From: "Pete Cordell" To: "Nico Williams" References: <7ADB5F59D5FC475CB251FF58797A873A@codalogic> Date: Fri, 21 Feb 2014 12:06:15 -0000 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original X-Vipre-Scanned: 0019FBCB0068340019FD18 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/FHROfxuTNQn9-NW23iuQlJaloug Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 21 Feb 2014 12:06:35 -0000 ----- Original Message From: "Nico Williams" > Anyways, I'm convincing myself that this (extensibility, > explicit or implicit) is a minor detail. If you've had to live with XML Schema for any length of time, you'll know extensibility is only a minor detail if you actually have it. I hope for this group it is a minor detail because it is a given. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com