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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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


Subject: Re: [sca-policy] Re: [sca-bindings] Re: [sca-policy] Suggested wording forPOLICY-83


Then, unfortunately, I think we have a problem with the proposal for BINDINGS-23.

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 Simon Nash ---05/13/2009 04:55:22 PM---Dave, If an intent of SOAP.1_1 is specified on a service or reSimon Nash ---05/13/2009 04:55:22 PM---Dave, If an intent of SOAP.1_1 is specified on a service or reference, and


From:

Simon Nash <oasis@cjnash.com>

To:

David Booz/Poughkeepsie/IBM@IBMUS

Cc:

sca-bindings@lists.oasis-open.org, sca-policy@lists.oasis-open.org

Date:

05/13/2009 04:55 PM

Subject:

Re: [sca-policy] Re: [sca-bindings] Re: [sca-policy] Suggested wording for POLICY-83





Dave,
If an intent of SOAP.1_1 is specified on a service or reference, and
the binding specifies a WSDL port that uses SOAP 1.2 only, the
SCA runtime MUST raise an error (according to my proposed resolution
for BINDINGS-23 which we reviewed last week and I hope we will
accept tomorrow).

If an intent of SOAP is specified on a service or reference, and
the binding specifies a WSDL port that uses SOAP 1.2 only, the
SCA runtime MUST use the specified WSDL port (according to my
proposed resolution for BINDINGS-23 which we reviewed last week
and I hope we will accept tomorrow).

This shows that specifying the SOAP intent is not equivalent to
specifiying the SOAP.1_1 intent.

  Simon

David Booz wrote:
> Simon,
>
> I don't see how you can come to that conclusion from the quoted text.
> The relevant part seems to be the first bullet. The MUST says 'use
> SOAP'. That is not inconsistent with the way that the SOAP intent is
> currently defined, neither is the "can" in the next line. The intent
> definition is going to get you SOAP 1.1 but there's nothing that would
> prevent a runtime from also using SOAP 1.2 (remember, only the SOAP
> intent was specified in the use case in question so the other two
> bullets in section 4.1 don't apply).
>
> However, I do agree that there could be different interpretations given
> the current state of the binding and policy specs. As I've said before,
> the Policy TC doesn't care what the definition of the SOAP intent is,
> the Policy TC only cares that the Policy FW is able to express the
> semantics needed by the various intent use cases in a way that is
> consistent through out all the intent use cases.
>
> What we seem to have here is a difference of opinion in how the intent
> FW needs to work, and this is a more serious problem. Default
> qualifiers, as currently spec'd by Policy, are intended to convey a
> default behavior for unqualified usage of the qualifiable intent (SOAP
> in this case). The rationale for this is that it increases portability
> from one runtime to another. Without this default behavior, different
> runtimes would be free to make different choices which would end up as
> subtle errors in ported applications. While intents are still abstract,
> the default qualifier feature further narrows the range of semantic
> mismatches that might occur between runtimes.
>
> My recollection of the binding TCs decision on SOAP 1.1 vs SOAP 1.2 is
> that we wanted SOAP 1.1 to be the default behavior (I see this embodied
> in section 4.2.2), but the words in section 4.1 don't quite say that, so
> apparently something subtle has changed and I have missed it (or maybe
> section 4.1 could be improved, or 4.2.2 needs fixing - I vote for the
> former).
>
> If the binding TC decides that we really want there to be no default
> qualifier for the SOAP intent then:
> 1) Binding TC needs to decide this and then formally communicate this to
> the Policy TC - If such a decision were made, I'd be happy to take the
> AI to inform Policy.
> 2) Policy TC needs to decide if can relax the default qualifier rules -
> Policy TC would need a sufficient justification from Binding TC and use
> case as this is a non-trivial change in the basic FW model. It's not
> impossible to change, it's just not trivial as you can see from Issue 83
> in policy which was aiming to simply clarify the existing FW model.
>
> 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 Simon Nash ---05/12/2009 03:04:37 PM---Dave,
> See inline below.Simon Nash ---05/12/2009 03:04:37 PM---Dave, See inline
> below.
>
>
> From:
> Simon Nash <oasis@cjnash.com>
>
> To:
> sca-policy@lists.oasis-open.org
>
> Cc:
> OASIS Bindings <sca-bindings@lists.oasis-open.org>
>
> Date:
> 05/12/2009 03:04 PM
>
> Subject:
> [sca-bindings] Re: [sca-policy] Suggested wording for POLICY-83
>
> ------------------------------------------------------------------------
>
>
>
> Dave,
> See inline below.
>
>   Simon
>
> David Booz wrote:
>  > Hi Ashok,
>  >
>  > Something about this issue was bugging me last night, so I did some
>  > investigation in the spec this AM. Looking at CD02/PRD, line 1451 (in
>  > the section which normalizes attached intents into a required intent
>  > set), I found this statement:
>  > "and where any unqualified qualifiable intents are replaced with the
>  > default qualified form of that intent, according to the default
>  > qualifier in the definition of the intent."
>  >
>  > While it doesn't read quite right, the intention is clearly to replace
>  > unqualified intents with their default qualified form and also assumes
>  > that there is a default qualifier if there are any qualifiers. This
>  > usage of default qualifiers was a surprise to me (i.e., I forgot about
>  > it) as I thought that the default qualifier was only used in processing
>  > intentMaps in policySets.
>  >
>  > I think the words you propose to resolve POLICY-83 are good.
>  >
>  > I also want to react to the last statement below:
>  >
>  >  >> In other discussions re the SOAP intents we have taken the position
>  > that a default qualifier may not be specified. This is contrary to
>  > POL30004 and would require a significant change to the spec.
>  >
>  > The current SOAP intent definition has "1_1" set as the default
>  > qualifier. Can you help me understand what discussion you're referring
>  > to because I might have missed something? The web service binding
>  > discussions I'm aware of have not suggested changing this default. We
>  > have been discussing the need to declare the qualifiers to be mutually
>  > exclusive.
>  >
> The WS Binding spec contains normative text that is incompatible with
> SOAP.1_1 being the default qualifier if the unqualified SOAP intent
> is used.  The following is from section 4.1:
>
>  So as to narrow the range of choices for how messages are carried,
>  the following policy intents affect the transport binding:
>   • SOAP
>     When the SOAP intent is required, the SCA runtime MUST transmit
>     and receive messages using SOAP. One or more SOAP versions can
>     be used [BWS40001].
>   • SOAP.1_1
>     When the SOAP.1_1 intent is required, the SCA runtime MUST transmit
>     and receive messages using only SOAP 1.1 [BWS40002].
>   • SOAP.1_2
>     When the SOAP.1_2 intent is required, the SCA runtime MUST transmit
>     and receive messages using only SOAP 1.2 [BWS40003].
>
> Using 1_1 as the default qualifier for the SOAP intent would contradict
> the above.  This needs to be resolved between the Policy TC and the
> Bindings TC.
>
>   Simon
>
>  > 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 ---05/12/2009 08:24:55
>  > AM---Eric pointed out that the existing wording for conformanceashok
>  > malhotra ---05/12/2009 08:24:55 AM---Eric pointed out that the existing
>  > wording for conformance statement [POL30004] states:
>  >
>  >
>  > From:
>  > ashok malhotra <ashok.malhotra@oracle.com>
>  >
>  > To:
>  > OASIS Policy <sca-policy@lists.oasis-open.org>
>  >
>  > Date:
>  > 05/12/2009 08:24 AM
>  >
>  > Subject:
>  > [sca-policy] Suggested wording for POLICY-83
>  >
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Eric pointed out that the existing wording for conformance statement
>  > [POL30004] states:
>  > "If an intent has more than one qualifier, one and only one MUST be
>  > declared as the default qualifier."
>  > and does not cover the case where a single qualifier is declared for the
>  > intent.  See
http://www.osoa.org/jira/browse/POLICY-83
>  >
>  > Suggested rewording:
>  > If an intent has one or more qualifiers, one and only one MUST be
>  > declared as the default qualifier.
>  >
>  > Note that this is an extra-Schema constraint.  The Schema provides an
>  > optional 'default' attribute for the
>  > qualifier definition in the intent so, according to the Schema, this
>  > attribute can be omitted for all qualifiers or
>  > set to 'false'.  POL30004 says that this attribute MUST be set to true
>  > for one and only one of the qualifiers.
>  >
>  > In other discussions re the SOAP intents we have taken the position that
>  > a default qualifier may not be specified.
>  > This is contrary to POL30004 and would require a significant change to
>  > the spec.
>  >
>  > --
>  > 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 
>
>
>






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