- From: Bob Freund <Bob.Freund@hitachisoftware.com>
- Date: Mon, 23 Feb 2009 17:40:18 -0500
- To: David Illsley <david.illsley@uk.ibm.com>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, ashok.malhotra@oracle.com, Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>, Gilbert Pilz <gilbert.pilz@oracle.com>, Jitendra.Kotamraju@Sun.COM, Monica Martin <momartin@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, Rama Pulavarthi <Rama.Pulavarthi@Sun.COM>, Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>, "Rogers, Tony" <Tony.Rogers@ca.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, wsi_wsbasic@mp.ws-i.org, ylafon@w3.org
- Message-Id: <8700919D-E607-4F2E-B230-40F1588741B4@hitachisoftware.com>
I am having a difficult time with proposals to formalize attachments
of policies at the WS-Addressing operation level.
1) My understanding is that the goal of WS-I and its profiles, are in
general to improve interoperability of the Web Services Stack.
The proposals do not improve interoperability since they introduce a
feature that is not contained in strictly implemented and conformant
versions of WS-Addressing. To the contrary, they introduce new
functionality that current conformant implementations do not have and
thus create incompatibilities with existing implementations. The goal
of improving interoperability is violated. Perhaps future
implementations that had this new feature might become interoperable,
but until that time, correct implementations would not interoperate
with "new-style" implementations.
2) There is no business scenario that is enabled by the new feature
that is not possible with the current specification of WS-Addressing.
While it might be "nice" to be able to introduce policy on an
operation by operation basis, the policy expressions developed for WS-
Addressing were intended to represent capabilities of an endpoint, not
requirements for an operation. An endpoint imbued with the capability
of dealing with either anonymous or non-anonymous addresses (see WS-
Addressing 1.0 metadata Example 3-8) certainly can then deal with
business scenarios that might want to perform operations synchronous
with respect to the underlying transport or asynchronous with the
underlying transport. Indeed, alternate operations might chose to use
one form or another, or the application might be designed to mix forms
of address at its him with whatever degree of rigor the application
designer might choose. The new features are not business-enablers.
Yes I agree that there is a certain degree of elegance combined with a
greater degree of complexity and overhead in the new proposals, but
there is no compelling argument to me for their existence. Time and
time again, through the course of developing the WS-Addressing
specification, there were discussions of whether WS-Addressing were a
stack layer or a building block. Building Block on the argument.
This proposal seems to b going in the opposite direction.
3) Should the community desire this feature enough to seriously
endeavor to make it happen, then it ought to deal with it as an
amendment or next revision to the WS-Addressing specification. Simply
because it is rather unlikely, albeit possible, to charter a group
within the W3C, it seems that the level of difficulty in some way
appropriately reflects the community at-large and its opinion about
the necessity of this proposal. Adding this feature by virtue of the
smaller circle of debate within the WS-I BP WG of the WS-I does not
bode well for its acceptance and thus the acceptance of profiles in
which this requirement might be contained.
I urge all members of BP to resist the temptation of feature addition
at this stage in the game, especially since there is no fundamental
application or business capability enabled by this feature-add that is
not present without it.
WS-I is not the place to re-design after the fact.
-bob
On Feb 17, 2009, at 4:15 AM, David Illsley wrote:
>
> I'll try to avoid spitting the dummy in this e-mail at least... ;-)
>
> It does feel like this question is spiralling out of control... and
> I don't think it has to.
>
> It is my assertion that the BP use cases could be satisfied by:
> 1. Allowing WS-A assertions to be attached to the binding operation
> if and only if no WS-Addressing assertions are attached at the
> endpoint subject
> 2. WS-A assertions must be present either on all binding operations
> of a given binding or none of them.
>
> This:
> 1. Allows operation level control of WS-A sync/async
> 2. Satisfies the very good advice of WS-Policy 1.5 Attachment
> section 4.1
> 3. Retains the existing semantics of the WS-A assertions
> 4. Can be summed up in a couple of sentences (seems suited to BP...)
> 5. Provides a simple WSDL level conformance check (it's one place or
> the other.... seems suited to BP)
>
> It does not:
> 1. Address what policy frameworks should do when they come across
> policy alternatives which are invalid per WS-A Metadata 3.1.3
> Personally, I expect most WS-A policy domain code to spit
> the dummy, but having written that code a couple of times, the
> processing happens at times when that's an appropriate thing to do.
> 2. Provide a concise 'override' format for WS-A Policy in WSDL...
>
> David
>
> David Illsley
> MP211, IBM Hursley Park, SO21 2JN
> +44 (0)1962 815049 (Int. 245049)
> david.illsley@uk.ibm.com
>
>
> From: Bob Freund <Bob.Freund@hitachisoftware.com>
> To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
> Cc: Gilbert Pilz <gilbert.pilz@oracle.com>, Fabian Ritzmann <Fabian.Ritzmann@Sun.COM
> >, Anish Karmarkar <Anish.Karmarkar@oracle.com>, "Rogers, Tony" <Tony.Rogers@ca.com
> >, ashok.malhotra@oracle.com, Rama Pulavarthi
> <Rama.Pulavarthi@Sun.COM>, Monica Martin <momartin@microsoft.com>, ylafon@w3.org
> , public-ws-addressing@w3.org, Jitendra.Kotamraju@Sun.COM, Ram
> Jeyaraman <Ram.Jeyaraman@microsoft.com>, wsi_wsbasic@mp.ws-i.org
> Date: 16/02/2009 18:05
> Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
> Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
> Sent by: public-ws-addressing-request@w3.org
>
>
>
>
> Draft insertion as part of the errata process:
>
> When presented with conflicting policies, endpoints or services are
> expected to make do with what they have, since these assertions do
> not present demands but describe some acceptable forms of addresses,
> potentially amongst others, that might be accepted. By making do
> with what it has, the service or end point is to collect all the
> various bits of policy assertions it has at its disposal and may
> consider them all to be potentially usable policy alternatives.
> Implementations are encouraged to respond with a non-anonymous form
> if presented or an anonymous form if not.
>
> Irrational behavior such as locking up completely, or electronically
> spitting the dummy by throwing faults that nobody is listening for
> and might not be received anyway especially since you can't
> determine what address form is acceptable, is not to be tolerated
> and will result in a free membership to the WS-Policy Working Group
> with the Complements of WS-Addressing.
>
> -bob
>
> On Feb 16, 2009, at 12:08 PM, Yalcinalp, Umit wrote:
>
> Looks like the perfect thing that an "errata" process should handle.
>
> --umit
>
>
> From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> Sent: Saturday, February 14, 2009 4:16 PM
> To: Bob Freund
> Cc: Fabian Ritzmann; Anish Karmarkar; Yalcinalp, Umit; Rogers, Tony; ashok.malhotra@oracle.com
> ; Rama Pulavarthi; Monica Martin; ylafon@w3.org; public-ws-addressing@w3.org
> ; Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org
> Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
> Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
>
> You don't need the two nested assertions to occur in the same policy
> alternative for there to be a conflict. Take a look at the following
> WSDL, it has two wsam:Addressing policies that are attached where WS-
> AM 1.0 currently says you can attach them, yet there is a conflict.
>
> <wsdl:definitions targetNamespace="http://www.wstf.org/docs/scenarios/sc003
> "
> . . .
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata
> "
> xmlns:wsp="http://www.w3.org/ns/ws-policy">
> . . .
> <wsdl:binding name="sc003SOAP12Binding" type="tns:sc003Port">
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy>
> <wsam:NonAnonymousResponses/>
> </wsp:Policy>
> </wsam:Addressing>
> </wsp:Policy>
> . . .
> </wsdl:binding>
>
> <wsdl:service name="sc003Service">
> <wsdl:port name="soap12port" binding="tns:sc003SOAP12Binding">
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy>
> <wsam:AnonymousResponses/>
> </wsp:Policy>
> </wsam:Addressing>
> </wsp:Policy>
> <soap12:address location="http://www.wstf.org/sc003/
> sc003SOAP12"/>
> </wsdl:port>
> </wsdl:service>
>
> </wsdl:definitions>
>
> The knowledge necessary to resolve this conflict is no less domain-
> specific than the knowledge necessary to figure out what to do when,
> for example, a binding is marked as non-anon but a specific
> operations is marked as supporting anon.
>
> - gp
>
> Bob Freund wrote:
> In WS-Addressing metadata 1.0 section 3.1.3 it says that
> "The wsam:NonAnonymousResponses policy assertion MUST NOT be used in
> the same policy alternative as the wsam:AnonymousResponses policy
> assertion."
>
> So, is the issue what happens when that conflict occurs?
> Is the issue that no fault is identified?
> With respect to fault transmission, should it be desired, where
> might it be sent unless there existed some non-conflicting policy?
> -bob
>
>
> On Feb 13, 2009, at 4:04 AM, Fabian Ritzmann wrote:
>
> On 13. Feb 2009, at 08:40, Anish Karmarkar wrote:
>
> In this particular case, how would one know that
> wsam:AnonymousResponse conflicts with wsam:NonAnonymousResponse
> unless you have some domain-specific information. These are two
> different QNames.
>
> Based on the responses and the spec, it seems that the following
> three scenarios are identical:
> 1) NonAnon on binding and Anon on port
> 2) A policy on binding (or port) that says: <wsp:All>Anon + NonAnon</
> wsp:All>
> 3) NonAnon on binding and Anon on binding/operation (if this were to
> be allowed)
>
> So, I don't quite see why allowing addressing assertion on binding/
> operation makes things any more problematic than it already is (as
> far as this specific issue is concerned).
>
> It seems that we have established that there may be conflicting
> addressing policies and those conflicts can only be detected and
> resolved in a domain-specific manner. Apparently that issue had been
> ignored or not recognized by the WS-Addressing WG earlier. I believe
> that the WS-Addressing WG would need to address that issue. The
> proposal has highlighted this issue and addressing it would remove
> one major concern with the proposal.
>
> Fabian
>
>
> Yalcinalp, Umit wrote:
> I go away and look what happens :-) Read Section 4.5 carefully, mate.
> Not all compatibility is domain specific. If you do not have assertion
> params, you have the Qnames to go with for compatibility. The whole
> idea
> is to rely on the types as much as possible and make the exceptions an
> exception, not a norm, so that one could rely on a program, not a
> human
> to make the determination of compatibility, whether it is lax or
> strict.
> Thus, compatibility is well defined in a domain-independent world.
> This
> is why parametric assertions of the past became the nested
> assertions of
> today. But, I will sign off for now. Have fun! HTH, --umit
> -----Original Message-----
> From: Rogers, Tony [mailto:Tony.Rogers@ca.com] Sent: Thursday,
> February 12, 2009 4:34 PM
> To: ashok.malhotra@oracle.com; Yalcinalp, Umit
> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
> Freund; ylafon@w3.org; public-ws-addressing@w3.org;
> Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org;
> Fabian Ritzmann
> Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
> Issue:
> (re: [wsi_wsbasic] BP 20133: proposal 1)
> I thought the "explanation" was that policy compatibility was
> domain-dependent, and could not be stated in a general way?
> But yes, something of a diversion from topic.
> Tony Rogers
> tony.rogers@ca.com
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of ashok
> malhotra
> Sent: Friday, 13 February 2009 11:23
> To: Yalcinalp, Umit
> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
> Freund; ylafon@w3.org; public-ws-addressing@w3.org;
> Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org;
> Fabian Ritzmann
> Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
> Issue:
> (re: [wsi_wsbasic] BP 20133: proposal 1)
> Hi Umit, good to hear from you!
> Unfortunately, this is like a eleventh commandment -- Thou shalt not
> attach incompatible policies
> It does not say how incompatible policies can be detected, nor does
> it say what to do when you find incompatible policies
> But I think we are getting away from the original topic.
> All the best, Ashok
> Yalcinalp, Umit wrote:
> Did we duck or actually say the following in section 4.1?
>
> {It is RECOMMENDED that, where specific policy assertions associated
> with one policy subject are only compatible with specific policy
> assertions on another policy subject in the same hierarchical chain,
> the
> policies containing these assertions should be attached within a
> single
> WSDL binding hierarchy.
>
> For any given port, the policy alternatives for each policy subject
> type
> SHOULD be compatible with each of the policy alternatives at each of
> the
> policy subjects parent and child policy subjects, such that choices
> between policy alternatives at each level are independent of each
> other.}
>
> We did not address what should happen when conflicts arise, but the
> recommendation is not to create conflicts in the first place...
>
> --umit
>
>
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of ashok
> malhotra
> Sent: Thursday, February 12, 2009 3:29 PM
> To: Anish Karmarkar
> Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
> ylafon@w3.org; public-ws-addressing@w3.org;
> Jitendra.Kotamraju@Sun.COM;
> Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org; Fabian Ritzmann
> Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
> Issue:
> (re: [wsi_wsbasic] BP 20133: proposal 1)
>
>
> Unfortunately, WS-Policy ducked this question. There are many
> situations where you can attach conflicting policies and there is no
> guidance as to what should be done. Note that, in general, it can be
> difficult to tell if policies are in conflict.
> All the best, Ashok
>
>
> Anish Karmarkar wrote:
>
> Good question.
>
> Shouldn't the answer be the same as what would happen if the
> operation
>
>
> specific policy was instead attached to the port? This would give you
> conflicting policies on binding and port and would have to be merged.
> These attachment points are currently allowed by the spec.
>
> -Anish
> --
>
> Rama Pulavarthi wrote:
>
> Some questions on the proposal.
>
> Gilbert Pilz wrote:
>
> As the authors of the proposal in question, Oracle feels obliged to
> refute the inaccuracies in the arguments presented by our
> colleagues
>
>
> from Microsoft and Sun as well as present our case with regards to
> the proposal.
>
> With regards to the particular points:
>
> 1.) What this point fails to mention is that WS-Adressing 1.0 -
> Metadata (WS-AM 1.0) *already* states that the wsam:Addressing
> assertion can be attached to the wsdl11:port or wsd11l:binding. Our
> proposal *extends* the existing specification to allow this
> assertion to be attached to wsdl11:binding/wsdl11:operation and
> applies this extension to the Operation Policy Subject. Our
> proposal
>
>
> does not alter the structure or the semantics of the
> wsam:Addressing
>
>
> assertion.
>
> What if conflicting policies are attached at the Endpoint policy
> subject and Operation policy subject.
> For example, on wsdl:binding it is specified as
>
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy>
> <wsam:NonAnonymousResponses/>
> </wsp:Policy>
> </wsam:Addressing>
> and on the </wsp:Policy>
>
> and on |wsdl11:binding/wsdl11:operation
> |
>
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy>
> <wsam:AnonymousResponses/>
> </wsp:Policy>
> </wsam:Addressing>
> and on the </wsp:Policy>
>
> Which one should be used?, How is the effective policy for that
> operation calculated?
> Its not precedence but a merge of these policies that is used to
> calculate the effective policy as per http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#merge
> .
>
> Is BP going to specify all the Addressing domain specific rules to
> handle merging of conflicting policies?
>
> 2.) The assertion that this proposal conflicts with WS-Policy best
> practices is false. Reference [3] below includes the following
> text:
> When the assertion's semantics do not change to invalidate any
>
> of
>
> the original policy subjects but new policy subjects need to be
> added, it may be possible to use the same assertion to
> designate
> the additional policy subjects without a namespace change. For
> example, a policy assertion for a protocol that is originally
> designed for endpoint policy subject may add message policy
> subject to indicate finer granularity in the attachment
> provided
> that endpoint policy subject is also retained in its design.
>
> When
>
> new policy subjects are added it is incumbent on the authors to
> retain the semantic of the policy assertion
>
> Since our proposal includes this text:
>
> When the WS-Addressing policy assertion occurs on the
> wsdl11:binding/wsdl11:operation element, it applies to the
> operation policy subject. Nevertheless, it should always be the
> case that if one operation of an endpoint supports or requires
> WS-Addressing, then all operations must support or require
> WS-Addressing (although, potentially, with different
>
> restrictions)
>
> and the following requirement:
>
> Ryyyy: /In a /*DESCRIPTION*/, if any operation of a WSDL 1.1
> endpoint supports or requires WS-Addressing, then all the
> operations of that endpoint MUST support or require
>
> WS-Addressing./
>
> /As I understand, This goes against the policy scopes/ and effective
> policy calculation as defined in
>
> http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffe
> ctivyPolicywithWSDL1.1
> How can a policy specified at Operation policy subject affect the
> effective policy at the Endpoint policy subject? The policy
> specified at Operation scope can add more non conflicting
> requirements to the policy specified at a higher level that will be
> effective only for that operation.
>
>
> thanks,
> Rama Pulavarthi
>
> it is clear that the semantics of the wsam:Addressing policy
> assertion are being retained and thus we are adhering to the
> guidelines described in [3].
>
> 3.) The claim that our proposal "disregards the existing structure
> of the WS-AM policy assertions" and jeopardizes backwards
> compatibility is false. As stated previously, our proposal does
> nothing to change the structure or the semantics of the
> wsam:Addressing assertion, it simply extends where such assertions
> can be attached. Furthermore, since it is an extension, our
> proposal
>
>
> logically cannot affect backwards compatibility. The
> implementations
>
>
> that interoperated at [5] should, baring any unrelated changes,
> continue to interoperate under the same test scenarios.
>
> 4.) The assertion that this change is "substantive" is subjective.
> The notion that this extension conflicts with the existing
> wsam:Addressing semantics has been addressed above.
>
> The case for this proposal is straightforward: The current WS-
> Addressing 1.0 - Metadata specification is technically
> deficient.
>
>
> It does not allow you to describe an interface that contains both
> synchronous and asynchronous operations. Input from our customers
> indicates that this is a common and important use case. The Web
> Services Test Forum provides an example of this in its Purchase
> Order Service scenario (http://www.wstf.org/docs/scenarios/sc009/sc009.xml
> ). Although
> there
>
>
> are workarounds for this problem, they have side-effects that
> undermine the simplicity and utility of the interface description.
>
> One of the reasons Oracle raised this issue is the fact that this
> technical deficiency is the result of an oversight by the W3C
> Addressing Working Group, not the result of a deliberate decision.
> In the WS-Addressing 1.0 - WSDL Binding specification, the
> wsaw:Anonymous element extended the wsd11:binding/wsdl11:operation
> element thus allowing you to specify that a particular operation
> was
>
>
> either synchronous or asynchronous. As the WSDL Binding
> specification evolved into the Metadata specification, the
> wsam:AnonymousResponses and wsam:NonAnonymousResponses assertions
> (which each express a distinct value of what was wsaw:Anonymous)
> were folded into nested assertions beneath the top-level
> wsam:Addressing assertion. Although this change was, in itself,
> technically correct, it had the side-effect of removing the ability
> to specify synchronous/asynchronous behavior at the operation level
> since , as we have discussed, wsam:Addressing can currently only be
> attached to the wsdl11:port or wsdl11:binding and has Endpoint
> Policy Subject. Our proposal seeks to correct this flaw in a way
> that preserves the semantics of wsam:Addressing.
>
> Finally, we brought this issue to the WS-I Basic Profiles Working
> Group because the W3C WS-Addressing Working Group is closed.
> Although there have been some discussions about creating a group to
> maintain the WS-Addressing specifications within the W3C it seems
> unlikely, at this time, that such a group will be created. Since
> correcting profiled specifications has some precedent in WS-I and
> the Basic Profile Working Group, it seems to be the best place to
> attempt to fix this problem.
>
> Gilbert Pilz | SOA/WS Technologist | Middleware Standards | Oracle
> Corporation
>
> Monica Martin wrote:
>
> An issue has been filed in the WS-I Basic Profile WG that belongs to
> WS-Addressing WG with possible assistance from the WS-Policy
> WG.
>
>
> The issue was filed in WS-I Basic Profile WG because the WS-
> Addressing WG was closed. The issue seeks to overturn a fundamental
> concept and constraint in WS-Addressing-Metadata 1.0 and could
> conflict with WS-Policy best practices. We've
> paraphrased
>
>
> the features sought, requirements requested and potential conflict
> it presents for existing implementations of WS-Addressing Metadata
> 1.0. As a WS-A Core schema change was handled in late July 2008
> by
>
>
> W3C on behalf of the WS-Addressing WG [1], can you assist us in
> clarifying and resolving this issue?
>
> The proposed changes:
> 1. Overturn a WS-AM 1.0 restriction that wsam:Addressing be
> limited
>
>
> to an endpoint policy subject [2]: Mandates these assertions be
> attached to a WSDL 1.1 port, binding or
>
> wsdl11:binding/wsdl:operation.
>
> 2. Could conflict with WS-Policy best practices on altering
> semantics of existing assertions for a policy subject: Allows a
> policy assertion to be used across different policy subjects without
> versioning or a clear indication how to differentiate semantics for
> assertion implementers. [3]
> 3. Disregards the existing structure of WS-AM policy assertions that
> can support such a Description without this change and
> without
>
>
> jeopardizing backward compatibility [4]: This proposal affects
> interoperable implementations that tested in July 2007 into non-
> conforming implementations. [5]
> 4. Introduces a substantive change or new conflicting feature to WS-
> AM.
>
> Can you also advise what is the maintenance plan for the WS-
> Addressing WG? Can you comment or act on this substantive WS-AM
> change? Are you in agreement to such a change in WS-I? [6]
>
> Your prompt attention would be appreciated. Responses can be
> directed to the chair of the WS-I Basic Profile WG. Thanks.
>
> Jitendra Kotamraju, Sun Microsystems
> Monica J. Martin, Microsoft Corporation
>
> [1] IBM request resolution:
>
> http://lists.w3.org/Archives/Public/public-ws-addressing/2008Jul/0001.ht
> ml
> [2] The same approach was also taken by SOAP/XMLP for MTOM.
> [3] The wsam:Addressing policy assertion is applied on multiple
> policy subjects with differing semantics - No versioning is use.
> No
>
>
> mechanism is provided for existing implementations to be backward
> compatible. Clients may be unable to find a compatible policy.
>
>
> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#supporting
> -new-policy-subjects,
> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#bp-WSDL-mu
> ltiple-policy-subjects,
> http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/#versioning-pol
> icy-language,
> http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffe
> ctivyPolicywithWSDL1.1
> and
>
> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#versioning
> -policy-assertions
> <http://www.w3.org/TR/2007/NOTE-%0Aws-policy-guidelines-20071112/#versio
> ning-policy-assertions>
> [4] A portType can be separated into two separate ones, one which
> contains one type of operations and the other which targets
> another
>
>
> type. This description supports interface related features sought by
> tools as was envisioned by W3C. [5] http://dev.w3.org/2004/ws/addressing/testsuitewsdl/report/
> [6] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify and
>
> http://www.w3.org/2005/10/Process-20051014/tr.html#correction-classes
>
>
> Notice: This email message, together with any attachments, may
> contain information of BEA Systems, Inc., its subsidiaries and
> affiliated entities, that may be confidential, proprietary,
>
>
> copyrighted and/or legally privileged, and is intended solely for
> the use of the individual or entity named in this message. If you
> are not the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>
Received on Monday, 23 February 2009 22:41:04 UTC