The xsd:extends would declare a new element, according to XML Schema. It
would not be the same element. That is, if one says <x:e> there are NO
variants unless namespace delacration rules and XML Schema is broken.
-----Original Message----- From: Steve Graham
[mailto:sggraham@us.ibm.com] Sent: Mon 11/1/2004 7:32 PM
To: Vambenepe, William N Cc: Sedukhin, Igor S; Vambenepe,
William N; wsrf@lists.oasis-open.org Subject: RE: [wsrf] new issue:
portType composition and properties document composition
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
|