Re: [xml-dev] Caution using XML Schema backward- or forward-compatibilit

["Greg Hunt" <greg@firmansyah.com>]

Stephen,
Actually yes.  Its a mess, isn't it?  If we have to do a non-zero amount of validation in application code, how much value do we get from a loose schema?  Is doing validation in two places really good design? Schema validation gets turned off usually because it is costly in CPU cycles but all too often that exposes the application to a range of failure modes that are discovered empirically.  For a significant system I'd quite frankly rather spend the money on something like a DataPower box or two to do Schema validation and Schematron with hardware assists than try to deal with an exciting range of outages (or worse, subtle data corruption) caused by hand-checked or unchecked data inputs to a system that we accept because we want to hold down the number of CPUs and application server licenses.

The effect of the all-too-common approach of validating in multiple places that you describe is to make the pain caused by a change larger and more difficult to assess with any accuracy.   In change management terms application software-based validation makes the problem worse.   Far worse if you don't control both sides of the data exchange. 

Is there any such thing as a generally compatible schema change?  Sure we can define extension points or whatever in the schema, make elements optional, but considered holistically how much benefit do we really get outside of avoiding changes to the schema itself?  I'd like to see some discussion of the schema change/code change trade-off in both open and closed environments.


Greg

On 12/27/07, Stephen Green <stephengreenubl@gmail.com> wrote:

But you accept that making things mandatory in the schema will
have the side-effect of making it permanent too (if you have a
forwards-compatibility versioning strategy and commitment)? And
this leads to the strong motivation to change semantics instead,
which is a dangerous kind of change.

So by avoiding application validation in addition to the schema (does
anyone actually ever not validate in the application after the schema
validation - don't most turn schema validation off after test phase and
use application level validation instead??) you have created an even
greater need for even more complex (perhaps impossible) validation
in the application - validation of the semantics :-)

On 27/12/2007, Greg Hunt < greg@firmansyah.com> wrote:
> And if we engage in "avoidance of making things mandatory" for any reason
> other than enforcing real business data constraints we reduce the value of
> schema-driven validation.  Doing that requires the applications to do their
> own structural validation to enforce the business requirements for
> mandatory-ness which in turn makes implementing changes or assessing the
> impact of a change even harder.
>
> Greg