You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2011/12/14 11:39:06 UTC
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
On 2011-12-14 11:28, Apache Wiki wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.
>
> The "Jsop" page has been changed by stefan:
> http://wiki.apache.org/jackrabbit/Jsop?action=diff&rev1=30&rev2=31
>
> Comment:
> added 'copy'
>
> SET ::= "^" STRING ":" ATOM | ARRAY
> REMOVE ::= "-" STRING
> MOVE ::= ">" STRING ":" (STRING | "{" STRING ":" STRING "}")
> + COPY ::= "*" STRING ":" (STRING | "{" STRING ":" STRING "}")
> TEST ::= "=" STRING ":" ATOM | ARRAY
> METADATA ::= "@" OBJECT
> EXTENSION ::= OP STRING ":" (OBJECT | ATOM | ARRAY)
> @@ -129, +130 @@
>
> * removeNodeDiff
> * removePropertyDiff
> * moveNodeDiff
> + * copyNodeDiff
> * testProperty
> * metaData
> ...
Not convinced.
If we think this is needed we should bring it up within the IETF so JSON
Patch gets this, too.
Or have we given up on that?
Best regards, Julian
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Michael Dürig <md...@apache.org>.
On 14.12.11 15:02, Stefan Guggisberg wrote:
> On Wed, Dec 14, 2011 at 3:54 PM, Michael Dürig<md...@apache.org> wrote:
>> On 14.12.11 14:18, Julian Reschke wrote:
>>>>
>>>> The use case is that the client should have a way to detect the JCR data
>>>> type for unstructured data (JSON doesn't have a 'date' data type). For
>>>> the
>>>> MicroKernel, we currently use a different convention: we encode the data
>>>> type in the value.
>>>
>>>
>>> <insert-anti-JSON-pro-XML-rant-here/>
>>>
>>> Maybe sometimes simple is too simple :-)
>>>
>>
>> When we started using 'JSOP' and JSON for the jr3 Microkernel based
>> implementation, we didn't have a clear picture on how to map things to JCR.
>> The conception then was 'decorate it on top somehow'. As it is apparent from
>> this discussion, this isn't as easy as it seems without resorting to ad-hoc
>> extensions.
>
> WRT 'copy': not simple? ad-hoc extension? to what? a non-existing specification?
Ad-hoc since it is specifically targeted to the Microkernel's
requirements and we don't seem to care too much about existing
implementations nor about other, similar efforts. That's alright but
then let's not call it JSOP.
Michael
>>
>> This discussion just touched two of the paint points: copy and data types.
>> Others are: observation, locking, name spaces and remapping, access control,
>> ordering, properties and nodes with the same name, same name siblings...
>>
>> Michael
>>
>>
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Stefan Guggisberg <st...@gmail.com>.
On Wed, Dec 14, 2011 at 3:54 PM, Michael Dürig <md...@apache.org> wrote:
> On 14.12.11 14:18, Julian Reschke wrote:
>>>
>>> The use case is that the client should have a way to detect the JCR data
>>> type for unstructured data (JSON doesn't have a 'date' data type). For
>>> the
>>> MicroKernel, we currently use a different convention: we encode the data
>>> type in the value.
>>
>>
>> <insert-anti-JSON-pro-XML-rant-here/>
>>
>> Maybe sometimes simple is too simple :-)
>>
>
> When we started using 'JSOP' and JSON for the jr3 Microkernel based
> implementation, we didn't have a clear picture on how to map things to JCR.
> The conception then was 'decorate it on top somehow'. As it is apparent from
> this discussion, this isn't as easy as it seems without resorting to ad-hoc
> extensions.
WRT 'copy': not simple? ad-hoc extension? to what? a non-existing specification?
cheers
stefan
>
> This discussion just touched two of the paint points: copy and data types.
> Others are: observation, locking, name spaces and remapping, access control,
> ordering, properties and nodes with the same name, same name siblings...
>
> Michael
>
>
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Michael Dürig <md...@apache.org>.
On 14.12.11 14:18, Julian Reschke wrote:
>> The use case is that the client should have a way to detect the JCR data
>> type for unstructured data (JSON doesn't have a 'date' data type). For
>> the
>> MicroKernel, we currently use a different convention: we encode the data
>> type in the value.
>
> <insert-anti-JSON-pro-XML-rant-here/>
>
> Maybe sometimes simple is too simple :-)
>
When we started using 'JSOP' and JSON for the jr3 Microkernel based
implementation, we didn't have a clear picture on how to map things to
JCR. The conception then was 'decorate it on top somehow'. As it is
apparent from this discussion, this isn't as easy as it seems without
resorting to ad-hoc extensions.
This discussion just touched two of the paint points: copy and data
types. Others are: observation, locking, name spaces and remapping,
access control, ordering, properties and nodes with the same name, same
name siblings...
Michael
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-12-14 15:32, Thomas Mueller wrote:
> Hi,
>
>> <insert-anti-JSON-pro-XML-rant-here/>
>
> Pro XML? Are you serious?
Absolutely.
>> Maybe sometimes simple is too simple :-)
>
> That's why we extend it :-)
> ...
Indeed. We are extending something simple step by step with things that
are already available in XML. But this time, everybody makes up their
own extensions.
Best regards, Julian
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
><insert-anti-JSON-pro-XML-rant-here/>
Pro XML? Are you serious?
>Maybe sometimes simple is too simple :-)
That's why we extend it :-)
Regards,
Thomas
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-12-14 15:07, Thomas Mueller wrote:
> Hi,
>
>>> 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.
>
> Well, they are part of draft-pbryan-json-patch-02.txt already.
Sorry for being unclear. I was referring to "copy".
>>> there could be no node called "/foo/1"
>>
>> 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.
>
> Not necessarily. What would be the result of:
>
> + "/test": {}
> + "/test/foo/0": {}
>
> Would it be:
>
> "test": { "foo": { "0": {} } }
>
> or:
>
> "test": { "foo": [ {} ] } }
>
> (I'm not saying we should support all that - I guess for the MicroKernel
> we will not - just in theory).
Or maybe a failure, because after the first step, "/test/foo" doesn't
exist yet.
Let's check:
The "add" operation adds a new value to the target document at the
specified location. The location must reference one of: the root of
the target document, a member to add to an existing object, or an
element to add to an existing array. The operation object contains a
"value" member, which specifies the value to be added.
Indeed. <https://tools.ietf.org/html/draft-pbryan-json-patch-04#section-4.1>
>> That being said this sounds like a valid reason to introduce a [n]
>> notation for referring to array members. (Will follow up).
>
> Yes, this would be clearer:
>
> + "/test": {}
> + "/test/foo[0]": {}
>
> But it would mean that both [ and ] are not allowed in path elements.
Nope, it would mean that they need to be escaped, just like "/".
>>> "/foo;hash"
>
>> Urgs.
>
>> From this I conclude you don't have a better solution for this problem :-)
>
>>> 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?
>
> The use case is that the client should have a way to detect the JCR data
> type for unstructured data (JSON doesn't have a 'date' data type). For the
> MicroKernel, we currently use a different convention: we encode the data
> type in the value.
<insert-anti-JSON-pro-XML-rant-here/>
Maybe sometimes simple is too simple :-)
Best regards, Julian
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>>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.
Well, they are part of draft-pbryan-json-patch-02.txt already.
>>there could be no node called "/foo/1"
>
>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.
Not necessarily. What would be the result of:
+ "/test": {}
+ "/test/foo/0": {}
Would it be:
"test": { "foo": { "0": {} } }
or:
"test": { "foo": [ {} ] } }
(I'm not saying we should support all that - I guess for the MicroKernel
we will not - just in theory).
>That being said this sounds like a valid reason to introduce a [n]
>notation for referring to array members. (Will follow up).
Yes, this would be clearer:
+ "/test": {}
+ "/test/foo[0]": {}
But it would mean that both [ and ] are not allowed in path elements.
> > "/foo;hash"
>Urgs.
>From this I conclude you don't have a better solution for this problem :-)
>> 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?
The use case is that the client should have a way to detect the JCR data
type for unstructured data (JSON doesn't have a 'date' data type). For the
MicroKernel, we currently use a different convention: we encode the data
type in the value.
Regards,
Thomas
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Julian Reschke <ju...@gmx.de>.
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
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-12-14 16:11, Thomas Mueller wrote:
> Hi,
>
>> It *is* a sub-delim, but the quoted text above is irrelevant.
>
> I just wanted to show one example of a URI where the semicolon is used.
>
>> it behaves exactly the same as "." or
>> ",", for example.
>
> Yes, only that a dot is quite common in JCR paths. A comma might be
> acceptable, but I personally prefer semicolon. Anyway, if we want to use
> http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02 as the
> specification for a path, then quite many characters would have to be
> escaped unfortunately. I guess the escaping would only be required in the
> getNodes(..) call, not in the JSOP / JSON Patch / returned JSON.
>
>> You could make it "?hash&index".
>
> That's true. But ";hash;index" is easier in my view (you only need one
> character: ";", which you need two characters when using the "?" and "&").
>
>> So essentially you want an extension mechanism on the identifier
>> notation.
>
> Yes.
>
>> I don't think this is a good idea.
>
> Too bad. Of course you are free to say you don't think it's a good idea,
> but it doesn't help much if you have no alternative solution for the given
> problem.
Well, the alternative is not to overload the pointers with additional
information.
>> In JSON Pointer, a pointer identifies a JSON member.
>
> The JSON Pointer specification
> http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02 actually
> already refers to RFC 3986, that means the "/foo;hash" would be OK I guess
> (syntactically). But semantically it wouldn't be clear that it refers to
> the same entity as "/foo".
Actually it's totally clear that it *does* refer to a different entity.
Best regards, Julian
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>It *is* a sub-delim, but the quoted text above is irrelevant.
I just wanted to show one example of a URI where the semicolon is used.
>it behaves exactly the same as "." or
>",", for example.
Yes, only that a dot is quite common in JCR paths. A comma might be
acceptable, but I personally prefer semicolon. Anyway, if we want to use
http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02 as the
specification for a path, then quite many characters would have to be
escaped unfortunately. I guess the escaping would only be required in the
getNodes(..) call, not in the JSOP / JSON Patch / returned JSON.
>You could make it "?hash&index".
That's true. But ";hash;index" is easier in my view (you only need one
character: ";", which you need two characters when using the "?" and "&").
>So essentially you want an extension mechanism on the identifier
>notation.
Yes.
> I don't think this is a good idea.
Too bad. Of course you are free to say you don't think it's a good idea,
but it doesn't help much if you have no alternative solution for the given
problem.
>In JSON Pointer, a pointer identifies a JSON member.
The JSON Pointer specification
http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02 actually
already refers to RFC 3986, that means the "/foo;hash" would be OK I guess
(syntactically). But semantically it wouldn't be clear that it refers to
the same entity as "/foo".
Regards,
Thomas
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-12-14 15:24, Thomas Mueller wrote:
> Hi,
>
>> 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.
>
> This is our own extension. I agree it's strange, similar to query
> parameters in URIs:
>
> http://www.day.com/day/en/toolbar/search.html?q=test
>
>
> The ";" is a sub-delim in RFC 3986 (Uniform Resource Identifier (URI):
> Generic Syntax) - see also http://tools.ietf.org/html/rfc3986 - quoting:
>
> "
> 5.4. Reference Resolution Examples
> Within a representation with a well defined base URI of
> http://a/b/c/d;p?q
>
> "
It *is* a sub-delim, but the quoted text above is irrelevant. With
respect to reference resolution, it behaves exactly the same as "." or
",", for example.
> We have used ";hash" and not "?hash" because the "?" is a gen-delim and
> not a sub-delim; the correct syntax would need to be "?hash=true", also
Um, no.
> other options would need to be added with a "&", in the form
> "?hash=true&index=true" instead of the shorter ";hash;index".
You could make it "?hash&index".
> I'm not saying that a "JSOP path" should be an "RFC 3986 URI". But I guess
> a "path" would be somewhat similar (possibly simpler), and have a somewhat
> similar extension mechanism for additional features.
So essentially you want an extension mechanism on the identifier
notation. I don't think this is a good idea.
In JSON Pointer, a pointer identifies a JSON member.
In the JSOP diff format (as initially planned), a pointer is a path
identifying a JCR item.
Best regards, Julian
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>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.
This is our own extension. I agree it's strange, similar to query
parameters in URIs:
http://www.day.com/day/en/toolbar/search.html?q=test
The ";" is a sub-delim in RFC 3986 (Uniform Resource Identifier (URI):
Generic Syntax) - see also http://tools.ietf.org/html/rfc3986 - quoting:
"
5.4. Reference Resolution Examples
Within a representation with a well defined base URI of
http://a/b/c/d;p?q
"
We have used ";hash" and not "?hash" because the "?" is a gen-delim and
not a sub-delim; the correct syntax would need to be "?hash=true", also
other options would need to be added with a "&", in the form
"?hash=true&index=true" instead of the shorter ";hash;index".
I'm not saying that a "JSOP path" should be an "RFC 3986 URI". But I guess
a "path" would be somewhat similar (possibly simpler), and have a somewhat
similar extension mechanism for additional features.
Regards,
Thomas
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Felix Meschberger <fm...@adobe.com>.
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
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Thomas Mueller <mu...@adobe.com>.
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
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Michael Dürig <md...@apache.org>.
> spi2dav, for which this has been invented for, simply does a COPY
> operation. Note this is a workspace operation not needed in batch
> operations.
>
>>> If we think this is needed we should bring it up within the IETF so JSON
>>> Patch gets this, too.
>>
>> sure, please go ahead.
>
> A-hem, no, I won't, because I don't think it's a good idea.
>
>>> Or have we given up on that?
>>
>> why would that be the case?
>
> I keep seeing additions to the format which are not motivated by the
> original use case, and have not been proposed outside this small group.
While I can see the need for these additions for the jr3 Microkernel as
it is currently designed, I also fear that we end up with yet another
variant of 'JSOP'. I don't like this personally but I also do not
understand what our goals and priorities are here: If we do care about
compatibility (i.e. Sling JSOP, DavEx JSOP, IETF JSON Diff) we shouldn't
introduce ad-hoc changes before having evaluated their impacts. If we
don't care we should probably refrain from calling this JSOP.
Michael
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-12-14 11:51, Stefan Guggisberg wrote:
> ...
>> Not convinced.
>
> i think it's useful and needed. how else would
> you support the javax.jcr.Workspace#copy use case?
> ...
spi2dav, for which this has been invented for, simply does a COPY
operation. Note this is a workspace operation not needed in batch
operations.
>> If we think this is needed we should bring it up within the IETF so JSON
>> Patch gets this, too.
>
> sure, please go ahead.
A-hem, no, I won't, because I don't think it's a good idea.
>> Or have we given up on that?
>
> why would that be the case?
I keep seeing additions to the format which are not motivated by the
original use case, and have not been proposed outside this small group.
Best regards, Julian
Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Posted by Stefan Guggisberg <st...@gmail.com>.
On Wed, Dec 14, 2011 at 11:39 AM, Julian Reschke <ju...@gmx.de> wrote:
> On 2011-12-14 11:28, Apache Wiki wrote:
>>
>> Dear Wiki user,
>>
>> You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki"
>> for change notification.
>>
>> The "Jsop" page has been changed by stefan:
>> http://wiki.apache.org/jackrabbit/Jsop?action=diff&rev1=30&rev2=31
>>
>> Comment:
>> added 'copy'
>>
>> SET ::= "^" STRING ":" ATOM | ARRAY
>> REMOVE ::= "-" STRING
>> MOVE ::= ">" STRING ":" (STRING | "{" STRING ":" STRING "}")
>> + COPY ::= "*" STRING ":" (STRING | "{" STRING ":" STRING "}")
>> TEST ::= "=" STRING ":" ATOM | ARRAY
>> METADATA ::= "@" OBJECT
>> EXTENSION ::= OP STRING ":" (OBJECT | ATOM | ARRAY)
>> @@ -129, +130 @@
>>
>> * removeNodeDiff
>> * removePropertyDiff
>> * moveNodeDiff
>> + * copyNodeDiff
>> * testProperty
>> * metaData
>> ...
>
>
> Not convinced.
i think it's useful and needed. how else would
you support the javax.jcr.Workspace#copy use case?
>
> If we think this is needed we should bring it up within the IETF so JSON
> Patch gets this, too.
sure, please go ahead.
>
> Or have we given up on that?
why would that be the case?
cheers
stefan
>
> Best regards, Julian