Business Rules, Best Practices and Examples for

Army SCORM v1.2 Compliant Courseware

Rule titles are hyperlinked to the rule text in this document. Word users note that the web toolbar icons (available from the View menubar item above) contain a “back button” that supports returning to this page.

The icon denotes rules and topics that have associated animations. To test that your browser has the necessary software to view the animations, please click here. Clicking on the icon will hyperlink to an animation.

Section Title	Sub-Section Title	Business Rule #	Business Rules
Executive Summary	Target Audience		Introduction to this document
Content Design	All About SCOs
		3.1.1-1	Definition of a SCO
		3.1.2-1	Independent SCO
		3.1.2-2	Dependent SCO
		3.1.2-3	Independent SCO Restrictions
		3.1.3-1	SCO Golden Rules
		3.1.4-1	Use of SCO Acronym
		3.1.5-1	Size of SCOs
		3.1.6-1	SCO Title Location/Display
		3.1.6-2	SCO Title Consistency
		3.1.6-3	SCO Title Restrictions
		3.1.7-1	Location of SCO Files
	Aggregations	3.2-1	XML Tagging of an Aggregation
	Definition of a Course
	Course Title	3.4-1	XML Tagging of the Course Title
	Course Title	3.4-2	Course Title Restrictions
	File Naming Conventions	3.5-1	File and Folder Naming Conventions
		3.5-2	Prohibited Special Characters
		3.5-3	File Naming Convention for Internal GFI Files
		3.5-4	File Naming Convention for External GFI Files
	Navigation	3.6.1-1	Navigation Help
		3.6.2-1	Intra SCO Navigation Requirements
		3.6.3-1	Closing a SCO
	Table of Contents	3.7-1	XML Tagging of Table of Contents
	Course Map	3.10-1	Course Map and Independent SCOs
	Course Map	3.10-2	Course Map Hyperlink Restrictions
	Launchable Assets	3.11-1	Launchable Asset Restrictions
	Designing for Reusability	3.12-1	Reusability of Independent SCOs
	Designing for Reusability	3.12-2	Exclusion of Transitional Statements in Independent SCOs
Communication with the LMS	Introduction	4-1	SCO Adherence to SCORM Run-Time Environment
	LMSInitialize	4.1-1	Initial Communication with LMS
	LMSFinish	4.2-1	Terminal Communication with LMS
	LMSFinish	4.2-2	Closing the Browser Window
	Data Transfer	4.3.1-1	Retrieving Data from the LMS
		4.3.2-1	Writing Data to the LMS
		4.3.3-1	Persisting Data to the LMS
	State Management	4.4.1-1	LMS Communication Errors
	SCORM Data Model	4.6.1-1	SCO Bookmarking
		4.6.3-1	Setting Lesson Status
		4.6.3-2	Student Performance Test (Failure)
		4.6.3-3	Re-entry of a Completed SCO
		4.6.3-4	Student Performance Test (Success)
		4.6.4-1	Storing of Student Score
		4.6.5-1	Location of Mastery Score
		4.6.5-2	Programming Restriction of Mastery Score
		4.6.6-1	Exiting a SCO
		4.6.7-1	SCO Session Time
		4.6.8-1	Calculation for a Timed SCO
		4.6.9-1	XML Tagging for Maximum Time Allowed in a SCO
		4.6.12-1	Test Item Data for Question Type
		4.6.13-1	Test Item Data for Student Response Patterns
		4.6.14-1	Test Item Data for Student's Response to Individual Test Items
		4.6.15-1	Test Item Data for Evaluation of Student's Response
		4.6.16-1	Test Item Data for Weighted Test Items
		4.6.17-1	Test Item Data for Timed Test Items
		4.6.18-1	Timestamp for “Timed” Test Items
Meta-Data	Army Meta-Data Requirements	6-1	Meta-Data Requirements for Courseware
Meta-Data	XML Binding for Separate Meta-Data Files	6.3-1	XML Binding for Separate Meta-Data Files
Meta-Data (cont)	Recognizing the 4 Different types of Meta-Data	6.4.2-1	Content Aggregation Meta-Data Requirement
	Recognizing the 4 Different types of Meta-Data	6.4.3-1	SCO Meta-Data Requirement
	Developing SCORM Meta-Data	6.5.1-1	Meta-Data Requirement for Title
		6.5.2-1	Meta-Data Requirement for Catalog Entry
		6.5.3-1	Meta-Data Requirement for Description
		6.5.4-1	Meta-Data Requirement for Keywords
		6.5.5-1	Meta-Data Requirement for Aggregation Level
		6.5.6-1	Meta-Data Requirement for Version Number
		6.5.7-1	Meta-Data Requirement for Submittal Status
		6.5.8-1	Meta-Data Requirement for Contributor Role
		6.5.9-1	Meta-Data Requirement for vcard of Contributor
		6.5.10-1	Meta-Data Requirement for Submittal Date
		6.5.11-1	Meta-Data Requirement for Meta-Data Specification
		6.5.12-1	Meta-Data Requirement for MIME Types
		6.5.13-1	Meta-Data Requirement for Resource Location
		6.5.14-1	Meta-Data Requirement for Resource Cost
		6.5.15-1	Meta-Data Requirement for Copyrights
		6.5.16-1	Meta-Data Requirement for Classification System
Packaging	Introduction	7-1	SCORM Package Requirements
	Introduction	7.4	How to create a Content Package
	Creating the Manifest File	7.5-1	Mandatory Manifest File Requirement
	Creating the Manifest File	7.5.1-1	Content Aggregation Manifest File
Courseware Delivery	PIF (Package Interchange File)	9.1-1	PIF Manifest File Location
		9.1-2	Delivery Format for SCORM Compliant Courseware
		9.1-3	Files Excluded from PIF

1 Executive Summary

Target Audience: This document is intended for use by personnel (both government and contractor) involved in the design, development, and programming of all Sharable Content Object Reference Model (SCORM) v1.2 compliant Army Distributed Learning (ADL) Courseware. The Business Rules and Best Practices contained in this document are based on lessons learned from the testing of SCORM compliant courseware since September 2002. At the Proponent agency, Instructional Systems Specialists (ISS) preparing Statements of Work (SOW) and/or overseeing contract development of Distributed Learning (DL) courseware must be familiar with this document. Instructional Designers and programmers from contractors and/or proponent agencies designing and developing DL courseware must thoroughly understand this document.

These Business Rules and Best Practices apply to any Army courseware that will be served on the Interim Learning Management System (ILMS) or the Army Learning Management System (ALMS). All Business Rules must be adhered to when developing above referenced courseware.

SCORM Version: All references to SCORM will be for version "1.2" issued in October, 2001 and specifications obtained from ADL (http://www.adlnet.org/). Specification documents referenced are the following: 1) SCORM v1.2 Content Aggregation Model (CAM) document dated October 1, 2001; 2) SCORM v1.2 Run-Time Environment (RTE) document dated October 1, 2001.

Notations Used: The following notations are used throughout the document and explained below:

· Reel icon: Graphic link to a vignette that explains an Army or SCORM business rule.

· BUSINESS RULE (SCORM): A mandatory requirement to meet minimal SCORM conformance. Comments concerning these rules must be submitted to ADL.

· BUSINESS RULE (ARMY): An Army mandatory requirement for implementing the SCORM specification.

· Best Practice: Recommended SCORM practice for what works best based on lessons learned. Alternative approaches are acceptable as long as they comply with SCORM and Army SCORM requirements and can be implemented in the Learning Management System (LMS) appropriate for the course.

· For the ILMS: When implementation is different for the Army’s Interim LMS (ILMS) than for the ALMS.

· For the ALMS: When implementation is different for the ALMS than for the ILMS.

· CAM: References the SCORM Content Aggregation Model document dated October 1, 2001

· RTE: References the SCORM Run-Time Environment document dated October 1, 2001

This document provides Business Rules, Best Practices, definitions, explanations and sample code for developing SCORM v1.2 conformant courseware produced under the ADL Program. The Business Rules (whether designated SCORM or Army) are mandatory requirements for Army SCORM courseware. To promote interoperability and courseware consistency, the Best Practices defined in this document should be used to the maximum extent possible.

The SCORM has been adopted as the standard for DL courseware and introduces a paradigm shift regarding courseware design. A SCORM course could be mapped to an Army course, phase, or module. A "course" is no longer an interrelated set of context specific learning instruction. Its meaning, as previously understood, has changed. Within SCORM, a course contains reusable, independent learning objects that are described by searchable meta-data. Careful design work still has to be done in accordance with (IAW) Training and Doctrine Command (TRADOC) Regulation (TR) 350-70 requirements. See Student Performance Tests Section.

This document is not intended as a primer on SCORM, and the reader needs a basic understanding of the SCORM specification (http://www.adlnet.org). For SCORM training, see the Tutorials Section.

In order to effectively use this document, one must consider the following during the front end analysis:

· Determine which LMS (ILMS or ALMS) your course will be fielded under

· Determine Testing Strategy

· Determine Size of Sharable Content Objects (SCO)s

· Determine Packaging

The latest Distributed Learning XXI (DLXXI) SOW Template (http://www.atsc.army.mil/itsd/imi/DLXXIContractDocs.asp) must be used for DL contracts, because it incorporates specific rules for SCORM in the development of Army courseware. Compliance with the standards and specifications in this template are required for all The Army Distributed Learning Program (TADLP) courseware and are highly recommended for all other Army DL courseware designed to play on the Army's ILMS or the ALMS. According to this template, contract deliverables will be developed according to SCORM specifications and, in addition, contain certain SCORM run-time (Communication with the LMS Section) and meta-data elements (Meta-data Section) that are SCORM optional but required by the Army.

Changes to this document are anticipated to coincide with updates to the SCORM specification as well as through identification of additional lessons learned. Document updates are scheduled annually to coincide with the U.S. Army Training Support Center (ATSC) Technical Change Control Board normally conducted in May of each year.

For SCORM technical support or to submit comments or suggestions for this document, send an e-mail to SCORM@atsc.army.mil or call 757-878-3508 (DSN 826-3508). For accessing courseware on the Army's developmental Aspen server, send email to DevCrsWare@atsc.army.mil.

2 Terms and Definitions

Here is a list of Terms and Definitions you should know before reading this document:

Acronyms/Terms	Definitions
ADL	Advanced Distributed Learning. The ADL Initiative, sponsored by the Office of the Secretary of Defense (OSD), is a collaborative effort between government, industry and academia to establish a new distributed learning environment that permits the interoperability of learning tools and course content on a global scale. (http://www.adlnet.org/). ADL has developed the SCORM.
ALMS	Army Learning Management System; specifically Saba Learning Management System which has been customized for the Army.
API	Application Programming Interface
ASI	Additional Skill Identifier
ATRRS	Army Training Requirements and Resources System. Legacy system that tracks quota and non-quota managed training
ATSC	Army Training Support Center
Asset	An asset is the smallest, atomic, meaningful learning content object used to develop Web-based IMI training to include the raw media (separate and distinct instructional text, audio, video, graphic, animation, etc.) used to create a Sharable Content Object (SCO). Also referred to as a "resource".
Block	A term used in a previous SCORM standard (SCORM v1.1) which maps to a Content Aggregation in SCORM v1.2.
CAM	Content Aggregation Model
CBT	Computer-based Training
COL	Check on Learning
Content Aggregation	A collection of SCOs.
Content SCO	A SCO that does not contain a graded assessment
Context-specific	Specific to the context of a particular structure or situation.
DL	Distributed Learning
Dependent	Relying on another for support, aid; etc; Determined or conditioned by another.
Dependent SCO	A SCO that is "not independent" and is context-specific and does not have a high degree of reusability (e.g., an Introduction SCO for a module or group of lessons). A SCO that pertains to the particular course structure.
DOM	Document Object Model
ELO	Enabling Learning Objective
Embedded Student Performance Test	A graded assessment contained in the same SCO as instructional content
External References	Content that the Student is not tested. Documents that would invite further study, research or information on the subject matter.
GFI	Government Furnished Information
Graded Assessment	The act of evaluation resulting in a score or grade
Granularity	"Becoming granular" or "showing a granulated structure". SCORM recommends "small particles" by reducing the size of learning objects for reusability and enhancing the learning experience.
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Protocol
ILMS	Interim Learning Management System. Presently the TRADOC Educational Data System – Redesign (TREDS-R) System with a back-end SCORM conformant Aspen LMS. Aspen serves up the IMI courseware and posts the student data to TREDS-R.
IMDP	Instructional Media Design Package
IMI	Interactive Multimedia Instruction
imsmanifest.xml	An xml file that is stored in the root of a content package that describes the entire package.
Independent SCO	A SCO that teaches a complete learning thought. An independent SCO must not be dependent on any other instructional content, must be "context independent" and must "stand alone".
Instructional Content	Content that teaches; Content that is germane to the Course.
Instructional Content Package	A SCORM package that contains the instructional content SCOs and other SCOs where a score is not emphasized but whether or not the Student "completed" the instruction. This indicates that a score is not rolled up to the ILMS/ALMS. See Student Performance Test Content Package.
Learning Content	Content that teaches; Also referred to as Instructional Content.
Learning steps	A Student activity that leads toward achievement of a learning objective. Learning steps are determined when the objective is broken down into its component parts. Often an explicit hierarchical relationship consisting of a terminal learning objective, an enabling learning objective, and learning step.
LOM	Learning Object Metadata. The root element or the beginning of the SCORM meta-data XML record, i.e. <lom>.
LMS	Learning Management System. Any SCORM conformant LMS.
Manifest	A common name that refers to the imsmanifest.xml file. This xml file is stored in the root of a SCORM content package and describes the entire package.
Menu	The list of available topics or available branching within a SCO. It is not the same as the Table of Contents.
Meta-data	Data about the resources contained in web-based courseware; used for searching.
MIME	Multipurpose Internet Mail Extensions
MOS	Military Occupational Specialty
Non-Instructional Content	Content that does not teach, but may inform, direct, explain, or provide understanding.
Objective Definitions Page	A page within the SCO that displays the Learning Objectives Actions, Conditions, and Standards.
Offline Player	An application that plays SCORM conformant courseware outside of a SCORM conformant LMS.
Pam(s)	Pamphlet(s)
PIF	Package Interchange File. This file is a representation of the content package components using the PKZIP Version 2.04g archive format (zip).
POI	Program of Instruction
Reach-Back	Reach-Back is a term used to indicate that the Student reaches back into or re-accesses the instructional content after the Student has completed a graded assessment.
Reg(s)	Regulation(s)
Repository	A data storage warehouse
Resource(s)	Files required for the courseware to play. These files can consist of HTML, Flash, graphics, audio, or video files. All these files are considered "assets".
Rollup	A single result from many. For example, a rollup of scores is an average. A rollup of lesson status is “complete” only when each and every SCO status is “complete". In other words, one “incomplete" status of a SCO makes the lesson status is "incomplete".
RTE	Run-Time Environment
Schema	Programming rules and allowable XML tags that apply to XML files.
SCO	Sharable Content Object. A SCO must reference one or more assets that include a specific launchable asset that utilizes the SCORM Run-Time Environment (RTE) to communicate with LMSs. A SCO must be independent of context and be able to "stand alone" when extracted from the package for reuse.
SCORM	Sharable Content Object Reference Model
SOW	Statement of Work
SQI	Skill Qualification Identifier
Student Performance Test	Any graded assessment of Student performance such as a Pretest or Post test.
Student Performance Test Content Package	A SCORM content package that contains one or more SCOs containing graded assessments, which abide by the restrictions of a Student performance test package per the ILMS or ALMS. The results of each package are rolled up and sent from the ILMS/ALMS to ATRRS.
Suspend	Describing the Student's action of exiting out of the SCO anywhere before the last page, therefore, not completing the SCO.
TRADOC	Training and Doctrine Command
TREDS-R	TRADOC Educational Data System – Redesign
TSP	Training Support Package
TLO	Terminal Learning Objective
TOC	Table of Contents. The main list of available instructional content for a course, phase or module.
URL	Uniform Resource Locator
vCard	vCard. The generic term for an electronic, virtual information card that can be transferred between computers, PDAs, or other electronic devices through telephone lines, or e-mail networks, or infrared links. vCard is a meta-data tag required by the Army.
www	World Wide Web
XML	eXtensible Markup Language

3 Content Design

The SCORM impacts content design of courseware. This section describes the recommended way to incorporate the design aspect of the SCORM specification for Army courseware into existing courseware design principles. It does not replace the instructional designer.

Thorough analysis and design of courseware brings about cost savings in development. Reusability brings about the benefit of not spending development dollars for courseware that already exists. The time spent in analysis and design phases will reap rewards during the implementation phase.

Please note that the Manifest file, which is part of the Content Package, is referred to many times in this section for understanding concepts. The Manifest, however, is usually not prepared until the course is fully developed and ready to be packaged. Instructions for creating a Manifest file in XML are contained in the Packaging Section.

3.1 All about SCOs

A SCO is the basic building block for SCORM conformant courseware. It is very important and necessary to understand its meaning and usage as described as follows:

3.1.1 Definition of a SCO

3.1.1-1 BUSINESS RULE (SCORM): A SCO represents a collection of one or more Assets that include a specific launchable Asset that utilizes the SCORM Run-Time Environment to communicate with LMSs. (CAM 2.1.1.2) The SCO must be specified within the Manifest with the attribute of scormtype="sco" on the <resource> element.

A SCO contains programming code that enables the SCO to communicate with the LMS via the SCORM API. This communication enables the LMS to track the SCO and read and write Student information to the LMS.

The following is an example of the XML tagging for a SCO within the Manifest with a SCO defined by the "scormtype" attribute of the parent "resource". The "scormtype" must have the value of "sco".

<title>SCO Title</title>

</item

...

</organization>

</organizations>

<schema>ADL SCORM</schema>

<adlcp:location>../metadata/unit1_sco.xml</adlcp:location>

</metadata>

</resource>

...

</resources>

Figure 3.1.1a

3.1.2 Army Classification of SCOs

The Army forecasts that there may be different classifications or purposes of SCOs.

· Independent SCOs

There are SCOs that are "independent", meaning those SCOs that are context-neutral and contain learning content and/or graded assessments. Context-neutral implies the absence of the MOS and removal of the course and module titles. Army structure terms of course, phase, module, lesson, etc. also would not be context-neutral. Independent SCOs are considered "sharable" and could be stored in a SCO repository to be available to other Schoolhouses.

The content files of an independent SCO will be local files contained in the Package. Content that the Student will be tested on must not be referenced outside the Package using a URL. However, if there is reference material that has a URL, the independent SCO may include these references according to the External References Section.

· Dependent SCOs

Another classification of a SCO would be a dependent SCO. Dependent SCOs would be developed to establish the context of an otherwise context-neutral group of SCOs such as a Course Introduction, Course Overview, or Course Map SCO. Also included would be SCOs that would transition the Student between content. For example, a dependent SCO could be developed to transition 1) from an Introduction SCO to an independent SCO, or 2) between two independent SCOs. Dependent SCOs would probably not be reusable, because they would be dependent on the course context and be limited as a "single use" SCO. Dependent SCO files will be local files contained in the content package. Dependent SCOs can contain external references accessed by URLs. See "External References" Section.

Hence, certain rules may apply to one type of SCO and not another.

3.1.2-1 BUSINESS RULE (ARMY): An independent SCO cannot contain instructional content that is dependent on another independent SCO. If learning content is dependent on other learning content and cannot stand-alone, then it must be combined together into one SCO. Independent SCOs, within its instructional content, should not refer to another SCO or aggregation.

3.1.2-2 BUSINESS RULE (ARMY): Dependent SCOs such as introduction SCOs or transitional SCOs, which have non-instructional content, may reference learning objectives, course content, etc., for the Student to understand what is to be taught. This is acceptable to the Army. The Army considers these transitional SCOs as "single use" objects and not reusable.

Below is an example of a course demonstrating the Course title and SCO titles along with an assumed indication of the Army classification:

Table of Contents	Army Classification
Basic Non-Commissioned Officer's Course	Course Title
Introduction to the BNCOC	Dependent SCO
Course Map	Launchable Asset
Pretest for Basic Non-Commissioned Officer's Course	Independent SCO
Strategies/Decisions	Lesson Aggregation (block)
Introduction to Strategies/Decisions	Dependent SCO
Using Field Level Strategies	Independent SCO
Using Squad Level Strategies	Independent SCO
Determine Front-Line Decisions	Independent SCO
Post test for Basic Non-Commissioned Officer's Course	Independent SCO

Figure 3.1.2a

3.1.2-3 BUSINESS RULE (ARMY): Independent SCOs, within its instructional content, should not refer to another SCO or aggregation. See the "Designing for Reusability" Section for more detail.

3.1.3 SCO Golden Rules

3.1.3-1 BUSINESS RULE (SCORM): SCORM requires the following:

(1) A SCO cannot link to another SCO. (CAM 2.1.1.3)

(2) A SCO must be launched by an LMS. (RTE 3.2.1.2, CAM 2.1.1.2)

(3) One SCO cannot access another SCO's data elements. (RTE 3.4.1.2)

(4) A SCO must be independent and not tied to a particular aggregation. (CAM 2.1.1.3)

In the past, courseware has been developed using stand-alone CBT authoring tools. These tools typically embedded all of the navigation and sequencing information within the learning content. Reuse was difficult and sharing learning content between authoring systems was impossible. SCORM has redefined this process.

Essentially, SCORM has brought about a new learning paradigm for developing learning resources. Navigation, sequencing, mastery score, etc., are moved externally to bring about learning content that is reusable. The reusability of a SCO depends on it being independent and not linked to or requiring data from another SCO. However, reuse cannot happen if SCO-to-SCO navigation exists. For example, if SCO-1 contains a hyperlink to SCO-2, then SCO-1 could not be extracted and reused in another course because of the link.

Major problems exist when a SCO contains links to other SCOs. The API provided by the LMS is always given in the context of the SCO which the Student just launched. For example, if the Student launches SCO "A", the API will only get values for SCO "A" and any values that are stored for SCO "A". If the Student jumps to "B", "C", and "D" and then returns to the LMS, the LMS shows "A" with "D" score and status and "B", "C", and "D" as "Not Attempted". This will confuse the students. The only way to complete "B" is to launch it from the LMS, complete it, and then exit. It is the same with "C" and "D". This alone makes SCO-to-SCO navigation impossible and is prohibited in SCORM.

SCOs must not rely on data from other SCOs. SCO-B should not be relying on SCO-A having been completed, because another developer may have replaced SCO-A with their own content. If SCOs are so tightly coupled that they cannot be repackaged or considered for reuse, then putting them into one big SCO and handling the navigation yourself sounds like the best solution.

3.1.4 "SCO" Acronym

3.1.4-1 BUSINESS RULE (ARMY): The acronym "SCO" if referring to a Sharable Content Object must not be included in any learning content or navigation link that is displayed to the Student anywhere in the courseware.

Best Practice: Use the word "item" or the word "activity" to replace the acronym "SCO". For example, "Select an activity from the Table of Contents".

"SCO" is a SCORM term, and Students are neither familiar nor expected to understand this terminology. Displaying this acronym to the Student will confuse the student possibly causing more delay in completing the learning material or more requests for help from support personnel.

Here is an example of what NOT to do. Below is shown a page in the right frame that is displaying the acronym "SCO" to the Student:

Figure 3.1.4a

3.1.5 Size of SCOs

3.1.5-1 BUSINESS RULE (SCORM): A SCO represents the lowest level of granularity of learning resources that can be tracked by an LMS using the SCORM Run-Time Environment. During content design and authoring activities, when determining the size of the SCO, thought should be given to the smallest logical size of content that one might desire to have tracked by a LMS. SCOs are intended to be subjectively small units, such that potential reuse across multiple learning objectives is feasible. SCORM does not impose any particular constraints on the exact size of a SCO. (CAM 2.1.1.2)

Below is a diagram of different sized SCOs:

Figure 3.1.5a

One SCO will be developed for each ELO, or in the absence of ELOs, one SCO will be developed for each TLO. SCOs may be developed at the sub-ELO/TLO level (e.g., learning step/activity), as necessary, to meet the course's desired educational strategy. The instructional design and testing strategy of the training will drive the size of SCOs. A SCO, by definition, is independent of context and is able to stand alone. SCORM prohibits separating dependent content into separate SCOs because one SCO would be dependent upon another SCO and would not stand alone.

Consideration should be given to the "time-out" problem existing for web-based LMSs. When there is no action performed by the Student, which triggers communication with the LMS during the learning experience, the LMS may lose connectivity with the SCO. Some suggestions or workarounds have been frequent bookmarking, smaller SCOs or reconfiguring system settings in the LMS. See the "cmi.core.lesson_location" section for more information about bookmarking.

The Army does not foresee "one page SCOs". SCOs that are too small will require excessive Student interaction launching SCOs from the TOC and closing SCOs in addition to the wait time while processing. The exception would be single HTML page SCOs containing a Flash movie, an applet, VRML, SVG, etc.

3.1.6 SCO Titles

3.1.6-1 BUSINESS RULE (SCORM): The SCO titles must be within the imsmanifest.xml file and displayed on the Table of Contents by a SCORM compliant LMS. (CAM 2.3.5.1.2, CAM 2.3.5.3.1.2.1)

3.1.6-2 BUSINESS RULE (ARMY): The SCO title contained within the SCO displayed to the Student must be exactly the same as the SCO title that is displayed on the LMS Table of Contents.

SCO titles should come from the POI or TSP if the course structure is the same. Titles could vary from the POI or TSP if redesigned to accommodate the context-neutral specifications of SCORM.

When selecting a SCO from the Table of Contents in the LMS, the Student is totally focused on the SCO title and determining from the title the content that the Student will receive. The Student expects to see that same title displayed within the learning content. Confusion will arise for the Student when the titles are different. The content designer should make sure that the programmer codes the same SCO titles into the TOC within the Manifest file.

3.1.6-3 BUSINESS RULE (ARMY): Hierarchical higher level instruction titles or words (course, phase, module, lesson, etc.,) must not be displayed within independent SCO titles. If an independent SCO contains an ELO, it must not reference its TLO within the content or title of the SCO. Independent SCO titles must not include the MOS, Skill Level, SQI, or ASI contained within the actual SCO pages or within the Manifest. Independent SCO titles must not include sequencing numbers.

One title exactly describing the learning content within the SCO is best and promotes reusability. SCOs that contain the course title, module title, and SCO title along with the topic title are confusing to the Student and unnecessary. A SCO title of "Course Post Test" or "Module Introduction" using the hierarchical Army terms is not allowed.

When a SCO that is scoped to an ELO references its TLO within the content or title of the SCO, the SCO becomes non-sharable since it is now identified with its TLO. Sharability is augmented when the SCO title only reflects the action statement of the learning objective. This SCO could be reused in another course at the TLO level or at the learning step level.

The SCO title is usually displayed on every page of the SCO. It is necessary for the Student to be aware of which SCO is displayed, because there is no other indication to the Student.

Extracting a SCO with numerical sequencing in the SCO title from one course to another course would mislead and confuse the Student. Examples of sequencing numbers are "Chapter 1" or "Topic 1". It is acceptable that school name, school graphics, or MOS, be contained within dependent SCOs such as introduction SCOs, course map SCOs, etc.

Suppose, a new module entitled "Executive Overview of all Safety Implementations" will have 5 lessons obtained by extracting SCOs from 5 other courses. A good example of SCO titles without sequencing numbers would be similar to the following (Please note these are dependent SCOs so there are no action statements):

Executive Overview of all Safety Implementations

Safety Overview for Aviation Life Support

Unit Safety Overview for Commander Safety GOOD EXAMPLE

Safety Introduction for Transportation Management

Construction Engineer Supervisor Safety Introduction

Figure 3.1.6a

The above example of SCO titles precisely identifies the content contained in each SCO. There are no references to the course names or module names from which the SCOs were extracted. They do not contain any sequencing numbers to confuse the Student.

If the SCO titles contained numbering or sequencing or an unclear title, the Student could possibly see a confusing Table of Contents like the following:

Executive Overview of all Safety Implementations

Module Introduction

Lesson 1 Overview BAD EXAMPLE

Introduction to Module 1

Topic 1 of 5

General Information-Introduction

Figure 3.1.6b

Common practice has been to include the MOS, Skill Level, SQI, and ASI in the titles of lessons. Neither of these designations should be contained within the SCO titles of independent SCOs.

Best Practice: Independent SCO titles are significant to the learning resource and should display the "Action" statement of the learning objective contained within the independent SCO.

Independent SCO titles with the action statements are more appropriate and more explanatory of the instruction that is being taught. The following are examples of independent SCO titles:

Adjust Drive Belt Tension on M151A2

Prepare for Deployment

Select Activities of Terrorist Operations

Describe the Master Gunner’s Role and Responsibilities

Identify Safety Procedures for an Armor Unit

Figure 3.1.6c

Below is a TOC example in the ILMS displaying fourteen SCO titles: (Please note that long titles are shortened.)

Figure 3.1.6d

The MOS, SQI ASI, hierarchical Army terms and sequencing numbers can be included in the course title, aggregation titles and dependent SCO titles but not in independent SCO titles.

The course title is not contained in independent SCO titles.

Independent SCO titles begin with action verbs and do not contain sequencing numbers or the Army hierarchical terms of "course", "phase", "module"," lesson", etc. .

Regarding XML tagging of SCOs, SCO titles are contained within the Manifest file in the <title> tag of parent element <item>. The <item> tag for a SCO must have an "identifierref" attribute. The following is an example of placement of SCO titles within the <organization> section of the Manifest:

<title>SCO Title</title>

</item>

...

</organization>

Figure 3.1.6e

3.1.7 Location of SCO Files

3.1.7-1 BUSINESS RULE (ARMY): Instructional content files for all SCOs must be physically located within its SCORM content package (within the root folder or subfolder) and not referenced by a URL.

All files containing instructional learning content must be physically located within the content package. Instructional learning content is germane to the instruction and on which the Student will be tested. Being physically located in the package would indicate that instructional content files would not use the HTTP protocol to access the files. URLs are permitted when hyperlinking to references provided to the Student for further study. These hyperlinked references can be located outside of the package. The information in these “external” references would not be evaluated as part of an assessment in order to complete the instruction. See the External References Section for how to include URLs in courseware.

3.2 Aggregations

Aggregations define how lower-level learning resources are gathered together, or aggregated, into a cohesive unit of instruction. A Content Aggregation hierarchically groups SCOs and other subordinate aggregations within the Manifest, and the LMS displays the aggregation titles on the Table of Contents. Aggregations are recommended for the hierarchical organizational grouping of learning resources in an instructionally, logical and ordered way to be presented to the Student.

3.2-1 BUSINESS RULE (SCORM): Define an Aggregation within the Manifest file by using the <item> tag without the "identifierref" attribute because an aggregation does not contain resources. (CAM 2.3.4-#3.2.4.2)

Best Practice: Aggregation titles should be representative of the learning objectives contained but different from the SCO, Module or Course title. Every hierarchical level should have a different title.

Aggregations associated with a logical order: Aggregations can support the "building block approach" to Student learning. Grouping SCOs of the same topic to form an aggregation enables the Student have some context of the learning. The Table of Contents, shown below, displays three aggregations of lessons with sequencing numbers and Army hierarchical terms contained in the aggregation titles.

The TOC as shown below is displayed in the ILMS. There are three aggregations circled in red.

Figure 3.2a

Notice how aggregations are not hyperlinked because there is no instructional content associated with aggregations. Aggregations are only titles that function as a grouping mechanism. The titles of the SCOs contained in each aggregation grouping are indented to form a hierarchical Table of Contents.

Aggregations mapped to TLOs: Aggregations that are mapped to TLOs could group one or more SCOs each containing an ELO. An additional SCO in this group should contain an "Introduction to the TLO" (dependent) SCO. If a TLO does not contain ELOs, then the TLO could be mapped to a SCO and be developed according to the rules for an independent SCO.

If SCOs are mapped to the ELO level, all of the ELO SCOs could be aggregated together. Using this concept, an aggregation would map to a TLO. The design strategy is to introduce that TLO and establish a relationship. An aggregation only has a title (label) for this grouping of SCOs. The "Action" statement of the TLO would be the title of the aggregation and should be different than any of its contained ELOs, but representative of the entire aggregation. The title of a lesson without supporting ELOs would be the "Action" statement of the TLO, and itself would be a SCO.

Since an aggregation cannot link to any pages and since the TLO has an Action, Conditions, and Standards and seemingly no place to present to the Student, a dependent SCO could be created to contain the Action, Conditions and Standards of the TLO. This SCO would be titled "Introduction to [Action Statement of the TLO]". This dependent SCO will transition the Student to the upcoming ELOs.

If a TLO is mapped to an aggregation and the TLO has 3 ELOs, then the content structure should be as follows:

ARMY Term	SCORM Term
TLO (Action statement for title)	Aggregation (block) (no resources)
Introduction (Dependent SCO)	SCO
ELO (Independent SCO)	SCO
ELO (Independent SCO)	SCO
ELO (Independent SCO)	SCO

Figure 3.2b

Using the above scenario, example titles from the POI or TSP have been shown as follows:

ARMY Term	SCORM Term	Actual Titles from POI or TSP
TLO (Action statement)	Aggregation (block) (no resources)	Conduct a Defense by a Platoon
Introduction (Dependent SCO)	SCO	Introduction to Conduct a Defense by a Platoon
ELO (Independent SCO)	SCO	Consolidate a Platoon Following Enemy Contact While in the Defense
ELO (Independent SCO)	SCO	Reorganize a Platoon Following Enemy Contact While in the Defense
ELO (Independent SCO)	SCO	Retreat a Platoon Following Enemy Contact While in the Defense

Figure 3.2c

The XML coding used to define an aggregation within the Manifest file is the <item> tag, but the identifierref attribute is required to be absent since it must not contain actual content (per SCORM specification), and, therefore, does not need to reference resources (pages). This <item> tag is just a container for other <item> elements.

Shown below is the XML coding in the Manifest for one aggregation with three SCOs:

…

<item identifier="C100"> (opening tag for aggregation)

<title>Aggregation Title </title>

<item identifier="SCO101" identifierref="R_SCO101"> (SCO)

<title>Introduction to TLO</title>

</item>

<item identifier="SCO102" identifierref="R_SCO102"> (SCO)

<title>Title of SCO</title>

</item>

<item identifier="SCO103" identifierref="R_SCO103"> (SCO)

<title>Title of SCO</title>

</item>

</item> (closing tag for aggregation)

…

</manifest>

Figure 3.2d

NOTE: The SCORM v1.2 term of "aggregation" has replaced the SCORM v1.1 term of "Block".

3.3 Definition of a Course as used in SCORM

The term "course" as used in this document refers to the top level of aggregation and is contained in a SCORM package. This package can be mapped to a level of instruction as determined by the organization. The term "course" is used because there is a Table of Contents within the Manifest, which is contained in each package. "Course" title describes the title of the top level aggregation contained in a SCORM package.

Details are shown in the diagram below:

Figure 3.3a

3.4 Course Title

3.4-1 BUSINESS RULE (SCORM): The Course title is obtained from within the Manifest file in the <title> tag of the parent <organization>.

3.4-2 BUSINESS RULE (ARMY): The Course title must not be contained within or referenced from the title or content of independent SCOs.

A course title is only the name of a particular collection of SCOs. It is for reusability reasons that this title be excluded in its propagation to independent SCOs. The course title must not be contained anywhere in the content inside independent SCOs because the SCO could not be reused "as-is" but would require modification before use in a different course.

In a SCORM-compliant LMS, the course titled is displayed according to its SCORM implementation usually once and is located above the Table of Contents.

The graphic below shows the placement of the course title as shown on the TOC in the ILMS:

Figure 3.4a

An MOS, course name, school name, etc. are allowed in the course title on the Table of Contents.

For an XML example, the course title is listed in the <title> tag of the parent element <organization> within the Manifest as shown below:

<title>Course Title</title>

…

</organization>

Figure 3.4b

3.5 File Naming Conventions

During testing of courseware on the Interim and the Army Learning Management System (ILMS/ALMS), some courseware would not load/play properly on the ALMS. Cause of the problem was due to inconsistent use of file/folder names within the courseware and imsmanifest.

It is imperative that courseware be portable from the ILMS to the ALMS. All courseware file names, folder and URL names must operate in Windows and Unix environments.

Since Unix file naming is case sensitive and Windows file naming is not, consistent naming of files must consider capitalization. The files “File.txt” and “file.txt” are not the same file in Unix but are the same file in Windows.

Unique file naming and identification is essential for sharing courseware across operating systems, Web Servers and Workstation Browsers. While it is technically possible to assign unique file names to all files, unique names are not always practical or desirable. It is common practice to use “index.html” as the launch file name for launching Sharable Content Objects (SCOs). By placing SCOs in different folders, the “index.html” file is uniquely named because the folder name is included in identifying Web and Workstation resources. The file identification “http://folder1/index.html” is not the same file identification “http://folder2/index.html” but is the same as “http://folder1/index.html

Best Practice: The Army recommends the following naming convention for all URLs, file names and folder names within the SCORM content package:

· A-Z, a-z, 0-9, hyphen (-) and underscore (_).

· A single period shall be used to separate the file name from its extension. Periods shall not be used in a folder name.

· File names with its extension must be uniquely named (no duplicate file/extension names for different file contents).

Examples:

Unitsafety_sco_a328.html

p1180-launch.html

ca217_metadata.xml

sco-21.xml

M60_graphic.gif

Figure 3.5a

3.5-1 BUSINESS RULE (ARMY): Mandatory URL, file and folder format and size:

File extensions shall be limited to five characters or less. A three character extension is recommended. A single period shall be used to separate the file name from its extension. Folder names shall not contain a period.

The path separator shall be either “/” or “\” depending upon the operating system (Windows, Unix) because the Browser will resolve the correct path using the appropriate separator.

Long file names are allowed but must conform to ISO 9660 with Microsoft’s Joliet extension and the Army’s file naming scheme. Joliet allows filenames up to 64 characters in length. While Joliet allows “spaces”, the Army’s naming scheme does not.

Best Practice: Use of reserved and unsafe characters in Distributed Learning (DL) courseware: There are a number of characters that should not be used in a Uniform Resource Locator (URL) because they cause a conflict in the interpretation of URLs or they are reserved by URL schemes. The reserved and unsafe characters listed below shall not be used in DL file/folder/URL names for files/folders/URLs contained within a SCORM content package. However, these characters may be used for courseware URLs external to the SCORM content package as long as they are “escaped” using their equivalent hexadecimal notation (e.g., %HH). See “GFI Example: External Files to the SCORM Content Package”.

Reserve and Unsafe Characters With Their “Escape” Code:

Space	%20
"	%22
#	%23
%	%25
&	%26
/	%2F
:	%3A
;	%3B
<	%3C
=	%3D
>	%3E
?	%3F
@	%40
[	%5B
\	%5C
]	%5D
^	%5E
'	%60
{	%7B
\|	%7C
}	%7D
~	%7E

3.5-2 BUSINESS RULE (ARMY): Additional characters that shall not be used in DL courseware for naming files/URLs: The following characters cause problems in a Unix Operating System environment:

| ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^ <space> <tab>

Best Practice: An industry practice and an Army recommendation is to limit the alphabetic characters to all lower case and the hyphen (-) characters. This reduces many of the human errors associated with consistently naming of URLs, file and folders names.

Examples:

unitsafety-sco-a328.html

p1180-launch.html

ca217-metadata.xml

sco-21.xml

m60-graphic.gif

Figure 3.5b

3.5-3 BUSINESS RULE (ARMY): The Army’s file naming scheme is extended to Government Furnished Information (GFI) for all files internal to the SCORM content package.

GFI Example for files within the SCORM content package:

Contractor receives, as GFI, a file named "AR 5-23 Unit Safety.pdf". This file mixes use of upper and lower case characters and uses the restricted “space” character. Before using the file in the courseware it is renamed as "AR_5-23_Unit_Safety.pdf" using all upper case characters and eliminates the restricted “space” character.

3.5-4 BUSINESS RULE (ARMY): Government Furnished Information (GFI) external to the SCORM content package: For GFI files external to the SCORM content package the reserved and unsafe characters used in Uniform Resource Locator (URL) shall be escaped (replaced with their hexadecimal equivalent).

GFI Example: External Files to the SCORM Content Package:

Contractor receives file "http://hostname/AR 5-23 Unit Safety.pdf" as external GFI. The file is referenced in the courseware as “http://hostname/AR%205-23%20Unit%20Safety.pdf” where “space” = %20 (hexadecimal).

3.6 Navigation

3.6.1 Navigation Help Feature

3.6.1-1 BUSINESS RULE (ARMY): A Navigation Help feature must be available in each SCO. It must explain the function of all navigation buttons because the behavior of each button and button label is not determined by SCORM.

Best Practice: The Navigation Help feature can be implemented by one of several options, depending upon the complexity of the navigation: 1) a tutorial; 2) a hyperlink; or 3) a mouse-over.

3.6.2 SCO Navigation

3.6.2-1 BUSINESS RULE (ARMY): Each active navigation button will have identifying text displayed when the mouse is hovered over the button.

Best Practice: The same navigation button behavior and name label should be implemented across all SCOs with a consistent look and feel.

Courseware buttons could have the same button label but different functionality. This non-standard approach creates confusion for the Students clicking on a button and being taken to a different location than assumed. This is frustrating not only to the Student, but also to the Tester when validating courseware as conformant or non-conformant.

With a standard navigation, aggregating SCOs from a SCO repository will produce a more professional product. Since navigation within the SCO is not dictated by SCORM and is up to the Instructional Designer, a navigation standard is highly recommended.

3.6.3 Closing or Navigating Out of a SCO

3.6.3-1 BUSINESS RULE (ARMY): A button must be on every page of a SCO that will close the SCO and return the Student to the LMS-generated Table of Contents. There must not be any behavior within a SCO that closes the LMS-generated TOC.

Best Practice: The Document Object Model (DOM) naming convention of "top" should not be used to specify the location of the upper-most frame in a SCO. Using this code could refer to the LMS frame and may close the LMS TOC.

Best Practice: With a large amount of SCO-to-LMS data transfer when closing the SCO, it is recommended to delay the closing of the SCO by displaying another final closing page in the SCO to ensure all data is transferred and that the Student obtains credit for completing the SCO.

CD-ROM based courseware is widely used by the Government. Exiting out of the course usually means clicking on the "Exit" button, which functions as a means to close the entire course. Since SCORM has been adopted by the U.S. Army, courseware developed to SCORM standards is required to run on a LMS giving new importance to the behavior of navigation buttons.

A button that closes the entire course would not only close out of the SCO but also close out of the course improperly. Therefore, any button that functions as closing or navigating away from the SCO must take the Student back to the LMS-generated TOC.

A Student may want to prematurely stop the lesson that is presently being taken. A button must be available to close the SCO on every page. With the exception of the first and last pages, however, this button should also initiate and store a bookmark so upon relaunch of the SCO, the Student is placed at the same page where the Student left off.

A Student may click on the X at the top right of the browser window and not using the courseware navigation buttons. See "LMSFinish" in the "Communication with the LMS" Section.

For the ILMS:

Best Practice: When closing a SCO in the ILMS, the last page of the SCO may remain visible even though the SCO was closed. In this case, a terminating page is displayed in the right frame. The terminating page shown below in the right frame also contains a brief instruction to the Student. This best practice may or may not work in other LMSs.

This is an example of a Terminating Page in right frame

Figure 3.6.3a

3.6.4 Previous button on first page of the SCO

Best Practice: A "previous" or "back" button should be either disabled or not visible on the first page of the SCO because SCORM specifications prohibit SCO navigating to or linking to other SCOs.

This functionality is misleading to the Student who may think that the "previous" button on the first page may launch another lesson, which would violate a SCO Golden Rule.

3.6.5 Next button on the last page of the SCO

Best Practice: A "next" or "forward" button must be either disabled or not visible on the last page of the SCO.

This functionality is misleading to the Student who may think that the "next" button on the last page may launch another lesson, which would violate a SCO Golden Rule.

3.7 Table of Contents

3.7-1 BUSINESS RULE (SCORM): The Table of Contents must be XML tagged within the Manifest file. The LMS is responsible for reading the Manifest and displaying the Table of Contents to the Student according to the LMS implementation. (RTE 3.2.1)

The usual TOC or Main Menu usually associated with CD-ROM and web-based courseware becomes obsolete with SCORM. With the SCORM specifications, the Table of Contents for the course is XML tagged and contained within the Manifest file. The LMS reads the Manifest file and displays the TOC according to the LMS implementation.

A sample TOC launched by the ILMS is displayed below:

Figure 3.7a

The above Table of Contents is shown below, XML tagged, in the "organization" section of the Manifest file. All the titles are in bold.

<title>88H10 Cargo Specialist</title>

<title>Introduction to 88H10 Cargo Specialist</title>

</item>

<title>Lesson 1 - Sling Load Operations</title>

<title>Introduction to Sling Load Operations</title>

</item>

<title>Perform Hookup Team Duties</title>

</item>

<title>Rig a Cargo Net (Helicopter)</title>

</item>

<title>Lesson 2 - Pallet Training</title>

<title>Introduction to Pallet Training</title>

</item>

<title>Load a 463L Pallet</title>

</item>

<title>Place 463L Pallets into Storage</title>

</item>

<title>Place 463L Top and Side Nets into Storage</title>

</item>

<title>Cover and Net a 463L Pallet</title>

</item>

<title>Marry and Load Two 463L Pallets</title>

</item>

<title>Lesson 3 - Cargo Administration</title>

<title>Introduction to Cargo Administration</title>

</item>

<title>Tally Cargo</title>

</item>

<title>Check Cargo into In-Transit Storage Area</title>

</item>

<title>Record Onward Movement of Cargo on DD Form 1384</title>

</item>

</organization>

</organizations>

Figure 3-7b

Consideration should be given to aggregations regarding how the learning objects should be grouped together in the Table of Contents (see Aggregations Section.) Also, consider how the TOC will be viewed by the Student because an organized Table of Contents can enhance the learning experience by the Student.

Menus inside of SCOs are acceptable as needed for intra-SCO navigation and branching to the topics contained within the SCO.

For further instructions for XML tagging of the Table of Contents, see "Table of Contents contained within the Manifest File" within the Packaging Section.

For each Table of Contents (organization section in the Manifest), Content Aggregation meta-data is required by the Army. See the Meta-data Section.

3.8 Folder Structure Example

The directory structure should be logical and intuitive and created early in the design process. It is the developer's responsibility to define the folder structure; it is not mandated by SCORM.

A recommended file structure consists of the following folders in the right frame below:

Figure 3.8a

Best Practice: A great way to store all the metadata files in one place would be to create a metadata folder, as shown above.

3.9 Checks on Learning

Best Practice: Test item data (cmi.interactions) is not required for COLs.

Best Practice: Scores from the COLs should not be sent to the LMS, which would indicate to the Student that a grade was collected and cause confusion.

The COL and PEs will be contained throughout the lesson as instructionally necessary and/or as agreed upon with the Proponent. These informal assessments can be developed according to different testing strategies, the most common of which will give the Student two tries to select the correct answer and then provide review/feedback for the correct answer. Determining whether the Student answered these assessments correctly is implemented within the lesson and should not impact the Student's ability to complete the SCO. Credit for the course is dependent upon the completion of each SCO.

However, if test item analysis is desired to be collected, then these API function calls would be needed. See the "Test Item Data" section for further information.

3.10 Course Map

3.10-1 BUSINESS RULE (ARMY): A Course Map is context-specific and, if provided, must not be contained inside independent SCOs. A Course Map inside independent SCOs negates this independence and potential reuse, and provides context specific information inside the SCO about the current course.

3.10-2 BUSINESS RULE (ARMY): A Course Map must not contain hyperlinks to SCOs.

Best Practice: A Course Map page or graphic can be placed inside a dependent SCO or developed as a launchable asset.

There are several different design strategies for placement of the Course Map page in SCORM compliant courseware, listed as follows:

· A Course Map may be included in the course as another separate, dependent SCO. Consideration must be given to the fact that this SCO requires the Student to launch the SCO and receive a "complete" lesson status. Not opening this SCO would interfere with the Student completing the course because the lesson status would remain as "not attempted". However, if it is mandatory that the Student access the Course Map and lesson status is needed to be tracked, then a separate dependent SCO would be reasonable. If developed as a SCO, the course map cannot have any hyperlinks or it would violate a SCO golden rule.

· The Course Map may be included in an existing dependent SCO such as an Introduction to the Course SCO containing a hyperlink to the course map or as actual pages within the dependent SCO. Lesson status would be tracked in the context of the entire SCO and not specifically the Course Map.

· As a launchable asset, the Course Map could be excluded from having any affect on the Student's completion of the course. The Student may access the Course Map only if desired, and the Course Map would be available from the TOC. The course map can be an html page with a graphic, but it still cannot link to SCOs. A launchable asset does not communicate with the LMS. (RTE 3.2.1.1) See the "Launchable Assets" Section for implementation information within the ILMS/ALMS.

3.11 Launchable Assets

3.11-1 BUSINESS RULE (ARMY): Launchable assets will function properly only in the ALMS and must not be used in the ILMS.

For the ILMS: Launchable assets do not function properly in the ILMS. When loaded into the ILMS, launchable assets have an invalid associated lesson status. Since the launchable asset does not have communication capabilities, it is impossible for the Student to obtain a completion status for this one activity in the course and the Student would not get credit for the course.

For the ALMS:

Best Practice: For the ALMS, launchable assets can be used for the Student's convenience, which are available to be launched from the TOC when certain web pages are needed for viewing but Student completion progress does not need to be tracked.

An activity on the TOC can be developed as a launchable asset when Student tracking is unnecessary. Instead of developing assets as a SCO, which requires communication and tracking within the LMS, a launchable asset may be the best recommendation. (RTE 3.2.1.2)

A launchable asset is exactly the same as normal web pages containing text and/or graphics but launched from the TOC. Within these assets, one file is the main entry point or launch file. This entry point or launch file of the group of files has to be designated within a resource tag within the Manifest file. The "scormtype" must be set to "asset". Therefore, a launchable asset has a link from the TOC but links to launchable assets (assets with a launch point) and does not communicate with an LMS.

A use for a launchable asset, for example, is when an online calculator is needed by the Student during the learning experience. The calculator could be a launchable asset from the Table of Contents and each SCO could have a hyperlink to the calculator web pages. Because the calculator web pages are not designed as a SCO with LMS communication, it is legal that they can also be used as "shared assets" within one or more SCOs.

Below is an example of XML code for a Launchable Asset contained within the Manifest:

...

<title>Course Map</title>

...

</organization>

...

</resource>

...

</resources>

Figure 3.11a

The above launchable asset example shows the Course Map as an item in the <organization> (TOC) pointing to resources of type "asset" with an entry point or launch file into the group of assets (href).

3.12 Designing for Reusability

3.12-1 BUSINESS RULE (SCORM): The reusability of a learning resource (SCO) depends on the SCO being independent and not tied to a particular aggregation. A SCO must be able to stand-alone. (CAM 2.1.1.3)

Reusability is one of the foundations for the SCORM specification. Instructional designers and/or developers should keep this aspect in mind. Each SCO should be able to be extracted from an existing course or selected from a SCO repository to be reused in another course structure. There should be nothing within independent SCOs that is dependent on other SCOs or dependent on course context.

Eliminating context seems to cause confusion for the educational designers who are taught that each lesson must build on previous knowledge. Therefore, the Army has developed the concept of independent and dependent SCOs as explained in the "Army Classification of SCOs" section. Dependent SCOs would provide the transition for the Student to connect the context-free independent SCOs.

3.12-2 BUSINESS RULE (ARMY): The Army requires the exclusion of transitional statements in independent SCOs such as "The next lesson will explain…"or” That topic will be discussed in the next lesson." This type of verbiage does not fit into the context of SCORM reusability.

Be careful of actual verbiage within the learning content or audio of each lesson. Refrain from including references to other lessons that follow or precede the current unit such as "Let us continue to the next lesson." or "In the next topic, you will learn…".

3.13 External References

Best Practice: External references should not link directly to the URL.

SCORM allows access to instructional content by URLs, although the Army has chosen not to recommend this method within Army courseware. See the "Location of Independent SCO Files " section. The Army allows external references that refer to non-instructional content. This content is beyond what the course has control over. External references could be used for ARs, Field Manuals, TRs, Pams, Regs, etc.

Best Practice: External references should link to a local redirect page. This method would allow ease of maintenance and conversion.

For courses to be easily converted to CD-ROM stand alone courseware, all external references within the courseware should link to a local redirect page. For the online web version, this redirect page will have the URL outside of the local domain. For the courseware to be used from a CD-ROM, the external reference itself would be copied or downloaded and stored locally on the CD-ROM. Programming code on this page will contain a statement directing the Student to either the URL for online or directing the Student to the local resources that are contained within the package.

The visual representation is as follows:

Figure 3.13a

Editing the redirect page is less time intensive than editing the SCO within the authoring tool, which requires the original files. Manual editing can easily occur on each redirect page by changing the URL to a local path. The filename for the redirect page should easily identify that it is a URL redirect page for a specific web site, perhaps in a "redirect" folder.

A conditional programming statement can also be used. Set an LMS variable as true in the top frame of the SCO for the LMS version. Change the variable to false for the CD-ROM version.

An example of a conditional statement is as follows:

// set the variable to true if using an LMS

// set to false if using CD-ROM

var LMS=true;

// redirect to URL if using an LMS or if not, redirect to local path

if (LMS)

document.location.href= [URL_of_Online_Resource];

else

document.location.href=[relative path to downloaded resource];

Figure 3.13b

Building on this method could include one redirect page for all external references using a JavaScript function for multiple redirects.

Below is an example of multiple redirects using a single JavaScript function:

function redirectURL(page) {

if (page=="atsc") {

document.location.href = "http://www.atsc.army.mil";

}

if (page=="tradoc") {

document.location.href = "http://www.tradoc.army.mil";

}

if (page=="cnn") {

document.location.href = "http://www.cnn.com";

}

Figure 3.13c

3.14 Prerequisites

The SCORM provides the ability to designate prerequisite SCOs within the Manifest that the Student must have completed prior to taking a certain SCO. However, SCORM did not mandate that SCORM compliant LMSs support prerequisites. See the "ADL Extensions to the Manifest" topic in the Packaging Section.

For the ILMS:

Best Practice: The SCORM method of designating prerequisite SCOs within the Manifest should not be used because it is not supported in the ILMS.

For the ALMS:

Best Practice: Prerequisites are not supported in the ALMS and should not be used.

3.15 Testing Strategy

Plan and develop your testing strategy early. A well-defined testing strategy is imperative because of the impact on the playability of the SCORM courseware in the ILMS/ALMS. Most importantly, one must consider that all SCOs (content and exam) in a package must rollup to a completion status in the LMS to get credit for a course. How SCOs are designed will impact the Student obtaining completion.

Here are some items to consider which impact the playability of SCORM courseware in any LMS:

What is the level of testing? Module level? TLO level?
At what level do you plan to pretest?
Is the Student performance test for credit and will the Student's progress be tracked?
How many attempts does the Student have to pass the Student performance test?
After the Student performance testis passed, is the Student permitted re-entry to the test?
Can the Student go back to previous questions and skip questions?
Is the Student performance test "resumable" or "non-resumable" or have a time limit?
Can the Student retake the Student performance test immediately upon failure?
Is the Student performance test graded for GO/NO GO or is the actual numeric grade needed?
Does the Student need reach-back of the instructional content? Unlimited or Restricted?
Will there be Student tracking for completion of the content or can the Student opt-out of the content?

Once the testing strategy has been developed, application can be made in the other areas of SCORM development.

3.15.1 Considerations

3.15.1.1 Pretests

There are two types of pretests: Prerequisite pretests and Mastery pretests.

· Prerequisite pretest verifies the Student has the prerequisites, skills, knowledge, and competencies in which to continue the learning. Prerequisite pretests, if failed, would require the Student be denied access to the instructional content.

· Mastery pretest is used to test the Student's prior mastery of the learning objectives for the purpose of "testing out" or reducing the objectives that must be mastered within the lesson/module/phase/course.

Prerequisite pretest functionality and mastery pretest functionality can be achieved but may be prohibited depending on design strategy and depending on the level at which pretests are presented to the Student.

It is assumed that the Student will only have one attempt to pass the pretest. It will be accessible when the Student enters the SCO for the first time as determined by the entry status of "ab-initio".

For the ILMS: Mastery Pretests developed as individual SCOs will not "test-out" the Student in the current version of the ILMS. Therefore, there are several design options:

· Combine pretest and content in one SCO. If the Student has mastered this objective, then the Student has saved time by being able to test-out. The Student proceeds with the other learning objectives and must take the post test.

· Combine pretest, content and post test in one SCO with instructional logic inside the SCO. For example, if the Pretest was "passed", the Student would be directed to exit the SCO and would receive credit for completion in the ILMS. If the pretest was "failed", then the Student would automatically be directed to the instructional content and post test inside the SCO. When the post test is "passed", the Student would receive credit. Consideration would have to be given to length of instruction and would have to fit courseware guidelines. This scenario would be viable for pretests occurring at the TLO level or lower. Passing each SCO either with the pretest or post test will indicate that the Student has mastered the objective.

· For pretests developed as a single SCO at the module or course level, the pretest would be set aside until implementation is supported.

· Combine the pretest and post test(s) in one SCO with instructional logic using the entry status and/or lesson status in conditional programming statements coupled with storage of number of attempts in the ILMS. This option would be viable at the module level or above.

Recommended SCO design applicable to pretests in the ILMS:

SCO contains:	Level of Testing
SCO contains:	Module	TLO/ELO
Pretest
Content only
Pretest + Content		Y
Pretest + Content + Post test(s)		Y
Pretest + Post test(s)	Y
Post test(s)

Figure 3.15.1.1a

For the ALMS: Mastery pretests developed as separate SCOs at the course or module level will test the Student out of content if contained in a single-SCO content package. Other pretest design options as explained above are also supported.

Recommended SCO design applicable to pretests in the ALMS:

SCO contains:	Level of Testing
SCO contains:	Module	TLO/ELO
Pretest	Y
Content only
Pretest + Content*	Y	Y
Pretest + Content + Post test(s)		Y
Pretest + Post test(s)
Post test(s)

Figure 3.15.1.1b

*Content at TLO level or lower

3.15.1.2 Reach-Back

Reach-Back is a term used to indicate that the Student reaches back into or re-accesses the instructional content after the Student has completed a graded assessment. Consideration must be given to Reach-Back in the design strategy. Reach-Back would be determined by any Student performance test lock-out policies of an LMS, attempt limits through an LMS, SCO size or by the number of packages. Restricting reach-back is also important for content that should not be readily available. Understanding reach-back is important when packaging for the LMS.

For the ILMS: If a graded assessment is embedded with the instructional content in the same SCO, then the Reach-Back may be prohibited depending on packaging strategy. If the ILMS lock-out is applied, then reach-back is not available in the locked package. If the ILMS lock-out is not applied, then instructional logic is needed to restrict access to each "passed" Student performance test within all SCOs in the package.

If Reach-Back capability and the actual Student performance test score are required, then the content and the Student performance test must be in separate SCOs (module level of testing) and in separate packages. In this instance, the ILMS does support a mastery score where the Student score is compared with the mastery score and a GO/NO GO is determined.

If Reach-Back and only pass/fail are required, then the content and the Student performance test could be in the same SCO (TLO/ELO level of testing) and contained in the same package. Lesson status of "incomplete" when the Student fails the Student performance test is recommended to be sent to the ILMS.

At the module level of testing, the ILMS can support reach-back when pretest and content for a learning objective are developed as one SCO using instructional logic to provide access to the content and restrict access to the Student performance test.

Recommended SCO design applicable to reach-back in the ILMS:

SCO contains:	Level of Testing
SCO contains:	Module	TLO/ELO
Pretest
Content only	Y	Y
Pretest + Content*	Y	Y
Pretest + Content + Post test(s)		Y
Pretest + Post test(s)
Post test(s)		Y

Figure 3.15.1.2a

*Content at TLO level or lower

For the ALMS: After completing a course, the course is retained in the Student's transcript (a linked history of all courses the Student has taken). Use of the Transcript capability would allow the Student to review the course after completing the course Student performance test. Tests can be excluded from the Transcript.

Recommended SCO design applicable to reach-back in the ALMS:

SCO contains:	Level of Testing
SCO contains:	Module	TLO/ELO
Pretest
Content only	Y	Y
Pretest + Content*		Y
Pretest + Content + Post test(s)		Y
Pretest + Post test(s)
Post test(s)		Y

Figure 3.15.1.2b

*Content at TLO level or lower

3.15.1.3 Lock-Out Policies

Consideration should be given to the number of attempts for a post test and when the Student is denied re-entry. If the Student has unlimited attempts until passed or the attempts are restricted, then this information is important for Packaging. Also important is if the plan denies re-entry after successfully passing the Student performance test. Testing at the TLO/ELO level can achieve lock-out within the SCO by using instructional logic to deny re-entry when passed.

For the ILMS: A two-attempt lock-out can be automatically applied to any single-SCO package. A lock-out can be applied to any multi-SCO package at the point when all SCOs roll up complete in the ILMS. (A "failed" lesson status is considered completed to the ILMS. See the cmi.core.lesson_status section.)

A lock-out can be applied by the ILMS to a single-SCO package after the SCO is passed. The ILMS reads the lesson status of "failed" as the first attempt and enables access for another attempt. After the SCO is failed the second time, the lock-out is applied to the package.

A lock-out can be automatically applied by the ILMS to any multi-SCO package once all SCOs are completed as determined by the lesson status data model. The Army does not recommend using the lesson status of "failed" because the ILMS interprets it as "Student is done" and rolls it up as successfully completed.

Recommended SCO design applicable to lock-out in the ILMS:

SCO contains:	Level of Testing
SCO contains:	Module	TLO/ELO
Pretest
Content only	Y	Y
Pretest + Content		Y
Pretest + Content + Post test(s)		Y
Pretest + Post test(s)	Y	Y
Post test(s)	Y	Y

Figure 3.15.1.3a

For the ALMS: Attempt limits can be applied when registering a package in the ALMS.

Recommended SCO design applicable to lock-out in the ALMS:

SCO contains:	Level of Testing
SCO contains:	Module	TLO/ELO
Pretest	Y	Y
Content only	Y	Y
Pretest + Content		Y
Pretest + Content + Post test(s)		Y
Pretest + Post test(s)
Post test(s)	Y	Y

Figure 3.15.1.3b

3.15.1.4 Scores: Actual vs Averaged

The ILMS averages two or more scores within a content package and compares this "averaged" score with the minimum passing score. If the Student is required to meet the minimum passing score on each Student performance test, then this method will not work. The SCO itself can calculate pass/fail and not depend on the ILMS method. Student performance tests requiring actual scores must be packaged separately as single-SCO packages. Include this information in the testing strategy.

3.15.2 Testing Strategies

3.15.2.1 Content Completion Required / Student Performance Tests with Lock-out

This strategy insures the Student accesses and completes all content SCOs. The Student has unlimited reach-back to content but is denied re-entry to the Student Performance test when passed. By passing the pretest, the Student would "test-out".

For the ILMS: The Student has two attempts to pass the module level Student Performance test. The Student receives one or more versions of the test, which are randomly chosen from a maximum of five test packages. Lock-out is automatic by the ILMS after Student has passed the Student performance test or two failed attempts. Completion of all instructional content is required. The mastery pretest SCO is not supported and would be excluded from the course. It would be reintegrated when transferred to the ALMS. See diagrams in Packaging section (7.3.1)

For the ALMS: Lock-out is applied to the Student performance test SCO through the ALMS without additional SCO programming. Completion of all instructional content is required. Mastery Pretest is supported.

3.15.2.2 Content Completion Not Required / Student Performance Tests with Lock-out

This strategy gives the Student a choice to opt-out of the instructional content or to have the benefit of unrestricted access to the content. The Student is denied re-entry to the Student performance test after passed. By passing the pretest, the Student would "test-out".

For the ILMS: The Student has two attempts to pass the Student performance test, which is randomly chosen from a maximum of five Student performance test packages. Lock-out is automatic when Student has passed the Student performance test. Mastery pretest via the post test is supported in this strategy. The post test can function as a pretest for the Student since the Student is not required to complete the optional instructional content. The pretest SCO would be set aside until supported. See diagrams in Packaging section (7.3.2).

For the ALMS: Pretest SCO is supported. Student performance test SCO lock-out is applied by the ALMS without additional SCO programming.

3.15.2.3 Content Completion Required / Student Performance Tests with Internal Testing Logic

This strategy insures that the Student accesses and completes all content SCOs. Since the Student has unlimited attempts to pass the Student performance test, it could be compromised. Student lock-out is required when the Student has passed the Student performance test. If developed as an embedded test, then additional SCO programming is required to deny re-entry. Lock-out by the LMS can be applied to a single-SCO Student performance test package. Student has reach-back capability.

For the ILMS: The Student has unlimited attempts to pass the Student performance test. At the module level of testing, the Student receives one or more versions of the Student performance test, which is randomly chosen from a maximum of five Student performance test packages. At the TLO/ELO level of testing, the test would send only two lesson status vocabulary values of "passed" and "incomplete". If a mastery pretest SCO exists, it would not function properly for a Student to test-out of content. This pretest SCO is excluded from the course but is included when transferred to the ALMS. See diagrams in Packaging section (7.3.3)

For the ALMS: The Student has unlimited attempts to pass the module level Student performance test. Lock-out can be applied by the ALMS to restrict access when passed. Mastery pretest is supported.

3.15.2.4 Read-Ahead Packages (No Student Performance Tests) Content Completion Not Required

This strategy consists of content for information only but there is no tracking of student progress. The Student has unlimited access and there is no Student performance test. See diagrams in Packaging section (7.3.4)

3.15.2.5 Read-Ahead Packages (No Student Performance Tests) Content Completion Required

This strategy consists of the tracking of student progress. All SCOs must be accessed and completed by the Student. The Student has unlimited access. This strategy does not require a Student performance test. See diagrams in Packaging section (7.3.5)

4 Communication with the LMS (Run-Time Environment)

A goal of the SCORM is that learning resources be reusable and interoperable across multiple LMS. For this to be possible, there must be a common way to start learning resources, a common mechanism for learning resources to communicate with an LMS, and a predefined language or vocabulary forming the basis of the communication. As illustrated below, these three aspects of the RTE are Launch, API and Data Model. (RTE 3.1)

Figure 4.0 a

This environment is called the "Run-Time Environment". JavaScript is the programming language necessary for implementing RTE API function calls to the LMS. The following examines SCORM Run-Time Execution State Commands, State Management, and Data Transfer Commands.

4-1 BUSINESS RULE (SCORM): Every SCO is required to adhere to the SCORM Run-Time Environment. This implies that it must have a means to locate an LMS's API Adapter and must contain the minimum API calls of LMSInitialize and LMSFinish. (CAM 2.1.1.2)

Best Practice: The JavaScript file entitled "APIWrapper.js" provided by ADL is recommended to be used in the development of courseware. This file incorporates state management diagnostic functions to handle errors. Using this file would mean that adding error handling routines to the programming code would be unnecessary. APIWrapper.js file can be obtained by emailing the contact email address and requesting the file.

NOTE: All of the programming code examples assume use of the API Wrapper file developed by ADL. Programming subroutines may begin with a similar name but has different parameters. It is the responsibility to make sure to use the APIWrapper function calls if using the APIWrapper.js file or, if not, use the exact SCORM API function calls as designated in the SCORM specification. If not using the APIWrapper file, the developer would replace each function name listed below with the actual SCORM specification API function call. For example, the APIWrapper function call is "LMSInitialize()" within this document, and the SCORM specification API function call is "LMSInitialize("")." Please be aware there are several versions of the APIWrapper file.

With version of APIWrapper.js file used in this document	With another version of APIWrapper.js file	Using actual SCORM API function calls without the APIWrapper.js file
LMSInitialize()	doLMSInitialize()	LMSInitialize( " " )
LMSFinish()	doLMSFinish()	LMSFinish( " " );
LMSCommit()	doLMSCommit()	LMSCommit( " " )

Figure 4.0b

Also, due to the fact that the API Wrapper file already contains LMSGetLastError error handling routines with each function call, there is no further need to assess error conditions repeating the API function call of LMSGetLastError. All of the examples assume use of the APIWrapper.js file.

4.1 LMSInitialize

4.1-1 BUSINESS RULE (SCORM): LMSInitialize is a mandatory SCORM API function call for all SCOs. LMSInitialize indicates that the SCO is ready to begin communication with the LMS. (RTE 3.3.2.1)

LMSInitialize();

Figure 4.1a

It is the responsibility of the SCO to initiate communication with the LMS by sending an LMSInitialize API function call, which means "I'm ready to talk".

Best Practice: LMSInitialize should not be called from the onLoad event on the first page of the SCO. Errors will result when clicking the back button on the second page.

To avoid this error, a "SCO Start" (redirect) page has been suggested that separately calls LMSInitialize. This page is placed as the launch page of the SCO. It will call LMS Initialize and then immediately will redirect the Student to the first "real" page of the SCO. All that is required is changing the href of the anchor tag on the "SCO Start" page to the redirected real first page of SCO. If this method is used, LMSInitialize should only be called on the "SCO Start" page.

Sample code for the sco start page is as follows:

<html>

<head>

</head>

<body>

Initializing Lesson…<br>

Please wait

LMSInitialize();

document.location.href="index.html";

</script>

</body>

</head>

Figure 4.1b

4.2 LMSFinish

4.2-1 BUSINESS RULE (SCORM): LMSFinish is mandatory for all SCOs. LMSFinish indicates that the SCO no longer needs to communicate with the LMS. It must be called when the Student is leaving the SCO. (RTE 3.3.2.1)

LMSFinish();

Figure 4.2a

LMSFinish should not be called on a page event (onUnload, etc.) on the last page. An error will occur when the Student, while on the last page, goes back to the previous page. A user event is required to call LMSFinish.

4.2-2 BUSINESS RULE (ARMY): LMSFinish must be called when the Student closes the SCO by clicking on the X and closing the browser window instead of the appropriate navigation button to exit the SCO.

The Student may close the browser window by clicking on the "X" on the upper right side of the browser window. When this happens, the SCO is closed incorrectly and LMSFinish is not called and any data still outstanding will not be saved. Therefore, the SCO can be programmed to call LMSFinish should this occur.

Best Practice: The following code will detect when the cursor is clicked outside of the page area and will execute right before the page unloads. This code determines the position of the cursor when it was clicked and, if the cursor was clicked outside of the page area, then LMSFinish is called.

There are two solutions presented below: 1) a "no-frames" solution, then, 2) a "frames" solution.

No-Frame Solution:

Below is an example of how clicking on the Exit button and clicking the X to close the browser will execute the exitSCO function and call LMSFinish.

<html>

<head>

<title>Closing the Browser Window</title>

function didStudentClicktheX() {

if (window.event.clientY < 0 ) {

exitSCO();

}

function exitSCO() {

alert("call LMSFinish");

window.close();

}

</script>

</head>

Content here

</div>

</body>

</html>

Figure 4.2b

Below is the solution for a frameset, which places the exit code on the other frame instead of the frame containing the instructional content. This means that only when the browser window is closed will the other unload events be executed. When navigating through the courseware pages, the data storage page still remains active. The data storage page is the best candidate for the location of the LMSFinish. For example, a frameset contains two pages: the data storage page and the courseware content page. Closing the browser window by clicking on the X will cause the unload event to execute for the entire frameset and LMSFinish would be called. LMSFinish, which would normally be called when the Student clicks on the Exit button, can be replaced with a parent.close because LMSFinish will be called from the data storage page. Clicking the Exit button or closing the browser window by clicking on the X would execute the unload event from the Data Storage Page.

Using the above frameset scenario, an example of a frameset page (frame.html) is shown below:

<html>

<head>

<title>Closing the Browser Window</title>

</head>

</frameset>

Sorry, your Browser does not support Frames. For this courseware to run correctly Frames must be enabled.

</noframes>

</html>

Figure 4.2c

The Data Storage page (storage.html) is shown below:

<html>

<head>

<title>Data Storage</title>

</script>

var currentTime = new Date();

var startTime = currentTime.getTime();

function exitSCO() {

// call exit routine and LMSFinish

LMSFinish("");

}

</script>

</head>

</body>

</html>

Figure 4.2d

The courseware content page (content.html) is shown below:

<html>

<head>

<title>SCO Title</title>

function endSCO() {

parent.close();

parent.location.href=”../../index.html”;

}

</script>

</head>

<body>

<p>Content Page</p>

<!—Content is here -->

</div>

</body>

</html>

Figure 4.2e

4.3 Data Transfer

Data Transfer functions are used to transfer data to and from an LMS using the SCORM data model. The data model is a standard set of data elements used to define the information being communicated, such as the status of the learning resource. The data model is explicitly described in the SCORM v1.2 Run-Time Environment specifications document dated October 1, 2001.

4.3.1 LMSGetValue

4.3.1-1 BUSINESS RULE (ARMY): LMSGetValue is mandatory for all SCOs. LMSGetValue allows the SCO to obtain information from the LMS. The Army requires the SCO to read certain information from the LMS. The SCORM v1.2 Run-time Environment specification (RTE) designates which data model supports this API call for “reading" data from an LMS.

variable = LMSGetValue("data model");

Figure 4.3.1a

Example:

var status = LMSGetValue("cmi.core.lesson_status");

Figure 4.3.1b

4.3.2 LMSSetValue

4.3.2-1 BUSINESS RULE (ARMY): LMSSetValue is mandatory for all SCOs. LMSSetValue allows the SCO to write information to the LMS. The Army requires the SCO to write certain information to the LMS. The SCORM v1.2 RTE designates which data model supports this API call for “writing" data to an LMS.

This API function call allows the SCO to send or "set" information in the LMS. The value has to be formatted according to the data type, which could be CMIDecimal, CMIString255, CMIVocabulary, etc.

LMSSetValue("data model", value);

Figure 4.3.2a

Example:

LMSSetValue("cmi.core.lesson_status", "passed");

Figure 4.3.2b

4.3.3 LMSCommit

4.3.3-1 BUSINESS RULE (ARMY): LMSCommit is mandatory for all SCOs. LMSCommit persists the data when the API Adapter is caching values received from the SCO via LMSSetValue().

Best Practice: Use LMSCommit frequently for data that needs to be persisted in the LMS to protect against loss of connectivity.

This API function call requires that any cached values, previously set via SCO calls to LMSSetValue that have not been persisted by the LMS, be persisted.

LMSCommit( );

Figure 4.3.3a

LMSCommit API function call should be called, at a minimum, whenever there is an LMSSetValue of the data elements, cmi.core.lesson_status and cmi.core.score.raw.

4.4 State Management

State Management defines a standardized way to determine an error condition with the API communication mechanism. The API has three API function calls that are used to handle errors. The Army has required the following state management API function calls.

4.4.1 LMSGetLastError

4.4.1-1 BUSINESS RULE (ARMY): LMSGetLastError is mandatory for all SCOs. LMGetLastError allows the SCO to determine an error condition on the communication to and from the LMS. LMSGetLastError is automatically included in programming code when using the APIWrapper file provided by ADL.

This API function call provides a way of assessing whether or not any given API function call was successful. It returns an error status code resulting from the previous API function call.

var retVal = LMSGetLastError();

Figure 4.4.1a

This API function call enables the SCO to assess the success of the immediately previous API function call. This function returns an error status code. The error status code will change when the next API function call is made. This function allows the SCO to retrieve the error code. Following is a list of the error codes:

Error Code	Error Description
0	No error
100’s	General exception
200’s	Syntax errors
300’s	LMS errors
400’s	Data model errors

Figure 4.4.1b

If the SCO sends "85" for the "cmi.core.score.raw" data model, the SCO is required to assess whether the data transfer is acknowledged by the API adapter. Using this scenario, the code would be similar to the following:

LMSSetValue("cmi.core.score.raw", "85");

var errorCode=LMSGetLastError();

if (errorCode!==0) {

//result is error. data transfer not complete

//other action is required and already defined in the

//API Wrapper file

}

LMSCommit();

Figure 4.4.1c

4.5 Macromedia Flash Specific Run-Time

Communication with the LMS can be achieved with Flash by using JavaScript. For instance, shown below is a JavaScript "setScore" function. The Flash code also shown below would be similar to the following:

JavaScript function in a <script> tag on the HTML page:

function setScore(score) {

LMSSetValue("cmi.core.score.raw", score);

LMSCommit();

}

Figure 4.5a

Within Flash 5 or Flash MX, the Actionscript would be similar to the following:

var score=0;

score = 75; (whatever the Student scored on the performance test)

getURL("javascript:setScore(' "+ score +" ' )" );

Figure 4.5b

The Student's score from within Flash is sent via the Flash "getURL" function to the JavaScript "setScore" function.

4.6 SCORM Data Model

4.6.1 cmi.core.lesson_location (Bookmarking)

Bookmarking is a process where the Student suspends learning for a certain period of time and upon re-entry, the Student is automatically taken to the point within the instructional content where the Student left off. Bookmarking does not bookmark which SCO the Student last accessed, but only bookmarks the last page accessed by the Student inside the SCO.

4.6.1-1 BUSINESS RULE (ARMY): Setting a bookmark when the Student prematurely leaves the SCO is mandatory for all SCOs except Student performance test SCOs. This bookmark must be retrieved upon re-entry and used as an entry point the next time the Student launches the SCO.

Below are examples of bookmarking code:

// retrieving the bookmark from the LMS

var retVal = LMSGetValue("cmi.core.lesson_location");

Figure 4.6.1a

// storing the bookmark in the LMS

LMSSetValue("cmi.core.lesson_location", "[page the student is viewing]");

Figure 4.6.1b

Below is an actual example of code when the Student suspends the SCO:

LMSSetValue("cmi.core.lesson_location", window.location);

Figure 4.6.1c

Best Practice: A bookmark when required should be sent on every page (except the first page) to help maintain communication with the LMS. For simulations, bookmarks should be sent after each simulation event. A loss of connectivity may occur in courseware where it is suspected that the ILMS or ALMS is not receiving data transfers or is timing out. The increased frequency of bookmarking has been recommended as a solution to this problem.

Best Practice: At the entry of a SCO, provide the Student a choice by prompting the student to either return to their last location or not. After LMSInitialize, the SCO should read cmi.core.lesson_location and if a value exists, the SCO should prompt the Student to either return to where the Student left off or go to the beginning.

Below is an example of code to prompt the Student after retrieving the bookmark:

var lastLocation = LMSGetValue("cmi.core.lesson_location");

if (lastLocation != "") {

result = confirm('Would you like to return to your last location?');

if ( result ) {

document.location.href=lastLocation;

}

Figure 4.6.1c

Best Practice: A bookmark should not be set on the first page of a content SCO and an empty bookmark should be set on the last page of a content SCO.

A bookmark should not be set on first page of the SCO when the Student enters the SCO. The Student could mistakenly launch the SCO, visit the first page and realize the learning resource is not the one anticipated, and close the SCO. Later, upon entering that same SCO again, not remembering in which lesson the mistake was made, a bookmark message appears asking to return to where the Student left off. Since the Student never began the SCO, the bookmark message causes confusion.

An empty bookmark should be set on the last page of content SCOs to avoid overwriting any previous value stored in the LMS. For example, a Student, after earlier completing all of the training, might want to review the material for a Student performance test and reassess the training. Launching the SCO would invoke the bookmark, which would take the Student to the last page and would be unnecessary and frustrating.

Below is an example of setting an empty bookmark on the last page of content SCOs:

LMSSetValue("cmi.core.lesson_location", "");

Figure 4.6.1d

Best Practice: In a Student performance test, bookmarks should not be sent to the ILMS/ALMS, unless the Proponent has specified a particular Testing Strategy.

For the ILMS:

The ILMS contains a unique feature that is not usually in a SCORM compliant Learning Management System. When launching courseware developed as SCORM compliant, the ILMS will automatically launch the last SCO the Student accessed during the previous attempt and the bookmarking code will be executed. Providing an option to abort a bookmark is recommended.

4.6.2 cmi.core.entry

The entry data model is an indication of whether the Student has been in the SCO before. There are three values: "ab-initio", "resume" or empty string ( " " ). The LMS is responsible for establishing the initial value of "ab-initio" upon initial launch by the LMS. When the Student leaves the SCO, the value of "ab-initio" is changed to "resume" by the LMS. Cmi.core.entry is a read-only value. The empty string value ( " " ) is assigned by the LMS when the Student has not suspended but has accessed the content after completion for review.

Shown below is an example of retrieving the value of cmi.core.entry:

variable = LMSGetValue( "cmi.core.entry" );

Figure 4.6.2a

This value is important to the instructional strategy of the SCO. If a pretest contained in a SCO is to be presented to the Student only upon initial entry into the SCO, then this value would be the best indicator of Student entry and should be retrieved from the LMS.

4.6.3 cmi.core.lesson_status

4.6.3-1 BUSINESS RULE (ARMY): Storing SCO Lesson Status in the LMS is mandatory for all SCOs and is the most important value to a SCO.

There are six status values: "passed", "completed", "failed", "incomplete", "browsed", and "not attempted", which is the LMS default value for any SCORM compliant LMS. The first time a course is presented to the Student, the lesson status for all SCOs is "not attempted".

Below are syntax examples of how "getting" and "setting" the lesson status values are coded:

Variable = LMSGetValue("cmi.core.lesson_status");

LMSSetValue("cmi.core.lesson_status", value);

Figure 4.6.3a

Below are examples of lesson status read from the LMS and written to the LMS:

//getting or reading the value from the LMS

var status = LMSGetValue("cmi.core.lesson_status");

//setting or writing the value to the LMS

LMSSetValue("cmi.core.lesson_status", "incomplete");

Figure 4.6.3b

Lesson Status can determine the lock-out policy (whether the Student can or cannot re-enter the SCO) as shown in the code example below:

Var status = LMSGetValue("cmi.core.lesson_status");

If (status == "passed") {

alert("You have already passed the Student performance test. Access denied.");

LMSFinish();

// close the SCO

}

Figure 4.6.3c

Most importantly, lesson status determines when a student is finished with the course. It also determines when information can be uploaded to ATRRS. In the ILMS, “failed”, “passed”, and “completed” trigger scoring action and initiation of lock-out policy. See the Packaging Section for more information on how the lesson status affects lock-out policy and playability.

4.6.3-2 BUSINESS RULE (ARMY): A lesson status of "incomplete" must be sent to the ILMS/ALMS when the Student fails the Student performance test.

A lesson status of "failed" for a SCO is interpreted by the ILMS as meaning "Student is done." If the lesson status for all SCOs in a course are either "passed", "failed" or "completed", then the LMS determines that the Student has finished the course, the rollup status of "complete" is sent to ATRRS and restrictions, if any, will be applied at that time of completion.

Lock-out policies may apply when the course is completed as determined by the ILMS/ALMS. If the ILMS/ALMS determine that a course is finished by a Student, then the Student may be prohibited from accessing some or all of the packages.

4.6.3-3 BUSINESS RULE (ARMY): A "completed" status for a Content SCO must not be changed upon re-entry to the SCO.

The ILMS contains a unique feature that is not usually in a SCORM compliant Learning Management System. When launching courseware developed as SCORM compliant, the ILMS will automatically launch the last SCO the Student accessed during the previous attempt. This impacts lesson status. The Student must be able to exit the SCO without a change to a "completed" status.

Best Practice: Lesson status should not be arbitrarily changed without checking existing value. Conditional programming statements should be used. The concern is that a lesson status would change when the Student returns to review for a Student performance test.

Below is an example of the programming logic: Content SCO (no Student Performance test)

Condition	Lesson Status Value sent to LMS
SCO launched	Get Value of "not attempted" Set Value to "Incomplete"
SCO exited prematurely	Do nothing (already set to incomplete)
SCO exited on last page	Set Value to "Complete"

Figure 4.6.2d

The JavaScript code for getting and setting lesson status in a conditional statement is as follows:

var status = LMSGetValue("cmi.core.lesson_status");

if (status == "not attempted") {

LMSSetValue( "cmi.core.lesson_status", "incomplete" );

}

Figure 4.6.3e

Notice that only under the condition of lesson_status equal to "not attempted" will be status be changed to "incomplete". This allows Students, after completing the SCO, to re-enter the SCO to review the content, perhaps, before taking a Student performance test. The Student’s "complete" status would not be changed.

4.6.3-4 BUSINESS RULE (ARMY): A lesson status of "passed" in a Student performance test SCO must deny the Student re-entry to the Student performance test. Use conditional programming statements to check the lesson status upon entry.

Var status = LMSGetValue("cmi.core.lesson_status");

if (status == "passed" || status == "completed") {

alert("Re-entry Denied. You have already passed this Student performance test.");

// now close the SCO and call LMSFinish

}

Figure 4.6.3f

If the testing strategy limits access to the Student performance test after passing, then programming statement should be included within the SCO to deny access.

If the testing strategy requires only a GO/NO GO, then shown below are examples of programming code to determine GO/NO GO.

For the ILMS: For a Student performance test SCO (calculating pass/incomplete inside SCO):

Note that the ILMS does not support mastery score.

Condition	SCO Value sent to LMS
SCO launched	Get Value of lesson status If lesson status equals "not attempted", then Set Value to "incomplete" If lesson status equals to "passed", then deny re-entry and exit SCO
Get the Mastery Score value	Get Value of Mastery score. Although the ILMS does not support mastery score, the code must exist. If mastery score is null, then use the backup score. See cmi.student_data.mastery_score section.
Student performance test exited prematurely	Do nothing (already set to incomplete)
Student’s numerical Student performance test Score (cmi.core.score.raw)	Set Value of cmi.core.score.raw to Student’s numerical score. Send LMSCommit.
cmi.student_data.mastery_score is greater than Student’s numerical Student performance test score	Do nothing (already set to incomplete)
cmi.student_data.mastery_score is less than Student’s numerical Student performance test score	Set Value of cmi.core.lesson_status to "passed"

Figure 4.6.3g

For the ALMS: For a Student performance test SCO (calculating pass/incomplete inside SCO):

Condition	SCO Value sent to LMS
SCO launched	Get Value of lesson_status If lesson_status equals "not attempted", then Set Value to "incomplete". If lesson_status equals "passed", then deny re-entry and exit SCO
Get the Mastery Score value	Get Value of Mastery score stored in cmi.student_data.mastery_score
Student performance test exited prematurely	Do nothing (already set to incomplete)
Student’s numerical Student performance test Score (cmi.core.score.raw)	Student finished Student performance test. Set Value of cmi.core.score.raw to Student’s numerical score. LMSCommit.
cmi.student_data.mastery_score is greater than Student’s numerical Student performance test score	Do nothing. (already set to incomplete)
cmi.student_data.mastery_score is less than Student’s numerical Student performance test score	Set Value of cmi.core.lesson_status to "passed"

Figure 4.6.3h

4.6.4 cmi.core.score.raw

4.6.4-1 BUSINESS RULE (ARMY): For graded assessments, Student score must be stored in the ILMS/ALMS.

This value indicates the performance of the Student during his last attempt on the Student performance test SCO and must be a normalized value (decimal) between 0 and 100 stored as a string value. Example: 85, 85.5, 100, 92.3, 92.

// decimal stored as a string

LMSSetValue("cmi.core.score.raw", "[decimal]");

Figure 4.6.4a

The Student's performance is evaluated within the SCO. This evaluation is stored as a numerical value, for example, studentScore="85"

// student's calculated score

var studentScore = "85";

// sending the value to the LMS

LMSSetValue("cmi.core.score.raw", studentScore);

Figure 4.6.4b

The SCO is responsible for setting the score, which is compared to the mastery score either by the SCO or the LMS to determine "pass/fail". See cmi.student_data.mastery_score section.

4.6.5 cmi.student_data.mastery_score

Mastery score is a very important value to any type of graded assessment. There are several aspects to the mastery score value which are:

· The mastery score is XML tagged on the Manifest file associated with the SCO

· The mastery score is uploaded to the LMS when the LMS reads the Manifest

· The mastery score is stored in the cmi.student_data.mastery_score data field

4.6.5-1 BUSINESS RULE (ARMY): All SCOs containing a Student performance test must have a mastery score within its Content Package Manifest. Mastery score is required to be external to a Student performance test SCO and located within the manifest in the <adlcp:masteryscore> tag of the parent <item>. This will ensure maximum reusability.

Mastery score is the score that must be attained by the Student to pass the graded assessment. SCORM allows the mastery score to be designated outside of the SCO within the Manifest file. The LMS reads the manifest file and stores this value in cmi.student_data.mastery_score data field.

4.6.5-2 BUSINESS RULE (ARMY): The mastery score must not be hard coded inside the SCO. This limits reusability.

The Army's desire is for maximum sharability and reusability. Changing the mastery score within the XML Manifest file is much easier than obtaining original files, installing software and reworking a SCO within the original authoring tool when the actual mastery score is contained (hard coded) within the SCO.

However, a hard coded score and a backup score are not the same. If a mastery score is not placed within the Manifest file or the LMS did not read the mastery score from the Manifest, a "backup" mastery score should be provided in the programming code within the SCO. It has been determined that the ILMS does not read in the mastery score from the Manifest file. Although this is a violation of the LMS implementation of the SCORM specification, the mastery score must continue to be designated within the Manifest file and setting a backup score within the SCO.

Below is an XML example of inserting the mastery score pertaining to a SCO within the Manifest file:

<title>SCO Title</title>

<adlcp:masteryscore>80</adlcp:masteryscore>

</item>

Figure 4.6.5a

The SCO reads the mastery score from the Manifest and stores this value to be used within the SCO. Below is an example of retrieving mastery score from the LMS by the SCO:

variable = LMSGetValue("cmi.student_data.mastery_score");

Figure 4.6.5b

The SCO then compares this score to the Student’s actual Student performance test score to determine pass/fail. The SCO sends the resulting "passed" or "failed" lesson status to the LMS.

Shown below is an example of the code retrieving mastery score from the ILMS/ALMS, evaluating if mastery score contains an empty, null or undefined value, then the backup mastery score is used, and the SCO can calculate GO/NO GO (passed or incomplete).

function getMasteryScore() {

var masteryScore;

//checking if LMS supports mastery score

var student_dataChildren = LMSGetValue( "cmi.student_data._children");

if ( student_dataChildren.indexOf("mastery_score" ) != -1) {

masteryScore = LMSGetValue( "cmi.student_data.mastery_score" );

if (masteryScore == null || masteryScore == "" || masteryScore == undefined) {

masteryScore = getBackupMasteryScore();

}

} else {

//mastery score not supported

masteryScore = getBackupMasteryScore();

}

// set persistent storage of masteryScore

[persistent storage.variable] = masteryScore;

}

function getBackupMasteryScore() {

// enter in the backup mastery score here

return "70";

}

Figure 4.6.5c

For the ILMS:

Best Practice: The data model of cmi.core._children in the ILMS indicates support of the external mastery score on the Manifest, but, in reality, the ILMS does not support mastery score.

Testing was performed using the following code for a SCO with the external mastery score within the Manifest:

var masteryScore;

//checking is LMS supports mastery score

var student_dataChildren = LMSGetValue( "cmi.student_data._children");

alert(student_dataChildren);

Figure 4.6.5d

The alert function displayed the supported values of: "mastery_score,max_time_allowed,time_limit_action". The names of the data model in this list returned from the ILMS means that these data models are supported.

However, when the following code is executed, an empty value for mastery_score was received:

// is mastery score in the list

if ( student_dataChildren.indexOf("mastery_score" ) != -1) {

masteryScore = LMSGetValue( "cmi.student_data.mastery_score" );

}

/* masteryScore variable is blank proving the ILMS does

not support mastery score */

Figure 4.6.5e

Best Practice: Since the ILMS does not support the external SCORM mastery score, a backup mastery score should be contained inside the SCO using conditional programming statements as a contingency effort. When a LMS does not read the external mastery score from within the Manifest, a backup score will be provided.

The mastery score tag within the Manifest is not read in by the ILMS and will produce erroneous results. The recommendation is to follow the best practice of determining support by retrieving cmi.student_data._children and providing a backup mastery score within the programming code of the SCO. Upon encountering an empty, null, or undefined variable when retrieving cmi.student_data.mastery_score, the backup mastery score is used.

function getMasteryScore() {

var masteryScore;

//checking if LMS supports mastery score

var student_dataChildren = LMSGetValue( "cmi.student_data._children");

if ( student_dataChildren.indexOf("mastery_score" ) != -1) {

masteryScore = LMSGetValue( "cmi.student_data.mastery_score" );

if (masteryScore == undefined || masteryScore == "" || masteryScore == null) {

masteryScore = getBackupMasteryScore();

}

} else {

masteryScore = getBackupMasteryScore();

}

function getBackupMasteryScore() {

// enter in the backup mastery score here

return "70";

}

Figure 4.6.5 f

For the ALMS:

The external mastery score is supported in the ALMS. Student performance tests that will play on the ALMS must be developed according to the Business Rules in this section. The backup mastery score recommended for the ILMS can be included in SCOs that will play on the ALMS for reasons of portability.

4.6.6 cmi.core.exit

4.6.6-1 BUSINESS RULE (ARMY): Cmi.core.exit is required to be sent to the LMS when the Student navigates away from the SCO as an indication of how or why the Student left the SCO.

This value indicates the reason that the SCO was exited. The Army recommends three of the four possible vocabulary values: " " (empty string), time-out, and suspend.

LMSSetValue( "cmi.core.exit", " " );

LMSSetValue( "cmi.core.exit", "time-out" );

LMSSetValue( "cmi.core.exit", "suspend" );

Figure 4.6.6a

An empty string ("") indicates a normal exit state.

LMSSetValue( "cmi.core.exit", "" );

Figure 4.6.6b

"Time-out" indicates the SCO ended because the SCO has determined an excessive amount of time has elapsed, or the max-time-allowed has been exceeded. The maximum time that is allowed in the SCO can be found within the Manifest (adlcp:maxtimeallowed for the item element), which is stored by the LMS using the "cmi.student_data.max_time_allowed" data model.

LMSSetValue( "cmi.core.exit", "time-out" );

Figure 4.6.6c

"Suspend" indicates the Student leaves the SCO with the intent of returning to it later at the point where he/she left off.

LMSSetValue( "cmi.core.exit", "suspend" );

Figure 4.6.6d

4.6.7 cmi.core.session_time

4.6.7-1 BUSINESS RULE (ARMY): Session time is required for every SCO and the SCO must calculate the time from the launching of the SCO to the closing of the SCO and send to the LMS. The format is HHHH:MM:SS.SS.

This value is the amount of time in hours, minutes, and seconds that the Student has spent in the SCO at the time they leave it. That is, this represents the time from beginning of the session to the end of a single use of the SCO.

Example logic:

//format example for sessionTime - "0010:34:14.56"

// example shows 10 hours, 34 minutes, 14.56 seconds

Get time the SCO was launched (start time)
Get the time the Student is leaving the SCO (end time)
Subtract the start time from the end time which indicates the session time.
Convert to correct HHHH:MM:SS.SS format
Send session time to the LMS

Figure 4.6.7a

A timer function would be needed to track the time the Student spends in the current session of the SCO and send to the LMS upon leaving the SCO. The timer would begin immediately after calling LMSInitialize and stop right before setting the value in the LMS, call LMSCommit and then LMSFinish. Because of the stateless nature of HTML frames would be one solution to store the time value that the SCO was launched.

Below are JavaScript functions that will start the timer, convert the seconds to hours, minutes and seconds and write to cmi.core.session_time.

/* set a global variable on a parent frame, retrieve and call setSessionTime function */

var startTime;

// call function right after LMSInitialize

function startTimer()

{

startTime = new Date().getTime();

}

// call function right before LMSFinish

function setSessionTime() {

var currentTime = new Date();

var endTime = currentTime.getTime()

var calculatedTime = endTime-startTime;

var totalHours = Math.floor(calculatedTime/1000/60/60);

calculatedTime = calculatedTime - totalHours*1000*60*60

if ( totalHours < 1000 && totalHours > 99 ) {

totalHours = "0"+totalHours;

} else if ( totalHours < 100 && totalHours > 9 ) {

totalHours = "00"+totalHours;

} else if ( totalHours < 10 ) {

totalHours = "000"+totalHours;

}

var totalMinutes = Math.floor(calculatedTime/1000/60);

calculatedTime = calculatedTime - totalMinutes*1000*60;

if ( totalMinutes < 10 ) {

totalMinutes = "0"+totalMinutes;

}

var totalSeconds = Math.floor(calculatedTime/1000);

if ( totalSeconds < 10 ) {

totalSeconds = "0"+totalSeconds;

}

var sessionTime = totalHours+":"+totalMinutes+":"+totalSeconds;

LMSSetValue("cmi.core.session_time", sessionTime);

}

Figure 4.6.7b

Another method would be to use cmi.suspend_data or cmi.comments as a place to store the start time just after LMSInitialize is called. Just before LMSFinish is called, this value could be retrieved and calculate the elapsed time.

Code executed right after LMSInitialize:

var startTime = new Date().getTime(); // time in seconds

LMSSetValue( "cmi.suspend_data", startTime );

Figure 4.6.7c

Code executed right before LMSFinish:

var startTime=LMSGetValue("cmi.suspend_data");

// then use the setSessionTime function shown above

Figure 4.6.7d

For the ILMS: The ILMS calculates the time the Student spends in the current session of the SCO. The SCORM specification.clearly indicates that it is the SCO's responsibility to calculate session time. (RTE 3.4.4) Adding in this code as explained in this section will not interfere with Aspen code and the code calculating session_time will then be contained in the SCO when transferred to the ALMS.

For the ALMS: The ALMS supports the SCO's responsibility for calculating session_time. The calculation of session_time must be added to the SCO.

4.6.8 cmi.core.total_time

4.6.8-1 BUSINESS RULE: (ARMY): For a timed SCO, the SCO must retrieve total time from the LMS to calculate remaining time available in the current session of the SCO.

This LMS value indicates the accumulated time of all the Student’s sessions in the SCO as reported by the SCO (using session_time) when exited by the Student. This is a "read-only" value. The LMS will initialize total_time to 0000:00:00:00 the first time the SCO is launched and then use SCO reported values of session_time to keep an accumulated total. Total_time is an Army required LMSGetValue API function call for timed tests. It can be used to determine the average time needed for a Student to learn the instruction.

variable = LMSGetValue("cmi.core.total_time");

Figure 4.6.8a

This value would be very important in a timed Student performance test and in a timed test that could be resumed. The SCO would retrieve the value of cmi.core.total_time upon launch of a timed test and subtract the total time from the maximum amount of time allowed in the SCO as stored in cmi.student_data.max_time_allowed. This max_time_allowed LMS value was specified within the Manifest using the <adlcp:maxtimeallowed> tag in the parent <item>.

For example code demonstrating the conversion of total_time from its HHHH:MM:SS.SS format to milliseconds, see the "cmi.student_data.max_time_allowed" section.

4.6.9 cmi.student_data.max_time_allowed

4.6.9-1 BUSINESS RULE (ARMY): For a timed SCO, maximum time allowed must be specified within the Manifest. This value will be stored in cmi.student_data.max_time_allowed.

This value indicates the amount of time the Student is allowed to have in the current attempt on the SCO. Format for this value is HHHH:MM:SS.SS. This value is required for "timed" Student performance tests. See time_limit_action for the SCOs expected response to exceeding the limit.

variable=LMSGetValue("cmi.student_data.max_time_allowed");

Figure 4.6.9a

The max_time_allowed value is required to be retrieved in timed Student performance tests to determine whether the maximum time allowed in the SCO has been exceeded. The following code examples reflect a non-resumable timed Student performance test.

Var mta = LMSGetValue("cmi.student_data.max_time_allowed");

// convert HHHH:MM:SS.SS to milliSeconds

Var mta_ms = convertToMilliseconds(mta);

setTimeout([function to execute when time has elapsed], mta_ms);

function convertToMilliseconds(time) {

arTime = new Array();

arTime = time.split(":");

// arTime[0] contains hours,

// arTime[1] contains minutes

// arTime[2] contains seconds

var milliseconds = ( (parseInt(arTime[0])*60*60) + (parseInt(arTime[1])*60) + parseInt(arTime[2]) ) *1000;

return milliseconds

}

Figure 4.6.9b

The max_time_allowed value is used in conjunction with cmi.student_data.time_limit_action. See the expanded example in the "cmi.student_data.time_limit_action" section.

Maximum time allowed is external to the SCO and is specified within the Manifest in the <adlcp:maxtimeallowed> xml tag within the parent <item> tag and stored in this data model by the LMS for SCO retrieval. See ADL Extensions to the Manifest File Section for more information.

4.6.10 cmi.student_data.time_limit_action

Best Practice: The time_limit_action data model is associated with max_time_allowed, which tells the SCO what to do when the max_time_allowed is exceeded. Of the four vocabulary options, it is recommended that two of the vocabularies, which display a message to the Student, be used.

variable=LMSGetValue("cmi.student_data.time_limit_action");

Figure 4.6.10a

This value is used to indicate to the SCO what the action should be when the maximum time allowed in the SCO has been exceeded.

Two recommended vocabulary values:

"exit,message"

"continue,message"

// retrieving values from LMS

var maxTimeAllowed=LMSGetValue("cmi.student_data.max_time_allowed");

var timeAction=LMSGetValue("cmi.student_data.time_limit_action");

// *convert maxTimeAllowed to milliseconds

Var mta_ms = convertToMilliseconds(maxTimeAllowed);

/*Use a setTimeout JavaScript function to execute after the time has elapsed */

setTimeout("noMoreTime(timeAction)", mta_ms);

function convertToMilliseconds(time) {

arTime = new Array();

arTime = time.split(":");

// arTime[0] contains hours,

// arTime[1] contains minutes

// arTime[2] contains seconds

var milliseconds = ( (parseInt(arTime[0])*60*60) + (parseInt(arTime[1])*60) + parseInt(arTime[2]) ) *1000;

return milliseconds;

}

function noMoreTime(action) {

// 2 results recommended

switch (action) {

case "exit,message":

alert("Your time has expired. The session will terminate.");

LMSSetValue( "cmi.core.exit", "time-out" );

LMSCommit();

LMSFinish();

break;

case "continue,message":

alert("Your time has expired and the session will be marked accordingly.");

LMSSetValue("cmi.core.exit", "time-out" );

LMSCommit();

LMSFinish();

break;

}

Figure 4.6.10b

Time limit action value is external to the SCO and is specified within the Manifest in the <adlcp:timelimitaction> xml tag within the parent <item> tag.

4.6.11 cmi.suspend_data

Best Practice: Use cmi.suspend_data for the following reasons: 1) to store the number of attempts in a multi-version Post test SCO; 2) to store the start time value to calculate session_time; 3) to store a bookmark within a large Flash file; 4) to store Student's bookmarks within the SCO content.

Best Practice: Be careful when designing the suspend data storage format and avoid leading zeros.

This element contains unique information generated by the SCO during previous uses that is needed for the current use.

var retVal = LMSGetValue("cmi.suspend_data");

LMSSetValue(" cmi.suspend_data ", value );

Figure 4.6.11a

This field contains unique information generated by the SCO during previous uses that is needed for the current use. Normally, this is an element used by the SCO for restart information, but can be used for other purposes. This data is created by the SCO and stored in the LMS. LMSSetValue is used to store the data with the LMS and LMSGetValue retrieves the data from the LMS to be used by the SCO.

This field can store Student placeholders or bookmarks within the SCO or pages so the Student can return. In a large SCO, functionality could be given to the Student to bookmark certain pages that the Student would like to return within the SCO.

For a Student performance test SCO with two versions of the test, the number of attempts could be stored in suspend_data to facilitate serving up the correct Student performance test. Avoid leading zeros in this storage area. An example of a design that failed is the use of zeros and ones (0,1) to track pages visited. In some instances, the leading zeros of a number are suppressed, which outputs incorrect data.

This field can also store the grade from a Student performance test when the testing strategy allows suspending and resuming the test. The Student will not be able to view which questions were answered correctly since the results would be stored in suspend_data and not viewable by the Student. When the Student resumes the performance test and the SCO retrieves the previous results, then all of the results should be sent after all questions have been answered and scored.

Suspend_data could be used to store a bookmark within a large Flash file in addition to storing the HTML page of the Flash object in the lesson_location field. Suspend_data can store multiple bookmarks from a Macromedia Flash file when the Flash file has several movies playing with the main file.

4.6.12 cmi.interactions.n.type

4.6.12-1 BUSINESS RULE (ARMY): For each test item in a Student performance test, the type of question (multiple choice, T/F, matching, etc.) must be stored in the LMS according to the SCORM vocabulary.

This value designates what type of question (multiple choice, true-false, etc.) was delivered to the Student.

LMSSetValue("cmi.interactions.[number].type", "[vocabulary]");

Figure 4.6.12a

The type of interaction determines how the interaction response should be interpreted. The letter, "n", designates a counting mechanism, always begins with "0" and then increases by 1.

Vocabulary for "Type"

true-false

Choice

fill-in

Matching

Performance

Sequencing

Likert

Numeric

Figure 4.6.12b

4.6.13 cmi.interactions.n.correct_responses.n.pattern

4.6.13-1 BUSINESS RULE (ARMY): For each test item in a Student performance test, the pattern of the correct Student response must be stored in the LMS.

LMSSetValue("cmi.interactions.[number].correct_responses.[number].pattern", "[pattern]");

Figure 4.6.13a

This value describes the correct Student response to the interaction.

Type	Correct Responses Pattern
true-false	t or f
choice	a or b or c or d
fill-in	alpha-numeric string
matching	pairs of identifiers separated by a period, source and target
performance	alpha-numeric field limited to 255 characters
sequencing	final positioning of the elements identified in any order
likert	leave blank
numeric	single number

Figure 4.6.13b

Code example of pattern:

LMSSetValue("cmi.interactions.0.correct_responses.0.pattern", "t");

Figure 4.6.13c

4.6.14 cmi.interactions.n.student_response

4.6.14-1 BUSINESS RULE (ARMY): For each test item in a Student performance test, the Student's response must be sent to the LMS.

This value is the description of possible responses to the interaction. There may be more than one correct response, and some responses may be more correct than others.

LMSSetValue("cmi.interactions.[number].student_response", "[student’s answer]");

Figure 4.6.14a

This value indicates the actual Student response to the interaction. This value can then be checked against the cmi.interactions.n.correct_responses.n.pattern.

Example:

LMSSetValue("cmi.interactions.0.student_response", "t");

Figure 4.6.14b

4.6.15 cmi.interactions.n.result

4.6.15-1 BUSINESS RULE (ARMY): For all graded assessments, results of the test items (correct/wrong, etc.) must be sent to the ILMS/ALMS using cmi.interactions.n.result after all test items have been answered and a score has been calculated. This data model is the only indicator of correctness for each test item.

This value indicates how the system judges the described response. The code is shown below:

LMSSetValue("cmi.interactions.[number].result", "[vocabulary]");

Figure 4.6.15a

Vocabulary for "result"

Correct

Wrong

Unanticipated

Neutral

x.x

Figure 4.6.15b

The following is a valid working example of the API function call.

LMSSetValue("cmi.interactions.0.result", "correct");

Figure 4.6.15c

Best Practice: Results of the test item (correct/wrong) could be stored in an array using JavaScript and sent to the ILMS/ALMS after scoring the Student performance test using cmi.interactions.n.result.

var arResult = new Array();

// storing correct/wrong in array for each test item

function storeResult(result) {

var i = arResult.length;

arResult[i] = result;

}

// send results to LMS after scoring

function sendResults(arResult) {

for (i=0;i<arResult.length;i++) {

LMSSetValue("cmi.interactions." + i + ".result", arResult[i]);

}

Figure 4.6.15d

When using Flash to develop a Student performance test, it may be easier to use an array inside of Flash to store the test item results. Sending the Flash array to JavaScript may require converting the array into a string and sending the string to the sendResults function. Use the split method to store string back into an array as shown below:

/* Question results (correct/wrong) must be sent to the LMS

after the Student performance test has been scored */

/* Flash sends a string to a Javascript function with the

Comma as the string delimiter */

function sendResults(stringList) {

var resultsArray = stringList.split(",");

for(i=0;i<resultsArray.length;i++) {

if (resultsArray[i] ) {

LMSSetValue("cmi.interactions." + i + ".result", resultsArray[i]);

}

Figure 4.6.15e

The following is a display of cmi.interactions.n.result in the ILMS under the "Result" heading:

Figure 4.6.15f

4.6.16 cmi.interactions.n.weighting

4.6.16-1 BUSINESS RULE (ARMY): For each weighted test item in a graded assessment, the weighted value of the test item must be stored in the LMS.

This value designates variations in importance. The weighting is a factor, which is used to identify the relative importance of one interaction compared to another.

LMSSetValue("cmi.interactions.[number].weighting", "[number indicating importance");

Figure 4.6.16a

If the first interaction has a weight of 15 and the second interaction has a weight of 25, then any combined score that reflects weighting would be more influenced by the second interactions. If all interactions are equal in importance, then each interaction has the same weight and this API function call would not be needed.

Example:

LMSSetValue("cmi.interactions.0.weighting", "15");

Figure 4.6.16b

4.6.17 cmi.interactions.n.latency

4.6.17-1 BUSINESS RULE (ARMY): For each timed test item in a graded assessment, the time between presentation and completion must be stored in the LMS.

This value is controlled by the SCO and is the time from the presentation of the stimulus to the completion of the measurable response.

LMSSetValue("cmi.interactions.[number].latency", "[time]");

Figure 4.6.17a

This value is required for "timed questions" responses and sent to the LMS at the Student's completion of each question. The "timer" function should begin with the presentation of the question and stop when the Student either goes forward to the next question or backwards to the previous question. This function would result in the amount of time the Student spent on the question, which would be stored in the LMS database.

If the Student moves to the previous questions, then the previous latency time value is overwritten. Below is an example:

LMSSetValue("cmi.interactions.0.latency", "0000:03:15");

Figure 4.6.17b

4.6.18 cmi.interactions.n.time

4.6.18-1 BUSINESS RULE (ARMY): For each timed test item in a graded assessment, a timestamp must be stored in the LMS.

This value is the identification of when the Student interaction was completed and is a point in time in a 24 hour clock. It is used as a "timestamp" of the interaction. Format is HH:MM:SS[.S]. This value is controlled by the SCO.

LMSSetValue("cmi.interactions.[number].time", "[time]");

Figure 4.6.18a

This value is required only for "timed questions" responses. If a Student returns to a previously answered question, then the previous "time" value is overwritten.

sTime = getTime();

LMSSetValue("cmi.interactions.0.time", sTime);

Figure 4.6.18b

4.6.19 cmi.comments

This value represents the ability for the SCO to get and set comments. It is used to store feedback from the Student and could also represent additional storage space to write values that are calculated within the SCO and need to be stored for retrieval when cmi.suspend_data is already being used. Cmi.comments is a data element that is optional for LMSs to support.

LMSSetValue("cmi.comments", value);

variable = LMSGetValue("cmi.comments");

Figure 4.6.19a

5 Student Performance Tests (Pretests and Post Tests)

All SCOs containing a Student performance test will have an external mastery score within its Content Package Manifest. More information about mastery score is contained in the "cmi.student_data.mastery_score" section. Also, see the "cmi.core.lesson_status" section and the "cmi.core.score.raw" section.

Best Practice: Students should be able to skip questions, go back to questions, change a response and review their completed Student performance test before submitting results for a grade.

Best Practice: A graded assessment containing a large number of test items should consider a loss of connectivity and a possible loss of data in the design of the assessment. During processing of a lengthy Student performance test or prolonged data transfer to the LMS, a window, page or message should be displayed indicating wait time during processing so the Student will not close the window and abort processing.

5.1 Pretests

The testing strategy usually requires a mastery pretest except in cases of a waiver. However, there are some major differences in how the pretest functions in the ILMS and the ALMS.

For the ILMS: Pretests developed as a single SCO cannot function as a mastery pretest to allow the Student to "test-out" of instructional content. For "pretest" capability, the pretest must be contained within the same SCO as the instructional content with intra-SCO branching to the content if the Student failed the pretest. This is usually done at the TLO/ELO level. Design strategy and size of SCOs are very important here. This step must be done early in the design phase. See "Testing Strategy" in the Design Section.

For the ALMS: Mastery pretests developed as a single SCO contained in a Package can allow the Student to "test-out" of instructional content in the ALMS if the pretest SCO is contained within a single package and the post test SCO is contained in another separate package (This package may also contain content SCOs as well). The ALMS has an "equivalence" functionality, which can be directed to the pretest package and the post test package. See the Packaging Section.

5.2 Post tests

For the ILMS: It is recommended that for the ILMS that the courseware, if testing at module level, be separated at the module level into two content packages: one package containing the instructional content and pretest and a second package containing the module Student performance test. This would mean that the pretest would not test-out of content, but would function as a diagnostic. The actual Student performance test score would be uploaded to the Student's record in ATRRS. This packaging strategy does not work for all instructional strategies. See the Packaging Section and contact your Courseware Manager prior to development to insure the packaging will reflect the testing strategy.

For the ALMS:

For a Student performance test to function properly in the ALMS, the post test SCO should be physically separated from the instructional content package to create a Student performance test content package. This method of packaging will coincide with the uploading of scores to ATRRS. This method is essentially separating a module into three content packages. See the Packaging Section for more detailed information.

5.3 Test Item Data

Test item data is collected in the ILMS/ALMS by using the cmi.interactions data model in SCORM. Examples of Run-Time API function calls used with the cmi.interactions data model are shown below:

Multiple Choice, Correct Student Response	LMSSetValue("cmi.interactions.0.type", "choice"); LMSSetValue("cmi.interactions.0.correct_responses.0.pattern", "b"); LMSSetValue("cmi.interactions.0.student_response", "b"); LMSSetValue("cmi.interactions.0.result", "correct");
Multiple Choice, Incorrect Student Response	LMSSetValue("cmi.interactions.0.type", "choice"); LMSSetValue("cmi.interactions.0.correct_responses.0.pattern", "b"); LMSSetValue("cmi.interactions.0.student_response", "a"); LMSSetValue("cmi.interactions.0.result", "wrong");
True-False, Correct Student Response	LMSSetValue("cmi.interactions.1.type", "true-false"); LMSSetValue("cmi.interactions.1.correct_responses.0.pattern", "t"); LMSSetValue("cmi.interactions.1.student_response", "t"); LMSSetValue("cmi.interactions.1.result", "correct");
True-False, Incorrect Student Response	LMSSetValue("cmi.interactions.1.type", "true-false"); LMSSetValue("cmi.interactions.1.correct_responses.0.pattern", "t"); LMSSetValue("cmi.interactions.1.student_response", "f"); LMSSetValue("cmi.interactions.1.result", "wrong");

Figure 5.3a

One type of data that is collected is whether the Student answered the test item correctly or not. This data model is the "cmi.interactions.[item number].result". Concerns have arisen about the possibility of a Student viewing the test item results (correct/wrong) before completion of the Student performance test. A Business Rule was developed because of this concern. See the "cmi.interactions.n.result" section for more detail.

When the Student skips questions and then has to go back to the questions, the cmi.interactions should be overwritten using the same "n" number.

5.4 Testing Examples

Many testing strategies exist in the Army for graded assessments. Several paths have been chosen as examples for SCORM API function calls.

The examples in this section assume use of the APIWrapper.js file, referenced in Section 4, Communication with the LMS, because state management API function calls are already included in the API Wrapper file and, therefore, are not needed in the actual programming code. The examples are also set up this way.

Example programming for selected testing strategies is shown below:

5.4.1 Non-Resumable Student Performance Test

Testing Strategy Example for Non-Resumable Student Performance Test:

a) Student able to skip questions and go back to questions.

b) Student can exit out of the Student performance test anytime before submitting answers and receive an "incomplete".

c) Student cannot resume from where the Student left off. (No bookmarks.)

d) Score will be displayed to Student after scoring.

e) After scoring, provide test review. Do not hyperlink to other SCOs.

f) Student is unable to go back to questions after scoring.

g) Student score is sent by the SCO and stored in the ILMS/ALMS.

h) Lesson Status (Pass/Incomplete) is stored in the ILMS/ALMS, which is sent to ATRRS.

i) Student has unlimited attempts with alternate Student performance test versions.

j) Mastery Score is contained within the Manifest and stored in the LMS. (ILMS does not support mastery score but inclusion of backup mastery score programming code is recommended. See cmi.student_data.mastery_score section.

k) There are two versions of the Student performance test in one SCO.

Description	Event	Pseudo-code for SCORM Run-Time, Data Model and Programming Code
First Page of Test	Launch	Send LMSInitialize Begin timer function Retrieve Mastery Score from the LMS If not supported, use backup score Retrieve Lesson Status If Lesson Status is not attempted, deliver Version A of the Student performance test If Lesson Status is incomplete, deliver Version B of the Student performance test Send Lesson status of incomplete Increment number of attempts
Student progresses through Student performance test	Next and Back Button	Send cmi.interactions.n.type Send cmi.interactions.n.correct_responses.n. pattern Send cmi.interactions.n.student_response Store cmi.interactions.n.result in an array Send LMSCommit
Student progresses through Student performance test	Close button	Send cmi.core.session_time Send cmi.core.exit Lesson_status is already set to incomplete Send LMSFinish
Last Page Submit Answers	Calc score and status.	Calculate student Score Send score with cmi.core.score.raw If failed, already set to incomplete If passed, send cmi.core.lesson_status Send LMSCommit
	Display score	Display Score to Student Send test item results from array using cmi.interactions.n.result
	Test Review	// Display Test Review
	Close SCO	Send cmi.core.session_time Send cmi.core.exit Lesson_status is already set to incomplete Store number of attempts to cmi.suspend_data Send LMSCommit Send LMSFinish

Figure 5.4.1a

5.4.2 Timed Non-Resumable Student Performance Test

A timed Student performance test has a maximum time limit. If the maximum time limit has been reached, a particular action is taken. The timing should be used only when necessary to verify mastery in accordance to the TLO standard.

Two specific API function calls and data model needed for a timed Student performance test are:

Var mta = LMSGetValue (“cmi.student_data.max_time_allowed”);

Var tla = LMSGetValue (“cmi.student_data.time_limit_action”);

For example, a Student has launched a lesson, but the maximum time allowed in the SCO is 30 minutes. The time elapsed in the session of the SCO would be continuously compared with the maximum time allowed. Either the session time would be written to the ILMS/ALMS upon Student exit or the time limit action would occur.

Testing Strategy Example for a Timed Non-Resumable Student Performance Test:

a) Student is able to skip questions and go back to questions.

b) Student must complete the entire Student performance test to receive credit and if exit prematurely out of the Student performance test, will receive "incomplete".

c) Score will be displayed to Student after scoring.

d) Student unable to go back to questions after scoring.

e) Score is calculated by the SCO and sent to the ILMS/ALMS to be stored.

f) Mastery Score is contained within the Manifest and stored in the LMS. (ILMS does not support mastery score but inclusion of backup mastery score programming code is recommended. See cmi.student_data.mastery_score section.

g) Lesson Status (Pass/Incomplete) is determined by the SCO.

h) When time exceeded, Student receives a message and must exit the Student performance test after maximum time allowed.

i) There is one version of the Student performance test.

Description	Event	SCORM Run-Time, Data Model and Programming Code
First Page of SCO- Introductory Page	Launch	Send LMSInitialize. Begin timer function. Retrieve mastery score from LMS If not supported, use backup score Retrieve lesson status. If lesson status is passed, deny access. If status is equal to not attempted, then retrieve max_time_allowed and time_limit_action. Set lesson status to incomplete in conditional statement.
First Test Item; Student progresses through Student performance test	Next Button	Use setTimeout function to determine when session_time exceeds max_time_allowed. Send cmi.interactions except result
Submit Answers	Calc score Send Status Close button	Calculate Student's score and display to Student If failed, already set to incomplete If passed, must send "passed" status Send results Send LMSCommit Send LMSFinish

Figure 5.4.2a

5.4.3 Resumed Student Performance Test

A resumed Student performance test is when a Student may exit the Student performance test before submitting the Student's answers to be scored, bookmarking the point at which the Student exited the Student performance test, and upon re-entry, place the Student where the Student left off.

Testing Strategy Example for Resumed Student Performance Test:

a) Student able to skip questions and go back to questions.

b) Student will receive an “incomplete” when exiting an incomplete Student performance test.

b) When Student exits, test item data and bookmark are stored.

c) Bookmark is retrieved upon re-entry to the Student performance test and Student is directed to the page where the Student left off.

d) Student may begin again at the bookmark but can not go back to questions answered during previous session.

e) Mastery Score is contained within the Manifest and stored in the LMS. (ILMS does not support mastery score but inclusion of backup mastery score programming code is recommended. See cmi.student_data.mastery_score section.

f) Score will be displayed to Student after scoring.

g) Student unable to go back to questions after scoring.

h) Score is calculated by the SCO and sent to the ILMS/ALMS to be stored.

i) No limit to the number of attempts to take the Student performance test.

j) Lesson status of "incomplete" (if failed) or "passed" to be sent by the SCO.

k) There is one version of the Student performance test.

l) Once passed, the Student is denied re-entry.

Description	Event	SCORM Run-Time, Data Model and Programming Code
First Page of Test	Launch	Send LMSInitialize Begin timer function Retrieve mastery score from the LMS If not supported, use backup score Retrieve lesson status If lesson status equals passed, deny re-entry If lesson status equals incomplete, retrieve stored test item data and bookmark and send student to bookmark If lesson status equals not attempted, send incomplete and send LMSCommit
Student progresses through Student performance test	Next, Back buttons	Send cmi.interactions to LMS Store result in array Send LMSCommit
Student progresses through Student performance test	Close Button	Set lesson location Store test item data for future session Send LMSCommit Send LMSFinish
Last Page - Submit Answers	Calc score Lesson Status Close button	Calculate score, store in LMS and display to student If student fails, already set to incomplete If student passes, send lesson status of passed Send results array to the LMS Send LMSCommit Send LMSFinish

Figure 5.4.3a

6 Meta-Data

6-1 BUSINESS RULE (ARMY): Context specific Meta-data is required for all Content Aggregations. Context independent meta-data is required for all SCOs. Army-required types of meta-data must be in separate XML files and referenced from within the Manifest file using the XML binding for separate meta-data file references. (CAM 2.3.5.2.3)

SCORM defines meta-data as a way "to provide a common nomenclature enabling learning resources to be described in a common way." SCORM adopted the IMS Learning Resource Meta-data Information Model (http://www.imsproject.org/).

Meta-data files must be separate XML files referenced within the Manifest file using the XML binding of the <metadata> tag to reference the location internal to the package. Army required meta-data (Content Aggregation and SCO) must not be placed directly into the Manifest file.

Meta-data is used for reusability and discoverability and provides information about the learning content. SCORM highly recommends the practice of including meta-data, but it is not required. However, the Army has identified optional SCORM meta-data requirements as "Army Mandatory" for content aggregations and SCOs.

This SCORM specification makes the process of finding and using a resource more efficient by providing a structure of defined elements that describe the learning resource for reusability. Most elements in the meta-data hierarchy have a specific definition, data type, and either a vocabulary or defined content.

When creating your meta-data, always remember the target audience, knowledge base, search habits and search vocabulary of those seeking content, and develop metadata with these things in mind. This includes using the most specific and descriptive terms possible.

The description and keywords will be useful for other individuals searching online content repositories for relevant content to use in their own courses.

A software tool is highly recommended for the automatic creation of meta-data .xml files. The Government has developed a Meta-Data Editor tool that is now in the public domain. To download this tool, visit http://www.atsc.army.mil/itsd/imi/TestingTools.asp.

Sample Army Meta-data templates can be obtained from http://www.atsc.army.mil/itsd/imi/scorm_examples.asp.

6.1 Army Meta-data Requirements

Meta-data is required by the Army for Content Aggregations and SCOs. SCORM defines requirements for each of the meta-data types. (CAM 2.2.4.4)

6.2 Context Specific and Context Independent Meta-data

Content Aggregation meta-data should be "context specific" meta-data because it describes learning content in a particular context pertinent to the course structure.

SCO meta-data should be "context independent" because it describes learning content in an independent manner and not in the "course context" of where the content is presently used. This allows the meta-data of SCOs to be searched, and the learning content to be shared, re-used and/or repurposed.

6.3 XML Binding for Separate Meta-Data Files

6.3-1 BUSINESS RULE (ARMY): Separate meta-data files referenced from the Manifest using the SCORM required XML binding must be used for Army-required Content Aggregation and SCO meta-data. The XML binding to be used within the Manifest that references the relative path for the separate XML meta-data file is shown below.

<schema>ADL SCORM</schema>

<adlcp:location>[relative path from the imsmanifest.xml file to the metadata file]</adlcp:location>

</metadata.

Figure 6.3a

An example of "relative path from the imsmanifest.xml file" is shown below:

If the physical file structure is:

unitsafety folder

metadata folder

sco1 folder

sco2 folder

images folder

references folder

glossary folder

imsmanifest.xml file

imscp_rootv1p1p2.xsd

ims_xml.xsd

imsmd_rootv1p2p1.xsd

adlcp_rootv1p2.xsd

If the meta-data file name is sco1_metadata.xml and located in the "metadata" folder, then, using this scenario, the <adlcp:location> tag within the Manifest would be "metadata/sco1_metadata.xml", which is the path from the location of the imsmanifest.xml file to the sco1_metadata.xml file.

In essence, a meta-data reference is contained within the Manifest file and the actual meta-data XML file is located within the physical files.

The "images" folder as shown above can contain all of the images for the package. The images do not have to be in separate folders. Resources for the package can be stored either in the root or in any sub-folder in the package. In the above file structure, any SCO can be extracted and reused in another aggregation.

6.4 Recognizing the 4 Different Types of Meta-data

The four types of Meta-data are:

· Package Level Meta-data

· Content Aggregation Meta-data

· SCO Meta-data

· Asset Meta-data

The Army does not require Package Level or Asset Meta-data, but does require the other two types: namely, Content Aggregation and SCO. Content Aggregation meta-data is located in the <organizations> section within the Manifest file, and SCO meta-data is located in the <resources> section within the Manifest file.

6.4.1 Package Level Meta-data File

Package level meta-data describes the entire SCORM package and enables discoverability on the package. The Army does not require package level meta-data but courseware will not be rejected if this type of meta-data is included either inline within the Manifest or external to the Manifest.

The XML binding for package level meta-data is shown below as an external file:

<metadata> (package level meta-data)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/pkg_unitsafety.xml</adlcp:location>

</metadata>

...

</manifest>

Figure 6.4.1a

6.4.2 Content Aggregation Meta-data Files

6.4.2-1 BUSINESS RULE (ARMY): Content Aggregation Meta-data is required for each Content Aggregation within a SCORM Package.

Content Aggregation Meta-data is located in the <organization> section within the Manifest file. It describes and provides information about the course structure in the organization section as a whole.

Below is an example of the placement of Content Aggregation Meta-data:

<organization> (opening tag for organization content aggregation)

</item>

<metadata> (content aggregation meta-data for <organization>)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/ca_unitsafety.xml</adlcp:location>

</metadata>

</organization> (closing tag for organization content aggregation)

Figure 6.4.2a

Content Aggregation meta-data is required for each <organization>, shown here as ca_unitsafety.xml.

6.4.3 SCO Meta-data Files

6.4.3-1 BUSINESS RULE (ARMY): SCO Meta-data (context independent) is required for each SCO within a SCORM Package.

SCO (context independent) Meta-data required by the Army is located in the <resource> section within the Manifest file. Example of the placement of SCO Meta-data:

<metadata> (SCO meta-data)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/unit.xml</adlcp:location>

</metadata>

</resource>

Figure 6.4.3a

6.4.4 Asset Meta-data Files

Though not required by the Army, the developer may choose to develop asset meta-data for all or specific assets in the courseware. If asset meta-data is developed and included within the SCORM package, it must be SCORM conformant.

Below are examples to help in the understanding of the placement of asset meta-data:

6.4.4.1 Example of the placement of Asset Meta-data when asset used only in one SCO

<metadata>…</metadata> (SCO meta-data)

<metadata> (asset meta-data)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/unit/A_index.xml</adlcp:location>

</metadata>

</file>

<metadata> (asset meta-data)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/a_page2.xml</adlcp:location>

</metadata>

</file>

</resource>

Figure 6.4.4.1a

6.4.4.2 Example of the placement of Asset Meta-data when one asset used in many SCOs and referenced with a <dependency> tag within the SCO resources

<metadata>…</metadata> (SCO meta-data)

<dependency identifierref="R_101"/>

</resource>

<schema>ADL SCORM</schema>

<adlcp:location>metadata/a_r101.xml</adlcp:location>

</metadata>

</file>

</resource>

Figure 6.4.4.2a

6.4.4.3 Example of the placement of Asset Meta-data where many assets are used in many SCOs and referenced with a <dependency> tag within each SCO resource

<metadata>…</metadata> (SCO meta-data)

<dependency identifierref="R_211"/>

</resource>

<metadata> (asset Meta-data)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/img001.xml</adlcp:location>

</metadata>

</file>

<metadata> (asset Meta-data)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/img002.xml</adlcp:location>

</metadata>

</file>

<metadata> (asset Meta-data)

<schema>ADL SCORM</schema>

<adlcp:location>metadata/img003.xml</adlcp:location>

</metadata>

</file>

</resource>

Figure 6.4.4.3a

6.5 Developing SCORM Meta-Data

To develop your meta-data, here is an example of a SCORM external meta-data file with tags required by the Army. The SCORM meta-data tags required by the Army are listed as a Business Rule (Army) and explained further in this section with sample values and examples. See SCORM v1.2 Content Aggregation Model document for clarification from the SCORM perspective.

Here is a macro example of how a separate meta-data file would look like:

<?xml version="1.0" encoding="UTF-8">

<lom>

<general>...</general>

<lifecycle>...</lifecycle>

<metametadata>...</metametadata>

<technical>...</technical>

<rights>...</rights>

<classification>...</classification>

</lom>

Figure 6.5a

6.5.1 general.title

6.5.1-1 BUSINESS RULE (ARMY): The general.title meta-data element describes the name given to the learning resource. For SCOs or Content Aggregations, this value must contain the same title used in the Manifest file or as similar as possible.

<title>

<langstring xml:lang="en">Introduce Basic M60 Machine Gun Training</langstring>

</title>

…

</general>

Figure 6.5.1a

6.5.2 general.catalogentry

6.5.2-1 BUSINESS RULE (ARMY): The general.catalogentry meta-data element contains two sub-elements: catalog and entry. These two sub-elements will designate the catalog and entry identification used by the Government (ATSC) to store the courseware after delivery. Catalog element must be "ATIA". Entry element must be "TBD".

…

<entry>

</entry>

</catalogentry>

…

</general>

Figure 6.5.2a

6.5.3 general.description

6.5.3-1 BUSINESS RULE (ARMY): The general.description meta-data element must contain a general description of the object for Content Aggregations and SCOs. This element must exclude any reference to hierarchy (lesson, phase, module, etc.).

Enter a full description of the object so that when selected within search results, the description would provide information to determine whether the instructional object would meet the qualifications.

For Content Aggregations:

    <description>
    <langstring xml:lang="en"> Basic instruction on U.S. Army Infantry M60 Machine Gun laying using field expedients, range card preparation, maintenance, function check performance, loading, unloading, malfunction corrections and target engaging.
      </langstring>
    </description>

For SCOs:

       <description>
    <langstring xml:lang="en">Explanation of the field expedient method of laying an M60 on preselected targets using the notched stake/tree crotch method
      </langstring>
  </description>

Figure 6.5.3a

6.5.4 general.keyword

6.5.4-1 BUSINESS RULE (ARMY): The general.keyword meta-data element contains keywords or phrases describing this learning resource. One or more keyword elements are derived from description. Enter words and phrases that accurately and precisely define the object.

Best Practice: The keywords most relevant should be listed first in the general.keyword meta-data element.

It is up to the content developer to determine what is represented as this string value.

<langstring xml:lang="en">Infantry

</langstring>
</keyword>

<langstring xml:lang="en">M60 laying using field expedients

</langstring>
</keyword>

<langstring xml:lang="en">Notched Stakes

</langstring>
</keyword>

Figure 6.5.4a

6.5.5 general.aggregationlevel

6.5.5-1 BUSINESS RULE (ARMY): The general.aggregationlevel meta-data element must designate which of the four types of resources the meta-data is describing. Separate meta-data files that are apart from the Manifest have no designator as to the type of learning resource described and, therefore, testing requirements cannot be determined.

The SCORM specification states that this data element container describes the "functional granularity of this learning resource. The vocabularies defined for this element are restricted vocabularies as follows: "1" to indicate the smallest level of aggregation, e.g. raw media data or fragments; "2" to indicate a collection of atoms, e.g. an HTML document with some embedded pictures or a lesson; "3" to indicate a collection of level 2 learning resources, e.g. a 'web' of HTML documents, with an index page that links the pages together or a course; "4" to indicate the largest level of granularity, e.g. a set of courses that lead to a certificate". (CAM 2.2.3.1.1.9)

Since there are four types of learning resources contained in SCORM, the Army has interpreted the above vocabulary to mean the following:

"1" indicates that an asset is being described

"2" indicates that a SCO is being described

"3" indicates that a Content Aggregation is being described

"4" indicates that a Package is being described

Below is an example of the aggregation level meta-data tag for SCO meta-data:

...

</source>

<value>

</value>

</aggregationlevel>

...

</general>

Figure 6.5.5a

6.5.6 lifecycle.version

6.5.6-1 BUSINESS RULE (ARMY): The lifecycle.version meta-data element describes the edition of the learning resource. Initial version will be 1.0. Corrections will change minor version number; enhancements/updates will change major version number. This element upon initial final delivery to the Army must contain the value "1.0".

Example: 1.0 for a major change or 1.1 for a minor change.

</version>

…

</lifecycle>

Figure 6.5.6a

6.5.7 lifecycle.status

6.5.7-1 BUSINESS RULE (ARMY): The lifecycle.status meta-data container element must contain the element "source" equal to "LOMv1.0" and the element "value" equal to "Final".

…

</source>

<value><langstring xml:lang="x-none">Final</langstring>

</value>

</status>

…

</lifecycle>

Figure 6.5.7a

6.5.8 lifecycle.contribute.role

6.5.8-1 BUSINESS RULE (ARMY): The lifecycle.contribute.role meta-data container element describes the kind of contribution. It must contain the element "source" equal to "LOMv1.0" and the element "value" equal to "Publisher", which will denote that the Proponent authored the learning resource being described.

…

<role>

</source>

<value>langstring xml:lang="x-none">Publisher</langstring>

</value>

</role>

…

</contribute>

</lifecycle>

Figure 6.5.8a

6.5.9 lifecycle.contribute.centity.vcard

6.5.9-1 BUSINESS RULE (ARMY): The lifecycle.contribute.centity.vcard meta-data element identifies the organization contributing to this resource according to the vCard specification located at http://www.imc.org/pdi/pdiproddev.html. This value must contain the full name and address of the Proponent institution according to the vCard specification.

Example of the vCard format is as follows:

…

…

<vcard>BEGIN:VCARD VERSION:2.1N:U.S. Army Infantry School

ORG:U.S. Army;Army Infantry School;Fort Benning NOTE:071

ADR;DOM;WORK:Suite 650;6751 Constitution Loop;Fort Benning;GA;31905-4502;U.S. EMAIL;INTERNET:soldierinfo@benning.army.mil END:VCARD

</vcard>

</centity>

…

</contribute>

</lifecycle>

Figure 6.5.9a

The "NOTE" field has been designated as the method for identifying the school code. A listing of all school codes are contained in TRADOC Reg 350-70, Appendix C, section C-2.

6.5.10 lifecycle.contribute.date

6.5.10-1 BUSINESS RULE (ARMY): The lifecycle.contribute.date meta-data container element describes the creation date of the contribution. This element must contain the object’s creation date using the SCORM designated format of YYYY-MM-DD.

The value specified in this field may not be interpreted exactly the same by each contributor, however, as time goes by, this date will be used to reflect a SCORM object’s age.

…

…

<date>

</date>

</contribute>

</lifecycle>

Figure 6.5.10a

6.5.11 metametadata.metadatascheme

6.5.11-1 BUSINESS RULE (ARMY): The metametadata.metadatascheme meta-data element identifies the name and version of the authoritative specification used to create this meta-data instance. This value must be "SCORM v1.2".

All meta-data contained within the package must be SCORM v1.2 conformant. Meta-data using the IMS or any other specification is not SCORM conformant.

<metadatascheme>SCORM v1.2</metadatascheme>

</metametadata>

Figure 6.5.11a

6.5.12 technical.format

6.5.12-1 BUSINESS RULE (ARMY): The technical.format meta-data element identifies technical data types of this resource by using the Multipurpose Internet Mail Extensions (MIME). This element must contain all MIME types that are used in the learning resource being described.

MIME types are used to identify the software needed to access the resource. Browsers use MIMEs in the same way they use legends. If a browser received some content with a unique file extension, it looks in its list of MIME types to help it identify the content. The syntax of MIME types is as follows: type + "/" + subtype. These types are then associated with file extension. For more details on MIME types, go to

http://www.mhonarc.org/~ehood/MIME/MIME.html OR

http://www.iana.org/assignments/media-types/index.html for an official list maintained by the Internet Assigned Numbers Authority (IANA).

<format>text/plain</format>

<format>image/gif</format>

<format>image/jpeg</format>

<format>application/x-shockwave-flash</format>

...

</technical>

Figure 6.5.12a

6.5.13 technical.location

6.5.13-1 BUSINESS RULE (ARMY): The technical.location meta-data element identifies where the learning resource described by this meta-data instance is physically located. This value must be a relative address to the location of the meta-data file. Use of the absolute address is allowed for reference to resources external to the package. For Content Aggregations, point to the highest level folder that encapsulates all of the other resources. For SCOs, point to the launch file.

Meta-data Type

Example

Content Aggregations

Point to highest level folder that encapsulates all the resources

…

../mod1

</location>

</technical>

SCOs

Location would be the path to the launch file of SCO relative to the location of the meta-data file

…

../sco1/safety/sf10/sf100.html </location>

</technical>

Figure 6.5.13a

6.5.14 rights.cost

6.5.14-1 BUSINESS RULE (ARMY): The rights.cost meta-data container element describes whether use of the resource requires payment. This element must have the "source" element equal to "LOMv1.0" and the "value" element equal to "no".

<cost>

</cost>

…

</rights>

Figure 6.5.13a

6.5.15 rights.copyrightandotherrestrictions

6.5.15-1 BUSINESS RULE (ARMY): The rights.copyrightandotherrestrictions meta-data element indicates whether copyright or other restrictions apply to the use of this resource. This value must be the "source" element equal to "LOMv1.0" and the "value" element equal to "no".

All copyright releases should be obtained before submission of courseware. Material must be unclassified. Material should have no "NOFORM" restrictions.

…

<source><langstring xml:lang="x-none">LOMv1.0

</langstring></source>

<value><langstring xml:lang="x-none">no

</langstring></value>

</copyrightandotherrestrictions>

</rights>

Figure 6.5.15a

6.5.16 classification

6.5.16-1 BUSINESS RULE (ARMY): The classification container element describes where this resource is placed within a particular classification system. To define multiple classifications, there may be multiple instances of this category. This classification container element must have three (3) sub-elements per classification instance, namely, "purpose", "description" and "keyword". Include one instance each for MOS & Skill Level, Tasks, Learning Objectives, Accessibility Restrictions and Security Level. If courseware is classified by a SQI or ASI or other classification, then one instance each must also be provided.

The classification.purpose best practice vocabulary relates to Army terms as follows:

Best Practice Vocabulary	In Army terms
Discipline	MOS & Skill Level
Discipline	SQI
Discipline	ASI
Educational Objective	Tasks
Educational Objective	Learning Objectives
Accessibility Restrictions	508 compliant or not
Security Level	Foreign Disclosure

Figure 6.5.16a

For an MOS and Skill Level, enter the MOS and Skill Level and textual description of the MOS for which the object was designed. Below is an example of this classification instance:

</source>

<value>

<langstring xml:lang="x-none">Discipline</langstring>

</value>

</purpose>

<langstring xml:lang="en">11C2 Indirect Fire Infantryman</langstring>

</description>

<langstring xml:lang="en">Indirect Fire Infantryman</langstring>

</keyword>

</classification>

Figure 6.5.16b

For an SQI, enter the SQI and textual description for which the object was designed. Below is an example of this classification instance:

</source>

<value>

<langstring xml:lang="x-none">Discipline</langstring>

</value>

</purpose>

<langstring xml:lang="en">E Mountaineer</langstring>

</description>

<langstring xml:lang="en">E Mountaineer</langstring>

</keyword>

</classification>

Figure 6.5.16c

For an ASI, enter the ASI and textual description for which the object was designed. Below is an example of this classification instance:

</source>

<value>

<langstring xml:lang="x-none">Discipline</langstring>

</value>

</purpose>

<langstring xml:lang="en">Q6 Long Range Surveillance Leader</langstring>

</description>

<langstring xml:lang="en">Long Range Surveillance Leader</langstring>

</keyword>

</classification>

Figure 6.5.16d

For Tasks, enter the list of task numbers and titles of the critical tasks for which this SCO/Aggregation provides training or support. Below is an example of this classification instance:

</source>

<value>

<langstring xml:lang="x-none">Educational Objective</langstring>

</value>

</purpose>

<langstring xml:lang="en">071-312-3003 Lay An M60 Machine gun Using Field Expedients; 071-312-3007 Prepare A Range Card For An M60 Machine gun; 071-312-3025 Main An M60 Machine Gun</langstring>

</description>

<langstring xml:lang="en">Field Expedients</langstring>

</keyword>

<langstring xml:lang="en">Range Card</langstring>

</keyword>

</classification>

Figure 6.5.16e

For Learning Objectives, enter the Action, Condition and Standard for which this SCO/Aggregation provides training or support. Below is an example of this classification instance:

</source>

<value>

<langstring xml:lang="x-none">Educational Objective</langstring>

</value>

</purpose>

<langstring xml:lang="en">Action: Lay An M60 Machine gun Using Field Expedients; Condition: Given Interactive Multimedia Instruction; Standard: The standards are met when the student has completed the IMI lesson and achieved a passing score on a separately administered test.</langstring>

</description>

<langstring xml:lang="en">M60 Machine gun using Field Expedients</langstring>

</keyword>

</classification>

Figure 6.5.16f

For accessibility, enter whether or not this object supports 508 compliancy. The values for "description" are "508 Compliant" or "Not 508 Compliant" and the values for "keyword" are "508", "PL508" or "accessibility restrictions". Below is an example of a classification instance:

</source>

<value>

<langstring xml:lang="x-none">Accessibility Restrictions</langstring>

</value>

</purpose>

<langstring xml:lang="en">508 Compliant</langstring>

</description>

</keyword>

</classification>

Figure 6.5.16g

For Foreign Disclosure, the following is an example of a classification instance:

</source>

<value>

<langstring xml:lang="x-none">Security Level</langstring>

</value>

</purpose>

</description>

</keyword>

</classification>

Figure 6.5.16h

The Foreign Disclosure restriction code is in accordance with provided policy and FD code tables below.

6.5.17 Policy on Tagging SCORM Objects with Foreign Disclosure Restrictions

The rules must address the Army's learning hierarchy and be consistent with the published guidance.

1. For automated presentation/restriction/sharing of material, FD restrictions are determined and applied at the lesson level. For completeness in content description (i.e., informational purposes), XML tags will include "course FD" restrictions; or the words “Public Domain”, which will allow the deliver and release of that object to anyone without restriction.

2. All objects will have a FD restriction statement or “Public Domain” assigned to them IAW the rules below and the matrices above.

3. If the lesson (and all SCOs/assets in the lesson) has no Controlled Unclassified Information (CUI) or Classified Military Information (CMI), then the lesson is labeled “Public Domain”; if the lesson contains CUI/CMI, then the FD description which fits the lesson is assigned (and all parts of the lesson are assigned that designator). If all lessons in a module are “Public Domain” (i.e., no CUI/CMI) then the module is ‘Public Domain”. If all lessons in a phase are “Public Domain”, then the phase is “Public Domain”. If all lessons in a course are “Public Domain”, then the course is “Public Domain”.

4. For course/phase level (IAW Army guidance) aggregations, use FD restrictions 1-4 with default to FD1. For module-level, lesson-level aggregations, SCOs, and assets use FDs restrictions 5-7 (with default to FD5).

NOTE: While restrictions are initially determined at lesson level, in general, it is NOT correct to think that these lesson-level restrictions can be "rolled-up" to higher levels. If we did so we would unnecessarily restrict access to lessons which have no access restrictions by the FD rules.

5. Specific Rules: See Figure 6.5.17a.

6. ALL objects within a lesson (SCOS/Assets) will have the same FD level assigned as that of the lesson aggregation of which they are a part (i.e., roll-down lesson FD to all objects within lesson). In particular, a lesson which is determined to be FD7, all objects within that lesson must be FD7. We cannot/will not try to differentiate smaller objects which may/or may not have CUI information. See Table 2.

7. If the proponent determines that lack of foreign learner access to a restricted lesson will make worthless the training provided in the entire module, the proponent will use the FD restrictions 6 or 7 at module level to indicate this (use of 6 or 7 is determined by using the FD restriction of the most restrictive lesson within that module). If the foreign learner can profit from the contents of the module without the lesson(s) which s/he cannot take, the module will be tagged as FD5 (and FD access restrictions will be determined at lesson level).

8. Stand-alone training products (i.e., a lesson, module, or group of modules) will be tagged with the appropriate restrictions using FD5-7 or “Public Domain”.

Learning Object FD Code Assignment Table 1, Ver 1.0, April. 03
Purpose: Implementation of these codes will allow appropriate delivery, avoid FD delivery violations, and maximize reusability. Rule of Thumb: A code assigned to an aggregation object means all objects within that aggregation are restricted in the same way (although the phase and course codes differ from the module, lesson and lower codes.
If	Then	Then	And	Notes/Caveats
Any SCO or asset within a lesson contains CUI./CMI	The lesson must have an FD designator.		All other parts of the lesson have the same FD designator as that assigned to the lesson.	Lesson FD roles down to all parts.
There is no CUI/CMI in an object, then	that object is “Public Domain”			A lesson, module, phase, or course might be Public Domain if ALL of their parts are “Public Domain”.
If there is CUI/CMI in at least one lesson	The rules for FD assignment below apply to that lesson, its parts, and aggregates.
All lessons in the course are FD5	Module FD code is FD5	All phases have code FD1	Course Assignment code is FD1	Best and most likely case.
Any lesson in any one module is FD7	The module can be either FD 5, 6, or 7 as appropriate (no rollup)	The phase containing the module can be FD2, 3, or 4, as appropriate. Cannot be FD1	Course assignment can be FD 2, 3, or 4. Cannot be FD1	All other modules/phases are determined by their lessons’ FD #.
All lessons in a module are FD7	The module is FD7	The phase containing the module can be FD2, 3, or 4. Cannot be FD1	Course assignment can be FD 2, 3, or 4. Cannot be FD1	Will occur when the CUI is concentrated in a single module.
All lessons in all the modules in a single phase are FD7	All modules within that phase are FD7.	The particular phase is FD4. Other phases are whatever is appropriate.	Course can be FD 2, 3, or 4. Cannot be FD1	Will occur when all the CUI is concentrated in a single phase of a course.
All lessons in all the modules in all phases are FD7	All modules within all phases are FD7.	All phases in the course are FD3.	The course is FD3	Will occur when an entire course is not releasable to any foreign learners.
If any lesson is FD6	Module may be FD6 or 7, whichever is appropriate. Cannot be FD5	1. The phase containing any FD6 lesson may be FD2, FD3, or FD4 depending on the other lessons in the phase. 2. The phase cannot be FD1.	The course can be FD 2, 3, or 4 based upon the other lessons in the course.	Will occur when all the CUI is concentrated in some number of lessons of a course and those lessons are releasable to some foreign learners. Other lessons may be more, less, or of equal FD restriction.
All lessons in module are FD6	The Module is FD6	1. The phase containing FD6 lessons is not less than FD2. 2. The phase may be FD3 or FD4 depending on the other modules in that phase.	The course can be FD2, 3, or 4 based upon the other lessons in the course.	Will occur when all the CUI is concentrated in a single module of a course and releasable to some foreign learners.
All lessons in all modules in all phases are FD6	Module is FD6	All phases are FD2.	The course is FD2	Will occur when all lessons contain CUI and the course is releasable to some foreign learners.

Table 2

Learning Object FD Code Assignment Table 2, (SCOs and Assets), Ver 1.0, Apr 03
If Lesson FD Assignment is	Then all SCOs within that lesson must be and are assigned
Public Domain	Public Domain
FD5	FD5
FD7	FD7
FD6	FD6

Figure 6.5.17b

7 Packaging

SCORM v1.2 specifications state: "The purpose of Content Packaging is to provide a standardized way to exchange digital learning resources between different systems or tools. The Content Aggregation Package contains a Manifest file describing the entire package and all physical files, both of which must be compressed into a Package Interchange file.

7-1 BUSINESS RULE (SCORM): A package must contain one imsmanifest.xml file and all of the SCORM and extension schemas in the root of the package. All physical files referenced locally required for the courseware must be contained within the content package and disclosed on the imsmanifest.xml file. It is required that the Manifest file name be "imsmanifest.xml" and must be in all lowercase letters. If meta-data is supplied as separate files, these files must be contained within the content package and disclosed on the imsmanifest.xml file.

A SCORM package contains an XML Manifest file, SCORM and extension schemas and all the physical files local to the package. One and only one Manifest file is contained within the root of a package. In the absence of this file, the package is not a SCORM package and cannot be processed.

Components of a SCORM package are shown in the diagram below:

Figure 7a

7.1 Packaging for the ILMS

The ILMS is a system primarily used for the Army Correspondence Course Program (ACCP). The system has been modified to play Interactive Multimedia Instruction (IMI) with the addition of a SCORM compliant LMS component (Aspen v1.1).

The ILMS is not concerned about what happens inside the SCO, but is concerned about how many objects per Package, whether a score is sent to the ILMS, and which lesson status is sent.

What is important to the ILMS

How many Scores are sent within this Package?

How many SCOs are in this Package?

Is a Score sent?

What Lesson Status is sent?

Package

SCO

Figure 7.1a

7.2 Packaging for the ALMS

A standard procedure for packaging for the ALMS when developing at the module level usually includes three packages containing: 1) the pretest; 2) the content; and 3) the post test. This section will be further defined when the testing version of the ALMS comes online.

7.3 Packaging Instructions for Testing/Instructional Strategies

The testing strategies identified in the Design Section will have specific content packaging that enable the courseware to play as intended.

Identify your testing strategy in the chart and note the Strategy Paragraph number. Then, locate the strategy paragraph number below the chart for information to determine how to package your courseware:

Strategy Paragraph #

Strategy

Content

Test

Capable

Reach Back

Content Tracking

Pre-test

Post-test

ILMS

ALMS

Unlimited

Restricted

Limited Attempts

Unlimited Attempts

Lock-out

Limited Attempts

Unlimited Attempts

Lock-out

Tracking

7.3.1

Content Completion Required/Student Performance Tests with Lock-Out

7.3.2

Content Completion Not Required/Student Performance Tests with Lock-Out

7.3.3

Content Completion Required/Student Performance Tests with Internal Testing Logic

7.3.4

Read-ahead Packages (No Student Performance Tests) Content Completion Not Required

7.3.5

Read-ahead Packages (No Student Performance Tests) Content Completion Required

Figure 7.3a

* Pretest is not supported

7.3.1 Content Completion Required/Student Performance Tests with Lock-out

For the ILMS:

Figure 7.3.1a

Figure 7.3.1b

7.3.2 Content Completion Not Required/Student Performance Tests with Lock-Out

For the ILMS:

Figure 7.3.2a

Figure 7.3.2b

7.3.3 Content Completion Required/Student Performance Tests with Internal Testing Logic

For the ILMS:

Figure 7.3.3a

Figure 7.3.3b

Note: Multiple versions of the Student performance test would be in one SCO and not multiple Post test SCOs containing one version.

7.3.4 Read-Ahead Packages (No Student Performance Tests) Content Completion Not Required

For the ILMS:

Figure 7.3.4a

Read-Ahead Packages (No Student Performance Tests) Content Completion Not Required

Figure 7.3.4b

7.3.5 Read-Ahead Packages (No Student Performance Tests) Content Completion Required

For the ILMS:

Figure 7.3.5a

Figure 7.3.5b

7.4 How to Create a Content Package per the SCORM Implementation Guide (http://www.adlnet.org):

1. Determine whether you want to package the files as a PIF.

2. PIF – Package Interchange File is a representation of the content package components using the PKZIP Version 2.04g archive format (zip). It is not mandatory that a content package be archived as a PIF. The PIF provides a concise Web delivery format that can be used to transport content packages between systems (zipped).

3. Non-PIF – File structure to be used on a CD-ROM or other file system.

4. Place the "imsmanifest.xml" file at the root level of the package.

5. Place all schemas referenced by the manifest at the root level of the package.

6. Place all physical files needed by the packaged courses, lessons, etc. where you refer to them in your manifest.

7. If using a PIF, compress and save using the PKZIP Version 2.04g standard.

8. Test the newly created package using the Content Package test of the Conformance Test Suite.

9. If the content packages pass the conformance test, import it into the ILMS/ALMS or system for use.

7.5 Creating the Manifest File

7.5-1 BUSINESS RULE (SCORM): Every SCORM Package must contain a Manifest file. The Manifest File must be located in the root of the Package and named "imsmanifest.xml".

The Manifest file is the most important file in the package. Specific data on the Manifest file is read into the Learning Management System. The ILMS/ALMS uses this file to determine the Table of Contents to display and launch file for each SCOs. Content Repositories use this file in aggregating and de-aggregating packages. Meta-data is determined and accessed by using the information from this file.

7.5.1 Two Types of Manifest Files

7.5.1-1 BUSINESS RULE (ARMY): A Content Aggregation Manifest file containing the XML tagged Table of Contents must be submitted with each SCORM package.

There are two types of Manifest files: Content Aggregation Manifest file or a Resource Package Manifest file. A Content Aggregation Manifest contains an <organizations> section, which describes a distinct course structure such as a Table of Contents. A Resource Package does not contain an <organizations> section and, therefore, no Table of Contents, and only provides a method of transferring learning resources that are not within a learning context.

The Army does not anticipate receiving Resource Packages as courseware deliverables.

The diagram below shows the differences between the two different types of Manifest files:

Figure 7.5.1a

7.5.2 Table of Contents contained within the Manifest File

The <organizations> section describes one or more content aggregations represented by the <organization> tag. Each <organization> tag specifies a distinct content structure such as a Table of Contents.

The Table of Contents appears in the ILMS/ALMS as shown below from ADL sample Maritime Navigation course:

Maritime Navigation

Inland Rules of the Road (HTML Format)

References and Lesson Objective

Steering & Sailing Rules

Conduct of Vessels in any Condition of Visibility

Conduct of Vessels in Sight of One Another

Conduct of Vessels in Restricted Visibility

Lights & Shapes

Sound & Light Signals

Exam

Figure 7.5.2a

The <organization> tag describes the Table of Contents for the learning material. The XML tagging of the Table of Contents within the Manifest file is shown below.

Figure 7.5.2b

7.5.3 ADL Extensions to the Manifest File

Specific SCO data can be designated on the Manifest file that is external to the SCO. SCORM provides this capability known as the ADL Extensions. This would facilitate reusability in that there is no need to re-author content just to change certain values such as the mastery score or the maximum time allowed.

The following describes and provides an example of the ADL extensions to the IMS specifications contained within the Manifest file:

Manifest Tag	Description
adlcp:mastery_score	The passing score for an assessment. Numeric value located outside of the SCO within the Manifest. Easily changed for SCO re-use. The ILMS does not support this value. The ALMS does support this value.
adlcp:prerequisites	This element defines what other parts of the learning content must be completed before starting this lesson. This tag is not recommended because it is not supported by most SCORM compliant LMSs.
adlcp:maxtimeallowed	The amount of time the Student is allowed in the current attempt of the SCO
adlcp:timelimitaction	What action to take when the maximum time allowed is exceeded.
adlcp:datafromlms	Unique information generated at the SCOs creation that is needed for every use.

Figure 7.5.3a

Example of the ADL extensions within the Manifest file:

…

<title>SCO Title</title>