Hi, > >> > * The data model specifies that a node contains an "an array of > >> > (child) node objects" and seems to imply that child nodes are always > >> > orderable. This is a major design constraint for the underlying > >> > storage model that doesn't seem necessary (a higher-level component > >> > could store ordering information explicitly) or desirable (see past > >> > discussions on this). To avoid this I think child nodes should be > >> > treated as an unordered set of name/node mappings. > > i don't think that it is a major design constraint in general. > > since in a jcr repository a lot of content is expected to be > > ordered (-> nt:unstructured) we should IMO support this in the mk > > and don't delegate this to the upper layer. > > > > i agree that very 'flat' nodes are a special case. > > how about stating something along the line of: > > > > child nodes are an orderable (implying 'ordered' of course) set > > of name/node mappings. however, if the size of the set > > exceeds a certain (discoverable?) trheshold, it might just > > ordered, but not orderable. > > > > I thinks that this is better tackled the other way around: store order > explicitly as Jukka proposed. This will basically have the same > observable effect as you describe but OTOH free the implementation from > the constraint of having to maintain the order. Furthermore it leaves > the decision for the threshold to the upper layers which can decide > individually what's good for them.
I agree with Michael on where to maintain the order of child nodes when needed. However, I don't agree that there should be a threshold where the behavior will flip. Even if it is documented, people will probably rely on the initial behavior when they test their application with a small set of content and then find out their application breaks as more content is added. I think it is better to have consistent behavior. Regards Marcel
