jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raphael Wegmueller" <raphael.wegmuel...@gmail.com>
Subject Re: DM Rule #4: Beware of Same Name Siblings.
Date Mon, 09 Jul 2007 13:14:28 GMT
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 <david.nuescheler@gmail.com> 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:david.nuescheler@gmail.com]
> > Sent: 07 July 2007 12:17
> > To: users@jackrabbit.apache.org
> > 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]
> >
> >
>

Mime
View raw message