RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

+1 on all points. WS-I (and BP) need to focus on how to improve
interoperability by restricting choices (profile) or by fixing errors.
Adding new features is out of scope for WS-I IMHO. We can certainly
liaison with the spec owing organization (and the respective WGs) to
effect this kind of change.

 

Regards,

Prasad

 

________________________________

From: Bob Freund [mailto:Bob.Freund@hitachisoftware.com] 
Sent: Monday, February 23, 2009 2:40 PM
To: David Illsley
Cc: Anish Karmarkar; ashok.malhotra@oracle.com; Fabian Ritzmann; Gilbert
Pilz; jitendra.kotamraju@sun.com; Monica Martin;
public-ws-addressing@w3.org; public-ws-addressing-request@w3.org; Rama
Pulavarthi; Ram Jeyaraman; Rogers, Tony; Yalcinalp, Umit;
wsi_wsbasic@mp.ws-i.org; ylafon@w3.org
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)

 

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
<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 <mailto:ashok.malhotra@oracle.com> ; Rama
Pulavarthi; Monica Martin; ylafon@w3.org <mailto:ylafon@w3.org> ;
public-ws-addressing@w3.org <mailto:public-ws-addressing@w3.org> ;
Jitendra.Kotamraju@Sun.COM <mailto:Jitendra.Kotamraju@Sun.COM> ; Ram
Jeyaraman; wsi_wsbasic@mp.ws-i.org <mailto: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"
<http://www.wstf.org/docs/scenarios/sc003> 
                 . . .
 
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
<http://www.w3.org/2007/05/addressing/metadata> 
                 xmlns:wsp="http://www.w3.org/ns/ws-policy"
<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"
<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