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

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

[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 
> 
>