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 14:07:30 GMT

>>I think our work will influence IETF JSON Diff. The "test" and "move"
>> operation were already added, I guess the "copy" operations will be
>> 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": {} } }


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


>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,
>> example "/foo/lastModified*date" would mean the value type is date.
>> that could only be a convention, it might make sense to document it in
>> 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.


View raw message