What would be the prescribed method when saving people? Seems a bit odd to try and shoehorn people's names into node names, dealing with naming collisions etc.
ie. /contacts/johndoe /contacts/janedoe etc. Maybe just using /contact/contact[1] /contact/contact[2] and using uuid's to reference individuals make sense for this? Regards, Mark On 7/9/07, Raphael Wegmueller <[EMAIL PROTECTED]> wrote:
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] > > > > >
-- Best, Mark Waschkowski
