Docstoc

SCORM_RTE_ArchitectureSample

Document Sample
SCORM_RTE_ArchitectureSample Powered By Docstoc
					               Terry Thurber SCORM LMS Project Experience




You are reading a description of Terry Thurber's specification and
development of a SCORM compliant LMS. The rest of this document is a
sketch of a data dictionary and RTE proposed by Terry Thurber.

SCORM RTE and the LMS
Except for the rare circumstance where an administrator may need to
reset a particular learner's sequencing state, a SCORM LMS would more
or less be limited to learner management, unless, of course, the LMS
provided an interface that allowed administrators to "easily" develop
SCORM compliant content.

SCORM does not limit to the number of local objectives1 or global2
objectives a manifest employs. The presented architecture will persist
measure collections and metaphor pointers as tagged3 strings in a notes
field. Why? Since the tracking and control information relies on IE DOM
"id" referencing, it makes sense to package all the information as a
single XML to deliver and initialize a reliable "start" (or resume)
course session state to the learner's IE DOM.


1
  Generally, an objective is a measurement between -1.0000 and 1.0000 that
summarizes the weighted average score of a cluster's child activities. One way
to look at it might be to view "1" as perfect (or the objective).
2
  Global objectives are specified in the manifest and appended to the default
course CMI as the CMI objectives collection.
3
  HTML - typically anchor tags.


Terry Thurber                                                               Page 1 of 14
TerryThurberSCORM.doc                                  281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

ADL's "sample" RTE is a large, complicated integration of Java Objects
and the APACHE XML DOM. The sample [ADL] RTE uses exotic session state
services and an Active X applet that synchronizes learner state with
APACHE session management objects (this explains why the sample RTE
does not require large HTTP requests). The sample RTE, through the
magic of the APACHE DOM, also queries the manifest for sequencing and
rollup information after every [API_1484_11] "Terminate()" request.

It would be easy to assume, simply because the sample RTE "works" and
[also] provides generous guidance through documentation and source
code, that an experienced developer could easily translate the ADL
APACHE RTE specification to a client script service. That is an over
simplification. Just the data dictionary for the {ADL] "monster"
requires several hundred pages to describe.

A prospective RTE architecture limited to client script could employ
the MS XMLDOM and mimic the ADL RTE server serviced XML queries at the
client. It makes sense. But, the MS XMLDOM is [very] slow and
"problematic". The client script to [just] run the XML queries would be
quite sizable, and the delivered architecture would still need to
implement the sequencing behaviors while persisting the learners
session states.

The biggest issue, however, related to translating the sample ADL RTE
to a script service is not technical, it is conceptual. Everything ADL
publishes regarding it's RTE is based on hierarchical XML strategies.
To move to a client script RTE requires a linear strategy using indexed
(client document addressing) pointers rather than relational
[hierarchical] XML query pointers.

And that gentlemen, is the "nut" this presentation cracks.

A client script RTE requires that all pointers, for the entire session
are defined, resolved and delivered to the learner's client when a
course is selected.

Data structures
This proposal assigns the structures to implement a SCORM conformant
[client script] RTE to three groups:
       Records
       Definitions
       Assemblies

These data groups are fixed length strings and are addressed using DOM
document IDs (some will be embedded in the DHTML tree view) and
"metaphors" bound through defined sub-string functions. For example, to
retrieve the "Rollup Objective Measure Weight" would require the
document ID and the string pointers to it's sub string in the
activity's "Rollup State Definition" (Figure 7) structure.

Records are read write structures. Default states will be defined when
the course is imported. The RTE behaviors4 will read, write and persist
"record" states.

4
 See appendix C, SCORM Sequencing and Navigation (1.3.1), p SN-C-3, "Sequencing
Behavior Pseudo Code".


Terry Thurber                                                               Page 2 of 14
TerryThurberSCORM.doc                                  281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

Definitions are read only structures that will be defined by the
manifest parser when a course is imported.

Assemblies and subassemblies are read only structures that will be
defined by the manifest when a course is imported. These guys are
global objective and rule action definition structures. Content may
define as many of these elements as required. From the RTE perspective
they will be "stacked" and made available to the RTE behavior engine,
for interpretation.

Dynamic CMI elements
There is a default CMI. The RTE will dynamically service the so called
CMI collection elements. These elements provide global objectives,
comments and interactions arrays to the CMI.

Global objectives are "fixed" in the manifest. The other CMI
collections are dynamic. This means the SCO, LMS, or learner would add
elements to these collections, interactively. The LMS will need to
assign the elements, in those cases, to the CMI as they are demanded.
The CMI collection [arrays] must persist their state. And, as in all
the tracking data, they will be stored as HTML tag strings in a notes
field and offered as anchor tag ids by an innerHTML string parsed from
an XML object. The script to add the collection elements to the CMI has
been prototyped (see Figure 1).

Figure 1 - JavaScript function to interactively add CMI elements.




The function in Figure 1 adds HTML text and input objects to the CMI
parent element in the buttons form. The RTE will address CMI values
through the tag's "id" property.




Terry Thurber                                                         Page 3 of 14
TerryThurberSCORM.doc                            281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

Activities, clusters, assets and sco[s]
From an API prospective, activities are typically characterized as an
sco (communicates with the CMI through the API) or an asset (non
communicative). In the context of the API, there is no distinction.
But, from a sequencing prospective, there are only two types of
activities. Those that service an "attempt" and those that do not.

With few exceptions, activities that can be attempted will not maintain
an activity set5 rollup accrual. These are the so called leaf, sco, or
asset items. Both assets and scos, as all manifest items, have default
states and subject to sequencing. To be SCORM compliant, an LMS must
implement a default state.

Activities that cannot be attempted, the so called module or cluster
activities, maintain rollup accruals. Also referred to as "rollup
objectives" by the sequencing behaviors, these objects will also be
used in the proposed RTE to maintain progress and success state counts
for their child activity set.

Pseudo code
The SCORM provided pseudo code will serve as framework for scheduling
sequencing and state updates. The presented RTE maintains accrual
summaries and state accumulators and will not need to iterate the child
activity set at each termination.

Persistence
When the learner requests a course, the state image from the previous
session is forwarded to the client. As the learner interacts with and
terminates each activity, a 20 (or so character string, the activity
state record or ASR) will be forwarded to the server in a URL.

The rollup activities, however, will remain with the client until the
course session is ended and [then] are forwarded to the LMS. Should an
abnormal ending occur as a result of system or network failure, the LMS
will know through a flag field that the last session ended abnormally
and reassess the rollup activity accruals and accumulators before
forwarding the "resumption" state to the learner's client. At most, the
learner will need to complete the activity that was active when the
abnormal ending occurred.

How to use this document
It is only important to understand that the three types of data
structures (records, definitions and assemblies) are addressable
through a document id set when the course is imported (like a DBF
index). And, that the sub string pointers within each structure will be
define by the function(s) that the RTE implements to retrieve or set
the metaphors (like a DBF field). Also understand that the structures
will be developed and assigned IE document IDs when the manifest is
imported.

Understanding rollup
Rollup is what happens when the learner terminates an activity.
Information in the CMI, set by the API as a result of the learner's

5
 An activity set are the immediate item descendants of a parent item. The set
can include assets, scos, and modules. Each activity in the set may offer a
unique weighted "measure" to the parent's rollup objective.


Terry Thurber                                                               Page 4 of 14
TerryThurberSCORM.doc                                  281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

interaction is transposed to corresponding metaphors (sub-strings in
the activity's state and definition structures). In the ADL RTE, this
information is forwarded to the server and an XML object using a
zillion Java classes. With the proposed RTE, this will all happen at
the client. It may be helpful to look at a simple rollup scenario that
describes a default rollup through the activity path6.

        Figure 2 - Activity Path




In Figure 2, the rollup activity path is highlighted. "Question 1" will
rollup to it's parent, "Exam", who will in turn rollup to root, the
"organization" or TOC node. All activities, should their state allow,
will rollup up to the root. SCORM specifies a formula to compute the
rollup (see Figure 3).

Figure 3 - Objective Rollup Formula




6
 The activity path represents the ancestry of the activity being terminated.
The activity is rolled up to it's parent based on it's parents sequencing
construct, the parent is rolled up to it's grandparent based on the
grandparent's sequencing constructs, the grandparent is rolled up to it's great
grandparent based it's great grandparents sequencing construct, and so on.


Terry Thurber                                                               Page 5 of 14
TerryThurberSCORM.doc                                  281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

The Objective Rollup Formula assesses the value of the activity's
rollup objective7.

It would be helpful to demonstrate a default rollup. Let's assume the
"weighting" is 1 for each rollup point. First we need a starting point.


                Table 1 - Start Rollup

                        Activity                      Rollup
                        Root                             0
                        Exam                             0


        The learner correctly answers "Question 1" and the rollup is
        assessed in Table 2.

                Table 2 - Rollup Question 1 correct

                        Activity                      Rollup
                        Root                             1
                        Exam                             1


        Next the learner correctly answers "Question 2" and "Question 3"
        correctly in Table 3.

                Table 3 - Question 1, 2, and 3 correct

                        Activity                      Rollup
                        Root                             1
                        Exam                             1


        Note the rollup objective measures for both Root and Exam remain
        the same. Next, the learner revisits "Question 3", and submits an
        incorrect answer for "Question 3" in Table 4.

                Table 4 - Question 1 and 2 correct, Question 3 incorrect


                        Activity                      Rollup
                        Root                           .6667
                        Exam                           .6667


        In table 4, the rollup for Exam is determined as ( 2 / 3), while
        the rollup for Root is determined as ( .6667 / 1). In this case,
        Exam evaluates 3 children (Q1,Q2,Q3) and Root only evaluates 1
        child (Exam).


7
 The metaphor for the for the rollup objective is "Objective Normalized
Measure"


Terry Thurber                                                               Page 6 of 14
TerryThurberSCORM.doc                                  281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

Activity State Record
The activity state record represents the collection of metaphors that
the RTE sequencing and rollup service may read or write when the
activity terminates (See Figure 4).

Figure 4 - Activity State Record (ASR default)




The activity's state will be, as other components of the proposed RTE,
addressed using a combination of DOM indexes and sub-string functions
that point to the metaphor requested. Shown are the implicit states (or
settings). Any explicit settings would be defined in the manifest and
will be assigned to the ASR when the course is imported. We might note
that the CMI score is written to the rightmost metaphor (Objective
Normalized Measure) by the RTE when the activity is terminated.

Activity State Definition
The activity definition presents read only metaphors that control the
activity's passage through the RTE sequencing and rollup engine.

Figure 5 - Activity State Definition (ASD - default)




Terry Thurber                                                         Page 7 of 14
TerryThurberSCORM.doc                            281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

Most of the metaphors in the ASD are rendered at course import from
elements and attributes in the manifest. It may also be interesting to
note that the first question the RTE sequencing service will ask, "Is
the activity Tracked?". The first metaphor in the ASD is "Tracked"!

The three rightmost metaphors are not defined in the manifest. They are
requirements of the proposed RTE. They will be set at course import and
will contain the numeric part of the IE DOM "id" index. For example,
the client DOM "id" might look something like "ASDSDP999", for the
activities (shared or unique) sequencing definition pointer (Figure 5).

Rollup State Record
The rollup state is a read write collection of metaphors that will
accrue the rollup for it's activity set and maintain a set of rollup
states to manage passage through the RTE sequencer. The RSD is
associated with module items and referred to in the ADL documentation
as the "rollup objective". The metaphors maintain state assessment
accumulators for its children (activity set) as well as states that
will be assessed as it is rolled up to its parent.

Figure 6 - Rollup State Record (RSR - default)




It also presents many of the metaphors the Activity State Record
encapsulates (Figure 4). That is because it may [also] be part of an
activity set, thus, subject to many of the rollup metrics a leaf
activity is.




Terry Thurber                                                         Page 8 of 14
TerryThurberSCORM.doc                            281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

Rollup State Definition
The rollup state definition is a collection of read only metaphors that
control the "rollup activity's" rollup to it's parent. As other so
called "definition" structures, the RSD is created and assigned a DOM
pointer when the manifest is imported.

Figure 7 - Rollup State Definition (RSD - default)




As shown in Figure 7, the RSD shares a few traits with the ASD (Figure
5). Many of the leftmost attributes control the behavior of it's
children (or activity set). The left four sequencing control metaphors
determine whether or not a navigation request from one of the RSD's
children is appropriate. Also, recalling the rollup example where our
learner changed a "correct" answer to an "incorrect" answer (Table 4),
we should note that the reason the incorrect answer was allowed was
[because] the "Use Current Attempt Objective Information" metaphor in
the RSD is "True".

Figure 8 - Control Mode




The sequencing control mode element prescribes the five leftmost
metaphors of the RSD (Figure 7). The sequencing control mode element is
a child of the rollup activity described by the RSD. In Figure 8, the
"false" value for the choice attribute indicates that the children of
the RSD (assets and scos) are not allowed a navigation request that
resulted from the learner selecting an activity from the course tree
view.


Terry Thurber                                                         Page 9 of 14
TerryThurberSCORM.doc                            281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

Global Objectives
As mentioned, there are local objectives, those that the rollup to the
"Objective Normalized Measure" in the parent activity, RSR (Figure 7),
and those that that the SCO typically writes to in the CMI objectives
collection, the global objectives. Global objectives are specified by
the manifest. They are of two types, the Primary Objective, and the
[not primary] objectives.

They can communicate with local objectives and are consumed by the RTE
sequencing service and affect sequencing outcomes. Each activity set
may have it's own objective definition based on the behaviors the
content developer desires when the objectives are submitted to the RTE
rollup service.

Objectives are [also] stackable. When the RTE sequencing service is
flagged to consume global objectives, a primary objective would always
be required. The secondary objectives would stack after it. The
proposed RTE will parse the "stacked" objectives when "the stack" is
scheduled for use by the RTE sequencing and rollup service. Besides
portability, another advantage to stacking objective definitions is
that it will only require one IE DOM "id" for the "stack".


Primary Objective
The Primary Objective would be the first objective assigned to the CMI
and will have the index 0 (cmi.objectives.0.id).

Figure 9 - Primary Objective Definition Assembly (PODA - default)




The PODA may present zero or many times in the manifest and is
associated with the activity set of it's parent (RSD - Figure 7).
Regardless of multiplicity, it is only allocated once to the CMI. The
reason for "apparent" duplications is that the content developer may


Terry Thurber                                                       Page 10 of 14
TerryThurberSCORM.doc                            281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

want to evoke specific rollup behaviors for the associated activity
set.

Figure 10 - Target Objective Definition Subassembly (TODS - default)




TODS (Figure 10) will always stack after the PODA (Figure 9). There
could be several TODS associated with the activity set. The SCO is
responsible (as with the PODA) for writing the measure to the TODS
respective CMI element. The RTE sequencing and rollup service will
consume the CMI objectives collection's measure and status, serviced
through the SCO, associated with the "Target Objective ID" metaphor.

The TODS CMI objectives collection index will always be greater than 0.

Rule Actions
Rule Actions allow the content developer to imply behaviors that affect
the activity tree that are outside the scope of the prescribed
sequencing and rollup serviced by the RTE. A content developer can, for
example, embed an action based on a specific condition that will force
the RTE service to disable a particular activity set, or, for that
matter, exit the course.

They come in several flavors, exit conditions, preconditions, post
conditions. They typically have similar structures as presented in the
manifest, but, depending on the rule action, may have a different token
set for a specific metaphor than a rule action of a another type. For
space purposes, this presentation will be limited to the Rollup Rule
Action. These structures are also stackable. One difference between
these structures and many of the other structures described is that
some rule action elements do not have a default. Therefore, they would
not be addressable and would not require an IE DOM element ID.




Terry Thurber                                                       Page 11 of 14
TerryThurberSCORM.doc                            281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

Rollup Rule
The rollup rule allows the content developer to define how learner
progress for cluster activities is to be evaluated8. There can be 0 or
many.

Figure 11 - Rollup Rule Action Definition Subassembly (RRADS)




Descriptions of the metaphors, and their tokens for the RRADS are
listed in the glossary. However, it may be helpful to demonstrate how
the RRADS is implemented with a sample manifest. So let's review the
tokens associated with the RRADS understanding that the other rule
action definitions may have different token sets associated with their
metaphors.

         Rollup Rule Child Activity Set          0   -   All
                                                 1   -   Any
                                                 2   -   None
                                                 3   -   At Least Count
                                                 4   -   At Least Percent

         Rollup Rule Condition Combination       0 - All
                                                 1 - Any

         Rollup Rule Condition Operator          0 - NO-OP
                                                 1 - Not

         Rollup Condition                        0   -   Satisfied
                                                 1   -   Objective Status Known
                                                 2   -   Objective Measure Known
                                                 3   -   Completed
                                                 4   -   Activity Progress Known
                                                 5   -   Attempted

8
    SCORM Sequencing and Navigation (SN) Version 1.3.1 p Sn-3-25


Terry Thurber                                                                  Page 12 of 14
TerryThurberSCORM.doc                                       281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience

        Rollup Condition (continued)        6 - Attempt Limit Exceeded

        Rollup Rule Action                  0   -   Satisfied
                                            1   -   Not Satisfied
                                            2   -   Completed
                                            3   -   Incomplete

        *Note - other rule action structures may share the rollup rule's
        metaphor names, but may have a different set of tokens.

        In the simplest terms, the rule actions evaluate activity state
        and status metaphors to determine state assignments for other
        metaphors.


Figure 12 - Example application of the RRADS

                                            0 0 0 0 0 . 0 0 0 0 0 0 0 0
                                            1 0 0 0 0 . 0 0 0 0 0 1 0 1
                                            Using the manifested Rollup Rule
                                            Action, this is how the RRADS for
                                            each rule action specified in Figure
                                            12 would be interpreted by the RTE:

                                            The top rule action indicates that
                                            when all the children of the cluster
                                            have either their Object Progress
                                            Status, or Objective Satisfied
                                            Status set true, then set the
                                            Objective Progress Status and the
                                            Objective Satisfied Status for the
                                            child's [cluster parent] RSR to
                                            true.

                                            The bottom rule action states that,
                                            should any child in the cluster NOT
                                            have either it's Objective Progress
                                            Status or it's Objective Satisfied
                                            Status set True, then the Objective
                                            Progress Status for the child's
                                            [cluster parent] RSR will be set
                                            True and Objective Satisfied Status
                                            for the child's [parent cluster] RSR
                                            will be set false.


At course import the SMP will parse any rollup rule elements to their
respective metaphors and assign an IE document ID.

In the example rollup rules presented in Figure 12, there are two
rollup rule elements that will be processed when an activity from the
associated activity set is rolled up to the activity set's parent RSR
(Figure 6). The parsed representation of the two RRADS (Figure 11) are
shown in the panel on the right. It appears as a binary field with a
decimal point, but the values, instead, represent condition and action
tokens. The RRADS will stack front to back in manifest order.

The information panel demonstrates how tokens may address (read or
write) the states of more than one metaphor.

Terry Thurber                                                             Page 13 of 14
TerryThurberSCORM.doc                                  281.851.5663/bos4@mindspring.com
               Terry Thurber SCORM LMS Project Experience


In addition to the GUIs on the first page, Terry has developed an ISAPI
server to manage learner interaction and activity states, DHTML Course
Navigation Tree and a SCORM 2004 API (API_1484_11)

You may contact Terry at:

Terry Thurber
7010 Napier Ln
Houston Tx 77069
281 851 5663 / 281 397 8895
bos4@mindspring.com




Terry Thurber                                                       Page 14 of 14
TerryThurberSCORM.doc                            281.851.5663/bos4@mindspring.com

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:22
posted:12/13/2010
language:English
pages:14