Movatterモバイル変換

1. Introduction(Non-Normative)

The Service Modeling Language (SML) provides a rich set ofconstructs for creating models of complex services and systems.Depending on the application domain, these models may includeinformation such as configuration, deployment, monitoring, policy,health, capacity planning, target operating range, service levelagreements, and so on. Models provide value in several importantways.

Models focus on capturing allinvariant aspects of aservice/system that must be maintained for the service/system tofunction properly.
Models represent a powerful mechanism forvalidatingchangesbefore applying the changes to a service/system.Also, when changes happen in a running service/system, they can bevalidated against the intended state described in the model. Theactual service/system and its model together enable aself-healing service/system ― the ultimate objective.Models of a service/system must necessarily stay decoupled fromthe live service/system to create the control loop.
Models are units ofcommunicationandcollaboration between designers, implementers, operators, andusers; and can easily be shared, tracked, and revision controlled.This is important because complex services are often built andmaintained by a variety of people playing different roles.
Models drivemodularity,reuse, andstandardization. Most real-world complex services and systemsare composed of sufficiently complex parts. Reuse andstandardization of services/systems and their parts is a key factorin reducing overall production and operation cost and in increasingreliability.
Models enable increasedautomation of management tasks.Automation facilities exposed by the majority of services/systemstoday could be driven by software ― not people ― both for reliableinitial realization of a service/system as well as for ongoinglifecycle management.

A model in SML is realized as a set of interrelated XMLdocuments. The XML documents contain information about the parts ofa service, as well as the constraints that each part must satisfyfor the service to function properly. Constraints are captured intwo ways:

Schemas ― these are constraints on the structure andcontent of the documents in a model. SML uses XML Schema[XML Schema Structures,XML Schema Datatypes] as theschema language. In addition SML defines a set of extensions to XMLSchema to support references that may cross documentboundaries.
Rules ― are Boolean expressions that constrain thestructure and content of documents in a model. SML uses Schematron[ISO/IEC 19757-3,Introduction toSchematron,Improving Validation withSchematron] and XPath [XPath] for rules.

One of the important operations on the model is to establish itsvalidity. This involves checking whether all data in a modelsatisfies the schemas and rules declared.

This specification focuses primarily on defining the extensionsto XML Schema for references that cross document boundaries,Schematron usage in SML, as well as the process of modelvalidation. It is assumed that the reader is familiar with XMLSchema and Schematron.

SML scenarios require several features that either do not existor are not fully supported in XML Schema. These features can beclassified as follows:

SML references – XML documents introduce boundariesacross content that needs to be treated as a unit. XML Schema doesnot have any support for references that cross documents, althoughit does support references to elements in the same document throughxs:ID,xs:IDREF,xs:key andxs:keyref. References between elements defined inseparate SMLmodel documents arefundamental to the SML specification. SML extends XML Schema tosupport references that may cross document boundaries, and a set ofconstraints on those references that apply regardless of whetherthey cross document boundaries or not.
Rules – XML Schema does not support a language fordefining arbitrary constraints on the structure and content of XMLdocuments. SML uses Schematron to express assertions on thestructure and content of XML documents.

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

2. Notations and Terminology

2.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULDNOT", "RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpretedas described in RFC 2119 [IETF RFC2119].

This specification uses the Augmented Backus-Naur Form (ABNF)notation [RFC 2234].

This specification follows the same conventions for schemacomponents as those used in the XML schema specification[XML Schema Structures]. That is,references to properties of schema components, such as {exampleproperty}, are links to the relevant definition, set off with curlybraces. References to properties of information items as defined in[XML Information Set], suchas [children], are notated as links to the relevant sectionthereof, set off with square brackets.

This specification refers to terms such as XML document,element, attribute, etc. for the sake of brevity. The alternativewould be to use terms like "XML document or aSyntheticInfoset", "elementinformation item", "attributeinformation item", etc. at each place. This would make thespecification excessively verbose without adding to or changing themeaning of the existing text. The use of the concise terms is notintended to exclude other XML representations. The concepts definedin this specification apply to all forms of XMLrepresentations.

The content of this specification is normative except forsections or texts that are explicitly marked as non-normative. If asection is marked as non-normative, then all contained sub-sectionsare non-normative, even if they are not explicitly marked as such.All notes are non-normative unless otherwise specified.

2.2 Terminology

The following terms are used in this specification. They arelisted here in alphabetical order.

Document: A well-formed XMLdocument, as defined in [XML].
Implementation-Defined: Animplementation-defined feature or behavior may varyamongmodel processors; the precisebehavior is not specified by this specification butMUST be specified by the implementor of eachmodel processor.
Implementation-Dependent: Animplementation-dependent feature or behavior may varyamongmodel processors; the precisebehavior is not specified by this or any other W3C specificationand is not required to be specified by the implementor for anyparticular implementation.
Model: A set of inter-relateddocuments that describe a service or system. Eachmodel consists of two disjoint subsets ofdocuments –model definitiondocuments andmodel instancedocuments.
Model Definition Documents: The subset of documents in amodelthat describes the schemas and rules that govern the structure andcontent of the model's documents. This specification defines twotypes ofmodel definition document,schema documents andrule documents, but permits implementations todefine other types of model definition documents. Such other typesof model definition documents do not play any role inmodel validation.
Model Instance Documents: The subset of documents in amodelthat describes the structure and content of the modeledentities.
Model Processor: Amodel processor is an embodiment that processes aconforming SML model using, in whole or in part, semantics definedby this specification.
Model Validation: Model validation is the process of determining whether ornot amodel is both conforming andvalid. [8. ConformanceCriteria]
Model Validator: Amodel validator is amodelprocessor capable of performingmodel validation.
Rule: Arule is a boolean expression that constrains thestructure and content of a set of documents in amodel.
RuleBindings: Arule binding is an association of a set of one or morerule documents with a set ofzero or more model documents. The documents associated with a givenrule document are said to be "bound" to it. For a model to bevalid, everydefinitiondocument andinstancedocument in themodel mustconform to the constraints defined by every rule document it isbound to. It is permissible for a rule document to have no bindingsassociated with it, and for a model document to be bound to zerorule documents.
RuleDocument: Arule document is amodel definition document consisting ofSchematronconstraints.
Schema document: Aschema document is amodel definition document that conforms tothe XML Schema specification [XML SchemaStructures] definition of a schema document.
Schematron Constraint: The information contained within a singlesch:schema element.
SMLReference: AnSML Reference is an element with an sml:ref attributewhose value is "true".
Note:
Conceptually, an SML reference is used to signal a link from oneelement in an SML model to another element in the same model.
SML Reference Scheme: AnSML Reference Scheme is a set of rules defining thesyntax used to create an instance of the reference scheme in thecontext of anSML reference, plusa set of rules for resolving an instance of the reference scheme toitstarget. Whenever "referencescheme" occurs in this specification, it should be assumed to mean"SML reference scheme" unless otherwise noted. Despite similarnames, the term SML reference scheme is unrelated to XPointerschemes and URI schemes.
Target: An element in a model to which anSML reference resolves is called thetargetof that SML reference.
Target-complete Identifier: Atarget-complete identifier is a URI or IRI thatcontains all the information required to locate thetarget of anSMLreference. It is a consequence of this definition that atarget-complete identifier cannot be a relative URI/IRI.

2.3 XMLNamespaces

Table 2-1 lists XML namespaces that areused in this specification. The choice of any namespace prefix isarbitrary and not semantically significant.

Table 2-1. XML Namespaces used in thisspecification.
Prefix	XML Namespace	Specification(s)
`sml`	`http://www.w3.org/ns/sml`	This specification
`smlfn`	`http://www.w3.org/ns/sml-function`	This specification
`xs`	`http://www.w3.org/2001/XMLSchema`	[XML SchemaStructures,XML SchemaDatatypes]
`sch`	`http://purl.oclc.org/dsdl/schematron`	[ISO/IEC19757-3]

3. Dependencies onOther Specifications

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

4. SML References

Support forSML references inan SMLmodel includes:

The ability to use multiple SML reference schemes for an SMLreference.
An extensibility mechanism allowing new SML reference schemes tobe defined.
Constraints on the type of a referenced element.
The ability to define key, unique, and key reference constraintsacross SML references.

Model validatorsMUST supportSML references as defined by thisspecification.

AppendixC. SML ReferencesSample has an example that shows how SML references aredefined and used.

4.1 SML Reference Definitions

4.1.1 SMLReference

An element information item in an SML model instance document isas anSML reference if and onlyif it has an attribute information item for which all of thefollowing is true:

Its[localname] isref
Its[namespacename] ishttp://www.w3.org/ns/sml
Its[normalizedvalue], after whitespace normalization usingcollapse followingschema rules, is either"true" or"1".

Note:

This mechanism enables schema-less identification of SMLreferences; i.e., SML references can be identified without relyingon the Post Schema Validation Infoset (PSVI). [XML Schema Structures]

It is implementation-defined whethermodel processors that are not alsomodel validators use the XML Infoset[XML Information Set] or thePost Schema Validation Infoset (PSVI) [XMLSchema Structures] for SML reference identification.

Note:

SML model validators must use PSVI to identify SML references.See8. Conformance Criteria.

An SML reference is considered to be an instance of a specificSMLreference scheme if itcan be identified as such according to that SML reference scheme'srules. See4.3 SML ReferenceSchemes. An SML reference MAY be an instance of multipleSML reference schemes.

Although its normative definition allows several syntaxes to beused to identify an SML reference, for the sake of brevity andconsistency, the rest of this specification usessml:ref="true" to denote an SML reference in examplesand text.

The following example shows an SML reference that is an instanceof the SML URI Reference scheme.

<RefElement sml:ref="true">    <sml:uri>targetDocument.xml</sml:uri></RefElement>

4.1.2 Null SMLReference

An SML reference is null if and only if it has an attributeinformation item for which all of the following is true

Its[localname] isnilref
Its[namespacename] ishttp://www.w3.org/ns/sml
Its[normalizedvalue] after whitespace normalization usingcollapse followingschema rules, is either"true" or"1".

It is a consequence of the preceding that this specificationassigns no meaning to thesml:nilref attribute when itis used on an element that is not an SML reference. ModelvalidatorsMAY choose to warn theirinvokers should they detect this condition in a document.

The following example shows a null SML reference.

<RefElement sml:ref="true" sml:nilref="true">    <sml:uri>targetDocument.xml</sml:uri></RefElement>

Note:

sml:nilref may be useful in the case where theschema author defines a complex type specifyingsml:ref="true" with a fixed value of "true", but theinstance author wants to signal the absence of a target.

Note:

SML model validators must use PSVI to identify null SMLreferences. See8. ConformanceCriteria.

4.1.3 Unresolved SML Reference

An SML reference is unresolved if and only if all of thefollowing is true:

It is a non-null SML reference.
None of thereferenceschemes, which the SML reference is recognized as using,resolves to an element in the model.

Note:

The notion of unresolved reference is context-dependent. Thatis, differentmodelprocessors, based on the set of SML reference schemes theyunderstand and which are used in the model they process, mayconsider different SML references to be unresolved.

The following example shows an unresolved SML reference(assuming that the documentdummy.xml does not existin the model).

<RefElement sml:ref="true">    <sml:uri>dummy.xml</sml:uri></RefElement>

4.1.4 SML Reference Target

The element node that a non-null SML reference resolves to isits target. The target of an SML referenceMUST be part of the same SML model as the SMLreference. Null SML references have no target.

The method of determining which documents are part of an SMLmodel is implementation-defined.

Note:

For example, an SML model may consist of documents listed in aconfiguration file or an SML model could be construed as thetransitive closure of documents referred to by any SML referencesstarting from a set of documents known to be in the model.

The following example shows an SML reference that targets thesecondCourse child element of the root element of thedocumenttarget.xml.

<RefElement sml:ref="true" xmlns:e="urn:example">    <sml:uri>target.xml#smlxpath1(e:Course[2])</sml:uri></RefElement>document 'target.xml':----------------------<Courses xmlns="urn:example">    <Course>        <Name>PHY101</Name>        <Grade>A</Grade>    </Course>    <Course>        <Name>MAT101</Name>        <Grade>A</Grade>    </Course></Courses>

4.2SML Reference Semantics

Model validatorsMUST attempt to resolve an SMLreference using all the reference schemes of which the SMLreference is recognized as an instance.

4.2.1At Most One Target

Every non-null SML referenceMUSTtarget at most one element in amodel. This means that each recognized referencescheme used in the SML referenceMUSTNOT resolve to more than one target.

The following example shows an SML reference that violates theat-most-one-target rule.

<RefElement sml:ref="true" xmlns:e="urn:example">    <sml:uri>target.xml#smlxpath1(e:Course)</sml:uri></RefElement>document 'target.xml':----------------------<Courses xmlns="urn:example">    <Course>        <Name>PHY101</Name>        <Grade>A</Grade>    </Course>    <Course>        <Name>MAT101</Name>        <Grade>A</Grade>    </Course></Courses>

4.2.2 Consistent References

If a non-null SML reference is an instance of multiple referenceschemes, all recognized reference schemesMUST resolve to the same target or they allMUST be unresolved.

4.2.3Identical Targets

To determine if two targets are the same or different,model validators MUST obey thefollowing rules.

If both of the following are true, then a model validatorMUST consider both targets to be thesame.
1. The definition of the reference scheme(s) specifies how URIs aretransformed totarget-complete identifiers.
2. The two target-complete identifiers are identical using acase-sensitive, codepoint-by-codepoint comparison.
Otherwise, a model validatorMUSTconsider both targets to be different when there is somethingavailable in the element information items for the targets thattells them apart. For example, if there is an infoset property forwhich the 2 targets have different values, they are different. Thisapplies recursively for complex-valued properties.
For all other cases, it is implementation-defined whether totreat the targets as the same or not.

4.2.4 Multiple References

An element in a documentMAY betargeted by multiple SML references.

4.2.5 NullSML References

A null SML reference is an explicit declaration of intent by thedocument author that thetarget ofthe SML reference does not exist. If an SML reference is recognizedas null, thenmodel processorsMUST NOT attempt to recognize anyreference schemes used in it.

4.2.6 Deterministic Evaluation ofSML Constraints

Each non-null SML referenceMUSTsatisfy all of the following conditions in order to be able todeterministically evaluate SML constraints and rules associatedwith it.

The reference must have at most one target. [4.2.1 At Most One Target]
The referenceMUST be consistent.[4.2.2 ConsistentReferences]

4.2.7 smlfn:deref() XPathExtension Function

Thederef() function takes a node set of elementsand returns a node set consisting of element nodes corresponding tothe elements referenced by the input node set. In particular,for each SML reference R in the input node set the output node setcontains at most one element node.

Let I = input node set; that is, the set of nodes passed to thederef() function.

Let O = output node set; that is, the set of nodes returned bythederef() function.

The behavior ofderef() functionMUST satisfy the following constraints:

For each SML reference R in the input node set I:
1. If the implementation recognizes no SML reference scheme used inthe SML reference R, then no element is added to O.
2. If the implementation recognizes R as an instance of N supportedreference schemes, thenderef() is not required toattempt to resolve all N schemes. Its behavior in this case isimplementation-defined and the set of reference schemes that areactually attempted may be any subset of the recognized schemes.This is subject to the following constraints:
  1. If deref() doesn't attempt to resolve any reference scheme or ifnone of the attempted reference schemes resolves, then no elementis added to O.
  2. If at least one of the attempted reference schemes resolves tomore than one target element, then 0 or 1 of the targets is addedto O.
  3. If one attempted reference scheme resolves to a target differentfrom the target resolved by another attempted reference scheme,then 0 or 1 of the targets is added to O.
  4. If one attempted reference scheme resolves and another doesn't,then 0 or 1 of the targets is added to O.
  5. If none of the above is true (that is, all attempted referenceschemes resolve to the same one and only one target element, callit T), then one target element (namely, T) is added to O, if itdoes not already exist in O.

Note:

The above describes the behavior required for a general XPath1.0 deref() library function, and as such exhibits severalsignificant differences from the behavior required to validate SMLreferences during model validation. First, it can be used tosuccessfully process instance documents whose SML model validity isunknown or invalid, although the results in this case may not beinteroperable. Second, since XPath 1.0 defines no way for afunction to signal erroneous input to its caller, the behavior hereis specified to return results for SML references that do not obeyall of the validity rules, e.g. a reference whose XPath expressionevaluates to more than one node. As described in this section, sucha function would be insufficient to check the validity of SMLreferences.

Model validators MUST provide an implementation of the deref()XPath extension function. In addition to the above requirements forgeneral deref() function implementations, for each SML referenceusing recognized schemes, deref() in model validators MUST attemptto resolve at least one of the recognized schemes.

4.3 SMLReference Schemes

An SML referenceMAY be an instanceof a variety of reference schemes. SML does not mandate the use ofany specific reference schemes. An SML reference schemeMAY use child elements, attributes,both, or neither to capture the information necessary to identifythe reference target. It isOPTIONALthat all elements in an SML model be reachable via an SMLreference. This will depend on the support defined by the chosenreference scheme.

Although SML does not require the use of any specific scheme, itdoes specify how a referenceMUST berepresented when using SML-defined reference schemes. Thisspecification defines the4.3.1SML URI Reference Scheme for use in SML references.

An SML reference scheme definitionMUST specify all of the following:

The set of rules that, when satisfied, identify an SML referenceas an instance of the scheme. An SML reference scheme definitionMAY impose additional validityrequirements on SML references recognized as instances of thatscheme.Model validatorsMUST NOT apply such requirements toSML references that are not instances of the correspondingreference scheme.
The set of rules that, when evaluated, resolve the SML referenceto its target element node.
An assertion that states whether instances of the referencescheme are transformed totarget-complete identifiers. Ifthey are transformed totarget-complete identifiers, thereference scheme definition MUST describe the transformationprocess.

An SML reference scheme definitionMUST specify all of the preceding items as theyapply to valid instances of the SML reference scheme, andMAY specify them for other (invalid)instances.

4.3.1 SML URI Reference Scheme

The SML URI Reference Scheme is defined as follows:

An SML reference is identified as an instance of the SML URIReference Scheme if and only if exactly one element informationitem [XML Information Set]whose [local name] isuri and whose [namespace name]ishttp://www.w3.org/ns/sml is present as a child ofthat reference element.
An instance of the SML reference scheme is valid if it meets allof the following requirements.
1. The content of theuri elementMUST be of typexs:anyURI as definedin the XML schema specification [XML SchemaDatatypes].
2. The fragment identifier (if present)MUST follow the syntax of one of thefollowing.
  1. 4.3.1.1 smlxpath1()scheme
  2. ShorthandPointer
An SML reference that is an instance of the SML URI ReferenceScheme is resolved using the following steps:
1. An XML documentD is obtained as follows:
  1. If the URI reference is a same-document reference as defined inthe applicable URI RFC, thenD is the document containingthe SML reference.
  2. Otherwise,D is determined as follows:
    1. If the URI reference is a relative reference, then letUbe the result of resolving the reference using the [base URI]property [XML InformationSet] of the<sml:uri> element as thebase URI. Otherwise,U is the URI reference itself. Thecomputation of the [base URI] property isimplementation-defined.
    2. DereferenceU as defined in the applicablespecifications. If the document targeted byU is in thecurrent SML model, thenD is that document. Otherwise, ifthe document is not in the current SML model, then the SML URIReference Scheme instance is unresolved (andD has novalue).
  Note:
  As a result of the above definition, if the retrieved object isnot of XML media type or if it is not well-formed XML then, bydefinition, that object is not a document as defined by thisspecification. In this case, the SML reference scheme instance isunresolved.
2. If no fragment component is present in the URI reference, theSML URI Reference Scheme instance resolves to the root element ofD.
3. If a fragment component is present in the URI reference, thenthe appropriate case among the following applies:
  1. If the fragment component complies with thesmlxpath1() XPointer scheme syntax, then the referencetarget is obtained by applying the fragment component toD,as defined in section4.3.1.1smlxpath1() scheme .
  2. If the fragment component complies with theShorthandPointer syntax, then the appropriate case among the followingapplies:
    1. If a targetT can be identified inD based on theXML-Schema-determinedID, then the reference target isT.
    2. If a target inD cannot be identified based on theXML-Schema-determinedID, then it is implementation-defined whether the referencetarget inD is identified based on other criteria allowedforShorthandPointers.
Instances of the SML URI Reference Scheme are transformed totarget-completeidentifiers through standard URI processing, as described inthe applicable URI RFC.

The following example shows an SML reference that is an instanceof the SML URI Reference scheme. The reference targets the elementwith IDtargetId in documenttarget.xml.

<RefElement sml:ref="true">    <sml:uri>target.xml#targetId</sml:uri></RefElement>

4.3.1.1`smlxpath1()` scheme

Thesmlxpath1() scheme is intended to be used withthe XPointer Framework [XPointer]to allow addressing of elements. The4.3.1 SML URI Reference Schemeuses it to encode fragment identifiers.

This section describes the syntax and semantics of thesmlxpath1() scheme and the behavior of XPointerprocessors with respect to this scheme.

Scheme name:smlxpath1
Scheme syntax using ABNF [RFC2234]:
SMLXPath1_Fragment_ID ::= 'smlxpath1' '('SMLXPath1_SchemeData ')'
SMLXPath1_SchemeData ::= XPath1.0_LocationPath
where,
XPath1.0_LocationPath is theLocationPathproduction defined in the XPath 1.0 specification[XPath].
Thederef() XPath extension functionMUST NOT be present in the expression evaluationcontext function library when processing the location path inSMLXPath1_SchemeData.
Namespace Binding Context: Thesmlxpath1() schemeinherits the set of namespace bindings available to the parentsml:uri element.
For a given documentD, the element targeted by a schemeinstance is obtained by applying the location path inSMLXPath1_SchemeData to the root element ofD.The resultMUST either be 1 elementnode or be empty. Otherwise, the XPointer result is an error.
Note:
In the case of instances of the SML URI Reference scheme,D is the document resolved to by the non-fragment part ofthe URI reference, as defined in item 2.a in section4.3.1 SML URI ReferenceScheme.

The following example shows an SML reference that is an instanceof the SML URI Reference scheme. The reference targets the rootelement of the documenttarget.xml.

<RefElement sml:ref="true">    <sml:uri>target.xml#smlxpath1(/*)</sml:uri></RefElement>

5. SMLConstraints

5.1 Constraints on SMLReferences

SML supports the following attributes for expressing constraintson SML references.

Table 5-1. Attributes
Name	Description
`sml:acyclic`	Used to specify whether cycles areprohibited for an SML reference.
`sml:targetRequired`	Used to specify that an SML reference'starget element is required to be present in the model.
`sml:targetElement`	Used to constrain the name of the SMLreference's target.
`sml:targetType`	Used to constrain the type of the SMLreference's target.

SML defines a new property for every Complex Type Definitionschema component:

{acyclic}: Anxs:boolean value. Required.

The value of{acyclic} forxs:anyType isfalse.

SML defines three new properties for every Element Declarationcomponent:

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

5.1.1sml:acyclic

sml:acyclic is used to specify whether or not acycle is allowed on instances of a complex type.Model validatorsMUST support thesml:acyclicattribute on any<xs:complexType> element in aschema document. This attribute is of typexs:booleanand itsactualvalue can be eithertrue orfalse.

5.1.1.1 SML ConstraintConstruction

The{acyclic} property value ofa complex type definition is as specified by the appropriate caseamong the following:

Ifsml:acyclic is present, then{acyclic} has the actual value of thisattribute.
Otherwise, if its {base type definition} is a complex typedefinition, then{acyclic} has thesame value of{acyclic} as its{base type definition}.
Otherwise ({base type definition} is a simple type definition),{acyclic} is false.

5.1.1.2 Schema ComponentRules

If a complex type definitionCT's {base type definition}is also a complex type definition and has{acyclic} true, thenCTMUST have{acyclic} true.

5.1.1.3 Instance ValidityRules

IfCT is a complex type definition with{acyclic} true, then instances ofCTMUST NOT create cycles in the model.More precisely, the directed graph constructed in the following wayMUST be acyclic:

The nodes in the graph are all the elements resolved to by SMLreferences of typeCT or types derived fromCT.
If a nodeN in the graph is or contains an SML referenceR of typeCT or a type derived fromCT, andR resolves toT (which must also be a node in thegraph), then an arc is drawn fromN toT.

5.1.2 Constraints on SML ReferenceTargets

SML defines three attributes:sml:targetRequired,sml:targetElement, andsml:targetType,for constraining the target of an SML reference. These threeattributes are collectively calledsml:target*attributes.ModelvalidatorsMUST support theseattributes on allxs:element elements with a nameattribute. Thesml:target* constraints are attached tothe element declaration schema component.

5.1.2.1 SML ConstraintConstruction

{target required} is asspecified by the appropriate case among the following:
1. Ifsml:targetRequired is present, then{target required} is the actual value ofthis attribute.
2. Otherwise if the element declaration has a {substitution groupaffiliation}, then{targetrequired} is the same as that of the {substitution groupaffiliation}.
3. Otherwise{targetrequired} is false.
{target element} is asspecified by the appropriate case among the following:
1. Ifsml:targetElement is present, then its actualvalueMUST resolve to a global elementdeclarationG, and{targetelement} isG.
2. Otherwise if {substitution group affiliation} is present, then{target element} is the sameas that of the {substitution group affiliation}.
3. Otherwise{target element}is absent.
{target type} is as specifiedby the appropriate case among the following:
1. Ifsml:targetType is present, then its actual valueMUST resolve to a global typedefinitionT, and{targettype} isT.
2. Otherwise if {substitution group affiliation} is present, then{target type} is the same asthat of the {substitution group affiliation}.
3. Otherwise{target type} isabsent.

5.1.2.2 Schema ComponentRules

Model validatorsMUST enforce the following:

If a global element declarationE has a {substitutiongroup affiliation}G, then the value ofE's SMLtarget constraint property P (one of{target required},{target element} or{target type})MUSTbe a valid restriction of the corresponding property ofG asdefined in section5.3Valid Restriction of SML Constraint Values.
If two element declarationsE1 andE2 have thesame {namespace name} and {name} and they are both contained(directly, indirectly, or implicitly) in a content model of acomplex type, thenE1 andE2 have the same{target required},{target element}, and{target type}.

Note:

The above condition #2 on the use ofsml:target*attributes has been defined to reduce the implementationburden onmodelvalidators. Please refer to section5.4.1 Overview of SMLConstraint Processing and Complex Type Derivation for moreinformation.

5.1.2.3 Instance ValidityRules

If an element declarationE has{target required}true, theneach element instance ofE that is also an SML referenceMUST target some element in the model.That is, no instance ofE can be a null or unresolved SMLreference.

If an element declarationE has{target element}TE, then each elementinstance ofE that is also a resolved SML referenceMUST target an element that is aninstance ofTE or an instance of some global elementdeclaration in the substitution group ofTE.

If an element declarationE has{target type}TT, then each elementinstance ofE that is also a resolved SML referenceMUST target an element whose [typedefinition] isTT or a type derived fromTT.

5.1.3 SML Reference Constraints Summary(Non-Normative)

The effect of the above instance validation rules is summarizedin the following table.

Table 5-2. Target Constraints and SML ReferenceCategories.
Reference Category	`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

"Check" in the table above means that the appropriate constraintmust be evaluated.

The constraints described above can be useful even on elementdeclarations whose instances are not necessarily SML references,because the decision about whether to include a constraint and thedecision about whether to make the element an SML reference can bemade independently - some choices made by the schema author, otherchoices made by the instance document author.

5.2 SML Identity Constraints

XML Schema supports the definition of uniqueness and referenceconstraints throughxs:key,xs:unique,andxs:keyref elements. However, the scope of theseconstraints is restricted to a single document. SML defines analogsfor these constraints, whose scope extends to multiple documents byallowing them to traverseSMLreferences.

Model validatorsMUST support the following elementsfor defining SML identity constraints across SML references, aschild elements ofxs:element/xs:annotation/xs:appinfowhere thexs:element has a name attribute.

Name	Description
`sml:key`	Similar to`xs:key` exceptthat 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

AppendixB. ModelDefinition Document Sample and AppendixE. SML Identity ConstraintsSample have examples that show how SML identity constraintsare defined.

SML identity constraints are attached to the element declarationschema component. SML defines a new property for every elementdeclaration schema component:

{SML identity-constraints definitions}: A set of SML identity constraint definitions components, whichhave the same set of properties as XML Schema identity constraintdefinitions.

5.2.1 Syntax andSemantics

Names of all SML identity constraint definitions exist in asingle symbol space, which is disjoint from any symbol space of XMLSchema components.

5.2.1.1 SMLConstraint Construction

For eachsml:key,sml:unique, orsml:keyref element without therefattribute specified,{SMLidentity-constraints definitions} contains a componentcorresponding to this element, as specified in section3.11 Identity-constraint Definitions of the XML Schemaspecification [XML Schema Structures]), wheresml:selector andsml:field elements areused in place ofxs:selector andxs:field.

For eachsml:key,sml:unique, orsml:keyref element with theref attributespecified,{SMLidentity-constraints definitions} contains the componentresolved to by the actual value of theref attribute,with the following conditions:

The name attributeMUST NOT bespecified.
Thesml:selector andsml:field childelementsMUST NOT be specified.
If the element issml:key, then the value ofref attributeMUSTresolve to an SML key constraint.
If the element issml:unique, then the value of theref attributeMUSTresolve to an SML unique constraint.
If element issml:keyref, then the value of theref attributeMUSTresolve to an SML keyref constraint, and thereferattributeMUST NOT be specified.

In addition to SML identity constraints obtained from the aboveexplicit definitions or references, if an element declarationS has a {substitution group affiliation}G, then its{SML identity-constraintsdefinitions} also contains members of{SML identity-constraints definitions} ofG.

5.2.1.2 SchemaComponent Rules

sml:selector XPath expression has the same syntaxas that defined in the XML Schema identity constraint selectorXPath syntax with one exception. Thesml:selectorXPathMAY usesmlfn:deref() functions, with function calls nested toany depth, at the beginning of the expression. The XML Schemaidentity constraint selector Path production is amended to supportthis requirement as defined below.
```
Path ::= ('.//')? Step ( '/' Step)* | DerefExprDerefExpr ::= NCName ':' 'deref' '(' Step ('/'Step)* ')' ('/'Step)* |              NCName ':' 'deref' '(' DerefExpr ')' ('/'Step)*
```
sml:field XPath expression has the same syntax asthat defined in the XML Schema identity constraint field XPathsyntax with one exception. Thesml:field XPathMAY usesmlfn:deref()functions, with function calls nested to any depth, at thebeginning of the expression. The XML Schema identity constraintfield Path production is amended to support this requirement asdefined below.
```
Path ::= ('.//')? ( Step '/')* ( Step | '@' NameTest ) |         DerefExpr ('/' '@' NameTest)?DerefExpr ::= NCName ':' 'deref' '(' Step ('/'Step)* ')' ('/'Step)* |              NCName ':' 'deref' '(' DerefExpr ')' ('/'Step)*
```
The{SML identity-constraintsdefinitions} of an element declarationMUST NOT contain two identity constraints with thesame name.
Note:
This could happen if the ref attribute resolves to an identityconstraint already contained in the same element declaration’s{SML identity-constraintsdefinitions}.
If a global element declarationE has a {substitutiongroup affiliation}G, then the value ofE's{SML identity-constraints definitions}propertyMUST be a valid restrictionof the value of the corresponding property ofG as definedin section5.3 ValidRestriction of SML Constraint Values.
If two element declarationsE1 andE2 have thesame {namespace name} and {name} and they are both contained(directly, indirectly, or implicitly) in a content model of acomplex type, thenE1 andE2MUST have the same set of{SML identity-constraints definitions}.
Note:
This rule is defined to reduce the implementation burden formodel validators. Please refer to section5.4.1 Overview of SMLConstraint Processing and Complex Type Derivation for moreinformation.

5.2.1.3 InstanceValidity Rules

Validation rules for SML identity constraints are the same asspecified in section3.11 Identity-constraint Definitions of the XML Schemaspecification [XML Schema Structures]), withthe addition of support for thesmlfn:deref()function.

5.3 Valid Restriction of SMLConstraint Values

Let BV = value of SML constraint property P (one of{target required},{target element},{target type} or{SML identity-constraints definitions}).

Let RV = value that restricts BV.

For RV to be a valid restriction of BV, the appropriate caseamong the followingMUST be true.

For{target required},the appropriate case among the following applies.
1. If BV is true, RV is true.
2. If BV is false, RV is either true or false.
For{target element}, oneof the following applies.
1. RV is same as BV.
2. RV is in the substitution group of BV.
For{target type}, one of thefollowing applies.
1. RV is same as BV.
2. RV is a type derived from BV.
For{SML identity-constraintsdefinitions}, one of the following applies.
1. RV is same as BV. That is, all of the following is true.
  1. The number of entries in RV is same as the number of entries inBV.
  2. For each entry in BV, there exists an entry in RV with the samequalified name ({name} + {target namespace}).
2. RV is a superset of BV. That is, RV has all of the entries fromBV as defined in the previous item and it has one or moreadditional entries.

5.4 SMLConstraints and Complex Type Derivation

5.4.1 Overview of SMLConstraint Processing and Complex Type Derivation

This section is non-normative.

For a complex type D derived from its {base type definition} B,if an element declaration ED is included in D and an elementdeclaration EB is included in B, and ED and EB satisfy the"NameAndTypeOK" constraint, then the SML constraints (target* andSML identity constraints) applicable to ED must be

the same as those on EB in case of derivation by extension,and
the same or more restrictive compared to those on EB in case ofderivation by restriction.

SML defines this behavior to ensure that one cannot get rid ofSML constraints on elements in a complex type by simply derivinganother type from that type.

Enforcing this condition across derivation by restriction wouldrequire an implementation to match a restricting particle to thecorresponding restricted particle in order to evaluate condition 2above. This level of support is not provided by most XML Schemaframeworks; thus most SML validators would otherwise need toduplicate large parts of XML Schema's compilation logic to verifyconsistent usage of SML constraints across derivation byrestriction. In order to reduce this implementation burden on modelvalidators, SML requires that all element declarations with a givenname that are included in a complex type definition must have thesame SML constraint value. This allows model validators to find therestricted particle for a restricting particle using a simple namematch.

This also means that the value of a given SML constraintapplicable to all element declarations of a given name in complextype definition can be logically viewed as available at a singleplace, for example in a property attached to that complex type,rather than being scattered across element declarations in thattype. The next section uses this logical view because it makes iteasier to understand and formally define SML constraint behavioracross complex type derivation.

5.4.2 Formal Definition

5.4.2.1 Properties

SML defines four properties for every complex type definitionschema component CT.

{target required constraintlist}

A list of (qname, value) pairs, where,

qname is a qualified name ({namespace name} + {name}).
value is the value of a{target required} property.

{target element constraintlist}

A list of (qname, value) pairs, where,

qname is a qualified name ({namespace name} + {name}).
value is the value of a{target element} property.

{target type constraint list}

A list of (qname, value) pairs, where,

qname is a qualified name ({namespace name} + {name}).
value is the value of a{targettype} property.

{identity constraint list}

A list of (qname, value) pairs, where,

qname is a qualified name ({namespace name} + {name}).
value is the value of a{SMLidentity-constraints definitions} property.

The value of the above 4 properties forxs:anyTypeis empty.

5.4.2.2 SML ConstraintConstruction

Let

CT = A complex type definition.
C = SML constraint (one of targetRequired, targetElement,targetType, SML identity constraint).
P = A property of CT corresponding to constraint C (one of{target requiredconstraint list},{target element constraintlist},{targettype constraint list},{identity constraint list}).
V = The value of P, a list of (qname, value) pairs.
ED = An element declaration contained in CT.
PED = A property of ED corresponding to constraint C (one of{target required},{target element},{target type},{SML identity-constraints definitions}).

Property P is assigned value V as defined below:

For each element declaration ED, with qualified name qn,contained in CT:
1. If ED does not have constraint C, that is, the value of PED isabsent (or false in case of targetRequired), then skip ED.
2. Otherwise, if there is already an entry in V for qn, then skipED.
  Note:
  If the value of the existing entry is different from the valueof PED then it is treated as a schema validation error as definedin section5.1.2.2Schema Component Rules and section5.2.1.2 SchemaComponent Rules.
3. Otherwise, the entry (qn, value of PED) is added to the listV.
The appropriate case among the following applies:
1. If CT is derived by extension from a simple type definition thenvalue V is empty.
2. If CT is derived by extension from a complex type definitionBT:
  The initial value of V is computed as defined in list item 1above and then,
  For each entry (qn, v_b) in the value of P in BT:
  1. If V has an entry (qn, v_c) present, then ensure thatv_c is same as v_b. If it is not same, then itis treated as a schema validation error.
  2. If V does not have any entry (qn, v_c) present, thencopy (qn, v_b) into V.
3. If CT is derived by restriction from a complex type definitionBT:
  The initial value of V is computed as defined in list item 1above and then,
  For each entry (qn, v_b) in the value of P in BT:
  1. If V has an entry (qn, v_c) present, then ensure thatv_c is a valid restriction of v_b as defined insection5.3 ValidRestriction of SML Constraint Values. If it is not, then itis treated as a schema validation error.
  2. If V does not have any entry (qn, v_c) present, thencopy (qn, v_b) into V.

5.4.2.3 Instance ValidityRules

Let,

CT = the complex type of element declaration ED.
E = an instance of ED.
C = a child element of E.

If C matches an element declaration contained in CT and if oneor more of CT's constraint properties, defined in5.4.2.1 Properties, contain anentry matching C's qualified name ({namespace name} + {name}) thenthe value of each of those entries is used for evaluating thecorresponding constraint on C, as defined in section5.1.2.3 Instance ValidityRules and section5.2.1.3 InstanceValidity Rules, as if the matching element declaration hasthe corresponding constraint with that value.

Note:

One way for constraints to be embedded in element declarationsor type definitions in a schema is for constraint element to beincluded in a schema document, embedded at the appropriatelocations within thexs:element orxs:complexType elements which describe the elementdeclaration or type definition.

Element declarations and type definitions created by other meanscan, however, also have constraints embedded within the{application information} of their {annotation} properties. Howsuch embedding is accomplished is outside the scope of thisspecification and is likely to vary amongmodel processors.

6. Rules

XML Schema supports a number of built-in grammar-basedconstraints but it does not support a language for definingarbitrary rules for constraining the structure and content ofdocuments. Schematron [ISO/IEC19757-3] is an ISO/IEC standard for defining assertionsconcerning a set of XML documents. SML uses Schematron to addsupport for additional model constraints not supported in XMLSchema.

6.1 Informal Description(Non-Normative)

This section assumes that the reader is familiar with Schematronconcepts; the Schematron standard is documented in [ISO/IEC 19757-3] and [Introduction to Schematron,Improving Validation withSchematron] are good tutorials on an older version ofSchematron.

Constraints can be specified using thesch:assertandsch:report elements from Schematron. Thefollowing example usessch:assert elements to specifytwo constraints:

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

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:x-example:IPAddress">    <xs:simpleType  name="IPAddressVersionType">        <xs:restriction base="xs:string" >            <xs:enumeration value="V4" />            <xs:enumeration value="V6" />        </xs:restriction>    </xs:simpleType>    <xs:complexType name="IPAddress">        <xs:annotation>            <xs:appinfo>                <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">                   <sch:ns prefix="tns" uri="urn:x-example:IPAddress" />                   <sch:pattern>                      <sch:rule context=".">                         <sch:assert test="tns:version != 'V4' or count(tns:address) = 4">                              A v4 IP address must have 4 bytes.                         </sch:assert>                         <sch:assert test="tns:version != 'V6' or count(tns:address) = 16">                              A v6 IP address must have 16 bytes.                         </sch:assert>                      </sch:rule>                   </sch:pattern>                </sch:schema>                        </xs:appinfo>        </xs:annotation>        <xs:sequence>            <xs:element name="version" type="tns:IPAddressVersionType" />            <xs:element name="address" type="xs:byte" minOccurs="4" maxOccurs="16" />        </xs:sequence>    </xs:complexType></xs:schema>

ASchematronconstraint embedded in thexs:annotation/xs:appinfo element for a complex typedefinition or an element declaration is applicable to all instancesof the complex type or element. In the above example, the patternLength (which is a part of the containing Schematronconstraint) is applicable for all elements whose type isIPAddress or a derived type ofIPAddress.Apattern element contains one or moresch:rule elements and a singlesch:ruleelement contains one or moreassert and/orreport elements. Eachsch:rule elementspecifies its context using thecontext attribute.This context expression is evaluated in the context of eachapplicable element and results in an element node set for which theassert and reporttest expressions contained in thesch:rule element are evaluated. Thecontext expression is defined as an XSLT Pattern. Thismeans that thesmlfn:deref function may not be used inthe location path of acontext expression.

In the above example,context=".". Therefore thetwo assert expressions are evaluated in the context of eachapplicable element; i.e., each element of typeIPAddress. Thetest expression for anassert is a boolean expression, and theassert is violated (or fires) if itstestexpression evaluates to false. Areport is violated(or fires) if itstest expression evaluates to true.Thus, anassert can be converted to areport by simply negating its test expression. Thefollowing example usesreport elements to representthe IP address constraints of the previous example:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:x-example:IPAddress">    <xs:simpleType  name="IPAddressVersionType">        <xs:restriction base="xs:string">           <xs:enumeration value="V4"/>           <xs:enumeration value="V6"/>        </xs:restriction>    </xs:simpleType>    <xs:complexType name="IPAddress">        <xs:annotation>            <xs:appinfo>                <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">                    <sch:ns prefix="tns" uri="urn:x-example:IPAddress" />                    <sch:pattern>                        <sch:rule context=".">                            <sch:report test="tns:version = 'V4' and count(tns:address)!= 4">                                A v4 IP address must have 4 bytes.                            </sch:report>                            <sch:report test="tns:version = 'V6' and count(tns:address) != 16">                                A v6 IP address must have 16 bytes.                            </sch:report>                        </sch:rule>                    </sch:pattern>                </sch:schema>                        </xs:appinfo>        </xs:annotation>        <xs:sequence>            <xs:element name="version" type="tns:IPAddressVersionType" />            <xs:element name="address" type="xs:byte" minOccurs="4" maxOccurs="16" />        </xs:sequence>    </xs:complexType></xs:schema>

If asch:assert orsch:report isviolated, the violation is reported together with the specifiedmessage. The message can include substitution strings based onXPath expressions. These can be specified using thesch:value-of element. The following example uses thesch:value-of element to include the number ofspecified address bytes in the message:

<sch:assert test="tns:version != 'v4' or count(tns:address) = 4">     A v4 IP address must have 4 bytes instead of the specified     <sch:value-of select="string(count(tns:address))"/> bytes.</sch:assert>

In addition to being embedded in complex type definitions,constraints can also be embedded in global element declarations.Such constraints are evaluated for each instance elementcorresponding to the global element declaration. Consider thefollowing example:

<xs:element name="StrictUniversity" type="tns:UniversityType">    <xs:annotation>        <xs:appinfo>            <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">                <sch:ns prefix="u" uri="http://www.university.example.org/ns" />                <sch:ns prefix="smlfn"                          uri="http://www.w3.org/ns/sml-function"/>                <sch:pattern>                    <sch:rule context="u:Students/u:Student">                        <sch:assert test="smlfn:deref(.)[starts-with(u:ID,'99')]">                            The specified ID <sch:value-of select="string(u:ID)"/>                             does not begin with 99.                        </sch:assert>                        <sch:assert test="count(u:Courses/u:Course)>0">                            The student <sch:value-of select="string(u:ID)"/> must be enrolled                            in at least one course.                        </sch:assert>                    </sch:rule>                </sch:pattern>             </sch:schema>         </xs:appinfo>    </xs:annotation></xs:element>

Thesch:rule elements contained inStudentPattern are applicable to all element instancesof theStrictUniversity global element declaration.For eachStrictUniversity element, the XPathexpression specified as the value of thecontextattribute is evaluated to return a node set, and the testexpressions for the two asserts are evaluated for each node in thisnode set. Thus, these two asserts verify the followingconditions for each instance ofStrictUniversity.

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 documentsthat are then bound to a set of documents in the model.

The following example shows the constraints forStrictUniversity expressed in a separate document:

<?xml version="1.0" encoding="utf-8" ?><sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">    <sch:ns prefix="u" uri="http://www.university.example.org/ns" />    <sch:ns prefix="smlfn" uri="http://www.w3.org/ns/sml-function"/>    <sch:pattern>        <sch:rule context="u:StrictUniversity/u:Students/u:Student">            <sch:assert test="smlfn:deref(.)[starts-with(u:ID,'99')]">                The specified ID <sch:value-of select="string(u:ID)"/>                does not begin with 99.            </sch:assert>            <sch:assert test="count(u:Courses/u:Course)>0">                The student <sch:value-of select="string(u:ID)"/> must be enrolled                in at least one course.            </sch:assert>        </sch:rule>    </sch:pattern></sch:schema>

The binding of the rule document containing theStudentPattern pattern to documents that may containinstances ofStrictUniversity element isimplementation-defined.

6.2 RuleSupport

Model validators areREQUIRED to support and evaluate XPathexpressions augmented with thesmlfn:deref() functionin the body of Schematron constraints.

If thequeryBinding attribute is not specified,then its value is assumed to be set to"xslt".Model validatorsMUST support the"xslt"query binding.ModelvalidatorsMAY additionallysupport query bindings other than"xslt".

6.3 RulesAssociated with Schema Components

SML defines a new property for every complex type definitionschema component and every element declaration schemacomponent.

{rules}: A set ofSchematronconstraints.

6.3.1 SML Rule Construction

The{rules} property contains allof the Schematron constraints applicable to instances of the giventype definition or element declaration. Its value is derived inpart fromsch:schema elements embedded within thecomponent, and sometimes in part from the{rules} properties of other components.

sch:schema elementsMAY appear as items in the {applicationinformation} of the {annotation} of a global element declaration ora global complex type definition. This specification assigns nomeaning tosch:schema elements if they appear as itemsin any other location.

Let thelocal-rules of a given global element declarationor global complex type definition be the set of Schematronconstraints embedded in the {application information} of thatschema component's {annotation} property. For other schemacomponents,local-rules is empty.

The value of the{rules} propertyof a schema component is computed as follows:

The value of{rules} forxs:anyType is the empty set.
If the schema component is a global element declaration, thenthe value of its{rules} is the unionof itslocal-rules and the appropriate case from thefollowing:
1. If the element declaration has a {substitution groupaffiliation}, then the value of{rules} of the {substitution group affiliation}.
2. Otherwise (the element declaration has no {substitution groupaffiliation}), the empty set.
If the schema component is a complex type definition, then thevalue of its{rules} property is theunion of itslocal-rules and the appropriate case from thefollowing:
1. If the component's {base type definition} is a complex typedefinition, then the{rules} of the{base type definition}. This is true for derivation by extension aswell as for derivation by restriction.
2. Otherwise (i.e., when {base type definition} is a simple typedefinition), the empty set.
Otherwise, the value of the{rules} property is not affected by thisspecification.

6.3.2 Schema Component Rules

Model validatorsMUST enforce the following rules.

If a complex typeD is derived by restriction orextension from {base type definition}B and ifB has{rules} defined on it then theyMUST be automatically copied toD and unioned with the{rules}defined onD.
If a complex typeD is derived by restriction from {basetype definition}B, then a global element declaration withnon-empty{rules} contained inBMUST NOT be restricted to alocal element declaration inD.
Note:
It is an error if all of the following are true.
1. An element declarationED is contained (directly,indirectly, or implicitly) inD and an element declarationEB is contained (directly, indirectly, or implicitly) inB.
2. ED andEB satisfy the "NameAndTypeOK" constraint(for XML Schema's definition of valid restrictions, seeSchemaComponent Constraint: Particle Valid (Restriction),Constraints onParticle Schema Components in [XML SchemaStructures]).
3. EB is a reference to a global element declaration with aSchematron constraint on it.
4. ED is a local element declaration with the same name asEB.

6.3.3 Instance ValidityRules

Model validatorsMUST behave as follows:

EachSchematronconstraint in{rules} of acomplex-type definitionCTMUSTbe evaluated for all element instances of typeCT in a modelduring the model's validation.
EachSchematronconstraint in{rules} of a globalelement declarationGMUST beevaluated for all element instances ofG in a model duringthe model's validation.
All of the assertion tests in fired rulesMUST succeed.

6.4 Rules Authored in RuleDocuments

6.4.1 RuleBinding

Model validatorsMUST provide a mechanism to supportthe binding of Schematron patterns, authored in separaterule documents, to a set of documentsin a model. Rule documentsMAY bebound to model instance documents as well as model definitiondocuments. The mechanism for binding rule documents to a set ofdocuments in a model is implementation-defined.

7. Localization of Natural LanguageMessages

SML defines thesml:locid attribute in support oflocalization of natural-language texts, for example,smlif:description or Schematron messages.Model validatorsMAY supportsml:locid attribute onthe following elements:

sch:assert andsch:report in arule document.
sch:assert andsch:report in aSchematronpattern embedded in the {applicationinformation} of the {annotation} property of a complex typedefinition or an element declaration.
Elements in instance documents with textual content.

Model validators that support thesml:locidattributeMUST use thesml:locid attribute value to access the location ofthe translated text.

Note:

The mechanism for using theQName value of thesml:locid attribute to locate the translated text isimplementation-dependent. For example, thenamespace name canbe used to identify the resource containing the text and thelocal namecan be used to identify the text within such a resource. Refer toAppendixF. Localization andVariable Substitution Samples for a concrete sample of howthesml:locid attribute can be used to support textlocalization.

7.1 Variable Substitution

It is often the case that asch:assert orsch:report message can be reused in differentsituations. To be able to reuse a message, the rule author must beable to substitute variable content based on the context in whichthe message is being used.

Although this specification does not mandate the use of variablesubstitution in Schematron messages, it suggests the use ofxsl:variable when variable substitution is desired.Refer to AppendixF. Localizationand Variable Substitution Samples section for a concretesample of how thexsl:variable can be used in supportof reusing localized messages.

8. ConformanceCriteria

A program is aconforming SML model processor if andonly if it satisfies all the constraints imposed on processorselsewhere in this specification.

A conforming SML model processor is aconforming SML modelvalidator if and only if it satisfies the followingconditions:

The validatorMUST performmodel validation asdefined in this specification.
The validatorMUST support XML 1.0[XML], XML Schema 1.0[XML Schema Structures,XML Schema Datatypes], and XPath1.0 [XPath] butMAY also additionally support any future versionsof these specifications.
The validator MUST support Schematron [ISO/IEC 19757-3].
The validatorMUST performSchematron rule evaluation on the #ALL phase.
The validatorMUST support thederef() XPath extension function.
The validatorMUST identify all SMLreferences in the model using the Post Schema Validation Infoset.[XML Schema Structures]
The validatorMUST use the PostSchema Validation Infoset to determine if an SML reference in themodel is a null SML reference. [XML SchemaStructures]

The conformance of a model and the validity of a model can beassessed if and only if all documents in the model are available tothe model validator. A model validatorMUST document its behavior when a model documentis found to be unavailable (i.e. the behavior isimplementation-defined). ItMAYrespond to this condition in ways that include but are not limitedto: assessing the model as invalid, or treating this as a warning.The intent of the latitude granted to model validators in this caseis to provide some implementation flexibility by not prescribing alimited set of choices, however it is be read narrowly rather thanas a broad license to take unrelated actions like failing toenforce SML constraints on unrelated documents.

A model is aconforming SMLmodel if and only if it satisfies the followingconditions:

Eachdocument in the modelMUST be a well-formed XML document[XML]
For each XML Schema document in the model's definitiondocuments, the [validity] property of the root elementMUST be "valid" when schema validity is assessedwith respect to a schema constructed from theXML Schema for Schemas andA. Normative SML Schema schemadocuments.
All schemas assembled from the XML Schema documents in themodel's definition documentsMUSTsatisfy the conditions expressed in Errors in Schema Constructionand Structure (§5.1). [XML SchemaStructures]
All schemas assembled from the XML Schema documents in themodel's definition documentsMUSTsatisfy the conditions expressed in sections5.1.1.1 SML ConstraintConstruction,5.1.1.2 Schema ComponentRules,5.1.2.1 SMLConstraint Construction,5.1.2.2 Schema ComponentRules,5.2.1.1 SMLConstraint Construction,5.2.1.2 SchemaComponent Rules,6.3.1 SML Rule Constructionand6.3.2 SchemaComponent Rules.
Each Schematron document in the model's definition documentsMUST be a valid Schematron document[ISO/IEC 19757-3]

Note:

This specification does not define how schemas are assembled andwhich schema documents contribute to assembling the schemas.

Aconforming SML model is valid if and only if itsatisfies all of the following conditions:

In each instance document in the model, which is bound to aschema, the [validity] property of the root elementMUST be "valid", and the [validity] property ofall the other elements and all the attributesMUST NOT be "invalid", when schema validity isassessed with respect to any schema that is bound to this instancedocument. The schema validity assessment starts with no stipulateddeclaration or definition at the root element. [XML Schema Structures]
The schema-validity of instance documents not bound to anyschema does not contribute to the validity or invalidity of themodel.
Note:
How schemas are bound to instance documents is not defined bythis specification. Multiple schemas may be bound to the sameinstance document.
SML validity entails NOT being Schema-Invalid on the root or anydescendant. SML validity can be non-vacuously checked only afterassessment of Schema validity, and only on the portions of thesubtree for which PSVI is available.
Because the depth of PSVI is implementation-dependent, there isvariability in the visibility of SML constraints available to theSML validator, and consequently in SML validity results.
Each document in the modelMUSTsatisfy all applicable Schematron constraints when validated in the#ALL phase.
Each document in the modelMUSTsatisfy all normative statements in this specification that pertainto model documents.
Note:
This means, for example, that each document must satisfy allapplicable sml:acyclic, sml:target*, and SML identityconstraints.

9. SML Extensions Reference(Non-Normative)

This section is a reference guide to the SML extensions of XMLSchema and XPath.

9.1 Attributes

9.1.1 sml:acyclic

Used to specify that instances of an SML reference of a giventype and its derived types do not create any cycles in a model

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

If this attribute is set to true for a complex typeCT,then instances ofCT (including any derived types ofCT) that are SML references cannot create any cycles in amodel. In the following example, HostedOnRefType is a complex typedeclaration whose instances cannot create a cycle:

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

If thesml:acyclic attribute is not specified orset to false for a complex type declaration, then instances of thistype that are SML references may create cycles in a model.

9.1.2 sml:ref

This global attribute is used to identify SML references.

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

Any element that has sml:ref="true" will be treated as anSML reference.

9.1.3 sml:nilref

This global attribute is used to identify null SMLreferences.

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

Any SML reference that hassml:nilref="true" orsml:nilref="1" will be treated as a null SMLreference.

9.1.4sml:targetElement

AQName representing the name of a referencedelement

 <xs:attribute name="targetElement" type="xs:QName"/>

sml:targetElement is supported as an attribute forany element declaration. The value of this attribute must bethe name of some global element declaration. Letsml:targetElement="ns:GTE" for some elementdeclarationE. Then each element instance ofE musttarget an element that is an instance ofns:GTE or aninstance of some global element declaration in the substitutiongroup hierarchy whose head isns:GTE.

In the following example, the element referenced by instances ofHostOS must be an instance ofwin:Windows

<xs:element name="HostOS" type="tns:HostOSRefType" sml:targetElement="win:Windows" minOccurs="0"/><xs:complexType name="HostOSRefType">    <xs:sequence>            <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/></xs:complexType>

A model is invalid if its documents violate one or moresml:targetElement constraints.

9.1.5sml:targetRequired

Used to specify that instances of an SML reference must targetelements in the model; i.e., an instance of the SML reference cannot be null or contain an unresolved reference. Therefore it is anerror iftargetRequired="true" is specified on anelement declaration where the corresponding SML reference element Rhassml:nilref="true".

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

In the following example, thetargetRequiredattribute is used to specify that application instances must have ahost operating system.

<xs:complexType name="ApplicationType">    <xs:sequence>        <xs:element name="Name" type="xs:string"/>        <xs:element name="Vendor" type="xs:string"/>        <xs:element name="Version" type="xs:string"/>        <xs:element name="HostOSRef" type="tns:HostOSRefType" sml:targetRequired="true"/>    </xs:sequence></xs:complexType><xs:complexType name="HostOSRefType">    <xs:sequence>      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/></xs:complexType>

A model is invalid if its documents violate one or moresml:targetRequired constraints.

9.1.6sml:targetType

AQName representing the type of a referencedelement

<xs:attribute name="targetType" type="xs:QName" />

sml:targetType is supported as an attribute for anyelement declarations. If the value of this attribute is specifiedasT, then the type of the referenced element musteither beT or a derived type ofT. Inthe following example, the type of the element referenced by theOperatingSystem element must be"ibm:LinuxType" or its derived type

<xs:element name="OperatingSystem" type="tns:OperatingSystemRefType"            sml:targetType="ibm:LinuxType" minOccurs="0"/><xs:complexType name="OperatingSystemRefType">    <xs:sequence>        <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/></xs:complexType>

A model is invalid if its documents violate one or moresml:targetType constraints.

9.1.7 sml:locid

This attribute can be defined on thesch:assert,sch:report and on any element with textual content.Thesml:locid attribute is used to define thetranslation location for the text content of the containingelement.

<xs:attribute name="locid" type="xs:QName"/>

The mechanism for using theQName value of thesml:locid attribute to locate a translated text isimplementation specific and hence outside the scope of thisspecification.

9.2 Elements

9.2.1 sml:key

This element is used to specify a key constraint in some scope.The semantics are the same as that forxs:key exceptthatsml:key can also be used to specify keyconstraints on other documents; i.e., the sml:selector child element ofsml:key can containderef functions toresolve elements in another document.

<xs:element name="key" type="sml:keybase"/>

sml:key is supported in theappinfo ofanxs:element.

9.2.2 sml:keyref

Applies a constraint in the context of the containingxs:element that scopes the range of a nested documentreference.

    <xs:element name="keyref">    <xs:complexType>        <xs:complexContent>            <xs:extension base="sml:keybase">                <xs:attribute name="refer" type="xs:QName" use="optional"/>            </xs:extension>        </xs:complexContent>    </xs:complexType></xs:element>

sml:keyref is supported in theappinfoof anxs:element.

9.2.3 sml:unique

This element is used to specify a uniqueness constraint in somescope. The semantics are the same as that forxs:unique except thatsml:unique can alsobe used to specify uniqueness constraints on other documents; i.e.,the sml:selector child element ofsml:unique can containderef functions toresolve elements in another document.

<xs:element name="unique" type="sml:keybase"/>

sml:unique is supported in theappinfoof anxs:element.

9.2.4 sml:uri

Specifies an SML reference that is an instance of the SML URIreference scheme.

<xs:element name="uri" type="xs:anyURI"/>

This element must be used to specify SML references that use theSML URI Reference Scheme.

9.3 XPathfunctions

9.3.1 smlfn:deref

node-set deref(node-set)

This function takes a node set and attempts to resolve the SMLreferences. The resulting node set is the set of elements thatare obtained by successfully resolving (or de-referencing) the SML references. For example,

deref(/u:Universities/u:Students/u:Student)

will resolve the SML reference,Student. The targetof an SML reference must always be an element.

10. References

10.1 Normative

[SML-IF1.1]: Service ModelingLanguage Interchange Format Version 1.1, BhalchandraPandit, Valentina Popescu, Virginia Smith, Editors. World Wide WebConsortium, 12 May 2009. This version of the Service ModelingLanguage Interchange Format specification is available athttp://www.w3.org/TR/2009/REC-sml-if-20090512/. Thelatest version of the ServiceModeling Language Interchange Format Version 1.1 specificationis available at http://www.w3.org/TR/sml-if/.
[IETF RFC2119]: Key wordsfor 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.
[IETF RFC3986]: UniformResource Identifier (URI): Generic Syntax , T.Berners-Lee, R. Fielding, L. Masinter, Authors. InternetEngineering Task Force, January 2005. Available athttp://www.ietf.org/rfc/rfc3986.txt.
[IETF RFC3987]: Internationalized ResourceIdentifiers (IRIs) , M. Duerst, M. Suignard, Authors.Internet Engineering Task Force, January 2005. Available athttp://www.ietf.org/rfc/rfc3987.txt.
[RFC2234]: Augmented BNF forSyntax Specifications: ABNF, Internet Mail Consortium,November 1997. Available athttp://www.rfc-editor.org/rfc/rfc2234.txt.
[ISO/IEC19757-3]: Information technology ― Document Schema Definition Languages(DSDL) ― Part 3: Rule-based validation ― Schematron.International Organization for Standardization and InternationalElectrotechnical Commission, 1 January 2006. Available athttp://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip
[XML-NS]: Namespaces inXML 1.0 (Second Edition), Tim Bray, Dave Hollander,Andrew Layman, Richard Tobin, Editors. World Wide Web Consortium,16 August 2006. This version of the Namespaces in XMLRecommendation ishttp://www.w3.org/TR/2006/REC-xml-names-20060816/. Thelatest version of Namespaces inXML is available at http://www.w3.org/TR/xml-names/.
[XML]: Extensible MarkupLanguage (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli,C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide WebConsortium, 10 February 1998, revised 16 August 2006. The editioncited (http://www.w3.org/TR/2006/REC-xml-20060816) was the onecurrent at the date of publication of this specification as aCandidate Recommendation. Thelatest version of XML 1.0 isavailable at http://www.w3.org/TR/xml/. Implementations may followthe edition cited and/or any later edition(s); it isimplementation-defined which editions are supported by animplementation.
[XMLInformation Set]: XMLInformation Set (Second Edition), John Cowan, RichardTobin, Editors. World Wide Web Consortium, 4 February 2004. Thisversion of the XML Information Set Recommendation ishttp://www.w3.org/TR/2004/REC-xml-infoset-20040204/. Thelatest version of XMLInformation Set is available athttp://www.w3.org/TR/xml-infoset/.
[XML SchemaStructures]: XML SchemaPart 1: Structures Second Edition, H. Thompson, D.Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide WebConsortium, 2 May 2001, revised 28 October 2004. This version ofthe XML Schema Part 1 Recommendation ishttp://www.w3.org/TR/2004/REC-xmlschema-1-20041028. Thelatest version of XML Schema1.0 Part 1 is available athttp://www.w3.org/TR/xmlschema-1.
[XML SchemaDatatypes]: XML SchemaPart 2: Datatypes Second Edition, P. Byron and A.Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised28 October 2004. This version of the XML Schema Part 2Recommendation ishttp://www.w3.org/TR/2004/REC-xmlschema-2-20041028. Thelatest version of XML Schema1.0 Part 2 is available athttp://www.w3.org/TR/xmlschema-2.
[XML Schema forSchemas]: XML Schemafor XML Schemas. World Wide Web Consortium, 2 May 2001,revised 28 October 2004.
[XPath]: XML Path Language(XPath) Version 1.0, J. Clark and S. DeRose, Editors.World Wide Web Consortium, 16 November 1999. This version of XMLPath Language (XPath) Version 1.0 ishttp://www.w3.org/TR/1999/REC-xpath-19991116. Thelatest version of XML Path Language(XPath) Version 1.0 is available athttp://www.w3.org/TR/xpath.
[XPointer]: XPointerFramework, P. Grosso, E. Maler, J. Marsh, and N. Walsh,Editors. World Wide Web Consortium, 25 March 2003. This version ofthe XPointer Framework Recommendation ishttp://www.w3.org/TR/2003/REC-xptr-framework-20030325/ Thelatest version of XPointerFramework is available athttp://www.w3.org/TR/xptr-framework/.
[xmlns()Scheme]: XPointerxmlns() Scheme, S. DeRose, R. Daniel Jr., E. Maler, andJ. Marsh, Editors. World Wide Web Consortium, 25 March 2003. Thisversion of the XPointer xmlns() Scheme Recommendation ishttp://www.w3.org/TR/2003/REC-xptr-framework-20030325/ Thelatest version of XPointerxmlns() Scheme is available athttp://www.w3.org/TR/xptr-xmlns/.

10.2 Non-Normative

[Introduction to Schematron]: AnIntroduction to Schematron, Eddie Robertsson, Author.O'Reilly Media, Inc., 12 November 2003. Available athttp://www.xml.com/pub/a/2003/11/12/schematron.html
[Improving Validation withSchematron]: ImprovingXML Document Validation with Schematron, Dare Obasanjo,Author. Microsoft Corporation, September 2004. Available athttp://msdn.microsoft.com/en-us/library/aa468554.aspx
[XML SchemaPrimer]: XML SchemaPart 0: Primer Second Edition, D. Fallside and P.Walmsley, Editors. World Wide Web Consortium, 2 May 2001, revised28 October 2004. This version of the XML Schema Part 0Recommendation ishttp://www.w3.org/TR/2004/REC-xmlschema-0-20041028. Thelatest version of XML SchemaPart 0 is available at http://www.w3.org/TR/xmlschema-0.

A. Normative SMLSchema

<!--/* * Copyright © ns World Wide Web Consortium, * * (Massachusetts Institute of Technology, European Research Consortium for * Informatics and Mathematics, Keio University). All Rights Reserved. This * work is distributed under the W3C® Document License [1] in the hope that * it will be useful, but WITHOUT ANY WARRANTY; without even the implied * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 */--><xs:schema      xmlns:sml="http://www.w3.org/ns/sml"      xmlns:xs="http://www.w3.org/2001/XMLSchema"      targetNamespace="http://www.w3.org/ns/sml"      elementFormDefault="qualified"      blockDefault="#all"      version="1.0"      xml:lang="en"      finalDefault=""      attributeFormDefault="unqualified">   <!--        References        ==========    -->      <!-- CONTEXT: To be used in any <xs:element> -->   <xs:attribute name="ref" type="xs:boolean">      <xs:annotation>         <xs:documentation>                Specifies if the element contains a reference            </xs:documentation>      </xs:annotation>   </xs:attribute>   <!-- CONTEXT: To be used in any <xs:element> -->   <xs:attribute name="nilref" type="xs:boolean">      <xs:annotation>         <xs:documentation>                Specifies that the reference element denotes a “null” reference.                 To be used only on elements for which sml:ref="true".            </xs:documentation>      </xs:annotation>   </xs:attribute>   <!-- CONTEXT: To be used in any <xs:element> -->   <xs:attribute name="targetElement" type="xs:QName">      <xs:annotation>         <xs:documentation>                A qualified name of a global element in the referenced document.            </xs:documentation>      </xs:annotation>   </xs:attribute>   <!-- CONTEXT: To be used in any <xs:element>-->   <xs:attribute name="targetRequired" type="xs:boolean">      <xs:annotation>         <xs:documentation>                If true, requires the target element of the reference to                exist in the model.            </xs:documentation>      </xs:annotation>   </xs:attribute>   <!-- CONTEXT: To be used in any <xs:element>-->   <xs:attribute name="targetType" type="xs:QName">      <xs:annotation>         <xs:documentation>                A qualified name of the type of the element in the                referenced document.            </xs:documentation>      </xs:annotation>   </xs:attribute>   <!-- CONTEXT: To be used in any <xs:complexType>-->   <xs:attribute name="acyclic" type="xs:boolean">      <xs:annotation>         <xs:documentation>                If this attribute is set to true for a type D                 then instances of D should not create any                cycles in a model. See Section 5.1.1.3 titled "Instance Validity Rules".                            </xs:documentation>      </xs:annotation>   </xs:attribute>   <!-- CONTEXT: To be used in <sch:assert>, <sch:report>         and elements with textual content.         This attribute is used to support string localization.         It is used to define the translation location for          the text content of the containing element.-->   <xs:attribute name="locid" type="xs:QName"/>   <!-- CONTEXT: Represents a reference using the URI scheme. To be         used as a child  element of elements for which         sml:ref="true". -->   <xs:element name="uri" type="xs:anyURI">      <xs:annotation>         <xs:documentation>                References in URI scheme must be representend by this                element.              </xs:documentation>      </xs:annotation>   </xs:element>   <!--        Uniqueness and Key constraints        ==============================    -->   <xs:complexType name="keybase" mixed="false">      <xs:sequence minOccurs="0">         <xs:element               name="selector"               type="sml:selectorXPathType"/>         <xs:element               name="field"               type="sml:fieldXPathType"               maxOccurs="unbounded"/>         <xs:any               namespace="##other"               minOccurs="0"               maxOccurs="unbounded"               processContents="lax"/>      </xs:sequence>      <xs:attribute name="name" type="xs:NCName"/>      <xs:attribute name="ref" type="xs:QName"/>      <xs:anyAttribute            namespace="##other"            processContents="lax"/>   </xs:complexType>   <xs:element name="key" type="sml:keybase"/>   <xs:element name="unique" type="sml:keybase"/>   <xs:element name="keyref">      <xs:complexType mixed="false">         <xs:complexContent>            <xs:extension base="sml:keybase">               <xs:attribute                     name="refer"                     type="xs:QName"                     use="optional"/>            </xs:extension>         </xs:complexContent>      </xs:complexType>   </xs:element>   <!--        Other Complex Types        ==================    -->   <xs:complexType name="selectorXPathType" mixed="false">      <xs:sequence>         <xs:any               namespace="##other"               minOccurs="0"               maxOccurs="unbounded"               processContents="lax"/>      </xs:sequence>      <xs:attribute name="xpath" use="required">         <xs:simpleType>            <xs:restriction base="xs:string">   <!-- The value MUST conform to the selector BNF grammar defined in                         section '4.4 Identity Constraints' in the SML specification.                    -->   </xs:restriction>         </xs:simpleType>      </xs:attribute>      <xs:anyAttribute            namespace="##other"            processContents="lax"/>   </xs:complexType>   <xs:complexType name="fieldXPathType" mixed="false">      <xs:sequence>         <xs:any               namespace="##other"               minOccurs="0"               maxOccurs="unbounded"               processContents="lax"/>      </xs:sequence>      <xs:attribute name="xpath" use="required">         <xs:simpleType>            <xs:restriction base="xs:string">   <!-- The value MUST conform to the field BNF grammar defined in                         section '4.4 Identity Constraints' in the SML specification.                    -->   </xs:restriction>         </xs:simpleType>      </xs:attribute>      <xs:anyAttribute            namespace="##other"            processContents="lax"/>   </xs:complexType></xs:schema>

B. Model Definition DocumentSample (Non-Normative)

Thismodel definitiondocument sample illustrates the use of the following SMLextensions:

SML references
key andkeyref constraints
Schematron constraints

<?xml version="1.0" encoding="utf-8"?><!--/* * Copyright ©  World Wide Web Consortium, * * (Massachusetts Institute of Technology, European Research Consortium for * Informatics and Mathematics, Keio University). All Rights Reserved. This * work is distributed under the W3C® Document License [1] in the hope that * it will be useful, but WITHOUT ANY WARRANTY; without even the implied * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 */--><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://example.org/SampleModel" xmlns:sml="http://www.w3.org/ns/sml" xmlns:smlfn="http://www.w3.org/ns/sml-function" xmlns:sch="http://purl.oclc.org/dsdl/schematron" targetNamespace="http://example.org/SampleModel" elementFormDefault="qualified" finalDefault="" blockDefault="" attributeFormDefault="unqualified">  <xs:simpleType name="SecurityLevel">    <xs:restriction base="xs:string">      <xs:enumeration value="Low"/>      <xs:enumeration value="Medium"/>      <xs:enumeration value="High"/>    </xs:restriction>  </xs:simpleType>  <xs:complexType name="Hostref" sml:acyclic="true" mixed="false">    <xs:sequence>      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/>  </xs:complexType>     <!-- This element represents the host operating system for       an application. Note that the type of the referenced       element must be OperatingSystemType or a derived type       of OperatingSystemType -->     <xs:element name="HostOSRef" type="tns:Hostref" sml:targetType="tns:OperatingSystemType"/>  <xs:complexType name="ApplicationType" mixed="false">    <xs:sequence>      <xs:element name="Name" type="xs:string"/>      <xs:element name="Vendor" type="xs:string"/>      <xs:element name="Version" type="xs:string"/>      <xs:element ref="tns:HostOSRef" minOccurs="0"/>    </xs:sequence>  </xs:complexType>   <xs:simpleType name="ProtocolType">    <xs:list>      <xs:simpleType>        <xs:restriction base="xs:string">          <xs:enumeration value="TCP"/>          <xs:enumeration value="UDP"/>          <xs:enumeration value="SMTP"/>          <xs:enumeration value="SNMP"/>        </xs:restriction>      </xs:simpleType>    </xs:list>  </xs:simpleType>  <xs:complexType name="GuestAppRefType" sml:acyclic="false" mixed="false">    <xs:sequence>      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/>  </xs:complexType>    <xs:element name="GuestAppRef" type="tns:GuestAppRefType" sml:targetType="tns:ApplicationType"/>  <xs:complexType name="OperatingSystemType" mixed="false">    <xs:sequence>      <xs:element name="Name" type="xs:string"/>      <xs:element name="FirewallEnabled" type="xs:boolean"/>      <xs:element name="Protocol" type="tns:ProtocolType"/>         <!-- The following element represents the applications hosted by           operating system -->         <xs:element name="Applications" minOccurs="0">        <xs:complexType mixed="false">          <xs:sequence>            <xs:element ref="tns:GuestAppRef" maxOccurs="unbounded"/>          </xs:sequence>        </xs:complexType>      </xs:element>    </xs:sequence>  </xs:complexType>  <xs:complexType name="OSRefType" sml:acyclic="false" mixed="false">    <xs:sequence>      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/>  </xs:complexType>  <xs:element name="OSRef" type="tns:OSRefType" sml:targetType="tns:OperatingSystemType"/>  <xs:complexType name="WorkstationType" mixed="false">    <xs:sequence>      <xs:element name="Name" type="xs:string"/>      <xs:element ref="tns:OSRef"/>      <xs:element name="Applications" minOccurs="0">        <xs:complexType mixed="false">          <xs:sequence>            <xs:element ref="tns:GuestAppRef" maxOccurs="unbounded"/>          </xs:sequence>        </xs:complexType>      </xs:element>    </xs:sequence>  </xs:complexType>   <xs:element name="Workstation" type="tns:WorkstationType">    <xs:annotation>      <xs:appinfo>        <sch:schema>          <sch:ns prefix="sm" uri="SampleModel"/>          <sch:ns prefix="smlfn" uri="http://www.w3.org/ns/sml-function"/>          <sch:pattern>               <!-- The constraints in the following rule are evaluated                   For all instances of the Workstation global element-->               <sch:rule context=".">                 <!-- define a named variable - MyApplications -                   for use in test expression-->                 <sch:let name="MyApplications" value="smlfn:deref(sm:Applications/sm:GuestAppRef)"/>              <sch:assert test="count($MyApplications)=count($MyApplications/sm:HostOSRef)">                Each application in workstation                <sch:value-of select="string(sm:Name)"/>                must be hosted on an operating system              </sch:assert>            </sch:rule>          </sch:pattern>        </sch:schema>           <!-- In a workstation, (Vendor,Name,Version) is the key for             guest applications -->           <sml:key name="GuestApplicationKey">          <sml:selector xpath="smlfn:deref(tns:Applications/tns:GuestAppRef)"/>          <sml:field xpath="tns:Vendor"/>          <sml:field xpath="tns:Name"/>          <sml:field xpath="tns:Version"/>        </sml:key>           <!-- In a workstation, Name is the key for operating system -->           <sml:key name="OSKey">          <sml:selector xpath="smlfn:deref(tns:OSRef)"/>          <sml:field xpath="tns:Name"/>        </sml:key>                   <!-- In a workstation, the applications hosted by the             referenced operatinsystem must be a subset of the             applications in the workstation -->           <sml:keyref name="OSGuestApplication" refer="tns:GuestApplicationKey">          <sml:selector xpath="smlfn:deref(tns:OSRef)/tns:Applications/tns:GuestAppRef"/>          <sml:field xpath="tns:Vendor"/>          <sml:field xpath="tns:Name"/>          <sml:field xpath="tns:Version"/>           </sml:keyref>           <!-- In a workstation, the host operating system of guest             applications must be a subset of the operating system in             the workstation -->           <sml:keyref name="ApplicationHostOS" refer="tns:OSKey">          <sml:selector xpath="smlfn:deref(tns:Applications/tns:GuestAppRef)/tns:HostOSRef"/>          <sml:field xpath="tns:Name"/>        </sml:keyref>      </xs:appinfo>    </xs:annotation>  </xs:element>  <xs:element name="SecureWorkstation" type="tns:WorkstationType">    <xs:annotation>      <xs:appinfo>        <sch:schema>          <sch:ns prefix="sm" uri="SampleModel"/>          <sch:ns prefix="smlfn" uri="http://www.w3.org/ns/sml-function"/>          <sch:pattern>            <sch:rule context="sm:Applications/sm:Application">              <sch:report test="smlfn:deref(.)[sm:SecurityLevel!='High']">                Application <sch:value-of select="string(sm:Name)"/>                from <sch:value-of select="string(sm:Vendor)"/>                does not have high security level.              </sch:report>              <sch:assert test="smlfn:deref(.)[sm:Vendor='TrustedVendor']">                A secure workstation can only contain                applications from TrustedVendor.              </sch:assert>            </sch:rule>          </sch:pattern>        </sch:schema>      </xs:appinfo>    </xs:annotation>  </xs:element></xs:schema>

C. SML References Sample(Non-Normative)

The following example illustrates the use of SML references.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 anddoes not make use of any SML attributes, elements, or types. TheEnrolledCourse element, however, has an open contentmodel and this can be used to mark instances ofEnrolledCourse as SML references as shown below:

<Student xmlns="http://www.university.example.org/ns"         xmlns:sml="http://www.w3.org/ns/sml"         xmlns:u="http://www.university.example.org/ns">    <ID>1000</ID>    <Name>John Doe</Name>    <EnrolledCourses>        <EnrolledCourse sml:ref="true">            <Name>PHY101</Name>            <Grade>A</Grade>            <sml:uri>                http://www.university.example.org/Universities/MIT/Courses.xml                #smlxpath1(/u:Courses/u:Course[u:Name='PHY101'])            </sml:uri>        </EnrolledCourse>        <EnrolledCourse sml:ref="false">            <Name>MAT100</Name>            <Grade>B</Grade>            <sml:uri>                http://www.university.example.org/Universities/MIT/Courses.xml                #smlxpath1(/u:Courses/u:Course[u:Name='MAT100'])            </sml:uri>        </EnrolledCourse>        <EnrolledCourse>            <Name>SocialSkills</Name>            <Grade>F</Grade>        </EnrolledCourse>    </EnrolledCourses></Student>

The firstEnrolledCourse element in the aboveexample is an SML reference since it specifiessml:ref="true". It uses the SML URI Reference Schemeto target the element for course PHY101. The second and thirdEnrolledCourse elements are not SML references; thesecond element specifiessml:ref="false" and the thirdelement does not specify thesml:ref attribute. Notethat the secondEnrolledCourse element contains ansml:uri element which satisfies the syntax of the SMLURI Reference Scheme (referring to course MAT100) but this will beignored sincesml:ref="false" for thisEnrolledCourse element.

Note that, there are no SML constraints defined on theEnrolledCourse element or on the type of that elementin the schema. Therefore, even if the firstEnrolledCourse element instance is marked as an SMLreference, no SML constraints are evaluated for that element duringmodel validation. However, checks such as the ones defined insection4.2.1 At Most OneTarget and section4.2.2 Consistent References arestill performed on that SML reference during model validation.

AnEnrolledCourse SML reference can be a marked asa null reference if it specifies thesml:nilref="true"attribute as shown in the following example (the firstEnrolledCourse element is a null SML reference):

<Student xmlns="http://www.university.example.org/ns"         xmlns:sml="http://www.w3.org/ns/sml"         xmlns:u="http://www.university.example.org/ns">    <ID>1000</ID>    <Name>John Doe</Name>    <EnrolledCourses>        <EnrolledCourse sml:ref="true" sml:nilref="true">            <Name>PHY101</Name>            <Grade>A</Grade>        </EnrolledCourse>        <EnrolledCourse sml:ref="false">            <Name>MAT100</Name>            <Grade>B</Grade>            <sml:uri>                http://www.university.example.org/Universities/MIT/Courses.xml                #smlxpath1(/u:Courses/u:Course[u:Name='MAT100'])            </sml:uri>        </EnrolledCourse>        <EnrolledCourse>            <Name>SocialSkills</Name>            <Grade>F</Grade>        </EnrolledCourse>    </EnrolledCourses></Student>

In the above example, the first SML reference,EnrolledCourse, defines thesml:nilref="true" attribute which marks this as a nullSML reference. By specifying a null reference, the document authormakes an explicit declaration that thisStudentelement does not refer to any target element. Specifying a nullreference does not have any SML-defined effect on theinterpretation of element in non-SML contexts. In particular, inthis case, SML says nothing about the interpretation of theGrade andName elements. Any suchinterpretation is left to the application, its usage context, otherspecifications, etc.

D. SML URI Reference SchemeSample (Non-Normative)

The following example illustrates the use of the SML URIReference Scheme [4.3.1 SML URIReference Scheme]. Consider the case where all coursesoffered 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 insideCourses.xml thatcorresponds to the course PHY101 can be referenced as follows(assuming thatCoursesis the root element inCourses.xml)

<Student xmlns="http://www.university.example.org/ns">    <ID>1000</ID>    <Name>John Doe</Name>    <EnrolledCourses>        <EnrolledCourse sml:ref="true" xmlns:u="http://www.university.example.org/ns">            <sml:uri>                http://www.university.example.org/Universities/MIT/Courses.xml                #smlxpath1(/u:Courses/u:Course[u:Name='PHY101'])            </sml:uri>        </EnrolledCourse>    </EnrolledCourses></Student>

An SML reference can also reference an element in its owndocument. To see this consider the following instance document

<University xmlns="http://www.university.example.org/ns">    <Name>MIT</Name>    <Courses>        <Course>            <Name>PHY101</Name>        </Course>        <Course>            <Name>MAT200</Name>        </Course>    </Courses>    <Students>        <Student>            <ID>123</ID>            <Name>Jane Doe</Name>            <EnrolledCourses>                <EnrolledCourse sml:ref="true" xmlns:u="http://www.university.example.org/ns">                    <sml:uri>                        #smlxpath1(/u:University/u:Courses/u:Course[u:Name='MAT200'])                    </sml:uri>                </EnrolledCourse>            </EnrolledCourses>        </Student>    </Students></University>

Here, theEnrolledCourse element for the studentJane Doe references theCourse element for MAT200 inthe same document.

E. SML Identity ConstraintsSample (Non-Normative)

The following example will be used to illustrate thesml:key,sml:unique, andsml:keyref constraints across SML references. Thisexample consists of three schema documents.university.xsd contains the type definitions for aUniversity element, a Student SML reference and a Course SMLreference.students.xsd contains the type definitionsfor an EnrolledCourse SML reference and a Student element.courses.xsd contains the type definition for a Courseelement.

<!-- from university.xsd --><xs:complexType name="StudentRefType">    <!-- SML reference to a Student -->    <xs:sequence>        <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/></xs:complexType>  <xs:element name="Student" type="StudentRefType"/><xs:complexType name="CourseRefType">    <!-- SML reference to a Course -->    <xs:sequence>        <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/></xs:complexType><xs:element name="Course" type="CourseRefType"/><xs:complexType name="UniversityType">    <xs:sequence>        <xs:element name="Name" type="xs:string"/>        <xs:element name="Students" minOccurs="0">        <xs:complexType>            <xs:sequence>              <xs:element ref="Student" maxOccurs="unbounded"/>            </xs:sequence>        </xs:complexType>        </xs:element>        <xs:element name="Courses" minOccurs="0">        <xs:complexType>            <xs:sequence>              <xs:element ref="Course" maxOccurs="unbounded"/>            </xs:sequence>        </xs:complexType>        </xs:element>    </xs:sequence></xs:complexType><!-- from students.xsd --><xs:complexType name="EnrolledCourseRefType">    <!-- SML reference to a Course -->    <xs:sequence>        <xs:element name="Grade" type="xs:string"/>        <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>    <xs:anyAttribute namespace="##any" processContents="lax"/></xs:complexType><xs:element name="EnrolledCourse" type="EnrolledCourseRefType"/><xs:complexType name="StudentType">    <xs:sequence>        <xs:element name="ID" type="xs:string"/>        <xs:element name="SSN" type="xs:string" minOccurs="0"/>        <xs:element name="Name" type="xs:string"/>        <xs:element name="EnrolledCourses" minOccurs="0">        <xs:complexType>            <xs:sequence>                <xs:element ref="EnrolledCourse" maxOccurs="unbounded"/>            </xs:sequence>        </xs:complexType>        </xs:element>    </xs:sequence></xs:complexType><xs:element name="Students">    <xs:complexType>        <xs:sequence>            <xs:element name="Student" type="StudentType"/>        </xs:sequence>    </xs:complexType></xs:element><!-- from courses.xsd --><xs:complexType name="CourseType">    <xs:sequence>        <xs:element name="Name" type="xs:string"/>        <xs:element name="EnrolledStudents" minOccurs="0">        <xs:complexType>            <xs:sequence>                <xs:element name="EnrolledStudent" maxOccurs="unbounded">                <xs:complexType>                    <xs:sequence>                        <xs:element name="StudentID" type="xs:string"/>                    </xs:sequence>                </xs:complexType>                </xs:element>            </xs:sequence>        </xs:complexType>        </xs:element>    </xs:sequence></xs:complexType><xs:element name="Courses">    <xs:complexType>        <xs:sequence>            <xs:element name="Course" type="CourseType"/>        </xs:sequence>    </xs:complexType></xs:element>

sml:key and sml:unique

XML Schema supports key and uniqueness constraints throughxs:key andxs:unique, but theseconstraints can only be specified within a single XML document. Thesml:key andsml:unique elements support the specification of key and uniqueness constraintsacross documents. We'll use theUniversityTypedefinition to illustrate this concept. It is reasonable to expectthat each student in a university must have a unique identity, andthis identity must be specified. This can be expressed asfollows:

<xs:element name="University" type="tns:UniversityType">    <xs:annotation>        <xs:appinfo>            <sml:key name="StudentIDisKey">                <sml:selector xpath="smlfn:deref(tns:Students/tns:Student)/tns:ID"/>                <sml:field xpath="."/>              </sml:key>          </xs:appinfo>    </xs:annotation></xs:element>

Thesml:key andsml:unique constraintsare similar but not the same.sml:key requires thatthe specified fields must be present in instance documents and haveunique values, whereassml:unique simply requires thespecified fields to have unique values but does not require them tobe present in instance documents. Thus keys imply uniqueness,but uniqueness does not imply keys. For example, students ina university must have a unique social security numbers, but theuniversity may have foreign students who do not possess thisnumber. This constraint can be specified as follows:

<xs:element name="University" type="tns:UniversityType">    <xs:annotation>        <xs:appinfo>            <sml:unique name="StudentSSNisUnique">                <sml:selector xpath="smlfn:deref(tns:Students/tns:Student)"/>                <sml:field xpath="tns:SSN"/>              </sml:unique>          </xs:appinfo>    </xs:annotation></xs:element>

Thesml:key andsml:unique constraint are always specified in the context of a scopingelement. In the above example, theUniversity elementdeclaration is the context for the key and unique constraints.

The following example illustrates the use of theref attribute in an SML identity constraint:

<xs:element name="PrivateUniversity" type="tns:UniversityType">    <xs:annotation>        <xs:appinfo>            <sml:unique ref="tns:StudentSSNisUnique"/>        </xs:appinfo>    </xs:annotation></xs:element>

In the above example, thePrivateUniversity elementdeclaration specifies theStudentSSNisUnique uniqueconstraint by referencing itsname in theUniversity element declaration.

sml:keyref

XML Schema supports key references throughxs:keyref to ensure that one set of values is a subsetof another set of values within an XML document. Such constraintsare similar to foreign keys in relational databases. Key referencesin XML Schema are only supported within a single XML document. Thesml:keyref element allows key references to bespecified across SML references and across XML documents. Thefollowing example usessml:keyref to capture therequirement that students enrolled in a course must be currentlyenrolled in the university:

<xs:element name="University" type="tns:UniversityType">    <xs:annotation>        <xs:appinfo>            <sml:key name="StudentIDisKey">                <sml:selector xpath="smlfn:deref(tns:Students/tns:Student)"/>                <sml:field xpath="tns:ID"/>              </sml:key>              <sml:keyref name="CourseStudents" refer="tns:StudentIDisKey">                <sml:selector xpath="smlfn:deref(tns:Courses/tns:Course)/tns:EnrolledStudents/tns:EnrolledStudent"/>                <sml:field xpath="tns:ID"/>            </sml:keyref>        </xs:appinfo>    </xs:annotation></xs:element>

The above constraint specifies that for a university, the set ofIDs of students enrolled in a course is a subset of the set of IDsof students currently enrolled in the university. In particular,theselector andfield elements inStudentIDisKey key constraint identify the set of IDsof students currently enrolled in the university, and theselector andfield elements inCourseStudents key reference constraint identify theset of IDs of students enrolled in courses.

F.Localization and Variable Substitution Samples (Non-Normative)

The following examples demonstrate how localization can beapplied to a message text resulting from Schematron ruleevaluation, allowing amodelprocessor to support multiple locales without changes to eitherthe model processor or the Schematron rules. Summarized below arethe benefits resulting from using thesml:locidlocalization support:

The Schematron rule message text is locale-independent in thesense that the author does not have to be concerned with the ruleevaluator's runtime locale. The Schematron rule is definedgenerically, consumable for any evaluator (including a modelprocessor) for which a translation file is made available at thelocation defined by thesml:locid value'snamespace name.
There is a clear separation between the message texttranslation, Schematron rule authoring, and Schematron ruleevaluator code. The Schematron rules require no changes whentranslations for other languages are made available. The sameSchematron rule can be used by multiple evaluators, each supportinga distinct set of languages. To support a new language, all thatneeds to be done is to add a new translation file under thelocation identified by thesml:locid value'snamespace name.

Building on the preceding university example, the followingexample of a Schematron rule uses thesml:locidattribute to locate translation information for the Schematronsch:assert error message:

<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"            xmlns:lang="http://www.university.example.org/translation/">      <sch:ns prefix="u" uri="http://www.university.example.org/ns" />    <sch:ns prefix="smlfn" uri="http://www.w3.org/ns/sml-function"/>    <sch:patternu:Students/u:Student">            <sch:assert test=".[starts-with(u:ID,'99')]"                        sml:locid="lang:StudentIDErrorMsg">                The specified ID <sch:value-of select="string(u:ID)"/> does not begin with 99.            </sch:assert>        </sch:rule>    </sch:pattern></sch:schema>

In general, thenamespace name canpoint to a file containing the translated message, a foldercontaining a set of translated files or any other type of resourcethat can help locate the translated message. It isimplementation-dependent how the model validator makes use of thisinformation for finding the actual resource containing thetranslated message.

In this concrete example, thenamespace name ofthesml:locid attribute value is used to define thelocation of the resource containing the translated text:

xmlns:lang="http://www.university.example.org/translation/"

Also, in this concrete example,http://www.university.example.org/translation/ names afolder containing a set of translation resources, and there is oneset of translation files located underhttp://www.university.example.org/translation/. Eachof these translation files corresponds to a language into which themessages have been translated. The translations to French andGerman are available in the following files:

Filehttp://www.university.example.org/translation/lang_fr.txtcontains the French translation of thesch:assertmessage.
Filehttp://www.university.example.org/translation/lang_de.txtcontains the German translation of thesch:assertmessage.

The {local part} of thesml:locid attribute value(StudentIDErrorMsg) is used to define the identity ofthe message being translated. This identity is used to locate thetranslated text within the translation resource.

The French translation of thesch:assert message isfound in the following entry:

StudentIDErrorMsg = L'identifiant specifié <sch:value-of select="string(u:ID)"/> ne commence pas par 99.

The German translation for thesch:assert messageis found in the following entry:

StudentIDErrorMsg = Der angegebene Wert des Attributs ID (<sch:value-of  select="string(u:ID)"/>) beginnt nicht mit "99".

Translatable messages, especially strings containing XML tags(such as<sch:value-of select="string(u:ID)"/>in the example below), may be best stored in XML containers. Thisallows more flexibility to manipulate and translate the data. Forexample, the XML document could utilize ITS (seeInternationalization Tag Set (ITS)specification) to add localization-related information.

<?xml version="1.0" encoding="UTF-8"/><messages xml:lang="en"  xmlns:sch="http://purl.oclc.org/dsdl/schematron"  xmlns:its="http://www.w3.org/2005/11/its">      <msg xml:id='StudentIDErrorMsg'          its:locNote="This message should not be longer than 128 characters">          The specified ID <sch:value-of select="string(u:ID)"/> does not begin with 99.    </msg> </messages>

Best Practice Recommendation for VariableSubstitution

It is often the case that translated text can be reused, forexample, a Schematron message can be reused in differentsch:assert orsch:report rules andpatterns. In the example above, the author of the Schematron rulemay want to use this error message in other contexts:

The specified ID <sch:value-of select="string(u:ID)"/> does not begin with 99.

Reuse opportunities for this message are limited since thetranslated message contains implicit assumptions about the rulecontext. To be able to reuse this message more widely, the messageauthor should substitute a context-independent expression, such asa variable, in place of theu:ID in<sch:value-of select="string(u:ID)"/>.

Thus, the original message translations

StudentIDErrorMsg = L'identifiant specifié <sch:value-of select="string(u:ID)"/> ne commence pas par 99.StudentIDErrorMsg = Der angegebene Wert des Attributs ID (<sch:value-of  select="string(u:ID)"/>) beginnt nicht mit "99".

should instead be coded to use a variable's value, as shownbelow.

StudentIDErrorMsg = L'identifiant specifié <sch:value-of select="$studentID"/> ne commence pas par 99.StudentIDErrorMsg = Der angegebene Wert des Attributs ID (<sch:value-of  select="$studentID"/>) beginnt nicht mit "99".

The error message insch:assert, identified by thelang:StudentIDErrorMsg value, can now be reused inSchematron rule contexts other than the one described by the sampleabove. In cases where variable substitution is used in this way,the responsibility for setting the variable in the message'svarious usage contexts rests with the rule author(s). Specifically,the Schematron rule used to start the Appendix F portion of thisrunning example would need to set the value of thestudentID variable. The sample below shows how therevised translation resources would be referenced from a Schematronrule.

<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"            xmlns:lang="http://www.university.example.org/translation/">    <sch:ns prefix="u" uri="http://www.university.example.org/ns" />    <sch:ns prefix="smlfn" uri="http://www.w3.org/ns/sml-function"/>    <sch:patternu:Students/u:Student">        <sch:let name="studentID" value="u:ID"/>            <sch:assert test="starts-with(u:ID,'99')"                        sml:locid="lang:StudentIDErrorMsg">                The specified ID <sch:value-of select="$studentID"/> does not begin with 99.            </sch:assert>        </sch:rule>    </sch:pattern></sch:schema>

The error message insch:assert and thelocalization identifierlang:StudentIDErrorMsg can nowbe reused in contexts other thanu:Students/u:Student.

If the translated string named byStudentIDErrorMsgis intended for use only in the context of Schematron elements,this mechanism is sufficient. If the message is intended for use inadditional contexts, the preceding syntax is not necessarilysufficient. In order to allow reuse of translated stringsexploiting variable substitution in other contexts, a syntaxunderstood both inside and outside of Schematron elements isrequired.xsl:variable andsch:let arepossible choices, made more practical by SML’s requirement thatvalidators support the “xslt" query binding for Schematron.However, there is currently insufficient practical experience tolabel this a best practice.

G.Acknowledgements (Non-Normative)

The editors acknowledge the members of the Service ModelingLanguage Working Group, the members of other W3C Working Groups,and industry experts in other forums who have contributed directlyor indirectly to the process or content of creating thisdocument.

At the time this specification was published, the members of theService Modeling Language Working Group were:

John Arwe (IBM Corporation), Len Charest (MicrosoftCorporation), Sandy Gao (IBM Corporation), Paul Lipton (CA), JamesLynn (HP), Kumar Pandit (Microsoft Corporation), Valentina Popescu(IBM Corporation), Virginia Smith (HP), Henry Thompson (W3C/ERCIM),David Whiteman (IBM Corporation), Kirk Wilson (CA).

The Service Modeling Language Working Group has benefited in itswork from the participation and contributions of a number of peoplenot currently members of the Working Group, including in particularthose named below.

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), C. Michael Sperberg-McQueen (W3C/MIT), BassamTabbara (Microsoft), Vijay Tewari (Intel), William Vambenepe (HP),Marv Waschke (CA), Andrea Westerinen (Microsoft), Pratul Dublish(Microsoft), Julia McCarthy (IBM).

Affiliations given above are those current at the time of theirwork with the working group.

Movatterモバイル変換

Service Modeling Language,Version 1.1

W3C Recommendation12 May 2009

Abstract

Status of this Document

Table of Contents

Appendices

1. Introduction(Non-Normative)

2. Notations and Terminology

2.1 Notational Conventions

2.2 Terminology

2.3 XMLNamespaces

3. Dependencies onOther Specifications

4. SML References

4.1 SML Reference Definitions

4.1.1 SMLReference

4.1.2 Null SMLReference

4.1.3 Unresolved SML Reference

4.1.4 SML Reference Target

4.2SML Reference Semantics

4.2.1At Most One Target

4.2.2 Consistent References

4.2.3Identical Targets

4.2.4 Multiple References

4.2.5 NullSML References

4.2.6 Deterministic Evaluation ofSML Constraints

4.2.7 smlfn:deref() XPathExtension Function

4.3 SMLReference Schemes

4.3.1 SML URI Reference Scheme

4.3.1.1smlxpath1() scheme

5. SMLConstraints

5.1 Constraints on SMLReferences

5.1.1sml:acyclic

5.1.1.1 SML ConstraintConstruction

5.1.1.2 Schema ComponentRules

5.1.1.3 Instance ValidityRules

5.1.2 Constraints on SML ReferenceTargets

5.1.2.1 SML ConstraintConstruction

5.1.2.2 Schema ComponentRules

5.1.2.3 Instance ValidityRules

5.1.3 SML Reference Constraints Summary(Non-Normative)

5.2 SML Identity Constraints

5.2.1 Syntax andSemantics

5.2.1.1 SMLConstraint Construction

5.2.1.2 SchemaComponent Rules

5.2.1.3 InstanceValidity Rules

5.3 Valid Restriction of SMLConstraint Values

5.4 SMLConstraints and Complex Type Derivation

5.4.1 Overview of SMLConstraint Processing and Complex Type Derivation

5.4.2 Formal Definition

5.4.2.1 Properties

5.4.2.2 SML ConstraintConstruction

5.4.2.3 Instance ValidityRules

6. Rules

6.1 Informal Description(Non-Normative)

6.2 RuleSupport

6.3 RulesAssociated with Schema Components

6.3.1 SML Rule Construction

6.3.2 Schema Component Rules

6.3.3 Instance ValidityRules

6.4 Rules Authored in RuleDocuments

6.4.1 RuleBinding

7. Localization of Natural LanguageMessages

7.1 Variable Substitution

8. ConformanceCriteria

9. SML Extensions Reference(Non-Normative)

9.1 Attributes

9.1.1 sml:acyclic

9.1.2 sml:ref

9.1.3 sml:nilref

9.1.4sml:targetElement

9.1.5sml:targetRequired

9.1.6sml:targetType

9.1.7 sml:locid

9.2 Elements

9.2.1 sml:key

9.2.2 sml:keyref

9.2.3 sml:unique

9.2.4 sml:uri

9.3 XPathfunctions

4.3.1.1`smlxpath1()` scheme