RE: [wsrf] new issue: portType composition and properties documentcomposition

[Steve Graham <sggraham@us.ibm.com>]

The text describes that in order to
combine RPs from different portTypes, they must use the ref= construct
to include them in the RP doc of a new portType.  This prevents things
like using XSD:extension to accomplish the same thing.  So if one
designer used ref= and another used xsd:extension to combine the RPs of
the same portTypes, both would come up with an RP document that met requirements,
but the XPath queries would be very different between the two specs.

This is the sort of compatibility we
are looking to keep.  This allows management applications to "treat"
specializations of generic portTypes just as they would a generic portType.

sgg

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

"Vambenepe, William N" <vbp@hp.com>

10/29/2004 06:46 PM

To	"Vambenepe, William N" <vbp@hp.com>, Steve Graham/Raleigh/IBM@IBMUS, "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
cc	<wsrf@lists.oasis-open.org>
Subject	RE: [wsrf] new issue: portType composition and properties document composition

> Can you explain how removing
the description of forming the RP document is necessary for interop?
 
Oops, I meant "how having
the description", "not how removing the description".
 
William

---

From: Vambenepe, William N 
Sent: Friday, October 29, 2004 3:41 PM
To: Steve Graham; Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
Subject: RE: [wsrf] new issue: portType composition and properties
document composition

Steve,
 
Can you explain how removing the
description of forming the RP document is necessary for interop?
 
In the meantime, +1 to Igor (with
correction 4.3 to 4.4).
 
William

---

From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Friday, October 29, 2004 6:25 AM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] new issue: portType composition and properties
document composition


Section 4.3 defines the @ResourceProperties attribute extension of WSDL
1.1 portType. This is absolutely required.  We cannot and should not
remove section 4.3 

Now, Igor's discussion suggests that it is perhaps section 4.4 that is
the issue.  I am ok with removing the cut and paste discussion and
moving it into the app note.  I am totally against removing the descriptoin
of forming the RP document.  This text must stay for purposes of interoperability
of RP docs across different smashed portTypes. 

sgg 

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

"Sedukhin, Igor S" <Igor.Sedukhin@ca.com>

10/29/2004 12:45 AM

To	<wsrf@lists.oasis-open.org>
cc
Subject	[wsrf] new issue: portType composition and properties document composition

Before I forget, here is the issue that I promised to post after we closed
the "DerivedFrom" issue with no action. 
  
[ 
I propose to remove section 4.3 from the WSRF-RP document in favor of 
  
#1 the document defines a number of message exchanges which an implementer
of a Web services endpoint will need to support and, as a consequence,
describe in a WSDL document following the rules defined by WSDL. The only
conformance claim that the WSRF-RP specification can define is therefore
that the implemented WSRF-RP message exchnages MUST be described in WSDL.
Full stop. 
I want to note again, that the current draft of the WSRF-RP specification
does not require that operation names in WSDL be one way or the other.
This is good, and we must remove any other claims that profile use of WSDL
such as the section 4.3. 
  
#2 The same applies to the properties document. The implementer of a Web
service endpoint which intends to support WSRF-RP will decide what properties
document schema is needed. The implementer is responsible to understand
what properties will be supported, how and why. Any composition and rules
thereof are part of such understanding. The implementer, then, uses XML
Schema to describe the properties document. Full stop. 
I believe that WSRF-RP document MUST not make any assertions or normative
claims or even explanatory notes which describe how one comes to realization
*what* properties document to describe in the XML Schema. Therefore section
4.3 must be removed. 
] 
  
Igor Sedukhin