IMS Learner Information Packaging XML Binding Final Specification Version 1.0

Copyright © 2001 IMS Global Learning Consortium, Inc. All Rights Reserved.

The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name:IMS Learner Information Packaging Best Practice & Implementation Guide v1.0
Revision: 9 March 2001

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/profiles/lipv1p0/lipv1p0speclicense.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

  ABOUT THIS DOCUMENT
LIST OF CONTRIBUTORS
REVISION HISTORY

1.             Introduction

1.1           IMS Learner Information Specifications Overview
1.1.1       Requirements
1.1.2       Learner Information Data and Meta-data
1.1.3       Learner Data Structure
1.1.4       Learner Information Meta-data

1.2           Scope & Context

1.3           Structure of this Document

1.4           Nomenclature

1.5           References

2.             XML Basics

2.1           Elements
2.1.1       Element Contents
2.1.2       Element Attributes
2.1.3       Element Names

2.2           XML Schema

2.3           Document Type Definitions (DTD)
2.3.1       Declaring Element Contents
2.3.2       Declaring Element Attributes
2.3.3       Use of Attributes

2.4           XML Data Reduced (XDR)

2.5           Special Handling Requirements
2.5.1       XML Reserved Characters
2.5.2       White Space Handling

2.6           Extensibility

3.             Narrative Description of XML Binding

3.1           <learnerinformation> Elements
3.1.1       <comment>
3.1.2       <contentype>
3.1.3       <identification>
3.1.4       <goal>
3.1.5       <qcl>
3.1.6       <activity>
3.1.7       <competency>
3.1.8       <transcript>
3.1.9       <accessibility>
3.1.10     <interest>
3.1.11     <affiliation>
3.1.12     <securitykey>
3.1.13     <relationship>
3.1.14     <ext_learnerinfo>

3.2           <identification> Elements
3.2.1       <comment>
3.2.2       <contentype>
3.2.3       <formname> Elements
3.2.4       <name> Elements
3.2.5       <address> Elements
3.2.6       <contactinfo> Elements
3.2.7       <demographics> Elements
3.2.8       <agent> Elements
3.2.9       <ext_identification>

3.3           <goal> Elements
3.3.1       <typename>
3.3.2       <comment>
3.3.3       <contentype>
3.3.4       <date>
3.3.5       <priority>
3.3.6       <status>
3.3.7       <description>
3.3.8       <goal>
3.3.9       <ext_goal>

3.4           <qcl > Elements
3.4.1       <typename>
3.4.2       <comment>
3.4.3       <contentype>
3.4.4       <title>
3.4.5       <organization>
3.4.6       <registrationno>
3.4.7       <level> Elements
3.4.8       <date>
3.4.9       <description>
3.4.10     <ext_qcl>

3.5           <activity> Elements
3.5.1       <typename>
3.5.2       <comment>
3.5.3       <contentype>
3.5.4       <date>
3.5.5       <status>
3.5.6       <units> Elements
3.5.7       <learningactivityref> Elements
3.5.8       <definition> Elements
3.5.9       <product>
3.5.10     <testimonial> Elements
3.5.11     <evaluation> Elements
3.5.12     <description>
3.5.13     <ext_activity>

3.6           <competency> Elements
3.6.1       <comment>
3.6.2       <contentype>
3.6.3       <exrefrecord>
3.6.4       <description>
3.6.5       <ext_competency>

3.7           <transcript> Elements
3.7.1       <typename>
3.7.2       <comment>
3.7.3       <contentype>
3.7.4       <exrefrecord>
3.7.5       <description>
3.7.6       <ext_transcript>

3.8           <accessibility> Elements
3.8.1       <comment>
3.8.2       <contentype>
3.8.3       <language> Elements
3.8.4       <preference> Elements
3.8.5       <eligibility> Elements
3.8.6       <disability> Elements
3.8.7       <ext_accessibility>

3.9           <interest > Elements
3.9.1       <typename>
3.9.2       <comment>
3.9.3       <contentype>
3.9.4       <product>
3.9.5       <description>
3.9.6       <ext_interest>

3.10         <affiliation> Elements
3.10.1     <typename>
3.10.2     <comment>
3.10.3     <contentype>
3.10.4     <classification>
3.10.5     <affiliationid>
3.10.6     <role> Elements
3.10.7     <organization>
3.10.8     <date>
3.10.9     <status>
3.10.10  <description>
3.10.11  <affiliation>
3.10.12  <ext_affiliation>

3.11         <securitykey> Elements
3.11.1     <typename>
3.11.2     <comment>
3.11.3     <contentype>
3.11.4     <keyfields>
3.11.5     <description>
3.11.6     <ext_securitykey>

3.12         <relationship> Elements
3.12.1     <typename>
3.12.2     <comment>
3.12.3     <contentype>
3.12.4     <tuple> Elements
3.12.5     <description>
3.12.6     <ext_relationship>

3.13         Common Data Elements
3.13.1     <comment> Elements
3.13.2     <contentype> Elements
3.13.3     <description> Elements
3.13.4     <date> Elements
3.13.5     <priority> Elements
3.13.6     <status> Elements
3.13.7     <product> Elements
3.13.8     <typename> Elements
3.13.9     <fieldlabel> Elements
3.13.10  <fielddata> Elements
3.13.11  <media> Elements
3.13.12  <text> Elements
3.13.13  <organization> Elements
3.13.14  <exrefrecord> Elements
3.13.15  <sourcedid> Elements
3.13.16  <indexid> Elements

4.             Physical Realisation of the XML Binding

5.             Examples in XML

5.1           <identification>

5.2           <goal>

5.3           <qcl>  

5.4           <activity>

5.5           <competency>

5.6           <transcript>

5.7           <accessibility>

5.8           <interest>

5.9           <affiliation>

5.10         <securitykey>

5.11         <relationship>

Appendix A -LIP DTD (Uncommented)

Figures

  Figure 1.1  The IMS Learner Information Package (LIP) core data structures
Figure 3.1 <learnerinformation> elements
Figure 3.2  <identification> elements
Figure 3.3  <formname> elements
Figure 3.4  <name> elements
Figure 3.5  <address> elements
Figure 3.6  <street> elements
Figure 3.7  <contactinfo> elements
Figure 3.8  <demographics> elements
Figure 3.9 <agent> elements
Figure 3.10  <goal> elements
Figure 3.11  <qcl> elements
Figure 3.12  <activity> elements
Figure 3.13  <definition> elements
Figure 3.14  <testimonial> elements
Figure 3.15  <evaluation> elements
Figure 3.16  <competency> elements
Figure 3.17  <transcript> elements
Figure 3.18  <accessibility> elements
Figure 3.19  <language> elements
Figure 3.20  <preference> elements
Figure 3.21  <eligibility> elements
Figure 3.22  <disability> elements
Figure 3.23  <interest> elements
Figure 3.24  <affiliation> elements
Figure 3.25  <role> elements
Figure 3.26  <securitykey> elements
Figure 3.27  <relationship> elements
Figure 3.28  <contentype> elements
Figure 3.29  <description> elements
Figure 3.30  <date> elements
Figure 3.31  <status> elements
Figure 3.32  <product> elements
Figure 3.33  <typename> elements
Figure 3.34  <fieldlabel> elements
Figure 3.35  <organization> elements
Figure 3.36  <exrefrecord> elements
Figure 3.37  <sourcedid> elements
Figure 4.1  XML schema inclusion hierarchy

1.     Introduction

1.1     IMS Learner Information Specifications Overview

IMS Learner Information Package is based on a data model that describes those characteristics of a learner needed for the general purposes of:

• Recording and managing learning-related history, goals, and accomplishments;
• Engaging a learner in a learning experience;
• Discovering learning opportunities for learners.

The specification supports the exchange of learner information among learning management systems, human resource systems, student information systems, enterprise e-learning systems, knowledge management systems, resume repositories, and other systems used in the learning process. In this document such systems will be called learner information systems regardless of any other functionality they possess or roles they fulfil.  The IMS Learner Information Package specification does not address requests for learner information or the exchange transaction mechanism.

1.1.1       Requirements

IMS Learner Information specifications are designed to meet the following requirements:

• Distributed information: A learner information system may in fact consist of multiple distributed systems that share learner information or that store learner information in a distributed fashion.  This necessitates the inclusion of adequate indexing and time stamping of learner information data as it is packaged;
• Scalability: To support large-scale systems it is necessary to exchange and reassemble chunks of arbitrary granularity as well as bulk transfer.  Packaging of multiple LIPs will use the IMS Content &Packaging specification;
• Privacy and Data Protection: Learner information systems must be able to implement privacy and data protection policies and insure the integrity of data;
• Flexibility and External references: Learner information includes many constructs, such as learning objectives and learning history, which are in practice represented by different structures in different contexts.  Learner information data models must be flexible enough to accommodate this need.

Privacy and Data Protection

The IMS project recognizes the need to:

• Maintain the privacy of learner information;
• Protect information from inappropriate access;
• Ensure the integrity of information;
• Accommodate the regulatory policies and requirements of different jurisdictions.

IMS Learner Information Package enables the inclusion of mechanisms for maintaining privacy and protecting the integrity of data with all data that comprises learner information.  The specification cannot, however, specify the form, format, or type of these mechanisms or policies for their use. These must be determined by specific implementations in accordance with their requirements.

1.1.2       Learner Information Data and Meta-data

IMS Learner Information Package is a structured information model. An XML binding is included but is not meant to exclude other bindings.  The information model contains both data and meta-data about that data. The model defines fields into which the data can be placed and the type of data that may be put into these fields. Typical data might be the name of a learner, a course or training completed, a learning objective, a preference for a particular type of technology, and so on. Meta-data about each field can include:

• Time-related information; 
• Identification and indexing information;
• Privacy and data protection information.

This meta-data is available for each and every field in the information model, either directly or via inheritance.

1.1.3       Learner Data Structure

The learner information model can be viewed in three different ways:

• A tree;
• An object model;
• A tabular representation.

All three ways are explained in the specification.  The Learner information is separated into eleven main categories (as shown in Figure 1.1).  These structures have been identified as the primary data structures that are required to support learner information.  This composite approach means that only the required information needs to be packaged and stored.

Figure 1.1  The IMS Learner Information Package (LIP) core data structures.

• Identification: Biographic and demographic data relevant to learning;
• Goal: Learning, career and other objectives and aspirations;
• Qualifications, Certifications and Licenses (qcl): Qualifications, certifications and licenses granted by recognized authorities;
• Activity: Any learning-related activity in any state of completion.  Could be self-reported.  Includes formal and informal education, training, work experience, and military or civic service;
• Transcript:  A record that is used to provide an institutionally-based summary of academic achievement.  The structure of this record can take many forms;
• Interest: Information describing hobbies and recreational activities;
• Competency: Skills, knowledge, and abilities acquired in the cognitive, affective, and/or psychomotor domains; 
• Affiliation: Membership of professional organizations, etc.  Membership of groups is covered by the IMS Enterprise specification;
• Accessibility: General accessibility to the learner information as defined through language capabilities, disabilities, eligibilities and learning preferences including cognitive preferences (e.g. issues of learning style), physical preferences (e.g. a preference for large print), and technological preferences (e.g. a preference for a particular computer platform);
• Securitykey:  The set of passwords and security keys assigned to the learner for transactions with learner information systems and services;
• Relationship:  The set of relationships between the core components.  The core structures do not have within them identifiers that link to the core structures.  Instead all of these relationships are captured in a single core structure thereby making the links simpler to identify and manage.

These categories were chosen to meet the requirements of a large variety of use cases and to facilitate mapping among IMS and other relevant specifications.  Within each category several data elements and structures are defined.  Some of these are specified explicitly as data types (language strings, for the most part) and others are defined as recursive hierarchical structures.  In addition, data may be defined by referencing mechanisms. The referencing mechanisms supported are internal references, references to an external learner information system, and references via a URI.

1.1.4       Learner Information Meta-data

The learning information meta-data (contained within the ‘contentype’ structure shown in Figure 1.1) is broken into four categories:

• Time Information: Time of creation and time of expiration of a piece of data;
• Index and Source: Supports a pair consisting of a source and an ID assigned by that source, a local index that is used for cross-referencing, and a URI;
• Privacy and data protection information: Unstructured data to be determined by practice and implementation.

All learning information data elements have meta-data sub-elements with the exception of atomic elements that can always inherit their meta-data. For example, in the Identification category, meta-data is associated with the Name element but not with its constituent elements since it is felt that the meta-data for the constituent elements cannot change independently of the meta-data for the Name element itself.

1.2     Scope & Context

The IMS Learner Information Package (LIP) XML Binding describes the XML Schema binding of the LIP Information Model.  A Document Type Definition (DTD) representation is also included for the binding but this is not formally supported.  Version 1.0 of the eXtensible Markup Language (XML) specification of the World Wide Web Consortium (W3C) is used.

This binding has been derived from the agreed IMS Learner Information Package Information Model specification [LIP, 01b] and conforms to the XML Version 1.0 specification [XML, 98] of the W3C.

1.3     Structure of this Document

The structure of this document is:

valign=top> 2.     XML Basics	valign=top> A brief description of the components within an XML schema;
valign=top> 3.     Narrative Description of the XML Binding	valign=top> The XML Schema used to describe the Learner Information;
valign=top> 4.     Physical Realisation of the XML Binding	valign=top> The manner in which the XML binding is realised as a series of separated but related XSD files;
valign=top> 5.     Example XML Schema	valign=top> Examples of the XML schema as applied to typical learner information interchange;
valign=top> Appendix A - LIP DTD (Uncommented)	valign=top> A copy of the uncommented DTD (this is informative only and is not a formally supported binding).

1.4     Nomenclature

 

ANSI	American National Standards Institute
CDATA	Character Data
DTD	Document Type Definition
EDI	Electronic Data Interchange
FE	Further Education
GUI	Graphical User Interface
HE	Higher Education
HRMS	Human Resource Management System
IEEE	Institute of Electronic & Electrical Engineers
JPEG	Joint Photographic Expert Group
LIP	Learner Information Packaging
LLL	Life-long Learning
LTSC	Learning Technology Standards Committee
NVC	National Validation Center
PAPI	Public & Private Information
PCDATA	Parsed Character Data
QTI	Question & Test Interoperability
SIF	Schools Interoperability Framework
UCAS	University Council for Admissions Services
UML	Unified Modelling Language
URI	Universal Resource Identifier
W3C	World Wide Web Consortium
XDR	XML Data Reduced
XML	Extensible Mark-up Language
XSD	XML Schema

1.5     References

[ANSI, 98]             Student Educational Record (Transcript), ANSI ASC X.12-TS130, ANSI, April 1998.

[CP, 00a]                IMS Content Packaging Information Model, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[CP, 00b]                IMS Content Packaging XML Binding, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[CP, 00c]                IMS Content Packaging Best Practice and Implementation Guide, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[Enterprise, 99a]   IMS Enterprise Information Model, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Enterprise, 99b]   IMS Enterprise XML Binding, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Enterprise, 99c]   IMS Enterprise Best Practice and Implementation Guide, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Gestalt, 00]           Gestalt: WP4 - Integrating IMS Enterprise, PAPI and Gestalt UOM Data Models, version 3.0, P.Foster, Gestalt Doc No: FC:/MAN/REPORTS/022GESTALT/D401/GestaltEnterprisePAPI_3, March 2000.

[Gestalt, 99]           Gestalt: WP5 - Object (Interfaces) Specification, V.Wade, K.Riley, B.Banks, P.Foster, N.Evans-Mudie, Y.Nicol, P.Doherty, Gestalt Doc No: A367/TCD/WP05/DS/L/008/b1, October 1999.

[HR, 00a]                Resume DTD, HR-XML Consortium, June 2000, http://www.hr-xml.org/.

[HR, 00b]               Candidate DTD, HR-XML Consortium, June 2000, http://www.hr-xml.org/.

[LIP, 00a]               Profiles Interchange Requirement Specification, G.Collier, T.Probart and C.Smythe, Version 1.0, IMS, March 2000.

[LIP, 01b]               IMS Learner Information Package Information Model Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

[LIP, 01c]               IMS Learner Information Packaging Best Practices & Implementation Guide Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

[MD, 99a]              IMS Meta-data Information Model, T.Wason, Version 1.0, IMS, September 1999.

[MD, 99b]              IMS Meta-data XML Binding, T.Wason, Version 1.0, IMS, September 1999.

[MD, 99c]              IMS Meta-data Best Practice and Implementation Guide, T.Wason, Version 1.0, IMS, September 1999.

[Messaging, 99]   Proposal for the Inclusion of a Run Time Messaging Service in the IMS 1.0 Specifications, Ken Schweller, IMS, May 1999.

[PAPI, 98]              IEEE PAPI Specification - Learning Technology: Public and Private Information, Version 6.0, IEEE LTSC P1484, June 2000.

[QTI, 01]                IMS Question & Test Interoperability: ASI Information Model, C.Smythe and E.Shepherd, Version 1.1, IMS, March 2001.

[Saba, 00]               Profile Format: Design Specification, Daniel Lipkin, Saba Inc, May 2000. 

[SIF, 99]                 Schools Interoperability Framework Preliminary Implementation Specifications, Version 1.0, SIF, November 1999.

[vCard, 98]             The vCard v3.0 XML DTD, F.Dawson, IETF Draft, June 1998.

[XML, 98]              XML Version 1.0 Specification of the W3C, http://www.w3.org./TR/1998/REC-xml-19980210, World Wide Web Consortium, 1998.

2.     XML Basics

The Learner Information Packaging data model has been defined as a hierarchy.  Hierarchical models are convenient for representing data consisting of many elements and sub-elements. XML is perfectly suited for representing hierarchical models. An XML document is a hierarchy comprised of elements that have contents and attributes.

2.1     Elements

An element is a component of a document that has been identified in a way a computer can understand. Each element has a tag name. When a tag name is shown as

 “<TAGNAME>”

“</TAGNAME>”

<TAGNAME>contents</TAGNAME>

2.1.1       Element Contents

An element may contain other elements, Parsed Character Data (PCDATA), Character Data (CDATA), or a mixture of PCDATA and elements. The allowable contents of an element are its content model. PCDATA really means any character string that does not contain elements. PCDATA is what the bulk of elements will use between their start and end-tags.  CDATA is different in that it is a method for adding any character data that should not be processed. For example, you could add some Java script code instructions using a CDATA section. A CDATA section tells the parser not to look for any markup until after it locates the end of the CDATA section.

2.1.2       Element Attributes

An attribute provides additional information about an element. Attributes are a way of attaching characteristics or properties to the elements of a document. An element may have more than one attribute and they are contained within the start tag of an element. Attributes are represented by an attribute name followed by an equal sign and the attribute value in quotation marks:

<timeframe>

            <begin restrict=”1”>1999-07-23</begin>

</timeframe>

In this example the <timeframe> element contains another element, the <begin> element. The <begin> element has one attribute “restrict”, with the value 1. The value for the element <begin> is  “1999-07-23”. These two elements then make up a ‘timeframe begin’ date.

2.1.3       Element Names

Each element has a unique name, referred to as the tag name.  XML is case-sensitive in its processing of tag names. The IMS Learner Information Package XML binding adheres to the following tag name rules:

All tag names will
conform to the rules for element naming as given within the XML Version 1.0
specification;


Names beginning in “xml”
in any case or mix of cases are not permitted;


All element and
attribute names in the IMS XML binding are aligned with the W3C XHTML standard
and as such will be lower-case;


Element names may not include words reserved by the
XML specification. These include:

DOCTYPE

ELEMENT

ATTLIST

ENTITY


Tag names defined by the
IMS binding may not be redefined, with the exception of those that are used for
extensions.

2.2     XML Schema

The LIP version 1.0 XML binding is defined in an XML-Schema.  XML-Schema is the primary XML binding control document format of IMS.  The XML-Schema defines elements, their content models, and attributes.  It also defines the standard IMS vocabularies.  The XML-Schema defines the element types and attribute groups separately from the elements.  This serves three purposes:

• The element names are declared before the type definitions to prevent any declaration confusions by XML-Schema validators.  This is analogous to declaring sub-routine and function names separately at the top of a program unit;
• The complexTypes may be managed more effectively, including support for derived types in the near future.  Derivation will be used for harmonization and extension;
• The attributes may be managed more effectively, particularly when the same attributes are used by several elements’ complexTypes.

The XML Schema for the IMS LIP is named: ims_lip_rootv1p0.xsd.

2.3     Document Type Definitions (DTD)

The tag name, content model, and attributes of elements are defined in a Document Type Definition (DTD) statement.  These may exist as an external file or a block of text internal to an XML document. Internal DTDs are used to override elements defined in external DTD files, so an internal DTD should be used with care. The DTD defines the elements that may be used, and may define the contents of the elements.

Some XML editors may make use of a DTD to help guide the developer in creating the proper elements at the proper locations in an XML file. Other developers will make use of the DTDs to validate their XML documents to ensure their document is consistent with all of the element names and locations defined in the DTD. An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it. Details of the construction of DTDs are outside the scope of this document, but links to the XML Version 1.0 specification are included in the References (sub-section 1.5) of this document.

The DTD for the IMS LIP is named: ims_lipv1p0.dtd

2.3.1       Declaring Element Contents

The information specifying the order and usage of allowable contents for an element are its content model. The content model is declared in a DTD (see below). The declaration of the content model is of the general form:

<!ELEMENT tagname (ContentModel)>

The SHORT element can again serve as an example of how an element is declared with its content model:

<!ELEMENT  short (#PCDATA)>

This element will contain character data (#PCDATA) that can be processed. The XML Specification provides more information about the details for creating and interpreting content models.

2.3.2       Declaring Element Attributes

An example of how the attributes for the element <learnerinformation>is declared in a DTD is found below:

<!ELEMENT learnerinformation (sourcedid, goal?, transcript?, qcl?)>

<!ATTLIST learnerinformation type CDATA #IMPLIED>

The first line declares that there is an element named <learnerinformation> that must have the <sourcedid> element and is additionally allowed to have <goal> and/or <transcript> and/or <qcl> elements as its contents. The second line begins with “!ATTLIST” to start an attribute list declaration for the <learnerinformation> element. The word ‘type’ will serve as the attribute’s name. The allowable value for this attribute must be of type CDATA.

At the end of the example above is the term IMPLIED. It is at this location in the attribute declaration, where a default value for an attribute may be specified. It is also possible to use the keyword REQUIRED which would force a TYPE value to be supplied and there would be no default value. In the example above, the IMPLIED designation means that the designer wants to allow users to omit the value for the attribute without forcing a particular default value.

2.3.3       Use of Attributes

Within the IMS XML binding, the use of attributes is reserved for information about the structure of the structure of the relevant data object.

Lists

A list is a repetition of the contents of an element.  In XML, this is accomplished by repeating the containing element: for example, the <learnerinformation> element contains an element <affiliation>. Described in the DTD as:

<!ELEMENT learnerinformation (affiliation*)>

When instantiated in XML a repeating list of ITEM elements would appear:

<learnerinformation>

            <affiliation> “The first affiliation.”</affiliation>

            <affiliation> “The secondaffiliation.”</affiliation>

</learnerinformation>

In this example, the element <affiliation>is repeated. Thus <affiliation> is the containing element for the repeated contents descriptions. The notation for repetitions of an element in a content model follows the XML specification. An asterisk (*) specifies that none or more repetitions of the element may be included in the XML instantiation.

2.4     XML Data Reduced (XDR)

A schema is a formal specification of element names that indicates which elements are allowed in an XML document, and in which combinations. New schema languages, such as those defined in the XML-Schemas Working Group, provide the same baseline functionality as a DTD.  However, because these schema languages are extensible, developers can augment them with additional information, such as data types, inheritance and presentation rules. This makes these new schema languages far more powerful than DTDs.  For more information about XML schemas, go to http://www.w3.org/XML/Group/Schemas.html.

This specification includes an XML Data Reduced (XDR). Some XML editors may make use of such a schema to help guide the developer in creating the proper elements at the proper locations in an XML file.  Other developers will make use of the schema to validate their XML documents and/or to define extensions to the IMS LIP specification. Details of the construction of XDRs are outside the scope of this document.

2.5     Special Handling Requirements

2.5.1       XML Reserved Characters

Some characters used in XML must be escaped when used outside of their XML defined usage as found in Section 2.4 of the XML 1.0 Specification. These characters are ampersand (&), less than (<), greater than (>), apostrophe(‘) and the double-quotes character(“).  These characters may be represented using either numeric character references or the strings “,&amp;”, “&lt;”, “&gt;”, “&apos;”, and “&quot;”.  Below is a more complete quote from the W3C XML specification:

Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10-February-1998
2.4 Character Data and Markup

 Text consists of intermingled character data and markup. Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comments, CDATA section delimiters, document type declarations, and processing instructions.

All text that is not markup constitutes the character data of the document.

The ampersand character (&) and the left angle bracket(<) may appear in their literal form only when used as markup delimiters or within a comment, a processing instruction or a CDATA section. They are also legal within the literal entity value of an internal entity declaration; see “4.3.2 Well-Formed Parsed Entities”. If they are needed elsewhere, they must be escaped using either numeric character references or the strings “&amp;” and “&lt;” respectively. The right angle bracket (>) may be represented using the string “&gt;” and must, for compatibility, be escaped using “&gt;” or a character reference when it appears in the string “]]>” in content, when that string is not marking the end of a CDATA section.

In the content of elements, character data is any string of characters which does not contain the start­delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA‑section‑close delimiter, “]]>”.

To allow attribute values to contain both single and double quotes, the apostrophe or single‑quote character (') may be represented as "&apos;", and the double‑quote character (") as “&quot;”.

2.5.2       White Space Handling

Questions arise as to whether web‑based data transmission tools might inadvertently strip off or transform some of the white space characters embedded in the LIP data transmitted between systems using XML. To eliminate concern about this issue, refer to the following quote from the W3C XML standards, which indicate that all white space must be preserved where it is part of the data.

Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10‑February‑1998
2.10 White Space Handling

In editing XML documents, it is often convenient to use “white space” (spaces, tabs, and blank lines, denoted by the nonterminal S in this specification) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, “significant” white space that should be preserved in the delivered version is common, for example in poetry and source code.

An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content.

A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, must be declared if it is used. When declared, it must be given as an enumerated type whose only possible values are “default” and “preserve”. For example:

<!ATTLIST poem xml:space (default | preserve)'preserve'>

The value “default” signals that applications’ default white‑space processing modes are acceptable for this element; the value “preserve” indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute.

2.6     Extensibility

Some providers will find the current element set defined in the Profiles Interoperability specification too restrictive to accomplish their purposes. To ensure extensibility, the specification requires that there be no limit on potential extensions on major elements. An extension is the addition of information to an existing XML structure.

<!ELEMENT ext_qcl ANY> 

An example of the inclusion of <extension> in the content model of element <qcl> is:

<!ELEMENT qcl (title, registrationno, description, ext_qcl?)>

The use of the <extension> element is illustrated as follows:

<qcl>

<title> .. </title>

<registrationno> .. </registrationno>

<description> Text entry selections</description> 

<ext_qcl> 

                  <comments>This is a test to demo extensions</comments> 

</ext_qcl>

</qcl>

The contents, but not a content model, of an extension must be declared in an internal or external Schema. Many extensions can be created through the use of existing elements. Care must be used with internal Schemas, as they override external Schemas declarations. The content of an extension must obey the attribute and content models of the elements employed. New elements that duplicate the definitions of existing elements should not be introduced.

Prefacing the <ext_qcl> element with an appropriate namespace may reference descriptions of extensions. For example, a group such as the Advanced Distributed Learning (ADL) initiative may wish to add the “adl” prefix to an extension element to uniquely identify ADL extensions. The following is an example of this:

<qcl>

            .. mandatory elements of item elements here 

<description lang= " en " >

                  <short>Military profile</short> 

</description> 

<ext_qcl adl:classification="Not classified" adl:title="Psychometric question">This example discusses how the psychometric profiles are constructed for defence posts.

</ext_qcl>

</qcl>

This serves to note the entire extension structure. Extensions should always be added at the lowest point (farthest from the root element) in the hierarchy possible, to the degree that the structure defines the meaning of the extension.

3.     Narrative Description of XML Binding

This specification defines the XML format using narrative.  XML XSDs and XML DTDs that implement this ‘abstract’ format are provided as informative parts of this specification.

3.1     <learnerinformation> Elements

Description:  The <learnerinformation> element is the outermost container for the learner information i.e. it is the Learner Information Package. This information can be about an individual or an organisation.  Multiple transactions on the same learner information record can be exchanged but these must use separate XML instances of the LIP.

Figure 3.1  <learnerinformation> elements.

Multiplicity:  The <learnerinformation> occurs only once in each XML instance file that is used to support Learner Information Package.

Attributes:

 

<formname>

   <typename>

       <tysource sourcetype="imsdefault"/>

       <tyvalue>Preferred</tyvalue>

   </typename>

   <contentype>

       <referential>

          <indexid>formname_01</indexid>

       </referential>

   </contentype>

   <text>Bob
Dylan</text>

</formname>

 

<name>

   <typename>

       <tysource sourcetype="imsdefault"/>

       <tyvalue>Preferred</tyvalue>

   </typename>   

   <contentype>

       <referential>

          <indexid>name_01</indexid>

       </referential>

   </contentype>

   <partname>

       <typename>

          <tysource sourcetype="imsdefault"/>

          <tyvalue>First</tyvalue>

       </typename>

       <text>Bob</text>

   </partname>

   <partname>

       <typename>

          <tysource sourcetype="imsdefault"/>

          <tyvalue>Last</tyvalue>

       </typename>

       <text>Dylan</text>

   </partname>

<name>

<address>

   <typename>

       <tysource sourcetype="imsdefault"/>

       <tyvalue>Mailing</tyvalue>

   </typename>

   <contentype>

       <referential>

          <indexid>address_01</indexid>

       </referential>

   </contentype>

   <locality>Burlington</locality>

   <city>Delaware</city>

   <statepr>Massachusetts</statepr>

   <region>North East</region>

   <country>USA</country>

   <postcode></postcode>MA01803

   <timezone>EDT</timezone>

   <geo>

       <lat>90:25:59</lat>

       <lon>270:30:27</lon>

   </geo>

</address>

 

<street>

   <nonfieldedstreetaddress>34 St.Pauls Road</nonfieldedstreetaddress>

   <streetnumber>34</streetnumber>

   <streetprefix>St.</streetprefix>

   <streetname>Pauls</streetname>

   <streetype<Road</streetype>

</street>