Hi, As a part of my effort to streamline node type handling in Oak, I've encountered a number of cases where validators and other components explicitly check whether a node is of a given type before processing it further. For example the indexing code checks whether children of an oak:index node are of the oak:indexDefinition type, and the security code verifies that only rep:accessControllable nodes can contain ACLs.
I wonder if we really do need such type checks. They increase implementation complexity and add extra performance overhead (though I've been able to cut down on that quite a bit) for no major benefit. Enforcing such type constraints would IMO be best left to the type validator that already has much better grasp of the available type information and is explicitly optimized for efficient type handling. Instead most of the other components that now validate such type information could simply rely on duck typing to figure out the meaning of the nodes they're processing. For example all children of an oak:index node could be interpreted as index definitions. The type validator (with some extensions about reserved names, etc.) could ensure the correctness of such assumptions so there would be no need to explicitly re-check the types of such content whenever it's accessed. BR, Jukka Zitting
