W3CW3C Member Submission

SML Interchange Format Version 1.0

W3C Member Submission 21 March 2007

This version:
http://www.w3.org/submissions/2007/SUBM-sml-if-20070321/
Latest version:
http://www.w3.org/submissions/sml-if/
Authors
John Arwe, IBM
Jordan Boucher, Sun
Pratul Dublish, Microsoft
Zulah Eckert, BEA
Dave Ehnebuske, IBM
Jon Hass, Dell
Steve Jerman, Cisco
Heather Kreger, IBM
Vincent Kowalski, BMC
Milan Milenkovic, Intel
Bryan Murray, HP
Phil Prasek, HP
Junaid Saiyed, EMC
Harm Sluiman, IBM
Bassam Tabbara, Microsoft
Vijay Tewari, Intel
William Vambenepe, HP
Marv Waschke, CA
Andrea Westerinen, Microsoft

Abstract

This specification defines the interchange format for SML models.

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 can be found in the W3C technical reports index at http://www.w3.org/TR/.

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

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

By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

Table of Contents

1. Introduction

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

In every SML model there is a distinguished subset of the documents that comprise it, called the model definition documents. A 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 other documents in the model, called its model instance documents, describe or support the description of the individual resources the model portrays. Broadly speaking, an SML model is a graph of nodes connected to one another by arcs. The nodes are formed by model instance documents; explicit inter-document references form its arcs.

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-defined subset and extensions to XML Schema 1.0 [2, 3]. Rule documents in a model are XML documents that conform to the SML-defined subset and extensions of Schematron [4].

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) that does that.

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

2. Informal Description

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.

Since documents may have been signed using XML Signature [5] or have had cryptographic digests made of them for other purposes, documents exchanged using SML-IF must be invariant with respect to XML Canonicalization. [6]

Explicit inter-document 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 uses such references for many purposes, and permits many different addressing mechanisms. The arcs in SML models are an obvious example. Less obvious are such references as xsi:schemaLocation. The SML-IF specifies a uniform mechanism for unambiguously resolving references among the documents being interchanged.

Binding of rule documents to the documents to which they apply: SML 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.

2.1 Packaging

The SML-IF packages the 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 [11] is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<model xmlns="http://schemas.serviceml.org/smlif/2007/02"
      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/>
   <baseURI>xs:anyURI</baseURI> ?
   <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>
 <definitions> ?
   <document> *
     <docInfo> ?
       <aliases> ?
         <alias> *
           xs:anyURI A URI by which this document may be referred to
         </alias>
       </aliases>
     </docInfo>
    [
     <data>
       xs:any <!—A 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<!—An 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 baseURI element defines the absolute URI that inter-document references using relative URIs are based on.

The optional ruleBindings element is used to contain information that associates Schematron Rule documents with the documents they apply to. See section 2.3 for further details.

The set of SML documents that are interchanged in a 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. 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 components (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 resolve inter-document references are given below.

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 [12], or a Web Services Addressing endpoint reference [9].

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.

2.2 Inter-document References

Explicit inter-document references can appear in SML documents as elements. For example, model arcs are represented by elements marked with the global attribute sml:ref="true". Inter-document references can also appear as attributes. For example, an xsi:schemaLocation attribute provides a hint about where to find a relevant schema document.

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

<?xml version="1.0" encoding="UTF-8"?>
<model xmlns="http://schemas.serviceml.org/smlif/2007/02"
      xmlns:sml=”http://schemas.serviceml.org/sml/2007/02”
      xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” version="1.0">
 <identity>
   <name>http://example.com/sml/models/Sample/InterDocReferences</name>
   <baseURI>http://example.com/sml/models/</baseURI>
 </identity>
 <instances>
   <document>
     <data>
       <Student xmlns="urn:university"
         xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
         xsi:schemaLocation=”urn:university
                             http:example.com/university/enrollmodel.xsd”>
         <ID>1000</ID>
         <Name>John Doe</Name>
         <EnrolledCourses>
           <EnrolledCourse sml:ref=”true”>
             <sml:uri>
               /Universities/MIT/Courses.xml#xmlns(u=urn:university)
               xpointer(/u:Courses/u:Course[u:Name=’PHY101’])
             </sml:uri>
           </EnrolledCourse>
           <EnrolledCourse sml:ref=”true”>
             <sml:uri>
               /Universities/Capella/Courses.xml#xmlns(u=urn:university)
               xpointer(/u:Courses/u:Course[u:Name=’LIT103’])
             </sml:uri>
           </EnrolledCourse>
         </EnrolledCourses>
       </Student>
      </data>
   </document>
   <document>
     <docInfo>
       <aliases>
         <alias>/Universities/MIT/Courses.xml</alias>
       </aliases>
     </docInfo>
     <data>
       <Courses xmlns="urn:university">
         <Course>
           <Name>PHY101</Name>
         </Course>
         <Course>
           <Name>MAT200</Name>
         </Course>
       </Courses>
     </data>
   </document>
 </instances>
</model>

SML-IF uses equivalence of URIs to resolve inter-document references among documents being interchanged. In deciding equivalence of URIs, SML-IF adopts the definition in RFC 3986. [7]. See section 6, “Equivalence,” and section 5 “Reference Resolution” in particular. For the algorithm in section 5, the “base URI” is the one specified in the baseURI in the identity element.

With the exceptions explained in the normative part of this specification, content whose type is anyURI or a type derived from anyURI and is contained in a document in the interchange is considered to be an inter-document reference.

If the URI in such a reference is equivalent to the URI in an alias, the reference is to the document with that alias, irrespective of any document that may be retrievable at this URI. If the reference has a fragment, the fragment is applied to the referred-to document to establish which element the reference points to.

If the element in a reference is not equivalent to the URI in any alias, the reference is to some (element of a) document not included in the interchange set. Such references are called unresolved references.

SML-IF specifies how sets of SML documents are interchanged. If and how an SML-IF document’s interchange set relates to a complete (i.e., “validatible”) model is context dependent and is not a part of this specification. One common relationship is that the interchange set constitutes a complete SML model. In such a case, the documents that unresolved references refer to are simply unavailable to the validation process. When SML-IF documents are used in other contexts, such as when they are the content of Web services requests or responses, the set of documents constituting a complete model may include more or fewer documents than those in the interchange set, and the conventions with respect to unresolved references may be different. For example, the convention may specify how to (attempt to) resolve such references.

The absolute URI form of every alias in an interchange, like all absolute URIs, contains an “authority” component. A reasonable interpretation of SML-IF aliases is that the SML-IF document containing them is asserting that the content marked with a given alias is a true copy of the content identified by that URI and issued by the authority in the alias URI. Since this may or may not be true, consumers need to be cautious with this interpretation.

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

/Universities/MIT/Courses.xml#xmlns(u=urn:university)
xpointer(/u:Courses/u:Course[u:Name=’PHY101’])

is equivalent to the URI listed in the alias accompanying the Courses document. (I.e., “/Universities/MIT/Courses.xml”). 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 reference:

/Universities/Capella/Courses.xml#xmlns(u=urn:university)
xpointer(/u:Courses/u:Course[u:Name=’LIT103’])

is not equivalent to the URI in any alias. This means that it is an unresolved reference. Since the reference is written as a relative reference, URI coming out of the reference resolution algorithm:

http://example.com/Universities/Capella/Courses.xml
 #xmlns(u=urn:university)
  xpointer(/u:Courses/u:Course[u:Name=’LIT103’])

is a hint for where to find the document.

The URI:

http:example.com/university/enrollmodel.xsd 

(in the content of xsi:schemaLocation for the Student document) isn’t equivalent to any alias. Since it is written as an absolute URI, the reference is to the document the URL locates. The same is true for all of the absolute URIs in the documents being interchanged:

urn:university  

and

http://www.w3.org/2001/XMLSchema-instance 

The other URIs in the example SML-IF document are not parts of the SML model being interchanged, so they are not SML inter-document references.

2.3 Rule Document Bindings

SML 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 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://example.com/sml/infrastructure/”/>
 <ruleAlias=“http://example.com/sml/infrastructurerules/”/>
</ruleBinding/>

Would associate documents that have the aliases such as:

http://example.com/sml/infrastructure/server427.xml

and

http://example.com/sml/infrastructure/switch6E.xml

with rule documents that have aliases such as:

http://example.com/sml/infrastructurerules/assetistracked.sch

and

http://example.com/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.

3. SML-IF Normative Definition

This section normatively defines the Service Modeling Language Interchange Format (SML-IF). It is not primarily intended as motivational or introductory material. For such material, please see the non-normative informal description, above. Instead, this section is intended to concisely define the requirements SML-IF documents must adhere to and to define the how inter-document references contained in them are to be interpreted by consumers of SML-IF documents.

3.1 Terminology

A producer is any process that constructs an SML-IF document. A producer creates SML-IF document for the purpose of conveying an SML model to one or more consumers. A consumer is any process that interprets the content of an SML-IF document for the purpose of understanding the model it contains. Using an SML-IF document to achieve the goal of accurately conveying an SML model from producer to consumer is called “interchanging the SML model.”

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 [10].

Producers and consumers of SML-IF documents are required to behave as described; otherwise they are in error.

3.2 The Basics

The purpose of SML-IF is to package the set of documents representing an SML model to be interchanged into a single XML document in a standard way. The set of documents to be interchanged is called the SML-IF document’s interchange set. The documents in the interchange set constitute the SML model being interchanged.

As defined by SML [1], model validity is with respect to some identifiable set of documents. That is, every specific collection of documents either forms a valid model or it does not. But SML-IF is about the interchange of models, not about their validation. Specifically, there is no requirement that the interchange set form a valid SML model. Various uses of SML-IF may well define requirements with respect to model validity and the interchange set, but SML-IF itself does not.

An SML-IF document must conform to XML 1.0 (Second Edition) [8] and must be encoded either in UTF-8 or in UTF-16. Additionally, it must be valid under the XML Schema given in Appendix A, below.

Each document in the interchange set is represented in SML-IF as the content of a separate document element. There are two ways to do this. The octet stream representing the document to be included may be physically embedded in the SML-IF document. Alternatively, a reference to the document to be included may be placed in the SML-IF document.

If a document is to be physically embedded in the SML-IF document, the octet stream representing it must first be processed as follows:

  1. The XML declaration and document type declaration (DTD) are removed.
  2. The stream is converted to the encoding of the SML-IF document into which it will be packaged.

Note: If the SML-IF document uses UTF-8 encoding, the octet-stream result of XML Canonicalization [6] is more than sufficient to accomplish this processing.

The resulting octet stream is then embedded as the content of the data child of the corresponding document element in the SML-IF document.

If on the other hand a document is to be referred to, a reference to it is placed in the locator child of the corresponding document element. SML-IF specifies one way such references may be constructed, the documentURI element, however any representation the producer and consumer agree on may be used. An SML-IF consumer processing the URI in a documentURI element may obtain the referred-to document by dereferencing the URI using the default retrieval action for the URI’s scheme. Producers should anticipate this usage. Typical alternative representations include URIs, XLinks [12], and WS Addressing [9] endpoint references. Since documents referred to using the locator mechanism are members of the interchange set, a consumer cannot fully understand the model being interchanged if it cannot obtain the referred-to documents.

Each definition document in the interchange set appears as a child of a document element that is a child of the definitions element of the SML-IF document. The order of the document children is not significant.

Similarly, each model instance document in the interchange set appears as a child of a document element that is a child of the instances element of the SML-IF document. Here too, the order of the document children is not significant.

3.3 Inter-document References

3.3.1 URI equivalence

SML-IF uses URI equivalence extensively to resolve references among documents in the interchange set. To determine whether two URIs are equivalent, consumers must use the definition of URI equivalence given by RFC 3986 [7]. The algorithm given there requires that a “base URI” be established whenever a relative URI is tested for equivalence with another URI. In SML-IF, the base URI is defined to be the absolute URI given in the baseURI child of the identity element. As defined below, the baseURI element will always be present when relative URIs must be tested for equivalence.

3.3.2 Definition of inter-document references in SML-IF

Definition: In the context of SML-IF, an inter-document reference is any content in a document in the interchange set whose type is xs:anyURI or a type derived from xs:anyURI and whose context in the document implies that the URI can (given the right permissions and connectivity) be dereferenced using the default retrieval action for the URI’s scheme.

Note: this definition WILL change to not require PSVI once the schema binding issue is resolved. See issue .

For example, an xsi:schemaLocation attribute is defined to be of type list of xs:anyURI. These come in pairs, one for the namespace name, and one for a hint as to the location of a schema document defining names for that namespace name. This makes the “hint” URIs in xsi:schemaLocation attributes inter-document references in the context of SML-IF.

Similarly, an sml:uri element contained in an element marked with sml:ref="true" is an inter-document reference because its content is of type xs:anyURI and the definition of sml:uri is that the referred-to document can be obtained by dereferencing the URI using the default retrieval action. In contrast, the wsa:address in a Web Services Addressing [9] endpoint reference is not an inter-document reference in the context of an SML-IF document. This is because, although a wsa:address is defined to be of type anyURI, the action needed to dereference the URI is not the default retrieval action for the scheme of the URI. Instead, the action required is defined by protocol binding used to interact with the endpoint.

Consumers must interpret xsi:schemaLocation hints and sml:uri content used as SML reference schemes as inter-document references. Consumers must not interpret wsa:address content as inter-document references.

3.3.3 SML reference schemes that are not SML-IF inter-document references

SML [1] defines two reference schemes, the sml:uri scheme and the EPR scheme. It also permits new schemes to be created without limit. Schemes that do not use URIs or whose use of URIs does not imply that the URIs may be dereferenced for retrieval using the default action (e.g., for the HTTP scheme, the GET method) are not inter-document references in the context of SML-IF. Three consequences flow from this.

First, to successfully interchange documents using such schemes, the sml:ref elements containing them must also contain an sml:ref scheme that is an inter-document reference in the SML-IF context. For example, an sml:ref that contains an EPR scheme reference (which is not an inter-document reference in SML-IF) could also contain an sml:uri scheme reference (which is).

Second, the producer of the SML-IF document and the consumer of must agree on the scheme(s) being used since SML-IF only requires consumers to understand the sml:uri scheme.

Third, when creating a new sml:ref scheme, authors must be explicit about whether the scheme is an SML-IF inter-document reference.

3.3.4 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 make inter-document references to the document in question.

A document element containing no alias elements signals that the document in question has no aliases. (By implication having no alias also signals that there can be no inter-document references to it.)

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.

3.3.5 Presence of the baseURI element

If any inter-document reference in the interchange set is a relative URI or if any alias of any document in the interchange set is a relative URI, the baseURI child of the identity element must be present and must contain an absolute URI.

3.3.6 Resolving inter-document references

If the URI representing an inter-document reference only contains a fragment, the inter-document reference is to the document in which it occurs. Otherwise, if the URI representing an inter-document reference is equivalent to a URI that is an alias of some document in the interchange set, the inter-document reference is to that document. In either case, such a reference is called “a resolved inter-document reference.” If neither of these cases applies, the inter-document reference is to a document not included in the interchange set. Such a reference is called “an unresolved inter-document reference.”

If the URI representing a resolved inter-document reference has no fragment, the reference is to the root element of the referred-to document.

If the URI representing a resolved inter-document reference has a fragment, the reference is to the element obtained by applying the fragment to the referred-to document starting with its root element.

By definition, unresolved inter-document references are references to documents (or to elements in documents) not included in the interchange.

3.4 Rule Document Bindings

3.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 alias mechanism described above 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 at any point in “climbing the ladder” of URI equivalence testing described in RFC-3986, Section 6.1 [7] the target, truncated to the length of the prefix, is equivalent to the prefix.

Given a prefix and a set of URIs, the matching set of the prefix is that subset of the URIs that match the prefix.

3.4.2 Bindings defined

A 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 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 well 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.

Appendix A – [Normative] SML-IF Schema

<?xml version="1.0" encoding="utf-8"?> 
<!-- Copyright (c) 2006-2007 by  BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun.
     All rights reserved. -->

<xs:schema xmlns:smlif="http://schemas.serviceml.org/smlif/2007/02"  
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://schemas.serviceml.org/smlif/2007/02"
           elementFormDefault="qualified"
           blockDefault="#all"
           version="1.0"
           xml:lang="EN">
  <xs:element name="model" type="smlif:modelType"/>
  <xs:complexType name="modelType">
    <xs:sequence>
      <xs:element name="identity" type="smlif:identityType"/>
      <xs:element name="ruleBindings"
                  type="smlif:ruleBindingCollectionType" 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="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </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">
    <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="baseURI" type="smlif:uriType" minOccurs="0"/>
      <xs:element name="description" type="smlif:displayType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="displayType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:anyAttribute namespace="##other" processContents="skip"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="tokenType">
    <xs:simpleContent>
      <xs:extension base="xs:token">
        <xs:anyAttribute namespace="##other" processContents ="skip"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="uriType">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:anyAttribute namespace="##other" processContents ="skip"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="ruleBindingType">
    <xs:sequence>
      <xs:element name="documentAlias" type="smlif:uriType" minOccurs="0"/>
      <xs:element name="ruleAlias" type="smlif:uriType"/>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="ruleBindingCollectionType">
    <xs:sequence>
      <xs:element name="ruleBinding" type="smlif:ruleBindingType"
                                     maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="documentType">
    <xs:sequence>
      <xs:element name="docinfo" type="smlif:docinfoType" minOccurs="0"/>
      <xs:choice>
        <xs:element name="data" type="smlif:dataType"/>
        <xs:element name="locator" type="smlif:locatorType"/>
      </xs:choice>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="documentCollectionType">
    <xs:sequence>
      <xs:element name="document" type="smlif:documentType"
                                  maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="docinfoType">
    <xs:sequence>
      <xs:element name="aliases" type="smlif:aliasCollectionType"
                                 minOccurs="0"/>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="aliasCollectionType">
    <xs:sequence>
      <xs:element name="alias" type="smlif:uriType" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="dataType">
    <xs:sequence>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
  <xs:complexType name="locatorType">
    <xs:sequence>
      <xs:element name="documentURI" type="smlif:uriType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="skip" minOccurs="0"
                                  maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="skip"/>
  </xs:complexType>
</xs:schema> 

Appendix B – Normative References

[1] “Service Modeling Language” Draft Specification Version 1.0, February 2007
<http://www.w3.org/submissions/2007/SUBM-sml-20070321/>

[2] “XML Schema Part 1: Structures Second Edition”
<http://www.w3.org/TR/xmlschema-1/>

[3] “XML Schema Part 2: Datatypes Second Edition”
<http://www.w3.org/TR/xmlschema-2/>

[4] “Information technology -- Document Schema Definition Languages (DSDL) -- Part 3: Rule-based validation -- Schematron” ISO/IEC 19757-3:2006
<http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip>

[5] “XML-Signature Syntax and Processing”
<http://www.w3.org/TR/xmldsig-core/>

[6] “Canonical XML”
<http://www.w3.org/TR/xml-c14n>

[7] “Uniform Resource Identifier (URI): Generic Syntax”
<http://www.ietf.org/rfc/rfc3986.txt>

[8] “Extensible Markup Language (XML) 1.0, Second Edition”
<http://www.w3.org/TR/2000/REC-xml-20001006>

[9] “Web Services Addressing 1.0 - Core”
< http://www.w3.org/TR/ws-addr-core/ >

[10] “Key words for use in RFCs to Indicate Requirement Levels”
<http://www.ietf.org/rfc/rfc2119.txt>

[11] “Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language”
<http://www.w3.org/TR/wsdl20/>

[12] “XML Linking Language (XLink) Version 1.0”
<http://www.w3.org/TR/xlink/>

Appendix C –Issues

  1. Open: Should the spec provide a means to designate zero or more instance documents as “root” documents for the model?
  2. Open: Decide which elements should be changed to global.
  3. Open: Do rule bindings need a name or identifier to enable management by consumers like repositories? Should they be moved to the SML specification? Reference: email to list 2006-11-27 from Dave Ehnebuske.
  4. Open: Do we need a general facility to allow keyword substitutions in translated text, e.g. the localization resources named via smlerr:localizationid?
  5. Open: How to specify that definitional schema documents should be preferentially used over all other sources when validating instances.
  6. Open: XSD currently says processContents=skip for wildcards, should we change to lax?
  7. Open: Do we need to say whether the normative text or XSD takes precedence, should a conflict between them be found?
  8. Open: Should elements other than <model> be made global? If so, which ones.
  9. Open: Remove requirement that anyURI and its derivations be treated as inter-document references; more generally, do not require PSVI to locate references.