Re: [sca-policy] ISSUE-106: Extensibility of Intents

[David Booz <booz@us.ibm.com>]

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

ashok 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