jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: JSOP vs JSON-Patch, was: [Jackrabbit Wiki] Update of "Jsop" by stefan
Date Wed, 21 Mar 2012 13:07:43 GMT
On 2012-03-21 13:47, Stefan Guggisberg wrote:
> On Tue, Mar 20, 2012 at 6:53 PM, Julian Reschke<julian.reschke@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?

> 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.

>> 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?

>> 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.

Best regards, Julian

Mime
View raw message