Ian Robinson has a great 2008 article Service-Oriented Development with Consumer-Driven Contracts and a follow-up A Contract Vocabulary that turns normal thinking about schemas on its head.
His idea, in the context of SOA systems with a limited number of XML consumers who are known to the XML information provider, is to help rein in a tendency he sees in REST and WS-* systems where point-to-point APIs nominally using the same standard schemas actually relate little to each other, if I take his meaning properly.
The basic idea is that each data consumer creates an open schema (e.g. a Schematron schema) which just captures their requirements, but does not rule out any other requirements. The data producer may also have an open schema that expresses any producer specific metadata or requirements.
The trick is that all the consumer and producer schemas are combined to make what Robinson calls a Consumer-Driven Contract.
Whether implicit or explicit, service contracts to date have been overly provider-centric.
In Schematron, this is all very straightforward. It is easy to write open/partial schemas with Schematron, and there is no trick needed to combine them: just run them in parallel or include them into a single schema file.
Does Ian's idea fits in with my Three-layer model for XML with Schematron? I think so:
- an industry-standard vocabulary from some kitchen-sink standard can form the Glossary;
- the consumer works out its (sharable) business rules and the Schematron schema for them;
- the producer assembles the consumer-driven schema and validates its XML product against it;
- on the pragmatic layer, the original kitchen sink schema can be used, as well as any producer-specific metadata.