IMS Abstract Framework: White Paper Version 1.0

Copyright © 2003 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Abstract Framework: White Paper
Revision: 01 July 2003 

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 © IMS Global Learning Consortium 2006. All Rights Reserved.

If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. 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 Licensee organizations 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 work 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/af/afv1p0/afv1p0speclicense.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.

Executive Summary

The IMS Abstract Framework is a device to enable the IMS to describe the context within which it develops its eLearning technology specifications. This framework is not an attempt to define the IMS architecture, rather it is a mechanism to define the set of interfaces for which IMS may or may not produce a set of interoperability specifications. The IMS Abstract Framework is so named because:

• It is an abstract representation of the set of services that are used to construct an eLearning system in its broadest sense;
• It is focused on the support of distributed electronic learning systems;
• It is a framework that covers the possible range of eLearning architectures that could be constructed from the set of defined services.

It is the intention of IMS that this Abstract Framework and the associated IMS specifications produced to realize the exchange of information between the identified services will be adopted in a manner suitable for a particular system requirement. The Abstract Framework is represented as a layered model, as shown in the figures below; this approach was derived from an extensive survey of the state-of-the-art for eLearning architectures.

The core features of the framework are:

• Application layer - the set of systems, tools and applications that are constructed from the suite of application and common services to provide a particular set of eLearning functionality;
• Application services layer - the set of entities that provide the eLearning specific services e.g., course management. It is these services that constitute the primary focus for IMS specification development;
• Common services layer - the set of entities that provide the generic services to be used by the application services e.g., authentication;
• Infrastructure layer - the underlying services that enable the exchange of the data structures in terms of physical communications, messaging and corresponding transaction needs;
• Service access points - the access points, or interface, to the corresponding service. Each access point provides access to one service capability;
• Entities - the processes that are used to represent a particular service. The realization of an entity with its service access points is termed a component and its abstract representation is called a Class.

The IMS specifications are used to define the data structures, and when appropriate the permitted behaviors for the exchange of those data structures, between the Components. This interoperability is defined in terms of the exchange of the appropriate XML instances as defined by their XML Schema Definitions. The IMS specification of a service is such that any number of bindings can be created e.g., native XML, web services description language, Java, etc. It is the corresponding information and behavioral descriptions that enable interoperability between these different bindings. The Abstract Framework also describes the transport mechanisms that can be used to exchange the XML documents.

The adoption of the Abstract Framework will be based upon the creation of suitable Domain Profiles. Domain profiling is the process that is undertaken to define which specifications and the detailed usage of the data objects within each specification are to be adopted to provide a particular solution. The domain profiling process is based upon:

• Identification of the appropriate specifications by matching their functional capabilities to the requirements of the application;
• Refinement of each IMS specification made by increasing the constraints on the information model to more accurately reflect the needs of the domain. This refinement includes definition of profile-specific extensions;
• The new binding for the domain profile should now be produced. In general, a instance document for a particular profile should validate against the new binding control document for the profile and the binding control document for the corresponding IMS specification. The profile-specific binding control document will be capable of identifying errors in the instances due to the increased constraints on the permitted data content;
• The corresponding strong conformance statement and certification test specification should now be produced for the domain profile.

This is a 'living' document i.e., it is not archival in nature. Our ideas for various parts of the Abstract Framework are constantly being developed and so the information contained herein should always be considered in that context. This white paper is one of a set of closely related documents, the others being:

• The IMS Abstract Framework: Glossary - the definitions of the key terms used throughout the ALF and the associated specifications;
• The IMS Abstract Framework: Applications, Services, and Components - the identification of the set of applications and services and their corresponding implementation components which can be used to support eLearning system interoperability (the separation of the detailed descriptions of the applications, services and components allows the details of this white paper to focus on the abstract representation itself);
• The IMS Learning Activity Model (LAM) - the description of the underlying content model and the learner design mechanisms to be adopted for the provision of learning content (this document will not be available until mid 2004);
• The IMS Use Case Portfolio - the collection and collation of the core set of use cases that reflect the interoperability needs within eLearning systems (work on the collection of these use cases is underway);
• The IMS Specification Development Methods and Best Practices - the identification of the methods and best practices that must be used when developing and documenting IMS specifications.

'Domain Conformance' will not be defined with respect to an IMS specification. These specifications contain too many optional features and are subject to regional and sector specific amendments e.g., the inclusion of the appropriate vocabularies. Therefore, conformance will be against a particular Conformance Profile that has been derived from the corresponding Domain Profile. Conformance certification is considerably easier when all of the functionality is mandatory and so it is important for Conformance Profiles to remove as much optional functionality as possible. In turn, there is a generic requirement that for a Domain Profile to be 'Strictly Conforming' to an IMS specification then an XML instance of the domain profile must also validate against the corresponding IMS specification.

Table of Contents

1. Introduction

1.1 Scope and Context

The IMS Abstract Framework (IAF) is a device to enable the IMS to describe the context within which it will continue to develop its eLearning technology interoperability specifications. This framework is not an attempt to define the IMS architecture, rather it is mechanism to define the set of interfaces for which IMS may or may not produce a set of interoperability specifications. In the cases where IMS does not produce a specification then every effort will be made to adopt or recommend a suitable specification from another organization. The IMS Abstract Framework is so named because:

• It is an abstract representation of the services and their interfaces that are used to construct an eLearning system in its broadest sense;
• It is focused on the support of distributed electronic learning systems;
• It is a framework that covers the possible range of eLearning architectures that could be constructed from the set of defined services and interfaces.

It is the intention of IMS that this Abstract Framework and the associated IMS specifications will be used as the starting point for the definition of many different eLearning systems. Each eLearning system will only adopt those parts of the IMS specifications that are of immediate use. This process is called the Profiling of the framework to define an architecture or reference model for a particular implementation domain; the process of profiling a particular specification is similar to refining the best practice to produce mandatory facets for an implementation domain. The Profiles can then be used to support conformance testing, based upon a particular conformance-profile for that domain, to ensure compliance to a particular requirement.

1.2 Using this Document

This is a 'living' document i.e., it is not archival in nature1. Our ideas for various parts of the IAF are constantly being developed and so the information contained herein should always be considered in that context. This white paper is one of a set of closely related documents, the others being:

• The IMS Abstract Framework: Glossary [IMS, 03a] - the definitions of the key terms used throughout the ALF and the associated specifications;
• The IMS Abstract Framework: Applications, Services, and Components [IMS, 03b] - the identification of the set of applications and services and their corresponding implementation components which can be used to support eLearning system interoperability (the separation of the detailed descriptions of the applications, services and components allows the details of this white paper to focus on the abstract representation itself);
• The IMS Learning Activity Model (LAM) - description of the underlying content model and the learner design mechanisms to be adopted for the provision of learning content (this document will not be available until mid 2004);
• The IMS Use Case Portfolio - the collection and collation of the core set of use cases that reflect the interoperability needs within eLearning systems (work on the collection of these use cases is underway);
• The IMS Specification Development Methods and Best Practices [IMS, 03c] - the identification of the methods and best practices that must be used when developing and documenting IMS specifications.

At the current time only the Glossary and the Application, Services, and Components documents are available as support to this white paper. During the next twelve months the other documents will become available and consequently new releases of the IAF may be required. This white paper is constructed in three sections:

• Basic structure of the IAF - definitions of the requirements and the corresponding overall structure of the IAF;
• Abstraction to implementation - the process through which the IAF can be used to define an architecture for implementation;
• Detailed background information - a series of appendices that contain the detailed technical information that forms the background to the IAF.

The IAF provides the context for the development of the next series of IMS specifications. The IMS specification development process uses the IAF to:

• Identify some of the eLearning components that are to be specified. Once these components have been specified then any appropriate amendments to the services identified in the IAF will also be made;
• Identify the components that will be adopted from other specification and standards activities. These components may be tailored to enhance their adoption for eLearning;
• Demonstrate the process by which the UML representations of the information model descriptions of the components are converted to their XML binding equivalents;
• Demonstrate the ways in which the 'sea of components' is combined and profiled to support the specification of eLearning architectures.

As with all of the IMS specifications there is a need to develop best practice for each of the activities summarized above. The IAF will be updated on a regular basis, typically once every six months, and as a part of other activities e.g., development of the learning activity model. While these updates will include important new information, the underlying principles of interoperable, component-based service definitions within a layered framework will not be changed.

1.3 Structure of this Document

The structure of this document is:

2. Requirements Definition	The definition of the requirements in terms of the underlying principles, scoping and use cases that define the context within which the abstract framework was developed;
3. The Abstract Framework	The definition of the overall structure of the abstract framework. This shows the relationship between the various sub-structures within the framework;
4. Applications, Services, and Components	The description of the ways in which the requirements and capabilities of applications, services and components can be defined;
5. Infrastructure layer	The detailed description of the Infrastructure Layer within the abstract framework. This includes the definition of the sub-layers and the identification of the core technologies that can be adopted to realize the corresponding functionality;
6. Service Bindings	A description of the different service bindings of the abstract framework and the implications for implementations based on these bindings;
7. Profiling and Conformance	A review of the profiling of the abstract framework and the accompanying IMS and other specifications to support a particular application, to define a specific architecture and to enable conformance;
Bibliography	The set of documents that are referenced within this document or which provide context to the contents of this document;
Appendix A - List of Acronyms	The list of acronyms used throughout this document;
Appendix B - IMS Specification Roadmap	A visualization of the development roadmap of the set of IMS specifications released and under development and their relationship and adoption timeline by other specification and architecture definition initiatives;
Appendix C - eLearning and Related Architectures & Models	Brief descriptions of each of the architectures and models currently in use or under development within the eLearning domain.

2. Requirements Definition

2.1 Historical Context

During the past 30 months IMS has released a unique set of interoperability specifications within the eLearning technology community (that work was founded upon an extensive range of experimental activities undertaken during the prior 24 months). During this period the various eLearning technology activities have begun a slow convergence that has been the result of extensive work behind the scenes by IMS and other organizations. It is now apparent that the current set of IMS activities and processes need to evolve to tackle the next series of technical issues [IMS, 02a]. As a consequence, IMS has produced its Abstract Framework to the context within which:

• The new set of IMS specifications are developed;
• The migration from the current to the new specifications can be defined and managed;
• The relationship between IMS and non-IMS specifications can be explained and clearly demonstrated;

The current set of IMS specifications released and under development is listed in Table 2.1.

IMS Specification	Description	Version	Release Date
Meta-data	The tagging of any learning content.	1.2.1	December 2001
Enterprise	The exchange of Person and Group information.	1.1	July 2002
Learner Information Package	To exchange a Person's profile or life-long learning log.	1.0	March 2001
Question & Test	Used to support computer-based Assessment.	1.2.1	April 2003
Content Packaging	Exchanging content with its associated learning structures.	1.1.3	May 2003
Simple Sequencing	Adaptive learning routes through a set of learning content.	1.0	March 2003
Reusable Definition for Competency and Educational Objectives	A syntax for the description of competencies.	1.0	August 2002
Learning Design	The unified representation of different learning activities.	1.0	February 2003
Digital Repositories Interoperability	Search and retrieval using meta-data tagged resources distributed across a federated set of databases.	1.0	January 2003

The IMS also has a set of guidelines that have been released to act as support documents to the specifications. These guidelines are:

• IMS Persistent Location-independent Resource Identifier (PLIRI) - the recommended IMS generic user identifier format [IMS, 01a];
• Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications: An Implementation Handbook - recommendations for the usage of the Content Packaging specification as a generalized packaging mechanism [IMS, 01b];
• Accessibility Guidelines - guidelines for the development of accessible content [IMS, 02d].

2.2 Underlying Principles

2.2.1 Interoperability

The specifications are focussed on the exchange of information between systems. The specifications make no assumptions on how the data is managed within the communicating systems.

2.2.2 Service-Oriented

The exchange between the systems is to be defined in terms of the services being supplied by the collaboration of the systems. This service collaboration could take many forms as well as being based upon peer-to-peer and client-server techniques.

2.2.3 Component-Based

The set of services will be supplied as a 'sea of components' that can be mixed and matched to form a particular service. A single component may provide all or a sub-set of a service but it will not provide more than one service.

2.2.4 Layering

The total set of services required to make an eLearning system will be modelled as a set of layers with each layer providing a clearly defined set of services. A particular layer will make use of the services in the layer below it and will provide services to the entities in the layers above it.

2.2.5 Behaviors and Data Models

A service will be defined in terms of its behaviors and data model. The behaviors will 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. It may not be appropriate to define every service in terms of its behavior and in these cases only the relevant data models will be developed.

2.2.6 Multiple Bindings

The information model is to be defined and represented using an established syntax and semantics. This will then enable automatic mapping of the information model into a range of different bindings. The bindings of immediate importance are XML and Web Services Description Language (WSDL), however Java bindings will also be supported.

2.2.7 Adoption

New specifications will only be created as required. Whenever possible, appropriate specifications will be adopted from wherever and either used 'as is' or modified to suit a particular set of requirements.

2.3 Key Use Cases

The service range covered by the abstract framework is based upon a core set of use cases that have been collected from:

• Higher education, community colleges and further education;
• Schools - education in the age range 4-16 e.g., K-12;
• Corporate training - this includes activities such as Professional Certification and Continuing Professional Development.

In all cases these use cases have been taken from different parts of the world, with a particular focus on North America, Europe and Asia. This ensures that the internationalization aspects of eLearning services are considered.

Note: The Use Case Portfolio activity currently underway will complete its work in late 2003. That portfolio will be used as the basis for further material in this sub-section. The key use cases will be used to identify the set of applications and services that need to be supported.

2.4 Scoping of the Abstract Framework

The scope of the abstract framework is set by the requirements generating by analyzing:

• The use cases as described within the Use Case Portfolio;
• The current set of IMS specifications;
• Reference models and architectures already available or undergoing development e.g., SCORM, SIF, OKI, etc.

Note: The Use Case Portfolio activity currently underway will complete its work in late 2003. That portfolio will be used as the basis for further material in this sub-section.

3. The Abstract Framework

3.1 eLearning Systems

A review of a wide range of eLearning systems is summarized in Appendix C and a synthesis of these is shown in Figure 3.1. Figure 3.1 is a logical architecture based upon layer abstraction. The equivalent physical architectural model is shown in Figure 3.2.

The logical representation consists of the following layers:

• Users - the set of users of the eLearning system e.g., students, administrators, teachers, etc. Users gain access to the system through an appropriate 'user agent';
• User agents (see Appendix C5 for more details) - the agents that deliver the services to the users themselves;
• Tools (see Appendix C5 for more details) - the tools enable the different services to be accessed in a convenient and 'user-friendly' manner. This includes assessment, tutoring, simulation, etc.
• Learning/education services (see Appendices C1, C5 and C7 for more details) - the learning services themselves;
• Support services (see Appendices C1, C5 and C7 for more details) - common services that are also required by non eLearning systems e.g., authentication, resource discovery etc.
• Digital repositories (see Appendix C7 for more details) -
• Communications infrastructure - the basic networking and data transport services that deliver information end-to-end.

The physical representation (Figure 3.2) consists of the following core structures:

• Core network - the primary network that interconnects the core computer systems. This includes what would be termed the 'Internet'. This is a part of the 'Communications Infrastructure' in the logical model;
• Access network - the network that links the delivery devices to the core network. Typical examples are cable networks, wireless networks, PSTNs, etc. This is a part of the 'Communications Infrastructure' in the logical model;
• Federated digital repositories - the series of digital resources that are available in a variety of digital repositories, databases, web servers, etc. This is the manifestation of the 'Digital Repositories' in the logical model;
• Service delivery engines - the systems that are responsible for the provision of the full series of learning services. This corresponds to the 'Learning/educational Services' and 'Support Services' in the logical model;
• Delivery devices - the devices and their client support that deliver the learning material to the user. This corresponds to the 'Tools' and 'user Agents' in the logical model.

The abstract framework has to be designed such that it can be used to represent a wide range of architectures.

3.2 The Functional Model

There are several possible functional perspectives of an eLearning system. The two perspectives that are introduced herein are (it is these perspectives that dominate the IMS specification activity):

• Content - this describes how content and related information flows and is managed within an eLearning system;
• Individual - this describes how information about an individual flows and is managed within a eLearning system.

These functional perspectives identify where the interoperability points are within an eLearning system i.e., where the arrows are used in Figures 3.3 and 3.4. If these exchange points are exposed as external communications between different systems then an interoperability specification is required.

3.2.1 The Content Perspective2

A functional representation of the flow and management of content and related information within an eLearning system is shown in Figure 3.3.

There are four key functional themes:

• Content repository and offering catalogue - the storage of the learning materials and the catalogue listing and describing those materials;
• Learner profile manager - management of the learner's profile;
• Content repository and offering catalogue source generators - this includes the set of tools that generate the actual learning content and the catalogue that describes those materials;
• The core activities that generate changes in the learner's profile as a result of undertaking learning. These activities are:
  • Planning of what and when learning needs to be undertaken
  • Registration on the appropriate course offerings
  • Learning with the materials
  • Collaboration with other participants on the course(s)
  • Assessment of what has been learnt.

3.2.2 The Individual Perspective

A functional representation of the flow and management of personal and related information within an eLearning system is shown in Figure 3.4

Again, there are four key functional themes:

• Personal profile repository - the management of the learner's profile in some personally maintained repository;
• Human resources repository - the management of the learner's profile in the institution's human-resources system;
• Personal information and work source generators - this includes the set of tools and sources that generate information about the person;
• The core activities that generate changes in the learner's profile as a result of undertaking learning. These activities are:
  • Planning of what and when training/education needs to be undertaken
  • Delivery of the training (corporate and training focus) and education (qualification focused)
  • Normal work activity that generates a range of materials that can for a portfolio of experience
  • Assessment of what has been learnt.

3.3 The Layered Model

The abstract learning framework can be represented as a layered model, as shown in Figure 3.5, consisting of four layers:

• Application layer - this is a tool, system, agent, etc. that presents the appropriate application services to the user i.e., an application manages the user interface. The application may use one or more application services but whenever possible the system composition should be hidden from the user;
• Application Services layer - a set of services that provide the required eLearning functionality to the applications. An application service may make use of one or more common services. Distributed application services communicate using via the Infrastructure Layer;
• Common Services layer - a set of services that are available to the application services. Common services may use other common services. Therefore, a common service is available to any other service;
• Infrastructure layer - this provides the end-to-end transaction and communications services for the application and common services.

Access to a service is through the appropriate Service Access Point (SAP). Each service has a single SAP. A Component may support one or more SAPs (in an object oriented representation, a SAP could be supported by one or more operators where the class is itself the definition of the service).

In a distributed implementation of this layered framework, as typified in a webs services environment, the interaction between the services would as shown in Figure 3.6. In this interaction framework there are three categories of interface that must be supported by the Infrastructure layer namely:

• The Application Services interface (A1) - this interface is used to provide interoperability between common application services e.g., Enterprise-to-Enterprise systems. One form of the interface is based upon XML-messaging;
• The Common Services interface (A2) - this interface is used to provide interoperability with the set of common services that are made available to the application specific services e.g., authentication and authorization for an Enterprise system;
• The run-time interface (B) - this interface is used to interconnect the client's run-time application with the remote service provider.

Figure 3.6 shows that there are two types of interaction behavior that need to be specified to ensure interoperability, namely:

• Message passing - where information is exchanged between systems using some form or another of message exchange. The content and sequence of the messages define the expected behavior. The communicating systems are expected to process and generate the messages as a response to known and understood events. The systems must be capable of handling unknown error conditions;
• Run-time - where the end systems have to reliably operate on information using some predefined algorithm. The data will determine the outcomes of the algorithms but the behavior is well defined for all possible outcomes.

3.4 The Service Abstraction

One of the design principles for the IAF is the adoption of service abstraction to describe the appropriate eLearning functionality. The service is hidden behind a SAP and can only be accessed by using the SAP (an API could be one way in which the SAP is actually implemented). However, even though the service provision is hidden behind the SAP, an implementation requires that the behavioral capabilities of the service be defined. Once again an object-oriented representation is adopted. In Figure 3.7 we have a schematic representation of a service, namely:

• The service has a clearly defined service access point. Each service has only one SAP. The SAP is now defined in terms of its constituent objects and behaviors;
• The SAP may consist of one or more objects and each object will, in general, will have more than one operator. Each object is defined using a class definition and consists of a group of attributes and operators. The operators describe how the state of the attributes may be changed. The set of behaviors permitted for each class must also be defined. These behavioral definitions ensure that any implementation of the class provides the same predicted behaviors for the same trigger events. Both the classes and their behaviors are defined in an implementation-independent manner;
• The 'Private Service Implementation' is beyond the scope of the IAF. The only requirements on this are that it provides all of the appropriate behavioral characteristics of the service and nothing more. This means that an implementation can be changed e.g., for optimization, without requiring a change to any of the systems using that service.

This approach means that every service (application and common) must be defined using this form of abstraction. In many cases the services interact with each other e.g., an application service will use a common service. This interaction is reflected by the service invoking the SAP of the required service.

The adoption of UML as our representation framework means that each service must be defined by:

• A single class package whose name reflects the name of the service. The functional capabilities of that class package are based upon the aggregation and inheritance of other Classes. The actual SAP is represented by 'Interface Classes'. The relationship between the classes will be shown using Class Diagrams and Package Diagrams;
• Each Interface Class has a set of operators which are the definition of the SAP i.e., the SAP is a single logical definition of one or more operators;
• The set of data structures for the object are defined using the attributes of the classes. All of the data structures must be strongly typed and their domain must be defined as tightly as possible;
• Whenever possible the behaviors will be defined using state diagrams/tables;
• The interactions between the classes will be defined using Sequence Diagrams;
• Implementation details will not be addressed thus Component Diagrams, Deployment Diagrams, etc. will not be produced.

3.5 The Run-time Environment

Few of the current IMS specifications address the issue of content run-time interoperability. This is handled by other specifications e.g., the AICC CMI. However, IMS need to look at several run-time issues such as content-to-content communication, web service based content launch, etc. A schematic representation of the run-time architecture for content is shown in Figure 3.8.

Figure 3.8 shows that the interactions between a content server (LMS, LCMS, etc.) and the delivery clients (typically this includes the usage of a browser); note that in general the server will have a significant number of concurrent users who will be using different learning materials and who may or may not wish to halt and restart their activities at various times. The client should be able to 'pull-in' other content as and when required without requiring communication through the server. The client should also be able to launch multiple concurrent 'learning objects' that co-operate to provide the full learning experience. Therefore the client will need a range of plug-ins that will enable it to parse the content, render the content, etc. before actually playing the material to the user.

This scenario requires clear definition of the internal behaviors of the server and client in response to the user's interactions with the content. The nature of the content being exchanged between the server and client needs to be addressed - at present this is either web pages with or without other material that can be played with the appropriate plug-in or it is executables that can run natively on the client device. The increasing adoption of XML may mean that it is possible to encode content natively in XML - clearly not all content will be XML encoded e.g., video.

3.6 UML Representation

The layered representation shown for the IAF in Figure 3.5 can be redrawn in UML as shown in Figure 3.9. In many regards this is a more appropriate representation as the IAF does not enforce a robust layering in the way that it can be implemented.

The object oriented representation in Figure 3.9 shows the dependence between the different 'layers' or the services.

4. Applications, Services, and Components

The set of applications, services and components that can be developed using this abstract framework are detailed in [IMS, 03b]. In this Section we are going to describe the characteristics that are used to categorize an application, application service, common service and component.

4.1 Applications

In the context of eLearning, an application is the manifestation of a system or tool that delivers one or more eLearning application services to a user. The key differences between an application and an application service are that an application provides an interface to the user(s) and that it may use more than one application service. A template for the brief description of an application is shown in Table 4.1.

Application
Application Description:	A description of the application.
User Interface:	Definition of the form and structure of the user interface.
Application Service Dependencies:	Identification of the application services that are used to create the application.

Note: IMS will not be undertaking the specification of applications as a part of its specification development activity.

4.2 Application Services

In the context of eLearning, an application service is responsible for delivering a set of features that support the manipulation of a set of data objects for a common purpose e.g., an Assessment Service for online assessment. An application service may be created by aggregating other application services. A template for the brief description of an application service is shown in Table 4.2.

Application Service
Service Description:	A description of the service.
Service Access Point:	Definition of the service access point i.e., the supported operators.
Core Attributes:	The definition of the core data objects that can be manipulated via the operators.
Core Components:	Identification of the component(s) that will be used to realize the application service.
Common Service Dependencies:	Identification of the common services that are invoked by the application service.
Infrastructure Dependencies:	Definition of the infrastructure required for the support of the application service.

Note: The core specification development activity undertaken by IMS will focus on the development of application services.

4.3 Common Services

A common service is responsible for delivering a set of features that are relevant to more than one application service and which, in many cases, are also required by non-eLearning systems e.g., an authentication service. A template for the brief description of a common service is shown in Table 4.3.

Common Service
Service Description:	A description of the service.
Service Access Point:	Definition of the service access point i.e., the supported operators.
Core Attributes:	The definition of the core data objects that can be manipulated via the operators.
Core Components:	Identification of the component(s) that will be used to realize the common service.
Infrastructure Dependencies:	Definition of the infrastructure required to support the common service.

Note: IMS will not be undertaking the specification of common services as a part of its specification development activity.

4.4 Components

A component is the realization of an abstract model. IMS produces specifications of services that can be released as components that provide interoperability capabilities for eLearning systems. A template for the brief description of a component is shown in Table 4.4.

Component
Component Description:	A description of the component.
Source Specification(s):	The data objects for the original specification(s) and standard(s) from which this component is derived.
Interfaces:	Definition of the interfaces that expose the support functionality.
Core Attributes:	The definition of the core data objects that can be manipulated via the interfaces.
Protocol Requirements:	Definition of the protocols required to provide intra and inter component communications.
Component Dependencies:	Identification of the other components that are required by this component.

An IMS specification of a component is the UML-based representation of the abstract application programming interface. This representation describes the set of classes for the component and defines the data and information that is exchanged between the corresponding objects.

5. Infrastructure Layer

5.1 The Composition of the Infrastructure Layer

The IMS specifications are focused on data exchange interoperability. To this end they define a data model of the information to be exchanged and a behavioral model that encapsulates the data model and constrains the way in which the data can be manipulated. An IMS information model is the manifestation of this behavioral and data description and an information model will consist of one or more IMS Components (these will realize either all, or part of, an Application Service). These components can then be realized in a variety of ways; the defined IMS method is as an XML-based binding. As such, this binding describes the way in which the data is exchanged in the form of XML messages/documents, however the actual transfer of these structures requires, at the very least, an appropriate communications system.

The exchange of the data between the XML components within the abstract framework is defined through the Infrastructure Layer. A schematic representation of the system components in this infrastructure description is shown in Figure 5.1. This representation assumes that the system is loosely coupled e.g., as per web services.

In Figure 5.1 the key parts of this infrastructure are:

• IMS XML Components - the application and common services components that are combined to create the e-learning system required. It is assumed that these components exchange information in the form of XML documents;
• XML-based Context - the XML documents are transformed to XML messages which are then mapped onto a common XML messaging infrastructure that is designed to support the required end-to-end services e.g., reliable data transfer, datagram, publish and subscribe, etc. The preferred context mapping language is the Web Services Description Language (WSDL). This could be based upon the W3C XML protocol (XP);
• XML-based Envelope - the common XML messaging system can be supported using several types of XML envelope encapsulation e.g., SOAP, SOAP with attachments (used to support file attachments such as images, etc.), ebXML, etc. WSDL supports SOAP, 'http-Get' and 'http-Post' transport mechanisms;
• Generic transport - the envelope is then transported across the network using an appropriate end-to-end file transfer protocol e.g., SMTP, FTP, HTTP, etc.;
• Communications network - this is the actual data network that is used to physically transport the data from one system to another. This will almost certainly be based upon the ubiquitous Internet Transmission Control Protocol/Internet Protocol (TCP/IP) combination providing seamless interworking between wire-line and wireless networks.

5.2 XML-Based Context Sub-Layer

The XML-based Context sub-layer is responsible for mapping the behaviors and associated operators of the XML components onto an appropriate sequence of XML messages. In principle there are a very large number of possible operators for even just a few components. There is however a number of common operators as described in Table 5.1. Table 5.1, or the Beshears Matrix (taken from work produced by the Enterprise working-group) was derived to identify the generic types of operation/methods required to enable the exchange of objects between an initiating system (initiator) and the responding system (respondent).

The corresponding state diagram requires that the completion of each method should be accompanied by the definition of which of the next methods can be invoked successfully on the same object.

The set of XML messages required to support the operators in Table 5.1 must include the following range of functionality:

• Operator action invocation message - the message sent from the initiator to the respondent invoking the functionality of the operator;
• Operator action invocation acknowledgement message - the message sent from the respondent to the initiator confirming receipt of the original operator action invocation message;
• Operator action invocation response message - the message sent from the respondent to the initiator containing the requested information.

Any of the messages may consist of the actual control and core data structures plus any associated resources e.g., jpeg files, etc.

	Respondent is the owner of the data. Request an action.	Initiator is the owner of the data. Announce data availability for others.	Initiator is the owner of the data. Request synchronization.
Create	Create the object and return the allocated identifier. The object data structure is populated with the supplied data (only the mandatory parts are supplied). The respondent owns the object.	Broadcasting of the fact that an object has been created with the assigned identifier. The initiator owns the object.	Create the object using the supplied identifier. The object data structure is initialized as empty. The initiator owns the object.
	createRequestObj()	createAnnounceObj()	createRequestObj()
Delete	Delete the object.	Broadcasting of the fact that the object has been deleted by its owner.	Delete the object.
	deleteRequestObj()	deleteAnnounceObj()	deleteRequestObj()
Update	Change the object identified by the supplied ID. This could be a partial update of the component. This is a destructive write but only the fields changed are updated; it is not required to have sent a copy of the old data.	Announcement that the Object has been changed. This includes the information of which part of the object has been changed.	Change the object identified by the supplied ID. This could be a partial update of the component. This is a destructive write but only the fields changed are updated; it is not required to have sent a copy of the old data.
	updateRequestObj()	updateAnnounceObj()	updateRequestObj()
Append	This is a functional adding of a new part to the identified parent. The commonality with 'update' equivalent needs thinking thru. This will need an equivalent delete part of object.	Announcement that the Object has been changed. This includes the information of which part of the object has been changed. This will need an equivalent delete part of object.	This is a functional adding of a new part to the identified parent. The commonality with 'update' equivalent needs thinking thru. This will need an equivalent delete part of object.
	appendRequestObj()	appendAnnounceObj()	synchronizeRequestObj()
Read	Read the part of the object identified. If read 'All' then only return those parts permitted for view by the requester. Need to consider whether we get flat data or just the reference. readObj()
Query	This provides the capability to ask for all objects that comply with a particular set of search criteria. The details for all of the objects that comply with the search criteria are returned. queryObj()

The equivalent state diagram for the operators shown in Table 5.1 is given in Figure 5.2.

The start state is when the system is idle. An instance of an object can then be created one of three ways:

• New remote object - the owner of the object requests that a copy is made in a remote system. The new object is owned by the remote system;
• New slave object - the owner of the object request that a copy is made in a remote system but this copy is not owned by the remote system;
• New object - the owner of the object announces the availability of the object to other systems.

Once the object has been created all operations are now supported. Once the delete operation has been invoked the object is deleted and the system returns to the 'Idle' state. In Figure 5.2, it is assumed that the state of the operation is reported to the system initiating the operation.

5.2.1 XML Context Messages

In the case of loosely coupled systems then the Beshears matrix is implemented by the exchange of messages. In most cases this is a two-phase message exchange with the initiator of the interaction issuing the 'request' message and the respondent replying with the 'response' message; this is normally termed the 'request-response' service model. It is good practice to ensure that the response message carries back the state of the initial request i.e., was the request successfully process or not and if not what was the cause for the failure. Table 5.2 shows the types of information that should be sent in the request/response messages. The various status codes include:

• Success - successful operation execution;
• NoIdFail - no identifiers available to be allocated;
• UnknownIdFail - the object identifier is unknown to the system;
• InvalidDataFail - the supplied data is invalid in some form or another;
• CommsFail - some form of communications system failure.

Operation	Request Message Information	Response Message Information
Create	Initialization state Transaction Identifier	Status Code Transaction Identifier
Delete	Object identifier Transaction Identifier	Status Code Transaction Identifier
Read	Object identifier Transaction Identifier	Object data Status Code Transaction Identifier
Update	Object identifier Replacement data Transaction Identifier	Status Code Transaction Identifier
Append	Object identifier New data Transaction Identifier	Status Code Transaction Identifier
Query	Search criteria Transaction Identifier	Set of object data Status Code Transaction Identifier

WSDL is one representation method for the context sub-layer. This enables the operations and their associated logical messages to be expressed in XML but it also provides the binding of those messages to the equivalent transport mechanism (the envelope sub-layer). In the case of SOAP the XML message is carried in the body part of the SOAP message is defined using an XSD. A brief overview of WSDL is given in the IMS specification development methods and best practices guide [SpecDev, 03].

5.3 XML-Based Envelope Sub-Layer

The XML-based Envelope sub-layer is responsible for encapsulating the sequence of XML messages and associated resources produced by the XML-based Context sub-layer in a common XML messaging structure. The three available approaches are:

• Develop an IMS-specific XML-based envelope - this approach is discouraged in preference to adopting an established mechanism;
• Use an established eLearning specific XML-based envelope - the SIF has such a mechanism however this approach could also lead to an idiosyncratic solution;
• The preferred approach, which is to use an established generic XML-based envelope such as:-
  • SOAP
  • SOAP with Attachments
  • http-Get
  • http-Post
  • ebXML Transaction, Routing & Packaging.

5.3.1 SOAP

The Simple Object Access Protocol (SOAP) is a messaging transport protocol that can be implemented using XML documents [SOAP, 03a], [SOAP, 03b], [SOAP, 03c]. A brief overview of SOAP is given in the IMS specification development methods and best practices guide [SpecDev, 03].

5.3.2 SOAP with Attachments

SOAP with Attachments is an extension of SOAP that is designed to enable non-XML information to be transported in the SOAP messages [SOAP, 01a]. A brief overview of SOAP is given in the IMS specification development methods and best practices guide [SpecDev, 03].

5.3.3 ebXML Transaction, Routing, and Packaging

The XML-based replacement of the Electronic Data Interchange (EDI) is termed ebXML. ebXML is based upon an extensive range of functionality ranging from the transaction exchange mechanisms to the routing table protocols [ebXML, 01a], [ebXML, 01b], [ebXML, 01c], [ebXML, 01d], [ebXML, 01e], [ebXML, 01f], [ebXML, 01g].

5.4 Generic Transport Sub-Layer

The Generic Transport sub-layer is responsible for transferring the XML messages across the appropriate data network architecture. The specification of these protocols is outside the scope of the abstract framework with the exception of ensuring that the XML-based Envelope sub-layer XML messages can be exchanged using the appropriate generic transport protocol. The detailed sub-structure of the generic transport sub-layer is:

• Generic transport protocol - the application transport protocol responsible for managing the delivery of the XML messages. A variety of protocols are available to provide this capability, including:-
  • File Transfer Protocol (FTP) - the standard Internet file transfer protocol
  • Simple Mail Transfer Protocol (SMTP) - normally used to send emails, with attachments, from the client to the mail server
  • Hypertext Transfer Protocol (HTTP) - the Internet web access protocol. The secure version, S-HTTP, is also available;
• End-to-end communications protocol - this is the protocol that turns the set of linked physical networks into a reliable end-to-end network. In general this protocol will be based upon Transmission Control Protocol/Internet protocol (TCP/IP) with the occasional usage of User Datagram protocol/Internet protocol (UDP/IP) in cases where high performance delivery is required. If UDP/IP is used then a higher level protocol will have to be responsible for ensuring reliable delivery as and when required;
• Physical data network - the actual data network, which may itself consist of several internetworked networks, which physically connects all of the system. The different parts of this network will have different characteristics e.g., terrestrial and mobile links, and so the end-to-end communications protocol is responsible for making this a reliable end-to-end network. The definition of the various networks, devices and networking techniques is outside the scope of the abstract learning framework.

5.5 Building the Infrastructure Stack

A working system requires the profiling of the entire infrastructure layer to support the appropriate application and common services. IMS will be producing a series of recommendations for a set of default infrastructure profiles as a part of its general web services binding project (to be completed by the end of 2003). One of the strengths of this layered approach is that the information model definition remains unchanged for different infrastructure profiles as it is the only the binding to that infrastructure that must be changed. Also, one infrastructure profile is capable of supporting many different information models provided the infrastructure sustains the minimum quality of service capabilities e.g., reliable end-to-end data delivery.

6. Service Bindings

6.1 Binding of the Information Model

The abstract framework is formally expressed as a UML representation. From an IMS perspective, this information model representation is traditionally bound to XML. In the new specifications XML will not be the only supported binding. This representation process is shown in Figures 6.1.

In Figure 6.1 it is shown that the logical representation of a system is derived from one or more classes that are grouped using packages. The package shows the dependencies between the classes. Each class consists of attributes (the data structures) and operators (the operations permitted on the data structures). The system is then constructed from these components as shown in the deployment diagram. The logical structure is represented using packages and it is representation that must be mapped using an appropriate binding. The advantage of this approach is that both the UML specification (the Information Model) and the corresponding set of bindings (of which XML and WSDL are just two) can be used for implementation. It is then possible to map together different implementations in different ways without loss of capability. The usage of an information model defines the common service capability between the different bindings.

The binding must take into account the attributes and operators of the class. In the original IMS specifications the XML DTDs and XSDs were a representation of the attributes of the class. The behavioral representations are defined through the class operators. In this case the binding is achieved by representing these operators as a series of messages exchanged by the communicating eLearning systems. The behavior is represented by the sequence of messages and the content of the control field in the headers of the messages (a message is assumed to consist of a header, containing the control fields, and the body, containing the data to be transferred).

A simple system showing the exchange of an object between two systems (the initiator and the respondent) is shown in Figure 6.2. In this system the initiator is requesting that the respondent create an object. In the initiator the 'createObject()' operator is invoked. The implementation of the object handler in the initiator translates this action into a 'createObject.request' XML message. This message is passed to the communications handler object that is responsible for transmitting this message to the respondent system via the communications network. The respondent communication handler may be required (this depends upon the protocol being implemented) to return an acknowledgment message that is used to inform the initiator that the request has been received. When the respondent actually completes the object creation request, notification of this may be returned to the initiator. This notification results in the transmission of the 'createObject.response' message. Its receipt at the initiator signifies that the request has been completed; this may or may not have resulted in the creation of the object and so some completion status codes should be returned via the 'createObject.response' message.

This sequence gives rise to three categories of information exchange, namely:

• Object operators - the operations defined in the equivalent class description;
• Binding messages - these are exchanged between the interoperating systems to implement the behaviors of the operator triggering the message exchange;
• Packets - the actual data packets that are sent across the data network (the binding messages are encapsulated in these messages).

From the perspective of the fully layered abstract framework one possible sequence of events is as shown in Figure 6.3. In this scenario two systems (perhaps Enterprise systems) are exchanging information e.g., the initiator wishes to inform the respondent of the creation of a group. The systems use a common application service and one common service e.g., authorization. The infrastructure service underpins all of the other services and provides a reliable end-to-end communication infrastructure. The initiator is using remote services and as such the initiating objects must contain the interface definitions for the service. The respondent objects must contain the functionality to actual handle the service requests.

The initiating system issues the 'createObject()' which results in the object invoking the relevant application service. The application service issues the remote object creation instruction. This request requires the application service to obtain authorization though the corresponding common service. Once the authorization has been completed the actual object creation process is started and this request is sent to the respondent system. Once the request has been processed the appropriate response is returned to the initiator.

There are several ways in which this scenario could be developed:

• More than one common service could be invoked by the application service;
• Any common service could itself invoke another common service;
• An application could invoke more than one application service;
• Each service (application, common, infrastructure) could be implemented using several objects. This depends on the functionality of each object and its relationship to the service definitions.

It is important to stress that this scenario has been considered from the perspective of a generic binding of the services. The actual mapping is dependent on the nature of the services and the underlying capabilities in the Infrastructure Layer.

6.2 Possible Bindings

The advantage of using a robust method for representing the behavioral aspects of the information model means that, in principle, different bindings can be automatically generated by the usage of the appropriate tools and the application of suitable transformation rules. Figure 6.4 shows the set of possible bindings that can be created.

The key points from Figure 6.4 are:

• Only Java is shown as an explicit non-XML based binding. Other language specific bindings are also possible. A Java implementation can be created by generating the corresponding Java methods and data structures from the class descriptions. Some UML tools will create a Java implementation as a 'Save As...' option;
• The IMS-specific XML-based binding requires that IMS create their own XML context and XML document representation. These XML documents can then be converted to XML messages using SOAP, SOAP with Attachments or some other technique (including an IMS-specific approach). One approach is that the permitted structure and contents of the XML messages are defined using an XSD. Each type of message is defined using its own XSD and each operator in a class is represented by one or more XSDs. The behavior is represented by the sequence of messages and the content of the control field in the headers of the XML messages (a message is assumed to consist of a header, containing the control fields, and the body, containing the data to be transferred). The disadvantage of this approach is that IMS would not be leveraging the work of organizations such as W3C;
• The proprietary XML-based binding approach makes use of work from other organizations that have developed their own messaging system (this may or may not use some standard underlying technologies). Systems of particular relevance are the SIF messaging mechanism and ebXML. The latter contains a sophisticated messaging system whereas the SIF approach requires a new message object to be created for every new object as opposed to using a single generic message object container;
• The web services binding covers all of the other XML-based techniques. In this category are the standard W3C techniques of XP, SOAP, SOAP with Attachments and WSDL. WSDL is itself a binding representation technique that must have an associated messaging mechanism i.e., SOAP, etc.;
• There will at some time in the future be other web service bindings.

The preferred IMS service binding approach is based upon:

• The usage of XML as the underlying data representation format. UML is the abstract representation of the information model but XML is the underlying binding encoding format;
• The usage of WSDL to act as the intermediate binding representation format. IMS will develop a series of recommendations on how to create the WSDL binding from a UML-based information model. These recommendations will also address the usage of different transport mechanism within the WSDL description;
• The usage of SOAP with Attachments as the underlying common messaging mechanism. The usage of HTTP/HTTPS (as opposed to FTP or SMTP) as the underlying transport mechanism.

It is possible to translate between different IMS bindings provided the binding of the information model has been reliably and consisted. This gives rise to the following forms of communications interoperability issues:

• End systems that use the same IMS binding mechanism can communicate using another binding (either IMS or non-IMS) provided the appropriate binding switch or router encapsulation is used;
• End systems that use the same IMS binding mechanism can communicate using another binding (either IMS or non-IMS) provided the appropriate binding switch or router transformation is used;
• End system that use different IMS binding mechanisms can communicate through a gateway that provides the appropriate binding translation;
• An IMS bindings switch/router fabric could be used to support the exchange of information between non-IMS systems.

7. Profiling and Conformance

7.1 Profiling

Domain profiling is the process that is undertaken to define which specifications and the detailed usage of the data objects within each specification are to be adopted to provide a particular solution. Therefore, the development of SCORM, using this terminology, was domain profiling undertaken on behalf of the US Department of Defense. In general, a resulting 'Domain Profile' or 'Reference Model' will be based upon a variety of specifications and standards i.e., it will not consist, solely, of IMS specifications.

The domain profiling process is based upon:

• Identification of the appropriate specifications by matching their functional capabilities to the requirements of the application;
• Refinement of each IMS specification made by:-
  • Where appropriate, the constraints within the information model and binding are made stronger e.g., optional elements can be made mandatory. The constraints must not be relaxed otherwise the profile will not be valid with respect to the IMS specification. All default attributes should be changed to be required or fixed
  • Profile-specific extensions must be defined. These will take the form of new elements and attributes that should, in general, be required. Whenever possible these extensions should only be applied where permitted within the IMS specification. All profile-specific extensions should have their own unique namespace
  • All proprietary extensions locations should now be defined. These must only be permitted wherever the IMS specification allows extensions i.e., the profile may wish to remove some of the IMS defined extension locations
  • All free format data content should be typed according to the required data types e.g., whenever possible a number should be defined as integer, etc. and the permitted range of values should also be defined
  • All of the vocabularies for the element and attribute data entries must be defined. The vocabularies will reflect the market and domain of the application. Whenever possible, internationally and nationally agreed vocabularies should be adopted;
  • The new binding for the domain profile should now be produced. In general, a instance document for a particular profile should validate against the new binding control document for the profile and the binding control document for the corresponding IMS specification. The profile-specific binding control document will be capable of identifying errors in the instances due to the increased constraints on the permitted data content;
• The corresponding strong conformance statement and certification test specification should now be produced for the domain profile.

The issue now becomes one of how to map between different domain profiles i.e., this is inter-domain interoperability (the domain profile supports intra-domain interoperability. In many cases different domain profiles will have a common core with only a small set of important differences. Mapping between domain profiles is simplified due to the usage of XML as the binding format. The mapping process is shown schematically in Figure 7.1 in which there are two, currently theoretical, domain profiles of QTI for SCORM and SIF. Each domain profile has its own XML schema that is the manifestation of the domain profile of the IMS QTI specification. These schemas are then used to validate the QTI-XML documents for the corresponding application profile. In each case the domain profile would be used by an appropriate system e.g., a SIF LMS (it is possible that a single LMS could in fact support both the SCORM and SIF domain profiles).

The advantage of the usage of XSDs is that an XML Stylesheet Transformation (XSLT) can be used to support the transformation between the XSDs; there would be one XSLT for each QTI transformation i.e., SIF-to-SCORM and SCORM-to-SIF.

The XSLT can be defined to handle the mapping of each element and attribute in the XSDs, including those defined in any extension - each domain profile must define the information model and XML binding for all extensions. In some cases it will not be possible to map some features from one domain profile to similar features in the other. In these cases there is a loss of functionality but this is a controlled situation in that the situations under which this loss occurs is well understood.

7.2 Conformance

'Domain Conformance' will not be defined with respect to an IMS specification. These specifications contain too many optional features and are subject to regional and sector specific amendments e.g., the inclusion of the appropriate vocabularies. Therefore, conformance will be against a particular Conformance Profile that has been derived from the corresponding Domain Profile. Conformance certification is considerably easier when all of the functionality is mandatory and so it is important for Conformance Profiles to remove as much optional functionality as possible.

7.2.1 First Generation Conformance

The key issue for conformance under the first-generation specifications is that they were not designed from the perspective of being testable i.e., exhaustive testing to show compliance is possible but not cost effective. The reason for this is that the specifications are designed to support practice and not to impose a best practice. This has produce specifications that a largely based upon optional features and so the derived conformance profiles can have many disjoint features. The current specifications are data models and so the associated behaviors are assumed in the information model and not defined in a behavioral model. Once again this leads to important discrepancies in the underlying assumptions used by different application profiles.

Each of the first-generation specifications contains a conformance statement. In most cases these statements are either a simple statement of the obvious i.e., the insistence that the information is followed or consists of a tick list of the features that are supposedly supported. In neither case is it possible to use the statements as a definitive guide to the compliance or otherwise of an implementation to the corresponding IMS specification.

7.2.2 Second Generation Conformance

An underlying objective in the creation of the second-generation specifications is the creation of specifications against which conformance can be clearly shown. This means that the second-generation specifications must:

• Minimize the number of optional elements and attributes. Whenever possible there should be no optional features - this implies that we are moving towards supporting a set of best practice recommendations;
• Whenever possible define the behaviors that are associated with the elements and attributes. These behavioral descriptions must reflect all the perspectives of the service being defined;
• When supporting an XML binding adopt as many as possible of the features of XSD to support extensive validation by the parsers e.g., the use of data typing. Many of the first-generation specification used DTDs and so only structural validation was possible;
• When defining the exchange messages ensure that different functionality is supported using different messages and that each message has no optional components, particularly in the body of the message;
• Be designed to ease the testing activities without compromising functional and performance effectiveness. This implies the usage of many XSDs as opposed to one single monolithic XSD.

Unlike the first-generation specification the second-generation ones will contain an extensive conformance specification that will form the basis for conformance against which the application profiles will build.

8. Bibliography

[ADL, 01a]	SCORM v1.2: The SCORM Overview, ADL, Version 1.2, October 2001.
[ADL, 01b]	SCORM v1.2: The SCORM Content Aggregation Model, ADL, Version 1.2, October 2001.
[ADL, 01c]	SCORM v1.2: The SCORM Run-time Environment, ADL, Version 1.2, October 2001.
[ADL, 02a]	SCORM v1.2: The SCORM Addendums, ADL, Version 2.0, January 2002.
[ADL, 02b]	SCORM v1.2: Conformance Requirements, ADL, Version 1.2, February 2002.
[CP, 03a]	IMS Content Packaging Information Model, T.Anderson, M.McKell, A.Cooper, W.Young, C.Moffatt and C.Smythe Version 1.1.3, IMS, May 2003.
[CP, 03b]	IMS Content Packaging XML Binding, T.Anderson, M.McKell, A.Cooper, W.Young, C.Moffatt and C.Smythe Version 1.1.3, IMS, May 2003.
[CP, 03c]	IMS Content Packaging Best Practice and Implementation Guide, T.Anderson, M.McKell, A.Cooper, W.Young, C.Moffatt and C.Smythe Version 1.1.3, IMS, May 2003.
[DRI, 03a]	IMS Digital Repositories Information Model, T.Barefoot, J.Mason and K.Riley Version 1.0, IMS, January 2003.
[DRI, 03b]	IMS Digital Repositories XML Binding, T.Barefoot, J.Mason and K.Riley Version 1.0, IMS, January 2003.
[DRI, 03c]	IMS Digital Repositories Best Practice and Implementation Guide, T.Barefoot, J.Mason and K.Riley Version 1.0, IMS, January 2003.
[ebXML, 01a]	ebXML Technical Architecture Specification, ebXML, Version 1.0.4, February 2001.
[ebXML, 01b]	ebXML Business Process Specification Schema, ebXML, Version 1.01, May 2001.
[ebXML, 01c]	Collaboration-Protocol Profile and Agreement Specification, ebXML, Version 1.0, May 2001.
[ebXML, 01d]	Message Service Specification ebXML Transport, Routing & Packaging, ebXML, Version 1.0, May 2001.
[ebXML, 01e]	ebXML Requirements Specification, ebXML, Version 1.06, May 2001.
[ebXML, 01f]	ebXML Registry Information Model, ebXML, Version 1.0, May 2001.
[ebXML, 01g]	ebXML Registry Services Specification, ebXML, Version 1.0, May 2001.
[eGIF, 02]	e-Government Schema Guidelines for XML, Version 3.0, Office of the e-Envoy, UK, December 2002.
[eGIF, 03a]	e-Government Interoperability Framework Part 1: Framework, Version 5.0, Office of the e-Envoy, UK, April 2003.
[eGIF, 03b]	e-Government Interoperability Framework Part 2: Technical Policies and Specifications, Version 5.0, Office of the e-Envoy, UK, April 2003.
[Ent, 02a]	IMS Enterprise Information Model V1.1 Final Specification, C.Smythe, G.Collier, C.Etesse and W.Veres, IMS Specification, July 2002.
[Ent, 02b]	IMS Enterprise XML Binding V1.1 Final Specification, C.Smythe, G.Collier, C.Etesse and W.Veres, IMS Specification, July 2002.
[Ent, 02c]	IMS Enterprise Best Practice & Implementation Guide V1.1 Final Specification, C.Smythe, G.Collier, C.Etesse and W.Veres, IMS Specification, July 2002.
[IEEE, 02]	IEEE P1484.1/D9 Draft Standard for Learning Technology: Learning Technology Systems Architecture (LTSA), IEEE LTSC Publication, Draft 9, 30th November 2002.
[IMS, 01a]	IMS Persistent Location-independent Resource Identifier Implementation Handbook, V1.0, M.McKell, IMS Specification, May 2001.
[IMS, 01b]	Using the IMS Content Packaging to Package Instances of LIP and Other IMS Specifications Implementation Handbook, V1.0, B.Olivier and M.McKell, IMS Specification, August 2001.
[IMS, 02a]	Minutes of the IMS System Components & Infrastructure Workshop: Cambridge USA 29th April - 1st May 2002, Colin Smythe, IMS, May 2002.
[IMS, 02b]	IMS Guidelines for Developing Accessible Learning Applications, Cathleen Barstow, Mark McKell, Madeleine Rothberg and Chris Schmidt, V1.0, IMS White Paper, June 2002.
[IMS, 03a]	IMS Abstract Framework: Glossary, Editor C.Smythe, IMS Publication, V1.0, July 2003.
[IMS, 03b]	IMS Abstract Framework: Applications, Services & Components, Editor C.Smythe, IMS Publication, V1.0, July 2003.
[LD, 03a]	IMS Learning Design Information & Behavioral Model, R.Koper, B.Olivier and T.Anderson Version 1.0, IMS, February 2003.
[LD, 03b]	IMS Learning Design XML Binding, R.Koper, B.Olivier and T.Anderson Version 1.0, IMS, February 2003
[LD, 03c]	IMS Learning Design Best Practice and Implementation Guide, R.Koper, B.Olivier and T.Anderson Version 1.0, IMS, February 2003
[LIP, 01a]