jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: DM Rule #4: Beware of Same Name Siblings.
Date Mon, 09 Jul 2007 12:28:11 GMT
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