Re: Option to Remove Strict Schema Validation

[Anthony Bull]

Title: Option to Remove Strict Schema Validation

Hi Peter, I strictly use XML Beans as the data-binding for all my contract-first web services in Axis 2, and have actually had quite a few problems due to lack of schema validation.  That is, unless we specifically validate the XML Beans DOM and throw an error, Axis 2/XML Beans doesn't validate against the schema. Peter Conrey wrote: I have been developing web services and web service clients in a large corporate environment for several years now.  We employed several Perl web services (using SOAP::Lite) to feed both Java-based web clients (using Axis 1) and .NET clients in other departments.  While the architecture works very well, we’ve run into a very frustrating scenario that limits our ability to respond quickly to change requests.  Whenever we need to add data to a web service (say, a new field to a customer profile object), we have to completely re-deploy any Java application that uses that service/object, even if that new field is not relevant to the application. When we discovered that Axis 2 provided a means of turning off strict schema validation, we were excited to covert our code.  However, according to the Axis documentation, the only client format that supports the “-Eosv” option is ADB, which also carries the following limitation:     “It is not meant to be a full schema binding application, and has difficulty with structures such as XML Schema element extensions and restrictions.”         --http://ws.apache.org/axis2/1_4/userguide-creatingclients.html#createclients Unfortunately, we use both extensions and restrictions in our schema, as they best define our data structure.  How difficult would it be to add the “Eosv” option (or equivalent) to all data binding formats?  As much as I hate to tout Microsoft, .NET has no such limitation, so adding information to serialized objects has no effect on .NET clients.  While this may not be the “correct” behavior from a strict standards-based perspective, from a  practical, enterprise perspective, it is unacceptable to have to rebuild 8-10 client applications just to support a change required only by one or two, especially when one of the unaffected applications is beyond the service developer’s control. Has anyone else discovered a solution to this issue, or found a way around it? -- Anthony ------------------------------------- Anthony Bull Senior Developer Black Coffee Software Ltd PO Box 10-192 The Terrace Wellington, New Zealand [EMAIL PROTECTED] Ph +64 4 472 8818 Fax +64 4 472 8811 ------------------------------------- www.bcsoft.co.nz --------------------------------------------------------------- This email may contain confidential or privileged information, and is intended for use only by the addressee, or addressees. If you are not the intended recipient please advise the sender immediately and do not copy, use or disclose the contents to any other person or organisation. Black Coffee Software Ltd accepts no responsibility for viruses received with this email, or to any changes made to the original content. Any views or opinions expressed in this email may be personal to the sender and are not necessarily those of Black Coffee Software Ltd. --------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]