How to indicate that an xml schema that requires schema 1.1 features?

Question

If I create an XML Schema that requires schema 1.1 features (especially subtle ones, like removing an optional element in restriction of a base type), what is the best way to indicate that this schema should not be used with a processor that only understands version 1.0?

In an XSLT stylesheet file, it is possible to indicate the version of the XSLT specification that is used using a version attribute.

But in an XSD file, the version attribute does not have this meaning - it is a free-form attribute that says something about the version of the schema, not about the version of the specification that is being used.

And is it required to label a schema that uses 1.1 features?

I have a complex set of schemas using the FPML 5.5 specification and some custom schemas, and it cannot be validated with some schema validators, but I'm not sure if that is because the validator has bugs or because the schema is subtly using xml schema 1.1 features.

Answer 1

At this point in time, this issue is not that easy to resolve; this is because most of the XSD processors are 1.0, and the schema versioning introduced in XSD 1.1 spec can't apply backwards. To learn more about it (in general) have a look at The Schema Versioning Namepsace, and the examples included in section 4.2.2 Conditional inclusion.

You could implement your own pre-processing solution, that is to at least help with choosing the appropriate XSD processor using something such as this:

<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning">

    <xsd:element name="e" vc:minVersion="1.1">
        <xsd:complexType>
            <xsd:all>
                <xsd:element name="a" minOccurs="0"/>
                <xsd:element name="b" maxOccurs="unbounded"/>       
            </xsd:all>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name="e" vc:minVersion="1.0" vc:maxVersion="1.1">
        <xsd:complexType>
            <xsd:choice maxOccurs="unbounded">
                <xsd:element name="a" minOccurs="0"/>
                <xsd:element name="b" />            
            </xsd:choice>
        </xsd:complexType>
    </xsd:element>      
</xsd:schema>

This way at least you'll be using an XSD 1.1 endorsed approach to versioning; it also comes with a processing model. For certain tasks, it is relatively easy to build a pre-processor that at least will handle the appropriate selection of the XSD processor (1.0 or 1.1) . To make simpler in a closed environment, you could also choose a convention where you could mark the whole xsd:schema with vc:minVersion="1.1" - basically what you seem to have wanted to begin with.

Regarding your last paragraph, the choice of the XSD processor has to be asserted rather than implied. This is because XSD 1.1 allows for constructs that were impossible in XSD 1.0 (e.g. an all compositor containing particles with max occurrence greater than 1)... so unless one makes a prior decision re: the processor to use, the XSD may or may not be invalid. Whereas other things will be invalid regardless of the processor used.