Explanation: --- In relational databases IDs are a necessary means to express relations, so people tend to use them in content models as well. Mostly for the wrong reasons through.
If your content model is full of properties that end in "Id" you probably are not leveraging the hierarchy properly. It is true that some nodes need a stable identification throughout their live cycle. Much fewer than you might think though. mix:referenceable provides such a mechanism built into the repository, so there really is no need to come up with an additional means of identifying a node in a stable fashion. Keep also in mind that items can be identified by path, and as much as "symlinks" make way more sense for most users than hardlinks in a unix filesystem, a path makes a sense for a lot of applications to refer to a target node. More importantly, it is _mix_:referenceable, which means that it can be applied to a node at the point in time when you actually need to reference it. So let's say, just because you would like to be able to potentially reference a node of type "Document" does not mean that your "Document" nodetype has to extend from mix:referenceable in a static fashion since it can be added to any instance of the "Document" dynamically. Example: --- use: /content/myblog/posts/iphone_shipping/attachments/front.jpg instead of: [Blog] - blogId - author [Post] - postId - blogId - title - text - date [Attachment] - attachmentId - postId - filename + resource (nt:resource)
