Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
James M Snell <jasnell@gmail.com> Tue, 08 January 2013 17:07 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 78DAA21F84E0; Tue, 8 Jan 2013 09:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.036
X-Spam-Level:
X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 Vywmc-YQNH+b; Tue, 8 Jan 2013 09:07:12 -0800 (PST)
Received: from mail-ia0-f179.google.com (mail-ia0-f179.google.com [209.85.210.179]) by ietfa.amsl.com (Postfix) with ESMTP id DB80821F84C0; Tue, 8 Jan 2013 09:07:11 -0800 (PST)
Received: by mail-ia0-f179.google.com with SMTP id o25so561155iad.10 for <multiple recipients>; Tue, 08 Jan 2013 09:07:11 -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=a8mUXHBc/lhQAOsrQLKZhHZSou57RXlD5TzUU91Kv9M=; b=BYM2as89e5+kSXXnASNb/uq4X3C+CRDwFYwZUxCqp2Eg5S5Ff25aR3RBXIQy/0aGfA OnIY13hbaCFeo/Qw5574i+76p9EsOy+qwrVODOYrpeAFTEx/BGNedMDLYMF33bUSDIAn MqInw15BhMoXKOQAjKImejhfa+DkJbPjUuYhI0eRAvFRJOZjRZiKYXmBPqcme1FKK75p xEnhAqHWbKBctl2/tfSf3JIyHE+nLlxwBPEjIZVgWPuiJnxjQBNgRPMg849AdtcrhASP BUfGjtC9GNaH1ffAB5NX091eaumfiHlc/hAalstWa40dzsn9kgP2L0qPjLb0fRSNyIhs TqsQ==
Received: by 10.50.150.174 with SMTP id uj14mr9636735igb.19.1357664831403; Tue, 08 Jan 2013 09:07:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Tue, 8 Jan 2013 09:06:50 -0800 (PST)
In-Reply-To: <CAD5Szk-U1LeBSfUgah8XXE2LZ=utR=0W-V7VsT6j-i2VixZerg@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> <CAChr6Sx7JdKM91EwJaSZ0Ra_F4FSqkuc3vzTY1LM=F_8sWho+Q@mail.gmail.com> <1357515310.6827.23.camel@polyglot> <CAChr6SyAq=7aQdZn54ihYK+0hDhL--2Oaq0RvehoNFbwKNNShA@mail.gmail.com> <CAChr6SxorKO20rGYi-e4YNF=HNGrwz8wPGKCFZQYWQwqsetjjg@mail.gmail.com> <CAOXDeqqE2mCLapwvjwQkme5VTpRCfmF0mFQcx02WW0-zi4i5=g@mail.gmail.com> <50EB4E8B.30700@versi.edu.au> <CAOXDeqoOj1K_zBWVZbE2j4Vnp1pYZ1yUEp9nyTKZmp-QrAziqg@mail.gmail.com> <CAD5Szk-U1LeBSfUgah8XXE2LZ=utR=0W-V7VsT6j-i2VixZerg@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Tue, 08 Jan 2013 09:06:50 -0800
Message-ID: <CABP7Rbea9HoauQs_VhzdgUzgbFoLG=ppP98V2wzo86=145tWTA@mail.gmail.com>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
To: Jared Rosoff <jsr@10gen.com>
Content-Type: multipart/alternative; boundary="f46d043d644bfff78a04d2c9f9f6"
Cc: Mark Nottingham <mnot@mnot.net>, IETF Discussion <ietf@ietf.org>, Matthew Morley <matt@mpcm.com>, IETF Apps Discuss <apps-discuss@ietf.org>, IESG <iesg@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, 08 Jan 2013 17:07:13 -0000
Fortunately the JSON-Patch syntax is designed such that it is possible to extend the range of defined operations without breaking basic structure... much as I have done with the json-predicates draft. You would need to define a new media type to associate with the extensions but that's not difficult. Consider something along the lines of.. application/json-patch-ext... [ {"op": "unset", "path": "/a/b"}, {"op": "inc", "path": "/a/c"}, {"op": "push", "path": "/a/d", "value": 1} ] - James On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff <jsr@10gen.com> wrote: > hi team, i'm new to the discussion here, but wanted to jump in. i work on > mongodb, a json database, and i wanted to share how we deal with these > issues. > > mongodb uses almost the same notation for pointers ("a.b.c" instead of > "/a/b/c"). We also index arrays in the same way as json pointer ( "a.0" > refers to the 0th element of the array called "a"). and this works fine in > practice. (ref: http://docs.mongodb.org/manual/core/document/#dot-notation > ) > > our update syntax is different tho. the verbs in mongodb updates for json > documents are more specific: > > set / unset / rename (operations on fields) > inc (increment integer values) > push / pop / pull (operations on arrays) > addToSet / removeFromSet (operations on arrays) > > (ref http://docs.mongodb.org/manual/reference/operators/#update) > > since update operations are more specific and type dependent, it's easy to > throw an error if an unexpected type is encountered (e.g. try to push onto > a field that has a non-array value) and to act smartly on empty fields ( if > path to push is empty, we assume it should be an array, create it, and then > push the value onto it). > > i concur the the pointer syntax is fine and ambiguity comes from the > definition of operators in json patch. > > -j > > > On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley <matt@mpcm.com> wrote: > >> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy <conal.tuohy@versi.edu.au>wrote: >> >>> On 07/01/13 13:23, Matthew Morley wrote: >>> >>> >>> For me the deficiency is not in the pointer, but patch format being >>> generated. >>> >>> One approach is to push that *one* test, structure conformity, into the >>> pointer syntax. Another is via the type operation. >>> >>> If a vague patch is generated, vague results are to be expected. >>> >>> It seems to me, on the contrary, that the deficiency is in the pointer >>> syntax, and I think it would be a mistake to try to work around that >>> deficiency in JSON Patch. Because aren't there other things which one might >>> do with JSON Pointer than use it with JSON Patch? There's been mention of >>> having it registered as a URI fragment identifier syntax for JSON for >>> example. JSON Pointers could then end up all over the place, outside of >>> patches. IMHO JSON Pointer needs to be taken seriously as a technology in >>> its own right. >>> >> >> Couldn't agree more about it being taken seriously in its own right. :) >> >> JSON Pointer for me exists outside of JSON Patch, always has and will do >> the way we think about structures. As it represents both a resolution path >> and an identity string (both ends of the path concept). I see value from >> the identity view, in describing a location that is aware of being inside >> an array. >> >> But JSON Pointer should not be changed just because of issues with JSON >> Patch, especially when JSON Patch is attempting to address those issues >> with other mechanisms within the specification. That is all I was trying to >> express. The syntax change should be for other reasons, if it is going to >> be made. >> >> My personal experience (for what its worth): In the past I've tried a >> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at >> times to address the same issues suggested here. Though my experiences >> pushed me towards a single syntax using a.b.c.0, and thus my support for >> /a/b/c/0 over /a/b/c:0. >> >> The system at first used the . or : syntax, combined with dynamic tokens, >> being pointers themselves, to resolve other pointers. So it was not >> reasonable to know ahead of time if an end point was an array or an object. >> "a.b.c.{d.e.f}" could end up in an array or in an object, depending on the >> value at d.e.f at the time of resolution. Especially with many layers of >> tokens to resolve, and changing data structures. >> >> I found in practice, it didn't really matter, so the choice of . or : was >> phased out. At the end of the day the two syntaxes point to mutually >> exclusive points within the data, so that `meta data` about the structure >> was removed from the syntax we used. It didn't add value, even if it added >> clarity at times. We also had functions at the end of paths, but that goes >> beyond the JSON focus of the JSON Pointer goals, so those points are not >> relevant here. >> >> This discussion thread seems to be getting overly complicated, but JSON >> Pointer changes should come from the JSON Pointer view point and that >> specifications goals, not from short comings in JSON Patch. >> >> -- >> Matthew P. C. Morley >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > >
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Manger, James H
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Abdussalam Baryun
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Abdussalam Baryun
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Paul C. Bryan
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Murray S. Kucherawy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Carsten Bormann
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Conal Tuohy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Paul C. Bryan
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Hector Santos
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre