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 14:18:58 GMT
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.


Maybe sometimes simple is too simple :-)

Best regards, Julian

View raw message