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/[EMAIL PROTECTED] /contacts/[EMAIL PROTECTED] ...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/[EMAIL PROTECTED]/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
