I've been evaluating XML schema, RDF/OWL, and RelaxNG for extensibility and versioning capabilities. Herein, I provide a draft version of a small set of scenarios that I think are good for a first pass evaluation.
The scenarios start simply, with the first scenario being compatible schema evolution where the type is extended at the end and the new type is created by simply rewriting the type with the additional extension. This proceeds through extension not at the end, to by-reference extension where the original type is left untouched and the new type refers to the original type + the extension, and concludes with by reference extension of another type that is an incompatible change with the original type.
Compatible Schema evolution by-value extension at end
A language is extended in a backwards and forwards compatible way, and a V2 Schema can be written by simply adding in the new information. My canonical example is a name type in V1 that requires first followed by last and allows extensions, ie name=first,last or name=first,last, middle. A subsequent version, V2, is a name that adds a middle. Both schemas should allow names with or without middles.
Compatible Schema evolution by value extension anywhere
Similar to the previous scenario with the addition that the content model allows for extension anywhere in the type. A middle could be added in between first and last, such as name=first,middle,last
Compatible Schema evolution by-value extension with duplicate prevention variant
This variant is a refinement of scenario #1 and #2 that adds a refinement that an element that is already known cannot occur in an extensibility point. In the first name example, it requires that a first name cannot also occur after a last name, ie name=first,last,first is precluded for extensibility at the end, and name=first,first,last is precluded with extensibility anywhere.
Compatible Schema evolution by-reference extension
This scenario is where the V2 schema refers to the V1 schema rather than augmenting the V1 schema. This is roughly nameV2 schema = name schema + optional middle
Incompatible Schema evolution by-reference extension by extension author
A v2 schema is not compatible with V1 and V2 is not authored by the V1 author. This is a common scenario for container languages, like SOAP and WSDL. These languages are specifically designed for extensibility and for extension authors to make incompatible extensions. An example is a Web service that requires that a SOAP body contain a particular element and the SOAP header MUST or MAY contain other elements. This is roughly where nameV2 schema = name schema + mandatory middle
Multiple Namespace names
Languages may, and often do, use multiple namespace names. Each of the scenarios has a variant where the V1 language consists of multiple namespace names. The first scenario with the multi-ns variant is roughly that V1Name = firstns:first, lastns:last.
Instance vs Schema Type vs Schema Language constructs
Schema languages provide and enable various constructs for extensibility and versioning. Each of the scenarios can be evaluated on what constructs are required to enable the extensibility and versioning. They range from roughly starting at the Schema language itself provides all the constructs necessary with schema instances and document instances containing no constructs, to the schema language provides constructs that must be used in schema instances or even document instances. An example of the latter is XML Schema, which provides a wildcard that must be combined with document instance constructs - such as a Extension element or Sentry/Marker element - to fulfill scenario #1.
Evaluation Criteria
This provides a small set of scenarios plus a couple of variants that can be used for examining extensibility and versioning in a schema language.