RE: [sca-policy] ISSUE 46: How to configure policySets

["Patil, Sanjay" <sanjay.patil@sap.com>]

Hi Ashok,

Thanks for the clarifications.

Regarding the symmetry part - I think one major unsymmetry we recently
(forgot the issue#) introduced is that while intents can be applied at
any level, policySet is now applicable only to the binding node.
Therefore syntactically it would be easier to define policySet as an
element by expanding upon the definition of the binding element. OTOH,
supporting 'requires' as an element would require adding an extra
optional element at all levels in the SCDL hierarchy, which may make the
SCDL a bit unwieldy. We will also have to expand upon the inheritance
and conflict resolution rules if intents were to be an element, since
the current rules are in terms of only a 'list of QNames' as value for
the 'requires' attribute. Moreover, I am still not sure about the
rationale for making 'requires' an element.

I think 'requires' should stay as an attribute unless a clear case is
made for promoting it to an element.

-- Sanjay

> -----Original Message-----
> From: ashok malhotra [mailto:ashok.malhotra@oracle.com] 
> Sent: Wednesday, Jan 30, 2008 5:33 AM
> To: Patil, Sanjay
> Cc: OASIS Policy
> Subject: Re: [sca-policy] ISSUE 46: How to configure policySets
> 
> Hi Sanjay:
> 
> Yes, we do not  want to standardize on a configuration model.
> 
> No, there is no attempt to change or reduce the intent functionality.
> 
> I made "requires"  a child element  merely for  symmetry.  If 
> folks want 
> to retain it as an attribute,
> I'm fine with that.
> 
> Ashok
> 
> Patil, Sanjay wrote:
> 
> >[Can we have an issue number assigned asap, please]
> >
> >Some comments inline ...
> >
> >  
> >
> >>-----Original Message-----
> >>From: ashok malhotra [mailto:ashok.malhotra@oracle.com] 
> >>Sent: Tuesday, Jan 29, 2008 6:29 AM
> >>To: OASIS Policy
> >>Subject: [sca-policy] NEW ISSUE: How to configure policySets
> >>
> >>TARGET:  SCA Policy Framework
> >>
> >>DESCRIPTION :
> >>
> >>The current SCA Policy Framework supports the specification 
> >>of intents 
> >>and policySets on SCDL elements using attributes.
> >>For example:
> >>
> >><service> or <reference>
> >>
> >><binding name = "xs:string"
> >>
> >>policySet="xs:QName"? requires="="listOfQNames"? />
> >>
> >></service> or </reference>
> >>
> >>
> >>There are a couple of problems with this approach.
> >>
> >>
> >>1. Attributes are not extensible.  If the intents and 
> policySets were 
> >>specified as child elements, this would  permit
> >>extensibility.  In the f2f meeting last week the argument was 
> >>made that 
> >>some extensibility was required to allow
> >>runtime extension of policies with information like the 
> >>location of the 
> >>key store  or the type  of certificate  required.
> >>    
> >>
> >
> >I am guessing that you want to support binding configuration 
> by allowing
> >extensibility of policySets but not standardize the 
> configuration model
> >itself. Am I right?
> >
> >
> >  
> >
> >>2. If the 'requires' attribute is  used in conjunction with  
> >>a policySet 
> >>attribute it's not clear what the semantics are.
> >>At one time the intents in the 'requires'  list  were used to 
> >> configure 
> >>the  policySets  but that  meaning seems  to have been lost.
> >>    
> >>
> >
> >I think we would still want to keep the intents mechanism 
> such that the
> >developers can express abstract requirements and deployers 
> can validate
> >any selected bindings for the concerned wire, right? 
> >
> >  
> >
> >>PROPOSAL:
> >>
> >>For the  reasons cited above,  I suggest that policySets and 
> >>intents be 
> >>associated with SCDL elements using child elements.
> >>For example:
> >>
> >><service> or <reference>
> >>
> >><binding name = "xs:string"
> >>
> >><policySet name="xs:QName" select="xs:string"*> *
> >>     <requires name ="xs:QName"/> *
> >>
> >></service> or </reference>
> >>    
> >>
> >
> >I understand why we might want to have policySet as an 
> element. I am not
> >sure why we would want to make 'requires' as an element (vs. an
> >attribute)? 
> >
> >-- Sanjay
> >
> >  
> >
> >>Each "policySet" element would name a single policySet.  
> The "select" 
> >>attribute could contain a list of xs:strings which would
> >>name qualified intents and customize the use of the policySet by 
> >>selecting specific options from the intentMaps within the policySet.
> >>
> >>For symmetry,  the "requires" element also names a single 
> intent but 
> >>this is not necessary.  It could be changed to take a
> >>list of intent names as long as there was no need to customize the  
> >>intents.
> >>
> >>-- 
> >>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_workgr
> >>oups.php 
> >>
> >>
> >>    
> >>
> 
> 
> -- 
> 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_workgr
> oups.php 
> 
>