[28 April 2014]
In an earlier post, resuscitation I talked about how to extend the MathML schema by using element substitution groups. I tend to think of that as the best way, pancreatitis other things being equal, to extend a schema.
But it’s also possible to extend the MathML schema by using
xsd:redefine; this post explains what’s involved.
Step by step
Define the extension elements
First, we make a schema document for our own namespace, including the extension elements. We can use the first version of the schema document given in the earlier post, before we messed around with the type definitions for the new elements.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:my="http://example.com/nss/sample" targetNamespace="http://example.com/nss/sample" elementFormDefault="qualified"> <xs:complexType name="extension-type-1" mixed="true"> <xs:sequence/> &t;xs:attribute name="id" type="xs:ID"/> <xs:attribute name="flavor"/> <xs:attribute name="tone"/> </xs:complexType> <xs:complexType name="extension-type-2" mixed="true"> <xs:sequence/> <xs:attribute name="gloss" type="xs:IDREF" use="required"/> </xs:complexType> <xs:element name="ext1" type="my:extension-type"/> <xs:element name="ext2" type="my:extension-type"/> </xs:schema>
Make a new MathML schema document
Next, we make a new top-level schema document to use when we import the MathML namespace. The new document will use
xsd:redefine to point to the standard top-level or root schema document for MathML, and specify some changes.
In particular, we decide that we want to add our extension elements to the content-model group named
mathml:Presentation-layout.class. We’ll define a group with that name, with the slightly unusual property that our new group will include a recursive reference to the existing group of that name, as a child. Such recursion is normally forbidden in content-model groups, but when redefining them, it’s obligatory. The group will look like this:
<xs:group name="Presentation-layout.class"> <xs:choice> <xs:element ref="my:ext1"/> <xs:element ref="my:ext2"/> <xs:group ref="mathml:Presentation-layout.class"/> </xs:choice> </xs:group>
The new top-level schema document for MathML will wrap that group definition in an
xsd:redefine element, and will contain nothing else.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mathml="http://www.w3.org/1998/Math/MathML" xmlns:my="http://example.com/nss/sample" targetNamespace="http://www.w3.org/1998/Math/MathML" elementFormDefault="qualified"> <xs:import namespace="http://example.com/nss/sample"/> <xs:redefine schemaLocation="../standard-modules/mathml2/mathml2.xsd"> <xs:annotation> <xs:documentation> This is a modified copy of the MathML 2 schema documents at http://www.w3.org/Math/XMLSchema/mathml2.tgz. We use xsd:redefine to extend the Presentation-layout class to include two extension elements. </xs:documentation> </xs:annotation> <xs:group name="Presentation-layout.class"> <xs:choice> <xs:element ref="my:ext1"/> <xs:element ref="my:ext2"/> <xs:group ref="mathml:Presentation-layout.class"/> </xs:choice> </xs:group> </xs:redefine> </xs:schema>
Point to the new MathML schema document, not the old
Finally, we make the top-level driver document for our schema import our redefinition of MathML, not the standard MathML schema documents. In a normal schema importing the MathML namespace, we might have something like this:
<xsd:import namespace="http://www.w3.org/1998/Math/MathML" schemaLocation="standard-modules/mathml2/mathml2.xsd"/>
In our modified schema we have:
<xsd:import namespace="http://www.w3.org/1998/Math/MathML" schemaLocation="local-mods/my-modified-mathml2.xsd"/>
Advantages and disadvantages
xsd:redefine has one advantage over using substitution groups: we didn’t have to muck with the type definitions of our extension elements in order to derive those types from the type used by the substitution-group head. It has a few disadvantages worth mentioning.
First, every group and type we redefine is required to refer to the group or type being redefined. So we cannot use
xsd:redefine to make arbitrary changes in a group or type. This was not a problem in our example, but it can be just as constraining, in its way, as the type-derivation requirement on substitution groups.
Second, despite the restrictions on what can be done in a redefinition,
xsd:redefine does not guarantee that the relation of our extended schema to the base schema is easy to explain, document, or understand. Documents valid against the base schema are not guaranteed to be valid against the extended schema, so we don’t necessarily have a clean extension. Nor is there a convenient way to ensure that documents valid against the redefinition are always valid against the base schema, in cases where we want a clean restriction. The redefined groups, or types, may turn out to violate some other constraint on schemas, so there is absolutely no guarantee that a redefinition which conforms to all the constraints in the spec, applied to a schema which conforms to all the constraints in the spec, will produce a resulting schema which conforms to the constraints in the spec. Under these circumstances, it’s not surprising that some informed observers regard the constraints on
xsd:redefine as pointless.
And, third, both the XSD 1.0 and the XSD 1.1 specs are internally contradictory with regard to
xsd:redefine, and it is not hard to find sets of schema documents which behave very differently in different implementations as a result of the implementors having different interpretations of the spec. It is possible to use
xsd:redefine in ways that will be consistently implemented by different XSD validators, but it’s very easy to find yourself locked in to a particular validator if you’re not careful.
Careful readers will have noticed that some imports in the schema documents shown have
schemaLocation attributes, and some don’t. The simplest way to achieve interoperability is to keep things very very simple, and never ever tell a validator more than once where to find a schema document for a given namespace. My way of doing that is always to have a top-level document for the schema that performs all the imports and includes needed for the schema, and provides explicit schema location information, and to insist as a general rule that no other schema documents ever contain schema location information, unless (as in the case of an
xsd:redefine) it is required for conformance to the spec. That way, the schema validator never sees two different schema locations for the same namespace, and we never need to worry about the fact that in such a situation different implementations of XSD may make different choices about which schema location to load and which to ignore. It is especially important to avoid the situation of having one schema document in your input import a particular namespace, while another redefines that same namespace: when that happens, no two XSD processors behave the same way. (This may seem implausible, since there are surely more than two XSD processors in the world. But it turns out that there are more than two different behaviors possible in the situation described. I once tested seven validators on an example, with different ways of formulating the command line, and got nine different behaviors from the set of seven processors.)