Portable Custom Interaction Best Practice Change Proposal: Added Support for Lifecycle, XML Definition, and Shared Libraries
Title: Portable Custom Interaction Best Practice Change Proposal: Added Support for Lifecycle, XML Definition, and Shared Libraries
Authors: Michael Aumock (Pacific Metrics, USA) Colin Smythe (1EdTech, UK)
Version: Public Draft
Version Date: 21 April 2014
Release: 1.0
Summary: The 1EdTech Portable Custom Interaction (PCI) Best Practice has deficiencies in the complete management of an item lifecycle, the XML definition describing the interaction, the ability to define delivery system shared libraries allowing items to leverage at rendering. The additions required to address the PCI deficiencies will require the release of an 1EdTech Portable Custom Interaction Best Practice v1.1
Table of Contents:
1 OVERVIEW ..........................................................................................2
1.1 INTERACTION LIFECYCLE ADDITIONS .......................................2
1.2 XML DEFINITION ENHANCEMENTS .............................................2
1.3 SHARED JAVASCRIPT LIBRARIES .................................................4
1.4 APIP ACCESSIBILITY ........................................................................6
2014 © 1EdTech Consortium
1 Overview
The 1EdTech Portable Custom Interaction Best Practice has deficiencies in the complete management of an item lifecycle, the XML definition describing the interaction, the ability to define delivery system shared libraries allowing items to leverage at rendering.
1.1 Interaction Lifecycle Additions
The Interaction lifecycle covers the areas of initialization, configuration, and rendering. The area of deficiency is configuration updates, destruction, and accessibility. The proposal submits the addition of two interaction methods and three qtiCustomInteractionContext methods for the ability to address an item’s full lifecycle. Therefore, Pacific Metrics proposes support for the following methods:
Table 1.1 Required Global Context Methods
|
Required Method |
Consumer |
|
Update(responseIdentifier) The update method allows the delivery engine or other interactions to update a specific interaction in the view. The method may be called at anytime after interaction initialization. |
Rendering Engine and/or Custom Interaction |
|
Destroy(responseIdentifier) The destroy method removes an interaction from the view. It is the responsibility of the interaction to perform DOM destruction and/or other tasks related to removing itself from the delivery engine. |
Rendering Engine |
Table 1.2 Required Interaction Methods
|
Required Method |
Consumer |
|
Update() The update method provides the ability for an interaction to refresh its state anytime after initialization. |
Rendering Engine |
|
Destroy() The destroy method, when called, requires an interaction to remove all DOM elements or other artifacts from the delivery engine. |
Rendering Engine |
Document additions will be required to define the new methods within the 1EdTech Portable Custom
Interaction Best Practice document.
1.2 XML Definition Enhancements
The XML definition defined for Portable Custom Interactions does not normalize elements required to describe an interaction. By identifying the elements of an interaction, delivery systems are provided with consistent access to information. The following is an example of a proposed XML definition.
Table 1.3 XML Definition Example
1: <!--CUSTOM INTERACTION -->
2: <customInteraction responseIdentifier="graph1">
3: <portableCustomInteraction customInteractionTypeIdentifier="IW30MX6U48JF9120GJS">
4: <templateVariableMapping templateIdentifier="X" configurationProperty="areaX" />
5: <templateVariableMapping templateIdentifier="Y" configurationProperty="areaY" />
6: <responseSchema href="http://imsglobal.org/schema/json/v1.0/response.json"/>
7: <resources location="http://imsglobal.org/pci/1.0.15/sharedLibraries.xml">
8: <libraries>
9: <lib id="/IMSGlobal/raphael_2_0" />
10: <lib id="/Pacific Metrics/Product One/three_2" />
11: <lib id="/Pacific Metrics/pickadate" />
12: </libraries>
13: </resources>
14: <properties>
15: <entry key=”x”>10</entry>
16: <entry key=”y”>30</entry>
17: <entry key=”title”>Your Awesome ${title}</entry>
18: <properties key="border">
19: <entry key=”width”>path.to.value</entry>
20: <entry key=”color”>method(‘value’)</entry>
21: </properties>
22: </properties>
23: <markup>
24: <div id="graph1" class="graph”></div>
25: </markup>
26: </portableCustomInteraction>
27: </customInteraction>
28: <!--CUSTOM INTERACTION -->
• Line 2: In the original PCI XML definition the customInteraction element used an id attribute as an identifier. In the new form of XML the id attribute has been replaced with the responseIdentifier attribute for consistency with the APIP standard. • Line 6: The responseSchema defines the location of the schema to validate response provided by the interaction. In order to ensure responses returned from custom interactions are interoperable, a JSON schema has been produced to address consistency. The JSON schema aligns with the APIP definition for XML item responses. The flexibility of the APIP standard should be sufficient for most interactions to adhere to. In the event of simulations or more advanced interaction types a deviation from the standard JSON schema is expected. • Line 7: The resources element defines a list of shared libraries used by the interaction. In the original document the script element was used to import JavaScript into the page. The lib elements supersede this feature and define a path-based key to identify script libraries. In the following section, “Shared JavaScript Libraries”, is the definition of libraries. • Line 14: To ensure the safety of rogue JavaScript from entering an item through configuration the properties element has superseded this JSON block found in the original custom interaction document. The qtiCustomInteractionContext will parse the XML into a JavaScript object with string values. The interaction developer will be responsible for parsing the dynamic nature of the string values. • Line 17, 19: Examples of possible value resolution by using dot notation or string templates. • Line 20: The use of eval in an interaction is highly discouraged due to the intent of protecting the delivery engine. • Line 23: The final block of configuration, the markup element, contains an HTML representation to be displayed by the rendering engine.
1.3 Shared JavaScript Libraries
Shared JavaScript libraries provide a mechanism for delivery engines to ensure, interactions, a specific version of a library will be available during rendering time. At the time of this writing AMD modules are a viable solution to the management of multiple JavaScript libraries. As there are no strong alternatives to this technology shared libraries will be available through AMD style definitions. With the complexity of defining and managing shared libraries within multiple delivery systems the least impact solution is a XML definition that may be extended by each vendor. 1EdTech will maintain a master definition of libraries. Vendors compliant with the best practice will provide default libraries defined in the master list, but each vendor may extend the list of shared libraries to meet their needs. The flexibility allows 1EdTech minimal impact in managing the shared library dependencies. Vendors have the opportunity to extend the list as needed. Interaction developers have the ability to target development to the particular platform with assurance of functionality. The following is a suggested XML example:
Table 1.4 Repository XML Definition
1: <?xml version="1.0" encoding="utf-8"?>
2: <repository>
3: <resources vendor="IMSGlobal">
4: <libraries>
5: <lib name="requireJS" href="//cdn.network/1.3.2/require.js"/>
6: <lib name="almond" href="//cdn.network/2.9.6/almond.js"/>
7: <lib name="raphael" href="//cdn.network/1.9.2/raphael"/>
8: <lib name="raphael_2_0" href="//cdn.network/2.0.3/raphel"/>
9: <lib name="raphael_2_0_4" href="//cdn.network/2.0.4/raphel"/>
10: </libraries>
11: </resources>
12: <resources vendor="Pacific Metrics 1.0.1" href="http://www.pm.com/">
13: <libraries>
14: <lib name="three" href="//cdn.network/three"/>
15: <lib name="pickadate" href="//cdn.network/three"/>
16: </libraries>
17: <product name="Product One">
18: <libraries>
19: <lib name="three_2" href="//cdn.network/three"/>
20: </libraries>
21: </product>
22: <product name="Product Two">
23: <libraries>
24: <lib name="three_2_0_1" href="//cdn/three"/>
25: </libraries>
26: </product>
27: <product name="Product Three">
28: <libraries>
29: <lib name="raphael" href="//cdn/three"/>
30: </libraries>
31: </product>
32: </resources>
33: <resources vendor="Pacific Metrics 1.0.2" href="http://www.pm.com/sl.xml"/>
34: <resources vendor="Pacific Metrics 1.0.3" href="http://www.pm.com/sl2.xml"/>
35: <resources vendor="Pacific Metrics 1.0.4" href="http://www.pm.com/sl3.xml"/>
36: <resources vendor="Measured Progress" href="http://www.mp.com/"/>
37: <resources vendor="ETS" href="http://www.ets.com/"/>
38: <resources vendor="ACT" href="http://www.act.com/"/>
39: <resources vendor="Pearson" href="http://www.p.com/"/>
40: </repository>
• Line 3: The resources element defines a list of products and library definitions. The vendor attribute is a unique identifier within the nested set of resources. This provides key based references as in the example defined in XML Definition Enhancements. • Line 4: The libraries element defines a list of libraries available. • Line 5: The lib element defines a unique library for a resource or product. The name attribute provides a part of the key based reference as displayed by the example “XML Definition Enhancements”. The requireJS library key is defined as “/IMSGlobal/requireJS”. The href tag defines the URL to the library implementation. • Line 13: The library tag defined at the top-level resource element is a global definition that applies to all nested products. In this example the products following the global definition will include the “three” and “pickdate” libraries at rendering time. • Line 17: The product element defines a product provided by a vendor. The name attribute is a unique identifier within the nested set of resources. This provides key based references as in the example defined in XML Definition Enhancements. • Line 33: The resources element may define the optional href attribute. The attribute defines a URL to a hosted repository definition. The intent is for vendors to extend the base repository definition with their own managed definition. This provides vendors the flexibility to make adjustments to the definition without the need to modify the 1EdTech managed definition.
1.4 APIP Accessibility
The assessment and accessibility communities in 1EdTech have formed a task force to work on improvements to the way accessibility is addressed in APIP. Rendering and delivery issues are being discussed as well as looking at ways to more closely integrate with other web accessibility standards like ARIA and WCAG. Outcomes from the discussions and decisions of this group will inform the approach PCI recommends for defining and delivering accessible custom interactions and will likely result in a future change proposal. More details about the progress of the accessibility task force will be communicated via the APIP public forum: http://www.imsglobal.org/community/forum/categories.cfm?catid=110 It is requested that this proposal be accepted and included so that it forms a part of the 1EdTech Portable Custom Interaction Best Practice.
