hi jukka as far as access control content is concerned that validation is IMO required due to the fact that without the mixin type on the parent the policy nodes would have a different declaring node type which IMO is part of the contract defined by the implementation... e.g. the repo could contain rep:policy nodes that are basically invalid.
but while talking about the validators and commit hooks: while taking a closer look at the permission evaluation i found that the commit hooks and validators get informed about all index updates which then get explicitly ignored by most validators/hooks, except for those dealing with index update. wouldn't it be possible to make it an explicit characteristic of the commit hooks if they want/need to deal with hidden trees and/or properties? IMO that would simplify the wast majority of all hooks and significantly reduce the amount of calls. what do you think? kind regards angela On 4/24/13 1:28 PM, Jukka Zitting wrote:
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
