Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 65529 invoked from network); 10 Jul 2007 06:48:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Jul 2007 06:48:43 -0000 Received: (qmail 52080 invoked by uid 500); 10 Jul 2007 06:48:44 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 52065 invoked by uid 500); 10 Jul 2007 06:48:44 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 52056 invoked by uid 99); 10 Jul 2007 06:48:44 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2007 23:48:44 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of david.nuescheler@gmail.com designates 209.85.146.180 as permitted sender) Received: from [209.85.146.180] (HELO wa-out-1112.google.com) (209.85.146.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2007 23:48:41 -0700 Received: by wa-out-1112.google.com with SMTP id m34so1807143wag for ; Mon, 09 Jul 2007 23:48:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=St7MA0ixif0iCTZ8F2NK26pjBn9puSo4tywGvwIeLtcH519blCHPO6OjTclEXCCxJDxMYhNv9g+fAjyhUJOAS5hiSZwQgLJywV4GDfuFCtV28Wli9YFkowaW22fFZLQO8eEaRCk1Upr7rQpe8GjFjGuDhHztuzmaQyIwsUclZbM= 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:content-transfer-encoding:content-disposition:references; b=cJobcs9EwUVzatxwgqy/KYmnZ/XwCtVqkzvaKvpdau/sMvoNw6mWK3M+jtenSV0CQkcowaiofqKeBUBcyM9EEx8TFMdQcLkhmKrDGil+Z3uWDyfjOsnuQqR6MKmY0ksJZqWDRYtJihIkMrNJfb3rKENDUoqMyfIpStllnuI+L+I= Received: by 10.115.74.1 with SMTP id b1mr3876952wal.1184050100558; Mon, 09 Jul 2007 23:48:20 -0700 (PDT) Received: by 10.115.49.7 with HTTP; Mon, 9 Jul 2007 23:48:20 -0700 (PDT) Message-ID: Date: Tue, 10 Jul 2007 08:48:20 +0200 From: "David Nuescheler" To: users@jackrabbit.apache.org Subject: Re: DM Rule #4: Beware of Same Name Siblings. In-Reply-To: <76a6ebd00707091316q776df0b9k950a82df44841ebc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003401c7c0a6$d1238aa0$736a9fe0$@co.uk> <140176f0707090614y4620a324idd2f8cb0f0e509bf@mail.gmail.com> <76a6ebd00707091316q776df0b9k950a82df44841ebc@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org 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 change. 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... /contacts/0 /contacts/1 /contacts/2 /contacts/3 ... 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... /contacts/david@day.com /contacts/dev@jackrabbit.apache.org ...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 information. Let's assume the path should ever surface, for example in a URL, then... /contacts/mark@gmail/ituneslibrary/Nelly Furtado/Loose/Say It Right will give the user much more context than ... /contacts/contact[42342]/ituneslib/artist[234]/album[2]/track[8] ..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... ;) regards, david