IETF Logo Mail Archive

Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

James M Snell <jasnell@gmail.com> Tue, 18 December 2012 03:54 UTC

Return-Path: <jasnell@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355BE21E804D; Mon, 17 Dec 2012 19:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.679
X-Spam-Level:
X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB2A18v+QnkY; Mon, 17 Dec 2012 19:54:09 -0800 (PST)
Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) by ietfa.amsl.com (Postfix) with ESMTP id 50CA421E804C; Mon, 17 Dec 2012 19:54:09 -0800 (PST)
Received: by mail-ia0-f173.google.com with SMTP id w21so135259iac.32 for <multiple recipients>; Mon, 17 Dec 2012 19:54: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:from:date:message-id:subject:to :cc:content-type; bh=xMnwV/UIS1JmPTGMpOCMLF7XzACv6147MLk94/lgUJA=; b=gNIWuRmxbqtkkrQqVSWgRFZgLGDvBLI5JjsfMP6gd7oBDrhZlZV4WmxLiYj29N3Xnt zWJbs/gJm9szzBkN4IXBYcENpRVLieziGbNqQcg0oy/vjW3s/eKBkP1PY8g1lBHkiZI9 x09WMF0WkPYoIrBKmRn8ojlQjCvDk5JBjNPlnxDEyjlEkHCUtmcooxi8ATY3nu/ae+41 QPI30wZvTQVwdd+kEoaRkHKgaGHKxP3Zl+g/77wUAJyyyNIhNWpJYgPuOhDQs7MC+4A8 Av0U7E5uMFPEjHwH4exm5RbqX7/pw3/MzO3/lK9QHSi2uUUacHJLRPGn61JmSzImbCpC QdVg==
Received: by 10.50.6.169 with SMTP id c9mr731126iga.24.1355802848780; Mon, 17 Dec 2012 19:54:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Mon, 17 Dec 2012 19:53:48 -0800 (PST)
In-Reply-To: <CAChr6SyV-kDLYnDXXjW5GD7KZ1brBYLmvO-5TkODGtcHOf2rmg@mail.gmail.com>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <CABP7RbeNsZ_rBWRjou=VG+hBhUKaOz+y1a0sSChwWiHte9znnQ@mail.gmail.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> <CAChr6SxZRc3B_HCbw76kLe2dsRSr43r-gLpfMVnCUfJTrZdTLA@mail.gmail.com> <CABP7RbfA33huBFadMeXTTEt=MkjW8-d4DFH7+GLXGurnm9sSRw@mail.gmail.com> <CAOXDeqpPE4eNy_qJpDPdPHbCQakG9-hDcNZ3Sj9r4kWedByVzQ@mail.gmail.com> <CAChr6SwtS_=iS-k4mJm1vHjEvvGVzay5jDYeGheqsPZqO-89CQ@mail.gmail.com> <EABB8F51-C3B4-49F5-8672-5C2ABAC7043A@mnot.net> <CAChr6Sy-Xc8vC6FabFmdseR7xfQ-6t9hARunWjYgt6FqjmoBWg@mail.gmail.com> <CABP7Rbd7w-7-8+q0T7WciBp6NU7c2uJjmRGiLFjxkc52P5KLdw@mail.gmail.com> <CAChr6SyV-kDLYnDXXjW5GD7KZ1brBYLmvO-5TkODGtcHOf2rmg@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Mon, 17 Dec 2012 19:53:48 -0800
Message-ID: <CABP7RbdQCh+9kLh22U1Oa3ncUt6VLB=M-hgJaTrRppXnxTeW7A@mail.gmail.com>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
To: Robert Sayre <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary="e89a8f6467172fe21404d1187383"
Cc: Mark Nottingham <mnot@mnot.net>, IETF Discussion <ietf@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Dec 2012 03:54:10 -0000

The key advantage to the current syntax is that it's just absolutely drop
dead simple. I get what you're saying but I'd rather avoid increasing the
complexity of the syntax any more than we absolutely have to. And, to be
absolutely honest, I haven't yet seen an actual application case where it's
been an issue (that's not to say they don't exist, just haven't seen it in
practice yet). What's your suggestion for making the syntax better?

On Mon, Dec 17, 2012 at 7:41 PM, Robert Sayre <sayrer@gmail.com> wrote:

> On Mon, Dec 17, 2012 at 7:08 AM, James M Snell <jasnell@gmail.com> wrote:
> >
> > Everyone's idea of "bloat" is different.
>
> What I meant was that the predicate additions increase the size of the
> protocol messages. Your example is twice as large. The check could be
> more efficiently represented in the path notation or the operation
> names.
>
> > Again, the point is, I don't see this as a problem in practice.
> Implementers
> > that make blind edits to arbitrary docs can expect surprising results
> > sometimes. That's just the way it is. There are mechanisms defined (test,
> > json-predicates and conditional requests) that can make the edit more
> > reliable.
>
> Well, one way of putting it would be that the patch format makes it
> difficult to ensure convergence at quiescence in OT software when
> there's a change in type from array to object or vice-versa:
>
> <http://en.wikipedia.org/wiki/Operational_transformation#The_CC_model>
>
> There's no good reason for it to be that way, is there?
>
> - Rob
>

v2.23.0 | Report a Bug | By Email