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
- From: David Booz <booz@us.ibm.com>
- To: sca-bindings@lists.oasis-open.org, sca-policy@lists.oasis-open.org
- Date: Thu, 14 May 2009 07:37:16 -0400
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
Simon 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]