1、IEEE Std 1484.11.2-2003IEEE Standards1484.11.2TMIEEE Standard for LearningTechnologyECMAScriptApplication Programming Interfacefor Content to Runtime ServicesCommunicationPublished by The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USA4 March 2004IE
2、EE Computer SocietySponsored by theLearning Technology Standards CommitteeIEEE StandardsPrint: SH95175PDF: SS95175Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IEEE Xplore. Restrictions apply. The Institute of Electrical and Electronics Engin
3、eers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 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 +1 978 750 8400. Permission to phot
4、ocopy portions of any individual standard for educationalclassroom use can also be obtained through the Copyright Clearance Center.Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IEEE Xplore. Restrictions apply. Copyright 2004 IEEE. All rights
5、reserved.iiiIntroductionThis introduction is not part of IEEE Std 1484.11.2-2003, IEEE Standard for Learning TechnologyECMAScriptApplication Programming Interface for Content to Runtime Services Communication.This standard describes a learning content ECMAScript API to support the data transfer need
6、s of contentwith a runtime service in a Web-browser-based content delivery environment. This standard provides a start-ing point for specifying a data communication channel and methods to support the data transfer needs ofeducation, training, and human performance support content. The capabilities o
7、f this API model may beextended as other communication needs or methods arise.AcknowledgementsThe IEEE LTSC P1484.11.2 CMI Working Group wishes to thank Tom King and Boyd Nielsen for theircontributions of initial documents used for the preparation of this standard.This standard is based on material
8、from Appendix B of the AICC/CMI Guidelines for Interoperability, Revi-sion 3.4.ParticipantsAt the time this standard was completed, the working group had the following membership:Tyde Richards,ChairJack Hyde,Chair (December 1998March 2001)Scott Lewis,Technical EditorThe following members of the ball
9、oting committee voted on this standard. Balloters may have voted forapproval, disapproval, or abstention.Mitchell BonnettFrank FaranceMike ForeLeonard GreenbergTom KingRolf LindnerKiyoshi NakabayashiBoyd NielsenClaude OstynDaniel RehakRobby RobsonSchawn ThroppMitchell BonnettKeith ChowHockemeyer Cor
10、dGuru Dutt DhingraKameshwar ErankiFrank FaranceHarriet FeldmanMike ForeEddy ForteRonald HoferJack HydeRobert Bruce KelseyTom KingRolf LindnerGregory LuriWilliam MeltonGeorge MiaoKiyoshi NakabayashiBoyd NielsenClaude OstynDaniel RehakTyde RichardsRobby RobsonLarry SternBrian TaliesinSchawn ThroppAuth
11、orized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IEEE Xplore. Restrictions apply. ivCopyright 2004 IEEE. All rights reserved.When the IEEE-SA Standards Board approved this standard on 11 September 2003, it had the followingmembership:Don Wright,Chai
12、rHoward M. Frazier,Vice ChairJudith Gorman,Secretary*Member EmeritusAlso included are the following nonvoting IEEE-SA Standards Board liaisons:Alan Cookson, NIST RepresentativeSatish K. Aggarwal, NRC RepresentativeAndrew IckowiczIEEE Standards Project EditorH. Stephen BergerJoe BruderBob DavisRichar
13、d DeBlasioJulian Forster*Toshio FukudaArnold M. GreenspanRaymond HapemanDonald M. HeirmanLaura HitchcockRichard H. HulettAnant JainLowell G. JohnsonJoseph L. Koepnger*Tom McGeanSteve MillsDaleep C. MohlaWilliam J. MoylanPaul NikolichGary RobinsonMalcolm V. ThadenGeoffrey O. ThompsonDoug ToppingHowar
14、d L. WolfmanAuthorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IEEE Xplore. Restrictions apply. Copyright 2004 IEEE. All rights reserved.vContents1. Overview 11.1 Scope 11.2 Purpose. 12. References 23. Definitions, abbreviations, and acronyms 23.1
15、 Definitions 23.2 Abbreviations and acronyms 34. Conformance 34.1 Behavior. 44.2 API implementation. 44.3 Content object use of an API implementation . 44.4 Outside of scope. 55. Conceptual model (informative) 55.1 Simplified learning content ECMAScript API communication model . 55.2 Basic scenario
16、65.3 Implementation for Web-browser-based content. 75.4 ECMAScript API extensibility 96. API instantiation and binding 96.1 Instantiation of an instance of an API implementation 96.2 Multiple instances 106.3 Binding a content object to an API instance 106.4 Sample implementation to find an API insta
17、nce (informative) . 107. Content communication state model 117.1 Communication and error states 117.2 Events. 128. ECMAScript API methods and syntax 168.1 Session methods. 168.2 Data-transfer methods 188.3 Support methods 218.4 API implementation error codes 23Annex A (informative) Bibliography. 26A
18、nnex B (informative) When to call the terminate communication session method 27Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IEEE Xplore. Restrictions apply. Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4,
19、 2010 at 13:34 from IEEE Xplore. Restrictions apply. Copyright 2004 IEEE. All rights reserved.1IEEE Standard for Learning TechnologyECMAScript Application Programming Interface for Content to Runtime Services Communication1. OverviewThe scope and purpose of this standard are discussed in 1.1 and 1.2
20、.1.1 Scope This standard describes an ECMAScript application programming interface (API) for content-to-runtime-services communication. This standard is based on an API dened in AICC/CMI Guidelines for Interopera-bility, Revision 3.4 B11, dened by the Aviation Industry CBT Committee (AICC). It denes
21、 common APIservices in the ECMAScript language that enable the communication of information between learning-related content and a runtime service (RTS) used to support learning management. This standard does notaddress the data structures that may be transmitted, data security, or communication bet
22、ween an RTS and arelated management system. 1.2 Purpose There is widespread acknowledgement that the ECMAScript API for content-to-runtime-services communi-cation dened in the AICC/CMI Guidelines for Interoperability, Revision 3.4, has broad applicability to sys-tems used for learning management. Th
23、e purpose of this standard is to build consensus around, resolveambiguities in, and correct defects in this ECMAScript API for exchanging data between learning-relatedcontent and a runtime service used to support learning management.1The numbers in brackets correspond to those of the bibliography in
24、 Annex A.Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IEEE Xplore. Restrictions apply. IEEEStd 1484.11.2-2003 IEEE STANDARD FOR LEARNING TECHNOLOGYECMASCRIPT APPLICATION2Copyright 2004 IEEE. All rights reserved.2. ReferencesThis standard sha
25、ll be used in conjunction with the following publication.ISO/IEC 16262:1998, Information technologyECMAScript language specication.2W3C, Document Object Model (DOM) Level 3 Core Specication, Version 1.0, W3C Working Draft 26February 2003.3(See: http:/www.w3.org/DOM/)3. Denitions, abbreviations, and
26、acronyms3.1 DenitionsFor purposes of this standard, the following terms and denitions apply. IEEE 100, The Authoritative Dictio-nary of IEEE Standards Terms, Seventh Edition B2, should be referenced for terms not dened in thisclause.3.1.1 application programming interface (API):A set of standard sof
27、tware interrupts, calls, functions, anddata formats that can be used by an application program to access network services, devices, or operatingsystems.3.1.2 application programming interface implementation (API implementation):An implementation ofthis standard that supplies the services of the appl
28、ication programming interface, in contrast to an implemen-tation of this standard that uses the application programming.3.1.3 application programming interface instance (API instance):An individual execution context andstate of an application programming interface implementation. NOTEThe notion of “
29、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 program-ming interface instance.3.1.5 content object:A collection of digital content that is intended for presentation to a learner by a learn
30、-ing technology system. A content object may include learning material and processing code. Example:Acontent 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 pro-grams and scripts t
31、o dynamically access and update the content, structure, and style of documents. The doc-ument can be further processed, and the results of that processing can be incorporated back into thepresented page (see W3C, Document Object Model (DOM) Level 3 Core Specication, Version 1.04).3.1.7 ECMAScript:An
32、 object-oriented programming language for performing computations and manipu-lating computational objects within a host environment as dened by ISO/IEC 16262:1998. 2ISO/IEC publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varemb, CH-1211, Genve 20, Swit-zerland/
33、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:/ Electronic copies are available in the United Statesfrom the American National Standards Institute, 25 West 43rd St
34、reet, 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: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IE
35、EE Xplore. Restrictions apply. IEEEPROGRAMMING INTERFACE FOR CONTENT TO RUNTIME SERVICES COMMUNICATION Std 1484.11.2-2003Copyright 2004 IEEE. All rights reserved.33.1.8 implementation behavior:Observable actions or appearance of an implementation. See also:imple-mentation-dened behavior; undened beh
36、avior; unspecied behavior.3.1.9 implementation-dened behavior:Unspecied behavior for which each implementation documentshow the choice among the available alternatives is made. Example:Permitting a maximum size, as measuredin octets, of a coding. See also:implementation behavior; undened behavior; u
37、nspecied 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 manag
38、ement system (LMS):A computer system that may include the capabilities to regis-ter learners, schedule learning resources, control and guide the learning process, analyze and report learnerperformance, and schedule and track learners.NOTESome implementations of LMSs also have the ability to launch a
39、nd deliver content. For this standard, thesecapabilities are known as a runtime service.3.1.14 runtime service (RTS):Software that controls the execution and delivery of learning content andthat may provide services such as resource allocation, scheduling, input-output control, and data manage-ment.
40、3.1.15 undened behavior:Implementation behavior for which a standard imposes no requirements. Unde-ned behavior describes nonconforming implementations of this standard. Possible undened behaviorsinclude, but are not limited to: ignoring the situation completely, unpredictable results, behaving in a
41、 docu-mented manner characteristic of the environment, and terminating processing. See also:implementationbehavior; implementation-dened behavior; unspecied behavior.3.1.16 unspecied behavior:Implementation behavior for which a standard provides two or more alterna-tives and imposes no further requi
42、rements on what is chosen in any instance. See also:implementationbehavior; implementation-dened behavior; undened behavior.3.2 Abbreviations and acronymsAICC Aviation Industry CBT CommitteeAPI application programming interfaceCBT computer-based trainingCMI computer managed instructionDOM Document O
43、bject ModelLMS learning management systemRTS runtime serviceAuthorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on February 4, 2010 at 13:34 from IEEE Xplore. Restrictions apply. IEEEStd 1484.11.2-2003 IEEE STANDARD FOR LEARNING TECHNOLOGYECMASCRIPT APPLICATION4Copyright 2004 IEEE.
44、 All rights reserved.4. ConformanceConformance to this standard is discussed in 4.14.4.4.1 BehaviorIn this standard, “shall” is to be interpreted as a requirement on an implementation; “shall not” is to be inter-preted as a prohibition. This standard denes undened behavior in the following ways: If
45、a “shall” requirement or “shall not” prohibition is violated; By the words “undened behavior;” and By the omission of any explicit denition of behavior.There is no difference in emphasis among these ways; they all describe “behavior that is undened.”NOTES:1“Unspecied behavior” and “implementation-de
46、ned behavior” both describe conforming behavior. With “unspeci-ed behavior,” several choices may be possible. This standard does not specify which one is chosen, and the implemen-tation is not requiredto “dene” (i.e., tell in advance) which set of behaviors it has chosen. Similarly, with“implementat
47、ion-dened behavior,” several choices may be possible and this standard does not specify which one is cho-sen. However, the implementation is requiredto “dene” (i.e., tell in advance) which set of behaviors it has chosen.2“Implementation behavior” describes observable action or appearance, which may
48、be conforming or nonconforming.“Undened 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 ObjectModel (DOM) Level 3 Core Sp
49、ecication, Version 1.0) environment of the content object as speci-ed 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 specied in Clause 8 of this standard.4.3 Content object use of an API implementationA conforming content object shall Find an instance of the API implementation as an ECMAScript-compatible object within the DOMenvironment of the content object as described in Clause 6 of this standard;
