<?xml version="1.0" encoding="utf-8"?><!--
/*
 * Copyright © 2009 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
 */
    --><?xml-stylesheet type='text/xsl' href='/2002/xmlspec/xhtml/1.13/xmlspec.xsl'?>
<!DOCTYPE spec
  SYSTEM "xmlspec.dtd"[
<!ATTLIST spec xmlns:xlink CDATA #IMPLIED>
]>
<spec xmlns:xlink="http://www.w3.org/1999/xlink" w3c-doctype="rec">
    <header>
        <title>Service Modeling Language Interchange Format Version 1.1</title>

        <w3c-designation>http://www.w3.org/TR/2009/REC-sml-if-20090512/</w3c-designation>
        <w3c-doctype>W3C Recommendation</w3c-doctype>

        <pubdate>
            <day>12</day>
            <month>May</month>
            <year>2009</year>
        </pubdate>
        <publoc>
            <loc href="http://www.w3.org/TR/2009/REC-sml-if-20090512/">http://www.w3.org/TR/2009/REC-sml-if-20090512/</loc>
        </publoc>
    <altlocs>
      <loc role="xml" href="sml-if.xml" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">XML</loc>
    </altlocs>
    <prevlocs>
            <loc href="http://www.w3.org/TR/2009/PR-sml-if-20090212/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://www.w3.org/TR/2009/PR-sml-if-20090212/</loc>
    </prevlocs>
        <latestloc>
            <loc href="http://www.w3.org/TR/sml-if/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://www.w3.org/TR/sml-if/</loc>
        </latestloc>
    <authlist>
      <author role="editor">
        <name>Bhalchandra Pandit</name>
        <affiliation>Microsoft Corporation</affiliation>
      </author>
      <author role="editor">
        <name>Valentina Popescu</name>
        <affiliation>IBM Corporation</affiliation>
      </author>
      <author role="editor">
        <name>Virginia Smith</name>
        <affiliation>HP</affiliation>
      </author>
    </authlist>
    <errataloc href="http://www.w3.org/2009/05/sml-errata" xlink:type="simple"/>
    <abstract>
      <p>This specification defines the interchange format for
      Service Modeling Language, Version 1.1 (SML) models. This format identifies the
      model being interchanged, distinguishes between model
      definition documents and model instance documents, and defines the binding of
      rule documents with other documents in the interchange model. </p>
    </abstract>
    <status id="status">

      <p>

                <emph>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 <loc href="http://www.w3.org/TR/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">W3C technical reports index</loc> at
      http://www.w3.org/TR/.</emph>

</p>

      <p>This is the 12 May 2009 W3C Recommendation of the Service Modeling Language Interchange Format Version 1.1
specification.  This document has been developed by the <loc href="http://www.w3.org/XML/SML/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">Service Modeling Language
          (SML) Working Group</loc>, which is a part of the <loc href="http://www.w3.org/XML/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">Extensible Markup Language (XML) Activity</loc>.</p>
      <p>Comments on this document are welcome via the Working Group’s
          <loc href="mailto:public-sml@w3.org" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">public mailing list</loc>
          (<loc href="http://lists.w3.org/Archives/Public/public-sml/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">public
archive</loc>).  An <loc href="http://www.w3.org/XML/SML/SMLPRFeatureImplementationReport.html" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">implementation report</loc> is available.</p>
     <p>The design of SML has been widely reviewed and satisfies the Working 
Group's technical requirements.  Only minor editorial changes have 
been made since the <loc href="http://www.w3.org/TR/2009/PR-sml-if-20090212/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">12 February 2009 Proposed Recommendation</loc>.</p>
     <p>This document has been reviewed by W3C Members, by software 
developers, and by other W3C groups and interested parties, and is 
endorsed by the Director as a W3C Recommendation. It is a stable 
document and may be used as reference material or cited from another 
document. W3C's role in making the Recommendation is to draw attention 
to the specification and to promote its widespread deployment. This 
enhances the functionality and interoperability of the Web.</p>
      <p>This document was produced by a group operating under the
          <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">5 February 
          2004 W3C Patent Policy</loc>.
          W3C maintains a <loc href="http://www.w3.org/2004/01/pp-impl/41079/status" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">public list of
          any patent disclosures</loc> 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 <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">Essential Claim(s)</loc>
          must disclose the information in accordance with
          <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
      section 6 of the W3C Patent Policy</loc>.
      </p>
    </status>

    <langusage>

            <language id="en-US">English</language>
        </langusage>
        <revisiondesc>
            <p>Last Modified: $Date: 2009/05/12 08:50:21 $</p>
        </revisiondesc>
    </header>
    <body>
<div1 id="Introduction">
<head>Introduction (Non-Normative)</head>
<p>As defined in the Service Modeling Language, Version 1.1 (SML) Specification [<bibref ref="SML"/>]
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.</p>

<p>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 that the model portrays.</p>

<p>The SML Specification identifies two categories of model definition
documents that participate in SML model validation: Schema documents and
rule documents. Schema documents in a model are XML documents that
conform to the [<bibref ref="SML"/>] defined extensions to 
XML Schema [<bibref ref="XSD1"/>, <bibref ref="XSD2"/>].
Rule documents in a model include XML documents that conform to the 
[<bibref ref="SML"/>] defined extensions of Schematron [<bibref ref="Schematron"/>].</p>

<p>To ensure accurate and convenient interchange of the documents that
make up an SML model, it is useful to
define both an implementation-neutral interchange format that preserves the
content and interrelationships among the documents and a constrained 
form of SML model validation. For this purpose, this specification
defines a standard format called the SML Interchange Format (SML-IF)
and a process called interchange model validation.</p>

<p>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.</p>

</div1>
<div1 id="Notations_and_Terminology">
<head>Notations and Terminology</head>
<div2 id="Notational_Conventions">
<head>Notational Conventions</head>

        <p>
          The keywords "<rfc2119>MUST</rfc2119>", "<rfc2119>MUST
          NOT</rfc2119>", "<rfc2119>REQUIRED</rfc2119>",
          "<rfc2119>SHALL</rfc2119>", "<rfc2119>SHALL
          NOT</rfc2119>", "<rfc2119>SHOULD</rfc2119>",
          "<rfc2119>SHOULD NOT</rfc2119>",
          "<rfc2119>RECOMMENDED</rfc2119>",
          "<rfc2119>MAY</rfc2119>", and
          "<rfc2119>OPTIONAL</rfc2119>" in this document are to be
          interpreted as described in RFC 2119 [<bibref ref="RFC2119"/>].
        </p>
  <p>This specification follows the same conventions for schema components as those used in the
  XML schema specification [<bibref ref="XSD1"/>]. That is, 
  references to properties of schema components are links to the 
  relevant definition, set off with curly braces, 
  for instance {example property}.
  References to properties of information items as defined in [<bibref ref="XMLInfoset"/>] 
  are notated as links to the relevant section thereof, set off with square brackets, 
  for example [children].  
  </p>


<p>
The content of this specification is normative except for sections 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.
All notes are non-normative unless otherwise specified.
</p>

</div2>
<div2 id="Terminology">
<head>Terminology</head>
<p>The following terms are used in this specification. They are listed here in alphabetical order.
This specification also uses terms defined in the [<bibref ref="SML"/>] specification.</p>
  <glist>
    <gitem>
      <label id="alias">Alias</label>
      <def>
    <p>An <term>alias</term> is a temporary name assigned to a model document [<bibref ref="SML"/>]
    within the context of an <termref def="interchange_model">interchange model</termref>.</p>
      </def>
    </gitem>
    <gitem>
      <label id="implementation_defined">Implementation-Defined</label>
      <def>
    <p>An <term>implementation-defined</term> feature or behavior may vary among processors conforming to this specification; 
    the precise behavior is not specified by this specification but <rfc2119>MUST</rfc2119> be specified by the implementor 
    for each particular conforming implementation. 
    </p>
      </def>
    </gitem>
    <gitem>
      <label id="implementation_dependent">Implementation-Dependent</label>
      <def>
    <p>An <term>implementation-dependent</term> feature or behavior may vary among processors conforming to this specification; 
    the precise behavior is not specified by this or any other W3C specification and is not required to be specified 
    by the implementor for any particular implementation. 
    </p>
      </def>
    </gitem>    
    <gitem>
      <label id="interchange_model">Interchange Model</label>
      <def>
    <p>An <term>interchange model</term> is an SML model [<bibref ref="SML"/>]
being interchanged.</p>
      </def>
    </gitem>
    <gitem>
      <label id="interchange_validation">Interchange Model Validation</label>
      <def>
    <p>

<term>Interchange model validation</term> is the process of performing
     SML model validation [<bibref ref="SML"/>] on the interchange model
     while maintaining all 
    assertions  and interrelationships among the documents in the interchange model as
    defined by this specification.</p>
      </def>
    </gitem>    
  <gitem>
    <label id="schema_binding">Schema Binding</label>
    <def>
        <p>A <term>schema binding</term> is an association of a namespace 
        with a set of schema documents in the <termref def="interchange_model">interchange model</termref> and 
        the instance documents [<bibref ref="SML"/>] that should be validated against this 
        set of schema documents. </p>
    </def>
    </gitem>
  <gitem>
    <label id="smlif_consumer">SML-IF Consumer</label>
    <def>
        <p>An <term>SML-IF consumer</term> is a program that processes 
an <termref def="smlif_document">SML-IF Document</termref> using, in
whole or part, semantics defined by this specification.  It may or may not
perform <termref def="interchange_validation">interchange model validation</termref>.</p>
    </def>
    </gitem>
  <gitem>
    <label id="smlif_document">SML-IF Document</label>
    <def>
        <p>An <term>SML-IF document</term> is an XML representation of an 
        <termref def="interchange_model">interchange model</termref>. 
        It includes the model's identity, its documents (by value or by
reference), metadata about its documents, and a syntactic representation of
concepts defined as part of an SML model but lacking an SML-defined sytnax
(e.g. rule bindings).</p>
    </def>
    </gitem>
  <gitem>
    <label id="smlif_producer">SML-IF Producer</label>
    <def>
        <p>An <term>SML-IF producer</term> is a program able to generate 
        an <termref def="smlif_document">SML-IF Document</termref> from an SML model.</p>
    </def>
    </gitem>
 </glist>
</div2>
</div1>
<div1 id="Dependencies">
<head>Dependencies on Other Specifications</head>

<p>Other specifications on which this one depends are listed in [<bibref ref="Normative_References"/>].
</p>
<p>
Conforming implementations of this specification MUST support SML 1.1 [<bibref ref="SML"/>],
XML 1.0 [<bibref ref="XML10"/>] and 
XML Schema 1.0 [<bibref ref="XSD1"/>, <bibref ref="XSD2"/>].
Conforming implementations MAY additionally support later
versions of the XML or XML Schema specifications.</p> 
<note>
                <p>Although <xspecref href="http://www.w3.org/TR/sml/#Dependencies" xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">SML 1.1</xspecref> 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.
</p> 
</note>
</div1>
<div1 id="Informal_Description">
<head>Informal Description (Non-Normative)</head>

<p>To represent an SML model in a standard way for interchange, the following
topics need to be addressed.</p>

<p>
<b>Packaging:</b> The collection of XML documents that make up a
model 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.</p>

<p>

                <b>Explicit references:</b> The documents to be
interchanged may explicitly refer to one another and to documents that
are not packaged with the documents being interchanged. [<bibref ref="SML"/>] SML references 
among SML model instance documents are an obvious example. Less
obvious are such references as certain <code>schemaLocation</code>
attributes in schema documents and <code>xsi:schemaLocation</code> attributes
in instance documents. Section <specref ref="Schema_Bindings"/> defines how <code>schemaLocation</code> is processed in these cases.</p>

<p>
<b>Rule bindings and schema bindings:</b> [<bibref ref="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.</p>

<p>

                <b>Model validation:</b> The process of 
SML model validation defined in [<bibref ref="SML"/>] contains points of variability 
that, left unconstrained, would make it difficult for SML-IF to ensure 
interoperability of independent implementations in any practical way.  
Many of these sources of variability are inherited from other specifications 
that SML uses, e.g. URI comparison RFC 3986 ([<bibref ref="RFC3986"/>]) and the 
source of Schema components ([<bibref ref="XSD1"/>]) used to validate model instance documents.  
SML-IF constrains these points of variability, with the goal of ensuring interoperability 
when specific conditions are met and of increasing the likelihood of 
interoperability in other cases. The enforcement of these additional 
constraints on SML model validation occurs during the process of 
<termref def="interchange_validation">interchange model validation</termref>.
</p>

<div2 id="Packaging">
<head>Packaging</head>

<p>An SML-IF document packages a collection of SML model 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.</p>

<p>Informally, the structure of SML-IF documents, using the
pseudo-schema notation from WSDL 2.0 [<bibref ref="WSDL20"/>] is as
follows:</p>

<eg xml:space="preserve">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;model xmlns="http://www.w3.org/ns/sml-if"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       SMLIFVersion="xs:token Version number of the SML-IF spec used to generate the current document"
       schemaComplete="xs:boolean"&gt;
    &lt;identity&gt;
        &lt;name&gt;
            xs:anyURI Namespace identifying the model
        &lt;/name&gt;
        &lt;version&gt; ?
            xs:token &lt;!-- The version of this model. E.g., 1.2 or 0.3 --&gt;
        &lt;/version&gt;
        &lt;displayName sml:locid="xs:anyURI URI identifying the translation
                                resource for the display name" ?&gt; ?
            xs:string Descriptive name of model intended for display
        &lt;/displayName&gt;
        &lt;baseURI&gt;
            xs:anyURI &lt;!-- Base URI for relative references defined in the interchange model; 
                           must be an absolute reference --&gt;
        &lt;/baseURI&gt; ?
        &lt;description sml:locid="xs:anyURI URI identifying the translation
                                resource for the description" ?&gt; ?
            xs:string Textual description of model for human consumption
        &lt;/description&gt;
    &lt;/identity&gt;
    &lt;ruleBindings&gt; ?
        &lt;ruleBinding&gt; *
            &lt;documentAlias="xs:anyURI"/&gt; ?
            &lt;ruleAlias="xs:anyURI"/&gt;
        &lt;/ruleBinding&gt;
    &lt;/ruleBindings&gt;
    &lt;schemaBindings&gt; ?
        &lt;defaultSchema&gt; ?
            &lt;namespaceBinding/&gt; *  
        &lt;/defaultSchema&gt;
        &lt;schemaBinding&gt; *
            &lt;namespaceBinding/&gt; *  
            &lt;documentAlias/&gt; *     
        &lt;/schemaBinding&gt;
        &lt;noSchemaBinding&gt; ?
            &lt;documentAlias/&gt; *     
        &lt;/noSchemaBinding&gt;
    &lt;/schemaBindings&gt;
    &lt;definitions&gt; ?
        &lt;document&gt; *
            &lt;docInfo&gt; ?
	            &lt;baseURI&gt; ?
	                xs:anyURI &lt;!-- If a document has a baseURI, then this will be used to form the 
	                               base URI for all relative URIs subject to SML URI processing 
	                               contained by that document. --&gt;            
	            &lt;/baseURI&gt;        
	            &lt;aliases&gt; ?
	                &lt;alias&gt; *
	                    xs:anyURI &lt;!-- A URI by which SML references from other documents may refer to this document. --&gt;
	                &lt;/alias&gt;
	            &lt;/aliases&gt;
            &lt;/docInfo&gt;
                [
                &lt;data&gt;
                    xs:any &lt;!-- At most one definition document goes here --&gt;
                &lt;/data&gt;
                |
                &lt;base64Data&gt;
                    xs:any &lt;!-- At most one base64 encoded definition document goes here --&gt;
                &lt;/base64Data&gt;
                |
                &lt;locator&gt;
                    &lt;documentURI/&gt; ?
                        xs:any &lt;!-- A URI or IRI that points to a definition document goes here --&gt;
                &lt;/locator&gt;
                ]
        &lt;/document&gt;
    &lt;/definitions&gt;
    &lt;instances&gt; ?
        &lt;document&gt; *
            &lt;docInfo&gt; ?
                &lt;baseURI&gt; ?
                     xs:anyURI &lt;!-- If a document has a baseURI, then this will be used to form the 
                            base URI for all relative URIs subject to SML URI processing 
                            contained by that document. --&gt;            
                &lt;/baseURI&gt;        
                &lt;aliases&gt; ?
                   &lt;alias&gt; *
                       xs:anyURI &lt;!-- A URI by which SML references from other documents may refer to this document. --&gt;                        
                   &lt;/alias&gt;
                &lt;/aliases&gt;
            &lt;/docInfo&gt;
            [
            &lt;data&gt;
                xs:any&lt;!-- At most one instance document goes here --&gt;
            &lt;/data&gt;
            |
            &lt;base64Data&gt;
                xs:any &lt;!-- At most one base64 encoded instance document goes here --&gt;
            &lt;/base64Data&gt;
            |
            &lt;locator&gt;
                &lt;documentURI/&gt; ?
                    xs:any &lt;!-- A URI or IRI that points to an instance document goes here --&gt;
            &lt;/locator&gt;
            ]
        &lt;/document&gt;
    &lt;/instances&gt;
&lt;/model&gt;
</eg>

<p>A document producer can specify the version of the specification under which
the current document was generated, and with which conformance is claimed,
in the <code>SMLIFVerion</code> attribute.  For example, if this version of SML-IF
is used as the basis of a document, the value of this attribute would be the value "1.1".
</p>
<p>The <code>identity</code> element provides information applications
can use to identify and describe the set of SML documents being
interchanged. The <code>baseURI</code> child element is one way to 
specify a base URI to be used by relative URI references in 
the <termref def="interchange_model">interchange model</termref>.
Another way to specify a base URI is to use the <code>document/docInfo/baseURI</code>
element. [<specref ref="Base_URI"/>] 
</p>

<p>
The <code>SMLIFVersion</code> attribute is defined on the <code>model</code> element and may
be useful when diagnosing failures encountered while processing SML-IF documents. 
For example, if a document asserts conformance with version 1.1 of the SML-IF specification
and a human can see that it is not in fact conformant, then it is likely that the problem 
occurred during the production of the document. If the same document appears to humans 
to be conformant, then the focus of diagnosis might shift toward the 
<termref def="smlif_consumer">SML-IF consumer</termref> 
and its invocation parameters.
</p>

<p>
The <code>schemaComplete</code> attribute is defined on the <code>model</code> 
element and is used to indicate that the schemas constructed from the definition documents in 
the interchange model are complete, in the sense that the validity of the interchanged
SML model is fully determined by these schemas. 
Formally, however, the <code>schemaComplete</code> attribute does not express any assertion 
that the schemas so constructed are in fact complete, or that 
<termref def="interchange_validation">interchange model validation</termref> using 
these schemas will not result in any errors indicating that some components 
are missing from the schemas. The only formal effect of <code>schemaComplete</code> 
attribute with a value of <code>true</code> or <code>1</code> is to specify precisely the schemas 
with which interchange model validation is to be performed.  
</p>

<p>The optional <code>ruleBindings</code> element is used to contain
information that associates rule documents with the
documents they apply to. See <specref ref="Rule_Bindings"/>
for further details.</p>

<p>Every document in the <termref def="interchange_model">interchange model</termref> 
appears as content of a <code>document</code> element
in either the <code>definitions</code> or the <code>instances</code>
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 <code>document/data</code> element. 
Both <code>definitions</code>
and <code>instances</code> are optional. So, for example, if there are
no model definition documents being packaged, the
<code>definitions</code> element must be omitted.</p>

<p>The first child of each <code>document</code> is typically a
<code>docInfo</code> element that contains a <code>baseURI</code> element 
and a list of
<code>alias</code> elements. 
The <code>baseURI</code>
element can be used to specify a base URI for relative references in the document. Defining 
base URIs is specified in <specref ref="Base_URI"/>.
The content of each <code>alias</code> element is a URI with no fragment
component (i.e., one with no "#" in it). Each of the <code>alias</code> elements serves as
a name that other documents can use to refer to this
document. Examples of how aliases are used to handle URI 
references are given in <specref ref="URI_References"/>.</p>

<p>A document in the interchange model 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 child of the
<code>document</code> element. A document can be embedded as-is or 
in a base64 encoded format.
In the former case, a <code>data</code> element is used to contain the actual 
content of the document whereas a <code>base64Data</code> element is used 
for the latter. The base64 format is typically used for, but is not restricted to,
 documents with DTD.
If the document is being referenced rather than embedded, 
a <code>locator</code>
element is used to contain the reference. The content
of a <code>locator</code> can be a <code>documentURI</code> element
defined by SML-IF or anything else understood by the
<termref def="smlif_consumer">SML-IF consumer</termref>. </p>

<p>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.</p>

</div2>

<div2 id="URI_References">
<head>URI References</head>

<p>
When processing the SML model packaged inside an SML-IF document,
certain URI references (as defined in RFC 3986 [<bibref ref="RFC3986"/>]) 
may need to be processed to find their corresponding target. 
For example, in order to assess SML validity of the interchanged model, 
SML references using the SML URI Reference Scheme [<bibref ref="SML"/>] need to be resolved. 
In addition, in order to assemble schemas from multiple schema documents as part 
of the interchange model validity assessment, the schemaLocation attribute 
on an <code>xs:include</code> element needs to be processed 
to locate the schema document.
</p>

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

<eg xml:space="preserve">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;model xmlns="http://www.w3.org/ns/sml-if" version="1.0"&gt;
    &lt;identity&gt;
        &lt;name&gt;http://www.university.example.org/sml/models/Sample/InterDocReferences&lt;/name&gt;
        &lt;baseURI&gt;http://www.university.example.org/Universities/&lt;/baseURI&gt;   
    &lt;/identity&gt;
    &lt;definitions&gt;
        &lt;document&gt;
            &lt;data&gt;
                &lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;
                    &lt;xs:include schemaLocation="http://www.university.example.org/university/enrollmodel.xsd"/&gt;
                &lt;/xs:schema&gt;     
            &lt;/data&gt;      
        &lt;/document&gt;
    &lt;/definitions&gt;
 
    &lt;instances&gt;
        &lt;document&gt;
            &lt;data&gt;
                &lt;Student xmlns="http://www.university.example.org/ns"
                         xmlns:sml="http://www.w3.org/2007/09/sml"
                         xmlns:u="http://www.university.example.org/ns"&gt;
                    &lt;ID&gt;1000&lt;/ID&gt;
                    &lt;Name&gt;John Doe&lt;/Name&gt;
                    &lt;EnrolledCourses&gt;
                        &lt;EnrolledCourse sml:ref="true"&gt;
                            &lt;!-- SML Reference to a course INside the interchange model --&gt;                                     
                            &lt;sml:uri&gt;
                                http://www.university.example.org/Universities/MIT/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='PHY101'])
                            &lt;/sml:uri&gt;
                        &lt;/EnrolledCourse&gt;
                        &lt;EnrolledCourse sml:ref="true"&gt;
                            &lt;!-- SML Reference to a course INside the interchange model --&gt;                        
                            &lt;sml:uri&gt;
                                http://www.university.example.org/Universities/SFU/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='MUSIC205'])
                            &lt;/sml:uri&gt;
                        &lt;/EnrolledCourse&gt;           
                        &lt;EnrolledCourse sml:ref="true"&gt;
                            &lt;!-- SML Reference to a course OUTside the interchange model --&gt;                        
                            &lt;sml:uri&gt;
                                http://www.university.example.org/Universities/Capella/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='LIT103'])
                            &lt;/sml:uri&gt;
                        &lt;/EnrolledCourse&gt;
                    &lt;/EnrolledCourses&gt;
                &lt;/Student&gt;
            &lt;/data&gt;
        &lt;/document&gt;
        &lt;document&gt;
            &lt;!-- The following alias matches the first course referenced above --&gt;
            &lt;docInfo&gt;
                &lt;aliases&gt;
                    &lt;alias&gt;http://www.university.example.org/Universities/MIT/Courses.xml&lt;/alias&gt;
                &lt;/aliases&gt;
            &lt;/docInfo&gt;
            &lt;data&gt;
                &lt;Courses xmlns="http://www.university.example.org/ns"&gt;
                    &lt;Course&gt;
                        &lt;Name&gt;PHY101&lt;/Name&gt;
                    &lt;/Course&gt;
                    &lt;Course&gt;
                        &lt;Name&gt;MAT200&lt;/Name&gt;
                    &lt;/Course&gt;
                &lt;/Courses&gt;
            &lt;/data&gt;
        &lt;/document&gt;
        &lt;document&gt;
            &lt;docInfo&gt;
                &lt;baseURI&gt;SFU/Courses.xml&lt;/baseURI&gt;
	            &lt;!-- The following alias matches the second course referenced above (after
	            being converted to an absolute URI)  --&gt;
                &lt;/aliases&gt;
                    &lt;alias&gt;SFU/Courses.xml&lt;/alias&gt;
                &lt;/aliases&gt;
            &lt;/docInfo&gt;
            &lt;data&gt;
                &lt;Courses xmlns="http://www.university.example.org/ns"&gt;
                    &lt;Course&gt;
                        &lt;Name&gt;ENG106&lt;/Name&gt;
                    &lt;/Course&gt;
                    &lt;Course&gt;
                        &lt;Name&gt;MUSIC205&lt;/Name&gt;
                    &lt;/Course&gt;
                &lt;/Courses&gt;
            &lt;/data&gt;
        &lt;/document&gt;   
    &lt;/instances&gt;
&lt;/model&gt;
</eg>

<p>
When not packaged 
in an SML-IF document, certain URI references (e.g. values of <code>sml:uri</code> 
elements or certain <code>schemaLocation</code> 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 the 
<code>alias</code> URIs of packaged model documents.
</p>

<p>If the URI is equal to the URI in an <code>alias</code> 
element (see <specref ref="URI_equality"/>), the 
<termref def="smlif_consumer">SML-IF consumer</termref> 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 URI is not equal to the URI in any <code>alias</code> 
 element, then the SML-IF document does not contain
the corresponding target of the original URI reference. The consumer 
may or may not attempt to look for targets outside of the SML-IF document,
depending on the nature of the URI reference.
Formal rules about how URI references are processed are defined
in section <specref ref="URI_Processing"/>.</p> 
<p>Several examples 
of resolving references can be seen in the example SML-IF document shown above, 
illustrating the use of both relative 
and absolute alias URI values. 
In the first example, a reference with an absolute URI, the following SML reference, 
must first be separated into its document URI and fragment components:
</p>

<eg xml:space="preserve">http://www.university.example.org/Universities/MIT/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='PHY101'])</eg>

<p>After removing the fragment, the document portion of the reference is:</p>

<eg xml:space="preserve">http://www.university.example.org/Universities/MIT/Courses.xml</eg>

<p>This document URI is equal to the URI listed in an <code>alias</code>
accompanying the <code>Courses</code> document. So, by applying the
fragment in the URI reference to the <code>Courses</code> document, we
determine that the reference is to the <code>Course</code> element
whose <code>Name</code> element has <code>"PHY101"</code> as its content.</p>

<p>
The second example reference, using a relative URI, is processed similarly.  The 
full reference is:
</p>

<eg xml:space="preserve">
http://www.university.example.org/Universities/SFU/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='MUSIC205'])
</eg>
<p>
After removing the fragment, the document portion of the reference is:
</p>
<eg xml:space="preserve">
http://www.university.example.org/Universities/SFU/Courses.xml
</eg>
<p>
This URI is equal to an <code>alias</code> defined on the last instance 
document in the interchange model, after the <code>model/identity/baseURI</code> content is 
applied to the relative URI contained by the document’s <code>alias</code> element. So, 
by applying the fragment in the reference to the <code>Courses</code> document, 
we determine that the reference is to the <code>Course</code> element whose 
<code>Name</code> element has <code>"MUSIC205"</code> as its content.
</p>

<p>The third example, showing an unresolved reference, is processed similarly. The full reference is:</p>

<eg xml:space="preserve">http://www.university.example.org/Universities/Capella/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='LIT103'])
</eg>

<p>After removing the fragment, the document portion of the reference is:</p>
<eg xml:space="preserve">http://www.university.example.org/Universities/Capella/Courses.xml</eg>

<p>This document URI is not equal to the URI in any <code>alias</code> element. 
This means that it is an unresolved SML reference.</p> 

<p>The URI:</p>
<eg xml:space="preserve">http://www.university.example.org/university/enrollmodel.xsd 
</eg>
<p>(value of the <code>schemaLocation</code> attribute 
on the <code>include</code> element) is not equal to any <code>alias</code>.
The <termref def="smlif_consumer">SML-IF consumer</termref>
 may or may not attempt to locate a schema document using this URI reference.
</p>
</div2>
<div2 id="Rule_Bindings">
<head>Rule Bindings</head>

<p>[<bibref ref="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. [<bibref ref="SML"/>] permits models
in which rule documents apply to all, none, or subsets of the model's
documents. SML-IF uses the list of <code>ruleBinding</code> elements
contained in the optional <code>ruleBindings</code> element to
associate rule documents with the documents in the interchange model to
which they apply. Each <code>ruleBinding</code> associates the
documents having an alias beginning with the URI prefix given in the
<code>documentAlias</code> with the rule documents having an alias
beginning with the prefix given in the <code>ruleAlias</code>. So, for
example, the <code>ruleBinding</code>:</p>

<eg xml:space="preserve">
&lt;ruleBinding&gt;
    &lt;documentAlias="http://www.university.example.org/sml/infrastructure/"/&gt;
    &lt;ruleAlias="http://www.university.example.org/sml/infrastructurerules/"/&gt;
&lt;/ruleBinding&gt;
</eg>

<p>Would associate documents that have the aliases such as:</p>

<eg xml:space="preserve">http://www.university.example.org/sml/infrastructure/server427.xml</eg>

<p>and</p>

<eg xml:space="preserve">http://www.university.example.org/sml/infrastructure/switch6E.xml</eg>

<p>with rule documents that have aliases such as:</p>

<eg xml:space="preserve">http://www.university.example.org/sml/infrastructurerules/assetistracked.sch</eg>

<p>and</p>

<eg xml:space="preserve">http://www.university.example.org/sml/infrastructurerules/managedbycorporate.sch</eg>

<p>SML-IF specifies rule bindings among documents in the interchange
model. It does not specify rule bindings that apply to documents not in
the interchange model. 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 model. For example, the
intent might be to merge the interchange model with an existing SML
model. In such cases the context of use may choose to extend the
definition of <code>ruleBinding</code> to bind documents not in the
interchange model. For example, if the interchange model is merged into an
existing model, the merge process might choose to extend the
definition of <code>ruleBinding</code> elements to bind rule documents
in the interchange model to documents in the merged model that weren't
included in the interchange model.</p>

</div2>
<div2 id="Schema_Bindings">
<head>Schema Bindings</head>

<p>
Schema documents can be connected with other schema documents using composition 
features provided by XML Schema.  This includes <code>xs:include</code>, 
<code>xs:redefine</code>, and <code>xs:import</code>.  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.
When performing <termref def="interchange_validation">interchange model validation</termref> 
over the SML model packaged in an SML-IF instance,
 an SML-IF consumer must draw associations between XML Schema
definition documents and
instance documents, both to completely validate XML Schema
documents themselves and to establish the schema-validity of the instance
documents.
</p>
<p>The XML Schema specification provides more flexibility in constructing the schema 
used for assessment than is appropriate for the semantics defined by SML and SML-IF for
<termref def="interchange_validation"> interchange model validation.</termref>
</p>
<olist>
<item>
                        <p>It allows XML Schema processors latitude in terms of locating schema documents 
(resolving namespace and schema location attributes) and composing schema documents 
together to form a single schema.</p>
</item>
<item>
                        <p>Schema location attributes can be ignored in some cases
 (<code>xsi:schemaLocation</code> in instance documents and 
 <code>schemaLocation</code> attribute on <code>xs:import</code>) and 
 allowed to "fail to resolve" in others (<code>schemaLocation</code> 
 attribute on <code>xs:include</code> and <code>xs:import</code>). </p>
</item>
<item>
                        <p>Multiple imports of the same namespace allow all but the first 
one to be ignored.</p>
</item>
</olist>
<p>
As a result, SML-IF cannot guarantee general case interoperability 
based only on XML Schema  and, therefore, needs to 
specify how to determine such associations. This section describes a method to achieve this goal. 
</p>
<p>
An SML-IF document can be:</p>
<olist>
<item>
                        <p>

                            <b>Schema-complete</b> - All schema documents are included in the 
SML-IF document, either as an
<specref ref="Embedded_Documents"/> or as <specref ref="Referenced_Documents"/>.</p>
</item>
<item>
                        <p>
                            <b>Schema-incomplete</b> - Some required schema documents
may not be included in the SML-IF document, either as an embedded
document or a referenced document.</p>

</item>
</olist>
<p>It is necessary for an SML-IF producer to declaratively distinguish 
between these two cases because making that distinction is not always 
possible for an <termref def="smlif_consumer">SML-IF consumer</termref>
based on the content alone. SML-IF uses the <code>schemaComplete</code> 
attribute on the <code>model</code> 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:</p>
<olist>
<item>
                        <p>four xsi: attributes (defined by XML Schema)</p>
</item>
<item>
                        <p>all schema built-in types (xs:anyType and simple types defined 
in XML Schema Part 2)</p>
</item>
<item>
                        <p>sml:ref attribute declaration</p>
</item>
<item>
                        <p>sml:uri element declaration</p>

</item>
</olist>
<p>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.</p>

<p>SML-IF uses a list of <code>schemaBinding</code> elements
contained in the optional <code>schemaBindings</code> element to
associate a namespace with a set of schema documents in the interchange model and 
the instance documents 
that should be validated against this set of schema documents.
 Each <code>namespaceBinding</code> child of a <code>schemaBinding</code> element 
 associates the
namespace specified in its <code>namespace</code> attribute 
with the schema documents whose aliases are specified in its <code>aliases</code> attribute. 
In addition, 
the instance documents that are to be assessed against this set of schemas are specified 
in the <code>documentAlias</code>
child element of the same <code>schemaBinding</code> element.</p>
<p>
The following example illustrates schema bindings.</p>
    
<eg xml:space="preserve">
&lt;schemaBindings&gt;
    &lt;!-- Each "schemaBinding" element corresponds to a schema and model
         instance documents that are assessed against this schema --&gt;
    &lt;schemaBinding&gt;
        &lt;!-- all "namespaceBinding" children together build the schema --&gt;
        &lt;namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/&gt;
        &lt;namespaceBinding namespace="ns2" aliases="xsd2-v1"/&gt;
        &lt;!-- list all applicable instances; same as for rule bindings --&gt;
        &lt;documentAlias&gt;doc1&lt;/documentAlias&gt;
        &lt;documentAlias&gt;doc2-v1-a&lt;/documentAlias&gt;
        &lt;documentAlias&gt;doc2-v1-b&lt;/documentAlias&gt;
    &lt;/schemaBinding&gt;
    &lt;schemaBinding&gt;
        &lt;namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/&gt;
        &lt;namespaceBinding namespace="ns2" aliases="xsd2-v2"/&gt;
        &lt;documentAlias&gt;doc1&lt;/documentAlias&gt;
        &lt;documentAlias&gt;doc2-v2&lt;/documentAlias&gt;
    &lt;/schemaBinding&gt;
&lt;/schemaBindings&gt;
&lt;definitions&gt;
    &lt;!-- schema documents for xsd1-a, xsd1-b, xsd2-v1, xsd2-v2 --&gt;
&lt;/definitions&gt;
</eg>
<p>
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 <code>schemaBinding</code> 
that lists all these instance documents.
The <code>defaultSchema</code> can be used to cover instance documents not included in 
any other<code>schemaBinding</code> as in the following example.</p>

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

<p>
There may be cases where an instance document should not be bound to any schema, including 
the default schema. 
The <code>noSchemaBinding</code> element can be used in this case to cover 
such instance documents as in the following example.</p>
   
<eg xml:space="preserve">
&lt;schemaBindings&gt;
    &lt;!-- The "noSchemaBinding" element contains the aliases for 
         all instance documents *not* bound to any schema. --&gt;
    &lt;noSchemaBinding&gt;
        &lt;documentAlias&gt;doc-a&lt;/documentAlias&gt;
        &lt;documentAlias&gt;doc-b&lt;/documentAlias&gt;
    &lt;/noSchemaBinding&gt;
&lt;/schemaBindings&gt;
</eg>    


</div2>
<div2 id="Interoperability">
<head>Interoperability of SML Models</head>

<p>
The goal of SML-IF is to enable the exchange of SML models. However, this
interoperability goal is affected by several aspects of SML models.
</p>
<olist>
                    <item>

                        <p>Use of the SML URI Reference
Scheme as defined in the SML specification is the only guaranteed way of
achieving interoperability for all SML references in the model. Use of any
other reference scheme requires that the <termref def="smlif_consumer">SML-IF consumer</termref>
 know about its use in the
document and understand how to dereference it.</p>
</item>
<item>
                        <p>SML documents can be included by reference using the <code>locator</code> element and,
therefore, are not directly embedded in the SML-IF document. This can be very
useful, especially when the SML-IF document is large or when the documents are
readily accessible to the consumer. However, the <code>locator</code> element may be ignored
by the consumer, may not resolve, or may resolve to different resources in
different contexts. Because of these uncertainties, interoperability is not
guaranteed when documents are included by reference.</p>
</item>
<item>

                        <p>The SML-IF document may be schema-incomplete [<specref ref="Schema_Bindings"/>]. 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.</p>
</item>
<item>

                        <p>The SML-IF document may use reference schemes that do not use target-complete
identifiers.  In addition to the requirements imposed by SML on reference
scheme definitions, SML-IF imposes additional requirements on references
schemes that do not use target-complete identifiers in order to make them
useful in the context of SML-IF [<specref ref="URI_Processing"/>].
</p>
</item>
<item>

                        <p>The presence of relative references subject to SML-IF URI processing 
introduces the necessity to transform them into absolute references [<specref ref="URI_Processing"/>].
 SML-IF provides two alternative mechanisms [<specref ref="Base_URI"/>] for doing so, 
 one of which is deprecated. 
 SML-IF producers can construct SML-IF documents that use either only absolute URIs 
 or both base URI mechanisms in order to achieve interoperability with the maximum 
 number of consumers.</p>
</item>
</olist>
</div2>
</div1>
<div1 id="SML-IF_Normative_Definition">
<head>SML Interchange Format Definition</head>

<p>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.</p>

<div2 id="ConformanceClause">
<head>Conformance Criteria</head>
<p> 
SML-IF defines two levels of conformance for SML-IF Documents: 
</p>
<olist>
<item>
                        <p>Minimal Conformance: A <emph>minimally conforming SML-IF Document</emph> 
<rfc2119>MUST</rfc2119> adhere to all SML-IF document requirements
 as described in the normative sections of this specification.
</p>
</item>
<item>

                        <p>Reference Conformance: A <emph>referentially conforming SML-IF Document</emph>
 <rfc2119>MUST</rfc2119> adhere to all SML-IF document requirements
 as described in the normative sections of this specification. 
 In addition, each non-null SML reference in the document <rfc2119>MUST</rfc2119> 
be an instance of the SML URI Reference Scheme [<bibref ref="SML"/>].
</p>

</item>
</olist>

<p>A <emph>conforming SML-IF Producer</emph> 
<rfc2119>MUST</rfc2119> be able to generate a referentially conforming SML-IF Document 
from a conforming SML model.</p>

<note>
<p>When a producer generates a referentially conforming SML-IF
document from a conforming source model, it is expected that the
source model and the generated model are equivalent. That is, the
source model and the destination model both have the same validity, same
number of documents with similar structure and content differing only
in places where references are updated to have equivalent SML URI
scheme representation. However, this specification does not normatively 
define the notion of model equivalence.
</p>
</note>

<p>A <emph>conforming SML-IF Consumer</emph> 
<rfc2119>MUST</rfc2119> process a conforming SML-IF Document using, in whole or part, 
semantics defined by this specification. It is <rfc2119>OPTIONAL</rfc2119> 
that a conforming SML-IF Consumer
 process all elements defined in this specification, but
any element that is processed <rfc2119>MUST</rfc2119> be processed 
according to the requirements stated in the normative
sections of this specification. In particular, if a conforming 
SML-IF Consumer performs <termref def="interchange_validation">interchange model validation</termref>, 
then that process <rfc2119>MUST</rfc2119> be performed as described in this specification. 
</p>

</div2>

<div2 id="SML-IF_Documents">
<head>SML-IF Documents</head>

<p>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. 
</p>

<p>An SML-IF document <rfc2119>MUST</rfc2119> be a well-formed XML document [<bibref ref="XML10"/>].</p>

<p>An SML-IF document <rfc2119>MUST</rfc2119> be valid under the XML Schema given in Appendix A.</p>

<p>
The definition and instance documents packaged by an SML-IF document 
<rfc2119>MAY</rfc2119> form a valid SML model 
but it is not required to do so. </p>
<p>Each document in the interchange model <rfc2119>MUST</rfc2119> be represented in the SML-IF document by 
a separate <code>document</code> element as follows: </p>
<olist>
<item>
                        <p>Each definition document  
in the interchange model <rfc2119>MUST</rfc2119> appear as a descendant
of a <code>model/definitions/document</code> element.
The order of the <code>document</code> children is not significant.</p>
</item>

<item>
                        <p>Each instance document in the interchange model
<rfc2119>MUST</rfc2119> appear as a descendant of a <code>model/instances/document</code> 
element. The order of
the <code>document</code> children is not significant.</p>

</item>
</olist>

<p>Each document in the interchange model <rfc2119>MUST</rfc2119> 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.</p>

<div3 id="Embedded_Documents">
<head>Embedded Documents</head>

<p>Documents that are to be embedded in the SML-IF document <rfc2119>MUST</rfc2119> be 
embedded as text or in an encoded format as follows:
</p>
<olist>
<item>
                            <p>If the document is embedded as text, it <rfc2119>MUST</rfc2119> be included as 
the content of a
<code>model/definitions/document/data</code> element if it is a definition document or a 
<code>model/instances/document/data</code> element if it is an instance document. 
Each <code>model/*/document/data</code> element <rfc2119>MUST</rfc2119> contain
at most one document.</p>
</item>
<item>
                            <p>If the document is embedded in an encoded format, then the
 octet stream representing the document <rfc2119>MUST</rfc2119> be 
encoded in base64 format. The resultant data stream <rfc2119>MUST</rfc2119> be embedded as the 
content of a <code>model/definitions/document/base64Data</code> element if it is a 
definition document or a 
<code>model/instances/document/base64Data</code> element if it is an instance document. 
Each <code>model/*/document/base64Data</code> element <rfc2119>MUST</rfc2119> contain
at most one document.
Documents that contain a DTD <rfc2119>MUST</rfc2119> be embedded 
in this encoded format.</p>

</item>
</olist>

<p>When extracting an embedded document that is contained in a <code>base64Data</code> element, 
an SML-IF consumer <rfc2119>MUST</rfc2119> decode the content of the <code>base64Data</code> element
 first and then process the resulting document as an embedded instance document. 
All  embedded instance documents not encoded in base64 <rfc2119>MUST</rfc2119> 
be processed as if they contained the same DTD as the 
one associated with the SML-IF document.</p> 
<p>
If the <code>model/*/document/data</code> element has no child element, then an SML-IF
consumer <rfc2119>MUST</rfc2119> treat the document as if it is not 
part of the interchange model.
If the <code>model/*/document/base64Data</code> element has a zero-length sequence of octets
as its value, then an SML-IF consumer <rfc2119>MUST</rfc2119> treat the document 
as if it is not part of the interchange model.

</p>
</div3>
<div3 id="Referenced_Documents">
<head>Referenced Documents</head>
<p>Documents that are to be referenced rather than embedded <rfc2119>MUST</rfc2119> be included as follows:</p>
<olist>
<item>
                            <p>If the document is a definition document, 
the location of the document <rfc2119>MUST</rfc2119> be included as the content of a 
<code>model/definitions/document/locator</code> element.</p>
</item>
<item>
                            <p>
If the document is an instance document, 
the location of the document <rfc2119>MUST</rfc2119> be included as the content of a 
<code>model/instances/document/locator</code> element.
</p>

</item>
</olist>
<p>SML-IF specifies one way
that <rfc2119>MAY</rfc2119> be used to provide the location of the 
referenced document, the <code>documentURI</code> element.
It is a consequence of <code>documentURI</code> schema definition that it contains a URI
reference, i.e., it may be an absolute URI or relative reference.  When it
is a relative reference, the [base URI] property SHOULD be used to transform it
to an absolute URI, as stated in [<specref ref="Base_URI"/>].
</p>
<p>An SML-IF 
consumer <rfc2119>MAY</rfc2119> 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 
<rfc2119>MUST</rfc2119> treat the referenced document as if it is not part of the 
<termref def="interchange_model">interchange model</termref>.
If either of these conditions occurs, the SML-IF consumer
<rfc2119>SHOULD</rfc2119> make its invoker aware of this condition. </p>
</div3>

<div3 id="Schema_Completeness">
<head>Schema Completeness</head>

<p>
The <code>smlif:schemaComplete</code> attribute is defined on the <code>model</code> element. 
The attribute indicates whether or not all the definition documents required for 
<termref def="interchange_validation">interchange model validation</termref>
 are included in the <termref def="interchange_model">interchange model</termref>. 
</p>
<p>
If <code>schemaComplete</code> has the value <code>true</code> or <code>1</code>,
then schemas used for interchange model validation <rfc2119>MUST</rfc2119>
contain only schema components declared in built-in components or in model definition documents 
within the interchange model. If <code>schemaComplete</code> has the value <code>false</code>
or <code>0</code>, then this specification does not constrain whether or not definition documents 
required for interchange model validation  
are retrieved from outside the interchange model. 
</p>
</div3>

<div3 id="smlif_version">
<head>SML-IF Document Version</head>
<p>
    An SML-IF producer <rfc2119>MAY</rfc2119> specify the version of the
    SML-IF specification with which conformance is declared by including
    the version number of the relevant specification as
    the value of the <code>SMLIFVersion</code> attribute in the document's
    <code>model</code> element. This value <rfc2119>MUST</rfc2119> be <code>"1.1"</code>
    for documents declared by the producer to conform to the SML-IF 1.1 specification.

    SML-IF Consumers <rfc2119>MUST</rfc2119> attempt to process an SML-IF document
    regardless of the value of the <code>SMLIFVersion</code> attribute.
    That is, an SML-IF Consumer <rfc2119>MUST NOT</rfc2119> reject
    the document solely because of the value of the <code>SMLIFVersion</code> attribute.
</p>
<note>
<p>Requiring <termref def="smlif_consumer">SML-IF consumers</termref> to continue processing in the 
    face of unknown version values makes it easier to deploy documents 
    that support future versions of this specification.
</p>
</note>
</div3>

</div2>
<div2 id="URI_References_Definition">
<head>URI References</head>

<div3 id="URI_equality">
<head>URI equality</head>

<p>SML-IF uses URI equality extensively to handle references among
documents in the interchange model. To determine whether two URIs are
equal, <termref def="smlif_consumer">SML-IF consumers</termref> <rfc2119>MUST</rfc2119> perform case sensitive 
codepoint-by-codepoint comparison of the corresponding 
characters in the URI references.
</p>

</div3>

<div3 id="Base_URI">
<head>Base URIs</head>
<p>If a document in the interchange model contains a relative reference 
subject to SML-IF URI processing (see <specref ref="URI_Processing"/>), 
then the base URI used to transform the relative URI reference into an absolute URI 
is the value of its [base URI] property according to the rules in section 4.3 of 
<bibref ref="XMLBase"/>. 
When a base URI is needed to transform a relative reference, then the information 
necessary to calculate the [base URI] property <rfc2119>MUST</rfc2119> be embedded within the 
SML-IF document’s content using at least one of the following mechanisms. </p>
<olist>
<item>

                            <p>The base URI is embedded using the <code>xml:base</code> attribute 
according to <bibref ref="XMLBase"/>. 
The value of an element's [base URI] property is calculated according 
to <bibref ref="XMLBase"/>. </p>
</item>
<item>

                            <p>The base URI is embedded using the <code>smlif:baseURI</code>
 element as described in 
<specref ref="smlif_baseuri"/>. The value of an element's [base URI] property is 
calculated as described in that section.</p>
</item>
</olist>
<note>

                        <p>
Because this specification requires that the base URI information be embedded in the 
document content, it follows that an element’s [base URI] will never be computed from 
the URI of the document entity or external entity (see section 4.2 of 
<bibref ref="XMLBase"/>) containing the element.</p>
</note>

<p>
                        <termref def="smlif_consumer">SML-IF consumers</termref> 
<rfc2119>MUST</rfc2119> support at least one of these mechanisms. 
The selection of which base URI mechanism(s) a consumer’s implementation 
supports is implementation-defined, i.e. it might be done as a fixed coding 
choice, as a run-time parameter, by scanning the content, or through any 
other means.  
<termref def="smlif_producer">SML-IF producers</termref> 
<rfc2119>MUST</rfc2119> support <code>xml:base</code> and 
<rfc2119>MAY</rfc2119> support <code>smlif:baseURI</code>.</p>
<p>If an SML-IF consumer supports both mechanisms and the interchange model document 
it is consuming contains markup for both mechanisms, 
then the SML-IF consumer <rfc2119>MUST</rfc2119> use the [base URI] value 
calculated using the <code>xml:base</code> mechanism.</p>
<p>All of the base URI mechanisms used in each interchange model 
document <rfc2119>MUST</rfc2119> be used consistently.  In other words, all of the 
base URI mechanisms 
whose markup appears in the document <rfc2119>MUST</rfc2119> result in the s
ame [base URI] value 
being calculated for each relative reference subject to SML-IF URI processing.  
SML-IF consumers <rfc2119>MAY</rfc2119> check this consistency.  </p>
<note>
<p>As a consequence of the granularity of the consistency requirement, 
a single SML-IF document may use different mechanisms in distinct 
interchange model documents.  In this scenario, it is true that only consumers that support 
all mechanisms used would be able to process the entire SML-IF document correctly.</p>
<p>Consistency checking of base URI results by SML-IF consumers is made 
optional to avoid requiring the potential overhead of performing twice as many 
calculations per relative reference as is minimally required to consume the model.  
An SML-IF consumer might choose to check base URI mechanism consistency 
based on input parameters, always, never, or based on any other criteria it chooses. 
If both base URI mechanisms are used in a given interchange model document 
contained within a conforming SML-IF document, and a consumer understands both mechanisms, 
such a consumer must use the xml:base mechanism to compute the [base URI] property. 
This consumer may choose to ignore the smlif:baseURI information or 
it may choose to verify that consistent results are obtained from both mechanisms. 
If both base URI mechanisms are used in a given interchange model document contained 
within a non-conforming SML-IF document, SML-IF provides no guarantees about the 
consistency of any [base URI] property computed using both mechanisms.</p>

<p>SML-IF producers have several combinations to consider when defining base URIs in an 
SML-IF document:</p>

<olist>
<item>
<p>When the interchange model contains no relative URI references subject 
to SML-IF URI processing, neither <code>xml:base</code> nor 
<code>smlif:baseURI</code> is necessary.</p>
</item>
<item>
<p>When relative URI references subject to SML-IF URI processing 
exist in the interchange model and all require the same base URI value, 
providing an <code>xml:base</code> or <code>smlif:baseURI</code>
 value for the model element is sufficient.</p>
</item>
<item>
<p>When relative URI references subject to SML-IF URI processing exist in the 
interchange model and they require different base URI values, 
a combination of  <code>xml:base</code> values or a combination of <code>smlif:baseURI</code> values 
can be used to ensure each document has the correct base URI.</p>
</item>
<item>
                                <p>When relative URI references subject to SML-IF URI processing exist 
within the same SML model document and they require different base URI values, 
<code>xml:base</code> can be used within the document to ensure that each relative URI has 
the correct base URI.</p>
</item>
</olist>
</note>

<div4 id="smlif_baseuri">
<head>smlif:baseURI</head>
<p>This syntax is supported in this version of the SML-IF specification for compatibility 
with existing SML-IF documents.  
It is, however, deprecated and may be removed in a future version of this specification. </p>
<p>
In the <code>smlif:baseURI</code> mechanism, two base URI values values are used to compute the value 
of an element’s [base URI] property, which is then used to resolve relative URI
references defined in the interchange model that are subject to SML-IF URI 
processing (see <specref ref="URI_Processing"/>).

</p>

<glist>
    <gitem>
      <label id="interchange_baseURI">Interchange model base URI</label>
      <def>
	    <p>A URI reference that complies with the “absolute-URI” production as defined 
	    in RFC 3986 ([<bibref ref="RFC3986"/>]). The value of the <term>interchange model base URI</term>
	    is the content of the <code>/model/identity/baseURI</code> element, if any. 
	     </p>
<note>
                                    <p>This is roughly equivalent to specifying the same value in an <code>xml:base</code> 
attribute on the /model element.</p>
</note>


      </def>
    </gitem>   
    <gitem>
      <label id="document_baseURI">Document base URI</label>
      <def>
    	<p>A URI reference that complies with the “absolute-URI” production as defined in 
    	RFC 3986 ([<bibref ref="RFC3986"/>]). Each document in the interchange model has a 
    	document base URI whose value is a computed value.</p>
      </def>
    </gitem>    
</glist>

<p>
For each document in the interchange model, 
the value of the <termref def="document_baseURI">document base URI</termref> 
is computed as follows:
</p>

<olist>
<item>
<p>If the document has a <code>docInfo/baseURI</code> element, 
let <term>U</term> be its value.</p>
<olist>
                                    <item>

<p>If <term>U</term> is a relative reference, let <term>B</term> be 
the value of the <termref def="interchange_baseURI">interchange model base URI</termref>. Then
the value of the document base URI
is the result of transforming <term>U</term> into an absolute URI, using <term>B</term> as the base URI.</p>
</item>
<item>
                                    <p>Otherwise the value of the document base URI is <term>U</term>.</p>
</item>
</olist>
</item>
<item>
                                <p>Otherwise if the <termref def="interchange_baseURI">interchange model base URI</termref> has a value, then 
the value of the document base URI is the value of the 
interchange model base URI.</p>
</item>
<item>
                                <p>Otherwise, the document base URI has no value.</p>
</item>
</olist>

<p>
According to the <code>smlif:baseURI</code> mechanism, the [base URI] property of an element 
is calculated as follows:</p>
<olist>
<item>

                                <p>If the element is part of a document in the interchange model 
(i.e. it has as one of its ancestor elements smlif:locator, smlif:data, smlif:base64Data), 
its [base URI] value is the <termref def="document_baseURI">document base URI</termref>.</p>
</item>
<item>

                                <p>Otherwise, its [base URI] value is 
the <termref def="interchange_baseURI">interchange model base URI</termref>.</p>
</item>
</olist>



</div4>
</div3>

<div3 id="Document_aliases">
<head>Document Aliases</head>

<p>
For each document in the <termref def="interchange_model">interchange model</termref>, 
the <code>document</code> element contains a set of zero or more 
<code>alias</code> elements that are used to 
define the <termref def="alias">aliases</termref> of the document.
</p> 
<p>
Conceptually, each document in the interchange model has the following property:
</p>

<glist>
    <gitem>
      <label id="aliases">[aliases]</label>
      <def>
    <p>A set of URI references that comply with the “absolute-URI” 
    production as defined in RFC 3986 ([<bibref ref="RFC3986"/>]).</p>
      </def>
    </gitem>    
</glist>

<p>
The value of the 
content of <termref def="aliases">[aliases]</termref> is computed as follows:
</p>

<olist>
<item>

<p>For each <code>alias</code>
child element under the model document’s <code>docInfo/aliases</code>, there is a corresponding 
member in the <termref def="aliases">[aliases]</termref>. Let <term>U</term> be the 
value of such child element:</p>
    <olist>
        <item>

                                    <p>If <term>U</term> is a relative reference, let <term>B</term> be value of the 
[base URI] property of the containing <code>alias</code> element, 
then <termref def="aliases">[aliases]</termref> contains the result of transforming <term>U</term>
into an absolute URI, using <term>B</term> as the base URI, as defined in section
5 of RFC 3986 ([<bibref ref="RFC3986"/>]).</p>
</item>
<item>
                                    <p>Otherwise <termref def="aliases">[aliases]</termref> contains <term>U</term>.</p>

</item>
</olist>
</item>
</olist>

<p>
Aliases <rfc2119>MUST</rfc2119> be unique. That is, there <rfc2119>MUST NOT</rfc2119> exist two model 
documents whose <termref def="aliases">[aliases]</termref> properties overlap.
</p>

<note>
                        <p>As a consequence of the above property definition’s 
reliance on the “absolute-URI” production, the <code>alias</code> elements
 <rfc2119>MUST NOT</rfc2119> contain fragment components.
</p>
</note>

</div3>

<div3 id="URI_Processing">
<head>URI Reference Processing</head>
<p>
When processing an SML-IF document, there are 3 categories
of URI references that may need to be resolved:
</p>
<olist>
<item>
<p>

<code>schemaLocation</code> attributes on <code>xs:include</code>
and <code>xs:redefine</code> in schema documents, when they are model definition documents.
</p>
</item>
<item>
<p>URI references specified in instances of SML reference 
schemes that use target-complete identifiers [<bibref ref="SML"/>]. 
</p>
</item>
<item>
<p>URI references specified in instances of SML reference schemes
that do not use target-complete identifiers. </p>
</item>
</olist>
<p>
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 reference 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. Their resolution 
is governed by their scheme definitions and is not covered by this section.
</p>

<p>
To process a URI reference <term>UR</term> that is within categories
#1 or #2 above, the following steps are performed:
</p>
<olist>
<item>
<p>Determine the document <term>D</term> that possibly contains the target:</p>
    <olist>
      <item>

<p>If <term>UR</term> is a same-document reference [<bibref ref="RFC3986"/>], 
        then <term>D</term> is the model document that contains <term>UR</term>. </p>
      </item>
      <item>
<p>Otherwise</p>
        <olist>
          <item>
<p>If <term>UR</term> has a fragment component,
          then let <term>UR'</term> be the URI reference formed 
          by removing the fragment component; otherwise let <term>UR'</term> be <term>UR</term>.</p>
          </item>
          <item>

<p>If <term>UR'</term> is a relative reference, 
          then transform <term>UR'</term> to form an (absolute) URI <term>U</term>, 
           using its [base URI] as the base URI, as defined in section
            5 of RFC 3986 ([<bibref ref="RFC3986"/>]); 
            otherwise let <term>U</term> be <term>UR'</term>. 
          </p>
          </item>
          <item>

<p>If there exists a model document with an alias URI that
           is equal to <term>U</term> (<specref ref="URI_equality"/>), then 
           <term>D</term> is that document; otherwise <term>D</term> has no value. 
          </p>
          </item>         
        </olist>       
      </item>      
    </olist>
</item>
<item>
<p>If <term>D</term> has no value, then</p>
    <olist>
      <item>

<p>If <term>UR</term> is within category #1 (<code>schemaLocation</code>), 
      then the SML-IF document does not contain the target schema document. 
      Whether the <termref def="smlif_consumer">SML-IF consumer</termref>
       continues to dereference <term>UR</term> or <term>U</term>
      is governed by other sections of this specification. </p>
      </item>
      <item>
<p>Otherwise (<term>UR</term> is within category #2, used in an SML reference),
      <term>UR</term> has no target.</p>
      </item>      
    </olist>
</item>
<item>
<p>If <term>D</term> has a value, then </p>
    <olist>
      <item>
<p>If <term>UR</term> is within category #1 (<code>schemaLocation</code>), 
      then <term>UR</term> has a target if and only if all of the following are true. </p>
      	<olist>
      	<item>
                                    <p>
                                    <term>D</term> is a schema document that is also a model definition document 
      	in the interchange model.</p>
</item>
      	<item>
                                    <p>
                                    <term>UR</term> does not contain a fragment component.
      	</p>
</item>
      	</olist>
      </item>
      <item>
<p>If <term>UR</term> is within category #2, then</p>
      	<olist>
      	    <item>
                                    <p>If <term>UR</term> does not contain a fragment 
      	    component, then it targets the root element of D.</p>
</item>
      	    <item>
                                    <p>Otherwise (<term>UR</term> contains a fragment component), the 
      	    fragment component of <term>UR</term> is applied 
      	    to the root element of <term>D</term>, which may result in 0, 1, or 
      	    many target elements.</p>

</item>
      	</olist>
      </item>
    </olist>
</item>
</olist>

<p>To process a URI reference UR that is within category #3 above, a set of steps
corresponding to those described above for categories #1 and #2 MUST be defined
as part of the reference scheme definition.</p>
</div3>

</div2>
<div2 id="Document_Bindings">
<head>Document Bindings</head>
<div3 id="URI_prefix_matching">
<head>URI Prefix Matching</head>

<p>To associate SML rule or schema documents with the subset of documents in the
model to which they apply, SML-IF uses a combination of the <termref def="alias">alias</termref>
mechanism described above [<specref ref="Document_aliases"/>] 
and URI prefix matching.</p>

<p>Two URIs, one called the <emph>prefix</emph>, and one called the
<emph>target</emph> 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 equal to the prefix as defined in section <specref ref="URI_equality"/>.</p>

</div3>
<div3 id="Rule_Bindings_Definition">
<head>Rule Bindings</head>

<p>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.</p>

<p>The <code>ruleBinding</code> 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 model with an alias that
matches the URI prefix given by the content of the
<code>ruleAlias</code> element. The set of model documents in the
binding is that subset of the documents in the interchange model with an
alias that matches the URI prefix given by the content of the
<code>documentAlias</code> element. If the <code>documentAlias</code>
element is omitted in a <code>ruleBinding</code>, the set of model
documents in the binding is all documents in the interchange model.</p>

<note>

<p>Since the URI prefixes specified as <code>ruleAlias</code>
 and <code>documentAlias</code> elements
are aliases, they are subject to all of the processing for aliases as described
in [<specref ref="Document_aliases"/>].  For example, if they are relative references then they would be
transformed to absolute URIs before comparison.
</p>
</note>

<p>SML-IF consumers <rfc2119>MAY</rfc2119>
 choose to extend the sets of documents involved in bindings to
include documents not contained in the interchange model. 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 model, but documents in the other model.</p>

</div3>
<div3 id="Schema_Bindings_Definition">
<head>Schema Bindings</head>

<p>SML-IF consumers <rfc2119>MAY</rfc2119> choose to ignore the <code>schemaBindings</code> 
element when present in the SML-IF document, in which case the consumer <rfc2119>SHOULD</rfc2119>
make its invoker aware of this situation. 
</p>
<p>If an SML-IF consumer chooses to process the schemaBindings element, then,
as part of the <termref def="interchange_validation">interchange model validation</termref>, for every schema binding <b>SB</b> 
in the model, i.e. every <code>/model/schemaBindings/schemaBinding</code> 
element, the SML-IF consumer <rfc2119>MUST</rfc2119> perform the following steps 
for instance document validation.</p> 
<olist>
<item>
                            <p>Compose a schema using all documents specified under all 
<b>SB</b>'s <code>namespaceBinding</code> children.</p>
</item>
<item>
<p>Whenever an <code>import</code> for a namespace <b>N</b> is encountered, perform the following steps.</p>
<olist>
<item>

                                    <p>If there is a <code>namespaceBinding</code> child of <b>SB</b> whose 
<code>namespace</code> attribute matches <b>N</b>, then components from schema documents listed in the 
corresponding <code>aliases</code> attribute are used.  As with rule bindings, 
URI prefixing [<specref ref="URI_prefix_matching"/>]
is used for matching schema document aliases.
At most one <code>namespaceBinding</code> is allowed per namespace <b>N</b> within 
a given <b>SB</b>.  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 <b>N</b> is empty, the namespace has no schema 
documents defining it in the schema binding.</p>
</item>
<item>
                                    <p>Otherwise, if there are schema documents in the SML-IF document whose targetNamespace 
is <b>N</b>, then components from all those schema documents are used.</p>
</item>
<item>
                                    <p>Otherwise, if this is a schema-complete SML-IF document 
(<code>/model/@schemaComplete</code> = "true"), then no component from <b>N</b> (other than built-ins) is included in 
the schema being composed.</p>
</item>
<item>
                                    <p>Otherwise, it is implementation-defined whether SML-IF consumer 
attempts to retrieve components for <b>N</b> from outside the SML-IF document.</p>
</item>

</olist>
</item>
<item>
<p>Whenever an <code>include</code> or <code>redefine</code> is encountered, 
the <code>schemaLocation</code> is used to match aliases of schema documents, as with base SML-IF.</p>
<olist>
<item>
                                    <p>If there is a schema document in the SML-IF document matching that alias, then 
that document is used.</p>
</item>
<item>
                                    <p>Otherwise, if this is a schema-complete SML-IF document, then the <code>include</code> or 
<code>redefine</code> is unresolved (which is allowed by XML Schema 
validity assessment rules).</p>
</item>
<item>
                                    <p>Otherwise, it is implementation-defined whether an SML-IF consumer attempts to resolve 
<code>include</code> or <code>redefine</code> to schema documents outside the SML-IF document.
</p>
</item>
</olist>
</item>
<item>

                            <p>The instance documents that are referenced in the <code>documentAlias</code> 
element of <b>SB</b> <rfc2119>MUST</rfc2119> be validated
against the schema constructed in steps 1 through 3. <code>sml:target*</code> and SML identity constraints can now be checked. 
Similar to <code>documentAlias</code> under <code>ruleBinding</code> elements [<specref ref="Rule_Bindings_Definition"/>], each 
<code>documentAlias</code> can refer to multiple documents via URI prefixing.
</p>
</item>
</olist>
<p>Whether or not a <code>schemaBindings</code> element is present or is ignored, 
SML-IF consumers  <rfc2119>MUST</rfc2119> process 
an <code>include</code> or <code>redefine</code> element as described in 
step 3 above.</p>

<p>The common use case where match-all namespace matching is desired 
can be achieved by omitting <code>schemaBindings</code> without introducing any additional 
complexity into the SML-IF document.</p>
<p>If an SML-IF consumer chooses to process the <code>schemaBindings</code> element, then the following
rules regarding the default schema must be followed:</p>
<olist>
                        <item>
                            <p>If the optional <code>defaultSchema</code> element is present, then an SML-IF consumer <rfc2119>MUST</rfc2119>
 compose a default schema from this element  
following rules 1 to 3 above, replacing <b>SB</b> in the text with <b>DS</b> (i.e., the
<code>/model/schemaBindings/defaultSchema</code> element). </p>
</item>
<item>
                            <p>Otherwise, an SML-IF consumer <rfc2119>MUST</rfc2119>
 compose a default schema using all schema documents 
included in the SML-IF document. </p>
</item>
<item>

<p>An SML-IF consumer <rfc2119>MUST</rfc2119> 
use this default schema to validate those SML instance documents whose alias is not 
matched by any <code>documentAlias</code> in a <code>schemaBinding</code> element or <code>noSchemaBinding</code> element.
Note that URI prefixing [<specref ref="URI_prefix_matching"/>]
is used for matching document aliases. </p>
</item>

</olist>

<p>In all other cases, the SML-IF consumer <rfc2119>MUST</rfc2119> compose a schema
 using all schema documents included in the SML-IF document and <rfc2119>MUST</rfc2119> 
 use this schema to validate all instance documents in the 
<termref def="interchange_model">interchange model</termref>.</p>
<note>
<p>Examples of these cases include:</p>
<olist>
                            <item>
                                <p>An SML-IF consumer chooses not to process the schemaBindings element.</p>
</item> 
<item>
                                <p>No schema documents are found among the SML-IF document's definition documents.</p>
</item>
</olist>
</note>
<note>

<p>The distinction between schema and schema documents is both intentional
and important; the absence of schema documents does not imply the absence of a
schema.  A schema containing only built-in components will be constructed given
zero schema documents as input, and this schema will be used to validate all
instance documents in the interchange model.  This distinction has an impact on
model validation results according to the definition of validity for a
conforming SML model [<specref ref="ConformanceClause"/>].
</p>
</note>

</div3>
</div2>

</div1>
<div1 id="References">
<head>References</head>
<div2 id="Normative_References">
<head>Normative</head>
<blist>
<bibl key="SML 1.1" id="SML" href="http://www.w3.org/TR/2009/REC-sml-20090512/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Service Modeling Language, Version 1.1</titleref>, Bhalchandra Pandit,
Valentina Popescu, Virginia Smith, Editors.  World Wide Web Consortium, 12 May 2009. This
   version of the Service Modeling Language specification is available
   at http://www.w3.org/TR/2009/REC-sml-20090512/. The
   <loc href="http://www.w3.org/TR/sml/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of Service Modeling Language, Version 1.1</loc> is available at
   http://www.w3.org/TR/sml/.
</bibl>
 <bibl id="XSD1" key="XML Schema Structures" href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Schema Part 1: Structures Second
   Edition</titleref>, 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
   <loc href="http://www.w3.org/TR/xmlschema-1/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
   version of XML Schema Part 1</loc> is available at
   http://www.w3.org/TR/xmlschema-1.
 </bibl>

 <bibl key="XML Schema Datatypes" id="XSD2" href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Schema Part 2: Datatypes Second
   Edition</titleref>, 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
   <loc href="http://www.w3.org/TR/xmlschema-2/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
   version of XML Schema Part 2</loc> is available at
   http://www.w3.org/TR/xmlschema-2.
 </bibl>
      <bibl id="XML10" key="XML" href="http://www.w3.org/TR/2006/REC-xml-20060816/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
        <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Extensible Markup Language (XML) 1.0 (Fourth
        Edition)</titleref>, T.  Bray, J. Paoli,
        C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide
        Web Consortium, 10 February 1998, revised 16 August 2006. 
        The edition cited (http://www.w3.org/TR/2006/REC-xml-20060816) was the
        one current at the date of publication of this specification as a Candidate
        Recommendation. The <loc href="http://www.w3.org/TR/xml/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of XML
        1.0</loc> is available at http://www.w3.org/TR/xml/. 
        Implementations may follow the edition cited and/or
        any later edition(s); it is implementation-defined which editions are supported
        by an implementation.
      </bibl>
 <bibl id="XMLInfoset" key="XML Information Set" href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Information Set</titleref>, 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 <loc href="http://www.w3.org/TR/xml-infoset/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   latest version of the XML Infoset</loc> is available at http://www.w3.org/TR/xml-infoset/.
 </bibl>      
 <bibl id="XMLBase" key="XML Base" href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Base</titleref>, Jonathan Marsh, Editor.
   World Wide Web Consortium, 27 June 2001.
   This version of the XML Base
   Recommendation is http://www.w3.org/TR/2001/REC-xmlbase-20010627/.
   The <loc href="http://www.w3.org/TR/xmlbase/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   latest version of XML Base</loc> is available at http://www.w3.org/TR/xmlbase/.
 </bibl>      
<bibl key="IETF RFC 3986" href="http://www.ietf.org/rfc/rfc3986.txt" id="RFC3986" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Uniform Resource Identifier (URI): Generic Syntax</titleref>, 
  T. Berners-Lee, R. Fielding, L. Masinter Authors. Internet
  Engineering Task Force, January 2005. Available at
  http://www.ietf.org/rfc/rfc3986.txt.
</bibl>  
<bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Key words for use in RFCs to Indicate
  Requirement Levels</titleref>, S. Bradner, Author. Internet
  Engineering Task Force, June 1999. Available at
  http://www.ietf.org/rfc/rfc2119.txt.
</bibl> 
</blist>
</div2>
<div2 id="NonNormative_References">
<head>Non-Normative</head>
<blist>
 <bibl key="ISO/IEC 19757-3" id="Schematron" href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Information technology ― Document Schema
  Definition Languages (DSDL) ― Part 3: Rule-based
  validation ― Schematron</titleref>. 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
</bibl>
<bibl id="Canonical" key="Canonical XML" href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Canonical XML</titleref>, 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 <loc href="http://www.w3.org/TR/xml-c14n" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of Canonical
   XML</loc> is available at http://www.w3.org/TR/xml-c14n.
</bibl>       
<bibl id="XML-Signature" key="XML-Signature" href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML-Signature Syntax and Processing</titleref>,
  D. Eastlake, J. Reagle, and D. Solo, Editors. Internet
  Engineering Task Force &amp; 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
  <loc href="http://www.w3.org/TR/xmldsig-core/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
  version of XML-Signature Syntax and Processing</loc> is
  available at http://www.w3.org/TR/xmldsig-core/.
</bibl>
<bibl key="WS-Addressing Core" id="WSADDR-CORE" href="http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Web Services Addressing 1.0 - Core</titleref>,
  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
  <loc href="http://www.w3.org/TR/ws-addr-core/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
  version of WS-Addressing Core</loc> is available at
  http://www.w3.org/TR/ws-addr-core/.
</bibl>
<bibl key="WSDL 2.0 Core Language" href="http://www.w3.org/TR/2007/PR-wsdl20-20070523/" id="WSDL20" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Web Services Description Language (WSDL) Version
  2.0 Part 1: Core Language</titleref>, 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 <loc href="http://www.w3.org/TR/wsdl20/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of "Web
  Services Description Language (WSDL) Version 2.0 Part 1:
  Core Language"</loc> is available at
  http://www.w3.org/TR/wsdl20/.
</bibl>
<bibl key="XLink" href="http://www.w3.org/TR/2001/REC-xlink-20010627/" id="XLink" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
   <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Linking Language (XLink) Version 1.0</titleref>, 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
   <loc href="http://www.w3.org/TR/xlink/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
   version of XLink</loc> is available at
   http://www.w3.org/TR/xlink/.
</bibl>   
</blist>
</div2>
</div1>
    </body>
<back>
<div1 id="SML_IF_Schema">
<head>SML-IF Schema</head>
<eg xml:space="preserve">&lt;!--
/*
 * Copyright © ns World Wide Web Consortium,
 *
 * (Massachusetts Institute of Technology, European Research Consortium for
 * Informatics and Mathematics, Keio University). All Rights Reserved. This
 * work is distributed under the W3C® Document License [1] in the hope that
 * it will be useful, but WITHOUT ANY WARRANTY; without even the implied
 * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *
 * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
 */
--&gt;&lt;xs:schema
      xmlns:smlif="http://www.w3.org/ns/sml-if"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      targetNamespace="http://www.w3.org/ns/sml-if"
      elementFormDefault="qualified"
      blockDefault="#all"
      version="1.0"
      xml:lang="EN"
      finalDefault=""
      attributeFormDefault="unqualified"&gt;
   &lt;xs:element name="model" type="smlif:modelType"/&gt;
   &lt;xs:complexType name="modelType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element name="identity" type="smlif:identityType"/&gt;
         &lt;xs:element ref="smlif:ruleBindings" minOccurs="0"/&gt;
         &lt;xs:element ref="smlif:schemaBindings" minOccurs="0"/&gt;
         &lt;xs:element
               name="definitions"
               type="smlif:documentCollectionType"
               minOccurs="0"/&gt;
         &lt;xs:element
               name="instances"
               type="smlif:documentCollectionType"
               minOccurs="0"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:attribute
            name="SMLIFVersion"
            type="xs:token"
            use="optional"/&gt;
      &lt;xs:attribute
            name="schemaComplete"
            type="xs:boolean"
            default="false"/&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;!-- If there is a need for localized string values, e.g. in displayName
         or description, the sml:locid global attribute can be
         used --&gt;
   &lt;xs:complexType name="identityType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element name="name" type="smlif:uriType"/&gt;
         &lt;xs:element
               name="version"
               type="smlif:tokenType"
               minOccurs="0"/&gt;
         &lt;xs:element
               name="displayName"
               type="smlif:displayType"
               minOccurs="0"/&gt;
         &lt;xs:element
               name="baseURI"
               type="smlif:uriType"
               minOccurs="0"/&gt;
         &lt;xs:element
               name="description"
               type="smlif:displayType"
               minOccurs="0"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:complexType name="displayType" mixed="false"&gt;
      &lt;xs:simpleContent&gt;
         &lt;xs:extension base="xs:string"&gt;
            &lt;xs:anyAttribute
                  namespace="##other"
                  processContents="lax"/&gt;
         &lt;/xs:extension&gt;
      &lt;/xs:simpleContent&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:complexType name="tokenType" mixed="false"&gt;
      &lt;xs:simpleContent&gt;
         &lt;xs:extension base="xs:token"&gt;
            &lt;xs:anyAttribute
                  namespace="##other"
                  processContents="lax"/&gt;
         &lt;/xs:extension&gt;
      &lt;/xs:simpleContent&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:complexType name="uriType" mixed="false"&gt;
      &lt;xs:simpleContent&gt;
         &lt;xs:extension base="xs:anyURI"&gt;
            &lt;xs:anyAttribute
                  namespace="##other"
                  processContents="lax"/&gt;
         &lt;/xs:extension&gt;
      &lt;/xs:simpleContent&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element
         name="ruleBindings"
         type="smlif:ruleBindingCollectionType"/&gt;
   &lt;xs:complexType
         name="ruleBindingCollectionType"
         mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               ref="smlif:ruleBinding"
               maxOccurs="unbounded"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element name="ruleBinding" type="smlif:ruleBindingType"/&gt;
   &lt;xs:complexType name="ruleBindingType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               name="documentAlias"
               type="smlif:uriType"
               minOccurs="0"/&gt;
         &lt;xs:element name="ruleAlias" type="smlif:uriType"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element
         name="schemaBindings"
         type="smlif:schemaBindingCollectionType"/&gt;
   &lt;xs:complexType
         name="schemaBindingCollectionType"
         mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element ref="smlif:defaultSchema" minOccurs="0"/&gt;
         &lt;xs:element
               ref="smlif:schemaBinding"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
         &lt;xs:element
               ref="smlif:noSchemaBinding"
               minOccurs="0"
               maxOccurs="1"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element
         name="schemaBinding"
         type="smlif:schemaBindingType"/&gt;
   &lt;xs:complexType name="schemaBindingType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               ref="smlif:namespaceBinding"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
         &lt;xs:element
               name="documentAlias"
               type="smlif:uriType"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element
         name="namespaceBinding"
         type="smlif:namespaceBindingType"/&gt;
   &lt;!-- The value of the aliases attribute in the complexType below 
       is a list of instance document URIs --&gt;
   &lt;xs:complexType name="namespaceBindingType" mixed="false"&gt;
      &lt;xs:attribute
            name="namespace"
            type="xs:anyURI"
            use="optional"/&gt;
      &lt;xs:attribute name="aliases" use="required"&gt;
         &lt;xs:simpleType&gt;
            &lt;xs:list itemType="xs:anyURI"/&gt;
         &lt;/xs:simpleType&gt;
      &lt;/xs:attribute&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element
         name="noSchemaBinding"
         type="smlif:noSchemaBindingType"/&gt;
   &lt;xs:complexType name="noSchemaBindingType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               name="documentAlias"
               type="smlif:uriType"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element
         name="defaultSchema"
         type="smlif:defaultSchemaType"/&gt;
   &lt;xs:complexType name="defaultSchemaType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               ref="smlif:namespaceBinding"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:complexType name="documentCollectionType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element ref="smlif:document" maxOccurs="unbounded"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element name="document" type="smlif:documentType"/&gt;
   &lt;xs:complexType name="documentType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element ref="smlif:docinfo" minOccurs="0"/&gt;
         &lt;xs:choice&gt;
            &lt;xs:element name="data" type="smlif:dataType"/&gt;
            &lt;xs:element
                  name="base64Data"
                  type="smlif:base64DataType"/&gt;
            &lt;xs:element name="locator" type="smlif:locatorType"/&gt;
         &lt;/xs:choice&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element name="docinfo" type="smlif:docinfoType"/&gt;
   &lt;xs:complexType name="docinfoType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               name="baseURI"
               type="smlif:uriType"
               minOccurs="0"/&gt;
         &lt;xs:element ref="smlif:aliases" minOccurs="0"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:element name="aliases" type="smlif:aliasCollectionType"/&gt;
   &lt;xs:complexType name="aliasCollectionType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               name="alias"
               type="smlif:uriType"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:complexType name="dataType" mixed="false"&gt;
      &lt;xs:annotation&gt;
         &lt;xs:documentation&gt;
                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.
            &lt;/xs:documentation&gt;
      &lt;/xs:annotation&gt;
      &lt;xs:sequence&gt;
         &lt;xs:any
               processContents="skip"
               minOccurs="0"
               namespace="##any"
               maxOccurs="1"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:complexType name="base64DataType" mixed="false"&gt;
      &lt;xs:simpleContent&gt;
         &lt;xs:extension base="xs:base64Binary"&gt;
            &lt;xs:anyAttribute
                  namespace="##other"
                  processContents="lax"/&gt;
         &lt;/xs:extension&gt;
      &lt;/xs:simpleContent&gt;
   &lt;/xs:complexType&gt;
   &lt;xs:complexType name="locatorType" mixed="false"&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element
               name="documentURI"
               type="smlif:uriType"
               minOccurs="0"/&gt;
         &lt;xs:any
               namespace="##other"
               processContents="lax"
               minOccurs="0"
               maxOccurs="unbounded"/&gt;
      &lt;/xs:sequence&gt;
      &lt;xs:anyAttribute
            namespace="##other"
            processContents="lax"/&gt;
   &lt;/xs:complexType&gt;
&lt;/xs:schema&gt;</eg>
</div1>

<inform-div1 id="LocalizationSample">
    <head>Localization of IF Identity Sample</head>

<p>The following example shows how the <code>sml:locid</code> attribute
can be used to define the translation information for the interchange 
model identity attributes:</p>

<eg xml:space="preserve">
&lt;model xmlns="http://www.w3.org/ns/sml-if" version="1.0"
       xmlns:sml="http://www.w3.org/ns/sml"&gt;
       xmlns:lang="http://www.university.example.org/translation/core"&gt;
    &lt;identity&gt;
        &lt;name sml:locid="lang:nameID“&gt;Univerity interchange model&lt;/name&gt;
        &lt;description sml:locid="lang:descrID"&gt; This document contains a list of universities.&lt;/description&gt;
    &lt;/identity&gt;
&lt;/model&gt;
</eg>

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

<eg xml:space="preserve">&lt;xmlns:lang="http://www.university.example.org/translation/core"&gt;</eg>

<p>
The [local part] information of the <code>sml:locid</code> 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. 
</p>
</inform-div1>

<inform-div1 id="Acknowledgements">
<head>Acknowledgements</head>

<p>The editors acknowledge the members of the Service Modeling Language Working
Group, the members of other W3C Working Groups, and industry experts
in other forums who have contributed directly or indirectly to the
process or content of creating this document.</p>
<p>At the time this specification was published, the members of the
Service Modeling Language Working Group were:</p>

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

<p>The Service Modeling Language Working Group has benefited in its work
from the participation and contributions of a number of people not currently
members of the Working Group, including in particular those named below.</p>

<p>Dave Ehnebuske (IBM), Jon Hass (Dell), Steve Jerman (Cisco), Heather Kreger (IBM), Vincent Kowalski (BMC), Milan Milenkovic (Intel), Bryan Murray (HP), Phil Prasek (HP), Junaid Saiyed (EMC), Harm Sluiman (IBM),
C. Michael Sperberg-McQueen (W3C/MIT), Bassam Tabbara (Microsoft), Vijay Tewari (Intel), William Vambenepe (HP), Marv Waschke (CA), Andrea Westerinen (Microsoft), Pratul Dublish (Microsoft), Julia McCarthy (IBM).
</p>

<p>Affiliations given above are those current at the time of their work with the working group. 
</p>
</inform-div1>

</back>
</spec>