This specification defines the Service Modeling Language, Version 1.1 (SML) used to model complex services and systems, including their structure, constraints, policies, and best practices. SML is based on a profile of XML Schema and Schematron.
This is the first Public Working Draft of the Service Modeling Language, Version 1.1
specification for review by W3C members and other
interested parties. It has been developed by the
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 (
This document was produced by a group operating under the
Last Modified: $Date: 2007/08/07 22:09:18 $
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 a profile of XML Schema 1.0 [
Rules ― are Boolean expressions that constrain
the structure and content of documents in a model. SML uses a
profile of Schematron [
One of the important operations on the model is to establish its validity. This involves checking whether all data in a model satisfies the schemas and rules declared.
This specification focuses primarily on defining the profile of XML Schema and Schematron used by SML, as well as the process of model validation. It is assumed that the reader is familiar with XML Schema and Schematron.
The keywords "
A well-formed XML 1.0
A set of inter-related documents that describe a service
or system. Each
A
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
A
The
A
| Prefix | XML Namespace | Specification(s) |
|---|---|---|
sml
|
http://www.w3.org/2007/08/sml
|
This specification |
smlerr
|
http://www.w3.org/2007/08/sml-err
|
This specification |
smlfn
|
http://www.w3.org/2007/08/sml-function
|
This specification |
wsa
|
http://www.w3.org/2005/08/addressing
|
[ |
xs
|
http://www.w3.org/2001/XMLSchema
|
[ |
sch
|
http://purl.oclc.org/dsdl/schematron
|
[ |
xsi
|
http://www.w3.org/2001/XMLSchema-instance
|
XML Schema instance, as defined in [ |
SML uses a profile of W3C XML Schema 1.0 [
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:
A new data type that represents references to elements in other documents.
Multiple addressing schemes for representing references.
Constraints on the type of a referenced element.
The ability to define key, unique, and key reference constraints across inter-document references.
An SML reference is a link from one element to another. It can be
represented by using a variety of schemes, such as Uniform Resource
Identifiers (URIs) [
Reference elements sml:ref="true" or sml:ref="1" where
sml:ref is a global attribute whose declaration is as follows:
An element that has sml:ref="true"
The following example illustrates the use
of sml:ref. Consider the
following schema fragment:
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:
The first EnrolledCourse element in the above example
is a reference element since it specifies
sml:ref="true". Assuming that references are
represented using URI and EPR schemes, it has two representations of the
reference to the element for course PHY101. The second and third
EnrolledCourse elements are not reference elements; the
second element specifies sml:ref="false" and
the third element does not specify the sml:ref
attribute. Note that the second element has a child element that
contains a reference scheme referring to course MAT100, but this reference will be
ignored since sml:ref="false" for the second
element.
A reference element EnrolledCourse element declaration:
The above declaration allows null values for
instances of EnrolledCourse. Thus, an EnrolledCourse
reference element can have null value as shown in the following
example (the first EnrolledCourse
element has null value):
SML also supports several schema-based constraints on
reference elements. The sml:refType type has been defined to
allow model authors to make use of these schema-based constraints in
their model's schema. The definition of sml:refType fixes
the value of sml:ref to true, and hence all
elements of type sml:refType are reference elements.
The sml:refType is defined as follows:
Note that
the above definition allows elements and attributes from any namespace to
occur in an element whose type is sml:refType. Thus, a scheme for reference elements
can be implemented by defining an
XML namespace for the scheme, and references can be represented in this
scheme by nesting element and attribute instances from this namespace as
attributes and children of sml:refType elements.
The
following example illustrates the use of sml:refType:
The EnrolledCourse
element declaration is of
type sml:refType which marks it as a
document reference, and this element declaration is used in
StudentType to reference the elements
corresponding to the courses in which a student is enrolled.
Examples of the use of sml:refType for
EnrolledCourse are found in the section
An element that has either sml:ref="true" or sml:ref="1" specified.
Although either sml:ref="true" or
sml:ref="1" can be used to identify an SML reference element,
for the sake of brevity and consistency, the rest of this specification uses
sml:ref="true" in examples and other definitions.
A reference element with xsi:nil="true" or no content, provided
that it is allowed by the element's declaration.
A non-null reference whose target does not exist.
Every reference element
If a single reference element has multiple representations,
every representation
An element in a document
A
Each deref() XPath extension function
that is capable of resolving references expressed in the model
validator's chosen scheme(s). This function takes a node-set of
elements and returns a node-set consisting of element nodes
corresponding to the elements referenced by the input node set. In
particular, for each node R in the input node set the output
node set contains at most one element node.
The output node set contains one element node for R provided that all of the following conditions are true
sml:ref
="true"
for R
R contains at least one reference scheme that is understood by the implementation
The reference targets a single element in some document in the model
The output node set contains no element node corresponding to R if any of the following conditions is true
the target of R is not in the model
R is an empty or null reference
R does not contain any reference scheme that is understood by the implementation
sml:ref is not specified for R
sml:ref is specified for R and its value is neither "true" nor "1".
A reference
References that are represented using the URI scheme
sml:uri global element as a child of reference elements,
i.e., elements for which sml:ref="true". More precisely,
if a
It sml:uri global element declaration
as a child of the reference element.
It 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 EnrolledCourse will appear as follows:
where http://www.university.example.org/someUri is a
valid URI as defined in [
Suppose that a
| 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:
Fragment identifiers in references that are represented using the
URI scheme
The expression specified
for the xpointer scheme
the union ("|") operator defined for XPath 1.0
point() and range() node
tests defined for the xpointer() scheme
This expression can only use the functions defined in the
XPath 1.0 core function library [smlfn:deref
function and/or the following functions defined for xpointer()
scheme [
range-to
string-range
range
range-inside
start-point
end-point
here
origin
The following example illustrates the use of xpointer
fragments. Consider the case where all courses offered by MIT are stored in a
single XML document – Courses.xml –
whose URI is http://www.university.example.org/Universities/MIT/Courses.xml. In this case, the element inside
Courses.xml that corresponds to the course
PHY101 can be referenced as follows (assuming that Coursesis the root element in
Courses.xml)
A reference element can also be used to reference an element in its own document. To see this consider the following instance document
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 wsa:EndpointReference global element declaration [EnrolledCourse reference that references course PHY101 in MIT university can be
represented using the EPR scheme:
[Example Under Construction]
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 These attributes These attributes sml:refType or a derived type of sml:refType.
Note that this specification specifies sml:acyclic="false" for
type sml:refType.
sml:acyclic attribute on derived types of
sml:refType. This is a boolean attribute and its value can be
either true or false. Let R be a
derived type of sml:refType. If
sml:acyclic="true" is specified for R, then
R is an acyclic reference type, i.e., instances of
R
A cyclic reference type can be used to derive cyclic or acyclic reference
types, but all derived types of an acylic reference type are acyclic. Model
validators that conform to this specification
If CR is a cyclic reference
type and DCR
is a derived type of
CR, then DCR
is an acyclic
reference if sml:acyclic="true" is specified for
DCR
. Otherwise,
DCR
is a cyclic reference
If AR is an acyclic
reference type and DAR
is a derived type of
AR, then sml:acyclic="true" holds for
DAR
even if the sml:acyclic
attribute is not explicitly specified for
DAR
. It is an error for
DAR
to specify
sml:acyclic="false"
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
If one/more of sml:target* attributes are specified (either
explicitly or by default) for a 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
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.
sml:targetElement attribute on element declarations whose type
is sml:refType or a derived type of sml:refType.
The value of this attribute sml:targetElement="ns:GTE" for some element
declaration E. Then each element instance of
E
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
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
, section
3.9.6, Constraints on Particle Schema Components
,
[
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.
sml:targetRequired attribute on element declarations whose
type is sml:refType or a derived type of
sml:refType. If sml:targetRequired
="true" for an element declaration E, then
each element instance of E "false".
Model validators that conform to this specification
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"
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
, section
3.9.6, Constraints on Particle Schema Components
,
[
If sml:targetRequired="true" for a particle P then
sml:targetRequired="false"
The sml:targetType attribute sml:refType or a derived type of sml:refType.
The value of this attribute sml:targetType="ns:T" for some element
declaration E. Then each element instance of
E
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
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
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.
| 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 [
If an SML identity constraint needs to be
specified for an element declaration E, then it 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
If the ref attribute is
specified for an sml:key element, then the value of
ref attribute
If the ref attribute is
specified for an sml:unique element then the value of
the ref attribute
If the ref attribute is
specified for an sml:keyref element then the value of
the ref attribute
If the ref attribute is
specified for an SML identity constraint, then the name
attribute
If the ref attribute is
specified for an SML identity constraint, then the
selector and field
child elements
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
The sml:selector XPath
expression
The sml:field XPath expression
Each SML identity constraint that is
specified for a global element declaration G
Each SML identity
constraint that is specified for a particle P in
a complex-type definition CT
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
The following example will be used to illustrate the sml:key,
sml:unique, and sml:keyref constraints across
references.
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
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:
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:
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:
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 smlfn:deref() extension function, as its constraint language. 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 [
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
A Schematron pattern embedded in the
xs:annotation/xs:appinfo element for a complex
type definition or an element declaration is applicable to all instances of
the complex type or element. In the above example, the pattern
Length is applicable for all elements whose
type is IPAddress or a derived type
of IPAddress. A pattern can have one or
more context attribute. The value of the
context attribute is an XPath expression that
is evaluated in the context of each applicable element, and results in an
element node set for which the assert and report test expressions defined in
the rule are evaluated. In the above example
context="." therefore the two assert
expressions are evaluated in the context of each applicable element, i.e.,
each element of type IPAddress. The
test expression for an assert is a
boolean expression, and the assert is
violated (or fires) if its test expression evaluates to false. For example,
the following XML document violates the assert that requires an IPv6 address to have sixteen address
bytes
In general, a rule element can include multiple assert and report elements.
A report also specifies a test
expression, just like an assert.
However, a report is violated (or
fires) if its test expression evaluates to true. Thus, an
assert can be converted to a
report by simply negating its test expression.
The following example uses report elements to represent the IP address constraints of the previous
example:
If an assert or report is violated, then
the violation must be reported during
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:
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:
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 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
Each Schematron pattern
that is embedded in the xs:annotation/xs:appinfo
element for a global complex-type definition
CT
Each Schematron pattern that is embedded in the
xs:annotation/xs:appinfo element for a global element
declaration G
A pattern rule elements of the
pattern in the order of their definition. The context expression for
a rule
StrictUniversity
expressed in a separate document:
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, 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
smlerr:localizationid
attributes in a model; they 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.
SML supports a conforming profile of Schematron. All elements and attributes are supported.
If the queryBinding
attribute is specified, then its value
Schematron has rich support for natural-language error
and diagnostic messages that provide details about failed assertions. As per
the Schematron specification the content of the
sch:assert,
sch:report, and the optional
sch:diagnostic elements should be natural
language assertions or messages. To facilitate machine processable output
from the evaluation of Schemtron rules, this specification extends Schematron
by adding support for structured XML output that provides details about
failed assertions. This structured XML data can be consumed by an application
to perform some application-specific tasks required to handle a failed
assertion. This is an smlerr:output element smlerr:output
elements in a model; they 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:
id = a required attribute that defines the
identity of an smlerr:output element. This identity is used by an assert and/or report element
to specify that the expression specified in the expression attribute of the smlerr:output element must be evaluated to
generate structured XML when the assert/report fires. This identity is specified on one or more assert and/or report elements'
smlerr:outputids attribute. Each time such an assert or report fires, the
smlerr:output element's expression attribute is evaluated to generate
structured XML.
applicationUri = an optional attribute that specifies the
identity of the application for which the output is generated
expression= an XPath 1.0 expression that evaluates to a node
set containing element and attribute nodes only. If the node set contains
namespace, processing instructions, comments, or text nodes, then no output
is generated. The expression is evaluated in the context of the node selected
by the context attribute in the parent sch:rule
element. This XPath expression can use the deref() extension
function.
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.
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.
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.
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 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
If the report with id="v4" fires for an element
ipaddress of type IPAddressType, then the output
may look like
The following example illustrates an
smlerr:output element whose expression results
in attribute nodes
If the assert fires for an element of type
universityType then the output may look
like
Each
Each XML Schema document in the model's
definition documents
Each Schematron document in the model's
definition documents
Each document in the model
Each document in the model sml:target* and Schematron constraints
The model
A phase in schematron can be used to define a collection of patterns. A schematron processor can optionally evaluate only rules within a specific phase. For model validation, rule evaluation happens on the #ALL phase, implying that every rule in every pattern is evaluated.
This section is a non-normative reference of the SML extensions to XML Schema and XPath 1.0.
A complex type representing a reference to an element.
No specific
scheme is mandated for representing references, and a sml:refType can only
be used with element declarations; it is not supported on attribute
declarations.
Used to specify that a derived type of sml:refType is
acyclic, i.e., its instances do not create any cycles in a model.
If this attribute is set to true for a
derived type D of
sml:refType, then instances of D (including any derived
types of D) can not create any cycles
in a model. More precisely, the directed graph whose nodes are documents that
contain the source or target elements for instances of
D, and whose edges are instances of
D (an edge is directed from the document
containing the source element to the document containing the target element),
must be acyclic. A model is invalid if its documents result in a cyclic
graph using instances of D. In
the following example, Hostref is a restricted derived type of sml:refType
and its instances can not create any cycles:
If
the sml:acyclic attribute is not
specified or set to false for a derived type of
sml:refType, then instances of this reference
type may create cycles in a model. Note that sml:acyclic
is specified as "false" for sml:refType; hence
its instances are allowed to create cycles in a model.
This global attribute is used to identify reference elements.
Any element that has sml:ref="true" will be treated as a reference element. Note that sml:ref="true" for all elements whose type is sml:refType or a derived type sml:refType.
A QName representing the name of a referenced element
sml:targetElement is supported as an attribute for element
declarations whose type is
sml:refType or a type derived by restriction
from sml:refType. The value of this
attribute must be the name of some global element declaration. Let
sml:targetElement="ns:GTE" for some element declaration
E. Then each element instance of E must
target an element that is an instance of ns:GTE or an
instance of some global element declaration in the substitution group
hierarchy whose head is ns:GTE.
In the following example, the element referenced by
instances of HostOS must be instances
of win:Windows
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 empty or null, or contain a dangling reference which does not target any element in the model.
In the
following example, the targetRequired attribute is used to specify that application instances must have
a host operating system.
A model is invalid if its documents violate one/more
sml:targetRequired constraints.
A QName representing the type of a referenced element
sml:targetType is supported as an attribute for element
declarations whose type is
sml:refType or a type derived by restriction
from sml:refType. If the value of this
attribute is specified as T, then the
type of the referenced element must either be T or a derived type of T. In
the following example, the type of the element referenced by the
OperatingSystem element must be
"ibm:LinuxType" or its derived
type
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.
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.
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.
sml:unique is supported in the
appinfo of an xs:element.
Specifies a reference in URI scheme.
This element must be used to specify references that use the URI scheme.
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,
will resolve the reference in element
Student. The target of the reference must
always be an element.
This sample model illustrates the use of the following SML extensions:
Inter-document references
key and keyref constraints
User-defined constraints
The editors acknowledge the members of the Service Modeling Language Working Group, the members of other W3C Working Groups, and industry experts in other forums who have contributed directly or indirectly to the process or content of creating this document.
At the time this specification was published, the members of the Service Modeling Language Working Group were:
John Arwe (IBM Corporation), Jordan Boucher (Sun Microsystems, Inc.), Pratul Dublish (Microsoft Corporation), Zulah Eckert (BEA Systems, Inc.), Sandy Gao (IBM Corporation), Heather Kreger (IBM Corporation), Philippe Le Hégaret (W3C/MIT), Paul Lipton (CA), James Lynn (HP), Kumar Pandit (Microsoft Corporation), Valentina Popescu (IBM Corporation), Virginia Smith (HP), Michael Sperberg-McQueen (W3C/MIT), Bassam Tabbara (Microsoft Corporation), Vijay Tewari (Intel Corporation), Marvin Waschke (CA), Kirk Wilson (CA), Brian You (IBM Corporation).