[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] ISSUE-106: Extensibility of Intents
Yes, that's another solution. All the best, Ashok David Booz wrote: > > Why wouldn't the vendor put his intents in his own file in his own > namespace? That's one of the reasons why we have support for multiple > definitions files in Assembly. > > 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 04:07:58 > PM---No, I want to allow new, vendor specific intents. Perhaps ashok > malhotra ---09/23/2009 04:07:58 PM---No, I want to allow new, vendor > specific intents. Perhaps we need to allow extensibility at the bott > > > From: > ashok malhotra <ashok.malhotra@oracle.com> > > To: > sca-policy@lists.oasis-open.org > > Date: > 09/23/2009 04:07 PM > > 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 > > > > > > > > --------------------------------------------------------------------- > 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]