ModeShape is currently fairly conservative in when it allows node type inheritance, and it behaves more like strongly-typed systems. Providing the ability to behave in a more weakly-typed system would possibly make it easier to change node types after they've been used by nodes (because the existing nodes could more easily adapt to changing node types), though it might also mean more potential for conversion problems (see below for an example).

As just one example, the following definitions are not currently allowed (because type A and B both declare a child node with the same name:

[nodeA]
+ child (nt:unstructured)

[nodeB]
+ child (nt:unstructured)

[nodeC] > nodeA, nodeB

Allowing this would mean that the property definition selected for various properties and child nodes might depend upon the inheritance hierarchy. Consider these node types:

[nodeD] mixin
-prop1 (LONG)

[nodeE] mixin
-prop1 (STRING)

[nodeF] > nodeD, nodeE mixin

In this case, consider a node that has a 'prop1' property and the 'nodeF' mixin type. In this case, if the value of the property were a long, then that property's definition would be that from nodeD, whereas a node with a string value for the property might result in that property having the node definition from nodeE. Essentially, the "best fitting" property definitions and child node definitions would be selected on a node-by-node basis. So not only might the selected definitions vary for different nodes, they might change over time if the node types are changed. (For example, the 'prop1' property definition on 'nodeD' might be removed, yet the existing long values would be automatically and transparently converted to a string when used.)

Also, consider a node that has 'nt:unstructured' for a primary type and the 'nodeE' mixin. If that node has a string value for the 'prop1' value, the nodeE.prop1 definition doesn't apply (the name does, but the type does not), so this property would use the residual property definition from 'nt:unstructured'. Obviously this makes for a much more flexible and ductile system, but it may not be immediately intuitive. An application might be programmed to get the 'prop1' value from the node and cast to a long (since according to the node type it "should be" a long), but this would result in a conversion exception because the property value does exist, but as a string value. Note that the property definition for that property would indeed point to the residual property that allows any type, so the graph is entirely consistent. It's just that the application is getting something it doesn't expect because of an invalid expectation.

Right now these cases are not allowed by the node types, and errors are produced when the nodes are loaded from a source should the content not fit the node type. This change would allow such misfitting content to be loaded and accessed, as long as the client application didn't make the strong-typing assumptions.