Schemas: stereotypes, archetypes or prototypes?

The problem with schemas is this: sometimes we need prototypes, sometimes we need archetypes, sometimes we need stereotypes, but transitioning between them is not trivial in any schema language, which may be optimised for particular cases.

Schema-as-stereotype is the classical view of a schema: something solid that is emulated. The old SGML idea of DTD as a contract between document provider and consumer is schema-as-stereotype.

However, when you have data interchange between preexisting systems which, though the same domain, were not each designed with a view to interchange, the availability of data becomes the luck of the draw. In this kind of case, the official schema becomes a wish list, a way of labelling information that does fit in shared ways. Think of the large industry-specific schemas such as ACORD. Schema-as-archetype is this wish-list view of a schema. There are quite a few schemas which borrow with minor changes from other schemas: ODF's not-quite-SVG graphics and OOXML's inspired-by-SMIL animations for example— if we take the stereotype view of schemas, these are quite wrong, but if we take the archetype view, they are unsurprising.

Schemas evolve. CORBA is often held to have failed because re-deployment of updated agents to cope with schema (API) changes did not scale. Of course, the same can be true of XML systems that hard-code a schema and with programming teams that treat Garbage-In/Garbage-Out as an acceptable state of affairs rather than cautionary note that needs to be actively guarded against. Schema-as-prototype emphasizes that systems need to be built that embrace and enable change. Agility.

We can see that grammars are quite good as stereotypes. Namespaces are designed to help with archetypes and the namespaces-aware schema languages are helpful; however often as a practical matter architype labels (old-timers: I mean architectural forms of course) are often expressed using attribute values (see microformats) that elude the grammar-based validators. And while XSD has its type derivation mechanisms to allow evolution, the base schema is not the prototype, because it may need to be adjusted in order to cope with derived schemas.

Is Schematron the answer here? I don't know, and I don't see any reason why any one schema language should necessarily be best in each of these three cases, let alone be best in transitioning between them. Schematron's phase mechanism, its open content-model foundation, and its built-in restriction semantics certainly look like being the ballpark for many cases, but I hope we are beyond the expectation of magic bullets.