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

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

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

David 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

ashok 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