IEEE P1484.11.3/D5, 2001-03-15
Draft Standard for Learning Technology —
HTTP-Bbased Content to LMS
Communications Protocol Binding
Sponsored by the Learning Technology Standards Committee
of the IEEE Computer Society
Copyright © 2001 by the Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue
New York, NY 10016-5997, USA
All rights reserved.
This is an unapproved draft of a proposed IEEE Standard, subject to change. Permission is
hereby granted for IEEE Standards Committee participants to reproduce this document for
purposes of IEEE standardization activities. If this document is to be submitted to ISO or IEC,
notification shall be given to the IEEE Copyright Administrator. Permission is also granted for
member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position. Other entities seeking permission to reproduce this
document for standardization or other activities, or to reproduce portions of this document for
these or other uses, must contact the IEEE Standards Department for the appropriate license.
Use of information contained in this unapproved draft is at your own risk.
IEEE Standards Department
Copyright and Permissions
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331, USA
[Note: Information about IEEE LTSC P1484.11 can be found at:
http://ieee.ltsc.org/wg11
This note will be removed upon reaching the final draft of this IEEE document.]
2001-03-15
P1484.11.3D5
Introduction
(This introduction is not part of IEEE P1484.11.3, HTTP-Based Content to LMS Communications Protocol Binding.)
** TO BE SUPPLIED **
_________________________________________________________________________
At the time this Standard was completed, the working group had the following membership:
Jack Hyde, Chair
Scott Lewis, Technical Editor
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
ii
2001-03-15
aaa
Carlos. C Amaro
Debbie Brown
Phil Dodds
Frank Farance
Mike Force
Chad Kainz
Cindy Mazow
Bill McDonald
Bill Melton
Kiyoshi Nakabayashi
Claude Ostyn
Bruce Peoples
Dan Rehak
Tyde Richards
Kevin Riley
Robby Robson
Kathy Sinitsa
Josh Tonkel
Brendon Towle
John Tyler
zzz
To be supplied
P1484.11.3D5
The following persons were on the balloting committee: (To be provided by IEEE editor at
time of publication.)
_________________________________________________________________________
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
3
2001-03-15
P1484.11.3D5
Contents
1 Overview...........................................................................................................................6
1.1 Scope..........................................................................................................................6
1.2 Purpose.......................................................................................................................6
1.3 Rationale.....................................................................................................................7
2 Normative references........................................................................................................8
3 Definitions.........................................................................................................................9
4 CMI/CBT communications overview for HTTP...........................................................10
4.1 Data for CMI and CBT communication......................................................................10
4.2 Communication data protocol: HTTP.........................................................................11
4.3 Communication data formats......................................................................................11
4.4 Groups.......................................................................................................................12
4.5 Keywords..................................................................................................................12
4.6 Examples...................................................................................................................13
5 Launching CBT lessons..................................................................................................14
5.1 CBT AU URL command line.....................................................................................14
5.1.1 URL of the CBT AU...........................................................................................14
5.1.2 IEEE required parameters...................................................................................15
5.1.3 Web launch parameters.......................................................................................15
5.1.4 Launch line format..............................................................................................15
6 CBT/CMI communication session.................................................................................17
6.1 HTTP communication................................................................................................17
6.2 HTTP request message format...................................................................................18
6.3 HTTP response message format.................................................................................19
6.4 HTTP communication error messages........................................................................19
6.5 HTTP CMI protocol commands.................................................................................20
6.6 Web launch parameters..............................................................................................21
6.7 AU_Password............................................................................................................22
7 CBT/CMI Communication Information......................................................................23
7.1 Table description........................................................................................................23
7.2 [Core]........................................................................................................................26
7.2.1 Student_ID.........................................................................................................26
7.2.2 Student_Name....................................................................................................27
7.2.3 Lesson_Location.................................................................................................27
7.2.4 Credit..................................................................................................................28
7.2.5 Lesson_Status.....................................................................................................28
7.2.6 Score..................................................................................................................29
7.2.7 Time...................................................................................................................30
7.2.8 Mode..................................................................................................................31
7.3 [Core_Lesson]...........................................................................................................31
7.4 [Core_Vendor]...........................................................................................................31
7.5 [Comments]..............................................................................................................32
7.6 [Comments]...............................................................................................................32
7.7 [Objectives_Status]...................................................................................................33
7.7.1 J_ID.1.................................................................................................................33
7.7.2 J_Score.1............................................................................................................34
7.7.3 J_Status.4............................................................................................................35
7.8 [Student_Data]...........................................................................................................36
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
4
2001-03-15
P1484.11.3D5
7.8.1 Mastery_Score....................................................................................................36
7.8.2 Max_Time_Allowed...........................................................................................37
7.8.3 Time_Limit_Action............................................................................................37
7.9 [Student_Preferences]................................................................................................38
7.9.1 Audio..................................................................................................................38
7.9.2 Language............................................................................................................38
7.9.3 Speed..................................................................................................................39
7.9.4 Text....................................................................................................................39
7.10 [Interactions]............................................................................................................40
7.10.1 Interaction_ID...................................................................................................40
7.10.2 Objective_ID....................................................................................................41
7.10.3 Time.................................................................................................................41
7.10.4 Type_Interaction...............................................................................................41
7.10.5 Correct_Response.............................................................................................42
7.10.6 Weighting.........................................................................................................43
7.10.7 Student_Response.............................................................................................43
7.10.8 Result...............................................................................................................44
7.10.9 Latency.............................................................................................................44
8 Data type definitions.......................................................................................................45
9 Annex A: Document development (informative)...........................................................46
9.1 Revision history.........................................................................................................46
9.2 Release notes for this document.................................................................................46
9.3 Resolved issues..........................................................................................................46
9.4 Open issues................................................................................................................46
9.5 Comments on this document......................................................................................46
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
5
2001-03-15
1
P1484.11.3D5
Overview
Introduction
This standard indocument is a single part of a multipart standard that covers a current industry
practice called “CMI—Computer Managed Instruction.” This computer-managed instruction
(CMI) specification was originally developed by the AICC (Aviation Industry CBT Committee) (AICC).
This multipart Standard is divided into the following pieces:
•
•
•
•
•
•
•
1484.11.1: Data Model for Content to LMS Communication
1484.11.2: File-Based Content to LMS Communications Coding Binding
1484.11.3: HTTP-Based Content to LMS Communications Protocol Binding
1484.11.4: JavaScript Content to LMS Communications API Binding
1484.11.5: Content Structure Format Data Model
1484.11.6: Content Structure Format File-Based Coding Binding
1484.11.7: Content Structure Format XML Coding Binding
1.1 Scope
This part of the standard is Part 3: HTTP-Based Content to LMS Communications Protocol
Binding. This Ppart covers the protocol bindings that involve the communication of information via common messages using HyperText Transfer Protocol (HTTP). This Sstandard applies to the delivery of learning content over the World Wide Web.
The definitions of many terms used in this document and the definitions of all the data types
referred to in this document may be found in Part 1 of this standard: P1484.11.1: Data Model
for Content to LMS Communication.
1.2 Purpose
The CMI specifications have been implemented and adopted in commercial products in the
aviation industry. There is widespread acknowledgement that these specifications have broad
applicability in the area of learning management systems (LMS).
Part 1, Data Model for Content to LMS Communications (1484.11.1), provides more details
on the 1484.11 multipart Sstandard.
As a Web-based implementation, this Ppart of this Sstandard is applicable to multiple operating system environments. Conforming to this Ppart of this Sstandard in any one of these environments enables interoperability with all other CMI systems and courseware in the same environment.
This Ppart of this Sstandard is designed to have applicability to all systems using the Web for
communication between a client running computer-based training (CBT) and a server running
the CMI system.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
6
2001-03-15
This Ppart describes, in a web environment:
•
•
P1484.11.3D5
How CMI systems shall launch student activities, called lessons or sessions.
How CMI systems shall communicate over the Web with different CBT systems.
The implementation described in this chapter does not relate directly to a specific course interchange implementation. In other words, whether course interchange is via several common
text files or a single Extensible Markup Language (XML) file makes no difference to this
communication implementation.
1.3 Rationale
The IEEE standard for CMI/CBT communication can be implemented in many ways. Universal interoperability, while desirable, is not an easily achieved goal. Because of the myriad of
environments and special needs, different mechanisms may be defined for different industries
or interest groups to achieve local interoperability.
The HTTP protocol was specifically selected as a transport mechanism for CMI/CBT data for
the following reasons:
•
•
•
HTTP Web browsers and Web servers are widely used for training delivery.
HTTP is a hardware-platform independent protocol.
Most Internet security firewalls allow HTTP request/response messages passage
(as opposed to other internet protocols, such as TCP/IP Sockets or Internet InterORB Protocol (IIOP)
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
7
2001-03-15
2
P1484.11.3D5
Normative references
The following normative documents contain provisions whichthat, through reference in this
text, constitute provisions of this International Standard. For dated references, subsequent
amendments to, or revisions of, any of these publications do not apply. However, parties to
agreements based on this International Standard are encouraged to investigate the possibility
of applying the most recent editions of the normative documents indicated below. For undated
references, the latest edition of the normative document referred to applies. IEEE and members of ISO and IEC maintain registers of currently valid Standards.
•
•
IEEE 1484.3, Learning Technology Glossary.
IEEE 1484.11.1, Data Model for Content to LMS Communications.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
8
2001-03-15
3
P1484.11.3D5
Definitions
See: IEEE P1484.11.1/D5, Clause 3.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
9
2001-03-15
4
P1484.11.3D5
CMI/CBT communications overview for HTTP
HTTP is a client/server protocol. A client program, usually a Web browser, makes requests and
a server program, a Web server, responds to the requests. With the HTTP protocol, client and
server programs may be running on the same computer or on different computers at different
locations. Some portions of the CMI system run as part of the Web server and other portions
(the student user interface) run as part of the Web browser.
This Cclause describes how the data flows shall be implemented on the Internet. Data shall be
exchanged in an ASCII-text format as group/keyword data, which is an ASCII stream divided
into groups with keywords in most of the groups.
4.1 Data for CMI and CBT communication
As shown in Figure 1, Aa conforming implementation shall include the following data
streams.
•
•
CMI-to-CBT: This stream is created by the CMI system as it launches the CBT
lesson. This data stream is then read by the CBT lesson to get the student information it needs.
CBT-to-CMI: This stream is created by the CBT lesson as the student finishes it.
This data includes the information that the CMI system needs.
CMI System
Group/Keyword
Send
eceive
R
CMI
To
Lesson
Lesson
To
CMI
Group/Keyword
CBT Lesson
Figure 1 — CMI/CBT communications.
The data shall include the following general contents and format.
CMI-to-CBT:
•
•
Contents: Information needed by a lesson to function optimally.
Data format: Group/Kkeyword.
CBT-to-CMI:
•
Contents: Information needed by a CMI system to track student performance and
make new assignments.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
10
2001-03-15
• Data format: Group/Kkeyword.
P1484.11.3D5
4.2 Communication data protocol: HTTP
This chapter Subclause references the HTTP standard, and describes the IEEE protocol for the
HTTP commands necessary for the IEEE CMI implementation.
The HTTP 1.0 specification is described in RFC 1945.
Other related RFCs:
•
•
•
•
RFC 822 Standard for the Format of ARPA Internet Text Messages
RFC 1738 Uniform Resource Locators (URL)
RFC 1808 Relative Uniform Resource Locators
RFC 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
for Specifying and Describing the Format of Internet Message Bodies
4.3 Communication data formats
The data format used in the communication between the CMI system and CBT shall be a
group/keyword data stream as shown in Figure 2Table 1. The format supports three types of
data—group, keyword, and comment.
Table 1 — Communication formats
Appearance
[group]<cr>
keyword=parameter<cr>
; groups and keywords
; may have comments
Element name
Group
Valid Keyword
Comment
Each item shall be one of three types—group, keyword, or comment. Group and keyword
names shall be case insensitive. A name shall consist of alphanumeric and underscore characters.
Group names shall be left justified and surrounded by brackets. Keywords shall be left justified and followed by an equals sign (=). A line that begins with a semicolon shall indicate a
comment line.
Comments are text that is of use to a human viewing a file. Comments have no effect on processing. The first character of a comment line shall be a semicolon. All characters following
the semicolon up to and including the carriage return are part of the comment. Comments
shall be on a separate line from group names and keywords as shown in the following example.
[CORE]
LESSON_STATUS = Passed
LESSON_LOCATION = End
SCORE = 87
TIME = 00:25:30
; this is the core group of data
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
11
2001-03-15
P1484.11.3D5
;
;
;
;
this is the lesson performance data
for a passed lesson that required a
time of 25 minutes, 30 seconds and
a score of 87
4.4 Groups
Groups provide a mechanism for dividing a file into manageable segments that are more easily accessed by data retrieval routines. Groups also provide a means to organize a file of data
into logically related parts. Groups may be helpful for human processing of a file as well as
computer processing.
Groups are logically related assemblies of data items and may span more than one line. A
group extends from its group identifier to the next group identifier and may span multiple
lines. Although groups may contain keywords, they may not contain other groups.
All carriage returns and symbols between group identifiers may be significant depending on
the definition of the specific group. If a group contains keywords, then blank lines and extra
carriage returns shall be ignored.
A group shall be identified by its name enclosed by square brackets. The left bracket shall appear at the far-left margin or shall be preceded by spaces or tabs. No other characters shall precede the left bracket. The left bracket shall not be embedded in a line of information. The
group name shall be case insensitive.
Groups may appear in any order. Only the first occurrence of the group shall be meaningful.
Group name examples
[comments]
[OBJECTIVES_STATUS]
4.5 Keywords
Keywords are names of data items that are limited in size to a single line. The data item, including punctuation, shall not exceed 255 characters. The data items associated with a keyword are referred to as keyword arguments or keyword values.
Keywords shall appear at the left-hand margin followed by an equals sign. Spaces before and
after the equals sign shall be ignored. Keywords shall be case insensitive. Blank lines between
keywords shall be ignored.
Keywords shall be members of a group. An example of a group without a keyword is the
[COMMENT] group.
Each keyword within a single group shall be unique. If keywords are duplicated, only the first
shall be significant. Keywords may be extended to avoid duplicates by appending a period and
a simple integer number from 0 through 9999.
The ordering of keywords shall have no effect. In this document, many are ordered alphabetically for the convenience of the reader.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
12
2001-03-15
P1484.11.3D5
Keywords may be duplicated in different groups. For example, in the same file there is a
group called LESSON_DATA with a keyword ID, and a group STUDENT_DATA with a
keyword ID. These IDs are different.
4.6 Examples
The [Objectives_Status] group is an example of a group with multiple instances of a keyword requiring an extension. It has multiple objective ID's and a different status for each objective recorded in the group.
[Objective_Status]
J_ID.1= AB112
J_Status.1 = Pass
J_ID.2= AB124
J_Status.2 = Pass
J_ID.3= AB196
J_Status.3 = Fail
The first non-space character after the “=” identifies the beginning of the data. Capitalization
and spaces in the keyword data may or may not be significant, depending on the definition of
the data associated with a specific keyword.
Student_ID = JQH2142
OUTPUT_FILE=C:\STURECS\JQH2142.DTA
postal_code = 98124-2207
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
13
2001-03-15
5
P1484.11.3D5
Launching CBT lessons
In general, a Web-based CBT launch sequence is as follows:
1. The student selects a CBT AU to launch from the CMI system's user interface (Menu)
2. The CMI system pushes a Uniform Resource Identifier (URI) location, complete with
startup parameters, to the HTTP client
3. The HTTP client requests the CBT AU from the HTTP server.
4. The HTTP server program copies the program and data to the HTTP client program.
5. The CBT AU grabs the URI parameters from the HTTP client upon startup and initiates a session with the CMI system.
A typical launch sequence is shown in Figure 2.
HTTP Server
#2 CSD system sends
URI to HTTP Client
HTTP Client
#1 user requests and AU
from the CSD User Menu
#3 HTTP Client
Requests the AU
#4 Download the AU
To the HTTP Client
#5 The CBT AU
executes and grabs URI
parameters from HTTP
Client
Figure 2 — Web-based launch sequence
5.1 CBT AU URL command line
When the CMI system launches a CBT AU, it sends a URL command line to the HTTP Client
(e.g. Web browser). The command line contains three basic values.
•
•
•
The URL of the CBT AU
IEEE-required parameters
Web-launch parameters
5.1.1 URL of the CBT AU
The CBT URL is the globally unique address of the AU on the World Wide Web. The first part
of the address indicates what protocol to use.
Usage rules
•
•
The URL shall start with “http://”
The URL shall not contain a question mark (?).
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
14
2001-03-15
Examples
P1484.11.3D5
The two URLs below point to two different files at the domain sandybay.com
http://www.sandybay.com/cgi-bin/lesson.cgi /param1
http://www.sandybay.com/index.html
5.1.2 IEEE required parameters
Figure 4Table 2 gives the parameters that shall be used.
Table 2 — Required IEEE parameters
IEEE parameter
name
AICC_SID
Format
Alpha-numeric
Example:
Value
Session ID. This string uniquely identifies this
AU session among all other active CMI/CBT
AU sessions.
AICC_SID=1234WE9
The CMI system generates and passes this
value on AU launch.
AICC_URL
The AU uses this value to identify its session
when making requests to the CMI system.
The full URL including the protocol to which
the AU will send requests to the CMI system.
URL location
Example:
AICC_URL=
http%3A%2F%2Fcompany.c
om%2Fcgi-bin%2FCMI.cgi
This will likely be a Common Gateway
Interface (CGI) servlet program on a server.
This program acts as a CGI “catcher” for the
CMI system.
Required IEEE parameters.
Example
AICC_sid=123&AICC_URL=http%3A%2F%2Fcmi.net%2FCGIBin%2FCMI.cgi&vendorparam=this
Not URL encoded:
AICC_sid=123&AICC_URL=http://cmi.net/CGIBin/CMI.cgi&vendorparam=this)
5.1.3 Web launch parameters
Web-launch parameters are lesson specific. They are the character string that is appended to
the lesson file name in order to successfully launch an AU in the World Wide Web environment. The parameters are any additional parameters required by individual AUs.
5.1.4 Launch line format
The launch line shall have the form of:
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
15
2001-03-15
P1484.11.3D5
<URL of CBT AU>?<IEEE-required Parameter 1>&<IEEErequired Parameter 2>& <Web Launch Parameters >
Where:
•
•
•
•
<URL of CBT AU> is the HTTP location of the primary AU file needed for web
launch. (Note that it shall not include a question mark. Question marks shall be
used as IEEE command line separators only.)
<IEEE-required Parameter 1> represents either the AICC_SID or the
AICC_URL parameter as needed by the specific AU being launched. Parameter
requirements and rules are described in Subclause, 6.1.3, Web Launch Parameters.
<IEEE-required Parameter 2> represents either the AICC_SID or the
AICC_URL, whichever is not parameter 1.
<Web Launch Parameters> are those lesson-specific parameters found in the
WEB_LAUNCH field of the course interchange AU file.
The command line is a concatenation including two fields in the AU file, File_Name and
Web_Launch, and the CMI-generated required parameters. The file name shall be separated
from the parameters with a question mark (?). Each of the parameter fields shall be separated
by an ampersand (&). All values shall be URL encoded.
Data format
Alphanumeric. The values may be case-sensitive. Characters to the right of the question mark
(?) shall be limited to 255.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
16
2001-03-15
6
P1484.11.3D5
CBT/CMI communication session
The CBT and the CMI system have a client/server relationship where the CMI system is the
Server and the CBT AU is the client. The CBT makes each request of the CMI system by calling the CGI URL using the POST method. The CGI URL is specified in the URI launch parameters
A typical communication session between a CMI system and CBT AU is as follows:
1. The AU spawns a separate HTTP session
2. The AU sends a message requesting startup information from the CMI system.
3. Just before the end of the AU session, the AU sends student-performance and lessonstatus data to the CMI system.
4. When the student exits the AU, the AU sends an “end session” message to the CMI
system.
Figure 5 3 shows a typical communications session.
HTTP Server
HTTP Client
CBT AU (HTTP Session)
CSD
CSD's CGI
"Catcher"
program
Request
CSD data
CGI/HTTP Session –
(Not Visible to user)
Response
Figure 3 — CMI/CBT communication flow
6.1 HTTP communication
This Subclause describes the format of HTTP messages used in HTTP IEEE CMI Protocol
(HICP). The HICP messages are described in terms of HTTP/1.0 messages. A detailed description of HTTP messages is beyond the scope of this document. For a more definitive description of HTTP messages see RFC 1945, Hypertext Transfer Protocol—HTTP/1.0
Communication between HTTP clients (Web browsers) and HTTP servers (Web servers) is
accomplished by messages. There are two kinds of HTTP messages:
•
•
Request: sent from the client
Response: sent from the server
HTTP request messages in HICP shall use the POST method with a “content-type” of
“application/x-www-form-urlencoded”. HTTP response messages in HICP shall have a
“content-type” of “text/plain”.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
17
2001-03-15
P1484.11.3D5
The HICP request/response message data are contained in the “entity-body” of the request/response messages, respectively.
Name/value pairs
The message data format shall follow a convention called “name/value pairs.” Name/value
pairs are defined as follows:
<name>=<value>
where the name represents a field title and the value represents the contents of the field.
The following sections describe the format of the entity-body.
6.2 HTTP request message format
Content-type: application/x-www-form-urlencoded
Request Method: POST
Format
Figure 6Table 3 gives the format of the entity-body is as follows.
Table 3 — HTTP request message format
<Name>
command=
<IEEE command >&
version=
<IEEE Spec Version>&
session_id=
<Unique Session Identifier>&
AU_password=
<AU specific password (optional)>&
AICC_Data=
<Value>
<(URL encoded) IEEE Data>
<end of buffer>
HTTP request message format.
Where:
•
•
•
•
•
<IEEE Command> = Any valid IEEE HTTP command (See HTTP IEEE CMI
Protocol Commands on page 52)
<IEEE Spec Version> = IEEE Spec Version (e.g. 1.9)
<Unique Session Identifier> = Unique Session Identifier (See IEEE Required
Parameters oin Subclause 5.1.2)
<AU specific password (optional)> = AU Specific Password
<IEEE Data>=Data specific to the command
Usage rules
•
•
All of the above values shall be URL-encoded
The Name/value pairs can appear in any order
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
18
2001-03-15
P1484.11.3D5
• If an optional value is to be omitted, the name also shall be omitted.
• The name of each parameter shall not be case sensitive.
Examples
Command=GetParam&version=2.0&session_id=AX36&AICC_Data=
Command=PutParam&Version=2.0&Session_id=DAX36
&AICC_Data=[core]%0D%0A
lesson_location+%3D+end%0D%0Alesson_status%3D
pass%0D%0Ascore%3D87%0D%0Atime%3D00:23:15
Note that %0D is the hex value for carriage return, %0A the hex value for line feed, %3D
the hex value for = and %26 the hex value for &.
6.3 HTTP response message format
Content-type: text/plain
Request Method: POST
Format
Figure 7 Table 4 gives the format of the entity-body is as follows.
Table 4 — HTTP response message format
<Name>
error=
<Value>
<IEEE error Number><CR>
error_text=
<IEEE error description (optional)><CR>
version=
<IEEE Spec Version (optional)><CR>
aicc_data=
<IEEE Data>
<end of buffer>
HTTP response message format.
Where:
•
•
•
•
<CR> = Carriage Return and Line feed characters (ASCII 13 10)
<IEEE error Number> = IEEE HTTP error message Number (see below)
<IEEE error description> = IEEE HTTP error message text (see below)
<IEEE Data> = PARAM.CMI data (if GetParam command was issued in the request)
6.4 HTTP communication error messages
Figure 8 Table 5 lists communication error messages.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
19
2001-03-15
P1484.11.3D5
Table 5 — HTTP response message format
Error Nnumber
0
1
2
3
4
5
Error Ttext
Successful
Invalid Command
Invalid AU-password
Invalid Session ID
Command not supported
<Undefined error> error text is vendor
specific
HTTP communication error messages.
Usage rules
•
•
•
•
•
•
•
•
Leading and trailing white space (tab, space) shall be allowed before and after the
<name>, “=”, and <value>.
The <value> data in aicc_data shall begin as the first non-white-space character
after the “=” and continue until the end of the entity-body buffer.
The <value> data for all other <name> variables shall begin as the first nonwhite-space character after the “=” and continue until the last non-white-space
character before the CRLF.
The <value> data shall be plain text (not URL-encoded).
aicc_data shall be included in a response to a GetParam request only.
If aicc_data is returned, it shall be the last name/value pair in the entity-body.
The name in the name/value pair shall not be case sensitive.
If an optional value is to be omitted, the name shall also be omitted.
Example
Error=0
error_text = successful
version= 2.0
aicc_data=[core]
Student_ID=B1781
Student_Name=Doe, John
Credit=C
Lesson_Location=
Lesson_Mode=Browse
Lesson_Status = Not Attempted
Score=
Time = 00:00:00
[Student_data]
max_time_allowed=00:45:00
time_limit_action=Exit,Message
6.5 HTTP CMI protocol commands
Figure 9 Table 6 defines the commands.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
20
2001-03-15
P1484.11.3D5
Table 6 — Protocol commands
Command
GetParam
PutParam
Function
Get input data from
the CMI system.
(Data format
specified in
Subclause 6.2.x.x)
Sends output
parameter file data to
the CMI system
(Data format
specified in
Subclause 6.2.x.x)
PutInteracti
ons
Sends at least one
row of data (i.e., one
record).
ExitAU
Ends an AU session
Usage Rules
Required.
This command may be issued to the CMI system
multiple times.
(Note: The data collected from the CMI system,
however, shall be the same within a specific AU session)
Required.
This command may be used multiple times. Each time it
is used, the output parameter data shall be replaced. The
CMI system shall use the data from the final PutParam
in a CBT AU session only (i.e. this is an “overwrite”
operation).
Multiple PutParams may be used to ensure against data
loss caused by a dropped connection or abnormal session
termination
Optional
This command can be called multiple times. The CMI
system collects and stores the new data content each
time this command is called in an AU. (i.e., this is an
“append” operation)
Required.
This command shall be issued at the end of an AU
session only.
Protocol commands.
6.6 Web launch parameters
Description
The Llesson-specific launch parameters for a web-based AU. The string of characters that
needs to be appended to the file name and CMI-generated (required) parameters in order to
successfully launch an AU in the World Wide Web environment.
These data are in the “query” portion of the URL command line after the “?” separator (see
Subclause 5.1.4x.x.x).
Two parameters are required. The “Web Launch Parameters” are any additional parameters required by individual AUs.
Data format
Alphanumeric. The values may be case sensitive. The field identifier is web_launch.
Usage rules
•
•
•
Values of the parameters shall be communicated in the form “<parameter name>
= <parameter value>”.
Name/value pairs shall be separated by an ampersand (“&”).
Name/value pairs can be in any order.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
21
2001-03-15
• Parameter names shall not be case sensitive.
• Parameter values may be case sensitive.
• All parameters shall be URL-encoded.
P1484.11.3D5
6.7 AU_Password
Description
A string of characters sent to the CMI system that enables the CMI system to authenticate an
AU.
The AU_password is an optional feature that allows for additional security. The password
value shall be specific to the AU and sent with HICP request messages so that the CMI system
can authenticate the AU making the request.
The entry in the AU file shall be the value that the CMI system checks for. The CMI system
shall compare the value of this entry with the value passed by the AU.
The value for the AU_password should be configurable for individual CBT AUs by the system administrator rather than being a static value embedded or “hard-coded” in the AU.
Data format
Alphanumeric. The values may be case sensitive and are limited to 255 characters. The field
identifier is AU_Password.
Examples
rtjh4578gh
trust!1
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
22
2001-03-15
7
P1484.11.3D5
CBT/CMI Communication Information
Description
This is information that a typical lesson obtains from a CMI system to enable it to perform the
functions expected of it and the information that a lesson sends back to the CMI as a record of
what and how the student performed in the lesson. Core items are listed first, followed by the
other group names alphabetically. After each group name are the keywords, if any, which are
appropriate for that group.
7.1 Table description
•
•
Obligation (Obl):
• Mandatory item (M): The CMI system shall provide mandatory items. The
lesson may not use the mandatory items, but they are available if needed.
• Optional item (O): The CMI system may provide optional items. Optional
items are group and keyword data that may be needed by a lesson to perform
optimally. The lesson shall assume a default value if the optional item is not
present.
Privilege (Prv):
• Get: The lesson may be able to obtain the value from the CMI system by
posting a GetParam request.
• Put: The lesson may be able to place the value in a PutParam.
• Get/Put: The lesson shall may be able to both get and put a value.
Mapping table
Figure 10Table 7 shows how group and keyword names map to data element names.
Table 7 — Group and keyword to data element mapping
Group or keyword
name
[Core]
Data element name
Core
Student_ID
|--Student ID
Student_Name
|--Student Name
Lesson_Location
|--Lesson Location
Data element definition
General information that may be
used by a lesson.
Unique alphanumeric
code/identifier that refers to a
single user of the CMI system.
The oOfficial name used for the
student on the course roster. A
complete name, not just a first
name.
Corresponds to the lLesson exit
point passed to the CMI system
the last time the student
experienced the lesson.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
Obl
Prv
M
-
M
Get
M
Get
M
Get/
Put
23
2001-03-15
Group or keyword
name
Credit
Lesson_Status
Lesson_Status, flag
Lesson_Status, flag
Score
Score
Score
Score
Time
Time
Mode
[Core_Lesson]
[Core_Vendor]
[Comments]
[Comments]
[Objectives_Status]
J_ID.1
J_Score.1
J_Score.1
P1484.11.3D5
Data element name
|--Credit
Data element definition
Indicates whether the student is
being credited by the CMI system
for his performance (pass/fail and
score) in this lesson.
|--Lesson Status
The cCurrent student status as
determined by the CMI system
and sent to the lesson when it is
launched.
|--Entry
Indicatesion of whether the
student has been in the lesson
before.
|--Exit
An iIndicates how or why the
student left the lesson.
|--Score
Indicatesion of the performance
of the student during his last
attempt on the lesson.
|--|--Raw
Numerical representation of
student performance in lesson.
May be unprocessed raw score.
|--|--Max
Maximum score or total number
that the student could have
achieved.
|--|--Min
Minimum score that the student
could have achieved.
|--Total Time
Accumulated time of all student
uses of the AU.
|--Session Time
Time spent in the lesson during
the session that is ending.
|--Lesson Mode
Identifiescation of desired lesson
behavior after launch.
Suspend Data
Unique information generated by
the lesson during previous uses
that is needed for the current use.
Launch Data
Unique information generated at
the lesson's creation that is needed
for every use.
Comments
Student’s written remarks
recorded during the current use of
the lesson.
Comments from LMS
Instructor comments directed at
the student that the lesson may
present to the student when
appropriate.
Objectives
Identifies how the student has
performed on individual
objectives covered in the lesson.
|--ID
Developer-defined lesson-specific
identifier for an objective.
|--Score
Performance measure of the
student's mastery after each
attempt on an objective.
|--|--Raw
Numerical representation of
student performance after each
attempt on the objective. May be
unprocessed raw score.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
Obl
Prv
M
Get
M
Get/
Put
M
Get
M
Put
M
-
M
Get/
Put
O
Get/
Put
O
M
Get/
Put
Get
M
Put
O
Get
M
Get/
Put
M
Get
O
Put
O
Get
O
-
O
Get/
Put
-
O
O
Get/
Put
24
2001-03-15
Group or keyword
name
P1484.11.3D5
Data element name
J_Score.1
|--|--Max
J_Score.1
|--|--Min
J_Status.1
|--Status
[Student_Data]
Student Data
Mastery_Score
|--Mastery Score
Max_Time_Allowed
|--Max Time Allowed
Time_Limit_Action
|--Time Limit Action
[Student_Preferences]
Student Preference
Audio
|--Audio
Language
|--Language
Speed
|--Speed
Text
[Interactions]
|--Text
Interactions
Interaction_ID
|--ID
Objective_ID
|--Objectives.n.ID
Time
|--Time
Type_Interaction
|--Type
|--Correct Responses.n
Correct_Response
|--Pattern
Weighting
|--Weighting
Student_Response
|--Student Response
Result
|--Result
Latency
|--Latency
Data element definition
Obl
Prv
Maximum score that the student
could have achieved.
Minimum score that the student
could have achieved.
Status obtained by the student
after each attempt to master the
objective.
Information to support
customization of a lesson based
on a student's performance.
Passing score, as determined
outside the lesson.
Amount of time the student is
allowed to have in the current
attempt on the lesson.
What the lesson is to do when the
max time allowed is exceeded.
Student-selected options that are
appropriate for subsequent
lessons.
Sound on/off and volume control.
O
Get/
Put
Get/
Put
Get/
Put
Identifies in what language the
information should be delivered.
Pace of content delivery.
O
Written content visibility control.
Recognized and recordable input
or group of inputs from the
student to the computer.
Unique alphanumeric label
created by the lesson developer.
Indicatesion of any objectives
associated with the interaction.
Indicatesion of when the
interaction is available to the
student.
Indicatesion of which category of
interaction is recorded.
Expected student feedback in the
interaction.
Definesition of possible student
response.
Factor that is used to identify the
relative importance of one
interaction compared to another.
Describesption of the computermeasurable action of a student in
an interaction.
Judgment of the of the student’s
response.
Time from the presentation of the
stimulus to the completion of the
measurable response.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
O
O
O
-
O
Get
O
Get
O
Get
O
-
O
O
O
Get/
Put
Get/
Put
Get/
Put
Get
-
O
Put
O
Put
O
Put
O
Put
O
Put
O
Put
O
Put
O
Put
O
Put
O
Put
O
25
2001-03-15
P1484.11.3D5
Group and keyword to data element mapping.
7.2 [Core]
Name
Data element
Core
[Core]
Data element definition
General information that may be
used by a lesson.
Obl
M
Prv
-
Definition
Core is a required group that shall contain the following keywords in the response to a GetParam post:
Student_ID
Student_Name
Lesson_Location
Credit
Lesson_Status
Score
Time
It may contain the following keyword:
Mode
Core is a required group that shall contain the following keywords in the AICC_Data in a
PutParam post.
Lesson_Location
Lesson_Status, flag
Score
Time
Example of AICC_Data in the response to a GetParam
[core]
student_ID = CAM-1942
student_name = McArthur, Christopher A. Jr.
lesson_location=0
credit=credit
lesson_status=complete
time=00:23:15
score=93
7.2.1 Student_ID
Name
Student_ID
Data element
|--Student ID
Data element definition
Unique alphanumeric code or
identifier that refers to a single
user of the CMI system.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
Obl
Prv
M
Put
26
2001-03-15
Description
P1484.11.3D5
See IEEE 1484.11.1, Subclause x.x.
Format
CMIIdentifier
Examples
student_id=Jack_Hyde1
student_ID =
JQH-1942
STUDENT_ID= jack1991-3
7.2.2 Student_Name
Name
Student_Name
Data element
|--Student Name
Data element definition
The oOfficial name used for the
student on the course roster. A
complete name, not just a first
name.
Obl
M
Prv
Get
Obl
Prv
M
Get/
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIString255
Examples
Student_name=Whiplash, William R.
STUDENT_NAME= Grey, Jane S.
student_name = McArthur, Christopher A. Jr.
7.2.3 Lesson_Location
Name
Lesson_Location
Data element
|--Lesson Location
Data element definition
The lLesson exit point passed to
the CMI system the last time the
student experienced the lesson.
Description
See IEEE 1484.11.1, Subclause x.x.
Data format
CMIString255
Implementation dependent. The CMI system simply holds this data and then returns it to the
lesson when the student re-enters it. Whatever the lesson passes back to the CMI system is returned. The format matches whatever the lesson expects—the format is created by the lesson.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
27
2001-03-15
P1484.11.3D5
7.2.4 Credit
Name
Credit
Data element
|--Credit
Data element definition
Indicates whether the student is
being credited by the CMI system
for his performance (pass/fail and
score) in this lesson.
Obl
M
Prv
Get
Description
See IEEE 1484.11.1, Subclause x.x.
Format
Only the first letter in the CMIVocabulary members is significant. Case is insensitive.
Examples
Credit=c
Credit = no-credit
credit=N
7.2.5 Lesson_Status
Name
Lesson_Status
Data element
|--Lesson Status
|--Entry
|--Exit
Data element definition
This is the cCurrent student status
as determined by the CMI system,
and sent to the lesson when it is
launched.
Indicatesion of whether the
student has been in the lesson
before.
An iIndicatesion of how or why
the student left the lesson.
Obl
Prv
M
Get/
Put
M
Get
M
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Entry Flag
See Entry, IEEE 1484.11.1, Subclause x.x.
Exit Flag
See Exit, IEEE 1484.11.1, Subclause x.x.
Format
A word, character, or phrase representing the status identified in the CMIVocabulary list, optionally followed by a coma and an additional character or word which represents the flag.
Only the first character shall be significant in each word. Note that the absence of a status flag
indicates a normal re-entry by the student.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
28
2001-03-15
Example 1: entry
P1484.11.3D5
Lesson_Status = failed
; Student failed the lesson the last time he or she was in it.
Example 2: entry
Lesson_Status = N,A
; Student is entering the lesson for the first time.
; along with the Not Attempted status is required.
The "A" flag
Example 3: entry
lesson_status = p
; Student passed the lesson when he or she was in it previously.
; Absence of the A flag indicates this is not the first time in
; the lesson. Absence of the R flag indicates the student exited
; the lesson normally when he or she passed it (i.e., Suspend
; flag was not generated).
Example 4: entry
lesson_status=i,r
; Student did not finish lesson. When he or she left, a Suspend
; flag was generated. The Resume flag is therefore required.
Example 5: entry
lesson_status = p,a
; Student has demonstrated mastery of the contents of the
; lesson – probably by passing a pre-test. This is his or first
; time into the lesson, as indicated by the Ab initio flag.
Example 6: entry
lesson_status=i
; Student did not finish lesson. When he or she left, a Logout
; or some other flag may have been generated. No Suspend flag
; was created.
Example 7: exit
Lesson_Status = incomplete,logout
; Student logged out without completing lesson
Example 8: exit
Lesson_Status = incomplete, suspend
; Student left without completing lesson. Student probably intends
; to return to the lesson.
Example 9: entry
Lesson_Status = not attempted
; Student looked at some part of the lesson, did not attempt to
; challenge it, and then left normally.
Example 10: exit
lesson_status = p,l
; Student passed the lesson and wants to log out of the course.
7.2.6 Score
Name
Data element
Data element definition
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
Obl
Prv
29
2001-03-15
P1484.11.3D5
Score
|--Score
Score
|--|--Raw
Score
|--|--Max
Score
|--|--Min
Indicatesion of the performance
of the student during his or her
last attempt on the lesson.
Numerical representation of
student performance in lesson.
May be unprocessed raw score.
The mMaximum score that the
student could have achieved.
The mMinimum score that the
student could have achieved.
M
-
M
Get/
Put
O
Get/
Put
Get/
Put
O
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIDecimal
If maximum and minimum are included, they shall be separated by commas. The order is significant and shall be: Raw, Max, Min.
Usage rules
For a student's first attempt, SCORE = "". That is, the score is a blank “Score=”. For additional attempts the score reflects what was recorded on the student's last previous attempt.
Examples
SCORE= 79
score=1, 2
score = 3.5, 8.1, -1
Score=
7.2.7 Time
Name
Time
Data element
|--Total Time
Time
|--Session Time
Data element definition
Accumulated time of all the
student uses of the AU.
Time spent in the lesson during
the session that is ending.
Obl
M
Prv
Get
M
Put
Description
Time shall relate to the data elements Total Time and Session Time. See IEEE 1484.11.1,
Subclauses x.x and y.y.
It is the responsibility of the CMI system to accumulate total time, not track individual session
times. The AU tracks the individual session time and sends this to the CMI system after each
student usage.
Format
CMITimespan
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
30
2001-03-15
P1484.11.3D5
7.2.8 Mode
Name
Data element
|--Lesson Mode
Mode
Data element definition
Identifiescation of desired lesson
behavior after launch.
Obl
O
Prv
Get
Obl
Prv
M
Get/
Put
Description
See Lesson Mode, IEEE 1484.11.1, Subclause x.x.
Format
CMIVocabulary
Examples
Mode = B
Mode = review
7.3 [Core_Lesson]
Name
[Core_Lesson]
Data element
Suspend Data
Data element definition
Unique information generated by
the lesson during previous uses
that is needed for the current use.
Definition
See Suspend Data, IEEE 1484.11.1, Subclause x.x.
Format
CMIString4096
The format of the Core_Lesson data may be lesson unique. The only limitations on this data
are:
•
•
Data shall be transferred in ASCII format. The lesson may then convert it to some
internal form.
Core_Lesson data shall be limited to 4096 bytes.
7.4 [Core_Vendor]
Name
[Core_Vendor]
Data element
Launch Data
Data element definition
Unique information generated at
the lesson's creation that is
needed for every use.
Obl
Prv
M
Get
Description
See Launch Data, IEEE 1484.11.1, Subclause x.x.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
31
2001-03-15
Format
P1484.11.3D5
CMIString4096
7.5
[Comments]
Name
[Comments]
Data element
Comments
Data element definition
Student’s written remarks
recorded during the current use of
the lesson.
Obl
O
Prv
Put
Description
See IEEE 1484.11, Subclause x.x.
Location examples
<l.frame12>
<L.page 36>
<L.fuel3-21>
<L.Fuel part 3: interaction 24>
The location parameter indicates exactly where in the lesson the student was when he or she
created the comment. The location is placed inside the comment delimiters along with any
other information deemed desirable.
Locations can correspond to lesson elements or segments. Lesson elements are arbitrary divisions of an AU that have been uniquely named (ID).
Examples
[Comments]
<1><L.apu.intro>Why is the APU swich labels reversed from my
airplane here?<E.1>
<2><L.apu.q3>I don't understand why B is right. Shudn't the fire
handle be checked first?<E.2>
[Comments]
<1> Electrical is mispelled here.<E.1>
; Without a location, some comments are less useful.
7.6 [Comments]
Name
[Comments]
Data element
Comments from LMS
Data element definition
Instructor comments directed at
the student that the lesson may
present to the student when
appropriate.
Obl
Prv
O
Get
Description
See IEEE 1484.11.1, Subclause x.x.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
32
2001-03-15
Format
P1484.11.3D5
CMIString4096
Examples
[Comments]
<1>The trainer session following this lesson will be at 13:15
Thursday instead of 9:00.<e.1><2>If you have passed practice session
three in the simulator, please skip the Practice section in this
lesson.<E.2>
[Comments]
<1> <L.Frame23>More information on this topic may be found in your
text book in Section 3.12.<e.1>
7.7
[Objectives_Status]
Name
[Objectives_Status]
Data element
Objectives
Data element definition
Identifies how the student has
performed on individual
objectives covered in the lesson.
Obl
Prv
O
-
Obl
Prv
O
Get/
Put
Description
See Objectives, IEEE 1484.11.1, Subclause x.x.
This group contains the following keywords.
J_ID.1
J_Score.1
J_Status.1
Example
[objectives_status]
J_ID.1 = APU1684
j_status.1 = passed
7.7.1 J_ID.1
Name
J_ID.1
Data element
|--ID
Data element definition
A developer defined lessonspecific identifier for an
objective.
Description
J_ID shall be a developer defined, lesson-specific identifier for an objective
Keyword format
Each J_ID keyword shall have an extension that makes it unique. The extension is a period
followed by a number from 1 to 9999. This number shall not be zero padded. (For example,
.0009 is an invalid extension for the number .9.)
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
33
2001-03-15
Data format
P1484.11.3D5
CMIIdentifier
Usage rules
The group Objectives_Status may contain multiple IDs, but each shall have a unique extension.
Because the value of each objective ID is a string internally defined in the CBT courseware,
the CMI system shall have a means of storing and referencing these lesson-specific IDs.
Example
J_ID.1 = A1373
7.7.2 J_Score.1
Name
J_Score.1
Data element
|--Score
J_Score.1
|--|--Raw
J_Score.1
|--|--Max
J_Score.1
|--|--Min
Data element definition
A pPerformance measure of the
student’s mastery after each
attempt on an objective.
Numerical representation of
student performance after each
attempt on the objective. May be
unprocessed raw score.
The mMaximum score that the
student could have achieved.
The mMinimum score that the
student could have achieved.
Obl
O
Prv
-
O
Get/
Put
O
Get/
Put
Get/
Put
O
Definition
J_Score shall be an indication of the performance of the student after the last attempt to master an objective. Objectives may have a score associated with them. If they do, this keyword
enables capturing that data.
If a maximum and minimum accompany the score, they shall be separated by a comma. This
score shall reflect the student’s last attempt on the objective.
Keyword format
The score keyword shall have an extension that makes it unique. The extension is a period followed by an integer number from 1 to 9999. This number shall not be zero padded. (For example, .0009 is an invalid extension for the number .9.)
Data format
One or more CMIDecimal numbers, separated by commas for raw, max, and min.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
34
2001-03-15
Usage rules
P1484.11.3D5
The extension enables associating the score with an J_ID. For example, the .1 set of scores is
for the objective with the J_ID.1 identifier.
Examples
J_Score.1 = 2
; during student's last attempt on the first objective, a score of 2
; was achieved.
J_Score.1 = 2, 3, 0
J_Score.2 = 4,,0
J_ID.1= First
J_Score.1 = 87
J_ID.2= Second
J_Score.2 = 3,5
; during last attempt, student scored 3, of
; possible 5
J_ID.1= 1
J_Score.1 = 87, 100, 0
; on objective 1 there is a raw, maximum, and minimum value.
J_ID.2= 2
J_Score.2 = 3
7.7.3 J_Status.4
Name
J_Status.1
Data element
|--Status
Data element definition
The sStatus obtained by the
student after each attempt to
master the objective.
Obl
Prv
O
Get/
Put
Description
See Status, IEEE 1484.11.1, Subclause x.x.
Keyword format
Each status keyword shall have an extension to make it unique. The extension is a period followed by an integer number from 1 to 9999. This number shall not be zero padded. (For example, .0009 is an invalid extension for the number .9.)
Data format
CMIVocabulary
Usage rules
A status shall have the same extension as its corresponding J_ID. This indicates the status of
the corresponding objective.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
35
2001-03-15
P1484.11.3D5
There shall never be more than one status keyword associated with a single objective. However, if more than one status does appear after an objective, then the first status to appear is the
one that is assumed correct by the lesson.
If a status has no corresponding J_ID, the status shall be ignored.
If no status is associated with an objective ID, then the assumed status shall be Not Attempted.
Examples
j_id.3 = 1987
j_status.3=p
j_id.6 = 1942
J_STATUS.6 = incomplete
J_ID.92 = 1847
J_Status.92 = P
7.8 [Student_Data]
Name
[Student_Data]
Data element
Student Data
Data element definition
Information to support
customization of a lesson based
on a student's performance.
Obl
O
Prv
-
Obl
O
Prv
Get
Description
See IEEE 1484.11.1, Subclause x.x.
This group contains the following data elements.
Mastery_Score
Max_Time_Allowed
Time_Limit_Action
7.8.1 Mastery_Score
Name
Mastery_Score
Data element
|--Mastery Score
Data element definition
The pPassing score, as
determined outside the lesson.
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIDecimal
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
36
2001-03-15
Examples
mastery_score = .75
Mastery_Score = 100
MASTERY_SCORE=5
P1484.11.3D5
7.8.2 Max_Time_Allowed
Name
Max_Time_Allowed
Data element
|--Max Time Allowed
Data element definition
The aAmount of time the student
is allowed to have in the current
attempt on the lesson.
Obl
O
Prv
Get
Obl
O
Prv
Get
Description
See IEEE 1484.11.1, Subclause x.x.
Data format
CMITimespan
Examples
max_time_allowed = 0:14:30.5
Max_Time_Allowed = 2:03:00
MAX_TIME_ALLOWED = 1:09:00
7.8.3 Time_Limit_Action
Name
Time_Limit_Action
Data element
|--Time Limit Action
Data element definition
What the lesson is to do when the
max time allowed is exceeded.
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIVocabulary
For HTTP communication, only the first letter of each word before and after the comma is significant. Case is not significant.
Examples
time_limit_action = Exit, Message
; The lesson presents a message to the student
; indicating he or she has exceeded the time
; limit in the lesson, and then exit or quit.
Time_Limit_Action=E,N
; The lesson quits or exits with no message to the
; student. The student jumps to the CMI environment.
time_limit_action = c,n
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
37
2001-03-15
P1484.11.3D5
; When the student exceeds his time limit in the
; lesson, no message is presented, the lesson
; continues.
TIME_LIMIT_ACTION = continue, message
: The student receives a message when he or she exceeds
; the time limit. The lesson continues
; after presenting the message.
7.9 [Student_Preferences]
Name
[Student_Preferences]
Data element
Student Preference
Contextualized definition
Student-selected options that are
appropriate for subsequent
lessons.
Obl
O
Prv
-
Contextualized definition
Sound on/off and volume control.
Obl
O
Prv
Get/
Put
Contextualized definition
Obl
Prv
O
Get/
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Keywords
This group contains the following keywords.
Audio
Language
Speed
Text
7.9.1 Audio
Name
Data element
|--Audio
Audio
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMISInteger
Examples
audio= -1
AUDIO = 33
7.9.2 Language
Name
Language
Data element
|--Language
Identifies in what language the
information should be delivered.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
38
2001-03-15
Description
P1484.11.3D5
See IEEE 1484.11.1, Subclause x.x.
Format
CMIString255
Alphabetic string. May include spaces.
7.9.3 Speed
Name
Speed
Data element
|--Speed
Contextualized definition
Pace of content delivery.
Obl
O
Prv
Get/
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Value format
CMISInteger
Examples
speed= -100
; If a system only has three speeds, slower, normal, and
; faster, any positive number (+1 and above) would
; result in the use of the faster speed.
SPEED = 33
7.9.4 Text
Name
Text
Data element
|--Text
Contextualized definition
Written content visibility control.
Obl
Prv
O
Get/
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMISInteger
Examples
Text = -1
text=0
TEXT = 1
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
39
2001-03-15
P1484.11.3D5
7.10 [Interactions]
Name
[Interactions]
Data element
Interactions
Data element definition
A rRecognized and recordable
input or group of inputs from the
student to the computer
Obl
O
Prv
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Interactions shall be posted with the PutInteractions command. Interactions shall not be
posted in the group and keyword format and shall not be posted with the PutParam command used for all other data elements described in this chapter. Interactions shall be sent in a
comma-delimited table format, URL encoded. Each row in the table shall constitute a record.
The fields to be sent shall be identified in the first row with the following names:
Interaction_ID
Objective_ID
Time
Type_Interaction
Correct_Response
Weighting
Student_Response
Result
Latency
A typical PutInteractions command might post the following information (for clarity this example is not URL encoded):
"time","interaction_id","objective_id","type_interaction",
"correct_response","student_response","result","weighting",
"latency"
"15:14:23",37,ft1016, C,A,C,W,,00:00:3
"15:14:23",38,ft2223,t,t,t,,,00:00:01
"15:14:23",39,ft1134,C,B,B,C,,00:00:02
"15:14:23",40,ft1156,C,C,C,C,,00:00:04
In the table format, columns may be in any order. The first row, or title row, shall determine
the order of the values in the following rows. All columns are optional. All values are optional.
Note that if the column exists, the value in that column may be a blank.
The PutInteractions command shall post complete records or rows. Each command may post
a single row or an entire table. Every PutInterations command is an append action.
7.10.1Interaction_ID
Column Label
Interaction_ID
Data element
|--ID
Data element definition
Unique alphanumeric label
created by the lesson developer.
Obl
Prv
O
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
40
2001-03-15
Format
P1484.11.3D5
CMIIdentifier
7.10.2Objective_ID
Column Label
Objective_ID
Data element
|--Objectives.n.ID
Data element definition
Indicatesion of any objectives
associated with the interaction.
Obl
O
Prv
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIIdentifier
If more than one objective is associated with an interaction, commas shall separate the objectives. In this comma-delimited format, any field with an embedded comma shall be surrounded by quotation marks.
7.10.3Time
Column Label
Time
Data element
|--Time
Data element definition
Indicatesion of when the
interaction is available to the
student.
Obl
Prv
O
Put
Definition
See IEEE 1484.11.1, Subclause x.x.
Format
CMITime
7.10.4Type_Interaction
Column Label
Type_Interaction
Data element
|--Type
Data element definition
Indication of which category of
interaction is recorded.
Obl
Prv
O
Put
Definition
See IEEE 1484.11.1, Subclause x.x.
Format
Only the first letter of the CMIVocabulary members is significant in this field. Case is insensitive.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
41
2001-03-15
Examples
P1484.11.3D5
"true-false"
"multiple choice"
-- this is interpreted as type matching because only the first
-- first letter in the field is significant
"C"
"F"
"Performance"
7.10.5Correct_Response
Column Label
Correct_Response
Data element
|--|--Correct
Responses.n.Pattern
Data element definition
Definesition of possible student
response.
Obl
Prv
O
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIFeedback
Examples
Interaction Type
Choice
Choice
Matching
Matching
Matching
Matching
Mixed examples
Representation
"b; d"
-- The response is considered correct when the student
-- selects either “b” or “d”.
"{b,d}"
-- The response is considered correct only when the
-- student has selected both “b” and “d” in his response
-- to the question
"1.c; 2.b; 3.a; 4.d"
-- answer is considered correct if any one of these four
-- matches is made by the student
"{1.c,2.b,3.a,4.d}"
-- answer is considered correct only if all of these four
-- matches is made by the student
"{3.4,1.6,5.2}"
-- answer is considered correct only if all of these three
-- matches is made by the student
"{a.e, d.g, c.f, b.h};{a.h, d.g, c.f, b.h}"
-- Student must make four matches to have answer
-- judged correct. However, he may match “a” to
-- either “e” or “h” and still have a correct match.
"<case> Washington"
"2300-2400"
-- This can only be valid as a response to a fill-in
-- question. If it represents a range on a performance
-- question, there must be two hyphens.
"2300 -- 2400"
"b,c,e,a,d"
-- A sequencing question. This is a single response.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
42
2001-03-15
P1484.11.3D5
"23291"
-- Notice that for some types of questions, large
-- numbers cannot have commas in them. 23,291
-- could be interpreted as two correct alternative
-- responses.
7.10.6Weighting
Name
Weighting
Data element
|--Weighting
Data element definition
Factor that is used to identify the
relative importance of one
interaction compared to another.
Obl
Prv
O
Put
Obl
Prv
O
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIDecimal
7.10.7Student_Response
Name
Student_Response
Data element
|--Student Response
Contextualized definition
Describesption of the computermeasurable action of a student in
an interaction.
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIFeedback
Examples
Matching
examples
"1.2"
"{1.c,2.b,3.a,4.d}"
"{3.4,1.6,5.2}"
"{a.e, d.g, c.f, b.h}"
"{12.2, 11.3, 10.11}"
Mixed examples
"1.2"
"1.2,1.3"
"Washington"
"C"
"b,c,e"
"23291"
-- Notice that for some types of questions, large
-- numbers cannot have commas in them. 23,291 is
-- interpreted as two alternative responses.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
43
2001-03-15
P1484.11.3D5
7.10.8Result
Name
Result
Data element
|--Result
Contextualized definition
Judgment of the of the student's
response.
Obl
O
Prv
Put
Obl
O
Prv
Put
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMIVocabulary
Examples
"c"
"c,c,w,c,c"
"unanticipated response, correct, correct, wrong, c"
"neutral"
"Correct"
7.10.9Latency
Name
Latency
Data element
|--Latency
Contextualized definition
The tTime from the presentation
of the stimulus to the completion
of the measurable response.
Description
See IEEE 1484.11.1, Subclause x.x.
Format
CMITimespan
Examples
"00:00:23"
-- the student required 23 seconds to respond
"00:23:00"
-- The student required 23 minutes to respond
"00:00:03.4"
-- The student required 3.4 seconds to respond
"00:01:13
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
44
2001-03-15
8
P1484.11.3D5
Data type definitions
See: IEEE P1484.11.1/D5, Clause 7.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
45
2001-03-15
9
P1484.11.3D5
Annex A: Document development (informative)
This Annex is informative and not normative.
This section concerns the development of this document. The past (revision history, resolved
issues), present (release notes, comment returns), and future (open issues) releases of this document are identified here.
9.1 Revision history
•
•
•
•
•
•
•
Draft 1, YYYY-MM-DD, the first draft. [Description of draft].
Draft 2, YYYY-MM-DD, the second draft. [Description of draft].
Draft 3, YYYY-MM-DD, the third draft. [Description of draft].
Draft 3.2, YYYY-MM-DD, revisions to the third draft. [Description of draft].
Draft 3.4, YYYY-MM-DD, revisions to the third draft. [Description of draft].
Draft 4, YYYY-MM-DD, the fourth major draft. [Description of draft].
Draft 5, YYYY-MM-DD, the current draft. [Description of draft].
9.2 Release notes for this document
The following notes apply to this release of this Standard:
•
xxx
9.3 Resolved issues
The following issues have been resolved:
•
xxx
9.4 Open issues
The following issues are outstanding:
•
xxx
9.5 Comments on this document
All comments are appreciated. Please return all comments on this release of this document by
Friday, 2001-MM-DD 23:00 UTC. Deliver all comments to the IEEE 1484.11 CMI Working
Group by sending E-mail to:
ltsc-cmi@majordomo.ieee.org
To subscribe to the working group mailing list, send the one-line message
subscribe ltsc-cmi
to the E-mail address “majordomo@majordomo.ieee.org”.
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
46
2001-03-15
The Technical Editor may be contacted at any one of the following:
P1484.11.3D5
Telephone: +1 512-928-1200
Fax: +1 612-632-3997
E-mail: slewis@oldworldaviaries.com
Address Info ...
Scott Lewis
3509 Carla Drive
Austin, TX 78754
Copyright © 2001 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
47