[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary proposal for Issue 93
http://www.osoa.org/jira/browse/POLICY-93 Allow external attachment for intents I thought I would outline the proposal so that if we have time we can have a brief discussion on Monday. If there is positive sentiment I will draft a more complete wording proposal for the next telcon The motivation behind this issue is the separation of policy and executable code. This is what made us go in the direction of allowing external attachment for policySets. We argue that policy artifacts should be stored and managed separately from code and should have their own lifecycle and management. Probably managed by different departments. It should be possible to change intents and policySets anytime during the application lifecycle -- even after the application starts to run. And in some cases, of course, the SCDL cannot or may not be changed. So, it should be possible to add or change abstract policy requirements independent of the SCDL. The proposal requires 2 steps: 1. Add an @attachTo attribute to the intent element. The value of the @attachTo attribute is an XPath expression over the Domain Composite Infoset and it is evaluated in a manner analogous to the @attachTo attribute on policySets to indicate the SCDL element where the intent is to be attached. An alternate design is to introduce a new element, say <intentAttachment> which has 2 attributes. The @intent attribute takes a QName as its value and identifies an intent and an @attachTo attribute that takes a XPath expression as its value and identifies the SCDL element that the intent is to be attached. 2. Add a processing rule to the External Attachment section that says: attach the intents before attaching the policySets. -- All the best, Ashok
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]