maybe shaun's example is more about seat types rather than locations... ;)
/audi/a8/w12/seats/sports /audi/a8/w12/seats/comfort /audi/a8/w12/seats/standard either way, the point is that node names should as meaningful as possible in their given context (parent). On 7/9/07, David Nuescheler <[EMAIL PROTECTED]> wrote:
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] > >
