A language designer makes a number of significant choices when designing or extending a language. I thought I'd list some of the major extensibility and versioning choices that a designer makes, either implicitly or explicitly.
I haven't provided schemas for the name constructs, nor definitions of backwards/forwards compatibility, as those are provided frequently in other entries that can be seen from my compatibility page
The choices facing a designer, and some of the ramifications:
Q1: What schema language(s) will be written for the language?
This guides the language design as some features, particularly extensibility, must be planned for in V1 and various features may be incompatible across different languages. An example is writing a V2 compatible Schema in XML Schema requires an Extension Element or Delimiter element, which is not required in RelaxNG.
Q2: Can 3rd parties extend the language?
Although rare, there may be reasons why 3rd party extensions are not desirable.
Q3: Can 3rd parties extend the language in a compatible/optional or in an incompatible way?
If no rule is provided to differentiate between compatible and incompatible extensions, then the handling of extensions is ambiguous at best, and potentially harmful.
Providing a substitution mechanism, such as simply ignoring unknown items, is required for forwards compatibility. Incompatible changes can be done as an over-ride of the substitution mechanism (such as a must understand model or extension) or it can be the default. WS-Security desired that 3rd parties can only provide incompatible extensions all extensions are required to be understood and there is no substitution mechanism.
Q4: Can the designer extend(version) the language in a compatible way?
A substitution mechanism for the designer痴 extensions is required for forwards compatibility.
A question that does not need to be asked is: can the designer extend the language in a mandatory way. They can always do this by using new namespace names, element names or version numbers.
Q5: Is the vocabulary a stand-alone language or an extension of another vocabulary? A part of this question is whether the language depends on another language?
This determines which, if any, facilities are provided for the language and what must be provided. An example is SOAP headers can use the soap:mustUnderstand attribute and processing model.
Q6: In the case of an extension or version, should instance of the new language be(?) compatible with the old instances?
The ability to write a schema for extensions or versions is directly affected by the schema design and the compatibility desires.
Decisions
Upon answering these questions, there are some key decisions that a language developer makes, whether they consciously make them or not.
D1: schema language design or constraints.
If the language can be extended in a compatible way, then a few specific schema design choices must be followed.
For XML Schema, a wildcard is used to provide extensibility. To provide a Schema V2 that supports substitution, then schema extension or delimiter elements must be used in conjunction with the wildcard. The main choices are: whether to provide wildcards or not, and whether to provide Extension elements or delimiter elements. If Extension/delimiter elements are not provided, then a compatible V2 Schema cannot be written.
D2: Provide substitution mechanism for V2 instances to V1 without knowledge of V2.
I致e regularly advocated the 溺ust Ignore unknown� rule as a simple substitution mechanism, but others exist. XSLT fallback is a good example of another technique.
D3: namespace management of the language: 1) multiple namespaces for the each version of the language; 2) a single namespace for each compatible version; 3) a single namespace for all versions and a version identifier.
D4: Type of mandatory extension capabilities.
A must Understand flag is a simple model.
Let痴 look at a few different scenarios to illustrate these choices.
Scenarios
1. Name with no wildcard.
A Name vocabulary, consisting of first and last names. Third parties cannot extend this type. The Name author can extend the type in a backwards compatible way by adding in optional elements. There is no forwards compatible way for the Name author to make changes.
2. Name with Wildcard with ##other.
Option #1 plus the Name type has a wildcard for ##other namespaces in the schema. Neither the namespace author or any 3rd party can add an extension in a new namespace and be sure that a client will not break as the software can justifiably break or not. Given the lack of compatibility, it does no good to update the schema.
3. Wildcard with ##other and Must Ignore.
Option #2 plus the Must Ignore rule. Any party can add an extension in a new namespace and retain forwards and backwards compatibility. The namespace owner can add optional elements in the target namespace and retain backwards compatibility. Third parties cannot indicate their extensions are mandatory. An optional element cannot be added near the wildcard for V2, so the choice is either to create a non-extensible V2 Schema or have only a V1 Schema.
4. Extension Elements or Delimiter elements with Must Ignore.
Any party can add an extension in same or new namespace and retain forwards and backwards compatibility. Third parties cannot indicate their extensions are mandatory. A V2 schema can be written that validates V1 and V2 instances.
6. Extension Elements or Delimiter elements with Must Ignore and mustUnderstand flag.
Option #4 + mU flag. Any party can add an extension in same or new namespace and retain forwards and backwards compatibility. Third parties can indicate their extensions are mandatory. A V2 schema can be written that validates V1 and V2 instances.
5. Wildcard with ##other, Must Ignore, and mustUnderstand flag.
Option #3 + mU flag. Any party can add an extension in new namespace and retain forwards and backwards compatibility. Third parties can indicate their extensions are mandatory. A V2 schema cannot be written that validates V1 and V2 instances. An example of this is WSDL 2.0.
6. Wildcard with ##other and Must Ignore in a SOAP envelope
Option #3 + inside SOAP envelope. Because the Name is in a SOAP envelope, a 3rd party could indicate that it痴 extension is mandatory by making a new SOAP header of it痴 extension and marking with soap:mustUnderstand=杯rue�. A V2 schema cannot be written for controlling the location of the extension.
This shows the questions that language designers should think about, the decisions they have available to them and some sample scenarios.