woden62 changes

[John Kaputin <KA...@uk.ibm.com>]

Lawrence,
I've made a lot of changes to the woden62 branch as my thoughts and code 
have evolved. I have made some API changes and completed a lot of the 
implementation, which was largely empty before.

The testcases you created now have compile breaks,  but there are some 
issues with fixing them.

Firstly, these individual assertion tests are functional tests of the WSDL 
spec and, like the 'good' document tests, they probably belong in the W3C 
WSDL 2.0 Assertion test suite as WSDL 2.0 documents.  For example, 
Interface-1009 already exists there as testcase Interface-2B (although I'd 
prefer a naming convention that matches the Assertion Id). I think I'll 
create some sort of 'staging' area ... a new package .... in the woden 
test suite, where we can develop any missing WSDL testcases prior to 
contributing them to the WSDL 2.0 test suite via bugzilla. Once they have 
been added to the W3C WSDL 2.0 Assertion test suite they can be deleted 
from the Woden test suite.

Secondly, I can't fix your testcases in their current style. The 
validation and assertion code has moved on from my early thoughts embodied 
in that initial commit to the woden62 branch.  The framework doesn't 
support stand alone use of assertions outside of woden. Even if you go 
outside the API, certain constructors in the relevant implementation 
classes are now private or package private where instantiation is meant to 
be handled by the woden framework, so you can't even use the internal 
classes directly.  The only way to test these assertions is via WSDL 
documents - parsing them with the WSDLReader and letting the woden 
framework invoke the assertion validation.

There is the issue of programmatic creation of WSDL descriptions and the 
requirement to validate such descriptions. One approach would be a 
validate() method on DescriptionElement or Description or a 
validate(Description) type of method somewhere on the API. If this were 
available, your existing test cases could be fixed. However, assertions 
only apply to schema-valid WSDL documents, so we will need to figure out 
how to schema-validate programatically created WSDL before we worry about 
how validate assertions against it. I think that's a job for later, after 
we've finished validating parsed documents.

regards,
John.






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







---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org

Re: woden62 changes

[Lawrence Mandel <lm...@ca.ibm.com>]

Hi John,

I have some comments on the work you've done. I've included them inline 
below.

>Lawrence,
>I've made a lot of changes to the woden62 branch as my thoughts and code 
>have evolved. I have made some API changes and completed a lot of the 
>implementation, which was largely empty before.
>
>The testcases you created now have compile breaks,  but there are some 
>issues with fixing them.
>
>Firstly, these individual assertion tests are functional tests of the 
WSDL 
>spec and, like the 'good' document tests, they probably belong in the W3C 

>WSDL 2.0 Assertion test suite as WSDL 2.0 documents.  For example, 
>Interface-1009 already exists there as testcase Interface-2B (although 
I'd 
>prefer a naming convention that matches the Assertion Id). I think I'll 
>create some sort of 'staging' area ... a new package .... in the woden 
>test suite, where we can develop any missing WSDL testcases prior to 
>contributing them to the WSDL 2.0 test suite via bugzilla. Once they have 

>been added to the W3C WSDL 2.0 Assertion test suite they can be deleted 
>from the Woden test suite.

I disagree. While assertions do warrant functional tests the tests I 
committed are unit tests. They test a specific unit of functionality in 
Woden, namely each assertion's validate method. Tests that involve parsing 
WSDL documents are integration or functional tests as they cover multiple 
components (parser, model, validator, registry, etc.). These tests are 
very useful for testing the correct functionality of Woden but do not 
necessarily help isolate the cause of a test failure. For example, if the 
Interface-2B functional test fails the problem may be that the document 
was not read or parsed properly, that the model was not created properly, 
that an extension was not registered correctly with the registry, that the 
validation framework did not run correctly, or that the assertion itself 
failed. Without unit tests we will need to debug all of Woden for any test 
failure.

>Secondly, I can't fix your testcases in their current style. The 
>validation and assertion code has moved on from my early thoughts 
embodied 
>in that initial commit to the woden62 branch.  The framework doesn't 
>support stand alone use of assertions outside of woden. 

I don't see anything preventing me from instantiating and using an 
assertion class outside of the framework. Remember, I don't have to go 
through the API for unit tests. Unit tests can and should where required 
reference internal packages and classes. Can you clarify this issue?

>Even if you go 
>outside the API, certain constructors in the relevant implementation 
>classes are now private or package private where instantiation is meant 
to 
>be handled by the woden framework, so you can't even use the internal 
>classes directly.  The only way to test these assertions is via WSDL 
>documents - parsing them with the WSDLReader and letting the woden 
>framework invoke the assertion validation.

The only artifact within the framework that I see that has a private 
constructor is the AssertionContext. I can get around this by creating an 
implementation of this interface (a test stub, common practice for unit 
tests) just for the unit tests. Take a look at the changes I committed for 
the tests for an example.

I also have a few issues with the AssertionContext:
1. I don't think the name is correct. Currently this interface contains 
references to an ErrorReporter and URIResolver. Neither of these objects 
has to do with the context of an assertion. I think these are really Woden 
context objects.
2. I don't think the ErrorReporter and URIResolver should be treated the 
same way. Every assertion will make use of an ErrorReporter and therefore 
I don't think they should each be required to call 
assertionContext.getErrorReporter to obtain it. 
3. I'm only aware of one assertion that will make use of the URIResolver. 
(Are there others?) Is there another way to obtain the URIResolver? If 
not, is there some way we can do this internally for this one assertion to 
avoid exposing the URIResolver to all of the assertion classes?

>There is the issue of programmatic creation of WSDL descriptions and the 
>requirement to validate such descriptions. One approach would be a 
>validate() method on DescriptionElement or Description or a 
>validate(Description) type of method somewhere on the API. If this were 
>available, your existing test cases could be fixed. However, assertions 
>only apply to schema-valid WSDL documents, so we will need to figure out 
>how to schema-validate programatically created WSDL before we worry about 

>how validate assertions against it. I think that's a job for later, after 

>we've finished validating parsed documents.

I think this is an important albeit separate issue from the unit test 
issue above. At a minimum I think the validator should be able to be 
called programmatically on a Woden model. We can build a model 
programmatically so we should be able to validate it programmatically. We 
will need to carefully consider the case of calling an individual 
assertion on a WSDL component/element as some of the assertions will fail 
if taken outside of the larger context of the WSDL document.

Lawrence

---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org