Re: [Json] Proposed minimal change for duplicate names in objects

Nico Williams <nico@cryptonector.com> Fri, 05 July 2013 02:52 UTC

Return-Path: <nico@cryptonector.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 F0A1511E8109 for <json@ietfa.amsl.com>; Thu, 4 Jul 2013 19:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level:
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 FNXJqnEE7eLi for <json@ietfa.amsl.com>; Thu, 4 Jul 2013 19:52:09 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BE92711E821F for <json@ietf.org>; Thu, 4 Jul 2013 19:52:08 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B2AB867C06E for <json@ietf.org>; Thu, 4 Jul 2013 19:52:04 -0700 (PDT)
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=JQD0hCdGd37NnRsDiXBh swXZV4A=; b=OBAZC2fCjJJ7qC8SxU9SgSzAnGro+7uiL5oyDjwPpwL7xKiR68ZR 87lEI+qgDGT5AcvHPEMrWbMZeUrJZpO/yS5IVhCRplchXAfaAGquv4fePmuaVtPA NhqMJetVTuvqeiejlC40YwLP9AX7lv1TXIY8kf7ZW/UDc31fD+H+FRI=
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 58EA267C06D for <json@ietf.org>; Thu, 4 Jul 2013 19:52:04 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id e11so1547225wgh.18 for <json@ietf.org>; Thu, 04 Jul 2013 19:52:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyyTAFELgipx2Er+WjRYLW1Igltslhz5eGtxRMipS4g=; b=gXW+ZfA30OQXpV4h0G/qnpBExWtB+lz2iauLBssAjLIAQ6xeZHXhZcQCXBr1iTHY0b m0rgyDDCTprSUFGKYix/VkvQF/+l4FLUS29/jpApJWJsGhowAbL8uWBmCrOnF82qlwgt Kz+7gJJTVdEi+x7yeW0WHjQw3IkLfnPEghi9tnFK1pwg4HEynPBXpG25Eotuvqb5NPnC 8lH3Npo2AuZkQTBK4SH4JRLuzakoGnEp/73i44EEAhOyL/XM34UhCTJON6QEZS0QwyNZ 6MCCJVuHZXdmhDNBy+3QDF3Ddoy32M2fQdFlYsA2V3iI4Mz0pr6zb9xPxvdwbbT2gzVY pOSg==
MIME-Version: 1.0
X-Received: by 10.194.173.37 with SMTP id bh5mr5052310wjc.30.1372992722490; Thu, 04 Jul 2013 19:52:02 -0700 (PDT)
Received: by 10.216.152.73 with HTTP; Thu, 4 Jul 2013 19:52:02 -0700 (PDT)
In-Reply-To: <CAGrxA24di1VgXZrHZfSGQ1YohuhidaRM2yPahbeKZpW4LQ7-kA@mail.gmail.com>
References: <B86E1D4B-1DC8-4AD6-B8B3-E989599E0537@vpnc.org> <CAK3OfOj3MNNhjwo2bMa5CgoqynzMRVvviBXC8szxt5D17Z7FDg@mail.gmail.com> <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <51D48990.7090305@cisco.com> <CAK3OfOijGyGMEaeM6CmV+AbRHq2aJ3KaEc7sbrGDvQYuzSCc3Q@mail.gmail.com> <CAGrxA24di1VgXZrHZfSGQ1YohuhidaRM2yPahbeKZpW4LQ7-kA@mail.gmail.com>
Date: Thu, 4 Jul 2013 21:52:02 -0500
Message-ID: <CAK3OfOjsoEVViBwY8Aza_YBnRkKsnVuc8ir8Rne-qgsWY+TBxA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Tatu Saloranta <tsaloranta@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Eliot Lear <lear@cisco.com>, "json@ietf.org WG" <json@ietf.org>
Subject: Re: [Json] Proposed minimal change for duplicate names in objects
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: Fri, 05 Jul 2013 02:52:14 -0000

On Thu, Jul 4, 2013 at 5:17 PM, Tatu Saloranta <tsaloranta@gmail.com> wrote:
> On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams <nico@cryptonector.com> wrote:
>> I think we're very likely to get consensus for SHOULD language with an
>> out for streaming generators/parsers pushing the MUST to the
>> application.
>>
>> We could force MUST with an out for streaming generators/parsers
>> pushing the MUST to the application, but it'd leave some implementors
>> on the rough side of consensus and unhappy.
>>
>
> One problem I have had is assumption that we only have 2 layers
> (application, parser/generator). While it simplifies language, it makes it
> difficult to define whether combination of parser and deserializer (as well
> as serializer and generator) should be considered "parser" (and "generator")
> in specifications or not.
> Perhaps "application" here would then refer to serialization library and
> application code?

There can be many layers.

One application I work with is a Ruby on Rails app with a DB
underneath.  In one client I have to read a very large subset of the
DB and the run with that and an audit feed from the same DB.  A JSON
streaming generator and parser that ignored duplicate names would work
just fine because schema is enforced on the *write* side and so there
can be no duplicate names, and *nothing* but the write side need ever
concern itself with duplicate names.  There's quite a few moving
pieces and layers in this one app, but only one piece that ensures
properly-formed data -- outside that piece there is no relevance to
duplicate name handling for there can't be duplicate names.

I don't think it'd be critical to wordsmith the RFC so that this app
can work with streaming generators/parsers that are oblivious to
duplicate names, but it'd be nice to.  One way to do it is to use the
passive voice.  Otherwise there might have to be a [what do we call
this?] consideration for application deverlopers using streaming
encoders/parsers that are duplicate name oblivious.  There's a
trade-off between writing very generic text (but in a passive voice)
and having to cover a number [possibly lots] of specific cases.

> I would be happy with "SHOULD" at parser/generator level, and even "MUST"
> for serializer/deserializer level, since those are cases that are easy to
> support efficiently.

That's not really enough for my use case.

> At the same time, given such separation of processing layers, nothing
> prevents applications from doing custom serialization/deserialization, and
> by-passing strict checks. I don't personally mind that -- as long as
> ramifications are made clear, it's their responsibility -- but I don't think
> is universally agreed view.

Right, "strict checks" somewhere.  Just not necessarily in the
generator nor parser.

Nico
--