Hi Tako, Thanks for your thoughtful comment.
But you have also lost any relation the two have, the only one who "knows" there is any relationship is your application. Any repository management tools you are going to use will have to be specifically written/adjusted to handle this.
I think it is important to understand that a content repository offers different ways of "Linking" content (I try not to use the term "reference", to avoid confusion) I guess one could assume that the two content nodes... /content/myblog/posts/iphone_shipping /content/myblog/comments/iphone_shipping/i_like_it_too ... are simply linked by their names. I guess this would be one way of linking. But I think the "link" be more explicit in addition to the "same name/path" linking. One way to do that would be to specify a link via path, by adding a path property to the "posts/iphone_shipping" that points to its comments. Of course one could also employ a weak (stringed UUID) or a hard reference to express the reference in a stable fashion (without changing the content hierarchy). I think it certainly makes sense to explain the different options that a content repository exposes to "link" content, and the characteristics of those... I feel a rule #8 coming up ;)
I do agree with your basic premise that you should think carefully about your hierarchy although it seems to go directly against your rule #1?
I can certainly agree to that, and I guess it sounds weird to on the one end "preach" about "data first" and then tell people to be really careful about the structure imposed in the hierarchy, right? Maybe it is because I think that the lightest, most intuitive, most quickly developed and re-organized structure can be implied by hierarchy. But I think you are right, I will have to work on the wording to express the relation between rule #1 and rule #2. regards, david
