W3C

Service Modeling Language, Version 1.1

W3C Working Draft 6 August 2007

This version:
http://www.w3.org/TR/2007/WD-sml-20070806/
Latest version:
http://www.w3.org/TR/sml/
Editors:
James Lynn, HP
Bhalchandra Pandit, Microsoft Corporation
Valentina Popescu, IBM Corporation
Virginia Smith, HP
Bassam Tabbara , Microsoft Corporation
Marvin Waschke, CA

This document is also available in these non-normative formats: XML.


Abstract

This specification defines the Service Modeling Language, Version 1.1 (SML) used to model complex services and systems, including their structure, constraints, policies, and best practices. SML is based on a profile of XML Schema and Schematron.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the first Public Working Draft of the Service Modeling Language, Version 1.1 specification for review by W3C members and other interested parties. It has been developed by the Service Modeling Language (SML) Working Group, which is a part of the Extensible Markup Language (XML) Activity.

The features and algorithms described in the normative portion of the document are specified in enough detail adequate for early implementation experiments.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Comments on this document are invited and are to be sent to the public-sml@w3.org mailing list (public archive).

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction (Non-Normative)
2. Notations and Terminology
    2.1 Notational Conventions
    2.2 Terminology
    2.3 XML Namespaces
3. Schemas
    3.1 References
        3.1.1 Reference Definitions
            3.1.1.1 SML Reference
            3.1.1.2 Null Reference
            3.1.1.3 Dangling Reference
        3.1.2 Reference Semantics
            3.1.2.1 At Most One Target
            3.1.2.2 Multiple References  
            3.1.2.3 Empty or Null References
            3.1.2.4 deref() XPath Extension Function
    3.2 Reference Schemes
        3.2.1 URI Scheme
            3.2.1.1 Fragment Identifier
        3.2.2 EPR Scheme
    3.3 Constraints on References
        3.3.1 sml:acyclic
        3.3.2 Constraints on Targets
            3.3.2.1 sml:targetElement
            3.3.2.2 sml:targetRequired
            3.3.2.3 sml:targetType
    3.4 Identity Constraints
        3.4.1 University Example
        3.4.2 sml:key and sml:unique
        3.4.3 sml:keyref
4. Rules
    4.1 Localization of Error Messages
        4.1.1 smlerr:localizationid
    4.2 Schematron Profile
        4.2.1 Limited Support
5. Structured XML Output from Schematron Rules
    5.1 smlerr:output
        5.1.1  smlerr:outputids
        5.1.2 smlerr:attributeNode
        5.1.3 smlerr:errorDataType
        5.1.4 Semantics
        5.1.5 Examples
6. Model Validation
    6.1 Schematron Phase
7. SML Extension Reference
    7.1 Types
        7.1.1 sml:refType
    7.2 Attributes
        7.2.1 sml:acyclic
        7.2.2 sml:ref
        7.2.3 sml:targetElement
        7.2.4 sml:targetRequired
        7.2.5 sml:targetType
    7.3 Elements
        7.3.1 sml:key
        7.3.2 sml:keyref
        7.3.3 sml:unique
        7.3.4 sml:uri
    7.4 XPath functions
        7.4.1 smlfn:deref
8. References
    8.1 Normative References
    8.2 Informative References

Appendices

A. Normative SML Schema
B. Normative SML Error Schema
C. Sample Model (Non-Normative)
D. Acknowledgements (Non-Normative)


1. Introduction (Non-Normative)

The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex services and systems. Depending on the application domain, these models may include information such as configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on. Models provide value in several important ways.

  1. Models focus on capturing all invariant aspects of a service/system that must be maintained for the service/system to function properly.

  2. Models represent a powerful mechanism for validating changes before applying the changes to a service/system. Also, when changes happen in a running service/system, they can be validated against the intended state described in the model. The actual service/system and its model together enable a self-healing service/system ― the ultimate objective. Models of a service/system must necessarily stay decoupled from the live service/system to create the control loop

  3. Models are units of communication and collaboration between designers, implementers, operators, and users; and can easily be shared, tracked, and revision controlled. This is important because complex services are often built and maintained by a variety of people playing different roles.

  4. Models drive modularity, re-use, and standardization. Most real-world complex services and systems are composed of sufficiently complex parts.  Re-use and standardization of services/systems and their parts is a key factor in reducing overall production and operation cost and in increasing reliability.

  5. Models enable increased automation of management tasks. Automation facilities exposed by the majority of services/systems today could be driven by software ― not people ― both for reliable initial realization of a service/system as well as for ongoing lifecycle management.

A model in SML is realized as a set of interrelated XML documents. The XML documents contain information about the parts of a service, as well as the constraints that each part must satisfy for the service to function properly. Constraints are captured in two ways:

  1. Schemas ― these are constraints on the structure and content of the documents in a model. SML uses a profile of XML Schema 1.0 [XML Schema Structures, XML Schema Datatypes] as the schema language. In addition SML defines a set of extensions to XML Schema to support inter-document references.

  2. Rules ― are Boolean expressions that constrain the structure and content of documents in a model. SML uses a profile of Schematron [ISO/IEC 19757-3, Introduction to Schematron, Improving Validation with Schematron] and XPath 1.0 [XPath 1.0] for rules.

One of the important operations on the model is to establish its validity. This involves checking whether all data in a model satisfies the schemas and rules declared.

This specification focuses primarily on defining the profile of XML Schema and Schematron used by SML, as well as the process of model validation. It is assumed that the reader is familiar with XML Schema and Schematron.

2. Notations and Terminology

2.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [IETF RFC 2119].

2.2 Terminology

Document

A well-formed XML 1.0 document, as defined in [XML 1.0].

Model

A set of inter-related documents that describe a service or system.  Each model consists of two disjoint subsets of documents –definition documents and instance documents.

Rule

A rule is a boolean expression that constrains the structure and content of a set of documents in a model.

Model Definition

The subset of documents in a model that describes the schemas and rules that govern the structure and content of the model's documents. This specification defines two types of model definition document - Schema documents that conform to SML's profile of XML Schema and rule documents that conform to SML's profile of Schematron – but permits implementations to define other types of model definition documents. Such other types of model definition documents do not play any role in SML model validation.

Model Instance

A model instance is the subset of documents in a model that describe the structure and content of the modeled entities.

Model Validation

The model validation is the process of verifying that all documents in a model are valid with respect to the model's definition documents.

Model Validator

A model validator is an embodiment capable of performing model validation

2.3 XML Namespaces

Table 2-1 lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 2-1. XML Namespaces used in this specification.
PrefixXML NamespaceSpecification(s)
sml http://www.w3.org/2007/08/sml This specification
smlerr http://www.w3.org/2007/08/sml-err This specification
smlfn http://www.w3.org/2007/08/sml-function This specification
wsa http://www.w3.org/2005/08/addressing [WS-Addressing Core]
xs http://www.w3.org/2001/XMLSchema [XML Schema Structures, XML Schema Datatypes]
sch http://purl.oclc.org/dsdl/schematron [ISO/IEC 19757-3]
xsi http://www.w3.org/2001/XMLSchema-instance XML Schema instance, as defined in [XML Schema Structures]

3. Schemas

SML uses a profile of W3C XML Schema 1.0 [XML Schema Structures, XML Schema Datatypes] to define constraints on the structure of data in a model.

SML scenarios require several features that either do not exist or are not fully supported in XML Schema. These features can be classified as follows:

XML Schema supports two forms of extension: "attributes in different namespace" and "application information elements"; both forms are used by SML extensions.

3.1 References

XML documents introduce boundaries across content that needs to be treated as a unit. XML Schema does not have any support for inter-document references. SML extends XML Schema to support inter-document references and a set of constraints on inter-document references.

Support for inter-document references includes:

  • A new data type that represents references to elements in other documents.

  • Multiple addressing schemes for representing references.

  • Constraints on the type of a referenced element.

  • The ability to define key, unique, and key reference constraints across inter-document references.

An SML reference is a link from one element to another. It can be represented by using a variety of schemes, such as Uniform Resource Identifiers (URIs) [IETF RFC 3986] and Endpoint References (EPRs) [WS-Addressing Core]. SML does not mandate the use of any specific scheme for representing references; implementations are free to choose suitable schemes for representing references.  References MUST be supported by model validators that conform to this specification.

Reference elements MUST be identified by sml:ref="true" or sml:ref="1" where sml:ref is a global attribute whose declaration is as follows:

<xs:attribute name="ref" type="xs:boolean" />

An element that has sml:ref="true" MUST be treated as a reference element, i.e., its child elements MAY contain one or more reference schemes. This mechanism enables schema-less identification of reference elements, i.e., reference elements can be identified without relying on PSVI.

The following example illustrates the use of sml:ref. Consider the following schema fragment:

<xs:element name="EnrolledCourse">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Name" type="xs:string"/>
        <xs:element name="Grade" type="xs:string"/>
        <xs:any namespace="##any" minOccurs="0"
                maxOccurs="unbounded" processContents="lax"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>
</xs:element>

<xs:complexType name="StudentType">
    <xs:sequence>
      <xs:element name="ID" type="xs:string"/>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="EnrolledCourses" minOccurs="0">
        <xs:complexType>
          <xs:sequence>
            <xs:element ref="tns:EnrolledCourse"
                        maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
</xs:complexType>

The schema definition in the above example is SML agnostic and does not make use of any SML attributes, elements, or types. The EnrolledCourse element, however, has an open content model and this can be used to mark instances of EnrolledCourse as reference elements as shown below:

<Student xmlns="http://www.university.example.org/ns"
         xmlns:sml="http://www.w3.org/2007/08/sml"
         xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <ID>1000</ID>
  <Name>John Doe</Name>
  <EnrolledCourses>
    <EnrolledCourse sml:ref="true">
      <Name>PHY101</Name>
      <Grade>A</Grade>
      <sml:uri>
        http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
        xpointer(/u:Courses/u:Course[u:Name='PHY101'])
      </sml:uri>
      <wsa:EndpointReference>
        <wsa:Address>http://www.university.example.org</wsa:Address>
        </wsa:EndpointReference>
    </EnrolledCourse>
    <EnrolledCourse sml:ref="false">
      <Name>MAT100</Name>
      <Grade>B</Grade>
      <sml:uri>
        http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
        xpointer(/u:Courses/u:Course[u:Name='MAT100'])
      </sml:uri>
    </EnrolledCourse>
    <EnrolledCourse>
      <Name>SocialSkills</Name>
      <Grade>F</Grade>
    </EnrolledCourse>
  </EnrolledCourses>
</Student>

The first EnrolledCourse element in the above example is a reference element since it specifies sml:ref="true". Assuming that references are represented using URI and EPR schemes, it has two representations of the reference to the element for course  PHY101. The second and third EnrolledCourse elements are not reference elements; the second element specifies sml:ref="false" and the third element does not specify the sml:ref attribute. Note that the second element has a child element that contains a reference scheme referring to course MAT100, but this reference will be ignored since sml:ref="false" for the second element.

A reference element MAY be empty or have a null value provided that this is allowed by the element's schema. For example, consider the following variation of the EnrolledCourse element declaration:

<xs:element name="EnrolledCourse" nillable="true">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Name" type="xs:string"/>
        <xs:element name="Grade" type="xs:string"/>
        <xs:any namespace="##any" minOccurs="0"
                maxOccurs="unbounded" processContents="lax"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>
</xs:element>

The above declaration allows null values for instances of EnrolledCourse. Thus, an EnrolledCourse reference element can have null value as shown in the following example (the first EnrolledCourse element has null value):

<Student xmlns="http://www.university.example.org/ns"
         xmlns:sml="http://www.w3.org/2007/08/sml"
         xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <ID>1000</ID>
  <Name>John Doe</Name>
  <EnrolledCourses>
    <EnrolledCourse sml:ref="true" xsi:nil="true"/>
    <EnrolledCourse sml:ref="false">
      <Name>MAT100</Name>
      <Grade>B</Grade>
      <sml:uri>
        http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
        xpointer(/u:Courses/u:Course[u:Name='MAT100'])
      </sml:uri>
    </EnrolledCourse>
    <EnrolledCourse>
      <Name>SocialSkills</Name>
      <Grade>F</Grade>
    </EnrolledCourse>
  </EnrolledCourses>
</Student>

SML also supports several schema-based constraints on reference elements. The sml:refType type has been defined to allow model authors to make use of these schema-based constraints in their model's schema. The definition of sml:refType fixes the value of sml:ref to true, and hence all elements of type sml:refType are reference elements.   The sml:refType is defined as follows:

<xs:complexType name="refType" sml:acyclic="false">
   <xs:sequence>
     <xs:any namespace="##any" minOccurs="0"
             maxOccurs="unbounded"
             processContents="lax"/>
   </xs:sequence>
   <xs:attribute ref="sml:ref" use="required"
                 fixed="true" />
   <xs:anyAttribute namespace="##any"
                 processContents="lax"/>
</xs:complexType>

Note that the above definition allows elements and attributes from any namespace to occur in an element whose type is sml:refType. Thus, a scheme for reference elements can be implemented by defining an XML namespace for the scheme, and references can be represented in this scheme by nesting element and attribute instances from this namespace as attributes and children of sml:refType elements.

The following example illustrates the use of sml:refType:

<xs:element name="EnrolledCourse" type="sml:refType" sml:targetType="tns:CourseType"/>
<xs:complexType name="StudentType">
        <xs:sequence>
            <xs:element name="ID" type="xs:string"/>
            <xs:element name="Name" type="xs:string"/>
            <xs:element name="EnrolledCourses" minOccurs="0">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element ref="tns:EnrolledCourse"
                                    maxOccurs="unbounded"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
</xs:complexType>

The EnrolledCourse element declaration is of type sml:refType which marks it as a document reference, and this element declaration is used in StudentType to reference the elements corresponding to the courses in which a student is enrolled.

Examples of the use of sml:refType for EnrolledCourse are found in the section 3.2 Reference Schemes.  This section demonstrates the use of the URI and EPR schemes to define the reference.

3.1.1 Reference Definitions

3.1.1.1 SML Reference

An element that has either sml:ref="true" or sml:ref="1" specified.

Although either sml:ref="true" or sml:ref="1" can be used to identify an SML reference element, for the sake of brevity and consistency, the rest of this specification uses sml:ref="true" in examples and other definitions.

3.1.1.2 Null Reference

A reference element with xsi:nil="true" or no content, provided that it is allowed by the element's declaration.

3.1.1.3 Dangling Reference

A non-null reference whose target does not exist.

3.1.2 Reference Semantics

3.1.2.1 At Most One Target

Every reference element MUST target (or resolve to) at most one element in a model. Dangling references are allowed in SML; therefore it is possible that the target of a reference does not exist in a model. It is an error if a reference element targets more than one element in a model.

If a single reference element has multiple representations, every representation MUST target the same element.  Validators MAY check this condition.

3.1.2.2 Multiple References  

An element in a document MAY be targeted by multiple reference elements. These reference elements may use different schemes and/or be expressed in different ways.  

3.1.2.3 Empty or Null References

A model validator MUST not perform the SML validation associated with references for a null reference element.

3.1.2.4 deref() XPath Extension Function

Each model validator MUST provide an implementation of the deref() XPath extension function that is capable of resolving references expressed in the model validator's chosen scheme(s). This function takes a node-set of elements and returns a node-set consisting of element nodes corresponding to the elements referenced by the input node set.  In particular, for each node R in the input node set the output node set contains at most one element node.

  • The output node set contains one element node for R provided that all of the following conditions are true

    • sml:ref ="true" for R

    • R contains at least one reference scheme that is understood by the implementation

    • The reference targets a single element in some document in the model

  • The output node set contains no element node corresponding to R if any of the following conditions is true

    • the target of R is not in the model

    • R is an empty or null reference

    • R does not contain any reference scheme that is understood by the implementation

    • sml:ref is not specified for R

    • sml:ref is specified for R and its value is neither "true" nor "1".

3.2 Reference Schemes

A reference MAY be represented by using a variety of schemes, and SML does not mandate the use of any specific schemes. Uniform Resource Identifiers (URIs) [IETF RFC 3986] and endpoint references (EPRs) [WS-Addressing Core] are two common schemes for referencing resources. Although SML does not require the use of either scheme, it does define how a reference MUST be represented using the URI scheme and the EPR scheme.

3.2.1 URI Scheme

References that are represented using the URI scheme MUST be implemented by using the sml:uri global element as a child of reference elements, i.e., elements for which sml:ref="true".  More precisely, if a model validator chooses to represent references using the URI scheme,

  • It MUST represent each reference using an instance of the sml:uri global element declaration as a child of the reference element.  

  • It MUST treat each instance of  the sml:uri global element declaration, whose parent element is a reference element, as a reference represented in the URI scheme.

For example, if the reference element in 3.1 References is represented using the URI scheme, an instance of EnrolledCourse will appear as follows:

<EnrolledCourse xmlns="http://www.university.example.org/ns"  sml:ref="true">
  <sml:uri>http://www.university.example.org/someUri</sml:uri>
</EnrolledCourse>

where http://www.university.example.org/someUri is a valid URI as defined in [IETF RFC 3986].

Suppose that a model has the following documents, and each document has an associated URI:

DocumentURI
Course PHY101http://www.university.example.org/Universities/MIT/Courses/PHY101.xml
Course MAT200http://www.university.example.org/Universities/MIT/Courses/MAT200.xml
Student 1000http://www.university.example.org/Universities/MIT/Students/1000.xml
Student 1001http://www.university.example.org/Universities/MIT/Students/1001.xml

The following is a sample instance document for Student 1000 where the references are represented in the URI scheme:

<Student xmlns="http://www.university.example.org/ns">
  <ID>1000</ID>
  <Name>John Doe</Name>
  <EnrolledCourses>
    <EnrolledCourse sml:ref="true">
      <sml:uri>http://www.university.example.org/Universities/MIT/Courses/PHY101.xml</sml:uri>
    </EnrolledCourse>
    <EnrolledCourse sml:ref="true">
      <sml:uri>http://www.university.example.org/Universities/MIT/Courses/MAT200.xml</sml:uri>
    </EnrolledCourse>
  </EnrolledCourses>
</Student>
3.2.1.1 Fragment Identifier

 Fragment identifiers in references that are represented using the URI scheme MUST use the following XPointer [XPointer] profile: Only two schemes – xmlns() [xmlns() Scheme] and xpointer() [xpointer() Scheme] – are supported.

  • The expression specified for the xpointer scheme MUST be a restricted XPath 1.0 [XPath 1.0] expression that MUST resolve to at most one element node. In particular, this expression MUST NOT contain

    • the union ("|") operator defined for XPath 1.0

    • point() and range() node tests defined for the xpointer() scheme

  • This expression can only use the functions defined in the XPath 1.0 core function library [XPath 1.0]. It MUST NOT use the smlfn:deref function and/or the following functions defined for xpointer() scheme [xpointer() Scheme]:

    • range-to

    • string-range

    • range

    • range-inside

    • start-point

    • end-point

    • here

    • origin

The following example illustrates the use of xpointer fragments. Consider the case where all courses offered by MIT are stored in a single XML document – Courses.xml – whose URI is  http://www.university.example.org/Universities/MIT/Courses.xml. In this case, the element inside Courses.xml that corresponds to the course PHY101 can be referenced as follows (assuming that Coursesis the root element in Courses.xml)

<Student xmlns="http://www.university.example.org/ns">
  <ID>1000</ID>
  <Name>John Doe</Name>
  <EnrolledCourses>
    <EnrolledCourse sml:ref="true">
      <sml:uri>
        http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
        xpointer(/u:Courses/u:Course[u:Name='PHY101'])
      </sml:uri>
    </EnrolledCourse>
  </EnrolledCourses>
</Student>

A reference element can also be used to reference an element in its own document. To see this consider the following instance document

<University xmlns="http://www.university.example.org/ns">
  <Name>MIT</Name>
  <Courses>
    <Course>
      <Name>PHY101</Name>
    </Course>
    <Course>
      <Name>MAT200</Name>
    </Course>
  </Courses>
  <Students>
    <Student>
      <ID>123</ID>
      <Name>Jane Doe</Name>
      <EnrolledCourses>
        <EnrolledCourse sml:ref="true">
          <sml:uri>
            #xmlns(u=http://www.university.example.org/ns)
            xpointer(/u:University/u:Courses/u:Course[u:Name='MAT200']
          </sml:uri>
        </EnrolledCourse>
      </EnrolledCourses>
    </Student>
  </Students>
</University>

Here, the EnrolledCourse element for the student Jane Doe references the Course element for MAT200 in the same document.

3.2.2 EPR Scheme

References that are represented using the EPR scheme MUST be implemented by using instances of  wsa:EndpointReference global element declaration [WS-Addressing Core] as  child  elements of reference elements. The following example illustrates how the EnrolledCourse reference that references course PHY101 in MIT university can be represented using the EPR scheme:

[Example Under Construction]

<EnrolledCourse xmlns="http://www.university.example.org/ns" sml:ref="true">
  <wsa:EndpointReference
       xmlns:u="http://www.university.example.org/schema">
    <wsa:Address>http://www.university.example.org</wsa:Address>
  </wsa:EndpointReference>
</EnrolledCourse>

3.3 Constraints on References

SML supports the following attributes for expressing constraints on reference elements.

Table 3-1. Attributes
NameDescription
sml:acyclic Used to specify whether cycles are supported for a reference.
sml:targetElement Used to constrain the name of the reference's target element.
sml:targetType Used to constrain the type of the reference's target element.
sml:targetRequired Used to specify that a reference's target element is required to be present in the model.

These attributes MUST be supported in the following specified locations only in an SML model:

  • These attributes MUST be supported in XML Schema documents.

  • These attributes MUST be supported for element declarations of type sml:refType or a derived type of sml:refType.  Note that this specification specifies sml:acyclic="false" for type sml:refType.

3.3.1 sml:acyclic

Model validators that conform to this specification MUST support the sml:acyclic attribute on derived types of sml:refType. This is a boolean attribute and its value can be either true or false. Let R be a derived type of sml:refType. If sml:acyclic="true" is specified for R, then R is an acyclic reference type, i.e., instances of R MUST NOT create cycles in any model. More precisely, the directed graph whose nodes are documents that contain the source or target elements for instances of R, and whose edges are instances of R (an edge is directed from the document containing the source element to the document containing the target element),  must be acyclic.

A cyclic reference type can be used to derive cyclic or acyclic reference types, but all derived types of an acylic reference type are acyclic. Model validators that conform to this specification MUST enforce the following:

  • If CR is a cyclic reference type and DCR is a derived type of CR, then DCR is an acyclic reference if sml:acyclic="true" is specified for DCR . Otherwise, DCR is a cyclic reference

  • If AR is an acyclic reference type and DAR is a derived type of AR, then sml:acyclic="true" holds for DAR even if the sml:acyclic attribute is not explicitly specified for DAR . It is an error for DAR to specify sml:acyclic="false"

3.3.2 Constraints on Targets

SML supports three attributes: sml:targetElement, sml:targetRequired, and sml:targetType, for constraining the target of a reference. These three attributes are collectively called sml:target* attributes and they MUST be supported on global and local element declarations. Model validators that conform to this specification MUST enforce the following:

If one/more of sml:target* attributes are specified (either explicitly or by default) for a particle P in a complex-type definition CT, then all particles in CT that have the same name as P must specify the same set of sml:target* attributes as P and these attributes must have the same values as those specified for P.

In particular, all of the following must be enforced:

  • If sml:targetElement="ns:GTE" for P then sml:targetElement="ns:GTE" for all particles in CT that have the same name as P

  • If sml:targetRequired="true" for P then sml:targetRequired="true" for all particles in CT that have the same name as P

  • If sml:targetRequired="false" for P then sml:targetRequired="false" for all particles in CT that have the same name as P

  • If sml:targetType="ns:T" for P  then sml:targetType="ns:T" for all particles in CT that have the same name as P

The above conditions on the use of sml:target* attributes have been defined to reduce the implementation burden  on  model validators for verifying  that the use of sml:target* attributes is consistent across derivation by restriction. These conditions enable model validators to find the restricted particle for a restricting particle using a simple name match when sml:target* attributes are specified for these particles.  In the absence of the above conditions, it is extremely difficult for SML validators to verify consistent use of sml:target* attributes across a base type and its restricted derived type. In order to verify consistent use of an sml:target* attribute on a restricted particle in the base type and its restricting particle in a restricted derived type, it is necessary to connect the particles in the derived type with  those from the restricted base type. However, this level of support is not provided by most XML Schema frameworks; thus most SML validators would otherwise need to duplicate large parts of XML Schema's compilation logic to verify consistent usage of sml:target* attributes across derivation by restriction.    

3.3.2.1 sml:targetElement

Model validators that conform to this specification MUST support the sml:targetElement attribute on element declarations whose type is sml:refType or a derived type of sml:refType. The value of this attribute MUST be the qualified name of some global element declaration. Let sml:targetElement="ns:GTE" for some element declaration E. Then each element instance of E MUST reference an element that is an instance of ns:GTE or an instance of some global element declaration in the substitution group hierarchy whose head is ns:GTE. If a target element constraint is specified for a global element declaration G then it continues to apply to all global element declarations in the substitution group hierarchy whose head is G. However, a global element declaration in G's substitution group can specify a target element constraint that refines the constraint defined for G. In particular, model validators that conform to this specification MUST enforce the following:

  • If sml:targetElement="ns:GTE" is specified for G, and SG is a global element declaration that specifies G as the value of its xs:substitutionGroup attribute, then

    • if  sml:targetElement is specified for SG then its value MUST  be ns:GTE or the name of a global element declaration in the substitution group hierarchy whose head is ns:GTE

    • if sml:targetElement is not specified for SG , then sml:targetElement="ns:GTE" holds for SG by default.

If a target element constraint is specified for a particle P in some type B, then it continues to apply to each particle PR that is a valid restrictions of P where PR is defined in some restricted derived type of B (see " Schema Component Constraint: Particle Valid (Restriction) ", section 3.9.6, "Constraints on Particle Schema Components", [XML Schema Datatypes] for XML Schema's definition of valid restrictions). However, PR can specify a target element constraint that refines the constraint defined for P.  In particular, model validators that conform to this specification MUST enforce the following:

  • If sml:targetElement="ns:GTE" is specified for P and sml:targetElement is specified for PR , then the value of sml:targetElement for PR must be ns:GTE or the name of a global element declaration in the substitution group hierarchy whose head is ns:GTE. If sml:targetElement is not specified for PR , then sml:targetElement="ns:GTE" holds for PR by default.

3.3.2.2 sml:targetRequired

Model validators that conform to this specification MUST support the   sml:targetRequired attribute   on element declarations whose type is sml:refType or a derived type of sml:refType. If  sml:targetRequired ="true" for an element declaration E, then each element instance of E MUST target some element in the model, i.e., no instance of E can be null, empty, or contain a dangling reference. Otherwise, instances of E can be empty, null, or contain dangling references. If this attribute is not specified, then its value is assumed to be "false".

Model validators that conform to this specification MUST enforce the following:

  • If the sml:targetRequired  attribute is specified for a global element declaration G then the specified value applies by default to each global element declaration SG in the substitution group hierarchy whose head is G unless the sml:targetRequired  attribute is specified for SG .

  • If sml:targetRequired="true" is specified for a global element declaration G then sml:targetRequired="false"  MUST NOT be specified for any element declaration in the substitution group hierarchy whose head is G.

  • If sml:targetRequired attribute is  specified for a particle  P in some type B, then the specified value applies by default to  to each particle PR that is a valid restriction of P unless the sml:targetRequired attribute is specified for PR (see " Schema Component Constraint: Particle Valid (Restriction) ", section 3.9.6, "Constraints on Particle Schema Components", [XML Schema Datatypes] for XML Schema's definition of valid restrictions).

  • If sml:targetRequired="true" for a particle P then sml:targetRequired="false"  MUST NOT be specified for any particle PR that is a valid restriction of P.  

3.3.2.3 sml:targetType

The sml:targetType attribute MUST be supported on element declarations whose type is sml:refType or a derived type of sml:refType. The value of this attribute MUST be the qualified name of some type definition. Let sml:targetType="ns:T"  for some element declaration E. Then each element instance of E MUST reference an element whose type is ns:T or a derived type of ns:T.

If a target type constraint is specified for a global element declaration G then it continues to apply to all global element declarations in the substitution group hierarchy whose head is G. However, a global element declaration in G's substitution group can specify a target type constraint that refines the constraint defined for G. In particular, model validators that conform to this specification MUST enforce the following:

  • If sml:targetType="ns:T" is specified for G, and SG is a global element declaration that specifies G as the value of its xs:substitutionGroup attribute, then

    • if the sml:targetType attribute is specified for SG the its value    MUST be either ns:T or the name of some derived type of ns:T

    • if sml:targetType is not specified for SG , then sml:targetType="ns:T" holds for SG by default

If the target type constraint is specified for a particle P in some type B, then it continues to apply to each particle PR that is a valid restriction of P where PR is defined in some restricted derived type of B. However, PR can specify a target type constraint that refines the constraint defined for P. In particular, model validators that conform to this specification MUST enforce the following:

  • If sml:targetType="ns:T" is specified for P and sml:targetType is specified for PR then the value of the sml:targetType for PR must be ns:T or the name of some derived type of ns:T. If sml:targetType is not specified for PR , then sml:targetType="ns:T" holds for PR by default

3.4 Identity Constraints

XML Schema supports the definition of key, unique, and key reference constraints through xs:key, xs:unique, and xs:keyref elements. However, the scope of these constraints is restricted to a single document. SML defines analogs for these constraints, whose scope extends   to multiple documents by allowing them  to traverse inter-document references.

Model validators that conform to this specification MUST support the following elements for defining identity constraints across references:

NameDescription
sml:key Similar to xs:key except that the selector and field XPath expression can use smlfn:deref function
sml:unique Similar to xs:unique except that the selector and field XPath expression can use smlfn:deref function
sml:keyref Similar to xs:keyref except that the selector and field XPath expression can use smlfn:deref function

The syntax and semantics of the above elements are according to Section 3.11.2 of the XML Schema specification [XML Schema Datatypes], except for the following:

  • If an SML identity constraint needs to be specified for an element declaration E, then it MUST be defined in the xs:annotation/xs:appinfo descendant element for the xs:element element for E

  • An SML identity constraint that is specified for an element declaration  E can reuse the definition of an SML identity constraint ID' specified for some other element declaration E' by specifying the name of E' as the value of its ref attribute. In particular,

    • If the ref attribute is specified for an SML identity constraint element that is specified for an element declaration E, then the value of ref attribute MUST NOT be name of any other SML identity constraint element specified for E.

    • If the ref attribute is specified for an sml:key element, then the value of ref attribute MUST be name of another SML key constraint

    • If the ref attribute is specified for an sml:unique element then the value of the ref attribute MUST be name of another SML unique constraint

    • If the ref attribute is specified for an sml:keyref element then the value of the ref attribute MUST be name of another SML keyref constraint

    • If the ref attribute is specified for an SML identity constraint, then the name attribute MUST NOT be specified

    • If the ref attribute is specified for an SML identity constraint, then the selector and field child elements MUST NOT be specified

  • If an SML identity constraint is specified for an element declaration E, then this constraint is applicable to all instances of E in a model, i.e., the identity constraint MUST be satisfied for each instance of E in a valid model

  • The sml:selector XPath expression MUST conform to the following extended BNF

Selector ::= Path ( '|' Path)*
Path ::= ('.//')? Step ( '/' Step)* | DerefExpr
DerefExpr ::= (NCName ':')? 'deref(' Step (/Step)* ')'  ('/'Step)* |
              (NCName ':')? 'deref(' DerefExpr ')' (/Step)*
Step::= '.' | NameTest
NameTest ::= QName |'*' | NCName ':' '*'
  • The sml:field XPath expression MUST conform to the BNF given above for the selector XPath expression with the following modification

Path::= ('.//')?  ( Step '/')* ( Step | @NameTest ) |
        DerefExpr ('/' @NameTest)?
  • Each SML identity constraint that is specified for a global element declaration G MUST be treated as if it is specified by default for all global element declarations SG that are in the substitution group hierarchy whose head is G

  • Each SML identity constraint that is specified for a particle P in a complex-type definition CT MUST be treated as if it is specified by default for all particles PR in restricted derived types of CT that are a valid restriction of P

  • If one/more SML identity constraints are specified (either explicitly or by default) for a particle P in a complex-type definition CT, then all particles in CT that have the same name as P MUST specify the same set of identity constraints as P. This rule is defined to reduce the implementation burden for model validators. It facilitates the matching of restricting and restricted particles using their names, and avoids the replication of large parts of XML Schema's compilation logic for this purpose.

3.4.1 University Example

The following example will be used to illustrate the sml:key, sml:unique, and sml:keyref constraints across references.

<xs:element name="Student"
                   type="sml:refType"
                   sml:targetType="tns:StudentType"/>
<xs:element name="Course"
                   type="sml:refType"
                   sml:targetType="tns:CourseType"/>
  
<xs:complexType name="UniversityType">
  <xs:sequence>
            <xs:element name="Name" type="xs:string"/>
            <xs:element name="Students" minOccurs="0">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element ref="tns:Student" maxOccurs="unbounded"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            <xs:element name="Courses" minOccurs="0">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element ref="tns:Course" maxOccurs="unbounded"/>                              
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
  </xs:sequence>
</xs:complexType>

        <xs:element name="EnrolledStudent"
                    type="sml:refType"
                    sml:targetType="tns:StudentType"/>
        <xs:element name="EnrolledCourse"
                    type="sml:refType"
                    sml:targetType="tns:CourseType"/>

<xs:complexType name="StudentType">
          <xs:sequence>
            <xs:element name="ID" type="xs:string"/>
            <xs:element name="SSN" type="xs:string" minOccurs="0"/>
            <xs:element name="Name" type="xs:string"/>
            <xs:element name="EnrolledCourses" minOccurs="0">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element ref="tns:EnrolledCourse"
                                    maxOccurs="unbounded"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
          </xs:sequence>
</xs:complexType>

<xs:complexType name="CourseType">
          <xs:sequence>
            <xs:element name="Name" type="xs:string"/>
            <xs:element name="EnrolledStudents" minOccurs="0">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element ref="tns:EnrolledStudent"
                                    maxOccurs="unbounded"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
          </xs:sequence>
</xs:complexType>

3.4.2 sml:key and sml:unique

XML Schema supports key and uniqueness constraints through xs:key and xs:unique, but these constraints can only be specified within a single XML document. The sml:key and sml:unique elements  support the specification of key and uniqueness constraints across documents.  We'll use the UniversityType (see 3.4.1 University Example) definition to illustrate this concept. It is reasonable to expect that each student in a university must have a unique identity, and this identity must be specified. This can be expressed as follows:

<xs:element name="University" type="tns:UniversityType">
        <xs:annotation>
            <xs:appinfo>
                <sml:key name="StudentIDisKey">
                   <sml:selector xpath="smlfn:deref(tns:Students/tns:Student)/tns:ID"/>
                   <sml:field xpath="."/>  
                </sml:key>  
            </xs:appinfo>
        </xs:annotation>
</xs:element>

The sml:key and sml:unique constraints are similar but not the same. sml:key requires that the specified fields must be present in instance documents and have unique values, whereas sml:unique simply requires the specified fields to have unique values but does not require them to be present in instance documents.  Thus keys imply uniqueness, but uniqueness does not imply keys.  For example, students in a university must have a unique social security numbers, but the university may have foreign students who do not possess this number. This constraint can be specified as follows:

<xs:element name="University" type="tns:UniversityType">
        <xs:annotation>
            <xs:appinfo>
                <sml:unique name="StudentSSNisUnique">
                   <sml:selector xpath="smlfn:deref(tns:Students/tns:Student)"/>
                   <sml:field xpath="tns:SSN"/>  
                </sml:unique>  
            </xs:appinfo>
        </xs:annotation>
</xs:element>

The sml:key and sml:unique  constraint are always specified in the context of a scoping element. In the above example, the University element declaration is the context for the key and unique constraints.

The following example illustrates the use of the ref attribute in an SML identity constraint:

<xs:element name="PrivateUniversity" type="tns:UniversityType">
        <xs:annotation>
            <xs:appinfo>
                <sml:unique ref="tns:StudentSSNisUnique"/>
            </xs:appinfo>
        </xs:annotation>
</xs:element>

In the above example, the PrivateUniversity element declaration specifies the StudentSSNisUnique unique constraint by referencing its definition in the University element declaration.

3.4.3 sml:keyref

XML Schema supports key references through xs:keyref to ensure that one set of values is a subset of another set of values within an XML document. Such constraints are similar to foreign keys in relational databases. Key references in XML Schema are only supported within a single XML document. The sml:keyref element allows key references to be specified across XML documents, and can be used to scope references to point to elements within a valid range. The following example uses sml:keyref to capture the requirement that courses in a university can only enroll students from the same university:

<xs:element name="University" type="tns:UniversityType">
        <xs:annotation>
            <xs:appinfo>
                <sml:key name="StudentIDisKey">
                   <sml:selector xpath="smlfn:deref(tns:Students/tns:Student)"/>
                   <sml:field xpath="tns:ID"/>  
                </sml:key>  
                <sml:keyref name="CourseStudents" refer="tns:StudentIDisKey">
                   <sml:selector xpath="smlfn:deref(
                                        smlfn:deref(tns:Courses/tns:Course)/
                                        tns:EnrolledStudents/tns:EnrolledStudent)"/>
                   <sml:field xpath="tns:ID"/>
                </sml:keyref>
            </xs:appinfo>
        </xs:annotation>
</xs:element>

The above constraint specifies that for a university, the set of IDs of students enrolled in courses is a subset of the set of IDs of students in a university. In particular, the selector and field elements in StudentIDisKey key constraint identify the set of IDs of students in a university, and the selector and field elements in CourseStudents key reference constraint identify the set of IDs of students enrolled in courses.  

4. Rules

XML Schema supports a number of built-in grammar-based constraints but it does not support a language for defining arbitrary rules for constraining the structure and content of documents. Schematron [ISO/IEC 19757-3] is an ISO/IEC standard for defining assertions concerning a set of XML documents. SML uses a profile of the Schematron schema to add support for user-defined constraints. SML uses XPath1.0, augmented with the smlfn:deref()  extension function, as its constraint language. Model validators that conform to this specification are REQUIRED to support and evaluate XPath 1.0 expressions augmented with the smlfn:deref() function in the body of Schematron constraints. This section assumes that the reader is familiar with Schematron concepts; the Schematron standard is documented in [ISO/IEC 19757-3] and [Introduction to Schematron, Improving Validation with Schematron] are good tutorials on an older version of Schematron.

User-defined constraints can be specified using the sch:assert and sch:report elements from Schematron.  The following example uses sch:assert elements to specify two constraints:

<xs:simpleType  name="IPAddressVersionType">
       <xs:restriction base="xs:string" >
           <xs:enumeration value="V4" />
           <xs:enumeration value="V6" />
        </xs:restriction>
</xs:simpleType>

<xs:complexType name="IPAddress">
        <xs:annotation>
            <xs:appinfo>
                <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
                   <sch:ns prefix="tns" uri="urn:IPAddress" />
                   <sch:pattern id="Length">
                      <sch:rule context=".">
                         <sch:assert test="tns:version != 'V4' or count(tns:address) = 4">
                              A v4 IP address must have 4 bytes.
                         </sch:assert>
                         <sch:assert test="tns:version != 'V6' or count(tns:address) = 16">
                              A v6 IP address must have 16 bytes.
                         </sch:assert>
                      </sch:rule>
                   </sch:pattern>
                </sch:schema>            
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="version" type="tns:IPAddressVersionType" />
            <xs:element name="address" type="xs:byte" minOccurs="4" maxOccurs="16" />
        </xs:sequence>
</xs:complexType>

A Schematron pattern embedded in the xs:annotation/xs:appinfo element for a complex type definition or an element declaration is applicable to all instances of the complex type or element. In the above example, the pattern Length is applicable for all elements whose type is IPAddress or a derived type of IPAddress. A pattern can have one or more rules, and each rule specifies a context expression using the context attribute. The value of the context attribute is an XPath expression that is evaluated in the context of each applicable element, and results in an element node set for which the assert and report test expressions defined in the rule are evaluated. In the above example context="." therefore the two assert expressions are evaluated in the context of each applicable element, i.e., each element of type IPAddress.  The test expression for an assert is a boolean expression, and the assert is violated (or fires) if its test expression evaluates to false.  For example, the following XML document violates the assert that requires an IPv6 address to have sixteen address bytes

<myIPAddress xmlns="urn:IPAddress">
  <version>v6</version>
  <address>100</address>
  <address>200</address>
  <address>10</address>
  <address>1</address>
  <address>10</address>
  <address>1</address>
</myIPAddress>

In general, a rule element can include multiple assert and report elements. A report also specifies a test expression, just like an assert. However, a report is violated (or fires) if its test expression evaluates to true. Thus, an assert can be converted to a report by simply negating its test expression. The following example uses report elements to represent the IP address constraints of the previous example:

    <xs:simpleType  name="IPAddressVersionType">
        <xs:restriction base="xs:string">
           <xs:enumeration value="V4"/>
           <xs:enumeration value="V6"/>
        </xs:restriction>
    </xs:simpleType>

    <xs:complexType name="IPAddress">
        <xs:annotation>
            <xs:appinfo>
                <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
                    <sch:ns prefix="tns" uri="urn:IPAddress" />
                    <sch:pattern id="Length">
                        <sch:rule context=".">
                            <sch:report test="tns:version = 'V4' and count(tns:address)!= 4">
                                A v4 IP address must have 4 bytes.
                            </sch:report>
                            <sch:report test="tns:version = 'V6' and count(tns:address) != 16">
                                A v6 IP address must have 16 bytes.
                            </sch:report>
                        </sch:rule>
                    </sch:pattern>
                </sch:schema>            
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="version" type="tns:IPAddressVersionType" />
            <xs:element name="address" type="xs:byte" minOccurs="4" maxOccurs="16" />
        </xs:sequence>
    </xs:complexType>

If an assert or report is violated, then the violation must be reported during model validation together with the specified message.  Model validation must evaluate each Schematron pattern for all of its applicable elements contained in the model.  

The message can include substitution strings based on XPath expressions. These can be specified using the sch:value-of element. The following example uses the sch:value-of element to include the number of specified address bytes in the message:

     <sch:assert test="tns:version != 'v4' or count(tns:address) = 4">
          A v4 IP address must have 4 bytes instead of the specified
          <sch:value-of select="string(count(tns:address))"/> bytes.
     </sch:assert>

In addition to being embedded in complex type definitions, constraints can also be embedded in global element declarations. Such constraints are evaluated for each instance element corresponding to the global element declaration. Consider the following example:

<xs:element name="StrictUniversity" type="tns:UniversityType">
    <xs:annotation>
        <xs:appinfo>
            <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
                <sch:ns prefix="u" uri="http://www.university.example.org/ns" />
                <sch:ns prefix="smlfn"  
                        uri="http://www.w3.org/2007/08/sml-function"/>
                <sch:pattern id="StudentPattern">
                    <sch:rule context="smlfn:deref(u:Students/u:Student)">
                        <sch:assert test="starts-with(u:ID,'99')">
                            The specified ID <sch:value-of select="string(u:ID)"/>
                             does not begin with 99
                        </sch:assert>
                        <sch:assert test="count(u:Courses/u:Course)>0">
                            The student <sch:value-of select="string(u:ID)"/> must be enrolled
                            in at least one course
                        </sch:assert>
                    </sch:rule>
                </sch:pattern>
             </sch:schema>
         </xs:appinfo>
    </xs:annotation>
</xs:element>

The constraints defined in StudentPattern are applicable to all element instances of the StrictUniversity global element declaration. For each StrictUniversity element, the XPath expression specified as the value of the context attribute is evaluated to return a node set, and the test expressions for the two asserts are evaluated for each node in this node set.  The context expression for the rule returns a node set consisting of all Student elements referenced by an instance of StrictUniversity, and the test expressions for the two asserts are evaluated for each element node in this node set.  Thus, these two asserts verify the following conditions for each instance of StrictUniversity

Model validators that conform to this specification  MUST behave as follows:  

Model validators that conform to this specification MUST provide a mechanism to support binding of Schematron patterns that are authored in separate documents, i.e., not embedded in schema definition, to a set of documents in a model. The mechanism for binding such Schematron patterns to a set of documents in a model is implementation-dependent and hence outside the scope of this specification.  The following example shows the constraints for StrictUniversity expressed in a separate document:

<?xml version="1.0" encoding="utf-8" ?>
        <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
            <sch:ns prefix="u" uri="http://www.university.example.org/ns" />
            <sch:ns prefix="smlfn" uri="http://www.w3.org/2007/08/sml-function"/>
            <sch:pattern id="StudentPattern">
                <sch:rule context="smlfn:deref(u:Students/u:Student)">
                    <sch:assert test="starts-with(u:ID,'99')">
                        The specified ID <sch:value-of select="string(u:ID)"/>
                        does not begin with 99
                    </sch:assert>
                    <sch:assert test="count(u:Course/u:Courses)>0">
                        The student <sch:value-of select="string(u:ID)"/> must be enrolled
                        in at least one course
                    </sch:assert>
                </sch:rule>
            </sch:pattern>
</sch:schema>

The binding of the StudentPattern pattern to instances of StrictUniversity element is implementation-dependent and hence outside the scope of this specification.

4.1 Localization of Error Messages

4.1.1 smlerr:localizationid

Localization of the natural-language error messages, which provide details about asserts and reports, MAY be supported by model validators that conform to this specification. Such model validators MAY support the use of smlerr:localizationid attribute on sch:report and sch:assert to specify the identity of the resource containing the localized versions of the natural-language error message.

Model validators that conform to this specification but do not support smlerr:localizationid attribute MUST ignore all smlerr:localizationid attributes in a model; they MUST NOT treat the model as invalid just because it contains smlerr:localizationid attributes.

The mechanisms for mapping values of smlerr:localizationid to the corresponding localization resources are implementation-dependent and hence outside the scope of this specification.

4.2 Schematron Profile

SML supports a conforming profile of Schematron. All elements and attributes are supported.  

4.2.1 Limited Support

If the queryBinding attribute is specified, then its value MUST be set to "xpath1.0"

5. Structured XML Output from Schematron Rules

Schematron has rich support for natural-language error and diagnostic messages that provide details about failed assertions. As per the Schematron specification the content of the sch:assert, sch:report, and the optional sch:diagnostic elements should be natural language assertions or messages. To facilitate machine processable output from the evaluation of Schemtron rules, this specification extends Schematron by adding support for structured XML output that provides details about failed assertions. This structured XML data can be consumed by an application to perform some application-specific tasks required to handle a failed assertion. This is an OPTIONAL feature and model validators that conform to this specification are not REQUIRED to support it. Model validators that conform to this specification but do not support smlerr:output element MUST ignore all smlerr:output elements in a model; they MUST NOT treat the model as invalid just because it contains smlerr:output elements.

5.1 smlerr:output

This element is used to specify the structured XML output for one/more failed assertions. It is supported as a child of the sch:rule element. An sch:rule element can contain multiple smlerr:output elements. The schema definition for smlerr:output is as follows:

  <xs:element name="output" type="smlerr:outputType"/>

  <xs:complexType name="outputType">
      <xs:attribute name="id" type="xs:ID"
                    use="required"/>
      <xs:attribute name="applicationUri" type="xs:anyURI"
                  use="optional"/>
      <xs:attribute name="expression" type="xs:string" use="required"/>
  </xs:complexType>

id = a required attribute that defines the identity of an smlerr:output element. This identity is used by an assert and/or report element to specify that the expression specified in the expression attribute of the smlerr:output element must be evaluated to generate structured XML when the assert/report fires. This identity is specified on one or more assert and/or report elements' smlerr:outputids attribute. Each time such an assert or report fires, the smlerr:output element's expression attribute is evaluated to generate structured XML.   

applicationUri = an optional attribute that specifies the identity of the application for which the output is generated

expression= an XPath 1.0 expression that evaluates to a node set containing element and attribute nodes only. If the node set contains namespace, processing instructions, comments, or text nodes, then no output is generated. The expression is evaluated in the context of the node selected by the context attribute in the  parent sch:rule element. This XPath expression can use the deref() extension function.

5.1.1  smlerr:outputids

This global attribute can be used in a sch:report or sch:assert element to specify the identities of the smlerr:output elements whose expressions must be evaluated to generate XML output when the assert/report fires.

<xs:attribute name="outputids" type="xs:IDREFS"/>

5.1.2 smlerr:attributeNode

This element is used for serialization of each attribute node in the node set resulting from the evaluation of the expression attribute on an smlerr:output element.

  <xs:element name="attributeNode" type="smlerr:attributeNodeType"/>

  <xs:complexType name="attributeNodeType">
      <xs:simpleContent>
          <xs:extension base="xs:string">
              <xs:attribute name="name" type="xs:QName"/>
          </xs:extension>
      </xs:simpleContent>
  </xs:complexType>

The value of the name attribute is the qualified name of the attribute whose value is being serialized.

5.1.3 smlerr:errorDataType

This element is used for enclosing the structured XML generated by an smlerr:output element.  

  <xs:element name="errorData" type="smlerr:errorDataType"/>
  <xs:complexType name="errorDataType">
      <xs:sequence>
          <xs:any namespace="##any" maxOccurs="unbounded" processContents="skip"/>
      </xs:sequence>
  </xs:complexType>

5.1.4 Semantics

When a report/assert fires, then all smlerr:output elements whose ID is listed in the outputids attribute on that sch:report or sch:assert element are evaluated. For each such smlerr:output,  the expression specified in its expression attribute is evaluated, and the resulting node set is serialized into XML by concatenating each node and enclosing the serialized XML fragment in the smlerr:errorData element to create a well-formed XML document. The resulting document is returned to the application that initiated the model validation. The serialization is only performed if the node set contains attribute and/or element nodes. Otherwise, no structured XML is serialized and an empty smlerr:errorData element is returned.

The nodes in the node set may be serialized in any order.  Element nodes are serialized directly into their XML representation, and attribute nodes are serialized by using the smlerr:attributeNode element.

All namespace bindings defined (through the sch:ns element) for the parent sch:rule, sch:pattern, or sch:schema elements remain valid and can be used in the expression specified in the expression attribute.

5.1.5 Examples

The following example illustrates the use of smlerr:output

   <xs:simpleType  name="IPAddressVersionType">
       <xs:restriction base="xs:string">
           <xs:enumeration value="V4"/>
           <xs:enumeration value="V6"/>
       </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="IPAddressType">
       <xs:annotation>
           <xs:appinfo>
               <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
                   <sch:ns prefix="tns" uri="urn:IPAddress" />
                   <sch:pattern id="Length">
                       <sch:rule context=".">
                           <sch:report id="v4" test="tns:version = 'V4' and count(tns:address)!= 4"
                                       smlerr:outputids="IPXML">
                               A v4 IP address must have 4 bytes.
                           </sch:report>
                           <sch:report id="v6" test="tns:version = 'V6' and count(tns:address) != 16"
                                       smlerr:outputids="IPXML">
                               A v6 IP address must have 16 bytes.
                           </sch:report>
                           <smlerr:output applicationUri="someApplicationUri"
                                       id="IPXML"
                                       expression=".">
                           </smlerr:output>
                       </sch:rule>
                   </sch:pattern>
               </sch:schema>
           </xs:appinfo>
       </xs:annotation>
       <xs:sequence>
           <xs:element name="version" type="tns:IPAddressVersionType" />
           <xs:element name="address" type="xs:byte"
                       minOccurs="4" maxOccurs="16" />
       </xs:sequence>
   </xs:complexType>

If the report with id="v4" fires for an element ipaddress of type IPAddressType, then the output may look like

<smlerr:errorData xmlns:smlerr="http://www.w3.org/2007/08/sml-err">
  <ipaddress xmlns="urn:IPAddress">
    <version>v4</version>
    <address>10</address>
    <address>10</address>
    <address>20</address>
    <address>0</address>
    <address>0</address>  
  </ipaddress>
</smlerr:errorData>

The following example illustrates an smlerr:output element whose expression results in attribute nodes

  <xs:complexType name="universityType">
      <xs:annotation>
          <xs:appinfo>
              <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
                  <sch:ns prefix="u" uri="http://www.university.example.org/ns" />
                  <sch:pattern id="Count">
                      <sch:rule context=".">
                          <sch:assert id="StudentCount"
                                      test="count(u:student)&gt;20"
                                      smlerr:outputids="StudentXml">
                              A university must have  more than 20 students 
                          </sch:assert>
                          <smlerr:output id="StudentXml"  
                                         expression="@name|@isPublic" />
                      </sch:rule>
                  </sch:pattern>
              </sch:schema>
          </xs:appinfo>
      </xs:annotation>
      <xs:sequence>
          <xs:element name="student" type="sml:refType"
                      minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="name" type="xs:string"/>
      <xs:attribute name="isPublic" type="xs:boolean"/>
  </xs:complexType>

If  the assert fires for an element of type universityType then the output may look like

<smlerr:errorData xmlns:sml="http://www.w3.org/2007/08/sml-err">
  <smlerr:attributeNode xmlns:u="http://www.university.example.org/ns"
                        name="u:name">MIT</smlerr:attributeNode>
  <smlerr:attributeNode xmlns:u="http://www.university.example.org/ns"
                        name="u:isPublic">false</smlerr:attributeNode>
</smlerr:errorData>

6. Model Validation

Model validation is the process of examining each document in a model and verifying that this document is valid with respect to the model's definition documents, i.e., each document satisfies the schemas and rules defined in the model's definition documents.  All of the following MUST be true for a valid model:

6.1 Schematron Phase

A phase in schematron can be used to define a collection of patterns. A schematron processor can optionally evaluate only rules within a specific phase. For model validation, rule evaluation happens on the #ALL phase, implying that every rule in every pattern is evaluated.

7. SML Extension Reference

This section is a non-normative reference of the SML extensions to XML Schema and XPath 1.0.

7.1 Types

7.1.1 sml:refType

A complex type representing a reference to an element.

    <xs:complexType name="refType" sml:acyclic="false">
      <xs:sequence>
        <xs:any namespace="##any" minOccurs="0"
                maxOccurs="unbounded"
                processContents="lax"/>
      </xs:sequence>
      <xs:attribute ref="sml:ref" use="required"
                    fixed="true" />
      <xs:anyAttribute namespace="##any"
                       processContents="lax"/>
    </xs:complexType>

No specific scheme is mandated for representing references, and a model validator is free to choose any suitable scheme. However, each reference value must resolve to a single element. sml:refType can only be used with element declarations; it is not supported on attribute declarations.

7.2 Attributes

7.2.1 sml:acyclic

Used to specify that a derived type of sml:refType is acyclic, i.e., its instances do not create any cycles in a model.

<xs:attribute name="acyclic" type="xs:boolean"/>

If this attribute is set to true for a derived type D of sml:refType, then instances of D (including any derived types of D) can not create any cycles in a model. More precisely, the directed graph whose nodes are documents that contain the source or target elements for instances of D, and whose edges are instances of D (an edge is directed from the document containing the source element to the document containing the target element),  must be acyclic. A model is invalid if its documents result in a cyclic graph using instances of D. In the following example, Hostref is a restricted derived type of sml:refType and its instances can not create any cycles:

<xs:complexType name="Hostref" sml:acyclic="true">
  <xs:complexContent>
    <xs:restriction base="sml:refType"/>
  </xs:complexContent>
</xs:complexType>

If the sml:acyclic attribute is not specified or set to false for a derived type of sml:refType, then instances of this reference type may create cycles in a model. Note that sml:acyclic is specified as "false" for sml:refType; hence its instances are allowed to create cycles in a model.

7.2.2 sml:ref

This global attribute is used to identify reference elements.

<xs:attribute name="ref" type="xs:boolean"/>

 Any element that has sml:ref="true" will be treated as a reference element. Note that sml:ref="true" for all elements whose type is sml:refType or a derived type sml:refType.

7.2.3 sml:targetElement

A QName representing the name of a referenced element

 <xs:attribute name="targetElement" type="xs:QName"/>

sml:targetElement is supported as an attribute for  element declarations  whose type is sml:refType or a type derived by restriction from sml:refType. The value of this attribute must be the name of some global element declaration. Let sml:targetElement="ns:GTE" for some element declaration E. Then each element instance of E must target an element that is an instance of ns:GTE or an instance of some global element declaration in the substitution group hierarchy whose head is ns:GTE.

In the following example, the element referenced by instances of HostOS must be instances of win:Windows

          <xs:element name="HostOS" type="sml:refType"
                      sml:targetElement="win:Windows"
                      minOccurs="0"/>

A model is invalid if its documents violate one/more sml:targetElement constraints.

7.2.4 sml:targetRequired

Used to specify that instances of a reference element must target elements in the model, i.e., an instance of the reference element can not be empty or null, or contain a dangling reference which does not target any element in the model.

<xs:attribute name="targetRequired" type="xs:boolean"/>

In the following example, the targetRequired attribute is used to specify that application instances must have a host operating system.

  <xs:complexType name="ApplicationType">
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Vendor" type="xs:string"/>
      <xs:element name="Version" type="xs:string"/>
      <xs:element name="HostOSRef" type="sml:refType"
                  sml:targetRequired="true"/>
    </xs:sequence>
  </xs:complexType>

A model is invalid if its documents violate one/more sml:targetRequired constraints.

7.2.5 sml:targetType

A QName representing the type of a referenced element

    <xs:attribute name="targetType" type="xs:QName">

sml:targetType is supported as an attribute for element declarations  whose type is sml:refType or a type derived by restriction from sml:refType. If the value of this attribute is specified as T, then the type of the referenced element must either be T or a derived type of T. In the following example, the type of the element referenced by the OperatingSystem element must be "ibm:LinuxType" or its derived type

          <xs:element name="OperatingSystem" type="sml:refType"
                      sml:targetType="ibm:LinuxType"
                      minOccurs="0"/>

A model is invalid if its documents violate one/more sml:targetType constraints.

7.3 Elements

7.3.1 sml:key

This element is used to specify a key constraint in some scope. The semantics are essentially the same as that for xs:key but sml:key can also be used to specify key constraints on other documents, i.e., the  sml:selector child element of sml:key can contain deref functions to resolve elements in another document.

<xs:element name="key" type="sml:keybase"/>

sml:key is supported in the appinfo of an xs:element.  

7.3.2 sml:keyref

Applies a constraint in the context of the containing xs:element that scopes the range of a nested document reference.

    <xs:element name="keyref">
      <xs:complexType>
        <xs:complexContent>
          <xs:extension base="sml:keybase">
            <xs:attribute name="refer" type="xs:QName" use="required"/>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
    </xs:element>>

sml:keyref is supported in the appinfo of an xs:element.  

7.3.3 sml:unique

This element is used to specify a uniqueness constraint in some scope. The semantics are essentially the same as that for xs:unique but sml:unique can also be used to specify uniqueness constraints on other documents, i.e., the  sml:selector child element of sml:unique can contain deref functions to resolve elements in another document.

<xs:element name="unique" type="sml:keybase"/>

sml:unique is supported in the appinfo of an xs:element.  

7.3.4 sml:uri

Specifies a reference in URI scheme.

<xs:element name="uri" type="xs:anyURI"/>

This element must be used to specify references that use the URI scheme.

7.4 XPath functions

7.4.1 smlfn:deref

node-set deref(node-set)

This function takes a node-set of elements and attempts to resolve the references contained in the elements that have sml:ref="true".    The resulting node-set is the set of elements that are obtained by successfully resolving (or de-referencing) the  reference contained in each element in the input node-set for which sml:ref="true".  For example,

deref(/u:Universities/u:Students/u:Student)

will resolve the reference in element Student. The target of the reference must always be an element.

8. References

8.1 Normative References

[IETF RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 3986]
Uniform Resource Identifier (URI): Generic Syntax , T. Berners-Lee, R. Fielding and L. Masinter, Authors. Network Working Group, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt.
[ISO/IEC 19757-3]
Information technology ― Document Schema Definition Languages (DSDL) ― Part 3: Rule-based validation ― Schematron. International Organization for Standardization and International Electrotechnical Commission, 1 January 2006. Available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip
[WS-Addressing Core]
Web Services Addressing 1.0 - Core, M. Gudgin, M. Hadley, and T. Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the WS-Addressing Core Recommendation is http://www.w3.org/TR/2006/REC-ws-addr-core-20060509. The latest version of WS-Addressing Core is available at http://www.w3.org/TR/ws-addr-core.
[XML 1.0]
Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 16 August 2006. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2006/REC-xml-20060816. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml.
[XML Schema Structures]
XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The latest version of XML Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The latest version of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2.
[XPath 1.0]
XML Path Language (XPath) Version 1.0, J. Clark and S. DeRose, Editors. World Wide Web Consortium, 16 November 1999. This version of XML Path Language (XPath) Version 1.0 is http://www.w3.org/TR/1999/REC-xpath-19991116. The latest version of XML Path Language (XPath) Version 1.0 is available at http://www.w3.org/TR/xpath.
[XPointer]
XPointer Framework, P. Grosso, E. Maler, J. Marsh, and N. Walsh, Editors. World Wide Web Consortium, 25 March 2003. This version of the XPointer Framework Recommendation is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The latest version of XPointer Framework is available at http://www.w3.org/TR/xptr-framework/.
[xmlns() Scheme]
XPointer xmlns() Scheme, S. DeRose, R. Daniel Jr., E. Maler, and J. Marsh, Editors. World Wide Web Consortium, 25 March 2003. This version of the XPointer xmlns() Scheme Recommendation is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The latest version of XPointer xmlns() Scheme is available at http://www.w3.org/TR/xptr-xmlns/.
[xpointer() Scheme]
XPointer xpointer() Scheme, S. DeRose, E. Maler, and R. Daniel Jr., Editors. World Wide Web Consortium, 19 December 2002. This version of the XPointer xpointer() Scheme specification is http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/. The latest version of XPointer xpointer() Scheme is available at http://www.w3.org/TR/xptr-xpointer/.

8.2 Informative References

[Introduction to Schematron]
An Introduction to Schematron, Eddie Robertsson, Author. O'Reilly Media, Inc., 12 November 2003. Available at http://www.xml.com/pub/a/2003/11/12/schematron.html
[Improving Validation with Schematron]
Improving XML Document Validation with Schematron, Dare Obasanjo, Author. Microsoft Corporation, September 2004. Available at http://msdn2.microsoft.com/en-us/library/Aa468554.aspx
[XML Schema Primer]
XML Schema Part 0: Primer Second Edition, D. Fallside and P. Walmsley, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 0 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-0-20041028. The latest version of XML Schema Part 0 is available at http://www.w3.org/TR/xmlschema-0.

A. Normative SML Schema

<?xml version="1.0" encoding="utf-8"?>

<!--
/*
 * Copyright © 2007 World Wide Web Consortium,
 *
 * (Massachusetts Institute of Technology, European Research Consortium for
 * Informatics and Mathematics, Keio University). All Rights Reserved. This
 * work is distributed under the W3C® Document License [1] in the hope that
 * it will be useful, but WITHOUT ANY WARRANTY; without even the implied
 * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *
 * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
 */
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sml="http://www.w3.org/2007/08/sml" targetNamespace="http://www.w3.org/2007/08/sml" elementFormDefault="qualified" blockDefault="#all" version="1.0" xml:lang="en" finalDefault="" attributeFormDefault="unqualified">
  
   <!--
      References
      ==========
  -->
   
  <xs:complexType name="refType" sml:acyclic="false" mixed="false">
    <xs:annotation>
      <xs:documentation>
	A complex type representing a reference to an element
	in the same or a different document. No specific scheme is  
	mandated for references; an implementation is free to
	choose an appropriate scheme such as URI, EPR, etc.
	The target of the reference must unambigously identify a
	single element.
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute ref="sml:ref" use="required" fixed="true"/>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
  </xs:complexType>
  
   <!-- CONTEXT: To be used in <xs:element> -->
   
  <xs:attribute name="ref" type="xs:boolean">
    <xs:annotation>
      <xs:documentation>
	Specifies if the element contains a reference
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  
   <!-- CONTEXT: To be used in <xs:element> where type="sml:refType"-->
   
  <xs:attribute name="targetElement" type="xs:QName">
    <xs:annotation>
      <xs:documentation>
	A qualified name of an element in the
	referenced document.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  
   <!-- CONTEXT: To be used in <xs:element> where type="sml:refType"-->
   
  <xs:attribute name="targetRequired" type="xs:boolean">
    <xs:annotation>
      <xs:documentation>
	If true, requires the target element of the reference to
	exist in the model.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  
   <!-- CONTEXT: To be used in <xs:element> where type="sml:refType"-->
   
  <xs:attribute name="targetType" type="xs:QName">
    <xs:annotation>
      <xs:documentation>
	A qualified name of the type of the element in the
	referenced document.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  
   <!-- CONTEXT: To be used in sml:refType and its derived types-->
   
  <xs:attribute name="acyclic" type="xs:boolean">
    <xs:annotation>
      <xs:documentation>
	If this attribute is set to true for a derived type D of
	sml:refType, then instances of D should not create any
	cycles in a model. More precisely, the directed graph whose
	edges represent instances of D, and whose nodes represent
	documents that contain the source or target elements for
	instances of D, must be acyclic.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  
   <!-- CONTEXT: Represents a reference using the URI scheme. To be
       used as a child  element of elements for which
       sml:ref="true". -->
   
  <xs:element name="uri" type="xs:anyURI">
    <xs:annotation>
      <xs:documentation>
	References in URI scheme must be representend by this
	element.  
      </xs:documentation>
    </xs:annotation>
  </xs:element>

  
   <!--
      Uniqueness and Key constraints
      ==============================
  -->
   

  <xs:complexType name="keybase" mixed="false">
    <xs:sequence minOccurs="0">
      <xs:element name="selector" type="sml:selectorXPathType"/>
      <xs:element name="field" type="sml:fieldXPathType" maxOccurs="unbounded"/>
      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:NCName"/>
    <xs:attribute name="ref" type="xs:QName"/>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="key" type="sml:keybase"/>
  <xs:element name="unique" type="sml:keybase"/>
  <xs:element name="keyref">
    <xs:complexType mixed="false">
      <xs:complexContent>
	<xs:extension base="sml:keybase">
	  <xs:attribute name="refer" type="xs:QName" use="required"/>
	</xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>

  
   <!--
      Other Complex Types
      ==================
  -->
   

  <xs:complexType name="selectorXPathType" mixed="false">
    <xs:sequence>
      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
    </xs:sequence>
    <xs:attribute name="xpath" use="required">
      <xs:simpleType>
	<xs:restriction base="xs:string">
	  
   <!-- TODO: add a pattern facet for selector xpath -->
   
	</xs:restriction>
      </xs:simpleType>
    </xs:attribute>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>

  <xs:complexType name="fieldXPathType" mixed="false">
    <xs:sequence>
      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
    </xs:sequence>
    <xs:attribute name="xpath" use="required">
      <xs:simpleType>
	<xs:restriction base="xs:string">
	  
   <!-- TODO: add a pattern facet for field xpath -->
   
	</xs:restriction>
      </xs:simpleType>
    </xs:attribute>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
</xs:schema>

B. Normative SML Error Schema

<?xml version="1.0" encoding="utf-8"?>

<!--
/*
 * Copyright © 2007 World Wide Web Consortium,
 *
 * (Massachusetts Institute of Technology, European Research Consortium for
 * Informatics and Mathematics, Keio University). All Rights Reserved. This
 * work is distributed under the W3C® Document License [1] in the hope that
 * it will be useful, but WITHOUT ANY WARRANTY; without even the implied
 * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *
 * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
 */
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:smlerr="http://www.w3.org/2007/08/sml-err" targetNamespace="http://www.w3.org/2007/08/sml-err" elementFormDefault="qualified" blockDefault="#all" version="1.0" xml:lang="en" finalDefault="" attributeFormDefault="unqualified">

  <xs:element name="errorData" type="smlerr:errorDataType"/>
  <xs:element name="output" type="smlerr:outputType"/>
  <xs:element name="attributeNode" type="smlerr:attributeNodeType"/>

  <xs:attribute name="outputids" type="xs:IDREFS"/>
  <xs:attribute name="localizationid" type="xs:anyURI"/>

  <xs:complexType name="outputType" mixed="false">
    <xs:attribute name="id" type="xs:ID" use="required"/>
    <xs:attribute name="applicationUri" type="xs:anyURI"/>
    <xs:attribute name="expression" type="xs:string" use="required"/>
  </xs:complexType>

  <xs:complexType name="attributeNodeType" mixed="false">
    <xs:simpleContent>
      <xs:extension base="xs:string">
	<xs:attribute name="name" type="xs:QName"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="errorDataType" mixed="false">
    <xs:sequence>
      <xs:any namespace="##any" maxOccurs="unbounded" processContents="skip" minOccurs="1"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

C. Sample Model (Non-Normative)

This sample model illustrates the use of the following SML extensions:

<?xml version="1.0" encoding="utf-8"?>

<!--
/*
 * Copyright ©  World Wide Web Consortium,
 *
 * (Massachusetts Institute of Technology, European Research Consortium for
 * Informatics and Mathematics, Keio University). All Rights Reserved. This
 * work is distributed under the W3C® Document License [1] in the hope that
 * it will be useful, but WITHOUT ANY WARRANTY; without even the implied
 * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *
 * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
 */
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://example.org/SampleModel" xmlns:sml="http://www.w3.org/2007/08/sml" xmlns:smlfn="http://www.w3.org/2007/08/sml-function" xmlns:sch="http://purl.oclc.org/dsdl/schematron" targetNamespace="http://example.org/SampleModel" elementFormDefault="qualified" finalDefault="" blockDefault="" attributeFormDefault="unqualified">

  <xs:import namespace="http://www.w3.org/2007/08/sml"/>

  <xs:simpleType name="SecurityLevel">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Low"/>
      <xs:enumeration value="Medium"/>
      <xs:enumeration value="High"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="Hostref" sml:acyclic="true" mixed="false">
    <xs:complexContent>
      <xs:restriction base="sml:refType"/>
    </xs:complexContent>
  </xs:complexType>

  
   <!-- This element represents the host operating system for
       an application. Note that the type of the referenced
       element must be OperatingSystemType or a derived type
       of OperatingSystemType -->
   
  <xs:element name="HostOSRef" type="tns:Hostref" sml:targetType="tns:OperatingSystemType"/>

  <xs:complexType name="ApplicationType" mixed="false">
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Vendor" type="xs:string"/>
      <xs:element name="Version" type="xs:string"/>
      <xs:element ref="tns:HostOSRef" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType> 

  <xs:simpleType name="ProtocolType">
    <xs:list>
      <xs:simpleType>
	<xs:restriction base="xs:string">
	  <xs:enumeration value="TCP"/>
	  <xs:enumeration value="UDP"/>
	  <xs:enumeration value="SMTP"/>
	  <xs:enumeration value="SNMP"/>
	</xs:restriction>
      </xs:simpleType>
    </xs:list>
  </xs:simpleType>

  <xs:element name="GuestAppRef" type="sml:refType" sml:targetType="tns:ApplicationType"/>

  <xs:complexType name="OperatingSystemType" mixed="false">
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="FirewallEnabled" type="xs:boolean"/>
      <xs:element name="Protocol" type="tns:ProtocolType"/>
      
   <!-- The following element represents the applications hosted by
	   operating system -->
   
      <xs:element name="Applications" minOccurs="0">
	<xs:complexType mixed="false">
	  <xs:sequence>
	    <xs:element ref="tns:GuestAppRef" maxOccurs="unbounded"/>
	  </xs:sequence>
	</xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="OSRef" type="sml:refType" sml:targetType="tns:OperatingSystemType"/>

  <xs:complexType name="WorkstationType" mixed="false">
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element ref="tns:OSRef"/>
      <xs:element name="Applications" minOccurs="0">
	<xs:complexType mixed="false">
	  <xs:sequence>
	    <xs:element ref="tns:GuestAppRef" maxOccurs="unbounded"/>
	  </xs:sequence>
	</xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType> 

  <xs:element name="Workstation" type="tns:WorkstationType">
    <xs:annotation>
      <xs:appinfo>
	<sch:schema>
	  <sch:ns prefix="sm" uri="SampleModel"/>
	  <sch:ns prefix="smlfn" uri="http://www.w3.org/2007/08/sml-function"/>
	  <sch:pattern id="OneHostOS">
	    
   <!-- The constraints in the following rule are evaluated  
		 For all instances of the Workstation global element-->
   
	    <sch:rule context=".">
	      
   <!-- define a named variable - MyApplications -
		   for use in test expression-->
   
	      <sch:let name="MyApplications" value="smlfn:deref(sm:Applications/sm:GuestAppRef)"/>
	      <sch:assert test="count($MyApplications)=count($MyApplications/sm:HostOSRef)">
		Each application in workstation
		<sch:value-of select="string(sm:Name)"/>
		must be hosted on an operating system
	      </sch:assert>
	    </sch:rule>
	  </sch:pattern>
	</sch:schema>

	
   <!-- In a workstation, (Vendor,Name,Version) is the key for
	     guest applications -->
   
	<sml:key name="GuestApplicationKey">
	  <sml:selector xpath="smlfn:deref(tns:Applications/tns:GuestAppRef)"/>
	  <sml:field xpath="tns:Vendor"/>
	  <sml:field xpath="tns:Name"/>
	  <sml:field xpath="tns:Version"/>
	</sml:key>

	
   <!-- In a workstation, Name is the key for operating system -->
   
	<sml:key name="OSKey">
	  <sml:selector xpath="smlfn:deref(tns:OSRef)"/>
	  <sml:field xpath="tns:Name"/>
	</sml:key>
	
	
   <!-- In a workstation, the applications hosted by the
	     referenced operatinsystem must be a subset of the
	     applications in the workstation -->
   
	<sml:keyref name="OSGuestApplication" refer="tns:GuestApplicationKey">
	  <sml:selector xpath="smlfn:deref(tns:OSRef)/tns:Applications/tns:GuestAppRef"/>
	  <sml:field xpath="tns:Vendor"/>
	  <sml:field xpath="tns:Name"/>
	  <sml:field xpath="tns:Version"/>   
	</sml:keyref>

	
   <!-- In a workstation, the host operating system of guest
	     applications must be a subset of the operating system in
	     the workstation -->
   
	<sml:keyref name="ApplicationHostOS" refer="tns:OSKey">
	  <sml:selector xpath="smlfn:deref(tns:Applications/tns:GuestAppRef)/tns:HostOSRef"/>
	  <sml:field xpath="tns:Name"/>
	</sml:keyref>
      </xs:appinfo>
    </xs:annotation>
  </xs:element>

  <xs:element name="SecureWorkstation" type="tns:WorkstationType">
    <xs:annotation>
      <xs:appinfo>
	<sch:schema>
	  <sch:ns prefix="sm" uri="SampleModel"/>
	  <sch:ns prefix="smlfn" uri="http://www.w3.org/2007/08/sml-function"/>
	  <sch:pattern id="SecureApplication">
	    <sch:rule context="smlfn:deref(sm:Applications/sm:Application)">
	      <sch:report test="sm:SecurityLevel!='High'">
		Application <sch:value-of select="string(sm:Name)"/>
		from <sch:value-of select="string(sm:Vendor)"/>
		does not have high security level
	      </sch:report>
	      <sch:assert test="sm:Vendor='TrustedVendor'">
		A secure workstation can only contain
		applications from TrustedVendor
	      </sch:assert>
	    </sch:rule>
	  </sch:pattern>
	</sch:schema>
      </xs:appinfo>
    </xs:annotation>
  </xs:element>

</xs:schema>

D. Acknowledgements (Non-Normative)

The editors acknowledge the members of the Service Modeling Language Working Group, the members of other W3C Working Groups, and industry experts in other forums who have contributed directly or indirectly to the process or content of creating this document.

At the time this specification was published, the members of the Service Modeling Language Working Group were:

John Arwe (IBM Corporation), Jordan Boucher (Sun Microsystems, Inc.), Pratul Dublish (Microsoft Corporation), Zulah Eckert (BEA Systems, Inc.), Sandy Gao (IBM Corporation), Heather Kreger (IBM Corporation), Philippe Le Hégaret (W3C/MIT), Paul Lipton (CA), James Lynn (HP), Kumar Pandit (Microsoft Corporation), Valentina Popescu (IBM Corporation), Virginia Smith (HP), Michael Sperberg-McQueen (W3C/MIT), Bassam Tabbara (Microsoft Corporation), Vijay Tewari (Intel Corporation), Marvin Waschke (CA), Kirk Wilson (CA), Brian You (IBM Corporation).