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
