The concept of the referenceable node is foundational to many features of the repository, including multiple workspaces and versioning. The following principles define the characteristics and functioning of referenceable nodes:
A repository may support referenceable nodes. To do this the repository must support the mixin type mix:referenceable.
The mix:referenceable type has the effect of enforcing, on any node to which it is assigned, the presence of a property called jcr:uuid.
The jcr:uuid property is a protected, auto-created, mandatory property. This means that it is created and administered by the system and can only be read (but not changed or deleted) by the client.
The job of the jcr:uuid property is to expose the universally unique identifier (UUID) of its node.
The UUID of a referenceable node is assigned on node creation (or at least on node persistence) by the system itself.
In a given workspace, there is never more than one node with a given UUID, though there may be nodes that are not mix:referenceable and so do not have UUIDs at all.
If a node that is not mix:referenceable happens to have a property called jcr:uuid, then this property has no special significance (Note that adding such a property is not recommended: In general, the jcr prefix should be reserved for items defined within the specification, though this restriction may not be enforced by the implementation).
A repository implementation may make its workspace root nodes mix:referenceable. If so, then the root node of all workspaces must be referenceable, and all must have the same UUID.
Some implementations may allow or even require every node to have a UUID, and hence be mix:referenceable. In some cases however, especially where this API is implemented on top of an existing datastore, the provision of UUIDs for every node may be impractical. For this reason, an implementation is free to enforce whatever policies it wishes regarding where within a workspace tree referenceable nodes may be created or existing nodes extended with an assignment of mix:referenceable (in fact, this stems from the more general principle that an implementation is free to enforce such policies on the assignment of primary and mixin node types in general).