sorry, i forgot to cc oak-dev. resending... On Wed, Mar 21, 2012 at 2:07 PM, Julian Reschke <julian.resc...@gmx.de> wrote: > On 2012-03-21 13:47, Stefan Guggisberg wrote: >> >> On Tue, Mar 20, 2012 at 6:53 PM, Julian Reschke<julian.resc...@gmx.de> >> wrote: >>> >>> Hi, >>> >>> so Stefan is cleaning up the JSOP Wiki page (thanks!). >>> >>> I think it's time to look again at the difference between the JSOP diff >>> format (as used in MK.commit()), and the IETF JSON Patch format, now >>> <http://trac.tools.ietf.org/html/draft-ietf-appsawg-json-patch-01>. >>> >>> JSOP has lost it's dependency on member ordering, and JSON Patch now has >>> "test" and "copy", so it seems the only missing gap is the metadata >>> feature. >> >> >> WRT the set of operations (add, replace, copy et al) i agree that there's >> a >> nice 1:1 match. > > > Thanks for confirming. > > So should I start work on a spec that defines "JSOP diff" as syntactical > variant of draft-ietf-appsawg-json-patch-01?
yes, i guess it would make sense. > > >> WRT the metadata feature. it might be useful in certain situations but >> i am not sure whether we really need it. > > > I assume it's needed for the commit message in MK, but that of course could > be separated into a separate string argument. the commit msg is already passed as a separate argument in the commit method. thomas' proposal referred to an alternative format of getJournal return value [1]. this has been discussed on the dev list a while ago [2]. IMO it does seem useful but i don't know whether or how we should specify that as a proposed extension to JSON patch. [1] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-mk/src/main/java/org/apache/jackrabbit/mk/api/MicroKernel.java [2] http://www.mail-archive.com/dev@jackrabbit.apache.org/msg26796.html > > >>> If this is true, we can (mostly) define the JSOP diff format as a >>> transformation from JSON Patch. That might be useful in order to avoid >>> bikeshed discussions about syntax. >> >> >> i agree that it would be useful if we could define JSOP diff as a >> transformation >> from JSON Patch. >> >> however, after skim-reading the JSON Patch draft i noticed the following >> issues: >> >> - adding nested object trees doesn't seem to be explicitly covered, >> e.g. +"/a/b/c" : { "foo" : "bar"} >> the draft only talks about manipulating non-object members of a >> document. > > > In > <http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-01#section-4.1>, > the example is setting an array as value. But I agree that it would be good > to clarify the term "value". > > >> - the draft does explicitly cover manipulating arrays of values. >> that's not applicable >> to the mk data model (array values are not supported). furthermore, >> there's >> no equivalent jcr operation. > > > Ack. So this would be something that can be syntactically expressed in "JSOP > Diff", but wouldn't be supported by the MK. Is this a problem? i don't know yet, but probably not. we would have to clearly document that restriction on the microkernel commit method. > > >>> One open issue seems to be escaping inside pathString; if a JSON member >>> contains a forward slash ("/"), how is it represented in a pathString? >>> >>> 1) We could define that it's not allowed to be in a member name, thus we >>> don't need escaping, or >>> >>> 2) We could adopt the escaping syntax from JSON Pointer (now "^"). >>> >>> 1) has the advantage of being simple. >>> >>> 2) has the advantage that it would work with generic JSON data, something >>> I >>> think we need to deal with if we want to use JSOP diff outside the MK >>> work. >>> >>> Thoughts? >> >> >> since forward slashes are not allowed in jcr names i guess it's not an >> issue >> for JSOP diff since "/" would need be encoded already according to the >> jcr rules. i would prefer 1) but i am fine with either 1) or 2). > > > My proposal is to start with 1) but to document the restriction; we can > still introduce escaping later on if we find out that this is a problem. agreed. cheers stefan > > Best regards, Julian
