1484 11 2 2003 ieee standard for learning technologyߞecma script application programming interface f by Jinghua

IEEE Standards

IEEE Std 1484.11.2™-2003

1484.11.2

IEEE Standard for Learning Technology—ECMAScript Application Programming Interface for Content to Runtime Services Communication

IEEE Computer Society Sponsored by the Learning Technology Standards Committee

Published by The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA 4 March 2004

Print: SH95175 PDF: SS95175

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

Recognized as an American National Standard (ANSI)

IEEE Std 1484.11.2™-2003(R2009)

IEEE Standard for Learning Technology—ECMAScript Application Programming Interface for Content to Runtime Services Communication Sponsor Learning Technology Standards Committee of the IEEE Computer Society Approved 29 December 2003

American National Standards Institute Reaffirmed 11 September 2009 Approved 11 September 2003

IEEE-SA Standards Board Abstract: An ECMAScript application programming interface (API) for content-to-runtime-services communication is described in this standard. It is based on a current industry practice called “CMI–computer managed intsruction.” This API enables the communication of information between content and a runtime service (RTS) typically provided by a learning management system (LMS) via common API services using the ECMAScript language. The purpose of this standard is to build consensus around, resolve ambiguities, and correct defects in existing specifications for an ECMAScript API for exchanging data between learning-related content and an LMS. Keywords: application programming interface, API, computer managed instruction, content object, ECMAScript, ECMAScript API, learning content, learning management system, LMS, runtime service, RTS The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2004 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 4 March 2004. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Incorporated. Print: PDF:

ISBN 0-7381-3824-X ISBN 0-7381-3825-8

SH95175 SS95175

No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus development process, approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards. Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document. The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied â&#x20AC;&#x153;AS IS.â&#x20AC;? The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation, or every ten years for stabilization. When a document is more than five years old and has not been reaffirmed, or more than ten years old and has not been stabilized, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to be, nor be relied upon as, a formal interpretation of the IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position, explanation, or interpretation of the IEEE. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Recommendations to change the status of a stabilized standard should include a rationale as to why a revision or withdrawal is required. Comments and recommendations on standards, and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.

iii Copyright ÂŠ 2009 IEEE. All rights reserved. This is an unapproved IEEE Standards draft, subject to change. Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

Introduction [This introduction is not part of IEEE Std 1484.11.2-2003, IEEE Standard for Learning Technology—ECMAScript Application Programming Interface for Content to Runtime Services Communication.]

This standard describes a learning content ECMAScript API to support the data transfer needs of content with a runtime service in a Web-browser-based content delivery environment. This standard provides a starting point for specifying a data communication channel and methods to support the data transfer needs of education, training, and human performance support content. The capabilities of this API model may be extended as other communication needs or methods arise.

Acknowledgements The IEEE LTSC P1484.11.2 CMI Working Group wishes to thank Tom King and Boyd Nielsen for their contributions of initial documents used for the preparation of this standard. This standard is based on material from Appendix B of the AICC/CMI Guidelines for Interoperability, Revision 3.4.

Participants At the time this standard was completed, the working group had the following membership: Tyde Richards, Chair Jack Hyde, Chair (December 1998–March 2001) Scott Lewis, Technical Editor Mitchell Bonnett Frank Farance Mike Fore Leonard Greenberg

Tom King Rolf Lindner Kiyoshi Nakabayashi Boyd Nielsen

Claude Ostyn Daniel Rehak Robby Robson Schawn Thropp

The following members of the balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention. Mitchell Bonnett Keith Chow Hockemeyer Cord Guru Dutt Dhingra Kameshwar Eranki Frank Farance Harriet Feldman Mike Fore Eddy Forte

Ronald Hofer Jack Hyde Robert Bruce Kelsey Tom King Rolf Lindner Gregory Luri William Melton George Miao

Kiyoshi Nakabayashi Boyd Nielsen Claude Ostyn Daniel Rehak Tyde Richards Robby Robson Larry Stern Brian Taliesin Schawn Thropp

iii

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

When the IEEE-SA Standards Board approved this standard on 11 September 2003, it had the following membership: Don Wright, Chair Howard M. Frazier, Vice Chair Judith Gorman, Secretary H. Stephen Berger Joe Bruder Bob Davis Richard DeBlasio Julian Forster* Toshio Fukuda Arnold M. Greenspan Raymond Hapeman

Daleep C. Mohla William J. Moylan Paul Nikolich Gary Robinson Malcolm V. Thaden Geoffrey O. Thompson Doug Topping Howard L. Wolfman

Donald M. Heirman Laura Hitchcock Richard H. Hulett Anant Jain Lowell G. Johnson Joseph L. KoepďŹ nger* Tom McGean Steve Mills

*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons: Alan Cookson, NIST Representative Satish K. Aggarwal, NRC Representative Andrew Ickowicz IEEE Standards Project Editor

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

Contents 1.

Overview.............................................................................................................................................. 1 1.1 Scope............................................................................................................................................ 1 1.2 Purpose......................................................................................................................................... 1

References............................................................................................................................................ 2

Definitions, abbreviations, and acronyms............................................................................................ 2 3.1 Definitions.................................................................................................................................... 2 3.2 Abbreviations and acronyms........................................................................................................ 3

Conformance........................................................................................................................................ 3 4.1 4.2 4.3 4.4

Conceptual model (informative) .......................................................................................................... 5 5.1 5.2 5.3 5.4

Simplified learning content ECMAScript API communication model ....................................... 5 Basic scenario .............................................................................................................................. 6 Implementation for Web-browser-based content......................................................................... 7 ECMAScript API extensibility .................................................................................................... 9

API instantiation and binding .............................................................................................................. 9 6.1 6.2 6.3 6.4

Behavior....................................................................................................................................... 4 API implementation ..................................................................................................................... 4 Content object use of an API implementation ............................................................................. 4 Outside of scope........................................................................................................................... 5

Instantiation of an instance of an API implementation................................................................ 9 Multiple instances ...................................................................................................................... 10 Binding a content object to an API instance.............................................................................. 10 Sample implementation to find an API instance (informative) ................................................. 10

Content communication state model.................................................................................................. 11 7.1 Communication and error states ................................................................................................ 11 7.2 Events......................................................................................................................................... 12

ECMAScript API methods and syntax .............................................................................................. 16 8.1 8.2 8.3 8.4

Session methods......................................................................................................................... 16 Data-transfer methods................................................................................................................ 18 Support methods ........................................................................................................................ 21 API implementation error codes ................................................................................................ 23

Annex A (informative) Bibliography............................................................................................................. 26 Annex B (informative) When to call the terminate communication session method .................................... 27 Copyright ÂŠ 2004 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Standard for Learning Technology—ECMAScript Application Programming Interface for Content to Runtime Services Communication

1. Overview The scope and purpose of this standard are discussed in 1.1 and 1.2.

1.1 Scope This standard describes an ECMAScript application programming interface (API) for content-to-runtimeservices communication. This standard is based on an API defined in AICC/CMI Guidelines for Interoperability, Revision 3.4 [B1]1, defined by the Aviation Industry CBT Committee (AICC). It defines common API services in the ECMAScript language that enable the communication of information between learningrelated content and a runtime service (RTS) used to support learning management. This standard does not address the data structures that may be transmitted, data security, or communication between an RTS and a related management system.

1.2 Purpose There is widespread acknowledgement that the ECMAScript API for content-to-runtime-services communication deﬁned in the AICC/CMI Guidelines for Interoperability, Revision 3.4, has broad applicability to systems used for learning management. The purpose of this standard is to build consensus around, resolve ambiguities in, and correct defects in this ECMAScript API for exchanging data between learning-related content and a runtime service used to support learning management.

1The

numbers in brackets correspond to those of the bibliography in Annex A.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

2. References This standard shall be used in conjunction with the following publication. ISO/IEC 16262:1998, Information technology—ECMAScript language speciﬁcation.2 W3C, Document Object Model (DOM) Level 3 Core Speciﬁcation, Version 1.0, W3C Working Draft 26 February 2003.3 (See: http://www.w3.org/DOM/)

3. Definitions, abbreviations, and acronyms 3.1 Definitions For purposes of this standard, the following terms and definitions apply. IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition [B2], should be referenced for terms not defined in this clause. 3.1.1 application programming interface (API): A set of standard software interrupts, calls, functions, and data formats that can be used by an application program to access network services, devices, or operating systems. 3.1.2 application programming interface implementation (API implementation): An implementation of this standard that supplies the services of the application programming interface, in contrast to an implementation of this standard that uses the application programming. 3.1.3 application programming interface instance (API instance): An individual execution context and state of an application programming interface implementation. NOTE—The notion of “execution context” in this standard is the same as in ECMAScript.

3.1.4 communication session: An active connection between a content object and an application programming interface instance. 3.1.5 content object: A collection of digital content that is intended for presentation to a learner by a learning technology system. A content object may include learning material and processing code. Example: A content object might be an HTML page with an embedded video clip and an ECMAScript. 3.1.6 Document Object Model (DOM): A platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure, and style of documents. The document can be further processed, and the results of that processing can be incorporated back into the presented page (see W3C, Document Object Model (DOM) Level 3 Core Speciﬁcation, Version 1.04). 3.1.7 ECMAScript: An object-oriented programming language for performing computations and manipulating computational objects within a host environment as deﬁned by ISO/IEC 16262:1998.

2ISO/IEC

publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH-1211, Genève 20, Switzerland/Suisse (http://www.iso.ch/). ISO/IEC publications are also available in the United States from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA (http://global.ihs.com/). Electronic copies are available in the United States from the American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.org/). 3More information may be obtained from the following URL: http://www.w3.org/DOM/ 4Information on references can be found in Clause 2.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

3.1.8 implementation behavior: Observable actions or appearance of an implementation. See also: implementation-defined behavior; undefined behavior; unspecified behavior. 3.1.9 implementation-defined behavior: Unspecified behavior for which each implementation documents how the choice among the available alternatives is made. Example: Permitting a maximum size, as measured in octets, of a coding. See also: implementation behavior; undefined behavior; unspecified behavior. 3.1.10 launch (v.): To cause a content object to be delivered to a learner. 3.1.11 learner: An individual engaged in acquiring knowledge or skills with a learning technology system. 3.1.12 learning content: Digital content intended for use in a learning experience. 3.1.13 learning management system (LMS): A computer system that may include the capabilities to register learners, schedule learning resources, control and guide the learning process, analyze and report learner performance, and schedule and track learners. NOTE—Some implementations of LMSs also have the ability to launch and deliver content. For this standard, these capabilities are known as a runtime service.

3.1.14 runtime service (RTS): Software that controls the execution and delivery of learning content and that may provide services such as resource allocation, scheduling, input-output control, and data management. 3.1.15 undefined behavior: Implementation behavior for which a standard imposes no requirements. Undefined behavior describes nonconforming implementations of this standard. Possible undefined behaviors include, but are not limited to: ignoring the situation completely, unpredictable results, behaving in a documented manner characteristic of the environment, and terminating processing. See also: implementation behavior; implementation-defined behavior; unspecified behavior. 3.1.16 unspecified behavior: Implementation behavior for which a standard provides two or more alternatives and imposes no further requirements on what is chosen in any instance. See also: implementation behavior; implementation-defined behavior; undefined behavior.

3.2 Abbreviations and acronyms AICC API CBT CMI DOM LMS RTS

Aviation Industry CBT Committee application programming interface computer-based training computer managed instruction Document Object Model learning management system runtime service

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

4. Conformance Conformance to this standard is discussed in 4.1–4.4.

4.1 Behavior In this standard, “shall” is to be interpreted as a requirement on an implementation; “shall not” is to be interpreted as a prohibition. This standard deﬁnes undeﬁned behavior in the following ways: — — —

If a “shall” requirement or “shall not” prohibition is violated; By the words “undeﬁned behavior;” and By the omission of any explicit deﬁnition of behavior.

There is no difference in emphasis among these ways; they all describe “behavior that is undefined.” NOTES: 1—“Unspecified behavior” and “implementation-defined behavior” both describe conforming behavior. With “unspecified behavior,” several choices may be possible. This standard does not specify which one is chosen, and the implementation is not required to “define” (i.e., tell in advance) which set of behaviors it has chosen. Similarly, with “implementation-defined behavior,” several choices may be possible and this standard does not specify which one is chosen. However, the implementation is required to “define” (i.e., tell in advance) which set of behaviors it has chosen. 2—“Implementation behavior” describes observable action or appearance, which may be conforming or nonconforming. “Undefined behavior” describes nonconforming implementations of this standard.

4.2 API implementation A conforming ECMAScript API implementation shall —

— —

Be instantiated as an object within the Document Object Model (DOM) (see W3C, Document Object Model (DOM) Level 3 Core Specification, Version 1.0) environment of the content object as specified in Clause 6 of this standard; Conform to the state model in Clause 7 of this standard; and Implement all methods and error returns, as specified in Clause 8 of this standard.

4.3 Content object use of an API implementation A conforming content object shall — — — — —

Find an instance of the API implementation as an ECMAScript-compatible object within the DOM environment of the content object as described in Clause 6 of this standard; Call Initialize after the content object is launched and has located the API instance before calling any other method (see 8.1.1); Call Terminate when the content object determines it no longer needs to communicate with the API instance or is unloaded, whichever happens ﬁrst (see 8.1.2); Not call any data-transfer method or Initialize after Terminate has been called; and Use conforming syntax when calling any optional data-transfer methods (see 8.2) or when calling any optional support methods (see 8.3).

A content object strictly conforms to this standard if it does not depend on implementation-deﬁned behavior or unspeciﬁed behavior.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

NOTE—It is anticipated, but not required, that a conforming content object will call one or more data-transfer methods. Without such calls, speciﬁc data is neither explicitly received nor explicitly transmitted during the communication session, and an RTS can only make inferences about the communication session, such as elapsed time.

4.4 Outside of scope The following are outside of the scope of conformance to this standard: —

—

— — — — — — —

The information returned by the GetDiagnostic implementation (see 8.3.3) (the information returned is particular to the stakeholders interested in using this method and not to all implementers generally); The deﬁnition and structure of a data model as well as the semantics and behavior associated with speciﬁc data model elements, as associated with the retrieve data and store data methods (see 8.2.1 and 8.2.2); The choice of language of implementation for the API implementation and backend communication; Whether a data-transfer cache is implemented and where it is implemented; Behavior of the API implementation after abnormal termination of communication; The implementation of the API; How an API implementation processes a call to the commit data method (see 8.2.3); How to initialize communication between an API instance and a content object; and The syntax and semantics of any characters following the minor release value of the API DOM object version attribute.

5. Conceptual model (informative) This clause is informative. This clause presents a conceptual model for communication between a content object and an RTS using an implementation of the ECMAScript API.

5.1 Simpliﬁed learning content ECMAScript API communication model Figure 1 shows the basic model of the learning content ECMAScript API implementation. An RTS refers to that part of an environment, typically an LMS, that delivers content to a learner.

Content repository / Learner data

API Instance Runtime Environment

Content object

LMS

A PI Calls RTS Results from A PI Calls

Figure 1—Learning content ECMAScript API model

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

This conceptual model applies to both connected and disconnected delivery of content objects. Possible implementations include — — —

The RTS resides on a server; The RTS resides on a client; and The RTS is distributed between a client and a server.

Regardless of approach, the concept is the same—a common set of communication methods is provided in the API implementation. The common implementation of this model is in an environment (Web-browser-based delivery) where a content object initiates all communication. This communication model makes no provision for communication initiated by an RTS to the content object. Interoperability is achieved by sending requests through the shared communication methods implemented in the API. Communication behavior and method interfaces are the same for every instance of an API implementation. The contents of the communications may be whatever is meaningful and agreed upon by different communities of practice. Nevertheless, the behavior of each agent (e.g., content object, RTS) implementing an API may be specific to its role. NOTES: 1—Because of potential communication latency between an API implementation and persistent data storage, a common optimization may be a cache associated with the API implementation itself. This standard provides a method that allows a content object to set the value of any number of data items and then signal the API instance that the data values held in the cache, if it exists, can be committed to more permanent storage. Whether a cache is implemented and where it is implemented are outside of the scope of this standard. Caching behavior is transparent to the content object. To the content object, it appears that all gets and sets of data values are to persistent storage. How an API implementation processes a call to the commit data method is also outside of the scope of this standard. Other than the commit data method, this standard does not specify any other caching methods or behaviors or any transaction methods or behaviors. For example, there are no transaction rollback methods. 2—A particular binding may specify that one or more data elements are session specific, read only, transient, or disposable. In such cases, the specified elements may not be available for future use, including being unavailable for use by a later communication session of the same content object by the same learner. Writers of data binding specifications are encouraged to identify such special-case elements as well as all expected transformations of such elements through both single- and multiple-session transitions.

5.2 Basic scenario The basic scenario for communication is discussed in 5.2.1 and 5.2.2. 5.2.1 Environment and preparations As depicted in Figure 1, an RTS implements an API in the content object’s environment. The implementer incorporates into the content object the capability to discover and communicate with an API instance. An LMS or the front-end to a content repository (local or remote) provides an RTS for the learner. The RTS delivers a content object to the learner and starts it. Typically, this is done by setting the location of a window in a browser to a speciﬁc uniform resource identiﬁer (URI) to load the content object. NOTE—A content object has integrated procedures to locate an API instance as described in 5.2.2.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

5.2.2 Sequence of operations The RTS initiates the launch of a content object. The content object searches for the API instance. After verifying that the API implementation is accessible as an instance in the content object’s environment, the content object initializes a communication session through the instance that has been located. All subsequent communication is part of this communication session until the session is ended. The content object may request data through the API instance. While running, content may send or set data-model data elements for storage across communication sessions. The RTS may use data elements or other data in reports on a learner’s status with that content. The content object may elicit a more detailed error message. The content object may continue communicating in this fashion, requesting and sending data until a learner finishes interacting with a content object, a learner terminates the communication session before finishing, or the communication session is abnormally terminated (e.g., loss of power, system crash). In the first two cases, the content object tells the API instance that it is closing the communication session. In the last case, the RTS will not receive a signal through the API instance that the communication session is closed. The RTS will need to deal with the abnormal event according to API implementation specifications (such specifications are outside of the scope of this standard.) The summary of the normal sequence of normal operations is as follows: a) b) c) d)

g) h)

The RTS instantiates the API implementation in the content DOM and initiates launch of a content object. The content object locates the API instance (this is a required action of the content object). The content object invokes the initialize communication session method of the API instance prior to calling any other method (this use of this session method is a required action of the content object). If the content object invokes one or more data-retrieval requests through the API instance, the RTS returns the data or, in the case of an error, an empty string (""). The RTS sets an appropriate error status, either "0" for no error or an error code. The error status can be retrieved by the content object on request. Calls to retrieve data (data-transfer methods) are optional actions of the content object. If the content object invokes one or more data-storage requests through the API instance, the RTS attempts to store the data and returns an acknowledgement, either "true" or, in the case of an error, "false". The RTS sets an appropriate error status, either "0" for no error or an error code. The error status can be retrieved by the content object on request. Calls to store data (data-transfer methods) are optional actions of the content object. If the content object invokes one or more of the predeﬁned support methods through the API instance, the RTS responds appropriately with data or messages through the API instance. Calls for support methods are optional actions of the content object. The API instance returns a value or message if a call is made. The content object invokes the termination method of the API instance (this use of this method is a required action of the content object). The API instance rejects any attempt by this instance of the content object to re-initialize the communication session.

5.3 Implementation for Web-browser-based content As shown in Figure 1, the API implementation uses ECMAScript-compatible methods that can be called by the content object. From the point of view of the content object, the key attributes of the ECMAScript API are — —

Methods are invoked using ECMAScript-compatible calls; All parameters and return values are passed as character strings;

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

— — —

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

Method names are case sensitive; Communication is invoked by content objects only; and Integers, real numbers, and times are to be encoded as they would be by the ECMAScript-to-string cast conversion.

The RTS instantiates an API implementation within the content object DOM. The content object finds the API instance and establishes a communication session by calling the initialize communication session method defined within this standard. The content object uses the first API instance found according to the precedence rules specified in Clause 6. An API implementation need not be implemented in ECMAScript, but the API implementation must support the ECMAScript API. NOTES: 1—Implementation of an API is outside of the scope of this standard. For example, an API implementation may be written in any language, as long as the ECMAScript calls are supported. An API implementation can shield a content object from particular server-side communication protocols, technology, and requirements for communicating with content or backend services. The particular implementation needs of an implementer are hidden behind a common, shared set of communication methods. This approach shields content object and RTS providers from needing to implement an API that is unique to each content or RTS implementer. The ECMAScript calling convention gives wide latitude to implementers. 2—The API instance is typically placed within the content object DOM by the RTS. The API instance is either embedded in the content page or in a frameset or window on a learner’s Web browser. Finding and establishing communication with the API instance typically occurs immediately after the content object is launched. 3—More than one API instance may exist in a DOM instance as shown in Figure 2. For example, this may occur if a content object acts as an RTS for another content object. The precedence rules in Clause 6 for locating the API instance ensure that the proper API implementation is found by each content object.

API Instance

Runtime environment Content object Runtime environment

API Instance

Content object

Figure 2—Multiple API implementations in the same DOM instance

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

4—Different user communities have speciﬁc rules about what software is permitted and prohibited in Web-browserbased environments. For example, some prohibit the use of plug-ins of any kind for security reasons. Likewise, Java applets, ECMAScript code, or other means used to implement or support the API methods may need to be signed by a trusted authority to properly function within certain security conﬁgurations of a Web browser when API communication spans domains. These restrictions may limit the applicability of this standard in these communities and environments.

5.4 ECMAScript API extensibility Adopters of this standard are encouraged to ﬁt their communication needs into the general messaging structure identiﬁed in Clause 7. If needed, this conceptual communication model may be extended by introducing new methods, error codes, and error descriptions. This standard does not specify an extensibility mechanism that maintains conformance to this standard.

6. API instantiation and binding The instantiation of an API implementation and the detection of the instance by a content object are discussed in 6.1–6.3. NOTE—In this clause, “window” is a DOM window object. Typically, a DOM window is a rendered display in the browser environment, but display of the DOM window or its contents is not a requirement.

6.1 Instantiation of an instance of an API implementation An API implementation shall be instantiated in the DOM environment of the content object before the content object is launched. 6.1.1 API DOM object name The instantiation shall be an object named API_1484_11. 6.1.2 API DOM object version attribute The object shall have an attribute named version. The attribute value shall consist of a period-delimited string containing major and minor release values as whole numbers; for example, "1.0."Any characters appearing after the minor release value shall be separated from the minor release value by a period ("."). The syntax and semantics of any characters following the minor release value is not specified by this standard. 6.1.3 API DOM object version value The major version number for the API object shall be "1". The minor version number shall be "0". Therefore, the first three characters of the value of the version attribute shall be "1.0." An implementation may append additional characters to the value of the version attribute, in which case the first four characters shall be "1.0." 6.1.4 Instantiating an API instance The API implementation may be instantiated in any of the following DOM elements, in order of preference: a) b)

The chain of parents of the window within which the content object is launched, up to and including the top window of the Web browser; The opener window of the window within which the content object is launched, if any; or

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

The chain of parents of the opener window, if any exist, up to and including the top window of the Web browser.

6.2 Multiple instances An environment that supports multiple concurrent content objects shall provide a separate instance of an API implementation for each content object. Only a single instance of an API implementation may be instantiated in any particular DOM element.

6.3 Binding a content object to an API instance To use the API, a content object shall locate an instance of the API implementation. The content object shall look for an instance of the API implementation in the following locations, in order of precedence, and stop as soon as an instance is found: a) b) c)

The chain of parents of the current window, if any exist, until the top window of the parent chain is reached; The opener window, if any; and The chain of parents of the opener window, if any exist, until the top window of the parent chain is reached.

NOTE—This order of precedence in searching for an instance of an API implementation ensures that a content object may act as an RTS for another content object. If the order of precedence were to look in the top window ﬁrst, for example, a nested content object would ﬁnd the wrong instance.

6.4 Sample implementation to ﬁnd an API instance (informative) This subclause is informative. A content object may follow a simple algorithm to ﬁnd an instance of an API implementation. — — —

Step 1: Follow the algorithm until an instance is found; Step 2: When found, return the instance and exit the “ﬁnd API instance” routine; or Step 3: If not found, return a null and exit the routine.

A sample ECMAScript implementation of this algorithm tested with several Web browsers is provided below. This sample is informative and may not be an optimal implementation. var var var var

nFindAPITries = 0; API = null; maxTries = 500; APIVersion = "";

function ScanForAPI(win) { while ((win.API_1484_11 == null) && (win.parent != null) && (win.parent != win)) { nFindAPITries ++; if (nFindAPITries > maxTries) { alert("Error in finding API instance -- too deeply nested."); return null; }

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

win = win.parent; } return win.API_1484_11; } function GetAPI() { if ((win.parent != null) && (win.parent != win)) { API = ScanForAPI(win.parent); } if ((API == null) && (win.opener != null)) { API = ScanForAPI(win.opener); } if (API != null) { APIVersion = API.version; } }

7. Content communication state model This clause defines how an API implementation shall behave in response to calls from a content object. The behavior is described in terms of the state transitions for each of the events (versus describing them as the transitions for each event in each state). This clause does not define the behavior of the API-to-RTS communication. It is not a requirement that a specific implementation of an API uses a formal state model or that an API implementation encodes or otherwise represents these specific states or this specific state model. It is required that an API implementation shall provide the described behavior.

7.1 Communication and error states Three states exist for each instance of communication between the content object that is launched and the corresponding API instance. The state model deﬁnes the behavior for each instance. Communication states The following communication states are mutually exclusive: — — —

Not initialized, Running, and Terminated.

The initial API communication state (before the content object is launched) shall be not initialized. Error states The following error states are mutually exclusive: — —

No error (numeric error code value is 0), and Error (numeric error code value is > 0).

The initial error state (before the content object is launched) shall be no error (numeric error code value "0").

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGYâ&#x20AC;&#x201D;ECMASCRIPT APPLICATION

7.2 Events Events are the calls and actions that a content object may explicitly invoke on an API instance and the action or actions resulting from a call. These are also the state transitions. There is one event for each of the eight methods of the API implementation. 7.2.1 Initialize communication session event The initialize communication session event occurs when the content object calls the initialize communication session method to enable communication with the API instance. Initialize communication session event behavior a) b)

Content calls the API instance with the initialize communication session method after ďŹ nding the API instance. When the communication state is not initialized and initialization of communication succeeds, the API instance 1) Sets the communication state to running; 2) Sets the error state to "0" (No error); and 3) Returns "true" to the calling content object. When the communication state is not initialized and initialization of communication fails, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "102" (General initialization failure); and 3) Returns "false" to the calling content object. When the communication state is running, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "103" (Already initialized); and 3) Returns "false" to the calling content object. When the communication state is terminated, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "104" (Content instance terminated); and 3) Returns "false" to the calling content object.

7.2.2 Terminate communication session event The terminate communication session event occurs when the content object calls the terminate communication session method to terminate communication between the content object and the API instance. Terminate communication session event behavior a) b)

Content calls the API instance with the terminate communication session method when content is ready to cease communications. When the communication state is running and terminating communication succeeds along with a successful persistence of all data persisted to long-term storage since the last successful Commit() or Initialize() (whichever occurred most recently), the API instance 1) Sets the communication state to terminated; 2) Sets the error state to "0" (No error); and 3) Returns "true" to the calling content object. When the communication state is running and termination of communication would succeed but for the fact that the commitment of all persistent data failed, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "391" (General commit failure); and 3) Returns "false" to the calling content object.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

When the communication state is running and termination of communication fails for any reason other than a failure to commit all persistent data, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "111" (General termination failure); and 3) Returns "false" to the calling content object. When the communication state is not initialized, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "112" (Attempt to terminate before initialization); and 3) Returns "false" to the calling content object. When the communication state is terminated, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "113" (Attempt to terminate after termination); and 3) Returns "false" to the calling content object.

7.2.3 Retrieve data event The retrieve data event occurs when the content object calls the retrieve data method to obtain a value for a data element of a data model via the API instance. Retrieve data event behavior a) b)

Content calls the API instance with the retrieve data method when content wants to retrieve data. When the communication state is running and the API instance succeeds in retrieving the requested data, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "0" (No error); and 3) Returns the requested data to the calling content object. When the communication state is running and the API instance fails to retrieve the requested data, the API instance 1) Makes no change to the communication state; 2) Sets the error state to the most appropriate of the following: i) "401" (UndeďŹ ned data model element); ii) "402" (Unimplemented data model element); iii) "403" (Data model element value not initialized); iv) "405" (Data model element is write only); v) "408" (Data model dependency not established); or vi) "301" (General retrieve failure); and 3) Returns an empty string ("") to the calling content object. When the communication state is not initialized, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "122" (Attempt to retrieve data before initialization); and 3) Returns an empty string ("") to the calling content object. When the communication state is terminated, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "123" (Attempt to retrieve data after termination); and 3) Returns an empty string ("") to the calling content object.

7.2.4 Store data event The store data event occurs when the content object calls the store data method to set a value for a data element in the data model via the API instance.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGYâ&#x20AC;&#x201D;ECMASCRIPT APPLICATION

Store data event behavior a) b)

Content calls the API instance with the store data method when content wants to store data. When the communication state is running and the API instance succeeds in storing the data, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "0" (No error); and 3) Returns "true" to the calling content object. When the communication state is running and the API instance fails to store the data, the API instance 1) Makes no change to the communication state; 2) Sets the error state to the most appropriate of the following: i) "401" (UndeďŹ ned data model element); ii) "402" (Unimplemented data model element); iii) "404" (Data model element is read only); iv) "406" (Data model element type mismatch); v) "407" (Data model element value out of range); vi) "408" (Data model dependency not established); or vii) "351" (General store failure); and 3) Returns "false" to the calling content object. When the communication state is not initialized, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "132" (Attempt to store data before initialization); and 3) Returns "false" to the calling content object. When the communication state is terminated, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "133" (Attempt to store data after termination); and 3) Returns "false" to the calling content object.

7.2.5 Commit data event The commit data event occurs when the content object calls the commit data method to request that the API implementation commit any cached data to the persistent data store. If the API instance does not cache data, the behavior shall be consistent with that of an API instance that succeeds in committing the cached data. Commit data event behavior a) b)

Content calls the API instance with the commit data method when content wants the API instance to forward all cached data to persistent storage. When the communication state is running and the API instance succeeds in committing the cached data, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "0" (No error); and 3) Returns "true" to the calling content object. When the communication state is running and the API instance fails to commit the data, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "391" (General commit failure); and 3) Returns "false" to the calling content object. When the communication state is not initialized, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "142" (Attempt to commit data before initialization); and 3) Returns "false" to the calling content object.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

When the communication state is terminated, the API instance 1) Makes no change to the communication state; 2) Sets the error state to "143" (Attempt to commit data after termination); and 3) Returns "false" to the calling content object.

7.2.6 Get error code event The get error code event occurs when the content object calls the get error code method to get the error code from the API instance. Get error code event behavior a) b)

Content calls the API instance with the get error code method when content wants to retrieve the latest error state from the API instance. Regardless of the communication state (not initialized, running, terminated), the API instance 1) Makes no change to the communication state; and 2) Returns the error state to the calling content object (e.g., "301").

7.2.7 Get error string event The get error string event occurs when the content object calls the get error string method to return error text for the error code associated with the method parameter. Get error string event behavior a) b)

Content calls the API instance with the get error string method when content wants to retrieve a textual message associated with the specified error code. Regardless of the communication state (not initialized, running, terminated), the API instance 1) Makes no change to the communication state; and 2) Returns text associated with the error code when the specified method parameter value is a known error code; or 3) Returns an empty string ("") when the specified method parameter value is an unknown error code.

7.2.8 Get diagnostics event The get diagnostics event occurs when the content object calls the get diagnostics method to return extended diagnostic information. Get diagnostics event behavior a)

Content calls the API instance with the get diagnostics method when content wants to retrieve the implementation-specific diagnostic information associated with the specified method parameter value from the API instance. Regardless of the communication state (not initialized, running, terminated), the API instance 1) Makes no change to the communication state; and 2) Returns diagnostic information (if implemented), for the specified method parameter value when the parameter value is known; or 3) Returns an empty string ("") when the specified method parameter value is unknown or the get diagnostics method is not implemented.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

8. ECMAScript API methods and syntax The ECMAScript API includes three kinds of methods —

Session methods: Used to mark the beginning and end of a communication session between a content object and an RTS through the API instance; — Data-transfer methods: Used to transfer data model values between a content object and an RTS through the API instance; and — Support methods: Used for auxiliary communications (e.g., error handing) between a content object and an RTS through the API instance. The API implementation shall conform to ECMAScript calling conventions as speciﬁed by ISO/IEC 16262:1998. The parameters and return values shall be of type character string. The syntax and conventions used for methods are shown below. method_label ( [parameter [ , parameter ]] ) — —

A method’s label shall be case sensitive; and Square brackets are used to indicate additional parameters, as described in each method’s speciﬁcations.

Examples: — — —

method_a ( ) // requires no parameters method_b ( param1 ) // requires exactly one parameter method_c ( param1, param2 ) // requires exactly two parameters

NOTES: 1—White space is used in this clause to improve readability and is not required by ECMAScript. 2—This standard does not specify the data bindings of parameters.

8.1 Session methods Sessions methods are used to initiate and terminate data communication between an API instance and a single instance of a content object during a single communication session. 8.1.1 Initialize communication session method Interface syntax return_status = Initialize(parameter) Description This method is used to initiate a communication session. Until the communication state has changed to running and a call to this method has returned "true", any call to another API method results in behavior as deﬁned in 7.2. NOTES: 1—Conformance for content objects requires that Initialize be the ﬁrst method called.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

2—Subsequent calls to Initialize after the initial call has returned "true" do not re-initialize the communication session (see 7.2.1).

Control inputs Called as an ECMAScript API function. Enables communication. Control outputs Always returns from function call. The API implementation shall take whatever actions needed to initialize a communication session with this instance of the content object. If a communication session for this instance of the content object was already enabled, no attempt to re-enable the communication session shall be made and an error shall be returned (see 7.2.1). Data inputs —

parameter: An empty string ("").

The API instance shall accept a call to this method as enabling a communication session. NOTE—The only value allowed for parameter in this standard is an empty string (""). Future revisions of this standard may specify the meanings of non-empty strings.

Data outputs The character string value "true" shall be returned if initialization was successful. Otherwise, the character string value "false" shall be returned. If this method returns "false", the API implementation shall set the error code to a value speciﬁc to that error, and the content object may call GetLastError to determine the nature of the error (see 8.3.1). Example: //Initialize a communication session status = Initialize("") 8.1.2 Terminate communication session method Interface syntax return_status = Terminate(parameter) Description This method is used to terminate a communication session. This method also requests forwarding to the persistent, long-term, data store any data from the content object that may have been cached by the API instance since the last call to Initialize or Commit, whichever occurred most recently. If this method returns "false" the API behavior shall be as deﬁned in 7.2. NOTE—If Terminate returns "false", the content object can call GetLastError to determine whether the failure was because the communication session had already been terminated (see 8.3.1).

Control inputs Called as an ECMAScript API function. Ends communication.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

Control outputs Always returns from function call. If the API implementation is caching data, data shall be forwarded from the cache to the appropriate persistent store. This implies an implicit Commit (see 8.2.3). Data inputs —

parameter: An empty string ("").

The API instance shall accept a call to this method as ending a communication session. NOTE—The only value allowed for parameter in this standard is an empty string (""). Future revisions of this standard may specify the meanings of non-empty strings.

Data outputs The character string value "true" shall be returned if termination was successful. Otherwise, "false" shall be returned. When the method returns "false", the API implementation shall set the error code to a value speciﬁc to that error, and the content object may call GetLastError to determine the nature of the error (see 8.3.1). Examples: //Terminate a communication session status = Terminate("")

8.2 Data-transfer methods Data-transfer methods are used to direct the storage and retrieval of data that is to be available within the current communication session. NOTE—Typically, data which is available in the current communication session will be stored for future use.

8.2.1 Retrieve data method Interface syntax return_value = GetValue(parameter) Description This method requests the information associated with parameter. Control inputs Called as an ECMAScript API function. Control outputs Always returns from function call.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

Data inputs —

parameter: The complete identiﬁcation of an element within a data model, including the identiﬁcation of the data model (e.g., data model.element). If an error occurs, the content object should not rely on the empty string as being a reliable value.

Data outputs A character string containing the value associated with parameter shall be returned. The maximum length shall be determined by the data element as specified in the binding that corresponds to parameter and is not specified by this standard. If an error occurs, then the API implementation shall set the error code to a value specific to that error and return an empty string (""). The content object may call GetLastError to determine the nature of the error (see 8.3.1). Example: //Get the learner's ID learner_id = GetValue("cmi.learner_id"); 8.2.2 Store data method Interface syntax return_status = SetValue(parameter_1, parameter_2) Description This method is used to transfer to the RTS the value of parameter_2 for the data element specified by parameter_1. NOTE—Data may be cached or passed on directly to the RTS by the API instance as the result of a call to SetValue.

Control inputs Called as an ECMAScript API function. Control outputs Always returns from function call. Data inputs — —

parameter_1: The complete identiﬁcation of a data element within a data model, including the identiﬁcation of the data model (e.g., data_model.element). parameter_2: The value to which the content of parameter_1 is to be set.

Data outputs The character string value "true" shall be returned if the RTS accepts the content of parameter_2 to set the value of parameter_1. Otherwise, "false" shall be returned. When the method returns "false", the API implementation shall set the error code to a value speciﬁc to that error, and the content object may call GetLastError to determine the nature of the error (see 8.3.1).

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

Example: //Set the lesson status status = SetValue("cmi.lesson_status","passed"); 8.2.3 Commit data method Interface syntax return_status = Commit(parameter) Description This method requests forwarding to the persistent, long-term, data store any data from the content object that may have been cached by the API implementation since the last call to Initialize or Commit, whichever occurred most recently. If the API implementation does not cache values, Commit shall return "true", set the error code to "0" (No error), and do no other processing. Cached data shall not be modiﬁed as a result of a call to the commit data method. For example, if the content object sets the value of a data element, then calls the commit data method, and then subsequently gets the value of the same data element, the value returned shall be the value set in the call prior to invoking the commit data method. NOTES: 1—Commit would typically be used defensively to reduce the likelihood that persistent data is lost because a communication session is interrupted, ends abnormally, or otherwise terminates prematurely without a call to Terminate (see 8.1.2). 2—At this time there is no companion method to “rollback” or discard any data that may be kept in internal, buffered, temporary, or other transient storage.

Control inputs Called as an ECMAScript API function. Control outputs Always returns from function call. If the API implementation is caching data, data shall be forwarded from the temporary store to the persistent store. Data inputs —

parameter: An empty string ("").

The API instance shall accept a call to this method as a directive to store data. NOTE—The only value allowed for parameter in this standard is an empty string (""). Future revisions of this standard may specify the meanings of non-empty strings.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

Data outputs The character string value "true" shall be returned if the data was successfully committed. Otherwise, "false" shall be returned. If the method returns "false", then the API implementation shall set the error code to a value speciﬁc to that error, and the content object may call GetLastError to determine the nature of the error (see 8.3.1). If the API implementation is not caching values, the character string value "true" shall be returned. Examples: //Commit the values from the cache status = Commit("");

8.3 Support methods Support methods are used for error handling and diagnostics. 8.3.1 Get error code Interface syntax error_code = GetLastError() Description This method requests the error code for the current error state of the API implementation. Calling this method shall not result in a change to the current error state. Repeated calls to GetLastError with no other interceding calls to any other methods shall return the same error code. GetLastError may be called after Terminate. NOTE—For any method called other than GetLastError, GetErrorString, and GetDiagnostic, the API implementation sets the error state as deﬁned in 7.2.

Control inputs Called as an ECMAScript API function. Control outputs Always returns from function call. Data inputs None. Data outputs A character string (convertible to an integer in the range from 0 to 65535 inclusive) representing the number of the last error shall be returned. If an error occurs during the processing of session or data-transfer methods, then the API implementation shall set the error code to a value speciﬁc to that error, and the content object may call GetLastError to determine the nature of the error.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

Examples: //Get the last error code code = GetLastError(); 8.3.2 Get error string Interface syntax error_text = GetErrorString(parameter) Description This method requests a textual message for the error code specified by the value of parameter. A conforming API implementation shall support the error codes identified in Table 2 (see 8.4). Calling this method shall not result in a change to the current error state. NOTE—For any method called other than GetLastError, GetErrorString, and GetDiagnostic, the API implementation sets the error state as defined in 7.2.

Control inputs Called as an ECMAScript API function. Control outputs Always returns from function call. Data inputs —

parameter: The character string representation of the integer value corresponding to an error message.

Data outputs A character string containing the textual description corresponding to the error code speciﬁed by the value of parameter shall be returned. The maximum length shall be 256 bytes (including null terminator). If the requested error code is unknown, an empty string ("") is returned. Examples: //Get text for error code error_text = GetErrorString("201") 8.3.3 Get API-implementation-speciﬁc diagnostics Interface syntax diagnostic_text = GetDiagnostic(parameter) Description This method allows an RTS implementer to provide detailed diagnostics through the API implementation. Calling this method shall not result in a change to the current error state.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

NOTES: 1—This method exists for implementation-specific use. It is useful to those who supply or know the parameter values that may return extended diagnostic information for an instance of an API implementation or RTS implementation. 2—A legitimate use for GetDiagnostic is to get additional machine-interpretable information about an error code. For example, GetDiagnostic("101") might be defined in an application profile as returning detailed error information that includes state information. 3—For any method called other than GetLastError, GetErrorString, and GetDiagnostic, the API implementation sets the error state as defined in 7.2.

Control inputs Called as an ECMAScript API function. Control outputs Always returns from function call. Data inputs —

parameter: An implementation-speciﬁc value for diagnostics. The maximum length of the parameter value shall be 256 bytes (including null terminator).

NOTE—The value of parameter need not be an error code.

Data outputs A character string shall be returned. The maximum length shall be 256 bytes (including null terminator). Examples: //Get implementer diagnostics diagnostics = GetDiagnostic("some_implementer_parameter")

8.4 API implementation error codes Error codes shall be integers represented as character strings. The integer values of error codes shall be in the range 0 to 65535 inclusive. Unspecified error codes in the range 0 to 999 inclusive are reserved for use in future revisions of this standard. Implementation-defined error codes shall be in the range 1000 to 65535. If an error occurs and one or more error codes are specified in Clause 7 for the resulting error state, a call to GetLastError shall return an error code as specified in Clause 7. If multiple error codes for an error state are specified in Clause 7, the precedence among error codes is unspecified behavior. If multiple errors are detected in processing a call to an API instance, one error code shall be returned by a call to GetLastError. Subsequent calls to GetLastError with no intervening calls to other methods shall return the same error code (see 8.3.1). NOTES: 1—Calls to support methods leave the error state unchanged (see 8.3). Successful calls to methods other than support methods reset the error state to 0. 2—If a specific error code is not specified in Clause 7, the most specific applicable error code in Table 2 should be used.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

Table 1 lists the ranges for classes of error codes. Table 1—Classes of error codes Numeric range

Error type

100–199

General errors

200–299

Syntax errors

300–399

RTS errors

400–499

Data model errors

Table 2 lists specific error codes and messages. The name and description columns in Table 2 are informative. The actual character string for the textual message returned for the error code is left to the API implementation. Additional error codes may be specified with data bindings. Table 2—Specific error codes and messages Code

Name

Description

No error

No errors encountered. Successful API call.

101

General exception

A general exception for which a more speciﬁc error code is not available.

102

General initialization failure

An attempt to initialize failed. No other error information is available.

103

Already initialized

An attempt was made to re-initialize communication that had already been initialized.

104

Content instance terminated

An attempt was made to re-initialize communication by an instance of a content object with a communication state of terminated.

111

General termination failure

An attempt to terminate the communication session failed. No other error information is available.

112

Attempt to terminate before initialization

An attempt was made to terminate communication prior to initialization.

113

Attempt to terminate after termination

An attempt was made to terminate communication that had already been terminated.

122

Attempt to retrieve data before initialization

An attempt was made to retrieve a value for a data element before communication had been initialized.

123

Attempt to retrieve data after termination

An attempt was made to retrieve a value for a data element after communication had been terminated.

132

Attempt to store data before initialization

An attempt was made to store a value for a data element before communication had been initialized.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

Table 2—Speciﬁc error codes and messages (continued) Code

Name

Description

133

Attempt to store data after termination

An attempt was made to store a value for a data element after communication had been terminated.

142

Attempt to commit data before initialization

An attempt was made to commit data to storage before communication had been initialized.

143

Attempt to commit data after termination

An attempt was made to commit data to storage after communication had been terminated.

201

General argument error

An attempt was made to pass an invalid argument.

301

General retrieve failure

An attempt to retrieve the value for a data element failed. No other error information is available.

351

General store failure

An attempt to store the value for a data element failed. No other error information is available.

391

General commit failure

An attempt to commit data to storage failed. No other information error is available.

401

Undeﬁned data model element

The data model element passed as parameter in GetValue or parameter_1 in SetValue is undeﬁned. An attempt was made to use a data model element that is not recognized.

402

Unimplemented data model element

The data model element passed as parameter in GetValue or parameter_1 in SetValue is recognized as a valid element but is not supported.

403

Data model element value not initialized

The data model element passed as parameter in GetValue has not been initialized. The value returned by GetValue is an empty string ("").

404

Data model element is read only

The data model element passed as parameter_1 in SetValue is implemented as a read-only data model element.

405

Data model element is write only

The data model element passed as parameter in GetValue is implemented as a write-only data model element.

406

Data model element type mismatch

The value passed as parameter_2 in SetValue does not evaluate to a valid type for the data model element indicated in parameter_1 of a SetValue.

407

Data model element value out of range

The value passed as parameter_2 in SetValue is out of range for the data model element indicated in parameter_1 of a SetValue.

408

Data model dependency not established

The data model element passed as parameter in GetValue or parameter_1 in SetValue is dependent on one or more related data model elements that have a value or values that are unassigned or invalid. Example: In an implementation where data elements are communicated individually through a series of SetValue operations, the identiﬁer of a data object must be set before communicating other data for that data object.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.11.2-2003

IEEE STANDARD FOR LEARNING TECHNOLOGY—ECMASCRIPT APPLICATION

Annex A (informative)

Bibliography [B1] AICC CMI001, AICC/CMI Guidelines for Interoperability, Revision 3.4, October 2000.5, 6 [B2] IEEE 100™, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition.7, 8

5More

information may be obtained from the following URL: http://www.aicc.org/pages/down-docs-index.htm B on API-Based CMI Communication. 7IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA (http://standards.ieee.org/). 8The IEEE product referred to in Annex A is a trademark belonging to the Institute of Electrical and Electronics Engineers, Inc. 6See Appendix

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.

PROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION

IEEE Std 1484.11.2-2003

Annex B (informative)

When to call the terminate communication session method To ensure that the terminate communication session method will be called even if a content object is unloaded, a properly initialized content object should be coded to call Terminate at the following times and under the following circumstances: —

— —

When the content object no longer needs to communicate with the RTS. (Example: When a learner clicks a “submit” button at the end of a test and the learner will not be allowed to change responses, the content object may upload the results of the test with SetValue, then call Terminate.) If Terminate has not been called successfully yet, when an onbeforeunload browser event is processed. (Currently, this may not happen with certain Web browsers.) If Terminate has not been called successfully yet, when an onunload browser event is processed.

NOTE—A call to Terminate is successful if the call returns "true". The call may return "false" if the RTS determines that an error or time out has occurred that prevents the RTS from terminating the communication session normally. How to handle this situation is not deﬁned, but it may be good practice to set a timer to call Terminate again after a few seconds.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 07:03:13 UTC from IEEE Xplore. Restrictions apply.