Service Constraints

[Fraser Goffin <goffinf@gmail.com>]

We use an XML schema library that models the majority of the entities
that we need to express business transactions. These typically can be
quite large complex types that contain the superset of all properties
for an entity. For example we might have a Customer complexType that
has 20 or 30 elements. When we use these complex types within the
context of creating a business transaction, there is an inevitable
discussion about whether a type should be specialised for that
particular context by applying greater constraints. For example, it
might be that for a particular business service schema, only 10 of the
elements in the Customer type are actually required, at least for now.
So we could create a new Customer type within the service schema that
only contains those 10. Others would prefer that the whole type is
used and all of the elements in it's content model remain as optional.
Part of the rationale for this is to minimise the possibility of
having to deal with a breaking change to the schema some time in the
future as/when requirements change and some of the excluded elements
could be required. A case is also made for leaving the full type so as
to provide a greater chance that the service schema will be more
reusable, and that by applying greater constraints (not limited to
just removing parts of the type but also tightening cardinality or
applying facts and so on) makes the service contract 'brittle'.

On the flip side, others prefer to have a service contract [schema]
which applies the fullest set of constraints and give the user of that
schema the best possible specification in terms of what data is
expected and would be valid in the context of the business
transaction. This is more in line with the concepts of 'consumer
driven contracts' which often have the (desirable) characteristic of
being much more communicative than schema that have few constraints
(ie. are packed with mostly (or completely) optional elements of type
xs:string of unspecified size or form).

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

Fraser.