...
Summary of issues with the current arrangement
- Better separation of policy model from assembly model
- implementation policy sets held by component due to reuse of implementation model objects
- OASIS are talking about moving to an external attachment model so we need flexibility to follow that move if necessary
- "Applies to" happens right at the start of contribution and is not subject to later builder processing
- Consistency of model style between assembly and policy models
- Separate any policy processing from policy model
- Consistency of policy extension model
- definitions.xml processing should be domain wide and not restricted to a single contribution
Idealistic policy model
The make sure I understand the model I reproduced my version of it from the existing spec resources. It's slightly different from what we have at present as the code model is somewhat optimized but I want to use this as my baseline for reviewing what we have in the implementations
Policy model reading follows the assembly model in having read and resolve phases. The read phase will create dummy objects with "unresolved = true" set to represent any unresolved references. These dummy objects are replaced with the real thing at the resolve stage.
...