Re: [Json] Generators

Marcos Caceres <w3c@marcosc.com> Mon, 10 June 2013 13:02 UTC

Return-Path: <w3c@marcosc.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E021F8EBC for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 06:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUtHzIvNmxxC for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 06:02:43 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E20B521F8CB4 for <json@ietf.org>; Mon, 10 Jun 2013 06:02:42 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id n57so4884762wev.14 for <json@ietf.org>; Mon, 10 Jun 2013 06:02:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=oIkjdxbdnCdFiu0zzH5zsN248nlR3JQfKKzNgAVHL9Y=; b=TF+KohIJepRfyI9bV+UqzwI3jZ25l6Pyd4VilvybvyWOjxLTW4nV8O5bu2/95CHkfU 2l5brn7KOv7j8GYQ6zQYd0+eVHIHbltmYTP4alXbuWpDS/fPMctwDTRu1YGET4YmTs4D Jt145mqUYeG6q9l07kItyUW1IkZQjg3HwREc65tFaNboL6l1xWSLzDSvtxQCC1TTOzP0 6jLkqb4jf1G9/W44Ah5oB4brYLz/PV/FrP5UrCmcBUnS0K53tbTZP8tGqOQq2HY8t8Io +4D2kCZvDu0oocFWLHWM7KwDqV1wfXQwhaVc/xZ8Nqu994LkpGsigEpQhOkrIB3Lr5gh Ji6A==
X-Received: by 10.180.182.228 with SMTP id eh4mr4544106wic.42.1370869362028; Mon, 10 Jun 2013 06:02:42 -0700 (PDT)
Received: from [172.16.0.7] (bl11-16-70.dsl.telepac.pt. [85.244.16.70]) by mx.google.com with ESMTPSA id b19sm11208107wik.10.2013.06.10.06.02.40 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 06:02:41 -0700 (PDT)
Date: Mon, 10 Jun 2013 14:02:39 +0100
From: Marcos Caceres <w3c@marcosc.com>
To: Carsten Bormann <cabo@tzi.org>
Message-ID: <B051939EAEBE47209C448BA8F0024822@marcosc.com>
In-Reply-To: <DA0F4370-C31B-4DCD-A22E-B385A8ACEDA2@tzi.org>
References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <CB545934-DB9A-42AC-9457-F46BF925E84B@tzi.org> <8BD6412FBAD444A393B55D3CE2D80B00@marcosc.com> <DA0F4370-C31B-4DCD-A22E-B385A8ACEDA2@tzi.org>
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Gm-Message-State: ALoCoQn3ooKjPXT2MxjETIVODsFDV0YhA7oJU6XBJj0ECQH89qoA7yD0G4g+uocuNsJLcATp6UqB
Cc: json@ietf.org
Subject: Re: [Json] Generators
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 13:02:44 -0000

On Monday, June 10, 2013 at 1:26 PM, Carsten Bormann wrote:

> 
> Comparing two algorithms is much harder (even for humans) than checking an implementation against assertions.
> Even more so if one of them is written in English, so it cannot even be executed unambiguously.

Right, but this is why we have test suites - i.e., to provide unambiguous computationally-verifiable testable assertions of what the English is saying. Personally, the primary motivation for me to see the algorithms is so that we can make sure we have a consistent way of testing everything in the spec. In my experience, the algorithms also help identify the gaps - particularly as you try to test and code against them. Yes, this also means having very competent people writing the tests so to make sure edge cases are also captured.     
> Don't get me wrong: Adding a pseudocode example can do a lot to aid understanding (and to disambiguate poorly worded assertions). However, turning English language pseudocode into the default mode of explaining things is a major mistake (and going full FDT is almost always worse, except for small elements such as ABNF). I'm not going to repeat what can be read as another copy of the cheap shot (and even implicitly blaming a single person for such an outcome is always wrong, mea culpa), but I think you are well aware what might count as exhibit A. Let's not go there.

My experience has been different, I admit. I'm mostly involved with specs at the W3C and we exclusively do algorithmic specs. I won't claim that one approach is better than the other, as I can only speak from my personal experience. I've jotted down some of those thoughts here:

http://www.w3.org/TR/test-methodology/

> Douglas' tight prose in RFC 4627 is actually something I would recommend to emulate.
> The "ambiguities" we are discussing are either the result of very "creative" use or were left in deliberately (SHOULD...).
> That's why I'm a bit unhappy that we seem to have started wordsmithing before getting some of the decisions done.

You are probably right. Like I said in a previous email, I just joined the list and have no idea at what stage you all are at - but I'm happy to try to help. 

-- 
Marcos Caceres