On 2011-12-09 11:32, Thomas Mueller wrote:
Hi,
Not sure this is a good idea, as long as we pretend that this format has
something to do with JSON. The main purpose of JSON is that the objects
can be instantiated again in JavaScript, at which point the ordering
becomes undefined.
If one possible *client* isn't interested in the order, then that's not a
problem. The problem is that the *server* should keep the order, so that
The problem here is that we pretend that part of the syntax use JSON,
which implies you can use off-the-shelve JSON code to produce or consume
these parts. But you can't if you pretend that JSON object members have
an ordering.
clients that are interested in the order can work. Otherwise "move" with
"before" / "after" isn't that meaningful.
For now, JSON Patch allows moving *to* locations that can be identified
by JSON Pointers, so within the hierarchy and within arrays, but that
doesn't affect the ordering of non-array members.
What about making it an optional feature ("may")? It still possible for a
client to define the order using many "move" calls, but it's a bit strange
I have admit:
+ "/test": {"a": {}, "b": {}, "c": {}}
"/test/b": { "after": "/test/a" }
"/test/c": { "after": "/test/b" }
This will ensure the order is "a", "b", "c".
-1, if this is supposed to be a generic format for use outside
Jackrabbit. But I'm starting to believe it's not.
To make it a generic format, it needs to make sense in terms of mapping
a JCR hierarchy to JSON, and operations *applied* to JSON.
*If* we want to support ordered collections, than the JSON mapping
should contain additional information on the sort order of the members.
Like this:
{"a": {}, "b": {}, "c": {}, "{somejcrrelateduri}sortorder": [ "a", "b",
"c" ] }
Best regards, Julian
