This document is also available in these non-normative formats: XML.
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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 uses XML Schema and is based on a profile of Schematron.
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 second 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.
1. Introduction (Non-Normative)
2. Notations and Terminology
2.1 Notational Conventions
2.2 Terminology
2.3 XML Namespaces
3. Dependencies on Other Specifications
4. Schemas
4.1 References
4.1.1 Reference Definitions
4.1.1.1 SML Reference
4.1.1.2 Null Reference
4.1.1.3 Unresolved Reference
4.1.2 Reference Semantics
4.1.2.1 At Most One Target
4.1.2.2 Multiple References
4.1.2.3 Null References
4.1.2.4 deref() XPath Extension Function
4.2 Reference Schemes
4.2.1 URI Scheme
4.2.1.1 Fragment Identifier
4.2.2 EPR Scheme
4.3 Constraints on References
4.3.1 sml:acyclic
4.3.1.1 Mapping from Schema
4.3.1.2 Rules
4.3.1.3 Validation
4.3.2 Constraints on Targets
4.3.2.1 sml:targetElement
4.3.2.2 sml:targetRequired
4.3.2.3 sml:targetType
4.4 Identity Constraints
4.4.1 University Example
4.4.2 sml:key and sml:unique
4.4.3 sml:keyref
5. Rules
5.1 Localization of Error Messages
5.1.1 smlerr:localizationid
5.2 Schematron Profile
5.2.1 Limited Support
6. Structured XML Output
from Schematron Rules
6.1 smlerr:output
6.1.1 smlerr:outputids
6.1.2 smlerr:attributeNode
6.1.3 smlerr:errorDataType
6.1.4 Semantics
6.1.5 Examples
7. Conformance Criteria
8. SML Extension Reference
8.1 Attributes
8.1.1 sml:acyclic
8.1.2 sml:ref
8.1.3 sml:nilref
8.1.4 sml:targetElement
8.1.5 sml:targetRequired
8.1.6 sml:targetType
8.2 Elements
8.2.1 sml:key
8.2.2 sml:keyref
8.2.3 sml:unique
8.2.4 sml:uri
8.3 XPath functions
8.3.1 smlfn:deref
9. References
9.1 Normative References
9.2 Informative References
A. Normative SML Schema
B. Normative SML Error Schema
C. Sample Model (Non-Normative)
D. Acknowledgements (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 inter-document references.
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 inter-document references, 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.
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].
A well-formed XML document, as defined in [XML].
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.
A rule is a boolean expression that constrains the structure and content of a set of documents in a model.
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 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.
A model instance is the subset of documents in a model that describe the structure and content of the modeled entities.
The model validation is the process of verifying that all documents in a model are valid with respect to the model's definition documents.
A model validator is an embodiment capable of performing model validation
Table 2-1 lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.
Prefix | XML Namespace | Specification(s) |
---|---|---|
sml
|
http://www.w3.org/2007/09/sml
| This specification |
smlerr
|
http://www.w3.org/2007/09/sml-err
| This specification |
smlfn
|
http://www.w3.org/2007/09/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] |
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]. However, conforming implementations MAY additionally support later versions of the XML, XML Schema, Schematron or XPath specifications.
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:
References – XML Schema does not have any support
for inter-document references, although it does support
intra-document references through xs:ID
,
xs:IDREF
, xs:key
and xs:keyref
.
Inter-document references are fundamental to SML since a document is a
unit of versioning. SML extends XML Schema to support inter-document
references and a set of constraints on inter-document references.
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.
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:
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 in an SML model to another element from the same model. It can be represented by using a variety of schemes, such as 4.2.1 URI Scheme 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. An SML reference MAY use one or more reference schemes.
Reference elements MUST be identified by
sml:ref="true"
or sml:ref="1"
where
sml:ref
is a global SML attribute whose declaration is as follows:
<xs:attribute name="ref" type="xs:boolean" />
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.
An element that has sml:ref="true"
MUST be treated as a reference element.
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/09/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.
An EnrolledCourse
reference element can be a marked as a null reference if it defines the sml:nilref="true"
attribute as shown in the following example (the first EnrolledCourse
element is a null reference):
<Student xmlns="http://www.university.example.org/ns" xmlns:sml="http://www.w3.org/2007/09/sml" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <ID>1000</ID> <Name>John Doe</Name> <EnrolledCourses> <EnrolledCourse sml:ref="true" sml:nilref="true"> <Name>PHY101</Name> <Grade>A</Grade> </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>
Null references are different from empty references. An empty reference is a normal reference that just happen to be empty. For a null reference, the content of that reference is intentionally left empty, as an explicit declaration of intent from the document author that the reference must be empty.
In the above example, first reference EnrolledCourse
defines
the sml:nilref="true"
attribute which marks this as a null reference.
By setting the reference null, the document author makes an explicit declaration
that this Student
doesn't have an EnrolledCourse
with a name PHY101
and grade A
.
An element information item in an SML model instance document is an SML reference if and only if:
It has an attribute information
item whose [local name]
is ref
and whose [namespace name]
is http://www.w3.org/2007/09/sml
and whose [normalized value]
, after whitespace normalization
using collapse
following schema rules, is either "true"
or "1"
.
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/2007/09/sml
and whose [normalized value]
after whitespace normalization
using collapse
following schema rules, is either "true"
or "1"
.
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 search the reference for reference scheme information items. 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.
Every non-null reference MUST target (or resolve to) at most one element in a model. When a scheme or multiple schemes in a reference resolve to more than one target then the model is declared invalid.
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.
A model validator MUST not attempt to resolve null references. The question of whether a null reference is resolved to one or more targets is undefined; it is an ill-formed question.
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:
R is not an SML reference.
R is a null reference.
R does not contain any reference scheme that is understood by the implementation.
R does not target any element in the model.
A reference MAY be represented by using a variety of schemes, and SML does not mandate the use of any specific schemes. A reference scheme normally uses, but is not required to use, child elements, attributes or both to capture the information necessary to identify a resource. 4.2.1 URI Scheme 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.
The URI Scheme is based on the anyURI
type defined in the XML schema specification [XML Schema Datatypes]. 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 author 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 4.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 4.2.1 URI Scheme.
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>
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
the union ("|") operator defined for XPath
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]:
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 Courses
is 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.
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>
SML supports the following attributes for expressing constraints on reference elements.
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 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.
The sml:acyclic
attribute MUST be supported for any <xs:complexType> element.
The sml:target*
attributes MUST be supported for any <xs:element> element.
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.
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
.
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}.
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.
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 nodes are SML model instance documents and whose edges are SML references with [type definition] T (an edge is directed from the document containing the SML reference to the document containing the target element), must be acyclic.
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.
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 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.
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 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.
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 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
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:
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.2 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
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
Either the ref
attribute or the refer
attribute (but not both) MUST be specified for an
sml:keyref
element.
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 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 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.
The following example will be used to illustrate the sml:key
,
sml:unique
, and sml:keyref
constraints across
references.
<xs:complexType name="StudentRefType" sml:acyclic="false"> <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="tns:StudentRefType" sml:targetType="tns:StudentType"/> <xs:complexType name="CourseRefType" sml:acyclic="false"> <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="tns:CourseRefType" 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:complexType name="EnrolledStudentRefType" sml:acyclic="false"> <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="EnrolledStudent" type="tns:EnrolledStudentRefType" sml:targetType="tns:StudentType"/> <xs:complexType name="EnrolledCourseRefType" sml:acyclic="false"> <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="EnrolledCourse" type="tns:EnrolledCourseRefType" 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>
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.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.
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.
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/2007/09/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 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/09/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.
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.
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 Schematron 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.
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 expression that evaluates to a node
set. 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.
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"/>
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.
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>
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.
If the node set is empty, 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.
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/09/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)>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="tns:StudentRefType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="isPublic" type="xs:boolean"/> </xs:complexType> <xs:complexType name="StudentRefType" sml:acyclic="false"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </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/09/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>
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 Schema and XPath but MAY also support any future versions of these specifications.
The validator MUST perform Schematron rule evaluation on the #ALL phase, implying that every rule in every pattern is evaluated.
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]
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.
Each document in the model MUST satisfy all applicable sml:acyclic and sml:target* constraints.
This section is a non-normative reference of the SML extensions to XML Schema and XPath.
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.
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.
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.
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.
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.
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.
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
.
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
.
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
.
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.
<?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/09/sml" targetNamespace="http://www.w3.org/2007/09/sml" elementFormDefault="qualified" blockDefault="#all" version="1.0" xml:lang="en" finalDefault="" attributeFormDefault="unqualified"> <!-- References ========== --> <!-- CONTEXT: To be used in any <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 any <xs:element> --> <xs:attribute name="nilref" type="xs:boolean"> <xs:annotation> <xs:documentation> Specifies that the reference element denotes a “null” reference. To be used only on elements for which sml:ref="true". </xs:documentation> </xs:annotation> </xs:attribute> <!-- CONTEXT: To be used in any <xs:element> --> <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 any <xs:element>--> <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 any <xs:element>--> <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 any <xs:complexType>--> <xs:attribute name="acyclic" type="xs:boolean"> <xs:annotation> <xs:documentation> If this attribute is set to true for a type D 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="optional"/> </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>
<?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/09/sml-err" targetNamespace="http://www.w3.org/2007/09/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>
This sample model illustrates the use of the following SML extensions:
Inter-document references
key
and keyref
constraints
User-defined constraints
<?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/09/sml" xmlns:smlfn="http://www.w3.org/2007/09/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/09/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:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </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:complexType name="GuestAppRefType" sml:acyclic="false" mixed="false"> <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="GuestAppRef" type="tns:GuestAppRefType" 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:complexType name="OSRefType" sml:acyclic="false" mixed="false"> <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="OSRef" type="tns:OSRefType" 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/09/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/09/sml-function"/> <sch:pattern id="SecureApplication"> <sch:rule context="sm:Applications/sm:Application"> <sch:report test="smlfn:deref(.)[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="smlfn:deref(.)[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>
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), 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).