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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
