• From: Michael Kay <mike@s...>
• To: xml-dev@l...
• Date: Sat, 09 Apr 2011 00:07:41 +0100

A rather big question to try and answer at this time on a Friday night, 
especially when there is no answer. Glad I'm not the only one who sees 
this as a problem.

I had a client who got into a real mess with this. Rather than your two 
options of a specialized schema for each message or an over-liberal 
schema with lots of optional fields, they were making properties 
mandatory (every book must have an ISBN in the business model, therefore 
every message containing a book element must make the ISBN mandatory) 
and of course applications were putting rubbish in the data fields 
because they knew the recipient wasn't going to use them... A classic 
case of "if you get the integrity rules wrong, people will supply 
incorrect data just to satisfy the rules".

My preference is to aim for a precise schema for each message type, 
based on the definition of the data flow - this is where people often go 
wrong, they derive the message schema from the object model and not from 
the process model. The next question is how to manage reuse of 
components shared between multiple messages. XSD derivation by 
restriction is not much use here, because a restricted content model 
restates everything in its parent. I think a better approach is to 
generate the individual message schemas from some high-level 
description/catalog of messages in terms of the components that each 
message contains. A possible way to do this is to have a "master" 
abstract schema that declares everything, and transforms that subset it 
to concrete message schemas by removing fields or making fields optional.

Then there are other questions of course, like whether each message 
should have a different namespace. I think there's an answer here: use 
one namespace across all messages for the element names, but use 
per-message namespaces for the types. However, I have to confess that we 
decided on that as a strategic approach for one project, but I didn't 
actually see it through into successful practice.

Michael Kay
Saxonica



On 08/04/2011 23:17, Fraser Goffin wrote:
> 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.
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

• References:
  • Service Constraints
    • From: Fraser Goffin <goffinf@g...>