Service Modeling Language Interchange Format Version 1.1

2.1 Notational Conventions

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

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

2.2 Terminology

Interchange set

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

Definition document, instance document, rule document

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

4.1 Packaging

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

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

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

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

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

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

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

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

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

4.2 URI References

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

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

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

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

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

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

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

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

, after removing the fragment, becomes

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

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

The fragment-free part of the reference:

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

is

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

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

The URI:

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

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

4.3 Rule Document Bindings

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

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

Would associate documents that have the aliases such as:

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

and

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

with rule documents that have aliases such as:

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

and

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

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

4.4 Schema Document Bindings

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

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

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

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

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

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

An SML-IF document can be:

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

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

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

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

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

3. sml:ref attribute declaration

4. sml:uri element declaration

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

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

The following example illustrates schema bindings.

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

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

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

5.1 Conformance Criteria

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

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

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

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

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

5.2 SML-IF Documents

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

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

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

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

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

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

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

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

5.3 URI References

5.4 Rule Document Bindings

5.5 Schema Document Bindings

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1 Normative

[SML 1.1]

Service Modeling Language, Version 1.1, Bhalchandra Pandit, Valentina Popescu, Virginia Smith, Editors. World Wide Web Consortium, 10 September 2008. This version of the Service Modeling Language specification is available at http://www.w3.org/TR/2008/WD-sml-20080110/. The latest version of Service Modeling Language, Version 1.1 is available at http://www.w3.org/TR/sml

[XML Schema Structures]

XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The latest version of XML Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.

[XML Schema Datatypes]

XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The latest version of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2.

[XML]

Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 16 August 2006. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2006/REC-xml-20060816. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml.

[XML Information Set]

XML Information Set, John Cowan and Richard Tobin, Editors. World Wide Web Consortium, 4 February 2004. This version of the XML Infoset Recommendation is http://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The latest version of the XML Infoset is available at http://www.w3.org/TR/xml-infoset/.

[IETF RFC 3986]

Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter Authors. Internet Engineering Task Force, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt.

[IETF RFC 2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt.

6.2 Non-Normative

[ISO/IEC 19757-3]

Information technology ― Document Schema Definition Languages (DSDL) ― Part 3: Rule-based validation ― Schematron. International Organization for Standardization and International Electrotechnical Commission, 1 January 2006. Available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip

[Canonical XML]

Canonical XML, J. Boyer, Author. World Wide Web Consortium, 15 March 2001. This version of the Canonical XML Recommendation is http://www.w3.org/TR/2001/REC-xml-c14n-20010315. The latest version of Canonical XML is available at http://www.w3.org/TR/xml-c14n.

[XML-Signature]

XML-Signature Syntax and Processing, D. Eastlake, J. Reagle, and D. Solo, Editors. Internet Engineering Task Force & World Wide Web Consortium, 12 February 2002. This version of the XML-Signature Syntax and Processing Recommendation is http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/. The latest version of XML-Signature Syntax and Processing is available at http://www.w3.org/TR/xmldsig-core/.

[WS-Addressing Core]

Web Services Addressing 1.0 - Core, M. Gudgin, M. Hadley, and T. Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the WS-Addressing Core Recommendation is http://www.w3.org/TR/2006/REC-ws-addr-core-20060509. The latest version of WS-Addressing Core is available at http://www.w3.org/TR/ws-addr-core.

[WSDL 2.0 Core Language]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, Editors. World Wide Web Consortium, 23 May 2007. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" Specification is available is available at http://www.w3.org/TR/2007/PR-wsdl20-20070523. The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" is available at http://www.w3.org/TR/wsdl20.

[XLink]

XML Linking Language (XLink) Version 1.0, Steve DeRose, Eve Maler, David Orchard, Editors. World Wide Web Consortium, 27 June 2001. This version of the XLink Recommendation is http://www.w3.org/TR/2001/REC-xlink-20010627/ The latest version of XLink is available at http://www.w3.org/TR/xlink/.