jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Date Wed, 14 Dec 2011 13:10:37 GMT

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.


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.


View raw message