On 9.12.11 11:23, Thomas Mueller wrote:
Hi,
if this is supposed to be a generic format for use outside
Jackrabbit. But I'm starting to believe it's not.
*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" ] }
-1 that's too weird for me. Also, duplicating data is always problematic.
I would rather say ordering is optional, and within Jackrabbit 3 we just
happen to support it. At least as long as orderable child nodes need to be
supported. Which, in my view, doesn't need to be the case. I would just
define that the order is undefined. File systems don't define an order
either either, and people don't seem to have a problem with that. If the
shell or a GUI tool orders them by name, and if they are ordered by name
on the server because the server uses a b-tree, then that's fine. But I
think it should not be required standard behavior.
I guess I should create an issue request in JSR-333.
I don't think this is necessary since orderable child nodes are optional
[1].
Michael
[1] http://www.day.com/specs/jcr/2.0/23_Orderable_Child_Nodes.html
