XML Schema 1.1 – What you need to know

Motivation

XML Schemas, more popularly known as XSDs, provide us a way to describe structure and content of XML Documents. Managed by W3C's XML Schema WG, a part of the XML Activity Group, XML Schemas evolved out of the shortcomings of its simpler and light-weight non-XML predecessor - DTDs, as well as through discussions and conferences of various interest groups across the community. The first W3C Recommendation of the XML Schema specification was released on 2 May, 2001.  The initial edition provided the users a strong type system, enabled users to model rich and complex structural constraints and value-spaces, recognized and allowed expression of namespaces, and also defined the intended behavior of Schema aware processors. This was followed up with a Second Edition in 2004, which wasn't really a newer version, but a minor errata driven release to the First Edition.

While XML Schemas matured, so did other XML based specifications like XSL, XQuery, Web Services, XPath, and several others . The XML Schema WG also ensured that these dependencies feed into the requirements for future versions of the language. The WG also provided an email distribution list that allowed developers and architects alike to exchange ideas, discuss issues and shortcomings, providing an open platform for debating the current and direction of the standard's future.  XML Schema 1.0 provided a platform that allowed architects in W3C and outside to clearly think about what is the next right step towards a "Version 2".

In 2005, W3C conducted a workshop on XML Schema 1.0 user experience. This workshop brought together users, developers and vendors into an open dialogue on potential usability issues, inter-op concerns and set the stage for a future version of the specification that addresses these glitches while adding in "must-have" features that were missed in 1.0. The key takeaways from all the following discussions were features related to Extensibility, Versioning and Validation. Apart from these, there were several very specific schema semantics that were long awaiting a change since 1.0 Ed2.

These led to the birth of a newer 1.1 version of the specification, which will be discussed in greater detail within this article.

Current Status of the Specification

The WG has released two Candidate Recommendation drafts of the following documents

The WG also released a non-normative guide to versioning XML Languages using new features of XML Schema 1.1.

Guide to Versioning XML Languages using new XML Schema 1.1 features

There are few key early implementers of the latest version of the specification namely Apache Xerces and SAXON.

Key Changes since 1.0

The changes since version 1.0 till date can be grouped into the following.

  • Validation
    • Rule based Validation - Love Schematron? 1.1 enables users to express cross-field validations and constraints using XPath 2.0.
  • Extensibility and Versioning
    • Wildcard Enhancements
      • Weak wildcard support - XSD 1.0 uses Unique Particle Attribution rule (UPA) to avoid ambiguity associated primarily with the usage of wildcard content. UPA restricts users from defining certain complex content models. XSD 1.1 attempts to address this using Weak wildcards that disambiguate using precedence rules.
      • Negative Wildcards and Multiple Namespaces
      • Open Content
    • <xsd:all> Model Group Changes  - Finally!
    • Vendor Unique Extensions - Enables vendors to ship their own primitive datatypes and facets
    • Conditional Inclusion - Enable creation of extensible schemas.
  • Miscellaneous Enhancements
    • Conditional Type Assignments
    • Inherited Attributes
    • Default Attribute Group - Enable globally shared set of attribute definitions.
    • Substitution Group Enhancements - Multiple element substitution related changes.
    • ID related changes - Enables, amonst others, mutliple ID attributes for elements.
    • Redefine Replaced by Override - Richer overrides, more interoperability.
    • Target Namespace attribute on local elements and attribute declarations
  • New Datatypes and Facets

One significant aspect of the standard that has been kept unchanged across revisions and editions is the Namespace URI for the schemas. What this means is that the version 1.1 schemas that you create will have the same XSD Namespace URI as a version 1.0 schema.

http://www.w3.org/2001/XMLSchema

In addition to this, almost all of the features in 1.0 have been brought into 1.1 in order to ensure backwards compatibility. What this means is that an XML document defined using a 1.0 schema can be validated using a 1.1 schema processor/validator.  This backward compatibility also ensures that the specification can satisfy dependant requirements from other specifications that rely on syntax and semantics of the 1.0 version of the specification.

1. Validations

Rule based Validation

XML Schema 1.1 introduces a new Schema component named <assert> to facilitate rule based validation, along similar lines of Schematron.

User can specify an Boolean XPath expression that will result in the assertions to pass or fail, depending on the evaluation of the expression. Assertion failures are equivalent to a  non-assertion validation failure.

Example 1
<xsd:element name="priceRange">
  <xsd:complexType>
     <xsd:sequence>
         <xsd:element name="minPrice" type="xsd:decimal"/>
         <xsd:element name="maxPrice" type="xsd:decimal"/>
     </xsd:sequence>
    <xsd:assert test="minPrice le maxPrice"/>
</xsd:complexType>
</xsd:element>

In the above example, the assertion checks if the decimal value of minPrice element is less than or equal to the maxPrice element. If an instance document fails this assertion, that document is considered invalid w.r.t the Schema, just like a non-assertion validation failure would cause it to be.

Syntax and Namespace Scope

The asserts are always defined at the end of the type declaration. It can hold a valid XPath 2.0 boolean expression. Being related to XPath 2.0, users can leverage the XPath 2.0 specific functions and operators while building the assertions.

The context node used for the expression evaluation is always the element whose type declaration hosts the mentioned assertion. In the above example, the context node would be the priceRange element. Hence all expressions within the assertions will need to be relative to the priceRange element.

One key restriction that is imposed on the path expressions that can be modeled in an assertion is that one cannot refer to parent or ancestor nodes of the context node. Only context node, or any of its descendants can be referred to within the path expressions. Neither it's siblings nor it's ancestors are permitted.

By this rule, the following assertion is invalid.

<assert test="string-length(ancestor::order/id) > 0"/>

so is

<assert test="string-length(following-sibling::shippingDate)  > 0"/>

and so is

<assert test="doc('pub/docs/customers.xml')/customerInfo[2]/id='12345'"/>

Users can model as many assertions as they want on the type declaration. In that case, the instance document will be considered valid only if none of the assertions for that type declaration have failed.

The namespace scope of the path elements in the expression is determined by the value of the xpathDefaultNamespace attribute on the assert element. If the attribute is absent, its value is assumed to be ##local - which translates into null namespace. This attribute can also be declared to hold any URI, or alternatively configured to use the targetNamespace or the default namespace declared for the XML Schema.

Example 2

<assert test="tns:price > 0" xmlns:tns="www.oracle.com" xpathDefaultNamespace="www.oracle.com"/>

<assert test="price > 0" xpathDefaultNamespace="##targetNamespace"/>

<assert test="price > 0" xpathDefaultNamespace="##defaultNamespace"/>

<assert test="tns:price > 0" xmlns:tns="www.oracle.com" xpathDefaultNamespace="##targetNamespace"/>

<assert test="price > 0" xpathDefaultNamespace="##local"/>

<assert test="ns1:value > ns2:netValue" xmlns:ns1="www.oracle.com" xmlns:ns2="www.abc.com"/>

The last assert is equivalent to not having the xpathDefaultNamespace attribute at all.

Rule based Validation of scalar content

As we described above, <assert>s can be used to define rule-based constraints on complex content. In the event that one wishes to model rules for simple content - for instance, against elements of string or decimal datatype, one can use a new facet available for atomic datatypes - named <assertion>.

Original Declaration:
<element name="evenPriceChangePercent" type="decimal"/>

Declaration with assertion:
<element name="evenPriceChangePercent" type="evenPriceChangePercentType"/>
<simpleType name="priceChangePercentType">
  <restriction base="decimal">
       <assertion test="$value <= 100 and $value >= 0"/>
       <assertion test="$value mod 2 = 0"/>
  </restriction>
</simpleType>

As seen above, this facet provides a default "value" variable that holds the text content of the simple content used for the evaluation. You cannot access any other context nodes within the XPath expression.

2. Extensibility and Versioning

Wildcard Related Enhancements

Weak Wildcards

Wildcards were introduced into XML Schema to build flexibility into schemas that users build. One could build newer schemas that could validate instances that were defined using an older version of the schema [Backward compatibility], or vice versa [Forward compatibility]. XMLSchema 1.0 provided schema constructs like <any/> and <anyAttribute/> for this purpose. These constructs enable elements and attributes that aren't explicitly defined in the schema, to occur in a valid XML instance document, providing way for extensible content models.

For instance,

Example 3
<element name="Address">
  <complexType>
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string"/>
          <!--allow any element from any namespace to occur -->
         <any namespace="##any" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

1.0 allowed for adding these wildcards at any position within your type declaration,as long as there isn't an ambiguity with explicitly declared elements.

Look at the example below.

Example 4
<element name="Address">
  <complexType>
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
          <!--allow any element from any namespace to occur -->
         <any namespace="##any" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

With the above schema in mind, consider the following XML document.

Example 5
<Address>
   <street>1, Courthouse Square</street1>
  <city>Hill Valley</city>
  <state>CA</state>
  <zip>91919</zip>
</Address>

With this document, it is impossible to state if zip element should be associated with the named element zip, or the wildcard any element. This schema is thus prohibited in XML Schema 1.0. The rule that prohibits this is termed as Unique Particle Attribution (UPA) Rule.

With 1.1, the UPA restriction is relaxed - it is no longer forbidden to have the kind of XML Schema mentioned in Example 4. [competition between element and wildcard]. When there is such an ambiguity, the named element definition takes precedence. In this case, since there is an element named "zip" that can resolve the ambiguiity, that one is chosen over the wildcard during resolution.

Also considered legal is a competition between two wildcards. However, competition between two elements is still considered a violation of the rule.

For example, the following XML schema is still invalid since the processing application will not be able to disambiguate the <direction> element in the XML Instance if their respective siblings were absent.

Example 6
<element name="TimeTravel">
   <complexType>
      <choice>
      <sequence>
          <element name="direction" type="string"/>
           <element name="year" type="integer" minOccurs="0"/> 
      </sequence>
      <sequence>
          <element name="direction" type="string"/>
           <element name="universeName" type="string" minOccurs="0"/> 
      </sequence>
     </choice>
  </complexType>
</element>

Multiple Namespaces and Negative Wildcards

In XML Schema 1.0, you had the capability to specify the namespace URI for a wildcard element. You could either specify

  • A list of one or more specific URIs
  • ##other - which means any URI other than the targetNamespace
  • ##targetNamespace - which is self explanatory
  • ##any - which means any URI
  • ##local - which indicates null namespace.
Example 7
<any namespace="##other"/>
<any namespace="http://www.delorean.com http://www.fluxcapacitor.com"/>
<any namespace="##targetNamespace"/>
<anyAttribute namespace="##local"/.>

In XML Schema 1.1, you have more ways to control your wildcards. You could in fact state that your wildcards NOT come from a namespace UR or multiple Namespace URIs.

In addition to this, you can also constrain the potential qualified name of the wildcard through the new schema constructs.

Example 8
<any notQName="tns:Almanac tns:IceHockey"/>
<anyAttribute notNamespace="##targetNamespace"/>
<any notNamespace="##defaultNamespace"/>
<any notNamespace="http://www.fluxcapacitor.org"/>

Other constraints you can impose are:

  • Ensure your wildcards do not have the same name as any of it's siblings.
  • Ensure your wildcards do not have the same name as any of the existing global declarations in the schema.
Example 9
<any notQName="##definedSibling"/>
<any notQName="##defined"/>

Take a look at the schema below.

Example 10
<element name="Address">
   <complexType>
      <sequence>
           <element name="street" type="string"/>
           <element name="city" type="string"/>
           <element name="state" type="string"/>
           <element name="zip" type="string"/>
            <any notQName="##definedSibling" namespace="##local"/>
      </sequence>
  </complexType>
</element>

This will fail validation for the following XML instance.
<Address>
   <street>1, Courthouse Square</street1>
  <city>Hill Valley</city>
  <state>CA</state>
  <zip>91919</zip>
  <zip>94321</zip>
</Address>

Open Content

Open Content allows for defining elements to possess child element or attribute content other than the ones explicitly defined in it's content model, and allow them to be available at any position within its content.

In 1.0, you needed to explicitly position your <xsd:any/> declarations within your choice or sequence content models. In 1.1, you can declare open content for your elements at one place - within the complexType definition, or at the schema level. On top of this, you can choose to distribute your open content interleaved between your named child elements [interleaved], choose to have them after all of the child elements. [suffixed], or disable inherited openContent behavior.

Example 11 - Interleaved Open Content
<element name="Address">
  <complexType>
    <openContent mode="interleave">
         <any/>
    </openContent>

     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

Valid Instances for the Schema

Example 1:

<Address>
   <street>1, Courthouse Square</street1>
   <boo/>
  <city>Hill Valley</city>
   <foo/>
   <bar/>

  <state>CA</state> 
  <zip>91919</zip>
   <boo2/>
</Address>

Example 2:

<Address>
   <street>1, Courthouse Square</street1>
   <boo/>
   <foo/>
   <bar/>
  <city>Hill Valley</city> 
  <state>CA</state> 
   <boo2/>
  <zip>91919</zip>
</Address>

Note that the maxOccurs="unbounded" and minOccurs="0" attributes on the <any/> is implicit - which explains how one is able to have multiple wildcard elements in your XML instance document.

Example 12: Suffixed Open Content

<element name="Address">
  <complexType>
    <openContent mode="suffix">
       <any/>
    </openContent>

     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

Valid Instance for the Schema

<Address>
   <street>1, Courthouse Square</street1> 
  <city>Hill Valley</city> 
  <state>CA</state> 
  <zip>91919</zip>
   <boo/>
   <foo/>
   <bar/>
   <boo2/>

</Address>

The third use-case - mode="none" is typically used when you are importing and extending a complexType from a foreign schema, but do not wish to inherit the openness of the inherited type definition.

The wildcard <any/> within the <openContent> section can be combined with the wildcard constraints discussed in the earlier section as well. [e.g. <any notQName="fc:doc"/>]

Another variant of of the openContent use-case is the one where user wishes to model adding wildcards within any element content defined in the schema - i.e. a schema-wide openContent.

This is supported through a schema construct <defaultOpenContent> declared as a direct child of the <schema> element. See example below.

Example 14 (I skipped "13")
<schema targetNamespace="..." xmlns="....">
<defaultOpenContent mode="interleave" appliesToEmpty="true">
   <any/>
</defaultOpenContent>

<element name="Order">
  ....
</element>

<element name="Info">
   <complexType/>
   <attribute name="id" type="string"/>
</element>

<element name="BillingAddress" type="tns:BillingAddressType"/>

<element name="ShippingAddress" type="tns:ShippingAddressType"/>

  <complexType name="BillingAddressType"> 
     <sequence>
          <element name="street1" type="string"/>
          <element name="street2" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>

  <complexType name="ShippingAddressType"> 
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>


</schema>

This schema can be used to generate XML documents where arbitrary elements can occur between the contents of ShippingAddress and BillingAddress. Even the empty element Info can have open content within it attributed to the appliesToEmpty attribute on the <defaultOpenContent> declaration.

Valid Instance for the above XSD:

<Order>
   <Info id="123">
        <HelloWorld/>
   </Info>
  <BillingAddress>
      <Welcome6>123</Welcome6>
      <street1>1, Courthouse Square</street1> 
      <street2>Apt 007</street2> 
      <boo2/> 
      <city>Hill Valley</city> 
      <state>CA</state> 
      <zip>91919</zip> 
      <foo3/> 
</BillingAddress>
  <ShippingAddress>
      <Welcome>123</Welcome>
      <street>1, Courthouse Square</street>  
      <boo/> 
      <city>Hill Valley</city> 
      <state>CA</state> 
      <zip>91919</zip> 
      <foo/> 
</ShippingAddress>
</Order>

<xsd:all> Group Changes

The "All" Model group was bundled with several restrictions when it was introduced in XML Schema 1.0.

1. The group disallowed multiple occurence elements to be a part of the content model.   The following is illegal in XML Schema 1.0

Example 15
<complexType name="FluxCapacitorType">
   <all>
       <element name="timeCalibrator" type="string" maxOccurs="unbounded"/>
       <element name="needsRecharge" type="boolean" minOccurs="3" maxOccurs="unbounded"/>
  </all>
</complexType>

Elements within <all> groups were supposed to have maxOccurs=1 and a minOccurs of 0 or 1.

i.e. elements occur in any order, but each element occurs exactly once, if present.

2. <all> group cannot be nested within another model group. What this means is that you cannot have an <all> nested within a <sequence> or a <choice> model group. Thus the following is illegal in 1.0.

Example 16
<complexType name="FluxCapacitorType">
  <choice>
       <element name="autoFunction" type="AutoFunctionType"/>
       <all>
            <element name="timeCalibrator" type="string" maxOccurs="unbounded"/>
            <element name="needsRecharge" type="boolean" minOccurs="3" maxOccurs="unbounded"/>
      </all>
   </choice>
</complexType>

3. You cannot extend a non-empty BaseType with an <all> content model. The following is illegal in 1.0

Example 17
<complexType name="BaseTimeTravelMachineType">
  <all>
        <element name="timeComputer" type="string"/>
        <element name="carrier" type="CarrierType"/>
  </all>
</complexType>

<complexType name="HighSpeedTimeTravelMachineType">
  <complexContent>
       <extension base="BaseTimeTravelMachineType">
            <all>
                   <element name="TravelerProfileReader" type="ProfileReaderType"/>
          </all>
       </extension>
   </complexContent>
</complexType>

4. You cannot have wildcards within <all> groups.  The following is illegal in 1.0.

Example 18
<complexType name="BaseTimeTravelMachineType">
  <all>
       <any/>
        <element name="timeComputer" type="string"/>
        <element name="carrier" type="CarrierType"/>
  </all>
</complexType>

XML Schema 1.1 has legalized all the above models.

Vendor Unique Extensions

Vendors can now define their own primitive datatypes and facets. For instance, it may provide support for a new primitive datatype called string, with it's own implementation defined facets. These datatypes will be in a vendor defined namespace in order to distinguish them from XSD's predefined datatypes. The treatment of  the vendor defined datatype depends on each vendor - and evidently, it may not be supported by a processor implemented by another vendor.

Example 19
<!--new custom integer datatype -->
<element name="age" type="xdk:integer"/>
<!--new custom 'era' facet -->
<simpleType name="TimeType">
     <extension base="xdk:oracleDateTime">
            <xdk:era="Andromedan"/>
      </extension>
</simpleType>

Conditional Inclusion

This feature is primarily used to ensure that XML documents that may be defined down the future using a later version of XML Schema language [say 5.5] can be processed in compatibility mode by a XML Processor that supports a prior version of  XML Schema [starting from 1.1].  For instance, one of the element declarations in a user defined XML Schema may use a new construct that was introduced in XML Schema 5.5. If you need to process this XML Schema using an XML Schema 1.1 compliant processor, you have to have a feature that allows you to pre-process and selectively interpret the constructs that the 1.1 version processor understands.

For this purpose, XML Schema 1.1 introduces a new set of attributes in the Schema Versioning Namespace, as listed below.

The Schema Versioning Namespace has a URI - http://www.w3.org/2007/XMLSchema-versioning. Within this namespace URI are four attributes.

  1. vc:typeAvailable
  2. vc:typeUnavailable
  3. vc:facetAvailable
  4. vc:facetUnavailable
  5. vc:minVersion
  6. vc:maxVersion

Look at the 2 examples below. In the first example, the user intends to define an element named TimeMachine that can be interpreted by an XML Schema Processor that complies with version 1.6, as well as one that supports version 1.1.

Example 20
<!--The below declaration is accepted for pre-processing for XML Schema versions 1.1 [inclusive], but less than 1.6. [exclusive] -->
<element name="TimeMachine" vc:minVersion="1.1" vc:maxVersion="1.6">
   <complexType>
         <sequence>
           .....
</element>
<!--The below declaration is accepted for pre-processing for XML Schema versions 1.6 or later. It may have constructs that are not understood by 1.1 processors.
-->

<element name="TimeMachine" vc:minVersion="1.6">
      <complexPhasedDatatype>
          <prioritizedSequence>
                ...
</element>

In the second example, listed below, the user intends to signal the usage of a vendor defined datatype or facet through the first 4 schema versioning attributes listed above.

Example 21
<!--line 1 is for processors that implement the custom datatype, whereas line 2 is used by other processor implementations -->
<element name="EmmetBrownsLabHeight" vc:typeAvailable="xdk:feet" type="xdk:feet"/>
<element name="EmmetBrownsLabHeight" vc:typeUnavailable="xdk:feet" type="xsd:integer"/>

<!--declaration 1 is used by processor that implements the custom minLength facet. The latter declaration is the fallback used by other processors ->
<element name="ItemCode" vc:facetAvailable="xdk:minLength">
    <simpleType>
       <restriction base="string">
              <xdk:minLength value="1,2"/>
       </restriction>
    </simpleType>
</element>
<element name="ItemCode" vc:facetUnavailable="xdk:minLength" type="string"/>

3. Miscellaneous Enhancements

Conditional Type Assignments

XML Schema 1.1 allows for dynamic type assignment based on XPath 2.0 boolean condition expressions.

See example below.

Example 22
<!--inline alternative type definitions -->
<element name="TimeTravel" type="TravelType">
      <alternative test="@direction='Future'">
          <complexType>
              <complexContent>
              <restriction base="TravelType"
                         ....
<!--        some past travel related elements go here -->
            </complexType>
       </alternative>
      <alternative test="@direction='Past'">
          <complexType>
              <complexContent>
              <restriction base="TravelType"
                         ....
   <!--        some future travel related elements go here -->
            </complexType>
       </alternative>
  </element>
                          OR
<!--Named alternative type definitions -->
<element name="TimeTravel" type="TravelType">
   <alternative test="@direction='Future' type="FutureTravelType"/>
   <alternative test="@direction='Past' type="PastTravelType"/>
</element>

Few points to note here.

  • You can only access attributes of the context node within the xpath expression. You cannot use child/descendant elements in the expression as you would have seen in the assert statements earlier in the article, nor anything on the ancestor axis. In the above example, direction is an attribute defined within  the complexType TravelType that is used to define the TimeTravel element.
  • The alternative types should be datatypes that are derived from the actual type defined on the element. In the above example, FutureTravelType and PastTravelType are derived from TravelType.
  • Just as you would model the namespaces in asserts, you could use the xpathDefaultNamespace attribute to qualify the xpath expression on the alternatives.

Inherited Attributes

Inheriting attributes allows access to attributes of ancestor elements within descendant elements. Though inheriting does not allow the attributes to actually appear on the descendant element in the XML instance, they can be effectively used within asserts and type alternatives for the descendant element. An attribute can be declared as inheritable by defining inheritable="true" on the attribute declaration, as illustrated below.

Example 23
<element name="TimeTravelType">
    <complexType>
         <sequence>
               <element name="GadgetType">
                    <alternative test="@mode='Past' type="PastGadgetType"/>
                    <alternative test="@mode='Future' type="FutureGadgetType"/>
              </element>
             <element name="dimension">
                 ....
                <assert test="@length > 200 and @mode='Past'"/>
                <assert test="@length <= 200 and @mode='Future'"/>
        </sequence>
        <attribute name="mode" inheritable="true"/>
    </complexType>
</element>

Note that defining an inheritable attribute does not prevent schema designer to define attributes with the same name on the descendant element datatypes. In that case, the local declaration prevails.

Default Attribute Group

Default attribute group defines a set of global attributes that can be accepted by all complexType definitions directly defined in the schema file. [not applicable to imported/included components]

Example 24
<schema targetNamespace="...."
                   defaultAttributes="myLocalAttrs"
                   ....>
     <element name="AllTimePieces">
               ...
     <element>
     <element name="MyTimePiece">
                   ...
      <element>
      <element name="HisMuchBetterTimePiece">
                ....
         </element>

        <attributeGroup name="myLocalAttrs">
             <attribute name="tpId" type="ID"/>
         </attributeGroup>
</schema>

<AllTimePieces tpId="NONE">
         <MyTimePiece tpId="0">
                        ....
          </MyTimePiece>
          <HisMuchBetterTimePiece tpId="1">
                        ...
           </HisMuchBetterTimePiece>
   </AllTimePieces> 

This eliminates the need for redundant reference to the attribute group within all complexType definitions that needed to share the same set of attributes.

Substitution Group Enhancements

SubstitutionGroups in XML Schema 1.0 allows elements to be substitutable for other elements. To be precise, it allows for replacing an element with another. XML Schema 1.1 enhances this functionality by allowing an element to be substitutable for one or more elements

Example 25
<!--SubstitutionGroups in XML Schema 1.0 -->
<element name="shipComment" substitutionGroup="po:Comment" type="ShipCommentType"/>
<element name="billComment" substitutionGroup="po:Comment" type="BillComentType"/>

<!--SubstitutionGroups in XML Schema 1.1 ->
<element name="Flute" substitutionGroup="po:MusicalInstrument po:WindInstrument" type="FluteType"/>
<element name="MusicalInstrument" type="po:MusicalInstrumentType"/>
<element name="WindInstrument" type="po:WindInstrumentType"/>

As seen in Example 25, the element Flute can be substituted for either the MusicalInstrument element, or the WindInstrument element, provided FluteType datatype is derived from MusicalInstrumentType and WindInstrumentType.

ID related changes

XML Schema 1.1 has revised ID semantics to allow elements to possess more than one xsd:ID attribute. XSD 1.0 had forbidden this usage for ensuring compatibility with DTDs. Schemas that intend to be compatible can choose to not use this feature.  It also allows ID attributes to have default and fixed values - again something that was forbidden in 1.0.

Example 26

<element name="Fruit">
   <complexType>
     <sequence>
          <element name="taste" type="f:TasteType"/>
           ...
      </sequence>
     <!--Illustrating more than one ID on an element -->
     <attribute name="fruitUID" type="ID"/>
     <attribute name="flavourUID" type="ID"/>
   <!--illustrating default value on an ID type attribute -->
    <attribute name="locationCode" type="ID" default="US-CA"/>
</element>

Redefine Replaced by Override

<redefine> construct in XML Schema 1.0 enabled users to extend or restrict element type declarations. What it did not allow was to create a new definition for the same element when redefining it.

Example 27
<!--Legal redefine in XML Schema 1.0 -->
<schema .....>
   <redefine schemaLocation="http://www.greatschemas.org/invoice.xsd">

    <complexType name="BillingAddressType">
<!--BillingAddressType is defined in the included schema above, and is being redefined -->
            <extension base="gsc:BillingAddressType">
                  <sequence>
                        <element name="BillingCode" type="string"/>
                  </sequence>
            </extension>
    </complexType>

    <!--
        Illegal redefine in XML Schema 1.0  where BillingAddressType has been defined in the included schema  above
       -->

      <complexType name="BillingAddressType">
                  <sequence>
                        <element name="TotallyDifferentBillingStuff" type="string"/>
                  </sequence>
            </extension>
    </complexType>
</redefine>

Moreover, XML Schema 1.0 had many conflicting and non-interoperable implementations for <redefine> that 1.1 decided to deprecate the <redefine> functionality and replace it with a richer <override> construct instead.

Example 28
<!--Legal override in XML Schema 1.1 showing extension of types-->
<schema .....>
   <override schemaLocation="http://www.greatschemas.org/invoice.xsd">

    <complexType name="BillingAddressType">
<!--BillingAddressType is defined in the included schema above, and is being redefined -->
            <extension base="gsc:BillingAddressType">
                  <sequence>
                        <element name="BillingCode" type="string"/>
                  </sequence>
            </extension>
    </complexType>

    <!--
        Legal override in XML Schema 1.0  where BillingAddressType has been defined in the included schema  above
       -->

      <complexType name="BillingAddressType">
                  <sequence>
                        <element name="TotallyDifferentBillingStuff" type="string"/>
                  </sequence>
            </extension>
    </complexType>
</override>

Note that <redefine>  has been deprecated, but not removed yet. The WG is still looking for feedback from users on this construct.  It MAY be removed from future versions of the specification.

Target Namespace attribute on local elements and attribute declarations

XML Schema 1.1 allows users to define targetNamespace on local element and attribute declarations. The namespace URI may be different from the targetNamespace defined on its ancestors or the schema element.

Example 29
<schema targetNamespace="http://xmlns.oracle.com/definitions" ..... elementFormDefault="qualifiied">
    <element name="Address">
           <complexType>
               <sequence>
                     <element name="street1" targetNamespace="www.alternatens.com/defns"/>
                       ....
               </sequence>
                <attribute name="id" targetNamespace="http://xmlns.groceries.com/defns"/>
             </complexType>
         </element>
</schema>

<schema targetNamespace="http://xmlns.oracle.com/definitions" ..... elementFormDefault="qualifiied">
    <import namespace="www.foreign.com/defns" schemaLocation="Alt_Objects.xsd"/>
    <element name="Address">
           <complexType>
            <complexContent>
              <extension base="ForeignAddressType">
               <sequence>
                     <element name="street1" targetNamespace="www.foreign.com/defns"/>
                       ....
               </sequence>
                <attribute name="id" targetNamespace="www.foreign.com/defns"/>
             </complexType>
         </element>
</schema>

4. New Datatypes and Facets

XML Schema 1.1 added several new core datatypes into its existing library.

xsd11_datatypes

1. The anyAtomicType datatype

This datatype has been newly introduced as the base type for all atomic datatypes in the Schema's datatype library. [i.e. string, float,boolean etc]. It extends from anySimpleType.

"In XML Schema, a simple type is either a list type, a union type, or an atomic type; however, these three kinds of simple type are not recognized explicitly in the type hierarchy. For XPath, it was necessary to distinguish atomic types from the other kinds of simple type, so xdt:anyAtomicType was invented to achieve this."

                - Michael Kay, SAXONICA

2. New Numeric Datatypes

A new datatype named precisionDecimal has been added to support IEEE-754 floating-point decimal datatypes. precisionDecimals carry a numeric value, an arithmetic precision and a sign. Apart from distinguishing between positive and negative zero, this datatype also holds NaN and positive/negative infinity in it's value space.

Example 30
<price>1200.04</price>
<price>INF</price>
<price>-INF</price>
<price>NaN</price>

3. Date/time Datatypes

The following new datatypes - dateTimestamp, dayTimeDuration and yearMonthDuration have been added to the library. dateTimestamp extends the existing dateTime datatype with a mandatory explicitTimezone facet. [the timezone portion was optional in the dateTime datatype.]

<element name="shipDate" type="dateTimeStamp"/>

<shipDate>2010-02-01T12:03:00-08:00</shipDate>
<shipDate>2010-02-01T12:03:00Z</shipDate>

Both new duration related datatypes extend from the existing duration datatype and does a simple restriction on its lexical space.

<!--2 years and 3 months yearMonthDuration -->
<sampleYearMonthDuration>P2Y3M</sampleYearMonthDuration>
<!--1 day and 6 hours dayTimeDuration-->
<sampleDayTimeDuration>P1D6H</sampleDayTimeDuration>

5. Next Steps

Several implementations are under development. This includes the upcoming versions of Xerces, and the SAXON processor. 

You can contribute to the specification by submitting your comments to the public comments mailing list for the standard - www-xml-schema-comments@w3.org. Here is the archive.

6. Credits

Roger Costello's Tutorial is one of the best you can grab to get to the next level of details on the specification. He has done a fabulous job in documenting all major features to fine levels of detail. You can find a link to his tutorial in the next section.

6. References

1. XML Schema 1.1 Part 1: Structures

2. XML Schema 1.1 Part 2: Datatypes

3. Roger Costello's XML Schema Tutorial

4. XML Schema 1.1, Part 1: An introduction to XML Schema 1.1 - IBM

5. XML Schema 1.1, Part 2: An introduction to XML Schema 1.1 - IBM

6. XML Schema 1.1, Part 3: An introduction to XML Schema 1.1 - IBM

Comments:

My nephew recommended this blog and he was totally right keep up the fantastic work!

Posted by Marion Vranek on April 25, 2011 at 04:42 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Principal Product Manager

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today