Service Modeling Language, Version 1.1 http://www.w3.org/TR/2008/WD-sml-20080114/ W3C Working Draft 14 January 2008 http://www.w3.org/TR/2008/WD-sml-20080114/ XML http://www.w3.org/TR/2007/WD-sml-20070806/ http://www.w3.org/TR/sml/ Bhalchandra Pandit Microsoft Corporation Valentina Popescu IBM Corporation Virginia Smith HP 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 third 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. English Last Modified: $Date: 2008/01/11 16:24:16 $ Introduction (Non-Normative) The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex services and systems. Depending on the application domain, these models may include information such as configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on. Models provide value in several important ways. Models focus on capturing all invariant aspects of a service/system that must be maintained for the service/system to function properly. Models represent a powerful mechanism for validating changes before applying the changes to a service/system. Also, when changes happen in a running service/system, they can be validated against the intended state described in the model. The actual service/system and its model together enable a self-healing service/system ― the ultimate objective. Models of a service/system must necessarily stay decoupled from the live service/system to create the control loop. Models are units of communication and collaboration between designers, implementers, operators, and users; and can easily be shared, tracked, and revision controlled. This is important because complex services are often built and maintained by a variety of people playing different roles. Models drive modularity, re-use, and standardization. Most real-world complex services and systems are composed of sufficiently complex parts.  Re-use and standardization of services/systems and their parts is a key factor in reducing overall production and operation cost and in increasing reliability. Models enable increased automation of management tasks. Automation facilities exposed by the majority of services/systems today could be driven by software ― not people ― both for reliable initial realization of a service/system as well as for ongoing lifecycle management. A model in SML is realized as a set of interrelated XML documents. The XML documents contain information about the parts of a service, as well as the constraints that each part must satisfy for the service to function properly. Constraints are captured in two ways: Schemas ― these are constraints on the structure and content of the documents in a model. SML uses XML Schema [, ] as the schema language. In addition SML defines a set of extensions to XML Schema to support references that may cross document boundaries. Rules ― are Boolean expressions that constrain the structure and content of documents in a model. SML uses a profile of Schematron [, , ] and XPath [] for rules. One of the important operations on the model is to establish its validity. This involves checking whether all data in a model satisfies the schemas and rules declared. This specification focuses primarily on defining the extensions to XML Schema for references that cross document boundaries, the profile of Schematron used by SML, as well as the process of model validation. It is assumed that the reader is familiar with XML Schema and Schematron. SML uses XML Schema [, ] to define constraints on the structure of data in a model. SML scenarios require several features that either do not exist or are not fully supported in XML Schema. These features can be classified as follows: SML references – XML documents introduce boundaries across content that needs to be treated as a unit. XML Schema does not have any support for references that cross documents, although it does support references within elements in the same document through xs:ID, xs:IDREF, xs:key and xs:keyref. References between elements defined in separate SML model documents are fundamental to the SML specification. SML extends XML Schema to support references that may cross document boundaries, and a set of constraints on those references that apply regardless of whether they cross document boundaries or not. Rules – XML Schema does not support a language for defining arbitrary rules on the structure and content of XML documents. SML uses Schematron to express assertions on the structure and content of XML documents. XML Schema supports two forms of extension: "attributes in different namespace" and "application information elements"; both forms are used by SML extensions. Notations and Terminology Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 []. The content of this specification is normative except for sections, notes, or texts that are explicitly marked as non-normative. If a section is marked as non-normative, then all contained sub-sections are non-normative, even if they are not explicitly marked as such. Terminology Document A well-formed XML document, as defined in []. Model A set of inter-related documents that describe a service or system.  Each model consists of two disjoint subsets of documents – model definition documents and model instance documents. Reference A link from one element in an SML model to another element from the same model. Schematron Constraint The information contained within a single sch:schema element. Rule A rule is a boolean expression that constrains the structure and content of a set of documents in a model. Rule bindings A rule binding is an association of a set of one or more rule documents with a set of zero or more model documents. The documents associated with a given rule document are said to be "bound" to it. For a model to be valid, every definition and/or instance document in the model must conform to the constraints defined by every rule document it is bound to. It is permissible for a rule document to have no bindings associated with it, and for a model document to be bound to zero rule documents. Rule document A rule document is a model definition document consisting of Schematron rules that conforms to the SML's profile of Schematron. Schema document A schema document is a model definition document that conforms to the XML Schema specification [XML Schema Structures] definition of a schema document. Model Definition Documents The subset of documents in a model that describes the schemas and rules that govern the structure and content of the model's documents. This specification defines two types of model definition document, schema documents and rule documents, but permits implementations to define other types of model definition documents. Such other types of model definition documents do not play any role in SML model validation. Model Instance Documents The subset of documents in a model that describes the structure and content of the modeled entities. Model Validation Model validation is the process of verifying that all documents in a model are valid with respect to the model's definition documents. Model Validator A model validator is an embodiment capable of performing model validation. Target-complete URI A target-complete URI is a URI or IRI that contains all the information required to locate a target of an SML reference. XML Namespaces lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant. XML Namespaces used in this specification. Prefix XML Namespace Specification(s) sml http://www.w3.org/2008/01/sml This specification smlerr http://www.w3.org/2008/01/sml-err This specification smlfn http://www.w3.org/2008/01/sml-function This specification 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 [] Dependencies on Other Specifications Other specifications on which this one depends are listed in []. Conforming implementations of this specification MUST support XML 1.0 [], XML Schema 1.0 [, ], Schematron [] and XPath 1.0 []. Conforming implementations MAY additionally support later versions of the XML, XML Schema, Schematron or XPath specifications. SML References Support for SML references in an SML model includes: The ability to use multiple reference schemes for representing references. An extensibility mechanism allowing new reference schemes to be defined. Constraints on the type of a referenced element. The ability to define key, unique, and key reference constraints across SML references. Conforming model validators MUST support SML references as defined by this specification. Reference Definitions SML Reference An element information item in an SML model instance document MUST be treated as a reference element if and only if: It has an attribute information item whose [local name] is ref and whose [namespace name] is http://www.w3.org/2008/01/sml and whose [normalized value] , after whitespace normalization using collapse following schema rules, is either "true" or "1". This mechanism enables schema-less identification of reference elements, i.e., reference elements can be identified without relying on PSVI. Although its normative definition allows several syntaxes to be used to identify an SML reference element, for the sake of brevity and consistency, the rest of this specification uses sml:ref="true" to denote an SML reference in examples and text. SML Null Reference An element information item in an SML model instance document is an SML null reference if and only if: It is an SML reference. It has an attribute information item whose [local name] is nilref and whose [namespace name] is http://www.w3.org/2008/01/sml and whose [normalized value] after whitespace normalization using collapse following schema rules, is either "true" or "1". Unresolved SML Reference An element information item in an SML model instance document is an unresolved SML reference if and only if: It is a non-null SML reference. None of the recognized reference schemes resolves. SML Reference Target The node set a non-null SML reference resolves to is its target. SML null references have no target. Reference Semantics A model validator MUST attempt to resolve an SML reference using all reference schemes of which the reference is recognized as an instance. At Most One Target Every non-null reference MUST target at most one element in a model. When a recognized scheme in a reference resolves to more than one target then the model MUST be declared invalid. Consistent References An SML model MUST be declared invalid when a recognized scheme resolves to a target that's different from the target resolved to by another recognized scheme or when one recognized scheme resolves and another does not. Identical Targets To determine if two targets are the same or different, a model validator MUST obey the following rules. A model validator MUST consider both targets to be the same when both of the following are true. The definition of the scheme(s) used to locate the targets specifies that the scheme uses target-complete URIs. [] The two URIs or IRIs used to locate the targets are identical using a case-sensitive, codepoint-by-codepoint comparison. A model validator MUST consider both targets to be different when there is something available in the element information items for the targets that tells them apart. For example, if there is an infoset property for which the 2 targets have different values, they are different. This applies recursively for complex-valued properties. For all other cases, it is implementation-defined whether to treat the targets as the same or not. Multiple References   An element in a document MAY be targeted by multiple reference elements. These reference elements may use different schemes and/or be expressed in different ways.   Null References A null reference is an explicit declaration of intent by the document author that the reference itself does not exist, and a processing directive (not a hint) to processors not to attempt to recognize any reference schemes in it. If a reference element is recognized as null, then processors MUST NOT attempt to resolve it. The question of whether a null reference is resolved or not is undefined; it is an ill-formed question. deref() XPath Extension Function Each SML processor MUST provide an implementation of the deref() XPath extension function. This function takes a node-set of elements and returns a node-set consisting of element nodes corresponding to the elements referenced by the input node set.  In particular, for each node R in the input node set the output node set contains at most one element node. The behavior of deref() function MUST satisfy the following constraints: If the implementation recognizes no scheme used in the reference, then deref() returns no target for R. If the implementation recognizes R as using N supported schemes, then deref() is not required to attempt to resolve all N schemes. Its behavior in this case is implementation-defined and the set of schemes that are actually attempted may be any subset of the recognized schemes. This is subject to the following constraints: If deref() doesn't attempt to resolve any scheme or if none of the attempted schemes resolves, then no target is returned. If at least one of the attempted schemes resolves to more than one target element, then 0 or 1 of the targets is returned. If one attempted scheme resolves to a target that's different from the target resolved by another attempted scheme, then 0 or 1 of the targets is returned. If one attempted scheme resolves and another doesn't, then 0 or 1 of the targets is returned. If none of the above is true (that is, all attempted schemes resolve to the same one and only one target element, call it T), then one target is returned (namely, T). Reference Schemes An SML reference MAY be represented by using a variety of schemes, including those defined in this specification. SML does not mandate the use of any specific schemes. A reference scheme MAY use child elements, attributes, both, or neither to capture the information necessary to identify the reference target. It is not required that all elements in an SML model be reachable via an SML reference. This will depend on the support defined by the chosen reference scheme. Although SML does not require the use of any specific scheme, it does specify how a reference MUST be represented when using SML-defined reference schemes. This specification defines the for identifying reference targets. All of the following MUST be defined for each SML reference scheme, The set of rules that, when satisfied, identify a reference element as containing one and the only instance of the scheme within that reference element. The set of rules that, when evaluated, resolve the containing reference to a set of target element nodes. An assertion that states whether or not the scheme uses target-complete URIs. A schema definition MAY impose additional requirements on references recognized as instances of that scheme. Such requirements, if any, MUST NOT be applied by scheme implementations to references that are not instances of the corresponding scheme. SML URI Scheme The SML URI Scheme is defined as follows: An SML reference element is identified as using the SML URI scheme if and only if exactly one element information item whose [local name] is uri and whose [namespace name] is http://www.w3.org/2008/01/sml is present as a child of that reference element. The SML URI scheme is resolved using the following steps: A document is obtained by dereferencing the URI reference, sans fragment identifier, using the appropriate operation defined for the scheme used in that URI reference. If there is no document retrieved, the scheme instance is unresolved. If a fragment identifier is not present in the URI reference, the scheme instance resolves to the root element of the retrieved document. If a fragment identifier is present in the URI reference, the scheme instance resolves to the set of elements obtained by applying the fragment identifier to the root element of the retrieved document. The SML URI Scheme can be used in an SML-IF [] document to reference documents from the interchange set. Scheme syntax: SMLURI ::= URI ('#' SMLXPath1_Fragment_ID)? where , URI is a URI reference without a fragment identifier. SMLXPath1_Fragment_ID is a production that defines the syntax of the fragment portion of the SML URI scheme. This is defined in section . The smlxpath1() scheme The smlxpath1() scheme is intended to be used with the XPointer Framework [] to allow addressing of elements. The uses it to encode fragment identifiers. This section describes the syntax and semantics of the smlxpath1() scheme and the behavior of XPointer processors with respect to this scheme. Scheme name: smlxpath1. Scheme syntax: SMLXPath1_Fragment_ID ::= 'smlxpath1' '(' SMLXPath1_SchemeData ')' SMLXPath1_SchemeData ::= XPath1.0_LocationPath where, XPath1.0_LocationPath is the LocationPath production defined in the XPath 1.0 specification []. The deref() XPath extension function MUST NOT be present in the expression evaluation context function library when processing the location path in SMLXPath1_SchemeData. Namespace Binding Context: The smlxpath1() scheme inherits the set of namespace bindings available to the containing element. Document Context: The document context is set by the URI reference containing the smlxpath1() scheme instance. The element(s) targeted by a scheme instance are obtained by applying the location path in SMLXPath1_SchemeData to the root element of the document in the document context. The result MUST be a set of elements. The set MAY be empty. If the result of applying the location path is something other than a set of elements, then the XPointer result is an error. Constraints on References SML supports the following attributes for expressing constraints on reference elements. Attributes Name Description sml:acyclic Used to specify whether cycles are prohibited for a reference. sml:targetRequired Used to specify that a reference's target element is required to be present in the model. sml:targetElement Used to constrain the name of the reference's target. sml:targetType Used to constrain the type of the reference's target. SML defines a new property for every Complex Type Definition schema component: {acyclic} An xs:boolean value. Required. The value of {acyclic} for xs:anyType is false. And 3 new properties for every Element Declaration component: {target required} An xs:boolean value. Required. {target element} An Element Declaration component. Optional. {target type} A Type Definition component. Optional. sml:acyclic sml:acyclic is used to specify that a cycle is not allowed for an SML reference type. Model validators that conform to this specification MUST support the sml:acyclic attribute on any element in a schema document. This attribute is of type xs:boolean and its actual value can be either true or false. Mapping from Schema {acyclic} of a complex type definition is as specified by the appropriate case among the following: If sml:acyclic is present, then {acyclic} has the actual value of this attribute. Otherwise, if its {base type definition} is a complex type definition, then {acyclic} has the same value of {acyclic} as its {base type definition}. Otherwise ({base type definition} is a simple type definition), {acyclic} is false. Schema Validity Rules If a complex type definition CT's {base type definition} is also a complex type definition and has {acyclic} true, then CT MUST have {acyclic} true. Instance Validity Rules If CT is a complex type definition with {acyclic} true, then instances of CT MUST NOT create cycles in the model. More precisely, the directed graph constructed in the following way MUST be acyclic: The nodes in the graph are all the elements resolved to by SML references of type CT or types derived from CT. If a node N is or contains an SML reference R of type CT or a type derived from CT, and R resolves to T (which must also be a node in the graph), then an arc is drawn from N to T. Constraints on SML Reference Targets SML defines three attributes: sml:targetRequired, sml:targetElement, and sml:targetType, for constraining the target of a reference. These three attributes are collectively called sml:target* attributes. Model validators that conform to this specification MUST support these attributes on all xs:element elements with a name attribute. Mapping from schema {target required} is as specified by the appropriate case among the following: If sml:targetRequired is present, then {target required} is the actual value of this attribute. Otherwise if the element declaration has a {substitution group affiliation}, then {target required} is the same as that of the {substitution group affiliation}. Otherwise if the element declaration ED is contained (directly, indirectly, or implicitly) in a content model of a complex type D, who is a restriction of another complex type B and B contains an element declaration EB with the same name as ED, then {target required} of ED is the same as that of EB. Otherwise {target required} is false. {target element} is as specified by the appropriate case among the following: If sml:targetElement is present, then its actual value MUST resolve to a global element declaration G, and {target element} is G. Otherwise if {substitution group affiliation} is present, then {target element} is the same as that of the {substitution group affiliation}. Otherwise if the element declaration ED is contained (directly, indirectly, or implicitly) in a content model of a complex type D, who is a restriction of another complex type B and B contains an element declaration EB with the same name as ED, then{target element} of ED is the same as that of EB. Otherwise {target element} is absent. {target type} is as specified by the appropriate case among the following: If sml:targetType is present, then its actual value MUST resolve to a global type definition T, and {target type} is T. Otherwise if {substitution group affiliation} is present, then {target type} is the same as that of the {substitution group affiliation}. Otherwise if the element declaration ED is contained (directly, indirectly, or implicitly) in a content model of a complex type D, who is a restriction of another complex type B and B contains an element declaration EB with the same name as ED, then {target type} of ED is the same as that of EB. Otherwise {target type} is absent. Schema Validity Rules Model validators that conform to this specification MUST enforce the following: If a global element declaration S has a {substitution group affiliation} G, then all the following are true: If G has {target required} true then S also has {target required} true. If G has {target element} TEG, then S has {target element} TES and TES is the same as TEG or is in the substitution group of TEG. If G has {target type} TTG, then S has {target type} TTS and TTS is validly derived from TTG. If 2 element declarations E1 and E2 have the same {namespace name} and {name} and they are both contained (directly, indirectly, or implicitly) in a content model of a complex type, then E1 and E2 have the same {target required}, {target element}, and {target type}. For a complex type D derived by restriction from its {base type definition} B, if an element declaration ED is included in D and an element declaration EB is included in B, and ED and EB satisfy the "NameAndTypeOK" constraint (for XML Schema’s definition of valid restrictions, see Schema Component Constraint: Particle Valid (Restriction), Constraints on Particle Schema Components in [XML Schema Structures]), then all the following are true: If EB has {target required} true then ED also has {target required} true. If EB has {target element} TEB, then ED has {target element} TED and TED is the same as TEB or is in the substitution group of TEB. If EB has {target type} TTB, then ED has {target type} TTD and TTD is validly derived from TTB. This note is non-normative. The above condition #2 on the use of sml:target* attributes has been defined to reduce the implementation burden on model validators for verifying condition #3, 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 condition #3. In order to verify condition #3, 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. Instance Validity Rules If an element declaration E has {target required} true, then each element instance of E that is also an SML reference MUST target some element in the model, (no instance of E can be a null or unresolved SML reference). If an element declaration E has {target element} TE, then each element instance of E that is also a resolved SML reference MUST target an element that is an instance of TE or an instance of some global element declaration in the substitution group of TE. If an element declaration E has {target type} TT, then each element instance of E that is also a resolved SML reference MUST target an element whose [type definition] is TT or a type derived from TT. Reference Constraints Summary (Non-Normative) The effect of the above instance validation rules is summarized in the following table. Target Constraints and SML Reference Categories. Acyclic targetRequired targetElement targetType Non-reference Satisfied Satisfied Satisfied Satisfied Null Satisfied Violated Satisfied Satisfied Unresolved Satisfied Violated Satisfied Satisfied Resolved Check Satisfied Check Check Identity Constraints XML Schema supports the definition of key, unique, and key reference constraints through xs:key, xs:unique, and xs:keyref elements. However, the scope of these constraints is restricted to a single document. SML defines analogs for these constraints, whose scope extends to multiple documents by allowing them to traverse SML references. Model validators that conform to this specification MUST support the following elements for defining identity constraints across references, as child elements of xs:element/xs:annotation/xs:appinfo where the xs:element has a name attribute: Name Description sml:key Similar to xs:key except that the selector and field XPath expression can use the smlfn:deref function sml:unique Similar to xs:unique except that the selector and field XPath expression can use the smlfn:deref function sml:keyref Similar to xs:keyref except that the selector and field XPath expression can use the smlfn:deref function SML defines a new property for every Element Declaration component: {SML identity-constraints definitions} A set of SML identity constraint definitions components, which have the same set of properties as XML Schema identity constraint definitions. Syntax and Semantics Names of all SML identity constraint definitions exist in a single symbol space, which is disjoint from any symbol space of XML Schema components. Mapping from Schema For each sml:key, sml:unique, or sml:keyref element without the ref attribute specified, {SML identity-constraints definitions} contains a component corresponding to this element, as specified in section 3.11 Identity-constraint Definitions of the XML Schema specification [XML Schema Structures]), where sml:selector and sml:field elements are used in place of xs:selector and xs:field. For each sml:key, sml:unique, or sml:keyref element with the ref attribute specified, {SML identity-constraints definitions} contains the component resolved to by the actual value of the ref attribute, with the following conditions: The name attribute MUST NOT be specified. The sml:selector and sml:field child elements MUST NOT be specified. If the element is sml:key, then the value of ref attribute MUST resolve to an SML key constraint. If the element is sml:unique, then the value of the ref attribute MUST resolve to an SML unique constraint. If element is sml:keyref, then the value of the ref attribute MUST resolve to an SML keyref constraint, and the refer attribute MUST NOT be specified. In addition to SML identity constraints obtained from the above explicit definitions or references, if an element declaration S has a {substitution group affiliation} G, then its {SML identity-constraints definitions} also contains members of {SML identity-constraints definitions} of G. If an element declaration ED is contained (directly, indirectly, or implicitly) in a content model of a complex type D, who is a restriction of another complex type B and B contains an element declaration EB with the same name as ED, then {SML identity-constraints definitions} of ED also contains members of {SML identity-constraints definitions} of EB. Schema Validity Rules {selector} in SML identity constraints has the same syntax as that defined in the XML identity constraint selector XPath syntax with one exception. The SML identity constraint {selector} XPath allows smlfn:deref() functions, 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)* The sml:field XPath expression MUST conform to the amended BNF defined above for the selector XPath expression with the following modification,to allow smlfn:deref() functions, nested to any depth, at the beginning of the expression. Path::= ('.//')?  ( Step '/')* ( Step | @NameTest ) |         DerefExpr ('/' @NameTest)? The {SML identity-constraints definitions} of an element declaration MUST NOT contain two identity constraints with the same name. This note is non-normative. This could happen if the ref attribute resolves to an identity constraint already contained in the same element declaration’s {SML identity-constraints definitions}. If a global element declaration S has a {substitution group affiliation} G, then {SML identity-constraints definitions} of S MUST be a superset of that of G. If two element declarations E1 and E2 have the same {namespace name} and {name} and they are both contained (directly, indirectly, or implicitly) in a content model of a complex type, then E1 and E2 MUST have the same set of {SML identity-constraints definitions}. This note is non-normative. 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. For a complex type D derived by restriction from its {base type definition} B, if ED is included in D and EB is included in B and ED and EB satisfies the "NameAndTypeOK" constraint (for XML Schema’s definition of valid restrictions, see Schema Component Constraint: Particle Valid (Restriction), Constraints on Particle Schema Components in [XML Schema Structures]), then {SML identity-constraints definitions} of ED MUST be a superset of that of EB. Instance Validity Rules Validation rules for SML identity constraints are the same as specified in section 3.11 Identity-constraint Definitions of the XML Schema specification [XML Schema Structures]), with the addition of support for the smlfn:deref() function. Rules XML Schema supports a number of built-in grammar-based constraints but it does not support a language for defining arbitrary rules for constraining the structure and content of documents. Schematron [] 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. Informal Description (Non-Normative) This section assumes that the reader is familiar with Schematron concepts; the Schematron standard is documented in [] and [, ] 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                                                                               A v4 IP address must have 4 bytes.                     A v6 IP address must have 16 bytes.                                                                               A Schematron constraint 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 (which is a part of the containing Schematron constraint) 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:                                                                                             A v4 IP address must have 4 bytes.                     A v6 IP address must have 16 bytes.                                                                                   If a sch:assert or sch:report is violated, the violation is reported together with the specified message. 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:               A v4 IP address must have 4 bytes instead of the specified           bytes.       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 specified ID                   does not begin with 99.                                                   The student must be enrolled                   in at least one course.                                                         The rules 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. Schematron patterns can be authored in separate rule documents which are next bound to a set of documents in the model. The following example shows the constraints for StrictUniversity expressed in a separate document:                                                                                       The specified ID                   does not begin with 99.                                                   The student must be enrolled                   in at least one course.                                       The binding of the StudentPattern pattern to instances of StrictUniversity element is implementation-dependent and hence outside the scope of this specification. Rule Support SML supports a conforming profile of Schematron. All elements and attributes are supported.   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. If the queryBinding attribute is not specified, then its value is assumed to be set to "xslt". Conforming implementations MUST support the "xslt" query binding. Conforming implementations MAY additionally support query bindings other than "xslt". Rules Embedded in Schema Documents SML defines a new property for every complex type definition schema component and every element declaration schema component. {rules} A set of Schematron constraints. Mapping from schema sch:schema elements can be embedded in members of the {application information} of the {annotation} of a global element declaration or a global complex type definition. They MUST NOT be embedded in any other kind of schema component. Let local-rules be the set of Schematron constraints attached to a global element declaration or a global complex type definition. The value of {rules} property of a schema component is computed as follows: The value of {rules} for xs:anyType is the empty set. If the schema component is a global element declaration, then the value of {rules} is same as its local-rules. If the schema component is a complex type definition, then the value of its {rules} is the union of its local-rules and the appropriate case from the following: If {base type definition} is a complex type definition, then {rules} of the {base type definition}. This is true for derivation by extension as well as for derivation by restriction. Otherwise ({base type definition} is a simple type definition, the empty set. Schema Validity Rules Model validators that conform to this specification MUST enforce the following rules. The value of {rules} MAY be non-empty for global element declarations, global complex type definitions or anonymous complex type definition of global element declarations. It MUST NOT be non-empty for any other schema component. The value of {rules} for a local element declaration MUST be the empty set. If a complex type D is derived by restriction or extension from {base type definition} B and if B has Schematron constraints defined on it then they are automatically copied to D and unioned with the Schematron constraints defined on D. If a complex type D is derived by restriction from {base type definition} B then, a global element declaration with non-empty {rules} contained in B cannot be restricted to a local element declaration in D. Consequently, it as an error if all of the following is true. An element declaration ED is contained (directly, indirectly, or implicitly) in D and an element declaration EB is contained (directly, indirectly, or implicitly) in B, ED and EB satisfy the "NameAndTypeOK" constraint (for XML Schema's definition of valid restrictions, see Schema Component Constraint: Particle Valid (Restriction), Constraints on Particle Schema Components in [XML Schema Structures]) EB is a reference to a global element declaration with a Schematron constraint on it. ED is a local element declaration with the same name as EB. Instance Validity Rules Model validators that conform to this specification MUST behave as follows:   Each Schematron constraint in {rules} of a complex-type definition CT MUST be evaluated for all element instances of type CT in a model during the model's validation. Each Schematron constraint in {rules} of 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 [], 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. If an assert or report is violated, then the violation MUST be reported during model validation together with the specified message. The model MUST be declared invalid when this happens. Rules Authored in Rule Documents Rule Binding Model validators that conform to this specification MUST provide a mechanism to support binding of Schematron patterns, authored in separate rule documents, to a set of documents in a model. The mechanism for binding such Schematron patterns to a set of documents in a model is implementation-dependent and hence outside the scope of this specification. Localization of natural-language messages SML defines the sml:locid attribute in support of localization of the natural-language texts or messages. Model validators that conform to this specification MAY support sml:locid attribute on the following elements: sch:assert and sch:report in a rule document. sch:assert and sch:report in a Schematron pattern embedded in the xs:annotation/xs:appinfo element for a complex type definition or an element declaration. Elements in instance documents where containing element has textual content, whenever allowed by schema. Conforming model validators that support the sml:locid attribute MUST use the sml:locid attribute value to access the location of the translated text. This note is non-normative. The mechanism for using the QName value of the sml:locid attribute to locate the translated text is implementation dependent. For example, the {namespace name} can be used to identify the resource containing the test and the {local name} can be used to identify the text within such resource. Refer to section for a concrete sample on how the sml:locid attribute can be used to support text localization. Variable substitution There is often the case that a sch:assert or sch:report message can be reused in different situations. To be able to re-use a message, the schema author must be able to substitute variable content based on the context in which the message is being used. Although this specification does not mandate how substitution variable is used in Schematron messages, it suggests the use of xsl:variable to achieve this support. Refer to section for a concrete sample on how the xsl:variable can be used in support of reusing localized messages. Conformance Criteria A program is a conforming SML model validator if it satisfies the following conditions: The validator MUST perform model validation as defined in this specification. Model validation is the process of examining each document in a model and verifying that this document is valid with respect to the model definition documents, i.e., each model instance document satisfies the schemas and rules defined in the applicable model definition documents. The validator MUST support XML ], XML Schema [], and XPath [] but MAY also support any future versions of these specifications. The validator MUST support Schematron []. The validator MUST perform Schematron rule evaluation on the #ALL phase. The validator MUST support the deref() XPath extension function. A set of XML documents is a conforming SML model if it satisfies the following conditions: Each document in the model MUST be a well-formed XML document [] Each XML Schema document in the model's definition documents MUST satisfy the conditions expressed in Errors in Schema Construction and Structure (§5.1). [] Each Schematron document in the model's definition documents MUST be a valid Schematron document [] A conforming SML model is valid if it satisfies all of the following conditions: In each instance document in the model, the [validity] property of the root element and all of its attributes and descendants MUST NOT be "invalid" when schema validity is assessed by a conforming schema-aware processor with respect to the referenced XML Schema documents in the model's definition documents. [] Each document in the model MUST satisfy all applicable Schematron constraints constraints when validated in the #ALL phase. Each document in the model MUST satisfy all applicable sml:acyclic and sml:target* constraints. Each document in the model MUST satisfy all applicable SML identity constraints. All documents in the model are available to the model validator. If any model document is not reachable, then the model validator's behavior is implementation-defined. SML Extension Reference (Non-Normative) This section is a reference of the SML extensions to XML Schema and XPath. Attributes sml:acyclic Used to specify that instances of an SML reference of a given type and its derived types do not create any cycles in a model If this attribute is set to true for a complex type CT, then instances of CT (including any derived types of CT) that are SML references cannot create any cycles in a model. In the following example, HostedOnRefType is a complex type declaration whose instances cannot create a cycle: ... If the sml:acyclic attribute is not specified or set to false for a complex type declaration, then instances of this type that are SML references may create cycles in a model. sml:ref This global attribute is used to identify reference elements.  Any element that has sml:ref="true" will be treated as a reference element. sml:nilref This global attribute is used to identify null reference elements. This attribute MUST NOT be used on an element unless it also has sml:ref="true" specified.  Any element that has sml:nilref="true" or sml:nilref="1" will be treated as a null reference element. sml:targetElement A QName representing the name of a referenced element   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 A model is invalid if its documents violate one/more sml:targetElement constraints. sml:targetRequired Used to specify that instances of a reference element must target elements in the model, i.e., an instance of the reference element can not be null or contain an unresolved reference which does not target any element in the model. Therefore it is an error if targetRequired="true" is specified on an element declaration where the corresponding reference element R has sml:nilref="true". 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. sml:targetType A QName representing the type of a referenced element     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 A model is invalid if its documents violate one/more sml:targetType constraints. sml:locid This attribute can be defined on the sch:assert, sch:report and on any element with a textual content, whenever the schema allows that. The sml:locid attribute is used to define the translation location for the text content of the containing element. The mechanism for using the QName value of the sml:locid attribute to locate a translated text is implementation specific and hence outside the scopes of this specification. Elements sml:key This element is used to specify a key constraint in some scope. The semantics are essentially the same as that for xs:key but sml:key can also be used to specify key constraints on other documents, i.e., the  sml:selector child element of sml:key can contain deref functions to resolve elements in another document. sml:key is supported in the appinfo of an xs:element.   sml:keyref 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.   sml:unique This element is used to specify a uniqueness constraint in some scope. The semantics are essentially the same as that for xs:unique but sml:unique can also be used to specify uniqueness constraints on other documents, i.e., the  sml:selector child element of sml:unique can contain deref functions to resolve elements in another document. sml:unique is supported in the appinfo of an xs:element.   sml:uri Specifies a reference in URI scheme. This element must be used to specify references that use the URI scheme. XPath functions smlfn:deref node-set deref(node-set) This function takes a node-set of elements and attempts to resolve the references contained in the elements that have sml:ref="true".    The resulting node-set is the set of elements that are obtained by successfully resolving (or de-referencing) the  reference contained in each element in the input node-set for which sml:ref="true".  For example, deref(/u:Universities/u:Students/u:Student) will resolve the reference in element Student. The target of the reference must always be an element. References Normative Service Modeling Language Interchange Format Version 1.1, Bhalchandra Pandit, Valentina Popescu, Virginia Smith, Editors. World Wide Web Consortium, 14 January 2008. This version of the Service Modeling Language Interchange Format specification is available at http://www.w3.org/TR/2008/WD-sml-if-20080114/. The latest version of the Service Modeling Language Interchange Format Version 1.1 specification is available at http://www.w3.org/TR/sml-if Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt. Information technology ― Document Schema Definition Languages (DSDL) ― Part 3: Rule-based validation ― Schematron. International Organization for Standardization and International Electrotechnical Commission, 1 January 2006. Available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 16 August 2006. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2006/REC-xml-20060816. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml. XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The latest version of XML Schema 1.0 Part 1 is available at http://www.w3.org/TR/xmlschema-1. XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The latest version of XML Schema 1.0 Part 2 is available at http://www.w3.org/TR/xmlschema-2. XML Path Language (XPath) Version 1.0, J. Clark and S. DeRose, Editors. World Wide Web Consortium, 16 November 1999. This version of XML Path Language (XPath) Version 1.0 is http://www.w3.org/TR/1999/REC-xpath-19991116. The latest version of XML Path Language (XPath) Version 1.0 is available at http://www.w3.org/TR/xpath. XPointer Framework, P. Grosso, E. Maler, J. Marsh, and N. Walsh, Editors. World Wide Web Consortium, 25 March 2003. This version of the XPointer Framework Recommendation is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The latest version of XPointer Framework is available at http://www.w3.org/TR/xptr-framework/. XPointer xmlns() Scheme, S. DeRose, R. Daniel Jr., E. Maler, and J. Marsh, Editors. World Wide Web Consortium, 25 March 2003. This version of the XPointer xmlns() Scheme Recommendation is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The latest version of XPointer xmlns() Scheme is available at http://www.w3.org/TR/xptr-xmlns/. XPointer xpointer() Scheme, S. DeRose, E. Maler, and R. Daniel Jr., Editors. World Wide Web Consortium, 19 December 2002. This version of the XPointer xpointer() Scheme specification is http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/. The latest version of XPointer xpointer() Scheme is available at http://www.w3.org/TR/xptr-xpointer/. Non-Normative An Introduction to Schematron, Eddie Robertsson, Author. O'Reilly Media, Inc., 12 November 2003. Available at http://www.xml.com/pub/a/2003/11/12/schematron.html Improving XML Document Validation with Schematron, Dare Obasanjo, Author. Microsoft Corporation, September 2004. Available at http://msdn2.microsoft.com/en-us/library/Aa468554.aspx XML Schema Part 0: Primer Second Edition, D. Fallside and P. Walmsley, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 0 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-0-20041028. The latest version of XML Schema Part 0 is available at http://www.w3.org/TR/xmlschema-0. Normative SML Schema Specifies if the element contains a reference Specifies that the reference element denotes a “null” reference. To be used only on elements for which sml:ref="true". A qualified name of an element in the referenced document. If true, requires the target element of the reference to exist in the model. A qualified name of the type of the element in the referenced document. 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. References in URI scheme must be representend by this element. Model Definition Document Sample This model definition document sample illustrates the use of the following SML extensions: SML references key and keyref constraints User-defined constraints Each application in workstation must be hosted on an operating system Application from does not have high security level. A secure workstation can only contain applications from TrustedVendor. SML References Sample The following example illustrates the use of SML references. 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:   1000   John Doe             PHY101       A               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'])                     MAT100       B               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'])                     SocialSkills       F       The first EnrolledCourse element in the above example is a reference element since it specifies sml:ref="true". It uses the SML URI scheme to target 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 specifies the sml:nilref="true" attribute as shown in the following example (the first EnrolledCourse element is a null reference):   1000   John Doe             PHY101       A               MAT100       B               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'])                     SocialSkills       F       In the above example, first reference EnrolledCourse defines the sml:nilref="true" attribute which marks this as a null reference. By specifying a null reference, the document author makes an explicit declaration that this Student element does not refer to any target element. Specifying a null reference does not have any SML-defined effect on the interpretation of element in non-SML contexts. In particular, in this case, SML says nothing about the interpretation of the Grade and Name elements. Any such interpretation is left to the application, its usage context, other specifications, etc. SML URI Scheme Sample The following example illustrates the use of SML URI scheme. 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)   1000   John Doe                     http://www.university.example.org/Universities/MIT/Courses.xml #smlxpath1(/u:Courses/u:Course[u:Name='PHY101'])             A reference element can also be used to reference an element in its own document. To see this consider the following instance document   MIT             PHY101               MAT200                   123       Jane Doe                                     #smlxpath1(/u:University/u:Courses/u:Course[u:Name='MAT200'])                               Here, the EnrolledCourse element for the student Jane Doe references the Course element for MAT200 in the same document. SML Identity Constraints Sample The following example will be used to illustrate the sml:key, sml:unique, and sml:keyref constraints across SML references. This example consists of 3 schema documents, university.xsd that contains the currently enrolled students, active courses, and other university information, students.xsd that contains information on all current and past students, and courses.xsd that contains information on the students currently enrolled in that course. The following snippets represent pieces of the definition documents. sml:key and sml:unique XML Schema supports key and uniqueness constraints through xs:key and xs:unique, but these constraints can only be specified within a single XML document. The sml:key and sml:unique elements  support the specification of key and uniqueness constraints across documents.  We'll use the UniversityType 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:                                                                 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 name in the University element declaration. sml:keyref XML Schema supports key references through xs:keyref to ensure that one set of values is a subset of another set of values within an XML document. Such constraints are similar to foreign keys in relational databases. Key references in XML Schema are only supported within a single XML document. The sml:keyref element allows key references to be specified across SML references and across XML documents. The following example uses sml:keyref to capture the requirement that students enrolled in a course must be currently enrolled in the university:                                                                                                       The above constraint specifies that for a university, the set of IDs of students enrolled in a course is a subset of the set of IDs of students currently enrolled in the university. In particular, the selector and field elements in StudentIDisKey key constraint identify the set of IDs of students currently enrolled in the university, and the selector and field elements in CourseStudents key reference constraint identify the set of IDs of students enrolled in courses.   Localization and Variable Substitution Sample In the following example, the sml:locid attribute is used to define the translation information for the Schematron sch:assert error message: The specified ID does not begin with 99. In this example, the {namespace name} URI information of the sml:locid attribute is used to define the location for the resource containing the translated text: The {namespace name} URI can point to a file containing the translated message, a folder containing a set of translated files or any other type of resource that can help locate the translated message. It is implementation dependant how the processor makes use of this information for finding the actual resource containing the translated message. In this example, http://www.university.example.org/translation/ points to a folder containing a set of translation resources. For this specific example, there will be a set of translation files located under http://www.university.example.org/translation/. Each of these translation files will correspond to a language in which the messages have been translated. For this example, the translation is only available in French and German so there are only two files under http://www.university.example.org/translation/: http://www.university.example.org/translation/fr_lang.txt file contains the French translation of the sch:assert message. http://www.university.example.org/translation/de_lang.txt contains the German translation of the sch:assert message. The {local part} information of the sml:locid attribute is used to define the identity of the message being translated. This information will be used to locate the translated text within the translation resource. The file http://www.university.example.org/translation/fr_lang.txt contains the French translation of the sch:assert message, identified by StudentIDErrorMsg, which is the {local part} information of the sml:locid attribute: StudentIDErrorMsg = L'identifieur specifie ne commence pas par 99. The file http://www.university.example.org/translation/de_lang.txt contains the German translation for the sch:assert message. The message is identified by StudentIDErrorMsg, which is the {local part} information of the sml:locid attribute: StudentIDErrorMsg = Das angegebene Attributkennzeichen ID beginnt nicht mit 99. This example demonstrates how localization can be applied to a Schematron rule with the purpose of making the Schematron rule available to consumers using different languages. Summarized below are the benefits resulting from using the sml:locid localization support: The Schematron rule is language agnostic in the sense that the author does not have to be aware of the locale of a potential consumer. The Schematron rule is defined generically, to be consumed by any producer for which a translation file is made available at the location defined by the sml:locid {namespace name} URI. There is a clear separation between the translation process and the Schematron rule. There are no changes required to be applied to the Schematron rule when translations for other languages are made available. To support a new language, all that needs to be done is to add a new translation file under the location identified by the sml:locid {namespace name} URI. Variable substitution support There is often the case that a message can be reused in different sch:assert or sch:report situations. In the example above, the author of the Schematron rule may want to use this error message in other contexts: The specified ID does not begin with 99. This is not possible since the translated message contains the context where the rule has been applied: To be able to re-use this message, the schema author must be able to substitute u:ID in with some content that is appropriate for the context in which the message is used. In order to do that, the translation messages should substitute this context with a generic value. In other words, instead of these messages: StudentIDErrorMsg = L'identifieur specifie ne commence pas par 99. StudentIDErrorMsg = Das angegebene Attributkennzeichen ID beginnt nicht mit 99. , the translation files should contain messages where the context of the Schematron rule is being replaced with a generic variable: StudentIDErrorMsg = L'identifieur specifie ne commence pas par 99. StudentIDErrorMsg = Das angegebene Attributkennzeichen ID beginnt nicht mit 99. The error message in sch:assert identified by the lang:StudentIDErrorMsg value can now be reused in contexts other than the one described by the above sample. The sample below shows how substitution variable support can be achieved on Schematron sch:assert messages by using xsl:variable support: does not begin with 99. The error message in sch:assert and the localization identifier lang:StudentIDErrorMsg can now be reused in contexts other than u:Students/u:Student. Acknowledgements 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), Kirk Wilson (CA).