Hi,
Am 14.12.2011 um 14:10 schrieb Thomas Mueller:
> 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.
Absolutely. I tend to think any Sling JSOP implementation would best reuse an
existing parser instead of writing its own stuff.
>
>> 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).
Is this IETF draft or your extension ? Anyways, it feels extremely strange.
Regards
Felix
