Handling parse-time errors in WSDLReader

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

Hi Lawrence,
saw your comments in Messages.properties about whether certain messages are
still required. I guess the question is whether the underlying errors need
to be checked at all in the WSDLReader or whether they should be left for
the Validator. We'll speak later today, so here's a starter for further
discussion. I will post any outcomes to the mailing list.

WSDLReader currently defines the features 'validation' and
'continue-on-error'. The 'validation' feature indicates whether the
Validator logic gets invoked. The 'continue-on-error' feature indicates
whether to continue parsing after encountering a non-fatal error (i.e.
parsing always terminates after a Fatal Error, it always continues after a
Warning, but for a non-fatal Error we check the continue-on-error property
to determine whether to continue or terminate).

We have at least 3 WSDLReader parsing scenarios involving the 'validation'
and 'continue-on-error' features:

1) Validation is true.
The WSDL is parsed and schema validation and semantic rule validation is
performed by the Validator.

2) Validation is false and continue-on-error is true .
We parse the WSDL and build as much of the model as possible, reporting any
parse-time errors encountered by the WSDLReader but not invoking the
Validator logic. This is the WSDL editing scenario where a WSDL author
wants to work on incomplete WSDL and validate it only when it's complete.

3) Validation is false and continue-on-error is false
We parse the WSDL, reporting and terminating on the first parse-time error
encountered by the WSDLReader (i.e. same behaviour as WSDL4J).
This is the runtime scenario where full validation is turned off for
performance because deployed WSDL is assumed to be valid, but if we do
encounter a parse-time error in the WSDLReader we want to report it and
terminate immediately.

'Parse-time errors in the WSDLReader' include things like being unable to
create a URI or a QName from a WSDL attribute value. Currently, they also
include things like target namespace attribute missing from <description>
or <xs:schema>, or namespace inequality between an <xs:import> element and
the imported schema document.

We probably need to discuss further these 'parse-time errors' in the
context of scenarios 2) and 3) - i.e. what, if anything, should be checked
in the Reader.

John Kaputin


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