Re: [sca-policy] ISSUE 15 -- Are policySets additive or overrideable

[David Booz <booz@us.ibm.com>]

Section 4.6 from the resolution to Issue 38 says:

For explicitly listed policySets, the list in the component using the
implementation may override policySets from the component type. More
precisely, a policySet on the componentType is considered to be overridden,
and is not used, if it has a @provides list that includes an intent that is
also listed in any component policySet @provides list.



Then moving to section 4.10:
If you look at step C of the policySet selection algorithm it describes how
to "normalize" the attached policySets.

C. Calculate the list of explicitly specified policySets that apply to the
target element.

In this calculation, a policySet applies to a target element if the XPath
expression contained in the policySet’s @appliesTo attribute is evaluated
against the parent of the target element and the result of the XPath
expression includes the target element. For example,
@appliesTo=”binding.ws[@impl=’axis’]” will match any binding.ws element
that has an @impl attribute value of ‘axis’.



The list of explicitly specified policySets is calculated as follows:

      Start with the list of policySets specified in the element's
   @policySets attribute.
      If any of these explicitly listed policySets does not apply to the
   target element (binding or  implementation) then the composite is
   invalid. The point of this rule is that it must have been a mistake to
   have explicitly listed a policySet on a binding or implementation
   element that cannot apply to that element.
      Include the values of @policySets attributes from ancestor elements.
      Remove any policySet where the XPath expression in that policySet’s
   @appliesTo attribute does not match the target element. It is not an
   error for an element to inherit a policySet from an ancestor element
   which doesn’t apply.


C.3. is the key.  The Policy spec seems to indicate that policySets are
additive, there is no concept of overrides mentioned here.



My summary of the current spec:

policySets can be overridden when they are introduced into the infoset from
a componentType, otherwise they are aggregated/accumulated.


In the context of issue 15 (external attachment), since we've already
stated a general rule that external attachment has similar semantics to
direct attachment, then external attachment would have to occur before C
above and would abide by the rule stated in section 4.6.


Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


                                                                           
             ashok malhotra                                                
             <ashok.malhotra@o                                             
             racle.com>                                                 To 
                                       OASIS Policy                        
             05/05/2008 04:30          <sca-policy@lists.oasis-open.org>   
             PM                                                         cc 
                                                                           
                                                                   Subject 
             Please respond to         [sca-policy] ISSUE 15 -- Are        
             ashok.malhotra@or         policySets additive or overrideable 
                 acle.com                                                  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




We had a discussion on today's call whether policySets on services,
references and bindings can be overridden by the
component or do the policySets on the component add to what's already
attached to services, references and bindings.
Here is what I found in the Assembly 1.00 spec:

412 Most of the characteristics of the services, references and
properties may be overridden by a
413 component that uses and configures the implementation, or the
component can decide not to
414 override those characteristics. Some characteristics cannot be
overridden, such as intents.
415 Other characteristics, such as interfaces, can only be overridden in
particular controlled ways
416 (see the Component section for details).

The component section does not explicitly mention whether the policySets
attached to the component add to or
override the policySets on services, references and bindings.  We need
to decide this to make progress.

Here's my 2 cents:
- a policySet that provides a qualified intent overrides a policySet
that provides the same intent in the unqualified form
- if a policySet from a component provides the identical intent as a
policySet on a service, reference and binding the
policySet from the component overrides
- in all other cases, the policySets on the component add to the
policySets on services, references and bindings
--
All the best, Ashok

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php