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-97: Suggestion to address suspected default/unqualifiedintent ambiguity


Using the numbering from Rich's email:

1) +1 to Mike. The words on line 234-240 get close to the issue, so that's the probably the place to start.

2) +1 to Mike. The term "unqualifiable intent" never appears in the spec, so I'm not sure where you got it from? I'm not keen to introduce this term to the spec since it doesn't make sense to me.

3) +1 to Mike. The meaning of an intent is abstract, even the ones we define in the spec leave room for various mechanisms to satisfy them. I don't think we want to tie down a normative meaning for each intent or each qualifier, the meaning should come from the policySet or binding that is providing the intent.

4) I differ slightly with Mike here. It is possible to create two policySets, one provides the unqualified intent, the other provides the qualified intent, and where each policySet contains different policy assertions to satisfy the intent. Again, the meaning is derived from what is providing the intent. In fact, it is even possible (and valuable) to have two policySets that both provide the same unqualified intent and yet both contain different policy assertions to satisfy the intent.


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 Mike Edwards ---07/21/2009 07:18:27 AM---Rich, Comments inline.Mike Edwards ---07/21/2009 07:18:27 AM---Rich, Comments inline.


From:

Mike Edwards <mike_edwards@uk.ibm.com>

To:

"OASIS Policy" <sca-policy@lists.oasis-open.org>

Date:

07/21/2009 07:18 AM

Subject:

Re: [sca-policy] ISSUE-97: Suggestion to address suspected default/unqualified intent ambiguity






Rich,

Comments inline.

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com

From: "Rich.Levinson" <rich.levinson@oracle.com>
To: Mike Edwards/UK/IBM@IBMGB
Cc: OASIS Policy <sca-policy@lists.oasis-open.org>
Date: 20/07/2009 14:52
Subject: Re: [sca-policy] ISSUE-97: Suggestion to address suspected default/unqualified intent ambiguity





I understand the concern about the possible confusion that the suggestion might introduce. However, the reason for the suggestion is to give substance to at least the following "use cases", which I don't believe currently have clear guidance in the spec:

1. An unqualified intent. What does it explicitly mean? I was not able to find defn in spec.
<mje>This means an intent name with no qualifiers - eg "confidentiality". We should add some words to define this in section 3.1 of the spec</mje>


2. An "unqualifiable intent". Does not appear to be explicitly defined. Does it mean there are currently no qualifiers defined or that there can never be any qualifiers defined?
<mje>It simply means an intent with no qualifiers declared. It certainly can't mean that no qualifiers can ever be defined since the meaning of an intent

is effectively what is currently declared in the SCA Domain. Clearly changing the definition is a serious matter since it will affect aplications, but
SCA does nothing to prevent such a change</mje>


3. There does not appear to be any clear mechanism for adding a qualifier to a currently "unqualifiable" intent in future release. Also not clear what meaning the new qualifier has wrt to the original defn of the unqualifiable intent.
<mje>The mechanism is simply to change the declaration of the intent. Job done.
The meaning is that it is one more possibility for the interpretation of the unqualified form of the intent. It does not change the meaning of a qualified form of the intent</mje>


4. What does it mean to have a qualifiable intent with only a single qualifier defined? i.e. is the unqualified version of such an intent automatically equal to the qualified version? What other explanation is meaningful?
<mje>In that case the unqualified form always means the same as the qualified form using the single qualifier.</mje>


I recognize that these are probably not the use cases foremost on people's list of concerns. However, all these questions presented themselves to me when I considered the use case of "release 1" having an intent defined with no qualifiers defined for it and then considering what it would mean to define a qualifier for such an intent in "release 2" and what forward/backward compatiblity issues might emerge from such an action.

I believe the proposal successfully addresses these situations. Without the proposal I am left without a clear understanding of what would be a well-defined process to add a qualifier to an intent that currently has no qualifiers.

<mje>I don't see that at all. It is not an easy process to make a change like this, whatever you do.


Take the idea of an intent like "SOAP".

- means "use the SOAP messaging protocol"

- starts out life with no qualifiers - let's say that at first there is only one version of the SOAP protocol = soap v1.1

- along comes a new version of the soap protocol, soap v1.2

- so we change the SOAP intent to be qualified with 2 qualifiers "1_1" and "1_2", with 1_1 the default

- unqualified SOAP can be provided either by soap v1.1 or soap v 1.2 - there MIGHT be some applications that are only really capable

of dealing with soap v1.1 - these guys will have problems if ever soap v1.2 is used. Such applications would have to change from using

SOAP to use SOAP.1_1.

- along comes another version of the protocol - soap v1.3

- we add another qualifier, "1_3"

- the intent "SOAP" unqualified now means any one of v1.1, v1.2, v1.3

- any application that cares MUST specify the qualified form eg SOAP.1_2 - any application which had one of the qualified forms
previously will continue to work. An application using the unqualified form may have a problem, if in fact it really cares about the

version of soap that gets used.


</mje>


If there is some obvious explanation that addresses the above concerns that I am simply not seeing, then I will be satisfied to accept that once it is pointed out to me.

Thanks,
Rich


Mike Edwards wrote:


Folks,

I don't like the introduction of this notional "any" qualifier.

It is at best confusing. I certainly think that it is NOT a good idea to have a formal definition of it in the schema.

The unqualified intent does mean that any of the defined qualifiers is a valid interpretation of the unqualified form
of the intent, but there is not really an "any" actual qualifier outside the set of explicitly defined qualifiers. So in that sense
"any" does not exist as a qualifier. What actually exists is the set of defined qualifiers - and the unqualified form
of the intent actually represents this set. Specifying a qualified form of the intent means taking the subset of the set
- with the subset being the one qualified form.

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From: "Rich.Levinson" <rich.levinson@oracle.com>
To: David Booz <booz@us.ibm.com>, sca-policy@lists.oasis-open.org
Date: 20/07/2009 06:27
Subject: Re: [sca-policy] ISSUE-97: Suggestion to address suspected default/unqualified intent ambiguity






Based on discussion from last week's meeting, I took an action item to suggest text changes to represent what was agreed to be the meaning of qualified/unqualified and default. I am suggesting that the following two text changes should capture that meaning (Note: the proposed change is fairly subtle in that it defines something that does not ever have to be explicitly used, but the fact that it is defined and can be used appears to remove the asserted ambiguities):

1.After line 241 in section 3.1 of version CD2, PubRev 01, 7-Apr-09, insert the following 2 paragraphs:
All intents are inherently “qualifiable”, but can only become qualified intents if one or more qualifiers are defined to be related to that intent. All intents may be considered to have an implicit qualifier defined, named “any”, which means any qualifier defined for the intent (including "any") may be used to satisfy the intent. An unqualified intent is implicitly qualified by the qualifier "any" and therefore implicitly becomes a qualified intent.

In general there may be many “known ways” to satisfy an intent. The implicit qualifier, “any” can be taken to mean that “any of those known ways” may be used to satisfy the intent. A defined qualifier other than "any" may be taken to mean a specific subset of those “known ways” to satisfy an intent.
2. Change the definition of default to be:

@default (0..1) - a boolean value with a default value of "false". If @default="true" the particular qualifier is the default qualifier for the intent. If an intent has more than one qualifier defined, then
either the implicit qualifier "any" or one and only one of the defined qualifiers must be defined as the default qualifier.
The intended net effect of these changes is allow "any" to be assumed to be an implicit qualifier that applies whenever the intent appears in its unqualified form. It also says that "any" represents an implicit set of all "known ways" to satisfy the intent. And finally, and most important to resolving the issue, it says that "any" may be explicitly defined as the default qualifier.

The only thing I am uncertain about is how to introduce "any" to the schema. The idea is that "any" is always implicitly specified for the unqualified version of any intent, but only needs to be ever explicitly specified if it is intended to be the qualifier for which the default property is intended to be set to "true" for a particular intent.

This also enables the definition to be made independently of qualifying whether defaults apply only to intentMaps or otherwise, which may or may not be a desired clarification to make in the spec.

If this overall approach is agreed to then we can decide how to apply it to the schema and whether or not to say more about the default vis a vis intentMaps.

Thanks,
Rich





David Booz wrote:

Rich,

I think the resolution of ISSUE-95 addresses your concern. With this resolution, the only thing a default qualifier does is choose a path through an intent map when the policySet provides the unqualified form of the intent.


http://www.osoa.org/jira/browse/POLICY-95


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---07/09/2009 08:49:28 AM---http://www.osoa.org/jira/browse/POLICY-97 Dave BoozDavid Booz---07/09/2009 08:49:28 AM---http://www.osoa.org/jira/browse/POLICY-97 Dave Booz

From:

David Booz/Poughkeepsie/IBM@IBMUS

To:

sca-policy@lists.oasis-open.org

Date:

07/09/2009 08:49 AM

Subject:

[sca-policy] ISSUE-97: Suggestion to address suspected default/unqualified intent ambiguity





http://www.osoa.org/jira/browse/POLICY-97

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 "Rich.Levinson" ---07/08/2009 05:41:41 PM---Note: this can either be a new issue or it can be conside"Rich.Levinson" ---07/08/2009 05:41:41 PM---Note: this can either be a new issue or it can be considered part of either or both of issues 90 an

From:

"Rich.Levinson"
<rich.levinson@oracle.com>

To:

OASIS Policy
<sca-policy@lists.oasis-open.org>

Date:

07/08/2009 05:41 PM

Subject:

[sca-policy] [NEW ISSUE] Suggestion to address suspected default/unqualified intent ambiguity






Note: this can either be a new issue or it can be considered part of either or both of issues 90 and 95. Discussion so far of issues 90 and 95 has pretty much convinced me that something is insufficiently specified about unqualified vs qualified intents in conjunction with specifications for defaults.

TARGET:
SCA Policy FW cd02 rev1 (doc)

http://www.oasis-open.org/committees/document.php?document_id=31980&wg_abbrev=sca-policy

SUMMARY:
Specifically, it appears to be unclear whether specifying an unqualified version of an intent that has qualifiers defined for it means that one should use the unqualified intent to mean that ANY of the qualifiers is acceptable, or whether it means that the default qualifier should be applied to the unqualified version.

DETAILS:
The definition of default says (305-308):

@default (0..1) - a boolean value with a default value of "false". If @default="true" the particular qualifier is the default qualifier for the intent. If an intent has more than one qualifier, one and only one MUST be declared as the default qualifier.

First, let me point out what appears to me to be a minor ambiguity in this defn: The highlighted text applies when there is MORE THAN ONE qualifier defined, and it says that ONE MUST be declared as the default. The "minor" ambiguity is that if there is ONLY ONE qualifier DEFINED, then is this by defn the default? or not? i.e. can an intent have only a single qualifier defined and at the same time have its "default" attribute have its default value of false? In my proposal below, this issue goes away, but I thought it worth mentioning.

What I consider to be the "major" ambiguity is what is described in the SUMMARY above, namely that if we go by the definition of "default" and have more than one qualifier defined, then one of those qualifiers must be defined as the default value. Therefore, one MUST assume (I would think) that if an unqualified intent was specified then when this intent was processed, that one MUST apply the default qualifier to it. Why? Because, otherwise the definition of "default" is rendered meaningless, because the default only is used when the intent is unqualified, and if we apply the default then the intent is now qualified. However, on the other hand, if we were say that the intent should remain unqualified, then this means there is no point to defining a default, since there are no circumstances when it would be used!

Based on the discussion of issue 95, and based on my original understanding of what was intended, and based on the proposed resolution to issue 95, which I believe is to allow the following lines about SOAP to remain accurate (2306-2310, esp. last sentence):

SOAP
– The SOAP intent specifies that the SOAP messaging model is used for delivering messages. It does not require the use of any specific transport technology for delivering the messages, so for example, this intent can be supported by a binding that sends SOAP messages over HTTP, bare TCP or even JMS. If the intent is attached in an unqualified form then any version of SOAP is acceptable.
i.e. based on all the above I am suggesting the following proposal:

PROPOSAL:
In words, the proposal is:

1.
Allow unqualified intents that have qualifiers defined, to indicate that ANY of the qualifiers is an acceptable means of satisfying the intent.
2.
Change the meaning of "default" as follows:
1.
Leave specification of the default to be optional (0:1) for each qualifier.
2.
Do NOT require any qualifier to be the default. i.e. REMOVE the sentence that says "...one MUST be declared as the default qualifier"
3.
But do say: "If one qualifier IS DEFINED with default="true", then if the intent is specified as unqualified, then the default value applies."
4.
However, also say: "If one or more qualifiers is defined for the intent, and NONE of the qualifiers has a default="true" attribute THEN if the intent is specified as unqualified, then ANY one of the qualifiers may be used to satisfy the intent.
As indicated in the "minor" problem above, that problem goes away because we no longer require any qualifier to have the default attribute true and so there is no need to force the unqualified intent to assume a default qualifier.










Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU










Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]