[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-policy] ISSUE 43: Use of intents from component types in policySet algorithm
The actual text for the proposal is the
following. In section 4.10, change the beginning of the algorithm to the following
(the bold text in step 4 is new): For each
element in the composite definition document that is a subtype of the abstract
XSD elements <sca:binding> or <sca:implementation>, including any
<sca:binding.sca> elements that are implied by the lack of other service
or reference bindings: A. Calculate
the required intent set that
applies to the target element as follows: 1. Start with the list of intents
specified in the element's @requires attribute. 2. Add intents found in any related
interface definition. 3. Add intents found in the
@requires attribute of each ancestor element. 4. Add any
required intents from the corresponding element of the component type. The
element may not be present, but implied. Steps A1 to A3 should also be
run on the component type to determine the required intents to use for that
element. 5. If the element is a binding
instance and its parent element (service, reference or callback) is wired, the
required intents of the other side of the wire may be added to the intent set
when they are available. This may simplify, or eliminate, the policy matching
step later described in step C. 6. Remove any intents that do not
include the target element's type in their @constrains attribute. 7. If the set of intents includes
both a qualified version of an intent and an unqualified version of the same
intent, remove the unqualified version from the set. Since step 4 is new, the subsequent steps
have been renumbered. Note that the sentence before step A was
somehow dropped between version 1.0 and CD01. I believe its removal was
just a simple mistake. Obviously, without that sentence the rest of the
algorithm is meaningless, since that sentence defines what the “target
element” is which is referred to by the rest of the algorithm. It
just needs to be added back in. Michael From: Joshi,
Kaanu [mailto:Kaanu.Joshi@patni.com] Hi, A new issue has been
created in the SC Policy JIRA. The URL to this issue is: http://www.osoa.org/jira/browse/POLICY-43 Regards, Kaanu Joshi From: RAISER: TARGET: Policy Framework
Specification, Guided Selection of PolicySets
section DESCRIPTION: The current policySet
selection algorithm does not take into account any of the required policy
intents defined in the component type of a component. The assembly
specification states the policy intents specified in the component type cannot
be overridden by a component that uses that type. The implication is that
all of the required policy intents for a component type also apply to any
component that uses that type. This needs to be figured into the policySet
selection algorithm. PROPOSAL: Add a step in the
algorithm after step A.3 which adds in the required intents from the component
type’s corresponding service, reference, or component type definition. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]