Hi,

The discussion about orderable nodes (OAK-169) brought up a topic that we'll be needing in a few other cases as well: How to handle extra internal content that's needed to implement specific JCR features, but that generally shouldn't be directly visible through the JCR API?

For example, the extra Oak-level property (or properties, depending on how we implement the feature) needed to keep track of JCR-level node ordering information needs to be available through the Oak API since oak-jcr needs it in order to correctly implement JCR methods like getNodes() or orderBefore(), but such extra properties shouldn't be directly visible to JCR clients as that would break application-level assumptions about node content and massively complicate node type handling.

One approach that's been in the air so far is to use some built-in "oak" namespace for such internal, and then filter out all content under that namespace in the oak-jcr layer. However, I believe we'll need such a namespace also for things that *are* visible to clients. For example the proposed "oak:unstructured" node type (i.e. "nt:unstructured" without orderable child nodes or same name siblings) would need to be visible to JCR clients, and things like query index configuration (OAK-178) fall in to the same category. Also, using a "normal" JCR namespace introduces a potential conflict with existing namespace prefixes.

So I was thinking of using an explicitly invalid JCR name pattern for such internal content. A nice one would be the ":name" pattern that's already used by the MicroKernel for the ":childNodeCount" and ":hash" pseudo-properties. For example, the child ordering information in OAK-169 could go to a ":childOrder" property that's visible through the Oak API and understood by things like namespace and node type validators. The oak-jcr component could then internally access and manipulate such properties, while automatically filtering them out from the set of content directly visible to the client.

WDYT? ...