Service Modeling Language, Version 1.1

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.

Models focus on capturing all invariant aspects of a service/system that must be maintained for the service/system to function properly.
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.
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.
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.
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:

Schemas ― these are constraints on the structure and content of the documents in a model. SML uses XML Schema [XML Schema Structures, XML Schema Datatypes] as the schema language. In addition SML defines a set of extensions to XML Schema to support references that may cross document boundaries.
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 [XPath] 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 extensions to XML Schema for references that cross document boundaries, the profile of 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.

SML uses XML Schema [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:

SML references – XML documents introduce boundaries across content that needs to be treated as a unit. XML Schema does not have any support for references that cross documents, although it does support references within elements in the same document through xs:ID, xs:IDREF, xs:key and xs:keyref. References between elements defined in separate SML model documents are fundamental to the SML specification. SML extends XML Schema to support references that may cross document boundaries, and a set of constraints on those references that apply regardless of whether they cross document boundaries or not.
Rules – XML Schema does not support a language for defining arbitrary rules on the structure and content of XML documents. SML uses Schematron to express assertions on the structure and content of XML documents.

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

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 document, as defined in [XML].
Model: A set of inter-related documents that describe a service or system. Each model consists of two disjoint subsets of documents – model definition documents and model instance documents.
Reference: A link from one element in an SML model to another element from the same model.
Rule: A rule is a boolean expression that constrains the structure and content of a set of documents in a model.
Rule bindings: A rule binding is an association of a set of one or more rule documents with a set of zero or more model documents. The documents associated with a given rule document are said to be "bound" to it. For a model to be valid, every definition and/or instance document in the model must conform to the constraints defined by every rule document it is bound to. It is permissible for a rule document to have no bindings associated with it, and for a model document to be bound to zero rule documents.
Rule document: A rule document is a model definition document consisting of Schematron rules that conforms to the SML's profile of Schematron.
Schema document: A schema document is a model definition document that conforms to the XML Schema specification [XML Schema Structures] definition of a schema document.
Model Definition Documents: 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 and rule documents, 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 Documents: The subset of documents in a model that describes the structure and content of the modeled entities.
Model Validation: 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.
Prefix	XML Namespace	Specification(s)
`sml`	`http://www.w3.org/@@@@/@@/sml`	This specification
`smlerr`	`http://www.w3.org/@@@@/@@/sml-err`	This specification
`smlfn`	`http://www.w3.org/@@@@/@@/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. Dependencies on Other Specifications

Other specifications on which this one depends are listed in [Normative-References].

Conforming implementations of this specification MUST support XML 1.0 [XML], XML Schema 1.0 [XML Schema Structures, XML Schema Datatypes], Schematron [ISO/IEC 19757-3] and XPath 1.0 [XPath]. Conforming implementations MAY additionally support later versions of the XML, XML Schema, Schematron or XPath specifications.

4. SML References

Support for SML references in an SML model includes:

The ability to use multiple reference schemes for representing references.
An extensibility mechanism allowing new reference schemes to be defined.
Constraints on the type of a referenced element.
The ability to define key, unique, and key reference constraints across SML references.

References MUST be supported by model validators that conform to this specification.

4.1 Reference Definitions

4.1.1 SML Reference

An element information item in an SML model instance document MUST be treated as a reference element if and only if:

It has an attribute information item whose [local name] is ref and whose [namespace name] is http://www.w3.org/@@@@/@@/sml and whose [normalized value] , after whitespace normalization using collapse following schema rules, is either "true" or "1".

This mechanism enables schema-less identification of reference elements, i.e., reference elements can be identified without relying on PSVI.

Although its normative definition allows several syntaxes to be used to identify an SML reference element, for the sake of brevity and consistency, the rest of this specification uses sml:ref="true" to denote an SML reference in examples and text.

4.1.2 SML Null Reference

An element information item in an SML model instance document is an SML null reference if and only if:

It is an SML reference.
It has an attribute information item whose [local name] is nilref and whose [namespace name] is http://www.w3.org/@@@@/@@/sml and whose [normalized value] after whitespace normalization using collapse following schema rules, is either "true" or "1".

4.1.3 Unresolved SML Reference

An element information item in an SML model instance document is an unresolved SML reference if and only if:

It is a non-null SML reference.
None of the recognized reference schemes resolves.

4.1.4 SML Reference Target

The node set a non-null SML reference resolves to is its target. SML null references have no target.

4.2 Reference Semantics

A model validator MUST attempt to resolve an SML reference using all reference schemes of which the reference is recognized as an instance.

4.2.1 At Most One Target

Every non-null reference MUST target at most one element in a model. When one or multiple recognized schemes in a reference resolve to more than one target then the model is declared invalid.

4.2.2 Consistent Reference Schemes

The model is declared invalid when a recognized scheme resolves to a target that's different from the target resolved by another recognized scheme or when a recognized scheme resolves and another doesn't.

4.2.3 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.

4.2.4 Null References

A null reference is an explicit declaration of intent by the document author that the reference itself does not exist, and a processing directive (not a hint) to processors not to attempt to recognize any reference schemes in it. If a reference element is recognized as null, then processors MUST NOT attempt to resolve it. The question of whether a null reference is resolved or not is undefined; it is an ill-formed question.

4.2.5 deref() XPath Extension Function

Each SML processor MUST provide an implementation of the deref() XPath extension function. 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 behavior of deref() function MUST satisfy the following constraints:

If the implementation recognizes no scheme used in the reference, then deref() returns no target for R.
If the implementation recognizes R as using N supported schemes, then deref() is not required to attempt to resolve all N schemes. Its behavior in this case is implementation-defined and the set of schemes that are actually attempted may be any subset of the recognized schemes. This is subject to the following constraints:
1. If deref() doesn't attempt to resolve any scheme or if none of the attempted schemes resolves, then no target is returned.
2. If at least one of the attempted schemes resolves to more than one target element, then 0 or 1 of the targets is returned.
3. If one attempted scheme resolves to a target that's different from the target resolved by another attempted scheme, then 0 or 1 of the targets is returned.
4. If one attempted scheme resolves and another doesn't, then 0 or 1 of the targets is returned.
5. If none of the above is true (that is, all attempted schemes resolve to the same one and only one target element, call it T), then one target is returned (namely, T).

4.3 Reference Schemes

An SML reference MAY be represented by using a variety of schemes, including those defined in this specification. SML does not mandate the use of any specific schemes. A reference scheme MAY use child elements, attributes, both, or neither to capture the information necessary to identify the reference target. It is not required that all elements in an SML model be reachable via an SML reference. This will depend on the support defined by the chosen reference scheme.

Although SML does not require the use of any specific scheme, it does specify how a reference MUST be represented when using SML-defined reference schemes. The 4.3.1 SML URI Scheme and 4.3.2 EPR Scheme are two schemes defined by SML for identifying reference targets.

All of the following MUST be defined for each SML reference scheme,

The set of rules that, when satisfied, identify a reference element as containing one and the only instance of the scheme within that reference element.
The set of rules that, when evaluated, resolve the containing reference to a set of target element nodes.
An assertion whether the scheme can be used in an SML-IF [SML-IF 1.1] document to reference documents in the interchange set.

4.3.1 SML URI Scheme

The SML URI Scheme is defined as follows:

An SML reference element is identified as using the SML URI scheme if and only if exactly one instance of the sml:uri global element declaration is present as a child of that reference element.
The SML URI scheme is resolved using the following steps:
1. A document is obtained by dereferencing the URI reference, sans fragment identifier, using the appropriate operation defined for the scheme used in that URI reference. If there is no document retrieved, the scheme instance is unresolved.
2. If a fragment identifier is not present in the URI reference, the scheme instance resolves to the root element of the retrieved document.
3. If a fragment identifier is present in the URI reference, the scheme instance resolves to the set of elements obtained by applying the fragment identifier to the root element of the retrieved document.
The SML URI Scheme can be used in an SML-IF [SML-IF 1.1] document to reference documents from the interchange set.

Here is an example. If the reference element in the SML References Sample 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>

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

Document	URI
Course PHY101	http://www.university.example.org/Universities/MIT/Courses/PHY101.xml
Course MAT200	http://www.university.example.org/Universities/MIT/Courses/MAT200.xml
Student 1000	http://www.university.example.org/Universities/MIT/Students/1000.xml
Student 1001	http://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>

4.3.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 [XPath] expression that MUST resolve to at most one element node. In particular, this expression MUST NOT contain
1. the union ("|") operator defined for XPath
2. point() and range() node tests defined for the xpointer() scheme
This expression can only use the functions defined in the XPath core function library [XPath]. It MUST NOT use the smlfn:deref function and/or the following functions defined for xpointer() scheme [xpointer() Scheme]:
1. range-to
2. string-range
3. range
4. range-inside
5. start-point
6. end-point
7. here
8. 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.

4.3.2 EPR Scheme

The EPR Scheme is defined as follows:

An SML reference element is identified as using the EPR scheme if and only if exactly one instance of the wsa:EndpointReference global element declaration is present as a child of that reference element.
Ed. note: Add definition of how the scheme is resolved.
The EPR Scheme can not be used in an SML-IF [SML-IF 1.1] document to reference documents from the interchange set.

The following example illustrates how the EnrolledCourse reference that references course PHY101 in MIT university can be represented using the EPR scheme:

<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>

4.4 Constraints on References

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

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

SML defines a new property for every Complex Type Definition schema component: {acyclic} An xs:boolean value. Required.

And 3 new properties for every Element Declaration and every Particle component:

{target element} An Element Declaration component. Optional.
{target required} An xs:boolean value. Required.
{target type} A Type Definition component. Optional.

4.4.1 sml:acyclic

Model validators that conform to this specification MUST support the sml:acyclic attribute on any <xs:complexType> element in a schema document. This is a boolean attribute and its value can be either true or false.

4.4.1.1 Mapping from Schema

If sml:acyclic is present, then {acyclic} has the actual value of sml:acyclic; otherwise, it has the same value of {acyclic} as its {base type definition}.

4.4.1.2 Rules

A cyclic 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 a complex type definition D's {base type definition} is also a complex type definition and has {acyclic} true, then D MUST have {acyclic} true.

4.4.1.3 Validation

If T is a complex type definition with {acyclic} true, then instances of T MUST NOT create cycles in any model. More precisely, the directed graph whose arcs are SML references of a given complexType (and any derived types) and whose nodes are all the elements pointed to by this set of SML references, must be acyclic.

4.4.2 Constraints on SML Reference Targets

SML defines 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.

Note (non-normative): 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.

4.4.2.1 sml:targetElement

Model validators that conform to this specification MUST support the sml:targetElement attribute on any element declarations. 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 S_G is a global element declaration that specifies G as the value of its xs:substitutionGroup attribute, then
1. if sml:targetElement is specified for S_G 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
2. if sml:targetElement is not specified for S_G , then sml:targetElement="ns:GTE" holds for S_G 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 P_R that is a valid restrictions of P where P_R 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, P_R 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 P_R , then the value of sml:targetElement for P_R 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 P_R , then sml:targetElement="ns:GTE" holds for P_R by default.

4.4.2.2 sml:targetRequired

Model validators that conform to this specification MUST support the sml:targetRequired attribute on any element declarations. 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 or contain an unresolved reference. Otherwise, instances of E can be null or contain unresolved 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 S_G in the substitution group hierarchy whose head is G unless the sml:targetRequired attribute is specified for S_G .
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 P_R that is a valid restriction of P unless the sml:targetRequired attribute is specified for P_R (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 P_R that is a valid restriction of P.

4.4.2.3 sml:targetType

The sml:targetType attribute MUST be supported on any element declarations. 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 S_G is a global element declaration that specifies G as the value of its xs:substitutionGroup attribute, then
1. if the sml:targetType attribute is specified for S_G the its value MUST be either ns:T or the name of some derived type of ns:T
2. if sml:targetType is not specified for S_G , then sml:targetType="ns:T" holds for S_G 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 P_R that is a valid restriction of P where P_R is defined in some restricted derived type of B. However, P_R 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 P_R then the value of the sml:targetType for P_R must be ns:T or the name of some derived type of ns:T. If sml:targetType is not specified for P_R , then sml:targetType="ns:T" holds for P_R by default

4.4.2.4 Derivation by Restriction

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.

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

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

4.4.2.5 Target Constraints and SML Reference Categories

The following table shows how target constraints MUST be handled for each of the reference categories in the table.

Table 4-2. Target Constraints and SML Reference Categories.
	`Acyclic`	`targetRequired`	`targetElement`	`targetType`
Non-reference	Satisfied	Satisfied	Satisfied	Satisfied
Null	Satisfied	Violated	Satisfied	Satisfied
Unresolved	Satisfied	Violated	Satisfied	Satisfied
Resolved	Check	Satisfied	Check	Check

4.5 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 SML references.

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

Name	Description
`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 of the XML Schema specification [XML Schema Structures], 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.
Each SML identity constraint declaration has a name, which exists in a single symbol space for SML constraints. This symbol space is disjoint from the symbol space of XML schema constraints.
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 ID' as the value of its ref attribute. In particular,
1. 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 the name of any other SML identity constraint element specified for E.
2. If the ref attribute is specified for an sml:key element, then the value of ref attribute MUST be the name of another SML key constraint.
3. If the ref attribute is specified for an sml:unique element then the value of the ref attribute MUST be the name of another SML unique constraint.
4. If the ref attribute is specified for an sml:keyref element then the value of the ref attribute MUST be the name of another SML keyref constraint.
5. Either the ref attribute or the refer attribute (but not both) MUST be specified for an sml:keyref element.
6. If the ref attribute is specified for an SML identity constraint, then the name attribute MUST NOT be specified.
7. If the ref attribute is specified for an SML identity constraint, then the selector and field child elements MUST NOT be specified.
The sml:selector XPath expression syntax and the XML identity constraint selector XPath syntax are identical in all respects except for 1 difference. The sml:selector XPath MAY use smlfn:deref() calls, nested to any depth, at the beginning of the expression. The XML identity constraint selector Path production is amended to support this requirement as defined below.
```
Path ::= ('.//')? Step ( '/' Step)* | DerefExpr
DerefExpr ::= (NCName ':')? 'deref(' Step (/Step)* ')'  ('/'Step)* |
              (NCName ':')? 'deref(' DerefExpr ')' (/Step)*
      
```
The sml:field XPath expression MUST conform to the amended BNF defined 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 S_G 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 P_R 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.

4.5.1 University Example

The following example will be used to illustrate the sml:key, sml:unique, and sml:keyref constraints across SML references. This example consists of 3 schema documents, university.xsd that contains the currently enrolled students, active courses, and other university information, students.xsd that contains information on all current and past students, and courses.xsd that contains information on the students currently enrolled in that course. The following snippets represent pieces of the definition documents.

  <!-- from university.xsd -->
  <xs:complexType name="StudentRefType">
    <!-- SML reference to a Student -->
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
  </xs:complexType>
  
  <xs:element name="Student" type="StudentRefType"/>

  <xs:complexType name="CourseRefType">
    <!-- SML reference to a Course -->
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
  </xs:complexType>

  <xs:element name="Course" type="CourseRefType"/>

  <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="Student" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="Courses" minOccurs="0">
        <xs:complexType>
          <xs:sequence>
            <xs:element ref="Course" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>


  <!-- from students.xsd -->
  <xs:complexType name="EnrolledCourseRefType">
    <!-- SML reference to a Course -->
    <xs:sequence>
      <xs:element name="Grade" type="xs:string"/>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
  </xs:complexType>

  <xs:element name="EnrolledCourse" type="EnrolledCourseRefType"/>

  <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="EnrolledCourse" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="Students">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Student" type="StudentType"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>


  <!-- from courses.xsd -->
  <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 name="EnrolledStudent" maxOccurs="unbounded">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="StudentID" type="xs:string"/>
                </xs:sequence>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="Courses">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Course" type="CourseType"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

4.5.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 4.5.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 name in the University element declaration.

4.5.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 SML references and across XML documents. The following example uses sml:keyref to capture the requirement that students enrolled in a course must be currently enrolled in the 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(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 a course is a subset of the set of IDs of students currently enrolled in the university. In particular, the selector and field elements in StudentIDisKey key constraint identify the set of IDs of students currently enrolled in the university, and the selector and field elements in CourseStudents key reference constraint identify the set of IDs of students enrolled in courses.

5. 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 XPath, 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 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:

An IPv4 address must have four bytes
An IPv6 address must have sixteen bytes

<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 element contains one or more rules and a rule element contains one or more assert and/or report elements. Each rule specifies its context using the context attribute. This context expression 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. The context expression is defined as an XSLT Pattern. This means that the smlfn:deref function may not be used in the location path of a context expression.

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. 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/@@@@/@@/sml-function"/>
                <sch:pattern id="StudentPattern">
                    <sch:rule context="u:Students/u:Student">
                        <sch:assert test="smlfn:deref(.)[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

The ID of each student must begin with '99'
Each student must be enrolled in at least one course

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

Each Schematron pattern that is embedded in the xs:annotation/xs:appinfo element for a global complex-type definition CT MUST be evaluated for all element instances of type CT in a model during the model's validation.

Each Schematron pattern that is embedded in the xs:annotation/xs:appinfo element for a global element declaration G MUST be evaluated for all element instances of G in a model during the model's validation.
As defined in the Schematron specification [ISO/IEC 19757-3], a pattern MUST be evaluated for an instance element by evaluating the rule elements of the pattern in the order of their definition. The context expression for a rule MUST be evaluated in the context of the instance element, and all asserts and reports contained in the first rule whose context expression evaluates to a non-empty node set MUST be evaluated for each node in this node set.

Model validators that conform to this specification MUST provide a mechanism to support binding of Schematron patterns, authored in separate rule documents, 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/@@@@/@@/sml-function"/>
            <sch:pattern id="StudentPattern">
                <sch:rule context="u:Students/u:Student">
                    <sch:assert test="smlfn:deref(.)[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>

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

5.1 Localization of Error Messages

5.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.

5.2 Schematron Profile

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

5.2.1 Limited Support

If the queryBinding attribute is not specified, then its value is assumed to be set to "xslt". Conforming implementations MUST support the "xslt" query binding. Conforming implementations MAY additionally support query bindings other than "xslt".

6. Conformance Criteria

A program is a conforming SML model validator if it satisfies the following conditions:

The validator MUST perform model validation as defined in this specification. Model validation is the process of examining each document in a model and verifying that this document is valid with respect to the model definition documents, i.e., each model instance document satisfies the schemas and rules defined in the applicable model definition documents.
The validator MUST support XML XML], XML Schema [XML Schema Structures], and XPath [XPath] but MAY also support any future versions of these specifications.
The validator MUST support Schematron [ISO/IEC 19757-3].
The validator MUST perform Schematron rule evaluation on the #ALL phase.
The validator MUST support the deref() XPath extension function.

A set of XML documents is a conforming SML model if it satisfies the following conditions:

Each document in the model MUST be a well-formed XML document [XML]
Each XML Schema document in the model's definition documents MUST satisfy the conditions expressed in Errors in Schema Construction and Structure (§5.1). [XML Schema Structures]
Each Schematron document in the model's definition documents MUST be a valid Schematron document [ISO/IEC 19757-3]

A conforming SML model is valid if it satisfies all of the following conditions:

In each instance document in the model, the [validity] property of the root element and all of its attributes and descendants MUST NOT be "invalid" when schema validity is assessed by a conforming schema-aware processor with respect to the referenced XML Schema documents in the model's definition documents. [XML Schema Structures]
Each document in the model MUST satisfy all applicable Schematron constraints constraints when validated in the #ALL phase.
Each document in the model MUST satisfy all applicable sml:acyclic and sml:target* constraints.
Each document in the model MUST satisfy all applicable SML identity constraints.
All documents in the model are available to the model validator. If any model document is not reachable, then the model validator's behavior is implementation-defined.

7. SML Extension Reference

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

7.1 Attributes

7.1.1 sml:acyclic

Used to specify that a complex type 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 complex type D, 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 complex type declaration whose instances can not create any cycles:

<xs:complexType name="Hostref" sml:acyclic="true">
...
</xs:complexType>

If the sml:acyclic attribute is not specified or set to false for a complex type declaration, then instances of this type may create cycles in a model.

7.1.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.

7.1.3 sml:nilref

This global attribute is used to identify null reference elements. This attribute MUST NOT be used on an element unless it also has sml:ref="true" specified.

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

Any element that has sml:nilref="true" or sml:nilref="1" will be treated as a null reference element.

7.1.4 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 any element declarations. 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="tns:HostOSRefType"
         sml:targetElement="win:Windows"
         minOccurs="0"/>
 
<xs:complexType name="HostOSRefType">
  <xs:sequence>
    <xs:any namespace="##any" processContents="lax" minOccurs="0"
     maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

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

7.1.5 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 null or contain an unresolved reference which does not target any element in the model. Therefore it is an error if targetRequired="true" is specified on an element declaration where the corresponding reference element R has sml:nilref="true".

<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="tns:HostOSRefType"
                  sml:targetRequired="true"/>
    </xs:sequence>
</xs:complexType>

<xs:complexType name="HostOSRefType">
  <xs:sequence>
    <xs:any namespace="##any" processContents="lax" minOccurs="0"
     maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

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

7.1.6 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 any element declarations. 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="tns:OperatingSystemRefType"
                      sml:targetType="ibm:LinuxType"
                      minOccurs="0"/>

<xs:complexType name="OperatingSystemRefType">
  <xs:sequence>
    <xs:any namespace="##any" processContents="lax" minOccurs="0"
     maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

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

7.2 Elements

7.2.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.2.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="optional"/>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
    </xs:element>>

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

7.2.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.2.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.3 XPath functions

7.3.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

[SML-IF 1.1]: Service Modeling Language Interchange Format Version 1.1, James Lynn, Bhalchandra Pandit, Valentina Popescu, Virginia Smith, Editors. World Wide Web Consortium, @@ @@@@ @@@@. This version of the Service Modeling Language Interchange Format specification is available at http://www.w3.org/TR/@@@@/WD-sml-if-@@@@@@@@/. The latest version of the Service Modeling Language Interchange Format Version 1.1 specification is available at http://www.w3.org/TR/sml-if
[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.
[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]: 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 1.0 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 1.0 Part 2 is available at http://www.w3.org/TR/xmlschema-2.
[XPath]: 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 Non-Normative 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.