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
