RE: WSDL 2.0 component model tests

Jonathan,

Recall that we came to the realization that the component model that 
results from processing a WSDL 2.0 document depends on the extensions that 
are engaged when the processing starts. For example, the safety extension 
causes a property to appear even if no markup is present.

Therefore, each test case needs to define the extensions that are engaged. 
We have been making this assumption that all the Part 2 extensions are 
engaged.

Now, you are introducing a new extension, i.e. WS-Addressing. We have two 
ways to proceed:

1) Just list any non-Part 2 extensions in TestMetadata.xml
2) Explicitly list all the extensions in TestMetadata.xml

In your example, you list the addressing and SOAP extensions, which is 
inconsistent.

For simplicity, I think 1) is best. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



"Jonathan Marsh" <jonathan@wso2.com> 
Sent by: www-ws-desc-request@w3.org
12/05/2006 01:02 PM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
<www-ws-desc@w3.org>
Subject
RE: WSDL 2.0 component model tests






I went around on that a couple of times, but it made most sense to me to 
only list the extensions that are required by the test in the test 
metadata.  For instance, an implementation that didn?t support the HTTP 
binding, would still be able to run the WSAddressing-1G test.
 
The implementations.xml file lists all the extensions supported by a 
particular implementation, and if the TestMetadata indicates an extension 
is required that the implementation doesn?t support, it will fill in the 
table with an ?unsupported extension?.  For instance here?s wsdl-xslt?s 
implementation manifest.
 
      <implementation name="WSDL XSLT" results-folder="wsdl-xslt">
            <supports extension="http://www.w3.org/2006/01/wsdl-extensions
" engaged="always"/>
            <supports extension="http://www.w3.org/2006/01/wsdl/http" 
engaged="always"/>
            <supports extension="http://www.w3.org/2006/01/wsdl/rpc" 
engaged="always"/>
            <supports extension="http://www.w3.org/2006/01/wsdl/soap" 
engaged="always"/>
            <supports extension="http://example.org/unknown-wsdl-extension
" engaged="always"/> <!-- assumes it's a dummy extension -->
            <supports extension="http://www.w3.org/2006/05/addressing/wsdl
" engaged="on-demand"/>
      </implementation>
 
There are a few interesting things here.  You can see that wsdl-xslt 
claims to support the unknown-wsdl-extension (so does Woden).  This isn?t 
really true, unless the definition of unknown-wsdl-extension paradoxically 
happens to be ?no change to component model?, as I?ve assumed here.  Canon 
doesn?t support this extension, as indicated by the fact that they refuse 
to generate any interchange results for a document that requires this 
extension. 
 
As you recall, Echo-2G, which introduces this extension, was cloned into 
the Bad documents bucket (should fail validation if the extension is 
really unknown), but for test purposes I left a copy in the Good documents 
to test and illustrate the extension matching logic.  We might want to get 
rid of this testcase and remove the claims that our extensions support it.
 
Implementations.xml also has an attribute engaged=?always|on demand? which 
is not used at present, although it describes the capabilities of the 
implementations accurately, as I changed my build process to engage the 
WS-Addressing extension for the one test that needs it (manually, rather 
than based on the implementations.xml metadata, at this point).
 
As I think I mentioned, the ability to mix and match extension support in 
an implementation with a testcase isn?t fully generalized.  Since our 3 
implementations all support virtually identical sets of implementations, 
we maintain only a single set of Baselines rather than a separate baseline 
for each combination of supported extensions.  That?s good enough for now, 
but if I ran my stylesheet with WS-Addressing engaged always, I?d end up 
with a different set of results (with {action} properties on each 
operation) that would hopefully be correct but not match the current 
Baseline.
 
Jonathan Marsh - http://www.wso2.com - 
http://auburnmarshes.spaces.live.com
 

From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Monday, December 04, 2006 8:10 PM
To: Jonathan Marsh
Cc: [WS-A]; www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: WSDL 2.0 component model tests
 

Jonathan, 

Nice work. I see you've made creative use of the <Input> element to 
specify the extensions: 

<Input role="root">wsaTestService2.wsdl</Input> 
<Input role="required-extension">http://www.w3.org/2006/01/wsdl/soap</
Input> 
<Input role="required-extension">http://www.w3.org/2006/05/addressing/wsdl
</Input> 

Why are you explicitly specifying SOAP and not the other extensions from 
Part 2? I think we should be consistent, i.e. assume the presence of ALL 
the Part 2 extensions OR explicitly list them. BTW, Woden cannot 
selectively turn off the other extensions at present. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca 


"Jonathan Marsh" <jonathan@wso2.com> 
Sent by: www-ws-desc-request@w3.org 
12/01/2006 07:10 PM 


To
"[WS-A]" <public-ws-addressing@w3.org> 
cc
<www-ws-desc@w3.org> 
Subject
WSDL 2.0 component model tests
 


 
 




I?ve updated my WSDL 2.0 ?implementation? to handle WS-Addressing 
extensions. 
  
Wsdl-xslt is a stylesheet that transforms WSDL documents to a so-called 
?interchange? format which is a direct, and verbose, serialization of the 
component model.  It?s used to verify that WSDL 2.0 parsers are acting 
consistently.  My stylesheet provides a baseline against which to compare 
other, more sophisticated, implementations (as well as putting another set 
of implementer eyes on the spec.) 
  
With the WS-Addressing extension support, one can browse the component 
model directly and verify that WS-Addressing properties were included 
appropriately. 
  
I also generated a WSDL 2.0 form of one of the WS-Addressing WSDL tests to 
work with [1].  The component model results can be viewed at [2]. 
  
I hope this encourages other implementations (e.g. Woden ;-) of the 
WS-Addressing extensions to WSDL 2.0. 
  
As the WS-Addressing WG develops WSDL 2.0 test cases, please submit them 
to the WSDL 2.0 test suite as well.  In addition, we?re close to getting 
an automated system in place for analyzing message logs wrt a WSDL 2.0 
document.  It is easy to imagine extending that framework to handle 
WS-Addressing extensions as well (e.g. verify that the wsa:Action in the 
message conforms to the {action} property in the component model.) 
  
[1] 
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/documents/good/WSAddressing-1G/ 

[2] 
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/results/wsdl-xslt/WSAddressing-1G/wsaTestService2.canonical.wsdlcm?rev=1.7 

  
Jonathan Marsh - http://www.wso2.com - 
http://auburnmarshes.spaces.live.com