Support deeper hierarchical paths/names for documents

XWiki does a good job at separating documents into spaces. But this is not enough. I would like to see a tree-like structure of the documents, with more than two levels. A document URL would look like /bin/view/Staff/Management/Boarding/CEO, or /bin/view/Doc/Administration/Users/HowToBanUsers. This gives a more meaningful URI, and further separates documents in a space into subcategories.

The current model does not allow such a radical change, but this can be emulated, using another document property similar with "parent", something like "pathParent". This should be an invisible (in the UI) property, used only for generating URIs.

A few items to be considered:

• Backwards compatibility: Old APIs should work the same, old URLs should still be generated and accepted. Deeper hierarchies are a bonus, not a requrement, and a classic 2level hierarchy must be a valid deep hierarchy.
• Space + Name: The document space should still be the root of the hierarchy. The document name should be either the final part of the path, or the full path except the space part. The former case better suits the notion of "document name". The latter case has advantages described bellow.
• Circular references: When constructing the full document path, check for circular paths. In this case, the first path element that causes the circularity is discarded and the path is considered full.
• The same name for two document belonging to two different branches: Two distinct documents could share the same name and space, but not the same path, like XWiki/Admin and XWiki/Users/Admin. Using full paths, this would create no problem, but if we intend to preserve the backwards compatibility, current API and current storage, it would create conflicts. The solutions would be to require all documents to have different names, regardless of the path, or to use the full path for document identification.
• The double hierarchy: The "parent" attribute already defines a hierarchy, but this one is not reflected in the document URL, and permits documents from different spaces to be part of the same document link path. This hierarchy is based on a "relates to" relation. The "pathParent" element defines a new hierarchy, reflected in the URL, and is based on the "subitem of" relation. In my oppinion, these two can coexist, or a client could choose one of the two.
• Manually entering the URL of a non-existing document, and some of the documents on the path missing, too. Should we warn that the document does not exist, or that the path is invalid? If the user edits such a page, should the missing documents on the path be created too?

I say that this is an important feature, and it should be implemented at least for 1.0 final, if not sooner. I really don't like the fact that I have to put so many unrelated documents in the same category just because they belong to the same space. Plus, it can be done without major changes to the code, while preserving backwards compatibiiity.