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