jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Date Wed, 14 Dec 2011 13:44:08 GMT
On 2011-12-14 14:10, Thomas Mueller wrote:
> 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?

Indeed. We probably should treat this as bug to be fixed. (If we agree 
on that I can do that).

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

s/Diff/Patch/

> 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'm not sure about that. I would recommend that someone who believes 
that it is needed raises this point on the IETF apps-discuss mailing list.

> 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

Yes and no. It means you can't have both at the same time. At runtime 
given an object to which the patch is applied, it's unambiguous.

That being said this sounds like a valid reason to introduce a [n] 
notation for referring to array members. (Will follow up).

> 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

Urgs.

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

Could you elaborate on the use case?

Best regards, Julian


Mime
View raw message