[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] ISSUE-106: Extensibility of Intents
No, I want to allow new, vendor specific intents. Perhaps we need to allow extensibility at the bottom of the file. All the best, Ashok David Booz wrote: > > One might consider your use case as in violation of "a vendor is NOT > allowed to alter the def'ns file using any of the spec'd aspects of an > intent definition." because to add an intent you'd have to use the > spec'd <intent/> element. > > Do you want to specifically prohibit that case?. > > Dave Booz > STSM, BPM and SCA Architecture > Co-Chair OASIS SCA-Policy TC and SCA-J TC > "Distributed objects first, then world hunger" > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > e-mail:booz@us.ibm.com > > Inactive hide details for ashok malhotra ---09/23/2009 03:24:05 > PM---Thanks, Dave. This is useful. An important case that we nashok > malhotra ---09/23/2009 03:24:05 PM---Thanks, Dave. This is useful. An > important case that we need to cover is adding intents to the > > > From: > ashok malhotra <ashok.malhotra@oracle.com> > > To: > sca-policy@lists.oasis-open.org > > Date: > 09/23/2009 03:24 PM > > Subject: > Re: [sca-policy] ISSUE-106: Extensibility of Intents > > ------------------------------------------------------------------------ > > > > Thanks, Dave. This is useful. > An important case that we need to cover is adding intents to the > intents.xml file. > All the best, Ashok > > > David Booz wrote: > > > > 1) Yes, we need to make it clear what a vendor can do to the > > sca-policy-1.1-intents-definitions.xml file and remain compliant with > > the spec. This is a special case where we have an XML instance > > document, that no other TC has. My position in the last call was that > > since the schema for intent def'ns is extensible, we should allow > > vendors to add their extensions to the spec'd definitions because > > those changes don't alter the portable aspect of the spec'd > > definitions. And further, such a change does not cause the namespace > > of the document to change. Finally, a vendor is NOT allowed to alter > > the def'ns file using any of the spec'd aspects of an intent > > definition. Such a change would require a change to the namespace, > > which vendors should not /cannot be able to do. > > > > For example: > > Starting with the base def'n for serverAuthentication: > > <intent name="serverAuthentication" constrains="sca:binding" > > intentType="interaction"> > > <description> > > Communication through the binding requires that the > > server is authenticated by the client > > </description> > > <qualifier name="transport" default="true"/> > > <qualifier name="message"/> > > </intent> > > > > > > The following is OK, in my view (see dab:exAttrib and dab:myExtension): > > > > <intent name="serverAuthentication" constrains="sca:binding" > > intentType="interaction" dab:exAttrib="true"> > > <description> > > Communication through the binding requires that the > > server is authenticated by the client > > </description> > > <qualifier name="transport" default="true"/> > > <qualifier name="message"/> > > <dab:myExtension name="Dave"/> > > </intent> > > > > But the following is not OK (for two reasons - changed default, added > > qualifier) > > > > <intent name="serverAuthentication" constrains="sca:binding" > > intentType="interaction"> > > <description> > > Communication through the binding requires that the > > server is authenticated by the client > > </description> > > <qualifier name="transport"/> > > <qualifier name="message" default="true"/> > > <qualifier name="magic"/> > > </intent> > > > > 2) No, I don't think we need to specify this in the spec, but I'm ok > > doing it if someone feels strongly. > > > > Dave Booz > > STSM, BPM and SCA Architecture > > Co-Chair OASIS SCA-Policy TC and SCA-J TC > > "Distributed objects first, then world hunger" > > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > > e-mail:booz@us.ibm.com > > > > Inactive hide details for David Booz---09/23/2009 02:55:58 > > PM---http://www.osoa.org/jira/browse/POLICY-106 Dave BoozDavid > > Booz---09/23/2009 02:55:58 > > PM---http://www.osoa.org/jira/browse/POLICY-106 Dave Booz > > > > > > From: > > David Booz/Poughkeepsie/IBM@IBMUS > > > > To: > > sca-policy@lists.oasis-open.org > > > > Date: > > 09/23/2009 02:55 PM > > > > Subject: > > [sca-policy] ISSUE-106: Extensibility of Intents > > > > ------------------------------------------------------------------------ > > > > > > > > _http://www.osoa.org/jira/browse/POLICY-106_ > > > > Dave Booz > > STSM, BPM and SCA Architecture > > Co-Chair OASIS SCA-Policy TC and SCA-J TC > > "Distributed objects first, then world hunger" > > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > > e-mail:booz@us.ibm.com > > > > Inactive hide details for ashok malhotra ---09/23/2009 02:35:14 > > PM---This comes out of a discussion of POLICY-97 from this Mondashok > > malhotra ---09/23/2009 02:35:14 PM---This comes out of a discussion of > > POLICY-97 from this Monday's call. The question has to do with who > > > > From: > > ashok malhotra <ashok.malhotra@oracle.com> > > > > To: > > OASIS Policy <sca-policy@lists.oasis-open.org> > > > > Date: > > 09/23/2009 02:35 PM > > > > Subject: > > [sca-policy] NEW ISSUE: Extensibility of Intents > > > > ------------------------------------------------------------------------ > > > > > > > > This comes out of a discussion of POLICY-97 from this Monday's call. > > The question has to do with who can extend intent definitions and the > > consequences > > of such extensions. > > > > The spec currently says: "SCA normatively defines a set of core intents > > that all SCA implementations are expected to support, to ensure a > > minimum level of portability. Users of SCA can define new intents, or > > extend the qualifier set of existing intents." > > > > To me, this says that vendors can add their own intents and perhaps > > additional qualifiers to the intents defined in the Policy Framework > > specification. We understand that these extensions will not be > > interoperable. Vendors cannot change the default qualifier for intents > > defined in the Policy Framework spec. > > > > The other discussion thread was about changes in intent definitions -- > > new intents, new qualifiers, changes in defaults -- that would occur in > > future versions of the Policy Framework specification. Clearly, such > > changes may occur and I argued that this should change the namespace of > > the specification and, in effect, create a new version of the spec. > > > > So, two questions: > > > > 1. Do we need to clarify the extensions that vendors can make? > > 2. Do we need to discuss changes that may occur in future versions of > > the Policy Framework specification? > > Note that we don't talk about such evolution in other sister SCA specs. > > > > -- > > All the best, Ashok > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at:_ > > > __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_ > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]