[xwiki-devs] [Discussion] Is the reference part of the document? (was: Re: [xwiki-notifications] r28419 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web)

On 04/17/2010 01:19 PM, Vincent Massol wrote: Looks like we have different views on where the reference sits relative to the document. IMO, the reference is a pointer to the document, not a definitive aspect of the document. In the future, I'd like to make this separation even clearer by removing the reference from the document and into a distinct "naming" concept. This is more inline with filesystems: the path/name is just metadata pointing to the real document data, that helps finding the document (or, the content of that document), by means of visual/spatial exploration. And, IMHO, the fact that current systems have folders and hierarchies for this is just a matter of circumstances which actually seems to change with the consistent introduction of tags and semantic desktops. Folders are dying, long live the tags! JNDI also separates names from the data, it provides a means to access a resource using a name, but the name is not actually part of the resource. If JCR puts the name inside the document, then this looks like a bad design on their side. I know that my voice does not weight much against the panel of experts that were involved in standardizing the JCR spec, but I will maintain my position unless convinced otherwise with strong arguments. Back to my vision of the future XWiki, documents, objects and all other data should be identified by an internal GUID which is unique and never changes. Internal references (from properties to objects and from there to documents, and between attachment<->document, translations<->master, history<->document, etc.) are done only using these GUIDs, and not with names. Hashes, which already cause problems because of collisions, will be gone. Externally, the document name is held in another structure, so that a document can have different names (references) pointing to it, a different one for each translation (a strong point is that we have this "same document, different translations" feature, but its worst downside is that the name/URL doesn't make sense in all these translations, most of the times), aliases, redirects... So, renaming a document would just be a change in this external reference table, and not something related to the document content. And reverting document changes should not have any effect on the references (maybe more than one) that point to it. WDYT? The doc (content) is *exactly* the same. But, is the reference *inside* the document? Our current model does suggest so, but I'm thinking on an abstract level. I really, really don't think that the reference belongs inside the document. Yes, the document object needs to have a "current" reference, the one which was used for retrieving it, so that we can use it for generating URLs in the factory, for example. And maybe it should also hold another reference, the "default" reference for that document. I want to revert the content, not the rename. This is what I see in the history, eg. "allowed edit right for John Doe", and this is what I want to revert. The rename does *NOT* appear in the history, so I don't know that I'm reverting the rename. It would be an invisible side effect. If I want to revert the rename, I rename it back to its original place. Another reason not to automatically move the document back: A document is created with a name, let's say Main.X. Again, create some versions, rename to Main.Y. Create another document Main.X. When I want to revert Main.Y, what happens with the new Main.X? Do we lose it? Will the revert fail because the target document already exists? Will we use another new, non conflicting name like Main.X_1, which looks worst than either Main.X or Main.Y? Yes, all devs should say their opinion on this (I renamed the thread). Please help me more, I didn't understand your answer. -- Sergiu Dumitriu http://purl.org/net/sergiu/