Draft Specification

Version 1.0, 28 February 2007

Authors

John Arwe, IBM

Jordan Boucher, Sun

Pratul Dublish, Microsoft

Zulah Eckert, BEA

Dave Ehnebuske, IBM

Jon Hass, Dell

Steve Jerman, Cisco

Heather Kreger, IBM

Vincent Kowalski, BMC

Milan Milenkovic, Intel

Bryan Murray, HP

Phil Prasek, HP

Junaid Saiyed, EMC

Harm Sluiman, IBM

Bassam Tabbara, Microsoft

Vijay Tewari, Intel

William Vambenepe, HP

Marv Waschke, CA

Andrea Westerinen, Microsoft

Permission to copy and display the Service Modeling Language Specification, in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of the Service Modeling Language Specification, or portions thereof, that you make:

1. A link or URL to the Service Modeling Language Specification at this location:

http://www.serviceml.org/SML-200702.pdf

2. The copyright notice as shown in the Service Modeling Language Specification.

BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun (collectively, the “Authors”) each agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions to their respective patents that they deem necessary to implement the Service Modeling Language Specification.

THE SERVICE MODELING LANGUAGE SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SERVICE MODELING LANGUAGE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE SERVICE MODELING LANGUAGE SPECIFICATION.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Service Modeling Language Specification or its contents without specific, written prior permission. Title to copyright in the Service Modeling Language Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

Abstract

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

Status

This specification is the first draft of a work in progress. It is being published to solicit feedback. A feedback agreement is required before the working group can accept feedback. Please contact sml-feedback@external.cisco.com for details.

At some future date, the contents may be published under another name or under several new specifications, as shall be agreed by the authors and their respective corporations at that time.

Table of Contents

Service Modeling Language. 1

2. Notations and Terminology. 7

2.1 Notational Conventions 7

2.2 Terminology. 7

2.3 XML Namespaces 7

3. Schemas. 8

3.1 XML Schema Profile. 8

3.1.1 <xs:redefine>. 8

3.1.2 Unqualified Local Elements 9

3.1.3 targetNamespace on <xs:schema>. 9

3.2 References 9

3.2.1 Reference Semantics 13

3.2.1.1 At Most One Target 13

3.2.1.2 Multiple References 13

3.2.1.3 Empty or Null References 13

3.2.1.4 deref() XPath Extension Function. 14

3.3 Reference Schemes 14

3.3.1 URI Scheme. 14

3.3.1.1 Fragment Identifier 15

3.3.2 EPR Scheme. 17

3.4 Constraints on References 17

3.4.1 sml:acyclic 18

3.4.2 Constraints on Targets 18

3.4.2.1 sml:targetElement 19

3.4.2.2 sml:targetRequired. 20

3.4.2.3 sml:targetType. 20

3.5 Identity Constraints 21

3.5.1 University Example. 22

3.5.2 sml:key and sml:unique. 24

3.5.3 sml:keyref 25

4. Rules. 25

4.1 Localization of Error Messages 30

4.2 Schematron Profile. 30

4.2.1 Limited Support 30

5. Structured XML output from Schematron Rules. 30

5.1 smlerr:output 31

5.1.1 smlerr:outputids 31

5.1.2 smlerr:attributeNode. 31

5.1.3 smlerr:errorData. 32

5.1.4 Semantics 32

5.1.5 Examples 32

6. Model Validation. 35

6.1 Schematron Phase. 35

7. SML Extension Reference. 35

7.1 Types 35

7.1.1 sml:refType. 35

7.2 Attributes 36

7.2.1 sml:acyclic 36

7.2.2 sml:ref 36

7.2.3 sml:targetElement 36

7.2.4 sml:targetRequired. 37

7.2.5 sml:targetType. 37

7.4 XPath functions 38

7.4.1 smlfn:deref 38

8. Open Issues. 38

9. Acknowledgements. 39

10. References. 39

Appendix I – Normative SML Schema. 41

Appendix II – Normative SML Error Schema. 45

Appendix III – Sample Model 47

1. Introduction

The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex IT services and systems. These models typically include information about 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 be functional.
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 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 enable increased automation of management tasks. Automation facilities exposed by the majority of IT services/systems today could be driven by software – not people – 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 an IT service, as well as the constraints that each part must satisfy for the IT service to function properly. Constraints are captured in two ways:

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

2. Rules – are Boolean expressions that constrain the structure and content of documents in a model. SML uses a profile of Schematron [4,5,6] and XPath 1.0 [9] for rules.

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

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

2. Notations and Terminology

2.1 Notational Conventions

In this document, the keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in RFC 2119 [13].

2.2 Terminology

Document

A well-formed XML 1.0 document (see [12] for a detailed definition)

Model

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

Rule

A Boolean expression that constrains the structure and content of a set of documents in a model.

Model Definition

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

Model Instance

The subset of documents in a model that describe the structure and content of the modeled entities.

Model Validation

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

Model Validator

An embodiment capable of performing model validation

2.3 XML Namespaces

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

Table 1: XML Namespaces used in this specification.

Prefix	XML Namespace	Specification(s)
sml	http://schemas.serviceml.org/sml/2007/02	This specification
smlerr	http://schemas.serviceml.org/smlerr/2007/02	This specification
smlfn	http://schemas.serviceml.org/sml/function/2006/07	This specification
wsa	http://www.w3.org/2005/08/addressing	[WS Addressing Core]
xs	http://www.w3.org/2001/XMLSchema	[XML Schema]
sch	http://purl.oclc.org/dsdl/schematron	[Schematron]
xsi	http://www.w3.org/2001/XMLSchema-instance	[Xml Schema Instance]

3. Schemas

SML uses a profile of W3C XML Schema 1.0 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.

3.1 XML Schema Profile

SML supports a strict subset of XML Schema 1.0. This section describes the XML Schema features that are not supported or have limited support in SML. A justification is provided for each feature. A model validator MUST reject a model if the model’s definition documents contain one/more XML Schema documents with any of these features.

3.1.1 <xs:redefine>

xs:redefine is not supported in SML and MUST NOT be used in any schema document that is a part of a model’s definition documents.

xs:redefine is a feature for schema evolution and versioning in XML Schema. This feature enables schema authors to define a new version of a schema component, and completely replace the original schema component with the new version. XML Schema does not guarantee that the new version of the component is compatible with the original component. Thus, it is possible to break existing schema components that depend on the original component.

3.1.2 Unqualified Local Elements

Unqualified local elements are not supported in SML and MUST NOT be used in any schema document that is a part of a model’s definition documents.

Local element declarations MUST describe elements with qualified names. This can be done, for example, by specifying elementFormDefault=”qualified” on <xs:schema> or by specifying form=”qualified” on local <xs:element>.

This is to avoid element name collisions, and maintain a consistent naming approach especially when dealing with different schemas.

3.1.3 targetNamespace on <xs:schema>

targetNamespace on xs:schema MUST always be specified in all schema documents that are a part of a model’s definition documents.

XML schemas without target namespaces are not supported. They do not work well with XPath expressions used in constraints within the schema.

3.2 References

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

Support for inter-document references includes:

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

· Multiple addressing schemes for representing references.

· Constraints on the type of a referenced element.

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

An SML reference is a link from one element to another. It can be represented by using a variety of schemes, such as Uniform Resource Identifiers (URIs) [7] and Endpoint References (EPRs) [8]. 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.

References MUST be identified by sml:ref=”true” where sml:refis a global attribute whose definition is as follows:

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

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

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

<xs:element name="EnrolledCourse">

<xs:complexType>

<xs:sequence>

<xs:element name="Name" type="xs:string"/>

<xs:element name="Grade" type="xs:string"/>

<xs:any namespace="##any" minOccurs="0"

maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:element>

<xs:complexType name="StudentType">

<xs:sequence>

<xs:element name="ID" type="xs:string"/>

<xs:element name="Name" type="xs:string"/>

<xs:element name="EnrolledCourses" minOccurs="0">

<xs:complexType>

<xs:sequence>

<xs:element ref="tns:EnrolledCourse"

maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

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

<Student xmlns="urn:university"

xmlns:sml="http://schemas.serviceml.org/sml/2007/02"

xmlns:wsa="http://www.w3.org/2005/08/addressing">

<sml:uri>

/Universities/MIT/Courses.xml#xmlns(u=urn:university)

xpointer(/u:Courses/u:Course[u:Name=’PHY101’])

</sml:uri>

<wsa:EndpointReference>

<wsa:Address>http://www.university.example</wsa:Address>

<wsa:ReferenceParameters>

</University>

</Course>

</wsa:ReferenceParameters>

</wsa:EndpointReference>

</EnrolledCourse>

<sml:uri>

/Universities/MIT/Courses.xml#xmlns(u=urn:university)

xpointer(/u:Courses/u:Course[u:Name=’MAT100’])

</sml:uri>

</EnrolledCourse>

<Name>SocialSkills</Name>

</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 in 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 to course MAT100, but this reference will be ignored since sml:ref=”false” for the second element.

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

<xs:element name="EnrolledCourse" nillable="true">

<xs:complexType>

<xs:sequence>

<xs:element name="Name" type="xs:string"/>

<xs:element name="Grade" type="xs:string"/>

<xs:any namespace="##any" minOccurs="0"

maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:element>

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

<Student xmlns="urn:university"

xmlns:sml="http://schemas.serviceml.org/sml/2007/02"

xmlns:wsa="http://www.w3.org/2005/08/addressing">

<sml:uri>

/Universities/MIT/Courses.xml#xmlns(u=urn:university)

xpointer(/u:Courses/u:Course[u:Name=’MAT100’])

</sml:uri>

</EnrolledCourse>

<Name>SocialSkills</Name>

</EnrolledCourse>

</EnrolledCourses>

</Student>

SML also supports several schema-based constraints on references. 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:refto true, and hence all elements of type sml:refType are reference elements. The sml:refType is defined as follows:

<xs:complexType name="refType" sml:acyclic="false">

<xs:sequence>

<xs:any namespace="##any" minOccurs="0"

maxOccurs="unbounded"

processContents="lax"/>

</xs:sequence>

<xs:attribute ref="sml:ref" use="required"

fixed="true" />

<xs:anyAttribute namespace="##any"

processContents="