Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of mueller@adobe.com designates
 64.18.1.35 as permitted sender)
From: Thomas Mueller <mueller@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Wed, 14 Dec 2011 13:10:37 +0000
Subject: Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Thread-Topic: [Jackrabbit Wiki] Update of "Jsop" by stefan
Thread-Index: Acy6Ycc41xtPu75hTtSD/Jyb/Q+yPw==
Message-ID: <CB0E5994.21408%mueller@adobe.com>
In-Reply-To: <4EE88C8C.20703@apache.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

In my view, we should try to stay compatible with DavEx JSOP, except for
those cases where DavEx JSOP is problematic:

- I think it didn't require paths to be double quoted?

- Move operations were defined as > "/from": "/to" [#before|#after], which
is problematic from a parser point of view, because optional token at the
end of "logical line" are ambiguous (the token might belong to the next
logical line).

>Sling JSOP

I believe the 'diff' part within Sling isn't implemented yet, right? I
guess The Sling JSOP should be compatible with what we do for Jackrabbit 3
as much as possible, but the use cases might be slightly different.

>IETF JSON Diff

I think our work will influence IETF JSON Diff. The "test" and "move"
operation were already added, I guess the "copy" operations will be added
as well, because it simply makes sense to have such an operation.

I think the standards are still ambiguous in a few areas. One is the exact
specification of a "path" and "path element". I saw that
draft-pbryan-json-patch-02.txt assumes a number at the end of a path is an
array index: "Moving an Array Element" - "/foo/1" refers to the second
element in the array "/foo". That could mean number are not allowed as
path elements (there could be no node called "/foo/1"). Another problem we
ran into is adding a 'options mechanism' in the getNodes call. One idea is
to append ";hash" to the path if the server should include the content
hash for each node. That means getNode("/foo;hash") would return the node
"/foo", together with the ":hash" property (in our implementation). But
that would mean semicolons are not allowed in path elements. Then, one
idea was the convention to append the data type to the property name, for
example "/foo/lastModified*date" would mean the value type is date. While
that could only be a convention, it might make sense to document it in the
standard as such.

Regards,
Thomas