Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.142.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=Ehhk17uVcZ1bZwSWOrpU+8Ay3QZBm6gc0EExBlhc43R9RoPpmi2/qTcEz+VgsFK7bm
         imtH3FWDKDzuZ3CWow1+Cvf4bSAbTpEhCkdqQi7sNARFhr3mD9TYG2Qg0lTY1piaQ5Dw
         +p1tOmctdVYatSVlTUSWWLf+iwLdJKNxxl1hk=
Message-Id: <E41668CB-582E-453E-96D4-F0E1C5ECE5E5@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: couchdb-user@incubator.apache.org
In-Reply-To: <20081113220313.GG15315@tumbolia.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Document Updates
Date: Fri, 14 Nov 2008 09:09:03 +1030
References: <403828.36717.qm@web52508.mail.re2.yahoo.com>
 <e2111bbb0811130822l1894e20fm1ff31aa2d54c3d5f@mail.gmail.com>
 <46837.75533.qm@web52503.mail.re2.yahoo.com>
 <20081113163808.GA15315@tumbolia.org>
 <27d8d0930811130840t47269d91o9539fae200bcd380@mail.gmail.com>
 <20081113164344.GB15315@tumbolia.org>
 <99294D7F-4D06-47F9-800B-DB9213D929F4@gmail.com>
 <20081113220313.GG15315@tumbolia.org>


On 14/11/2008, at 8:33 AM, Noah Slater wrote:

> On Fri, Nov 14, 2008 at 08:19:22AM +1030, Antony Blakey wrote:
>> The relevent section from XQuery Update,
>> http://www.w3.org/TR/xquery-update-10/#id-update-primitives, might  
>> be useful
>> starting point for defining a JSON-encoded (recursive) EDL-based  
>> structural
>> diff.
>
> I think an XQuery/XPath type solution would be very interesting.

IMO the simplest thing that would work (ignoring representation) looks  
something like this:

   insert <json> in <jsonpath>
   insert <json> after <jsonpath>
   insert <json> before <jsonpath>
   delete <jsonpath>
   replace <jsonpath> with <json>

where jsonpath is roughly as: http://goessner.net/articles/JsonPath/  
without the executable expressions.

Diff computation would undoubtedly generate a restricted subset of  
jsonpath selectors, but it's worth supporting the wildcard/recursive  
descent operations for clients.

Representing the update document as json itself would be clean, so an  
EDL could look like this:

[
   { "replace":"$.post.comments[2].email"  
"with":"antony@linkuistics.com" },
   { "insert": { "email":.... } "in": "$.post.comments" }
   { "insert": { "email":.... } "after": "$.post.comments[5]" }

]

or, using a meta-encoding (which IMO is unneccessary)

[
   { "op":"replace" "path":"$.post.comments[2].email" "content":"antony@linkuistics.com 
" },
   { "op":"insert-in" "path":"$.post.comments" "content":  
{ "email":.... }  }
   { "op":"insert-after" "path":"$.post.comments[5]" "content":  
{ "email":.... }  }

]

I propose that these aren't declarative, but procedural, in the sense  
that they are applied linearly and hence each path context is the  
result of the proceeding edits, rather than the original tree. This  
complicates the encoding of diffs but results in a much simpler apply  
mechanism. But maybe it would be worth using a declarative form with a  
constant context - I'm unsure about the tradeoffs.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

He who would make his own liberty secure, must guard even his enemy  
from repression.
   -- Thomas Paine