Request: Option to Remove Strict Schema Validation

[Peter Conrey <pf...@hotmail.com>]

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#
<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.