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 Tue, 10 Jul 2007 06:48:20 GMT
Hi Mark,

Thanks a lot for your comment.

> /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?

I think it is important to look at (a) a meaningful path that is
explanatory of the context that you are in and (b) stable and unique
identification as two totally separate issues.

(a) Meaningful Path
[which really belongs into the "drive your hierarchy" section]

I mainly use SNS as a symptom to diagnose a hierarchy issue
in a content model.

People use SNS mostly for large, unordered collections,
which it is definitely not what they are designed for.

[note to self: propose a better way to address this problem in jsr-283]

SNS means that if you for example remove contact[1] the
paths of all other contacts and all their children will need to

Keep in mind that you force the repository to keep track of the
order of your contacts. Which you are actually not interested in
I would assume.

While I think that...


... is better from that perspective, since the repository does not
need to keep track of sort order and you get better path stability,

I would still try something like...


...which could be both meaningful and unique.

The reason for that is that someone who browses the repository
with any form of generic application ...

 (like http://jsr170tools.day.com/crx/browser/index.jsp)

... understands get a meaningful list of contacts and
the path reveals information about the context of the

Let's assume the path should ever surface, for example in a URL,

/contacts/mark@gmail/ituneslibrary/Nelly Furtado/Loose/Say It Right

will give the user much more context than ...


..and really, i cannot see a drawback for naming
nodes in a meaningful way. ;)

(b) Stable and Unique Identification
If your contacts should be mix:referenceable and therefore expose
a UUID so they can be referenced in my mind is decided by
the needs of you application.

If you application needs to reference users in a stable fashion and
you don't have something like a unique stable user-id (eg. an email
or a login...) mix:referenceable certainly would be the way to go.

(Important: this does not mean that a hard reference property
needs to be used to refer to or identify the node later)


Please keep in mind, this is just how I would model the content,
and I am convinced that someone could possibly come up with
a usecase where even I would warm up to the idea of using SNS... ;)


View raw message