Everything's related to one application is stored in a top level common area.

• Easy to do bulk operations such as the removal of all pages.

• Analogy of the spaces Applications, Data and Var with several operating systems structure such as Microsoft Windows (folders Program Files, Application Data, ...), Debian (/usr/, /var/, /home/) or MacOS.
• Each reserved functional area should be configurable.
• Each user page could be a space.

• There are far less reserved top level spaces than with L1, hence lowering the risk of conflicts with user data, all the more as the reserved spaces could be configurable.
• Content and data live in different spaces, but some users consider it's a downside.

Differences with L2:

• No reserved Data space: data goes where the user wants to.
• Top level spaces are introduced for Users and Groups.

• There is no encouragement to separate data from content by default, but the users can remain free to do so if they wish to.
• This non-separation is more in line with happens on a personal computer: files produced by applications such as LibreOffice or Gimp, while they consist of structure data just as an XWiki Diagram or XWiki Forum, are not stored in dedicated folders, they're simply stored where the user wants them to.
• The URLs for accessing content created by users are shorter (they don't include the Data prefix).
• There is a lack of namespace separation between application code files and content.

Differences with other layouts:

• Named according to the Unix layout: easy to understand for developers
• Dedicated space for all application configurations: easy to undertand where the configuration should take place
• Dedicated space for all content, should it be data created by applications or not, solving the namespace separation concern

• To be detailed

Put the application code in a nested space inside the XWiki top level space, which should be the only top level space reserved by XWiki. The users should be allowed to use any other name for a top level space. Applications that can have entries (data) should not enforce a specific space where entries are created. The users should be allowed to create application entries in multiple places, and to be able to group them under multiple "home" / "collection" (live data) pages. Applications could provide a "Home page" template to help with that. Applications could also have a "default entry location" configuration that points to a page outside XWiki top level space, and the users should be able to move / rename that default location (besides being able to use other locations for storing application entries).

To take the example of a hypothetical Meeting Notes application, after installing it there's no top level space created by default for holding meeting notes. The user goes to Create Page and has two options:

• create a "standalone" Meeting Notes page in whatever location they want; the Meeting Notes application can suggest a (configurable) default location (say the top level "Meeting Notes" page) but the administrator can change that and can also move / rename the previously configured default location without breaking the application
• or create a "Meeting Notes Collection" / "Meeting Notes Home" page that provides a live data view of existing child meeting notes
  • from this collection / home page the user can go to Create Page and create a child Meeting Notes page, that will then appear in the live data

• Separation of code and data
• Code editing is protected by default
• Users can use whatever top level page name they want (except XWiki)
• Users can move / rename the application data location without breaking the application (the code remains in the same place)
• Users can have multiple "instances" of the application, i.e. multiple locations where to group application entries based on their needs (e.g. multiple meeting notes spaces, one per each project)
• Deleting the (default) application entry space doesn't delete the code. The users should uninstall the application to remove it

• The applications panel needs to be rethinked: it assumes there is only one space for the application entries; it could point to the (configurable) default application entry location, but it needs to be updated when the user changes the configuration.