Hi David et al, (...definite opportunity for a book here David :)) "People use SNS mostly for large, unordered collections, which it is definitely not what they are designed for."
When mapping our object model to JCR I used SNS for almost all composition relationships, both ordered and unordered. Mainly as I assumed this was the intended way to model anonymous composition. It never quite felt right for the ordered case as you have to then make the parent object 'ordered' which seemed wrong as then all multi-node properties are 'ordered'.....so this thread is proving an eye opener. I tried to think of an abstract example in the car/seat use-case but the group still managed to find appropriate 'names' for the nodes :) If I think hard enough I can come up with semi-useful node names for most of the relationships in our model. So can we conclude this thread with a JCR pattern/best practise for modelling the following? * ordered composition examples e.g. an ordered list * unordered composition example e.g. a bag Regards, Shaun. -----Original Message----- From: David Nuescheler [mailto:[EMAIL PROTECTED] Sent: 09 July 2007 13:28 To: [email protected] Subject: Re: DM Rule #4: Beware of Same Name Siblings. Hi Shaun, thanks for your feedback. > Our model includes various SNS and while 'yes' I agree that [1],[2] etc > aspect can cause problems how else would you model anonymous composition > where Object A contains multiple instances of Object B, where Object B has > no unique & distinguishing concept of a name. > For example, > [acme:Car] > acme:seats multiple acme:Seat > What would be your preferred way to model the above in a green field model? I agree with Felix on using a subnode. If I read Felix's recommendation we would end up with something like: /mercedes/s-class/s-500/seats/0 /mercedes/s-class/s-500/seats/1 /mercedes/s-class/s-500/seats/2 Based on the idea that arbitrary numbers hardly ever qualify as a "good name", I would probably go further in leveraging my hierarchy and use something like: /mercedes/s-class/s-500/seats/driver /mercedes/s-class/s-500/seats/passenger /mercedes/s-class/s-500/seats/back-left I think this adds context for people navigating the hierarchy. Even for people searching the content repository and for whatever reason finding a "seat", they will automatically know that they are looking at a drivers seat of an s-500 mercedes without any further information beyond the path. In my mind this context information is a valuable asset and therefore should not be given away lightly. It may well be that I misunderstood the "seat" example, so please let me know if this all makes sense. regards, david > -----Original Message----- > From: David Nuescheler [mailto:[EMAIL PROTECTED] > Sent: 07 July 2007 12:17 > To: [email protected] > Subject: DM Rule #4: Beware of Same Name Siblings. > > Explanation > --- > While Same Name Siblings (SNS) have been introduced into the spec to > allow compatibility with data structures that are designed for and > expressed through XML and therefore are extremely valuable to JCR, SNS > come with a substantial overhead and complexity for the repository. > > Any path into the content repository that contains an SNS in one of > its path segments becomes much less stable, if an SNS is removed or > reordered, it has an impact on the paths of all the other SNS and > their children. > > For import of XML or interaction with existing XML SNS maybe necessary > and useful but I have never used SNS, and never will in my "green > field" data models. > > Example: > --- > Use > > /content/myblog/posts/what_i_learned_today > /content/myblog/posts/iphone_shipping > > instead of > > /content/blog[1]/post[1] > /content/blog[1]/post[2] > >
