Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of fmeschbe@adobe.com designates
 64.18.1.189 as permitted sender)
From: Felix Meschberger <fmeschbe@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Wed, 14 Dec 2011 14:04:37 +0000
Subject: Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Thread-Topic: [Jackrabbit Wiki] Update of "Jsop" by stefan
Thread-Index: Acy6aVCg2odpiLCQSIqO5L9ouxi5lQ==
Message-ID: <5927EAB7-5BF6-428E-8454-F47B560272C5@adobe.com>
References: <CB0E5994.21408%mueller@adobe.com>
In-Reply-To: <CB0E5994.21408%mueller@adobe.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

Am 14.12.2011 um 14:10 schrieb Thomas Mueller:

> Hi,
>=20
> In my view, we should try to stay compatible with DavEx JSOP, except for
> those cases where DavEx JSOP is problematic:
>=20
> - I think it didn't require paths to be double quoted?
>=20
> - Move operations were defined as > "/from": "/to" [#before|#after], whic=
h
> 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).
>=20
>> Sling JSOP
>=20
> 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.

Absolutely. I tend to think any Sling JSOP implementation would best reuse =
an existing parser instead of writing its own stuff.

>=20
>> IETF JSON Diff
>=20
> 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.
>=20
> I think the standards are still ambiguous in a few areas. One is the exac=
t
> 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 a=
n
> 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 w=
e
> ran into is adding a 'options mechanism' in the getNodes call. One idea i=
s
> 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).

Is this IETF draft or your extension ? Anyways, it feels extremely strange.

Regards
Felix=