Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of mwaschkowski@gmail.com
 designates 64.233.162.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=cQwjwRgGcfwzos5BJGkOS47uOnQAHciCvfUUuqBntYBatBKJ0womTvYs8d2iyTQCgRT5DOZwaZIMYRkIXrF3beXuuQ4/sPm4Io+/qjPcPSMcs/Ahil4fsKNMGvdX0EgTm+DrS8eGkBTovVe6ewUeLMINEaJKO1ePCTUndpqFPKA=
Message-ID: <76a6ebd00707091316q776df0b9k950a82df44841ebc@mail.gmail.com>
Date: Mon, 9 Jul 2007 16:16:26 -0400
From: "Mark Waschkowski" <mwaschkowski@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: DM Rule #4: Beware of Same Name Siblings.
In-Reply-To: <140176f0707090614y4620a324idd2f8cb0f0e509bf@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_23598_9655592.1184012186570"
References: <eb7e2190707070416l58e0636crf9829d4e6014c57d@mail.gmail.com>
	 <003401c7c0a6$d1238aa0$736a9fe0$@co.uk>
	 <eb7e2190707090528u7ceec6aal136ec2425696076e@mail.gmail.com>
	 <140176f0707090614y4620a324idd2f8cb0f0e509bf@mail.gmail.com>

------=_Part_23598_9655592.1184012186570
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <raphael.wegmueller@gmail.com> 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 <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]
> > >
> > >
> >
>


-- 
Best,

Mark Waschkowski

------=_Part_23598_9655592.1184012186570--