[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]