OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

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