Re: [xml-dev] Service Constraints

[Andrew Welch <andrew.j.welch@gmail.com>]

> This subject often gives rise to some heated debate that somewhat
> predictably  tends to centre around subjects such as versioning,
> compatible/incompatible change, integrity of the base data model, ease
> of use for service consumer, potential service reuse and so on...
>
> So I thought I'd invite members of this community to comment on
> whether you favour very open lightly constrained schema when defining
> business services (at least when expressing the data content as XSD)
> or whether you prefer to try and specify all constraints even at the
> risk of generating greater churn (aka: incompatible change).

Instinctively I always went for a tighter XSD, but in reality and with
hindsight and being pragmatic then versioning XSDs is hard work, but
versioning the application is easy.

The problem is because application version A expects XSD version B,
and if you need to tweak the XSD to relax a rule then what are your
options?  It can become a real pain keeping track of which version of
the application accepts which versions of the XSDs...

It all seems to come back to where your store the rules - is it better
to fail at validation time with a cryptic "cvc-complex-type..." error,
or after validation in the application itself with a specific,
localised message.  In your application, is it better to process 99%
of the xml, or should nothing get processed where there is a
validation failure...

I still don't know the right thing to do, but now I tend towards a
relaxed XSD and putting the rules in the application.  A change that
doesn't then need a change to the XSD (because something is already
optional) is no problem at all.  Previously I would go for the
tightest possible schema, but when a change was needed (as is always
the case) meaning frequent new versions of the XSDs, it was a huge
pain.

The extreme flip side is an XSD where everything is optional, which
doesn't do anyone any good, but there is a sweet spot.  Its much
easier to put a comment/annotation in the XSD or a text file or wiki
etc explaining why something is optional but shouldn't be used, versus
the amount of time and effort to update the XSD, update its version,
'release' it, update the application, update the documentation saying
which version the XSD that version of the application supports etc.

So, at the moment, the 'open lightly constrained schema' gets my vote,
but only because there isn't some clear process to avoid the change
pain.


-- 
Andrew Welch
http://andrewjwelch.com