W3C

Service Modeling Language Interchange Format Version 1.1

W3C Working Draft 14 January 2008

This version:
http://www.w3.org/TR/2008/WD-sml-if-20080114/
Latest version:
http://www.w3.org/TR/sml-if/
Previous version:
http://www.w3.org/TR/2007/WD-sml-if-20070806/
Editors:
Bhalchandra Pandit, Microsoft Corporation
Valentina Popescu, IBM Corporation
Virginia Smith, HP

This document is also available in these non-normative formats: XML.


Abstract

This specification defines the interchange format for Service Modeling Language, Version 1.1 (SML) models. Markup is defined to identify the model being interchanged, to distinguish between model definition documents and model instance documents, and to bind rule documents with other documents in the interchange set.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the third Public Working Draft of the Service Modeling Language Interchange Format Version 1.1 specification for review by W3C members and other interested parties. It has been developed by the Service Modeling Language (SML) Working Group, which is a part of the Extensible Markup Language (XML) Activity.

The features and algorithms described in the normative portion of the document are specified in enough detail adequate for early implementation experiments.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Comments on this document are invited and are to be sent to the public-sml@w3.org mailing list (public archive).

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction (Non-Normative)
2. Notations and Terminology
    2.1 Notational Conventions
    2.2 Terminology
3. Dependencies on Other Specifications
4. Informal Description (Non-Normative)
    4.1 Packaging
    4.2 URI References
    4.3 Rule Document Bindings
    4.4 Schema Document Bindings
5. SML Interchange Format Definition
    5.1 Conformance Criteria
    5.2 SML-IF Documents
        5.2.1 Embedded Documents
        5.2.2 Referenced Documents
    5.3 URI References
        5.3.1 URI equivalence
        5.3.2 Document aliases
        5.3.3 URI Reference Processing
    5.4 Rule Document Bindings
        5.4.1 URI prefix matching
        5.4.2 Bindings defined
    5.5 Schema Document Bindings
6. References
    6.1 Normative
    6.2 Non-Normative

Appendices

A. SML-IF Schema
B. Localization of IF Identity Sample (Non-Normative)


1. Introduction (Non-Normative)

As defined in the Service Modeling Language, Version 1.1 (SML) Specification [SML 1.1] an SML model is a collection of XML documents that may be used to describe complex services and systems such as a set of IT resources, services and their interrelations.

In every SML model there are two distinguished subsets of the model's documents, the definition documents and the instance documents. The model's definition documents describe the abstract structure of the model, and provide much of the information a model validator needs to decide whether the model as a whole is valid. The model's instance documents describe or support the description of the individual resources the model portrays.

The SML Specification identifies two categories of model definition documents that participate in model validation: Schema documents and rule documents. Schema documents in a model are XML documents that conform to the [SML 1.1] defined extensions to XML Schema [XML Schema Structures, XML Schema Datatypes]. Rule documents in a model include XML documents that conform to the [SML 1.1] defined extensions of Schematron [ISO/IEC 19757-3].

To ensure accurate and convenient interchange of the documents that make up an SML model or a portion of an SML model, it is useful to define an implementation-neutral interchange format that preserves the content and interrelationships among the documents. This specification defines a standard format called the SML Interchange Format (SML-IF) for this purpose.

The specification consists of two parts. The first part is an informal description of SML-IF to set the context. This is followed by SML-IF's normative definition.

2. Notations and Terminology

2.1 Notational Conventions

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

The content of this specification is normative except for sections, notes, or texts that are explicitly marked as non-normative. If a section is marked as non-normative, then all contained sub-sections are non-normative, even if they are not explicitly marked as such.

2.2 Terminology

Interchange set

The SML-IF interchange set is the set of documents that constitute the SML model to be interchanged.

Definition document, instance document, rule document

These terms are defined in the [SML 1.1] specification.

3. Dependencies on Other Specifications

Other specifications on which this one depends are listed in [Normative_References].

Conforming implementations of this specification MUST support SML 1.1 [SML 1.1], XML 1.0 [XML] and XML Schema 1.0 [XML Schema Structures, XML Schema Datatypes]. Conforming implementations MAY additionally support later versions of the XML or XML Schema specifications.

Note:

This note is non-normative. Although SML 1.1 and SML-IF allow conforming implementations to support newer versions of dependent specifications, there are interoperability implications to be considered when documents based on those versions are interchanged using SML-IF. When an SML-IF document interchanges data built using newer versions of the SML and SML-IF dependent specifications, consumers of the SML-IF document not supporting these versions may be unable to interpret some of the data exchanged by this document.

4. Informal Description (Non-Normative)

To represent an SML model in a standard way for interchange, three topics need to be addressed.

Packaging: The collection of XML documents that make up a model (or model portion) to be interchanged need to be gathered together. In doing so, the model definition and model instance documents need to be distinguished from one another since they play distinct roles in the model.

Explicit references: The documents to be interchanged may explicitly refer to one another and to documents that are not packaged with the documents being interchanged. SML [SML 1.1] references among SML model instance documents are an obvious example. Less obvious are such references as certain xsi:schemaLocation attributes in schema documents.

Binding of rule documents to the documents to which they apply: [SML 1.1] permits models in which rule documents apply to all, none, or subsets of the model's documents. SML-IF specifies how to describe which rule documents apply to which of the model's documents.

4.1 Packaging

An SML-IF document packages a collection of SML documents to be interchanged as a single XML document. All SML-IF documents conform to the XML Schema defined in the normative part of this specification.

Informally, the structure of SML-IF documents, using the pseudoschema notation from WSDL 2.0 [WSDL 2.0 Core Language] is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<model xmlns="http://www.w3.org/2008/01/sml-if"
      xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <identity>
    <name>
      xs:anyURI Namespace identifying the model
    </name>
    <version> ?
      xs:token <!—The version of this model. E.g., 1.2 or 0.3>
    </version>
    <displayName smlerr:localizationid=
                         "xs:anyURI URI identifying the translation
                        resource for the display name" ?> ?
      xs:string Descriptive name of model intended for display
    <displayName/>
    <description smlerr:localizationid=
                         "xs:anyURI URI identifying the translation
                        resource for the description" ?> ?
      xs:string Textual description of model for human consumption
    <description/>
  </identity>
  <ruleBindings> ?
   <ruleBinding> *
     <documentAlias="xs:anyURI"/> ?
     <ruleAlias="xs:anyURI"/>
   </ruleBinding>
  </ruleBindings>
  <schemaBindings> ?
    <defaultSchema> ?
      <namespaceBinding/> *  
    </defaultSchema>
    <schemaBinding> *
      <namespaceBinding/> *  
      <documentAlias/> +     
    </schemaBinding>
  </schemaBindings>
  <definitions schemaComplete="xs:boolean"> ?
    <document> *
      <docInfo> ?
        <aliases> ?
          <alias> *
            xs:anyURI A URI by which this document may be referred to
          </alias>
        </aliases>
      </docInfo>
     [
      <data>
        xs:any <!—At most one definition document goes here>
      </data>
     |
      <locator>
        <documentURI/> ?
        xs:any <!—A reference to a definition document goes here>
      </locator>
     ]
    </document>
  </definitions>
  <instances> ?
    <document> *
      <docInfo> ?
        <aliases> ?
          <alias> +
            xs:anyURI A URI by which this document may be referred to
          </alias>
        </aliases>
      </docInfo>
     [
      <data>
        xs:any<!—At most one instance document goes here>
      </data>
     |
      <locator>
        <documentURI/> ?
        xs:any <!—A reference to an instance document goes here>
      </locator>
     ]
    </document>
  </instances>
</model>

The identity element provides information applications can use to identify and describe the set of SML documents being interchanged.

The optional ruleBindings element is used to contain information that associates rule documents with the documents they apply to. See 4.3 Rule Document Bindings for further details.

The set of SML documents that are interchanged in an SML-IF document is called the interchange set. Every document in the interchange set appears as content of a document element in either the definitions or the instances element, depending on whether the document in question is a model definition or a model instance document. There can be at most one embedded document contained by a document/data element. Both definitions and instances are optional. So, for example, if there are no model definition documents being packaged, the definitions element must be omitted.

The first child of each document is typically a docInfo element that (indirectly) contains a list of alias elements whose content is a URI with no fragment component (i.e., one with no "#" in it). Each of these URIs serves as a name that other documents can use to refer to this document. Examples of how aliases are used to handle certain URI-based references are given in 4.2 URI References.

A document in the interchange set can be represented in either of two ways, by embedding its content, or by providing a reference to it. Which is being used is indicated by the next child of the document element. If the document is to be embedded, a data element is used to contain the actual content of the document. If the document is to be referred to, a locator element is used to contain the reference. Syntactically, the content of a locator can be a documentURI element defined by SML-IF or anything else understood by the consumer. Typically it is a URI, an XLink [XLink], or a Web Services Addressing endpoint reference [WS-Addressing Core].

Although it is not fully shown in the pseudo-schema above, the SML-IF schema has an "open content model." To provide extensibility, essentially every element in it can contain additional content and/or attributes from other XML namespaces.

4.2 URI References

When processing the SML model packaged inside an SML-IF document, certain URI references (as defined in RFC 3986 [IETF RFC 3986]) may need to be processed to find their corresponding target. For example, to assess SML validity of the interchanged model, SML references using the URI scheme need to be resolved; and to assemble a schema from multiple schema documents as part of SML model validity assessment, the schemaLocation attribute on an xs:include element needs to be processed to locate the schema document being included.

To see how these URI references are handled, consider the following SML-IF document:

<?xml version="1.0" encoding="UTF-8"?>
<model 
      xmlns="http://www.w3.org/2008/01/sml-if" version="1.0">
 <identity>
   <name>http://www.university.example.org/sml/models/Sample/InterDocReferences</name>
 </identity>
 <definitions>
   <document>
     <data>
        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
          <xs:include schemaLocation="http://www.university.example.org/university/enrollmodel.xsd"/>
        </xs:schema>     
     </data>      
   </document>
 </definitions>
 
 <instances>
   <document>
     <data>
       <Student xmlns="http://www.university.example.org/ns"
       	xmlns:sml="http://www.w3.org/2007/09/sml">
         <ID>1000</ID>
         <Name>John Doe</Name>
         <EnrolledCourses>
           <EnrolledCourse sml:ref="true">
<!-- Reference to a course Inside the interchange set -->                                     
             <sml:uri>
               http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
               xpointer(/u:Courses/u:Course[u:Name='PHY101'])
             </sml:uri>
           </EnrolledCourse>
           <EnrolledCourse sml:ref="true">
<!-- Reference to a course OUTside the interchange set -->                        
             <sml:uri>
               http://www.university.example.org/Universities/Capella/Courses.xml#xmlns(u=http://www.university.example.org/ns)
               xpointer(/u:Courses/u:Course[u:Name='LIT103'])
             </sml:uri>
           </EnrolledCourse>
         </EnrolledCourses>
       </Student>
      </data>
   </document>
   <document>
<!-- One of the courses referenced above -->
     <docInfo>
       <aliases>
         <alias>http://www.university.example.org/Universities/MIT/Courses.xml</alias>
       </aliases>
     </docInfo>
     <data>
       <Courses xmlns="http://www.university.example.org/ns">
         <Course>
           <Name>PHY101</Name>
         </Course>
         <Course>
           <Name>MAT200</Name>
         </Course>
       </Courses>
     </data>
   </document>
 </instances>
</model>

Formal rules about how URI references are processed are defined in section 5.3.3 URI Reference Processing. When not packaged in an SML-IF document, certain URI references (e.g. values of sml:uri elements or certain schemaLocation attributes) are dereferenced to find their corresponding document. When these references are packaged in an SML-IF document, consumers of the SML-IF document need to first examine whether the target document or element is packaged in the same SML-IF document. To determine this, the fragment component, if any, is temporarily ignored to form a URI. This URI is then compared against alias URIs of packaged model documents.

If the URI is equivalent to the URI in an alias (see 5.3.1 URI equivalence), the consumer will not attempt to look for targets of this URI outside of the SML-IF document, although there may exist a document retrievable at this URI. If the original reference has a fragment, the fragment is applied to the referred-to document to establish the reference target(s) according to the corresponding reference scheme definition; otherwise the reference is to the root element of the referred-to document.

If the URI is not equivalent to the URI in any alias, then the SML-IF document does not contain the corresponding target of the original reference. The consumer may or may not attempt to look for targets outside of the SML-IF document, depending on the nature of the reference.

Referring now to the example SML-IF document above. The reference:

http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
xpointer(/u:Courses/u:Course[u:Name='PHY101'])

, after removing the fragment, becomes

http://www.university.example.org/Universities/MIT/Courses.xml

, which is equivalent to the URI listed in the alias accompanying the Courses document. So, by applying the fragment in the reference to the Courses document, we determine that the reference is to the Course element whose Name element has "PHY101" as its content.

The fragment-free part of the reference:

http://www.university.example.org/Universities/Capella/Courses.xml#xmlns(u=http://www.university.example.org/ns)
xpointer(/u:Courses/u:Course[u:Name='LIT103'])

is

http://www.university.example.org/Universities/Capella/Courses.xml

which is not equivalent to the URI in any alias. This means that it is an unresolved SML reference.

The URI:

http://www.university.example.org/university/enrollmodel.xsd 

(value of the schemaLocation attribute on the include element) is not equivalent to any alias. The consumer may or may not attempt to locate a schema document using this URI reference.

4.3 Rule Document Bindings

[SML 1.1] uses Schematron patterns embedded in SML schemas and in separate explicitly bound rule documents to express constraints that cannot be expressed in XML Schemas. Schematron patterns embedded in SML Schema documents all have well defined targets. [SML 1.1] permits models in which rule documents apply to all, none, or subsets of the model's documents. SML-IF uses the list of ruleBinding elements contained in the optional ruleBindings element to associate rule documents with the documents in the interchange set to which they apply. Each ruleBinding associates the documents having an alias beginning with the URI prefix given in the documentAlias with the rule documents having an alias beginning with the prefix given in the ruleAlias. So, for example, the ruleBinding:

<ruleBinding/>
 <documentAlias="http://www.university.example.org/sml/infrastructure/"/>
 <ruleAlias="http://www.university.example.org/sml/infrastructurerules/"/>
</ruleBinding/>

Would associate documents that have the aliases such as:

http://www.university.example.org/sml/infrastructure/server427.xml

and

http://www.university.example.org/sml/infrastructure/switch6E.xml

with rule documents that have aliases such as:

http://www.university.example.org/sml/infrastructurerules/assetistracked.sch

and

http://www.university.example.org/sml/infrastructurerules/managedbycorporate.sch

SML-IF specifies rule bindings among documents in the interchange set. It does not specify rule bindings that apply to documents not in the interchange set. That said, it is often the case that the intent of transferring an SML-IF document is to relate its contents with other SML documents not in the interchange set. For example, the intent might be to merge the interchange set with an existing SML model. In such cases the context of use may choose to extend the definition of ruleBinding to bind documents not in the interchange set. For example, if the interchange set is merged into an existing model, the merge process might choose to extend the definition of ruleBinding elements to bind rule documents in the interchange set to documents in the merged model that weren't included in the interchange set.

4.4 Schema Document Bindings

Schema documents can be connected with other schema documents using composition features provided by XML Schema. This includes xs:include, xs:redefine, and xs:import. A schema document's validity may depend on other schema documents it includes/redefines/imports, or even other schema documents that include/redefine/import it. In performing SML model validation over the SML model packaged in an SML-IF instance, associations between XML Schema definition documents and instance documents need to be drawn, both to completely validate XML Schema documents themselves and to establish the schema-validity of the instance documents.

The XML Schema 1.0 specification provides more flexibility in constructing the schema used for assessment than is appropriate for the semantics defined by SML and SML-IF validation.

  1. It allows processor latitude in terms of locating schema documents (resolving namespace and schema location attributes) and composing schema documents together to form a single schema.

  2. Schema location attributes can be ignored in some cases (xsi:schemaLocation in instance documents and schemaLocation attribute on xs:import) and allowed to "fail to resolve" in others (schemaLocation attribute on xs:include and xs:import).

  3. Multiple imports of the same namespace allow all but the first one to be ignored.

So it is clear that SML-IF cannot guarantee general case interoperability based only on XML Schema given the constraints above and, therefore, needs to specify how to determine such associations. This proposal concerns only SML model validation and not SML-IF validation (against the IF schema). Unless otherwise indicated, "validation" or "validity" in the following sections refers to SML model validation.

An SML-IF document can be:

  1. Schema-complete - All schema documents are included in the SML-IF document, either as an 5.2.1 Embedded Documents or as 5.2.2 Referenced Documents.

  2. Schema-incomplete - A required schema is not included in the SML-IF document, either as an embedded document or a referenced document.

It is necessary for an SML-IF producer to declaratively distinguish between these two cases and that is not always possible based on the content alone. SML-IF uses the schemaComplete attribute on the definitions element to indicate whether this SML-IF document includes all necessary schema definition documents. When this attribute is specified with a value of "true", then the schema validity of the schema definition documents and instance documents depend only on built-in components or components from definition documents included in the SML-IF document. Built-in components include:

  1. 4 xsi: attributes (defined by XML Schema)

  2. all schema built-in types (xs:anyType and simple types defined in XML Schema Part 2)

  3. sml:ref attribute declaration

  4. sml:uri element declaration

An SML model represented by a schema-incomplete SML-IF document is not necessarily invalid. However, SML-IF cannot guarantee interoperability for a schema-incomplete SML-IF document.

SML-IF uses a list of schemaBinding elements contained in the optional schemaBindings element to associate a namespace with a set of schema documents in the interchange set and the instance documents that should be validated against this set of schema documents. Each namespaceBinding child of a schemaBinding element associates the namespace specified in its namespace attribute with the schema documents whose aliases are specified in its aliases attribute. In addition, the instance documents that are to be assessed against this set of schemas are specified in the documentAlias child element of the same schemaBinding element.

The following example illustrates schema bindings.

    <schemaBindings>
      <!-- Each "schemaBinding" element corresponds to a schema and model
           instance documents that are assessed against this schema -->
      <schemaBinding>
        <!-- all "namespaceBinding" children together build the schema -->
        <namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/>
        <namespaceBinding namespace="ns2" aliases="xsd2-v1"/>
        <!-- list all applicable instances; same as for rule bindings -->
        <documentAlias>doc1</documentAlias>
        <documentAlias>doc2-v1-a</documentAlias>
        <documentAlias>doc2-v1-b</documentAlias>
      </schemaBinding>
      <schemaBinding>
        <namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/>
        <namespaceBinding namespace="ns2" aliases="xsd2-v2"/>
        <documentAlias>doc1</documentAlias>
        <documentAlias>doc2-v2</documentAlias>
      </schemaBinding>
    </schemaBindings>
    <definitions schemaComplete="true">
      <!-- schema documents for xsd1-a, xsd1-b, xsd2-v1, xsd2-v2 -->
    </definitions>

There are cases where many instance documents use the same schema. In this case, it is desirable to have a default schema binding rather than specifying a schemaBinding that lists all these instance documents. The defaultSchema can be used cover to instance documents that are not included in any otherschemaBinding as in the following example.

    <schemaBindings>
      <!-- The "defaultSchema" element corresponds to a schema that governs
           all instance documents *not* included in any "schemaBinding". -->
      <defaultSchema>
        <!-- all "namespaceBinding" children together build the schema -->
        <namespaceBinding namespace="ns1" aliases="ns1.xsd"/>
        <namespaceBinding namespace="ns2" aliases="ns2.xsd"/>
      </defaultSchema>
    </schemaBindings>

5. SML Interchange Format Definition

This section normatively defines the Service Modeling Language Interchange Format (SML-IF). It defines the requirements that SML-IF documents must adhere to and how URI references contained in them are to be interpreted by consumers of SML-IF documents.

5.1 Conformance Criteria

SML-IF defines two levels of conformance for SML-IF Documents:

  1. A level 2 conforming SML-IF Document MUST adhere to all requirements in this specification as described in the normative sections. In particular, all non-null SML references in the document MUST contain a URI scheme representation [SML 1.1].

  2. A level 1 conforming SML-IF Document MUST adhere to all requirements in this specification as described in the normative sections with the exception that a URI scheme representation [SML 1.1] is not required for SML references. An SML-IF Document that contains at least one non-null SML reference which has no URI scheme representation but satisfies all other SML-IF requirements is a level 1 conforming SML-IF Document.

A conforming SML-IF Producer MUST be able to generate a level 2 conforming SML-IF Document from an SML model.

A conforming SML-IF Consumer MUST process a conforming SML-IF Document using, in whole or part, semantics defined by this specification. It is OPTIONAL that a conforming SML-IF Consumer process all elements defined in this specification, but any element that is processed MUST be processed in a manner that is consistent with the semantics defined here.

5.2 SML-IF Documents

The purpose of SML-IF is to package the set of documents that constitute an SML model into a standard format so that it can be exchanged in a standard way.

An SML-IF document MUST conform to XML [XML] specification.

An SML-IF document MUST be valid under the XML Schema given in Appendix A.

An SML-IF document MAY form a valid SML model but it is not required to do so. Various uses of SML-IF may define requirements with respect to model validity and the interchange set, but this specification does not.

Each document in the interchange set MUST be represented in the SML-IF document by a separate document element as follows:

  1. Each definition document in the interchange set MUST appear as a descendant of a model/definitions/document element. The order of the document children is not significant.

  2. Each instance document in the interchange set MUST appear as a descendant of a model/instances/document element. The order of the document children is not significant.

Each document in the interchange set MUST be included in the SML-IF document either as an embedded document (where the document to be included is embedded in the SML-IF document) or by including a reference to the document.

5.2.1 Embedded Documents

Documents that are to be embedded in the SML-IF document MUST be embedded as text or in an encoded format as follows:

  1. If the document is embedded as text, it MUST be included as the content of a model/definitions/document/data element if it is a definition document or a model/instances/document/data element if it is an instance document. There MUST be at most one document embedded in each model/*/document/data element.

  2. If the document is embedded in an encoded format, then the octet stream representing the document MUST be encoded in base64 format. The resultant data stream MUST be embedded as the content of a model/definitions/document/base64Data element if it is a definition document or a model/instances/document/base64Data element if it is an instance document. There MUST be at most one document embedded in each model/*/document/base64Data element. Documents that contain a DTD MUST be embedded in this encoded format.

When extracting an embedded document that is contained in a base64Data element, an SML-IF consumer MUST decode the content of the base64Data element first and then process the resulting document as an embedded instance document. All embedded instance documents not encoded in base64 MUST be processed as if they contained the same DTD as the one specified on the model element. If model/*/document/data contains no child element or model/*/document/base64Data has empty content then the SML-IF consumer MUST treat the document as if it is not part of the interchange set.

5.2.2 Referenced Documents

Documents that are to be referenced rather than embedded MUST be included as follows:

  1. If the document is a definition document, the location of the document MUST be included as the content of a model/definitions/document/locator element.

  2. If the document is an instance document, the location of the document MUST be included as the content of a model/instances/document/locator element.

SML-IF specifies one way that MAY be used to provide the location of the referenced document, the documentURI element.

An SML-IF consumer MAY choose to locate a referenced document. If an SML-IF consumer chooses not to locate a referenced document or if it attempts to locate the referenced document and this attempt fails, then the SML-IF consumer MUST treat the referenced document as if it is not part of the interchange set. If either of these conditions occurs, the SML-IF consumer SHOULD make its invoker aware of this condition.

5.3 URI References

5.3.1 URI equivalence

SML-IF uses URI equivalence extensively to handle references among documents in the interchange set. To determine whether two URIs are equivalent, consumers MUST perform case sensitive codepoint-by-codepoint comparison of the corresponding characters in the URI references.

5.3.2 Document aliases

In addition to containing or referring to one of the documents in the interchange set, each document element may (indirectly) contain a list of alias elements. Each alias contains a URI. The set of alias URIs for a given document constitutes the set of identifiers by which documents in the interchange set may have references to the document in question.

A document element containing no alias elements signals that the document in question has no aliases.

Each member of the set of all alias URIs in an SML-IF document MUST be unique. That is, no two alias URIs in a given SML-IF document may be equivalent.

Alias URIs MUST comply with the “absolute-URI” production as defined in RFC 3986 ([IETF RFC 3986]). This implies that they do not contain fragment components.

All alias URIs in an SML-IF document MUST be unique.

5.3.3 URI Reference Processing

When processing an SML-IF document, there are 3 categories of URI references that may need to be resolved:

  1. schemaLocation attributes on xs:include and xs:redefine in schema documents, when they are model definition documents.

  2. Target-complete URIs [SML 1.1] used in SML reference schemes. For a URI reference to be in this category, its non-fragment URI components have all the information to uniquely identify at most one model document that potentially contains the target(s) of the URI reference.

  3. URI references used in SML reference schemes which are not in category #2.

It is clear which references fall into category #1. An example of category #2 is URI references used in SML references that use the SML URI reference scheme. When new references schemes that use URI references are defined, whether they fall into category #2 or #3 will be clear from the reference scheme definitions. Resolution of URI references in category #3 is defined in their respective scheme definitions. It is also possible to have reference schemes that do not use URI references. Again, their resolution is governed by their scheme definitions and is not covered by this section.

To process a URI reference UR that is within categories #1 or #2 above, the following steps are performed:

  1. Determine the document D that possibly contains the target:

    1. If UR contains only a fragment component, then D is the model document that contains UR.

    2. Otherwise

      1. If UR has a fragment component, then let UR' be the URI referenced formed by removing the fragment component; otherwise let UR' be UR.

      2. If UR' is a relative reference, then let B be the [base URI] ([XML Information Set]) property of the element information item containing UR, and transform UR' to form an (absolute) URI U, using B as the base URI, as defined in section “5 Reference Resolution” of RFC 3986 ([IETF RFC 3986]); otherwise let U be UR'.

      3. If there exists a model document with an alias URI that is equivalent to U (5.3.1 URI equivalence), then D is that document; otherwise D has no value.

  2. If D has no value, then

    1. If UR is within category #1 (schemaLocation), then the SML-IF document does not contain the target schema document. (Whether the consumer continues to dereference UR or U is governed by other sections of this specification.)

    2. Otherwise (R is within category #2, used in an SML reference) UR has no target.

  3. If D is a schema document that is also a model definition document in the interchange set, then

    1. If UR is within category #1 (schemaLocation), and it does not contain a fragment component, then UR targets the root element of D.

    2. Otherwise (UR contains a fragment component or is within category #2) UR has no target.

  4. If D is a model instance document in the interchange set, then

    1. If UR is within category #1 (schemaLocation), then it has no target.

    2. If UR does not contain a fragment component, then it targets the root element of D.

    3. Otherwise (UR is within category #2 and contains a fragment component) the fragment component of UR is applied to the root element of D, which may result in 0, 1, or many target elements.

  5. Otherwise (D is another kind of document in the interchange set) UR has no target.

5.4 Rule Document Bindings

5.4.1 URI prefix matching

To associate SML rule documents with the subset of documents in the model to which they apply, SML-IF uses a combination of the alias mechanism described above [5.3.2 Document aliases] and URI prefix matching.

Two URIs, one called the prefix, and one called the target participate in URI prefix matching. The target is said to match the prefix if and only if the target, truncated to the length of the prefix, is equivalent to the prefix as defined in section 5.3.1 URI equivalence.

5.4.2 Bindings defined

A rule binding is an association of a set of one or more rule documents with a set of zero or more model documents. The documents associated with a given rule document are said to be "bound" to it. For a model to be valid, every document in the model must conform to the constraints defined by every rule document it is bound to. It is permissible for a rule document to have no bindings associated with it, and for a model document to be bound to zero rule documents.

The ruleBinding element is used in SML-IF to express rule bindings. In any given binding the set of rule documents is that subset of rule documents in the interchange set with an alias that matches the URI prefix given by the content of the ruleAlias element. The set of model documents in the binding is that subset of the documents in the interchange set with an alias that matches the URI prefix given by the content of the documentAlias element. If the documentAlias element is omitted in a ruleBinding, the set of model documents in the binding is all documents in the interchange set.

Although SML-IF itself does not do so, various uses of SML-IF MAY choose to extend the sets of documents involved in bindings to include documents not contained in the interchange set. For example, if an SML-IF document is used to represent a model fragment that is intended to be merged with some other model, it is entirely possible that some or all of the bindings may involve not just the documents in the interchange set, but documents in the other model.

5.5 Schema Document Bindings

SML-IF consumers MAY choose to ignore the schemaBindings element when present in the SML-IF document, in which case the consumer SHOULD make its invoker aware of this situation. The remainder of this section applies to SML-IF consumers who choose to process the schemaBindings element.

For every schema binding SB in the model, i.e. every /model/schemaBindings/schemaBinding element, SML-IF consumers MUST perform the following steps for instance document validation.

  1. Compose a schema using all documents specified under all SB's namespaceBinding children.

  2. Whenever an import for a namespace N is encountered, perform the following steps.

    1. If there is a namespaceBinding child of SB whose namespace attribute matches N, then components from schema documents listed in the corresponding aliases attribute are used. As with rule bindings, URI prefixing [5.4.1 URI prefix matching] is used for matching schema document aliases. At most one namespaceBinding is allowed per namespace N within a given SB. If more than one namespace binding exists for the namespace as part of a single schema binding, the SML-IF document is in error. If the set of aliases for namespace N is empty, the namespace has no schema documents defining it in the schema binding.

    2. Otherwise, if there are schema documents in the SML-IF document whose targetNamespace is N, then components from all those schema documents are used.

    3. Otherwise, if this is a schema-complete SML-IF document (/model/definitions/@schemaComplete = "true"), then no component from N (other than built-ins) is included in the schema being composed.

    4. Otherwise, it is implementation-defined whether an SML-IF consumer tries to retrieve components for N from outside the SML-IF document.

  3. Whenever an include or redefine is encountered, the schemaLocation is used to match aliases of schema documents, as with base SML-IF.

    1. If there is a schema document in the SML-IF document matching that alias, then that document is used.

    2. Otherwise, if this is a schema-complete SML-IF document, then the include or redefine is unresolved (which is allowed by XML Schema validity assessment rules).

    3. Otherwise, it is implementation-defined whether an SML-IF consumer tries to resolve include or redefine to schema documents outside the SML-IF document.

  4. The instance documents that are referenced in the documentAlias element of SB MUST be validated against the schema constructed in steps 1 through 3. sml:target* and SML identity constraints can now be checked. Similar to documentAlias under ruleBinding elements [5.4 Rule Document Bindings], each documentAlias can refer to multiple documents via URI prefixing.

If defaultSchema is present, then an SML-IF consumer MUST compose a default schema from this element following rules 1 to 3 above. Otherwise, an SML-IF consumers MUST compose a default schema using *all* schema documents included in the SML-IF document. An SML-IF consumer MUST use this default schema to validate those SML instance documents that are not included in any schemaBinding.

The common use case where match-all namespace matching is desired can be achieved by omitting schemaBindings without introducing any additional complexity into the SML-IF document.

6. References

6.1 Normative

[SML 1.1]
Service Modeling Language, Version 1.1, Bhalchandra Pandit, Valentina Popescu, Virginia Smith, Editors. World Wide Web Consortium, 14 January 2008. This version of the Service Modeling Language specification is available at http://www.w3.org/TR/2008/WD-sml-20080114/. The latest version of Service Modeling Language, Version 1.1 is available at http://www.w3.org/TR/sml
[XML Schema Structures]
XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The latest version of XML Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The latest version of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2.
[XML]
Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 16 August 2006. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2006/REC-xml-20060816. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml.
[XML Information Set]
XML Information Set, John Cowan and Richard Tobin, Editors. World Wide Web Consortium, 4 February 2004. This version of the XML Infoset Recommendation is http://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The latest version of the XML Infoset is available at http://www.w3.org/TR/xml-infoset/.
[IETF RFC 3986]
Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter Authors. Internet Engineering Task Force, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt.
[IETF RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt.

6.2 Non-Normative

[ISO/IEC 19757-3]
Information technology ― Document Schema Definition Languages (DSDL) ― Part 3: Rule-based validation ― Schematron. International Organization for Standardization and International Electrotechnical Commission, 1 January 2006. Available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip
[Canonical XML]
Canonical XML, J. Boyer, Author. World Wide Web Consortium, 15 March 2001. This version of the Canonical XML Recommendation is http://www.w3.org/TR/2001/REC-xml-c14n-20010315. The latest version of Canonical XML is available at http://www.w3.org/TR/xml-c14n.
[XML-Signature]
XML-Signature Syntax and Processing, D. Eastlake, J. Reagle, and D. Solo, Editors. Internet Engineering Task Force & World Wide Web Consortium, 12 February 2002. This version of the XML-Signature Syntax and Processing Recommendation is http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/. The latest version of XML-Signature Syntax and Processing is available at http://www.w3.org/TR/xmldsig-core/.
[WS-Addressing Core]
Web Services Addressing 1.0 - Core, M. Gudgin, M. Hadley, and T. Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the WS-Addressing Core Recommendation is http://www.w3.org/TR/2006/REC-ws-addr-core-20060509. The latest version of WS-Addressing Core is available at http://www.w3.org/TR/ws-addr-core.
[WSDL 2.0 Core Language]
Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, Editors. World Wide Web Consortium, 23 May 2007. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" Specification is available is available at http://www.w3.org/TR/2007/PR-wsdl20-20070523. The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" is available at http://www.w3.org/TR/wsdl20.
[XLink]
XML Linking Language (XLink) Version 1.0, Steve DeRose, Eve Maler, David Orchard, Editors. World Wide Web Consortium, 27 June 2001. This version of the XLink Recommendation is http://www.w3.org/TR/2001/REC-xlink-20010627/ The latest version of XLink is available at http://www.w3.org/TR/xlink/.

A. SML-IF Schema

<?xml version="1.0" encoding="utf-8"?>

<!--
/*
 * Copyright © 2008 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:smlif="http://www.w3.org/2008/01/sml-if" xmlns:ns1="http://www.w3.org/2008/01/sml-if" targetNamespace="http://www.w3.org/2008/01/sml-if" elementFormDefault="qualified" blockDefault="#all" version="1.0" xml:lang="EN" finalDefault="" attributeFormDefault="unqualified">
  <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
  <xs:element name="model" type="smlif:modelType"/>
  <xs:complexType name="modelType" mixed="false">
    <xs:sequence>
      <xs:element name="identity" type="smlif:identityType"/>
      <xs:element ref="smlif:ruleBindings" minOccurs="0"/>
      <xs:element ref="smlif:schemaBindings" minOccurs="0"/>
      <xs:element name="definitions" type="smlif:documentCollectionType" minOccurs="0"/>
      <xs:element name="instances" type="smlif:documentCollectionType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  
   <!-- If there is a need for localized string values, e.g. in displayName
       or description, the smlerr:localizationid global attribute can be
       used -->
   
  <xs:complexType name="identityType" mixed="false">
    <xs:sequence>
      <xs:element name="name" type="smlif:uriType"/>
      <xs:element name="version" type="smlif:tokenType" minOccurs="0"/>
      <xs:element name="displayName" type="smlif:displayType" minOccurs="0"/>
      <xs:element name="description" type="smlif:displayType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:complexType name="displayType" mixed="false">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="tokenType" mixed="false">
    <xs:simpleContent>
      <xs:extension base="xs:token">
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="uriType" mixed="false">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:element name="ruleBindings" type="smlif:ruleBindingCollectionType"/>
  <xs:complexType name="ruleBindingCollectionType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:ruleBinding" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="ruleBinding" type="smlif:ruleBindingType"/>
  <xs:complexType name="ruleBindingType" mixed="false">
    <xs:sequence>
      <xs:element name="documentAlias" type="smlif:uriType" minOccurs="0"/>
      <xs:element name="ruleAlias" type="smlif:uriType"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="schemaBindings" type="smlif:schemaBindingCollectionType"/>
  <xs:complexType name="schemaBindingCollectionType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:defaultSchema" minOccurs="0"/>
      <xs:element ref="smlif:schemaBinding" minOccurs="0" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="schemaBinding" type="smlif:schemaBindingType"/>
  <xs:complexType name="schemaBindingType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:namespaceBinding"/>
      <xs:element name="documentAlias" type="smlif:uriType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="namespaceBinding" type="smlif:namespaceBindingType"/>
  <xs:complexType name="namespaceBindingType" mixed="false">
    <xs:attribute name="namespace" type="xs:NCName" use="optional"/>
    <xs:attribute name="aliases" use="required">
      <xs:simpleType>
        <xs:list itemType="xs:anyURI"/>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>
  <xs:element name="defaultSchema" type="smlif:defaultSchemaType"/>
  <xs:complexType name="defaultSchemaType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:namespaceBinding" minOccurs="0" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:complexType name="documentCollectionType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:document" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="schemaComplete" type="xs:boolean"/>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="document" type="smlif:documentType"/>
  <xs:complexType name="documentType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:docinfo" minOccurs="0"/>
      <xs:choice>
        <xs:element name="data" type="smlif:dataType"/>
        <xs:element name="base64Data" type="smlif:base64DataType"/>
        <xs:element name="locator" type="smlif:locatorType"/>
      </xs:choice>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="docinfo" type="smlif:docinfoType"/>
  <xs:complexType name="docinfoType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:aliases" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:element name="aliases" type="smlif:aliasCollectionType"/>
  <xs:complexType name="aliasCollectionType" mixed="false">
    <xs:sequence>
      <xs:element name="alias" type="smlif:uriType" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:complexType name="dataType" mixed="false">
    <xs:annotation>
      <xs:documentation>
The wildcard with processContents "skip" matches the root element of the  
model document being packaged. The value of processContents is set to "skip" so
that the contained element is not processed for schema validation. As a result,
validity of the packaged document will not affect validity of the IF document
itself.
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:any processContents="skip" minOccurs="0" namespace="##any" maxOccurs="1"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <xs:complexType name="base64DataType" mixed="false">
    <xs:simpleContent>
      <xs:extension base="xs:base64Binary">
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="locatorType" mixed="false">
    <xs:sequence>
      <xs:element name="documentURI" type="smlif:uriType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
</xs:schema>

B. Localization of IF Identity Sample (Non-Normative)

The following example shows how the sml:locid attribute can be used to define the translation information for the interchange set identity attributes:

<model 
      xmlns="http://www.w3.org/2008/01/sml-if" version="1.0"
      xmlns:sml="http://www.w3.org/2008/01/sml">
      xmlns:lang="http://www.university.example.org/translation/core">
 <identity>
   <name sml:locid="lang:nameID“>Univerity interchange set</name>
   <description sml:locid="lang:descrID"> This document contains a list of universities.</description>
 </identity>
 </model>

In this example, the {namespace name} URI information of the sml:locid attribute can be used to define the location for the resource containing the translated text. The smlif:name and smlif:description elements are using the same URI to identify the resource containing the translated strings:

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

The {local part} information of the sml:locid attribute can be used to define the id of the text being translated. This information will be used to locate the translation of the name and description texts within the translation resource.