Vincent Massol wrote: +1 +1 +1 At least it should still exist because in velocity and apis it's a good and simple way to define the document. When we render links it's important to only have to run an "exist" call on the DB and not load the full document. We have seen cases where not doing that was an issue. So lazy loading is good. I think our users do need a simple Space taxonomy. It is needed to have namespaces (page with the same name in two different spaces), so tags will be an issue. Some users are even asking for tree of spaces (which we handle for rights and preferences but not for differentiated naming) Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

Vincent Massol wrote: See below. See below. +1 DocumentName whenever possible, but also allow Strings for backwards compatibility, and for easy access from scripts. At leas for the moment, maybe later we can drop strings, if we see that working with DocumentName-s is good, simple and easy. I don't know why we need to store wiki objects. As far as things are now, wikis don't share the same database/schema. Sure, the document should be able to access the wiki it belongs to, but I see no need for a persistent relationship between the two. A reference to the wiki object can be added when creating the Document object. As for spaces, right now I think that first we must define what a space is (or will be), and then see if it makes sense to make the link between documents and spaces, and if this link should be persisted in the Document object. There have been many posts on the folksonomy vs ontology, tags vs hierarchies, loose semantics vs rigid semantics debates. So far, neither is winning (at least not on all points, and not for everybody). My take is that tags have the advantage that they are much more flexible and sometimes better at organizing data, but hierarchies are needed, too. We cannot get rid of spaces. A lot of users require them (and require even deeper hierarchies). A lot of our features and strong points come from here, although these features could be mostly reworked to be based on tags. So, I think that we should put more power in tags. And we should keep spaces. And add hierarchical spaces, too. But we should change the way spaces and documents work. The major problem with the current way spaces are implemented is that there is a strong link between spaces, document IDs, URLs and the whole platform code. This is wrong. URLs should be a way to access the wiki, and not a strict, unique reference to documents. Spaces should be a way to organize documents, not a major part of the document definition. Like in a FS, a file is NOT defined by the directory it resides in. You can move files around without changing the way the work or the data they contain. We should do the same. To go further, documents are not at all dependent on the document name, either. In a modern FS, a document can have several names in several places, as _hard_ and symbolic links. One of the best things about XWiki (and in general of wikis as opposed to CMSs) is that documents have names, and not just numbers. But XWiki went too far with this, by using the names as internal identifiers. Confluence got it right, and internal IDs are unique identifiers, but pretty names are displayed/used by the users. - Spaces should not be a part of documents, but a "feature", or "property" of them. - A document should have _at least_ one access name - The way URLs identify documents should be pluggable. We kind of have this in one direction, with the URL factories, but we don't have it the other way around. The XWiki giant class has only one method for finding a document, given a URL. - We should also have pluggable document identifier components. For example, the language field should not be hardcoded in the Document class, but another optional feature of documents. The space feature as well. - When retrieving documents from the database, retrieve not an exactly identified document, but one that best matches a set of criterias. For example, retrieve a document that has the "name" "WebPreferences" (matches 172 documents); and which has the "space" "Documents.Media.Music" (matches 3 documents); and which has the "language" "en" (matches 1 document). All these should be optional document properties. The only required document property is the unique ID. - All these document identification features could (should?) be components (as in Plexus/IoC components). Now, back to the DocumentName, it should not have a strong fixed type (wiki, name, space and language), but a loose collection of features. It should be able to have a constructor that interprets one map-like string (like Vincent proposed), a constructor that can interpret old-style document names, a constructor that receives a map (string -> string, feature name -> value), and a plain constructor, with the features being set later with identifier.set("property", "value"). Since these are loose features, we can allow a Document object to have two names, or three spaces. Do we want to link features between them? Like, 2 names x 3 spaces = 6 classic identifiers, or should we be able to say the name N1 is only valid in space S1, and N2 is valid in S2 and S3. And it should not be called DocumentName. Maybe DocumentIdentifier is better? I'm too sleepy right now to come up with a good name. Back to the DocumentNameFactory, as stated above, we should have several such factories, each one able to construct a document identifier from some specific data. ServletURLDocumentIndentifierFactory accepts URLs as used in a servlet-based wiki, PortletURLDocumentIdentifierFactory accepts URLs as used in a portlet wiki, HierarchicalServletURLDocumentIndentifierFactory also accepts hierarchies, or extended spaces, XmlRpcDocumentIdentifierFactory works with XmlRpc, and so on. One thing we must keep in mind is that XWiki also uses URLs to identify attachments and files inside attachments, and skin files located in the FS. Thus, I'm not sure these factories should return document identifiers, or a more general resource identifier (this would allow to identify objects and properties, too, or even the generic fragment identifiers Stephane used in http://arkub.net/xwiki/bin/Blog/Farewell_SMTP). On the tags vs. document features, I see them as related, but different in one essential point: features are typed tags. Now, do we want them to share the same storage mechanism, and the same way to access them from the Document object? Should they be stored together, with normal tags as features with no type, or with features as tags with a special syntax? -- Sergiu Dumitriu http://purl.org/net/sergiu/

Vincent Massol wrote: What about optional - String language? For example XWikiStoreInterface#loadBacklinks should return languages of documents too. This causes XWIKI-1325. -- Artem Melentyev