Simon Laws wrote:
I didn't get anyone to bite with this post but I've been updating the
models on the wiki page [1] over the last few days. I hassled Sebastien
off line and got feeback on the idealized model so that's so that's
starting to look a little cleaner.
...
More comments on the policy model diagram on [1]. I'm now happier with
the blue part of the diagram, but I think that the yellow part is still
too tied to the XML representation of the logical model.
Here's a first cut of what I envisioned:
Yellow classes:
- PolicyConfiguration, a set of policy configuration info
- PolicySet, a top level PolicyConfiguration (like line 339 of the spec)
- QualifiedPolicyConfiguration, an inner PolicyConfiguration (like line
346 of the spec)
- Policy, a policy declaration
- WSPPolicy and WSPPolicyAttachment represent WSP policy declarations
Relationships:
- PolicySet extends PolicyConfiguration
- QualifiedPolicyConfiguration extends PolicyConfiguration
- PolicyConfiguration extends IntentProvider
(as it provides Intents)
- PolicyConfiguration contains 0..n QualifiedPolicyConfigurations
(analog to Intent contains 0..n QualifiedIntents)
- PolicyConfiguration references 0..1 default
QualifiedPolicyConfiguration (which indicates how to qualify a
non-qualified intent requirement)
- WSPPolicy, WSPPolicyAttachement and PolicySet extend Policy
- PolicyConfiguration references 0..n (included) Policy (declarations or
capabilities)
So, basically we don't try to model the XML noise (IntentMaps and
Qualifiers), we model the core classes and their logical relationships.
The green part of the diagram and the 'policy and assembly' model need
work too but I suggest to look at them later once we're happy with the
yellow part of the diagram, as it's simpler to take things one at a time.
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
--
Jean-Sebastien
