Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: The WSDL Validator uses it's own schema validator, which could lead to inconsistencies with validation as other validators and bug fixes are added to the XSD Validator. For consistency and reliability, the WSDL Validator should leverage the XSD validator, this way the WSDL validation for inline schemas is consistent with the XSD validation. If bugs are addressed in one, it will propagate to the other. Also bug 147033 addresses an issue about full conformance checking. If the WSDL validator doesn't use the existing XSD Validator this could lead to different validations between the two editors and validators. More information:
David C., the proper component for this is wst.wsdl. If you cannot change it let me know and I'll correct it.
Corrected component.
Vic you'll need to change the assigned to so that it goes to the correct inbox.
Valentine, I'm going to mark this one for a future bugday if that is okay. I'll take a look at the refactoring and see if I can get the WSDL editor so that it isn't duplicating the XSD validation and still try to maintain similar dependencies and functionality.
Sounds good. You know how to run the JUnits right? Them staying green should give you some reassurance that the refactoring will keep things functionally equivalent.
(In reply to comment #5) > Sounds good. You know how to run the JUnits right? Them staying green should > give you some reassurance that the refactoring will keep things functionally > equivalent. > Yep, I plan to make sure all the tests stay green. Dave
In order to implement this so that the XSD and WSDL validators behave the same for validation of the XSDs, the code for the WSDL Validators should be changed so that it accepts a XMLGrammarPreparser being passed to the validateXSD and validate methods in the XSDValidator class of org.eclipse.wst.wsdl.validation.internal.wsdl11.xsd. The ANT class would also need to be changed so that the Task in org.eclipse.wst.wsdl.validation.internal.ui.ant creates the necessary XMLGrammarPreparser setup based on information passed into it for controling the schema validation. Changing these internal APIs would result in potential adopter breakage if anybody is currently using the API. To bring the XSD validator up to the current default implementation that is now implemented in bug 147033, the full schema validation option has been changed from false (off) to true (on). This more closely matches the default options and provides greater XSD tool error reporting interoperablility with other XML Tools. All current WSDL tests still pass with the current change.
Created attachment 84262 [details] Bring WSDL XSD Validator up to default for XSD Validator Changes schema validation to a default of full compliance, from lax compliance. Brings it more in line the current implementation of the XSD validation conformance checking option.
Created attachment 84271 [details] Updated Patch to set default value for conformance and new optional constructors for XSDValidator This patch goes a step further in having the XSDValidator() constructor in the WSDL packages set the default handling of the schema conformance check. This keeps api compatibility, but allows for implementations to set the conformance level by instantiating the XSDValidator(boolean fullSchemaConformance) constructor call, which accepts a true or false value for setting compliance level. A similiar constructor would need to be added to the WSDLValidator in the wsdl.validation.internal package, so that it may use the new XSDValidator constructor to set the schema conformance level. However,because of the way this is currently handled, it looks like the WSDL11BasicValidator will need to have a set Method so that the conformance check can be set before the validate routine is called. I may view this option for further enhancement to this patch. Thoughts, and suggestions on how to improve the patch would be appreciated.
Further investigation, shows that the interfaces are going to complicate implementing this fully, even trying to put it at the WSDLConfiguration level will not address the issue, because of how far down the XSDValidator class is used in the chain. Is there a way where configuration information is passed to the validate methods? If so, we might be able to force it in there so that it is available farther down in the call hierarchy.
I think this is better handled as an enhancement.
