[SUBTITLE]Draft -- 17 February 2005
[SUBTITLE]XML Schema Working Group
[VERSION]This version: http://www.w3.org/XML/2005/xsd-versioning-use-cases.html
[VERSION]Latest version: http://www.w3.org/XML/2005/xsd-versioning-use-cases/
[VERSION]Previous version: [none]
[VERSION]Editors:
[EDITORS]Hoylen Sue, DSTC Pty Ltd <h.sue@dstc.edu.au>
[COPYRIGHT]Copyright © 2005 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 desired behaviour of XML Schema processors.
The aim of this document is to provide a better understanding the versioning problem. It describes the different types of versioning that users want.
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.
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 further information on versioning, the W3C Technical Architecture Group (TAG) is investigating versioning on the Web.
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.
[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 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 local General Practice 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 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
[AXIS]Schema Availability: B and V(B)
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)
[AXIS]Schema Availability: B and V(B)
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
[AXIS]Schema Availability: B
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)
[AXIS]Schema Availability: B
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)...)
[AXIS]Schema Availability: B
Brief summary: A local GP system sends a message to a hospital system. An instance of the refined schema is processed using the base schema (when the processor does not have access to the refined schema nor access to the specialized 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.
[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 Mega-store which has a head office and branches. One of the suppliers to Mega-store is Cooltoys, which has a head office and warehouses.
A base schema is defined by a Mega-store for invoices. We shall call this schema B. Mega-store requires all of its suppliers to provide invoices using it.
An example instance of an item in the Mega-store invoice is:
<item> <part>1138</part> <description>Generic widget</description> <quantity>12</part> </item>
When the Mega-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.
Cooltoys decides to reimplement their stock tracking system to be natively based on the Mega-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, Cooltoys needs to store additional information in their internal invoices. To do this, they create a customized schema that is a version of the Mega-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 mega-store invoice. We shall call this schema V(B).
This is an example instance of the Cooltoys 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 Cooltoys warehouses to the Cooltoys head office (which expects to see the customized information items). They are also sent from the Cooltoys head office to the Mega-store head office. Invoices are also sent from the Mega-store head office to their Mega-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 Mega-store invoice schema referred to a Mega-store item, in the new Cooltoys schema a Cooltoys item must always be used instead. Redefining everything that refers to the Mega-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, Cooltoys wants to send their customized invoices to the Mega-store without translation (i.e. without needing to strip out the customized elements). Those new Cooltoys instances must work with old processors that expect Mega-store instances, as shown in the scenarios below.
[AXIS]Instance processed: V(B)
[AXIS]Schema Availability: B
Brief summary: The Cooltoys head office sends an invoice to the Mega-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 Mega-store schema. The information returned by the PSVI must not cause the Mega-store application to break.
[AXIS]Instance processed: V(B)
[AXIS]Schema Availability: B and V(B)
Brief summary: A Cooltoys warehouse sends an invoice to the Cooltoys head office. An instance of the customized schema is processed by the customized schema.
Basic course of events:
The outcome:
[AXIS]Instance processed: B
[AXIS]Schema Availability: B
Brief summary: The Mega-store head office sends an invoice to a Mega-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
[AXIS]Schema Availability: B and V(B)
Brief summary: The Mega-store (incorrectly) sends an invoice to the Cooltoys 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 Cooltoys 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]Do we also need an V(...(B)...) scenario too?
Consider a convenience store, with an electronic cash register, fuel pumps, car wash, and back-office accounting and management system.
The computer systems in the cash register, fuel pumps, car wash, and back-office system are built and sold by different vendors, but they must cooperate:
In order to provide for some interoperation among devices, vendor-neutral organizations create schemas which provide definitions for common document exchanges. Because the vendors compete for sales, it is to each vendor's advantage to add value by providing more useful information than the other vendor's product; this useful information most naturally takes the form of new child elements or attributes on elements defined in the common schema.
Because the devices must cooperate, dropped or garbled messages are a potential problem; if one device rejects a message sent by another device, the result is likely to be finger-pointing between the vendors about whose device is at fault: did the fuel pump emit a bad message, or did the cash register reject a perfectly legal data stream? In order to make such disputes relatively easy to resolve, it is extremely helpful to have a written description of the set of messages the devices are required to accept. An obvious choice is to have this description take the form of a schema document: that is, the accept set is defined as the set of documents valid against a particular schema. (Either full-validation (VF) or or partial-validation (VP) will do, although VP may involve some further stipulations about how full or partial the validation has to be.)
Any approach to versioning which involves accepting partially valid documents abandons the idea of using the schema as defining the contract between sender and recipient, and that leaves the vendors without a convenient way to adjudicate disputes over dropped data, greatly reducing the value of the schema or DTD.
For security or processing-footprint reasons, the convenience store devices do not load new schemas dynamically; schemas may be changed as part of an upgrade or as part of system maintenance, but the upgrades to each device are scheduled by their respective vendors, not always under the control of the convenience store operator. Vendors may be understandably loath to spend time and effort changing the schemas in their deployed devices just to support an upgrade made by a competitor to a different device. Therefore, in deploying a new version of a common schema (or a new set of value-added additions to it), a vendor cannot count on corresponding changes to the other devices. This requirement for coordination severely complicates the logistics of upgrading systems.
Basic Cash register schema:
For example, consider a basic cash register that processes sales transaction information. It might expect data according to this datatype (Schema-B):
<xsd:complexType name="basic-item">
<xsd:sequence>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element name="description" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
An example instance is (Instance-B):
<item> <price>12.90</price> <description>Unleaded fuel</description> </item>
Fuel pump schema:
A vendor that supplies the gas/petrol station market produces fuel pumps and special fuel cash registers. These exchange data using a version of the basic cash register schema. This version adds information that is relevant to managing a fuel sale (Schema-F1).
<xsd:complexType name="fuel-item">
<xsd:sequence>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="pump-id" type="xsd:integer"/>
<xsd:element name="litres" type="xsd:decimal"/>
</xsd:sequence>
</xsd:complexType>
An example instance (Instance-F1):
<item> <price>12.90</price> <description>Unleaded fuel</description> <pump-id>1</pump-id> <litres>42.1</litres> </item>
[Instance-F1 validated by Schema-F1]
The fuel cash register is, obviously, designed to use the extra information provided by the gas pump. It must validate a fuel sale message against the fuel sale schema. However, some installations may have a mixture of different types of devices and cash registers.
[Instance-F1 partially validated by Schema-B]
If a fuel pump sends a fuel sale message to a basic cash register, the basic cash register may want to validate the fuel cash register document against the basic cash register schema, since the basic cash register is unaware of the fuel pump version of the schema.
[Instance-B partially validated by Schema-F1]
If a device sends a basic cash register message to a fuel cash register, then the fuel cash register needs to validate the document, even if that document conforms to the basic (not fuel) cash register schema.
Car wash schema:
A different vendor manufactures car wash machines which exchange a car wash item message, which is another version of the basic cash register item message. This car wash schema (Schema-CW) contains:
<xsd:complexType name="car-wash-item">
<xsd:sequence>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="clean-level" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
An instance document looks like this (Instance-CW):
<item> <price>10.95</price> <description>Standard car wash</description> <clean-level>1</clean-level> </item>
Similar to the situation with the fuel pump manufacturer, the vendor also produces car wash cash registers that can accept these enhanced car wash versions of the sales message.
However, the versioning mechanism now also needs to handle additional versioning situations.
[Instance-CW validated against Schema-F1]
If a car wash machine sends a car wash item message to a fuel cash register, the latter needs to (partially) validate it against the basic cash register schema.
[Instance-F1 validated against Schema-CW]
???
Enhanced fuel cash register
The fuel pump vendor produces a new type of fuel pump, which sends enhanced fuel sale messages. The schema (Schema-F2) is an enhanced version of the fuel item schema.
<xsd:complexType name="enhanced-fuel-item">
<xsd:sequence>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="pump-id" type="xsd:integer"/>
<xsd:element name="litres" type="xsd:decimal"/>
<xsd:element name="pay-at-pump" type="xsd:boolean"/>
<xsd:element name="credit-card-number" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
An instance is (Instance-F2):
<item> <price>12.90</price> <description>Unleaded fuel</description> <pump-id>1</pump-id> <litres>42.1</litres> <pay-at-pump>true</pay-at-pump> <credit-card-number>5313 1234 1234 1234</credit-card-number> </item>
[Instance-F2 validated against Schema-B]
If a basic cash register receives an enhanced fuel sale message... ???
[Instance-F2 validated against Schema-F1]
If the original fuel cash register recieves an enhanced fuel sale message... ???
[Instance-F2 validated against Schema-CW]
If a car wash cash register receives an enhanced fuel sale message... ???
[Instance-F1 validated against Schema-F2]
???
[Instance-B validated against Schema-F2]
???
[Instance-CW validated against Schema-F2]
???
A back-office system may need to connect to POS systems from a variety of vendors. Each of the POS systems generates an XML file where each element represents a separate transaction performed at that workstation, and the back-office system has reporting and shredding systems that know what to do with that XML file. The Basic Transaction System
In this simple example, the back office system has a style-sheet to display a basic transaction report but is assumed to have selective ability to process the same data for other purposes.
Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="transaction">
<xs:complexType>
<xs:sequence>
<xs:element ref="dateTime"/>
<xs:element ref="seq"/>
<xs:element ref="total"/>
<xs:element ref="tax"/>
<xs:element ref="lines"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="dateTime" type="xs:dateTime"/>
<xs:element name="seq" type="xs:nonNegativeInteger"/>
<xs:element name="total" type="xs:decimal"/>
<xs:element name="tax" type="xs:decimal"/>
<xs:element name="lines">
<xs:complexType>
<xs:sequence>
<xs:element ref="line" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="line">
<xs:complexType>
<xs:sequence>
<xs:element ref="plu"/>
<xs:element ref="description"/>
<xs:element ref="lineamt"/>
<xs:element ref="unitprice"/>
<xs:element ref="quantity"/>
<xs:element ref="taxability"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="plu" type="xs:nonNegativeInteger"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="lineamt" type="xs:decimal"/>
<xs:element name="unitprice" type="xs:decimal"/>
<xs:element name="quantity" type="xs:decimal"/>
<xs:element name="taxability" type="taxlist"/>
<xs:simpleType name="taxlist">
<xs:list itemType="taxtype"/>
</xs:simpleType>
<xs:simpleType name="taxtype">
<xs:restriction base="xs:string">
<xs:enumeration value="ST"/>
<xs:enumeration value="LO"/>
<xs:enumeration value="VAT"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Instance document (transaction log)
<?xml version="1.0" encoding="UTF-8"?>
<transaction xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16">
<dateTime>2005-01-15T19:17:03</dateTime>
<seq>42</seq>
<total>1.93</total>
<tax>.15</tax>
<lines>
<line>
<plu>12312312312</plu>
<description>Mars Bar</description>
<lineamt>.69</lineamt>
<unitprice>.69</unitprice>
<quantity>1</quantity>
<taxability>ST</taxability>
</line>
<line>
<plu>23423423423</plu>
<description>Coke 16oz</description>
<lineamt>1.09</lineamt>
<unitprice>1.09</unitprice>
<quantity>1</quantity>
<taxability>ST</taxability>
</line>
</lines>
</transaction>
Example XSLT application
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:nax="http://www.naxml.org/POSBO/Vocabulary/2003-10-16">
<xsl:output method="html" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<html>
<head>
<title>Transaction #
<xsl:value-of select="/nax:transaction/nax:seq"/></title>
</head>
<body>
<h1>POS Transaction Summary</h1>
<table border="1">
<tbody>
<tr>
<td>Time</td>
<td align="right">
<xsl:value-of select="/nax:transaction/nax:dateTime"/></td>
</tr>
<tr>
<td>Transaction number:</td>
<td align="right">
<xsl:value-of select="/nax:transaction/nax:seq"/></td>
</tr>
<tr>
<td>Transaction total:</td>
<td align="right">
<strong>
<xsl:value-of select="format-number(/nax:transaction/nax:total,'0.00')"/>
</strong>
</td>
</tr>
<tr>
<td>Tax:</td>
<td align="right">
<xsl:value-of select="format-number(/nax:transaction/nax:tax,'0.00')"/>
</td>
</tr>
</tbody>
</table>
<hr/>
<table border="1">
<tbody>
<tr>
<th>Description</th>
<th>Code</th>
<th>Line Total</th>
<th>Unit Price</th>
<th>Quantity</th>
</tr>
<xsl:apply-templates
select="/nax:transaction/nax:lines/*"/>
<tr>
<td colspan="2" align="right">Line item total:</td>
<td align="right">
<xsl:value-of
select="format-number(sum(/nax:transaction/nax:lines/nax:line/nax:lineamt),'0.00')"/>
</td>
<td>.</td>
<td>.</td>
</tr>
<tr>
<td colspan="2" align="right">Tax:</td>
<td align="right">
<xsl:value-of
select="format-number(/nax:transaction/nax:tax,'0.00')"/>
</td>
<td>.</td>
<td>.</td>
</tr>
<tr>
<td colspan="2" align="right">Total:</td>
<td align="right" >
<strong>
<xsl:value-of select="format-number(
sum(/nax:transaction/nax:lines/nax:line/nax:lineamt) +
/nax:transaction/nax:tax,'0.00')
"/>
</strong>
</td>
<td>.</td>
<td>.</td>
</tr>
</tbody>
</table>
</body>
</html>
</xsl:template>
<xsl:template match="nax:line">
<tr>
<td><xsl:value-of select="nax:description"/></td>
<td><xsl:value-of select="nax:plu"/></td>
<td align="right"><xsl:value-of select="format-number(nax:lineamt,'0.00')"/></td>
<td align="right"><xsl:value-of select="format-number(nax:unitprice,'0.00')"/></td>
<td align="right"><xsl:value-of select="format-number(nax:quantity,'0.000')"/></td>
</tr>
</xsl:template>
</xsl:stylesheet>
Vendor Enhancement - Product Encoding
Due to an industry initiative, products encoded with a UPC-A label must get special handling. This handling includes provisions for computing checksums and checking lengths. The POS vendor in this case introduces an attribute on the "plu" element to designate the encoding type. At the same time, the vendor introduces a new "discount" element to designate price reductions. Even with these new fields appearing from the vendor's POS, all the back-office companies must be able to continue to apply the basic XSLT stylesheet described above. Further, companies that know nothing about the changes must continue to be able to validate the documents as suitable for use. Such validation will likely mean partial validation. Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="transaction">
<xs:complexType>
<xs:sequence>
<xs:element ref="dateTime"/>
<xs:element ref="seq"/>
<xs:element ref="total"/>
<xs:element ref="tax"/>
<xs:element ref="lines"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="dateTime" type="xs:dateTime"/>
<xs:element name="seq" type="xs:nonNegativeInteger"/>
<xs:element name="total" type="xs:decimal"/>
<xs:element name="tax" type="xs:decimal"/>
<xs:element name="lines">
<xs:complexType>
<xs:sequence>
<xs:element ref="line" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="line">
<xs:complexType>
<xs:sequence>
<xs:element ref="plu"/>
<xs:element ref="description"/>
<xs:element ref="lineamt"/>
<xs:element ref="unitprice"/>
<xs:element ref="quantity"/>
<xs:element ref="taxability"/>
<xs:element ref="discount" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="plu">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:nonNegativeInteger">
<xs:attribute name="encoding" type="pluEncoding" default="none"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="description" type="xs:string"/>
<xs:element name="lineamt" type="xs:decimal"/>
<xs:element name="unitprice" type="xs:decimal"/>
<xs:element name="quantity" type="xs:decimal"/>
<xs:element name="discount" type="xs:decimal"/>
<xs:element name="taxability" type="taxlist"/>
<xs:simpleType name="taxlist">
<xs:list itemType="taxtype"/>
</xs:simpleType>
<xs:simpleType name="taxtype">
<xs:restriction base="xs:string">
<xs:enumeration value="ST"/>
<xs:enumeration value="LO"/>
<xs:enumeration value="VAT"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="pluEncoding">
<xs:restriction base="xs:string">
<xs:enumeration value="upcA"/>
<xs:enumeration value="upcE"/>
<xs:enumeration value="ean8"/>
<xs:enumeration value="ean13"/>
<xs:enumeration value="plu"/>
<xs:enumeration value="gtin"/>
<xs:enumeration value="rss14"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Instance document (transaction log)
<?xml version="1.0" encoding="UTF-8"?>
<transaction xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16">
<dateTime>2005-01-15T19:17:03</dateTime>
<seq>43</seq>
<total>4.26</total>
<tax>.25</tax>
<lines>
<line>
<plu encoding="upcA">12312312312</plu>
<description>Mars Bar</description>
<lineamt>2.07</lineamt>
<unitprice>.69</unitprice>
<quantity>3</quantity>
<taxability>ST</taxability>
</line>
<line>
<plu encoding="upcA">23423423423</plu>
<description>Coke 16oz</description>
<lineamt>1.94</lineamt>
<unitprice>1.09</unitprice>
<quantity>2</quantity>
<taxability>ST</taxability>
<discount>.24</discount>
</line>
</lines>
</transaction>
Committee Enhancement - Money Order Sales
The central committee responsible for the industry schema accepts and encorporates the POS vendor's changes. The committee then defines a new Money Order transaction, and introduces a new value for the encoding attribute of "none" to handle the PLU encoding characteristics. Again, the stylesheets must continue to work, and the instance document must be able to be validated as suitable for use in order to prevent disputes between vendors, even if a given vendor has not upgraded to the new version of the schema. Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="transaction">
<xs:complexType>
<xs:sequence>
<xs:element ref="dateTime"/>
<xs:element ref="seq"/>
<xs:element ref="total"/>
<xs:element ref="tax"/>
<xs:element ref="lines"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="dateTime" type="xs:dateTime"/>
<xs:element name="seq" type="xs:nonNegativeInteger"/>
<xs:element name="total" type="xs:decimal"/>
<xs:element name="tax" type="xs:decimal"/>
<xs:element name="lines">
<xs:complexType>
<xs:sequence>
<xs:element ref="line" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="line">
<xs:complexType>
<xs:sequence>
<xs:element ref="plu"/>
<xs:element ref="description"/>
<xs:element ref="lineamt"/>
<xs:element ref="unitprice"/>
<xs:element ref="quantity"/>
<xs:element ref="taxability"/>
<xs:element ref="discount" minOccurs="0"/>
<xs:element ref="fee" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="plu">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:nonNegativeInteger">
<xs:attribute name="encoding" type="pluEncoding" default="none"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="description" type="xs:string"/>
<xs:element name="lineamt" type="xs:decimal"/>
<xs:element name="unitprice" type="xs:decimal"/>
<xs:element name="quantity" type="xs:decimal"/>
<xs:element name="taxability" type="taxlist"/>
<xs:element name="discount" type="xs:decimal"/>
<xs:element name="fee" type="xs:decimal"/>
<xs:simpleType name="taxlist">
<xs:list itemType="taxtype"/>
</xs:simpleType>
<xs:simpleType name="taxtype">
<xs:restriction base="xs:string">
<xs:enumeration value="ST"/>
<xs:enumeration value="LO"/>
<xs:enumeration value="VAT"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="pluEncoding">
<xs:restriction base="xs:string">
<xs:enumeration value="upcA"/>
<xs:enumeration value="upcE"/>
<xs:enumeration value="ean8"/>
<xs:enumeration value="ean13"/>
<xs:enumeration value="plu"/>
<xs:enumeration value="gtin"/>
<xs:enumeration value="rss14"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Instance document (transaction log)
<?xml version="1.0" encoding="UTF-8"?>
<transaction xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16">
<dateTime>2005-01-15T19:17:03</dateTime>
<seq>44</seq>
<total>27.74</total>
<tax>.05</tax>
<lines>
<line>
<plu encoding="upcA">12312312312</plu>
<description>Mars Bar</description>
<lineamt>.69</lineamt>
<unitprice>.69</unitprice>
<quantity>1</quantity>
<taxability>ST</taxability>
</line>
<line>
<plu encoding="none">0</plu>
<description>Money Order</description>
<lineamt>27.00</lineamt>
<unitprice>25.00</unitprice>
<quantity>1</quantity>
<taxability/>
<fee>2.00</fee>
</line>
</lines>
</transaction>
Vendor Enhancement - Sell Units
A POS/Back-office vendor (the vendor produces both products) realizes that their inventory system needs more than just the PLU of a product to keep up with inventory. For excample, because the same PLU number will apply to both a single and a six-pack of a softdrink, there needs to be an additional piece of information, called the "sell unit". The introduction of the sell unit must (again) not interfere with the operation of the stylesheet nor with the ability of older programs to validate the document even though they have no access to the schema. Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="transaction">
<xs:complexType>
<xs:sequence>
<xs:element ref="dateTime"/>
<xs:element ref="seq"/>
<xs:element ref="total"/>
<xs:element ref="tax"/>
<xs:element ref="lines"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="dateTime" type="xs:dateTime"/>
<xs:element name="seq" type="xs:nonNegativeInteger"/>
<xs:element name="total" type="xs:decimal"/>
<xs:element name="tax" type="xs:decimal"/>
<xs:element name="lines">
<xs:complexType>
<xs:sequence>
<xs:element ref="line" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="line">
<xs:complexType>
<xs:sequence>
<xs:element ref="plu"/>
<xs:element ref="description"/>
<xs:element ref="lineamt"/>
<xs:element ref="unitprice"/>
<xs:element ref="quantity"/>
<xs:element ref="sellunit"/>
<xs:element ref="taxability"/>
<xs:element ref="discount" minOccurs="0"/>
<xs:element ref="fee" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="plu">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:nonNegativeInteger">
<xs:attribute name="encoding" type="pluEncoding" default="none"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="description" type="xs:string"/>
<xs:element name="lineamt" type="xs:decimal"/>
<xs:element name="unitprice" type="xs:decimal"/>
<xs:element name="quantity" type="xs:decimal"/>
<xs:element name="sellunit" type="xs:decimal"/>
<xs:element name="taxability" type="taxlist"/>
<xs:element name="discount" type="xs:decimal"/>
<xs:element name="fee" type="xs:decimal"/>
<xs:simpleType name="taxlist">
<xs:list itemType="taxtype"/>
</xs:simpleType>
<xs:simpleType name="taxtype">
<xs:restriction base="xs:string">
<xs:enumeration value="ST"/>
<xs:enumeration value="LO"/>
<xs:enumeration value="VAT"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="pluEncoding">
<xs:restriction base="xs:string">
<xs:enumeration value="upcA"/>
<xs:enumeration value="upcE"/>
<xs:enumeration value="ean8"/>
<xs:enumeration value="ean13"/>
<xs:enumeration value="plu"/>
<xs:enumeration value="gtin"/>
<xs:enumeration value="rss14"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Instance document (transaction log)
<?xml version="1.0" encoding="UTF-8"?>
<transaction xmlns="http://www.naxml.org/POSBO/Vocabulary/2003-10-16">
<dateTime>2005-01-15T19:17:03</dateTime>
<seq>45</seq>
<total>7.54</total>
<tax>.25</tax>
<lines>
<line>
<plu encoding="upcA">12312312312</plu>
<description>Mars Bar</description>
<lineamt>2.07</lineamt>
<unitprice>.69</unitprice>
<quantity>3</quantity>
<sellunit>1</sellunit>
<taxability>ST</taxability>
</line>
<line>
<plu encoding="upcA">23423423423</plu>
<description>Coke 16oz 6-pack</description>
<lineamt>5.22</lineamt>
<unitprice>5.22</unitprice>
<quantity>1</quantity>
<sellunit>6</sellunit>
<taxability>ST</taxability>
</line>
</lines>
</transaction>
[TODO]This needs to be written up.
http://www.idealliance.org/papers/dx_xmle03/html/abstract/03-04-03.html
Two largish goals
[TODO]Is this more about mechanisms (and should be described in a separate document)?
In XHTML 1.0, the strict, transitional, and frameset document types all use the same XML namespace. However, the schemas for them are very different. Additionally, variants of XHTML 1.0 such as XHTML Basic also share the same namespace, even though the schema for them is different.
Developers are often tempted into designing extensibility into their schemas at the infoset level rather than at the schema level. For example, they may add a "version" attribute to the root element: Hoping that future applications will be able to change their behaviour based on the value in that attribute. However, schema processors are not aware of application semantics, and cannot handle schema validation on the different versions.
Consider a real estate schema to record details about a property. In the original version, only the number of bathrooms is captured.
<property xmlns="http://realestate.example.com/property" version="1.0"> <bedrooms>3</bedrooms> <bathrooms>1</bathrooms> </property>
In the next version of the application, the schema has been changed. Here, details of how many baths, showers, and toilets are individually recorded.
<property xmlns="http://realestate.example.com/property" version="2.0">
<bedrooms>3</bedrooms>
<bathrooms>
<bath>1</bath>
<shower>1</shower>
<toilet>2</toilet>
</bathrooms>
</property>
[TODO]Can schemas (without co-constraits) ever hope to cope with this? If people choose to do things this way, is it schema's role to address the issues that arise?
[TODO]"Example is XSLT -- must a transform continue to work if the input uses a new version of its vocabulary."
[TODO]Need more information on this one.
[TODO]This needs to be completed.