IMS Resource List Interoperability XML/WSDL Binding Version 1.0 Final Specification

Copyright © 2004 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Resource List Interoperability XML/WSDL Binding
Revision: 8 July 2004

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2004 IMS Global Learning Consortium. All Rights Reserved.

If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Table of Contents

1. Introduction

1.1 Resource List Interoperability Services Overview

This document is the XML and WSDL Binding of the Resource List Interoperability Information Model [RLI, 04a]. The specification is based on an abstract service behaviors and data model that describes in generalized terms a resource at the item level, a collection of these resources (i.e., a list) and the behaviors associated with a resource list management service. The data model is then bound or expressed in XML, combining elements that map to subsets of key standards, including the IEEE-LOM (Learning Object Metadata), ISO 690-2 for bibliographic citations, and NISO's OpenURL to describe the resource items and aggregated Resource List. The abstract service interface is bound to web services expressed as WSDL.

The Resource List Interoperability XML/WSDL Binding specification [RLI, 04b] is the definition of how systems manage the exchange of information that describes resource lists within the context of course management systems and library systems. The RLI specification is constructed following the recommendations documented in the IMS Abstract Framework (IAF) [AbsGloss, 03], [AbsASC, 03], [AbsWhite, 03]. This means that this specification is based upon the concepts of:

• Interoperability - RLI Management Services focuses on the exchange of Resource List information between Enterprise systems. There are no assumptions in the specification on how the data is managed within the Enterprise systems;
• Service-oriented - RLI Management Services defines the exchange of information in terms of the services being supplied by the collaboration of the systems;
• Component-based - the RLI Management Services will be combined with the Group Management Services to provide the Enterprise Service. Other services will be added to it in later releases;
• Layering - the RLI Management Service is a part of the Application Services layer but it interacts with the services available in the Common Services layer e.g. authentication;
• Behaviors and Data Models - the RLI Management Services are defined in terms of their behaviors and data models. The behaviors cause changes in the state of the data model and the state of the data model will only be altered as a result of a clearly defined behavior;
• Multiple Bindings - the RLI Management Services information model is to be defined using the Unified Modelling Language (UML). This enables reliable mapping of the information model into a range of different bindings. The bindings of immediate importance are to the Web Services Description Language (WSDL);
• Adoption - the RLI Management Services are based upon the original Enterprise specification data model. While there are significant changes, the underlying data model has been maintained and the core structures remain.

1.2 Scope and Context

This WSDL binding takes the Resource List Interoperability Information Model and produces an encoding of that description in WSDL. This WSDL binding is generated as recommended by the IMS General Web Services documents [GWS, 04a], [GWS, 04b].

The following are out of scope for this specification:

1. In this specification, the definition of persistent locators is out of scope and not addressed. The RLI specification does state, however, when locators are needed and what meta-data is required for the construction of known, standard resolver schemes such as OpenURL and the Digital Object Identifier.
2. Authorization/Access Management. Ensuring authorized access to the resource list creation functionality and the items contained within a Resource List is outside the scope of this specification. The RLI Specification does provide a meta-data element in which access rights or other intellectual property declarations associated with the resource list can be stated in human readable form for display or other, non-machine actionable purposes.
3. Association of Course Identifiers. Dynamically associating system course identifiers to resource lists is critical to the practical working of the RLI spec (see Constraints in Data Model, RLI Information Model section 4.6). The definition of course identifiers is out of scope.
4. Update transactions. Lists already created that have been modified must in their entirety replace any previous versions (Destructive Update). Update functionality may be formalized in a later phase of specification development.

1.3 Structure of this Document

The structure of this document is:

1.4 Nomenclature

1.5 References

2. Application of the WSDL Binding Guidelines

The WSDL bindings have been generated using the methodology documented in [GWS 04a] and [GWS, 04b]. The composition of the synchronous WSDL binding is shown in Figure 2.1.

The binding files described in Figure 2.1 contain:

• 'imsRLIManServiceSyncv1p0.wsdl' - the service specific WSDL binding file. For the RLI Management Service this is based upon SOAP/HTTP. This file imports the abstract definitions using the <wsdl:import> construct. See Appendix A - Synchronous Binding WSDL Listings;
• 'imsRLIManAbstractSyncv1p0.wsdl' - the abstract message definitions that represent the behavior of the RLI Management Service operations. This file imports the message XSD using the <xsd:import> construct. See Appendix A - Synchronous Binding WSDL Listings;
• 'imsRLIManMessSchemav1p0.xsd' - the XSD definitions for the synchronous and asynchronous messages. This file imports the RLI data model XSD using the <xsd:import> construct. See Appendix A - Synchronous Binding WSDL Listings
• 'imsRLIManDataSchemav1p0.xsd' - the definition of the RLI data model. This is the file that was produced by the equivalent data model binding in Enterprise v1.1. See Appendix A - Synchronous Binding WSDL Listings;
• 'imsMessBindSchemav1p0.xsd' - the XSD binding of the message header parts. This includes the message headers for synchronous, polled and asynchronous message models;
• 'imsCommonSchemav1p0.xsd' - the XSD binding of the IMS common data objects. This file is used by the RLI message and data model XSDs as well as the IMS message binding XSD;
• 'wsiwsdlv1p1.xsd' - this is the reference XSD for the WSDL definition. This file is the WS-I amended version of the original file from W3C;
• 'wsisoapv1p1.xsd' - this is the reference XSD for the SOAP extensions to WSDL. This file is from WS-I.

The name spaces used within these bindings are listed in Table 2.1.

2.1 Testing

The XML Schema files have been validated and tested. UC Berkeley successfully generated client Java code from the WSDL in the RLI specification using the AXIS 1.1 tool kit. Microsoft successfully generated client .NET code from the WSDL in the RLI specification using the Visual Studio .NET tools. Oxford University ran the draft WSDL files through the WS-I tests successfully.

As examples and sample files become available they will be included on the Resource List Interoperability specification web page (http://www.imsglobal.org/rli/).

3. Synchronous WSDL Binding

For more details on any of the Operations or the OCL information see the RLI Information Model, section 3.1.2 "Operations", the OCL table in the Information Model, section 4.8, and the XSD and WSDL files described below.

3.1 SOAP Specific Service Binding

The key properties of the Specific Service binding files are detailed in Table 3.1. The Service Specific filename is: 'imsRLIManServiceSyncv1p0.wsdl'.

3.2 Abstract Definition Binding

The key properties of the Specific Service binding files are detailed in Table 3.2. The Abstract Definitions filename is: 'imsRLIManAbstractSyncv1p0.wsdl'.

3.3 Message XML Schemas

3.3.1 'createResourceListRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'createResourceList ()' operation.

Two parameters are supplied:

• sourcedId - the unique identifier to be assigned to the new resourceList record;
• resourceList - the resourceList data to be stored in the new record.

3.3.2 'createResourceListResponse' Message

This is the response message from the Sync Agent to the Reference Agent to complete the 'createResourceList ()' operation.

The <createResourceListResponse> element is empty.

Note: The status information is returned in the header of the SOAP transport message.

3.3.3 'createByProxyResourceListRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'createByProxyResourceList ()' operation.

One parameter is supplied:

• resourceList - the resourceList data to be stored in the new record.

3.3.4 'createByProxyResourceListResponse' Message

This is the response message from the Sync Agent to the Reference Agent to complete the 'createByProxyResourceList ()' operation.

The returned information is:

• sourcedId - the unique identifier assigned by the Sync Agent to the new record.

Note: The status information is returned in the header of the SOAP transport message.

3.3.5 'deleteResourceListRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'deleteResourceList ()' operation.

One parameter is supplied:

• sourcedId - the identifier of the resourceList record to be deleted.

3.3.6 'deleteResourceListResponse' Message

This is the response message from the Sync Agent to the Reference Agent to complete the 'deleteResourceList ()' operation.

The <deleteResourceListResponse> element is empty.

Note: The status information is returned in the header of the SOAP transport message.

3.3.7 'readResourceListRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'readResourceList ()' operation.

One parameter is supplied:

• sourcedId - the identifier of the resourceList record to be read.

3.3.8 'readResourceListResponse' Message

This is the response message from the Sync Agent to the Reference Agent to complete the 'readResourceList ()' operation.

The returned information is:

• resourceList - the returned resourceList record.

Note: The status information is returned in the header of the SOAP transport message.

3.3.9 'replaceResourceListRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'replaceResourceList ()' operation.

Two parameters are supplied:

• sourcedId - the identifier of the resourceList record to be changed.
• resourceList - the resourceList data to be stored in the new record.

3.3.10 'replaceResourceListResponse' Message

This is the response message from the Sync Agent to the Reference Agent to complete the 'replaceResourceList ()' operation.

The <replaceResourceListResponse> element is empty.

Note: The status information is returned in the header of the SOAP transport message.

3.3.11 'readResourceListsForGroupRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'readResourceListsForGroup ()' operation.

Two parameters are supplied:

• sourcedId - the identifier of the resourceLists that are to be returned.
• groupSourcedIdSet - the identifier of the Group whose resourceList records are to be returned.

3.3.12 'readResourceListsForGroupResponse' Message

This is the response message from the Sync Agent to the Reference Agent to complete the 'readResourceListsForGroup ()' operation.

The returned information is:

• ResourceListSet - the set of resourceList records that have been read.

Note: The status information is returned in the header of the SOAP transport message.

3.3.13 'assignResourceListRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'assignResourceList ()' operation.

Four parameters are supplied:

• sourcedId - the identifier of the resourceLists that are to be returned.
• groupSourcedId - the identifier of the Group whose resourceList members records are to be returned.
• constraints - the constraints on the assignment (see sub-section 3.4.9 of this document for the constraints model).
• note - a string containing a description of the assignment.

3.3.14 'assignResourceListResponse' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'assignResourceList ()' operation.

The <assignResourceListResponse> element is empty.

Note: The status information is returned in the header of the SOAP transport message.

3.3.15 'deassignResourceListRequest' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'dassignResourceList ()' operation.

Three parameters are supplied:

• sourcedId - the identifier of the resourceLists that are to be returned.
• groupSourcedId - the identifier of the Group whose resourceList members records are to be returned.
• note - a string containing a description of the assignment.

3.3.16 'deassignResourceListResponse' Message

This is the request message from the Reference Agent to the Sync Agent to invoke the 'deassignResourceList ()' operation.

The <deassignResourceListResponse> element is empty.

Note: The status information is returned in the header of the SOAP transport message.

3.4 Data Model XML Schemas

This section documents the element structure of the 'imsRLIManDataSchema_v1p0.xsd' file. For details on the OCL definitions and UML characteristics see the XML Schema file and the Information Model. This is an XSD representation, and the XML equivalent, of the UML model in the RLI Information Model.

We will not describe the elements and their relationships in narrative here. All that information can be found in the Information Model [RLI, 04a].

3.4.1 Type Mapping

Each meta-data element in the RLI specification is designed to be mappable to a particular schema as a result a set of meta-data complex types were created that would allow for that information to be contained in the local profile of the schema and to aid interoperability between resource list schemas. Four meta-data complex types were created to allow for the four core types of information storage required by the RLI UML model: complex language strings, strings, dates, and tokens.

The nomenclature used is camelback with "DType" at the end to signify data type.

The example below is the <MetadataLangStringDType>.

Notice that there is an element for the name of the schema the element is mapped to, the version of that schema that was used, and the element name of the schema, all strings. Then the fourth element is the value element that contains the actual meta-data value. It is of the type of the "Dtype". In this case, the complex type <SeqLangStringDType> handles the complex language strings.

Here are the other structures:

Note: The <MetadataTokenDType> element includes a vdexTerm element that allows terms to be utilized as per the IMS Vocabulary Definitions Exchange specification [VDEX, 04].

3.4.2 <resourceList> Element

All the following sections in 3.4 describe the element structure of the resourceList element that binds the Information Model including the constraints construct.

The XSD visualization of the RLI data model is shown in Figure 3.21.

3.4.3 <annotation> Element

3.4.4 <resourceListMetadata> Element

3.4.5 <resource> Element

3.4.6 <resourceMetadata> Element

3.4.7 <citation> Element

3.4.8 <relatedTitle> Element

3.4.9 <constraints> Element

3.5 Example SOAP/HTTP Message

This section contains examples of a Resource List Soap Message. We are using the Request and the Response of the <createResourceList> operation as our example.

3.5.1 'createResourceListRequest' Message

POST /RLIManagementService HTTP/1.1
Host: www.RLImanagementserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://www.imsglobal.org/soap/rlims/createResourceList"
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header>
      <h:syncRequestHeaderInfo xmlns:h="../imsMessBindSchemav1p0.xsd">
         <h:messageIdentifier>AB12345e4t6789</h:messageIdentifier>
      </h:syncRequestHeaderInfo>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      <m:createResourceListRequest xmlns:m="../imsRLIManMessSchemav1p0.xsd">
         <m:sourcedId>oldsource:oldidentifier</m:sourcedId>
         <m:resourceList>
            <m:edition>
               <m:metadataToken>12</m:metadataToken>
            </m:edition>
            <m:resource>
               <m:indexId>AB1234YUOAREIT</m:indexed>
               <m:resourceMetadata>
                  <m:citation>
                     <m:title>
                        <m:metadataLangString>The Harsatari Experiment- The Final 
Chapter</m:metadataLangString>
                     </m:title>
                     <m:creator>
                        <m:metadataLangString>Dr. Locks Garner, CCMI</m:metadataLangString>
                     </m:creator>
                     <m:publicationDate>
                        <m:metadataDate>January 4, 2004</m:metadataDate>
                     </m:publicationDate>
                     <m:publisher>
                        <m:metadataLangString>Muffini Press</m:metadataLangString>
                     </m:publisher>
                  </m:citation>
               </m:resourceListMetadata>
            </m:resource>
            <m:resourceListMetadata>
               <m:title>
                  <m:metadataLangString>The Harsatari Experiment</m:metadataLangString>
               </m:title>
               <m:rightsDescription>
                  <m:metadataLangString>copyright 2004 Arthur Blake, Treemont 
University</m:metadataLangString>
               </m:rightsDescription>
            </m:resourceListMetadata>
         </m:resourceList>
      </m:createResourceListRequest>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

3.5.2 'createResourceListResponse' Message

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header>
      <h:syncResponseHeaderInfo xmlns:h="../imsMessBindSchemav1p0.xsd">
         <h:messageIdentifier>AB12345e4t6889</h:messageIdentifier>
         <h:statusInfo>
            <h:codeMajor>success</h:codeMajor>
            <h:severity>status</h:severity>
            <h:messageIdRef>AB12345e4t6789</h:messageIdRef>
         </h:statusInfo>
      </h:syncResponseHeaderInfo>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      <m:createResourceListResponse xmlns:m="../imsRLIManMessSchemav1p0.xsd"/>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

4. Extensions

This section is not normative and addresses the concept of modularity, reusability, etc.

4.1 Extension of the RLI Model

If RLI does not provide the expressiveness required, then the recommended approach is to use RLI with extensions, preferably agreed in a community of practice. This approach:

• Avoids proliferation of exchange models with a great deal of similarity at a semantic level.
• May allow a user of a system that is ignorant of the extensions to gain some benefit from a degraded but non-zero performance.

The manner of extension is binding-dependent. The RLI Binding document explains how XML 1.0 documents using W3C XML Schema Definition Language can be extended such that graceful degradation of performance is enabled.

4.2 Extension Statements

Vendors making use of extensions to RLI should clearly identify the function and form of the extensions in order for users of data and software to understand the likely degradation of behavior in systems not supporting the extensions.

Extendable elements in this binding of the RLI specification are:

4.2.1 Resource List

• description
  • resourceListMetadata
  • annotation
  • resources

4.2.2 Resource

• resourceMetadata
  • annotation
  • description
  • annotation.Description
  • citation

4.3 Other Bindings

Although the RLI Project Group has determined that METS and RSS bindings would be useful, they are not in scope for this initial specification. People interested in creating a METS or RSS binding should use the XML/WSDL binding as a guide.

Appendix A - Synchronous Binding WSDL Listings

The bindings listed below are for the synchronous SOAPv1.1/HTTPv1.1 based implementation. The set of binding files are given in Table A1.

About This Document

List of Contributors

The following individuals contributed to the development of this document:

Revision History

Index

A
Abstract Framework 1
Attributes
     Common

sourcedId 1, 2, 3, 4      Role

status 1, 2, 3, 4, 5

B
Behavior 1
Bibliographic 1
Binding 1, 2, 3, 4, 5, 6, 7, 8
Binding technologies
     SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9
     WSDL 1, 2, 3, 4

C
Conformance 1

E
Enterprise Service 1
Extension 1

I
IEEE 1, 2
IMS Specifications
     Resource List Interoperability 1, 2, 3, 4, 5, 6, 7
     Vocabulary Definition Exchange 1
Interoperability 1
ISO 1, 2

L
LOM 1, 2
LTSC 1

M
Meta-data 1, 2

N
Namespace 1
Normative 1

O
OpenURL 1

P
Profile 1

R
Records 1, 2, 3
Resource 1, 2
Resource list 1, 2, 3, 4, 5, 6
Resources 1
RFC 1

S
Schema 1, 2, 3
SCORM 1
Services 1
SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9
Standards 1
Structure 1, 2

W
W3C 1, 2, 3
WDSL 1, 2, 3, 4

X
XML 1, 2, 3, 4, 5, 6
     XSD 1, 2, 3, 4, 5, 6