Though this specification provides a hierarchical, tree-based view of content, it is also compatible with repository implementations that are not primarily hierarchy-based.
Though such implementations must still expose a hierarchical structure, the flexibility of this specification ensures that this need not be a particularly restrictive requirement. The following strategies, amongst others, can be adopted by implementations that are not primarily hierarchical:
The exposed hierarchy can be almost flat. A very shallow tree consisting of a root node with a large set of child nodes or properties is a valid arrangement. The names of the nodes may be identical with the UUIDs of the nodes.
There is no requirement that a particular hierarchical view of the repository be in any way “primary”. Through the use of REFERENCE properties feature, many orthogonal hierarchical views of the same underlying content are supported. This does away with the notion that there is a single canonical hierarchy. See, for example, 6.7.22.7 nt:linkedFile.
Hierarchical navigation is only one possible way to access the repository. The specification also supports a search query interface (see 6.6 Searching Repository Content). In addition, direct access via node UUID is also provided (see 6.2.1 Session Read Methods).