[SUBTITLE]Draft - 29 March 2005
[SUBTITLE]W3C XML Schema Working Group
[VERSION]This version: http://www.w3.org/XML/2005/xsd-versioning-use-cases/xsdvuc-2005-03-29.html
[VERSION]Latest version: http://www.w3.org/XML/2005/xsd-versioning-use-cases/
[VERSION]Previous version: http://www.w3.org/XML/2005/xsd-versioning-use-cases/xsd-versioning-use-cases-2005-03-17.html
[VERSION]Editor:
[EDITORS]Hoylen Sue, DSTC Pty Ltd <h.sue@dstc.edu.au>
[COPYRIGHT]Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document describes use cases where XML Schemas are being versioned. These are situations where there are more than one XML Schemas and instances corresponding to them, and those schemas are based on each other. The use cases describe the different types of versioning behaviour that users want from XML Schema processors.
This document has been produced by the W3C XML Schema Working Group, to serve as input to the Working Group's work on the versioning of XML Schemas. It illustrates the types of versioning problems that could be solved by versioning mechanisms in XML Schema. However, note that the presences of a use case does not necessarily imply that XML Schema will be able to solve that particular versioning problem.
This is a draft discussion document. Some of the use cases have been extensively discussed in the Working Group. However, the current set of use cases and text describing them have not been endorsed by the Working Group. The current document is in draft form, and is subject to change.
These use cases are based on real examples submitted by users of XML Schema.
The XML Schema Working Group would welcome additional uses cases which illustrate aspects of versioning which have not been captured by the existing use cases.
The ability to create different versions of XML Schemas is important. In some applications, schemas need to change over time and be adapted to meet new requirements. However, it is often not practical to instantaneously replace all the deployments of the old schemas with the new ones. Applications will need to cope with instances corresponding to the different versions of schemas. Versioning mechanisms will allow those new versions to be created, and the processors to handle instances from the different versions.
This document describes desirable behaviour in use cases that involve XML Schema versioning. The use case approach aims to describes external interactions on the system (in this case, the system is the XML Schema processor). They deliberately do not describe any implementation-specific mechanisms. Possible versioning mechanismes are discussed in "Framework for discussion of versioning" <http://www.w3.org/XML/2004/02/xsdv.html>.
This document focuses on the versioning of XML Schemas. In particular, on the behaviour of XML schema processors, which performs schema validation and exposes information via the Post-Schema Validation Infoset (PSVI). Schema versioning is also important to other types of systems, such as for the application and for code generators using XML Schemas. However, those other aspects of versioning are outside the scope of this document.
For more general information on versioning, the W3C Technical Architecture Group (TAG) is producing a TAG Finding on versioning on the Web.
Discussions on versioning is conducted on the <public-xml-versioning@w3.org> mailing list. Please send your comments on this document to that mailing list.
Several different axes have been identified to classify the different types of use cases. These axes are:
This axis indicates which schemas are available to the processor. Schemas will be identified by a letter, for example "B". The notation "V(B)" will be used to describe a schema called V that is a version of schema B.
If a schema is based on more than one schema, the base schemas are all listed. For example, "V(B,C,D)" denotes a schema called V that is a version of schemas B, C, and D.
A version of a schema may be versioned again. The notation "W(V(B))" indicates a schema called W which is a version of V, and V is a version of B.
It is important to remember that versioning can occur multiple times. The notation "D(...(B)...)" is use to be denote a schema D that is ultimately a version of B. However, there may be several versions between them.
The availability of schemas will depend on the schema processor and application. Sometimes processors can be easily updated with the new schemas. Schemas could be manually installed into the application, or the processor could automatically fetch them when they are needed. At other times, processors might not be configurable with the new schemas. They may be embedded devices that cannot easily be changed, or they might be disconnected from a network and can't automatically fetch any new schemas. Fetching external schemas might also be disallowed due to performance or security reasons.
This axis indicates what kind of instance is being processed. That is, which version of schema the instance correspond to. The same notation as for schemas will be used to denote the different versions of instances.
A schema processor needs to handle instances of different versions. It may accept, partially accept, or reject the instance. The behaviour of schema processors is the subject of these use cases.
This asis describes what action is being performed by the XML Schema processor.
The most common action is schema validation, where an instance document is validated against a XML Schema. This produces a result indicating if the document is valid, and a Post Schema Validation Infoset (PSVI). This is what current schema processors do.
A new operation in versioning is the comparison of two schemas to see if they are versions of each other.
[TODO]To be completed. Is this really an axis?
[TODO]Investigate if behaviour or fallback is another valid axis. Possibilities are: Must fail if you encounter unexpected things; Must ignore any unexpected things you come across; Trigger special action; Fallback based on schema; Fallback based on data in the instance. Fallback behaviour might be another use case.
The term "backward compatiable" will mean an instance of an old schema can be processed by a processor that handles the new schema. Processing does not necessarily mean in the same way as an old schema processor would.
The term "forward compatiable" will mean an instance of the new schema can be processed by a processor that handles the old schema. Processing does not necessarily mean in the same way as a new schema processor would.
In this use case, schemas are written to match the expectations of the programs which process the instances. These programs operate in a "ignore what you didn't expect" mode.
Consider a convenience store, with a point-of-sale (POS) cash register that receives transaction data from various devices in the store. There are many different types of devices and they are produced by different vendors.
Due to market forces and competition between the vendors, there is no single standard data schema that they all use. Each vendor enhances their own schemas to be more competative within their own line of products. However, this produces problems for customers who use products from multiple vendors. Their schemas are similar to each other, because they borrow features from each other. However, there is no well defined versioning lineage.
One vendor produces a bar code reader. It consists of a bar code reader that identifies an item, looks up the pricing information, and sends this to a cash register. It generates messages corresponding to this datatype (which we'll call schema B):
<xs:complexType name="bar_code_transaction">
<xs:sequence>
<xs:element name="code" type="xsd:string"/>
<xs:element name="description" type="xsd:string"/>
<xs:element name="price" type="xsd:decimal"/>
</xs:sequence>
</xs:complexType>
An example instance is:
<transaction> <code>1861003129</code> <description>Orange juice</description> <price>3.95</price> </transaction>
Another vendor produces fuel pumps. These contain additional information relevant to the management of fuel pumps. This vendor may have based their fuel pump schema on the bar code reader schema, or they might not have -- due to the unregulated marketplace, the relationships between the schemas is unclear. The fuel pumps transmit transactions containing entries according to this XML Schema datatype (which we'll call schema F):
<xs:complexType name="fuel_pump_transaction">
<xs:sequence>
<xs:element name="description" type="xsd:string"/>
<xs:element name="unitprice" type="xsd:decimal"/>
<xs:element name="litres" type="xsd:decimal"/>
<xs:element name="price" type="xsd:decimal"/>
</xs:sequence>
</xs:complexType>
An example instance is:
<transaction> <description>Diesel</description> <unitprice>0.899</unitprice> <litres>42.1</litres> <price>37.85</price> </transaction>
Elements designed to hold extension data do not work in this environment. Firstly, because it is not a scalable solution when there are many versions of versions. Secondly, because vendors see their data as important, and would not want to make them appear inferior to the other data by placing them in a separate extension section.
A third vendor produces cash registers. The cash registers process the transactions by displaying them to the operator.
Since the cash register must interoperate with many different forms of messages, it has been written to be flexible in what it expects. Specifically, it has been written with the assumption that it will ignore any extra elements that it didn't expect. This way, future versions can add elements without breaking the application.
The devices must interoperate, and XML Schemas should help make that possible. Some of these devices may be embedded devices that are difficult to update and contain limited processing power. The more powerful devices might validate messages when they are received. The more limited devices might not perform any validation, however, it will reject bad messages. If there is problem (accusations that the fuel pump created a bad message, or the cash register rejected a good message) the XML Schema could be brought out to settle the dispute. In either case, the XML Schema needs to be able to represent the input that the application expects.
The application could be written in many different ways. For example, as a program using a DOM API. Alternatively, the following fragment of an XSLT script can be used to represent the behaviour. The important aspect of this example is that it works on any document as long as there is a description and price (in any order) in the transaction -- it deliberately ignores extra elements that it does not use.
<xsl:template match="transaction">
<tr>
<td><xsl:value-of select="description"/></td>
<td><xsl:value-of select="price"/></td>
</tr>
</xsl:template>
The challenge here is to represent this using XML Schema. We shall call this the cash register schema R. Unfortunately, this schema cannot be fully represented using XML Schema 1.0. The following schema datatype is too restrictive -- it will reject many documents which the program would otherwise accept. It does not capture the "ignore what you don't expect" behaviour of the program.
<xs:complexType name="cash_register_transaction">
<xs:sequence>
<xs:element name="description" type="xsd:string"/>
<xs:element name="price" type="xsd:decimal"/>
</xs:sequence>
</xs:complexType>
A fourth vendor produces fuel volume management systems. These report the volume of fuel sold. It is designed to accept transactions from the fuel pumps. The function of the volume management system can be illustrated by the following fragment of XSLT. Note that it makes use of the "litres" element from the fuel pump transaction.
<xsl:template match="transaction">
<tr>
<td><xsl:value-of select="description"/></td>
<td><xsl:value-of select="litres"/></td>
</tr>
</xsl:template>
The XML Schema for the volume management system will be called schema V.
[AXIS]Instance processed: B [Bar code]
[AXIS]Schema Availability: R [Cash register]
[AXIS]Operation performed: Schema validation
Brief summary: The output from the bar code reader is sent to the cash register, and the extra data in it is ignored.
Basic course of events:
The outcome:
[AXIS]Instance processed: F [Fuel pump]
[AXIS]Schema Availability: R [Cash register]
[AXIS]Operation performed: Schema validation
Brief summary: The output from the fuel pump is sent to the cash register, and the extra data in it is ignored.
Basic course of events:
The outcome:
This scenario is similar to Scenario 1, except that the bar code reader has been replaced by the fuel pump.
[AXIS]Instance processed: B [Bar code]
[AXIS]Schema Availability: V [Volume management]
[AXIS]Operation performed: Schema validation
Brief summary: The output from the bar code reader is sent (in error) to the fuel volume management system.
Basic course of events:
The outcome:
[AXIS]Instance processed: F [Fuel pump]
[AXIS]Schema Availability: V [Volume management]
[AXIS]Operation performed: Schema validation
Brief summary: The output from the fuel pump is sent to the fuel volume management system.
Basic course of events:
The outcome:
This use case is about providing mechanisms in XML Schema so that it can more closely represent the class of documents accepted by processing programs. A certain class of programs are designed to be forward-compatiable with new versions of the document. They do this by deliberately ignoring extra nodes that they don't understand. This approach to versioning allows newer versions to add nodes without breaking older applications.
However, the current mechanisms in XML Schema cannot fully represent that flexibility. The schema ends up being too constraining: although the program will work properly with a new version of the instance, the schema validator rejects it.
In this use case, schemas are compared to see if they are versions of each other.
This use case uses the situation of a convenience store with a cash register, bar code reader and fuel pump. This situation was described in the previous use case.
[AXIS]Instance processed: none
[AXIS]Schema Availability: R and B [Cash register and Bar code]
[AXIS]Operation performed: comparison
Brief summary: A systems integrator wants to check if the data produced by the bar code reader is suitable for the cash register to use.
Basic course of events:
The outcome:
Although both schemas might have been developed independently, it is possible to consider the bar code reader as a compatiable version of the cash register schema. This operation allows that to be determined.
[AXIS]Instance processed: none
[AXIS]Schema Availability: R and F [Cash register and fuel pump]
[AXIS]Operation performed: comparison
Brief summary: A systems integrator wants to check if the data produced by the fuel pump is suitable for the cash register to use.
Basic course of events:
The outcome:
[AXIS]Instance processed: none
[AXIS]Schema Availability: V and B [Volume manager and bar code]
[AXIS]Operation performed: comparison
Brief summary: A systems integrator wants to check if the data produced by the bar code reader is suitable for the volume manager to use.
Basic course of events:
The outcome:
[AXIS]Instance processed: none
[AXIS]Schema Availability: V and F [Volume manager and fuel pump]
[AXIS]Operation performed: comparison
Brief summary: A systems integrator wants to check if the data produced by the fuel pump is suitable for the volume manager to use.
Basic course of events:
The outcome:
Comparison of schemas is a new type of operation. This use case has illustrated testing if the set of documents described by one schema is a subset of the set described by a different schema. Other possible operations could be to determine if that relationship is a proper subset, or equality.
Another example is XHTML. In XHTML 1.0, the strict, transitional, and frameset document types all use the same XML namespace. However, the schemas for them are slightly different. Also, variants of XHTML 1.0 such as XHTML Basic also share the same namespace, even though the schemas for them are different. Thus, an application that processes one variant of XHTML needs to know whether it can accept instances of another variant.
In this use case, a schema is versioned many times. Some of those versions are significant changes and some are insignificant. The versioning mechanism needs a way to distinguish between the two.
In the application world, the concept of major and minor versions is commonly used. This convention is used to convey information about interoperability: minor versions are guaranteed to be compatiable, major versions do not have such guarantees.
What constitutes an incompatiable change is application dependent. Hence, this distinction cannot be automatically determined by examining the schemas.
For example, consider a schema for a book store's inventory system. This will be known as schema B.
<xsd:complexType name="booktype">
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element type="xsd:any"/>
</xsd:sequence>
</xsd:complexType>
An example instance of B is:
<book> <title>Fun with XML Schemas</title> <author>A. Smith</author> <price>39.95</price> </book>
A minor version of the schema is created, schema V(B). The only change is the addition of an optional editor element.
<xsd:complexType name="booktype">
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element name="editor" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
An example instance of V(B) is:
<book> <title>Fun with XML Schemas</title> <author>A. Smith</author> <price>39.95</price> <editor>B. Jones</editor> </book>
A major version of the schema is created, schema W(B). The only change is the addition of an optional discount element. For the application, the "price" must be interpreted along with the "discount", so this is an incompatiable change.
<xsd:complexType name="booktype">
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element name="discount" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
An example instance of W(B) is:
<book> <title>Fun with XML Schemas</title> <author>A. Smith</author> <price>39.95</price> <discount>0.90</discount> </book>
[AXIS]Instance processed: V(B) [Minor version]
[AXIS]Schema Availability: B [Base]
[AXIS]Operation performed: Schema validation
Brief summary: The inventory system processes an instance that has a minor version change.
Basic course of events:
The outcome:
[AXIS]Instance processed: W(B) [Major version]
[AXIS]Schema Availability: B [Base]
[AXIS]Operation performed: Schema validation
Brief summary: The inventory system processes an instance that has a major version change.
Basic course of events:
The outcome:
[AXIS]Instance processed: V(B) [Minor version]
[AXIS]Schema Availability: B and V(B) [Base and Minor]
[AXIS]Operation performed: Schema validation
Brief summary: The inventory system processes an instance that has a minor version change.
Basic course of events:
The outcome:
[AXIS]Instance processed: W(B) [Major version]
[AXIS]Schema Availability: B and W(B) [Base]
[AXIS]Operation performed: Schema validation
Brief summary: The inventory system processes an instance that has a major version change.
Basic course of events:
The outcome:
This use case extends to multiple levels of versioning (both major and minor) even though just one level is shown here.
In this use case, XML document versioning mimics the inheritance and polymorphic behaviour of object oriented classes.
In object oriented programming languages, the concept inheritance can be used to create a new class based on an existing class. This establishes an "is-a" version relationship. Polymorphism is one of the key features of object oriented programming: where a subclass (derived class) can be used in the place of a superclass (base class).
Programmers may want to develop systems where the programming classes are serialized into XML. Hence, methods (implemented as services) need to behave the same way with regards to the serialized subclasses.
For example, consider a class that defines a Person. The XML Schema for the serialized class will be known as schema P.
class Person {
string name;
date dob; /* date of birth */
};
An example of a serialized person object is:
<person> <name>John Smith</name> <dob>1938-11-01</dob> </person>
An employee class is defined as inheriting from a person, and adding an extra "employee_ID" member variable. The XML Schema for the serialized employee will be known as E(P) -- since it is a version of the person schema.
class Employee: public Person {
int employee_number;
};
An example of a serialized employee object is:
<person> <name>John Smith</name> <dob>1938-11-01</dob> <employee_number>69105</employee_number> </person>
A manager is defined as inheriting from an employee, and adding an extra "department" member variable. The XML Schema for the serialized manager will be known as M(E(P)) or M(E) or simply M.
class Manager: public Employee {
string department;
};
An example of a serialized manager object is:
<person> <name>John Smith</name> <dob>1938-11-01</dob> <employee_number>69105</employee_number> <department>Research and Development</department> </person>
Now consider a service that expects person objects, such as a customer database, which can accept any person, employees and managers.
class Customer_Database {
public:
void register(Person p);
...
};
There is also a payroll service which accepts employees (including managers), but not persons who are not employees.
class Payroll {
public:
void pay_wages(Employee e);
...
};
[AXIS]Instance processed: E(P) [Employee]
[AXIS]Schema Availability: P [Person]
[AXIS]Operation performed: Schema validation
Brief summary: The customer database receives an employee as a customer. Although it does not know about employees, it does accept the employee because an employee is a version of a person. The schema processor is forward compatiable.
Basic course of events:
The outcome:
[AXIS]Instance processed: M(E(P)) [Manager]
[AXIS]Schema Availability: P [Person]
[AXIS]Operation performed: Schema validation
Brief summary: The customer database receives a manager as a customer. Although it does not know about managers, it does accept the manager because it is a version of a person. The schema processor is forward compatiable.
Basic course of events:
The outcome:
[AXIS]Instance processed: M(E(P)) [Manager]
[AXIS]Schema Availability: P and E(P) [Person and Employee]
[AXIS]Operation performed: Schema validation
Brief summary: The payroll service receives a manager object. Although it does not know about managers, it does accept the manager because a manager is a version of an employee. The schema processor is forward compatiable.
Basic course of events:
The outcome:
Currently, XML Schema 1.0 can solve this use case if all the schemas are available to the processor. However, it cannot solve the case (as described here) where the newer versions of the schema are not available.
In this use case, schemas are specialized with more specific versions, and processing software needs to operate in the presence or absence of those specialized schemas. A distinguishing characteristic of this use case is that instances of the specialized schemas are always valid instances of the base schema.
There is a generic base schema which has been approved by a country's health department. To ensure interoperability, the country's government has mandated that all compliant software must be able to store and process data that corresponds to this generic base schema. This generic base schema has been designed to store medical data, but in a very non-specific way so that it is flexible enough to handle a wide variety of data. This is necessary because medical data changes often due to new technology and practices, as well as being very diverse.
For example, the generic base schema could contain a generic datatype for storing two measurement values. We shall call this generic base schema: schema B.
<xsd:complexType name="measurement2">
<xsd:sequence>
<xsd:element name="value1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="value2">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
An example instance of an element from schema B is:
<data>
<value1>
<magnitude>1660</magnitude>
<unit>mm</unit>
</value1>
<value2>
<magnitude>72</magnitude>
<unit>kg</unit>
</value2>
</data>
There are two products that use the generic schema: a General Practice (GP) management system, and a hospital clinical information management system. Clinical record information is exchanged between the two programs using messages containing XML. When the programs receive data, they validate it before storing or process them.
The country's General Practice doctor organization decides that it wants to standardize how blood pressures are recorded. They define it as a specialization (or constraint) of the generic base schema's measurement datatype. The versioning mechanism (whatever that may be) is used indicate that this is a version of the generic measurement datatype.
Here is an example from the specialized blood pressure schema, which we will call schema V(B). It constraints the units of both measurments to be mmHg.
<xsd:complexType name="blood_pressure">
<xsd:sequence>
<xsd:element name="value1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="value2">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
An example instance of a blood pressure specialization V(B) is:
<data>
<value1>
<magnitude>142</magnitude>
<unit>mmHg</unit>
</value1>
<value2>
<magnitude>80</magnitude>
<unit>mmHg</unit>
</value2>
</data>
The General Practice software is modified or updated to have the blood pressure schema, but the hospital software is not. There can be many reasons why the hospital software does not have the blood pressure schema, such as: the timing cycle of software upgrades, it may be running in an off-line mode where schemas cannot be fetched, cost, performance, security or policy.
Later on, a physiotherapy clinic decides that it wants to further refine the definition of a blood pressure to only contain sensible values for the systolic and diastolic readings. The versioning mechanism would indicate that this refined blood pressure datatype is a version of the ordinary blood pressure datatype.
This is an excerpt from the refined physiotherapy schema W(V(B)). It shows that the numeric values in the measurement are restricted to certain ranges.
<xsd:complexType name="blood_pressure_refined">
<xsd:sequence>
<xsd:element name="value1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="90"/>
<xsd:maxInclusive value="140"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="value2">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="60"/>
<xsd:maxInclusive value="90"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
[AXIS]Instance processed: B [Hospital]
[AXIS]Schema Availability: B and V(B) [Hospital and GP]
[AXIS]Operation performed: Schema validation
Brief summary: The hospital system sends a message to the GP system. An instance of the base schema will be processed according to the base schema. Even though the processor has access to the specialized schema, it is not used. The schema processor is backward compatiable.
Basic course of events:
The outcome:
Since the GP system is receiving a base instance, it cannot (and should not) use the specialization schema.
[AXIS]Instance processed: V(B) [GP]
[AXIS]Schema Availability: B and V(B) [Hospital and GP]
[AXIS]Operation performed: Schema validation
Brief summary: One GP system sends a message to another GP system. An instance of the specialized schema will be processed according to the specialized schema. Even though the processor could have validated it using the base schema, it must use the specialized schema.
Basic course of events:
The outcome:
The receiving GP system needs to treat the instance as a blood pressure, because it wants to process it in a special way (e.g. graph it or apply decision support on it). Although it could also validate it using the generic base schema, it does not do so because the extra constraints in the blood pressure schema are important for the application to correctly interpret the data as a blood pressure.
[AXIS]Instance processed: B [Hospital]
[AXIS]Schema Availability: B [Hospital]
[AXIS]Operation performed: Schema validation
Brief summary: One hospital system sends a message to another hospital. An instance of the base schema is processed according to the base schema.
Basic course of events:
The outcome:
This use case does not invoke any special versioning feature, but it is included here for completeness.
[AXIS]Instance processed: V(B) [GP]
[AXIS]Schema Availability: B [Hospital]
[AXIS]Operation performed: Schema validation
Brief summary: A GP system sends a message to a hospital system. An instance of the specialized schema is processed using the base schema when the processor does not have access to the specialized schema. The schema processor is forward compatiable.
Basic course of events:
The outcome:
The hospital system cannot recognise the data as a blood pressure, but can process it generically. There might be a generic base schema database for storing them, or a generic viewer that can display the values.
[AXIS]Instance processed: W(...(B)...) [Physiotherapy]
[AXIS]Schema Availability: B [Hospital]
[AXIS]Operation performed: Schema validation
Brief summary: A physiotherapy system sends a message to a hospital system. An instance of the refined physiotherapy schema is processed using the base schema (when the processor does not have access to the refined physiotherapy schema nor access to the specialized GP schema). The schema processor is forward compatiable across multiple versions.
Basic course of events:
The outcome:
This scenario shows that the versioning must work across multiple generations of versions, not just between two successive versions.
The inclusion of the physiotherapy in this use case is to highlight the point that the versioning mechanism must work when there are multiple versions involved. A solution that provides for only a single level of versioning is useless in the real world.
In this use case, schemas are specialized with more specific versions and information items are renamed in those versions. The processing software needs to operate in the presence or absence of those specialized schemas. Note: this use case is similar to the "Specialization without renaming" use case, except that items are renamed.
There is a generic base schema which has been approved by a country's health department. To ensure interoperability, the country's government has mandated that all compliant software must be able to store and process data that corresponds to this generic base schema. This generic base schema has been designed to store medical data, but in a very non-specific way so that it is flexible enough to handle a wide variety of data. This is necessary because medical data changes often due to new technology and practices, as well as being very diverse.
For example, the generic base schema could contain a generic datatype for storing two measurement values. We shall call this generic base schema: schema B.
<xsd:complexType name="measurement2">
<xsd:sequence>
<xsd:element name="value1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="value2">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
An example instance of an element from schema B is:
<data>
<value1>
<magnitude>1660</magnitude>
<unit>mm</unit>
</value1>
<value2>
<magnitude>72</magnitude>
<unit>kg</unit>
</value2>
</data>
There are two products that use the generic schema: a General Practice (GP) management system, and a hospital clinical information management system. Clinical record information is exchanged between the two programs using messages containing XML. When the programs receive data, they validate it before storing or process them.
The country's General Practice doctor organization decides that it wants to standardize how blood pressures are recorded. They define it as a specialization (or constraint) of the generic base schema's measurement datatype. The versioning mechanism (whatever that may be) is used indicate that this is a version of the generic measurement datatype.
Here is an example from the specialized blood pressure schema, which we will call schema V(B). It constraints the units of both measurments to be mmHg.
<xsd:complexType name="blood_pressure">
<xsd:sequence>
<xsd:element name="systolic">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="diastolic">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude" type="xsd:decimal"/>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
An example instance of a blood pressure specialization V(B) is:
<blood_pressure>
<systolic>
<magnitude>142</magnitude>
<unit>mmHg</unit>
</systolic>
<diastolic>
<magnitude>80</magnitude>
<unit>mmHg</unit>
</diastolic>
</blood_pressure>
The General Practice software is modified or updated to have the blood pressure schema, but the hospital software is not. There can be many reasons why the hospital software does not have the blood pressure schema, such as: the timing cycle of software upgrades, it may be running in an off-line mode where schemas cannot be fetched, cost, performance, security or policy.
Later on, a physiotherapy clinic decides that it wants to further refine the definition of a blood pressure to only contain sensible values for the systolic and diastolic readings. The versioning mechanism would indicate that this refined blood pressure datatype is a version of the ordinary blood pressure datatype.
This is an excerpt from the refined physiotherapy schema W(V(B)). It shows that the numeric values in the measurement are restricted to certain ranges.
<xsd:complexType name="blood_pressure_refined">
<xsd:sequence>
<xsd:element name="systolic">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="90"/>
<xsd:maxInclusive value="140"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="diastolic">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="magnitude">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="60"/>
<xsd:maxInclusive value="90"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mmHg"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
[AXIS]Instance processed: B [Hospital]
[AXIS]Schema Availability: B and V(B) [Hospital and GP]
[AXIS]Operation performed: Schema validation
Brief summary: The hospital system sends a message to the GP system. An instance of the base schema will be processed according to the base schema. Even though the processor has access to the specialized schema, it is not used. The schema processor is backward compatiable.
Basic course of events:
The outcome:
Since the GP system is receiving a base instance, it cannot (and should not) use the specialization schema.
[AXIS]Instance processed: V(B) [GP]
[AXIS]Schema Availability: B and V(B) [Hospital and GP]
[AXIS]Operation performed: Schema validation
Brief summary: One GP system sends a message to another GP system. An instance of the specialized schema will be processed according to the specialized schema. Even though the processor could have validated it using the base schema, it must use the specialized schema.
Basic course of events:
The outcome:
The receiving GP system needs to treat the instance as a blood pressure, because it wants to process it in a special way (e.g. graph it or apply decision support on it). Although it could also validate it using the generic base schema, it does not do so because the extra constraints in the blood pressure schema are important for the application to correctly interpret the data as a blood pressure.
[AXIS]Instance processed: B [Hospital]
[AXIS]Schema Availability: B [Hospital]
[AXIS]Operation performed: Schema validation
Brief summary: One hospital system sends a message to another hospital. An instance of the base schema is processed according to the base schema.
Basic course of events:
The outcome:
This use case does not invoke any special versioning feature, but it is included here for completeness.
[AXIS]Instance processed: V(B) [GP]
[AXIS]Schema Availability: B [Hospital]
[AXIS]Operation performed: Schema validation
Brief summary: A GP system sends a message to a hospital system. An instance of the specialized schema is processed using the base schema when the processor does not have access to the specialized schema. The schema processor is forward compatiable.
Basic course of events:
The outcome:
The hospital system cannot recognise the data as a blood pressure, but can process it generically. There might be a generic base schema database for storing them, or a generic viewer that can display the values.
[AXIS]Instance processed: W(...(B)...) [Physiotherapy]
[AXIS]Schema Availability: B [Hospital]
[AXIS]Operation performed: Schema validation
Brief summary: A physiotherapy system sends a message to a hospital system. An instance of the refined physiotherapy schema is processed using the base schema (when the processor does not have access to the refined physiotherapy schema nor access to the specialized GP schema). The schema processor is forward compatiable across multiple versions.
Basic course of events:
The outcome:
This scenario shows that the versioning must work across multiple generations of versions, not just between two successive versions.
This use case originated from discussions about the "specialization" use case. Although the "specialization" use case has its basis in a real world example, this one does not. However, it is an interesting use case worth considering.
[TODO]This section is incomplete: it only has example instances, and we need to show the example schemas corresponding to them.
In this use case, a schema is customized for local needs, but the local version must not break validation with the original schema.
This use case is different from the "health care / specialization" use case because the customizations are extensions of the base schema. Without any versioning mechanisms, instances of the customized schemas would not normally be valid instances of the base schema.
This use case involves a Big-store which has a head office and branches. One of the suppliers to Big-store is Video-supplier, which has a head office and warehouses.
A base schema is defined by a Big-store for invoices. We shall call this schema B. Big-store requires all of its suppliers to provide invoices using it.
An example instance of an item in the Big-store invoice is:
<item> <part>1138</part> <description>Generic widget</description> <quantity>12</part> </item>
When the Big-store created this schema, it did not know how others may want to extend it, and they had no plans nor expectations on the reuse of the schema. This means they did not deliberately spend time putting in hooks for versioning. However, that does not preclude others from using any versioning mechanisms if they were avalabile by default.
Video-supplier decides to reimplement their stock tracking system to be natively based on the Big-store invoice schema. They want to avoid the need to translate between the schemas they use internally and those that it sends to external customers.
However, Video-supplier needs to store additional information in their internal invoices. To do this, they create a customized schema that is a version of the Big-store invoice schema.
In this example, they want to indicate which warehouse the items were shipped from. Here, they have added their customizations to the same namespace as the Big-store invoice. We shall call this schema V(B).
This is an example instance of the Video-supplier item:
<item>
<part>1138</part>
<description>Generic widget</description>
<quantity>12</part>
<source>
<warehouse>W1</warehouse>
</source>
</item>
An item is used in a number of different places in an invoice (e.g. items delivered, items backordered).
Invoices are sent from Video-supplier warehouses to the Video-supplier head office (which expects to see the customized information items). They are also sent from the Video-supplier head office to the Big-store head office. Invoices are also sent from the Big-store head office to their Big-store branches.
The versioning mechanism must accomplish two things: make it easy to write the extensions, and to not break processors expecting instances of the original schema.
Firstly, the versioning mechanism needs a simple way of indicating that wherever the Big-store invoice schema referred to a Big-store item, in the new Video-supplier schema a Video-supplier item must always be used instead. Redefining everything that refers to the Big-store item is not a good solution. The customised element could be used in many different places, leading to a maintenance problem. Redefining everything would effectively create a parallel copy of the schema, where the clear relationship with the original schema would have been lost. The clear relationship being that only the item has versioned, and nothing else.
Secondly, Video-supplier wants to send their customized invoices to the Big-store without translation (i.e. without needing to strip out the customized elements). Those new Video-supplier instances must work with old processors that expect Big-store instances, as shown in the scenarios below.
[AXIS]Instance processed: V(B) [Video-supplier]
[AXIS]Schema Availability: B [Big-store]
[AXIS]Operation performed: Schema validation
Brief summary: The Video-supplier head office sends an invoice to the Big-store head office. An instance of the customized schema is processed by the base schema (without access to the customized schema). The schema processor is forward compatiable.
Basic course of events:
The outcome:
Although the customized instance contains extra elements which are not a part of the base schema, they must not cause the processor or the application to fail. The instance must be valid according to the base schema, because the contract between the two companies was based on exchanging invoices valid according to the Big-store schema. The information returned by the PSVI must not cause the Big-store application to break.
[AXIS]Instance processed: V(B) [Video-supplier]
[AXIS]Schema Availability: B and V(B) [Big-store and Video-supplier]
[AXIS]Operation performed: Schema validation
Brief summary: A Video-supplier warehouse sends an invoice to the Video-supplier head office. An instance of the customized schema is processed by the customized schema.
Basic course of events:
The outcome:
[AXIS]Instance processed: B [Big-store]
[AXIS]Schema Availability: B [Big-store]
[AXIS]Operation performed: Schema validation
Brief summary: The Big-store head office sends an invoice to a Big-store branch. An instance of the base schema is processed by a procesor with the base schema.
Basic course of events:
The outcome:
[AXIS]Instance processed: B [Big-store]
[AXIS]Schema Availability: B and V(B) [Big-store and Video-supplier]
[AXIS]Operation performed: Schema validation
Brief summary: The Big-store (incorrectly) sends an invoice to the Video-supplier head office. An instance of the base schema is processed by a system that expects an instance of the customized schema.
Basic course of events:
The outcome:
The Video-supplier head office application expects that all invoices it receives are Cooltoy invoices, which contain the extra warehouse information. It must rejects the invoice because it does not have the warehouse information.
[TODO]Need more information on this one. This is a multi-headed substitution group type use case.
[TODO]This needs to be completed.
[TODO]Add text to use cases to discuss which ones are currently solvable by XML Schema 1.0.