This report covers four sets of comments incorporated into Draft 8:
Note:
The following are comments received in the LTSA Draft 6 ballot.
| Comment # | Disposition Status | Comment Details/Change Description |
| D06/DB01 | Completed. Added to draft 7. |
Please add my name to the list of working group members. |
| D06/DB02 | Completed. Done in draft 7. |
Table of Contents field needs to be updated so that the new entries/changes are reflected. |
| D06/DB03 | Not yet completed. Add to draft 8. |
In section 3.9, 2nd sentence: "Bus notation is useful when the are a large number of subsystems, the functions or ..." should be changed to "Bus notation is useful when there are a large number of subsystems, the functions or...". |
| D06/DB04 | No change. The preferred spelling is "recordkeeping". |
According to my dictionaries, the word 'recordkeeping' should be separated into two words, 'record keeping'. This change should be made consistently throughout the document. |
| D06/DB05 | Completed. Corrected in draft 7. |
In section 5.5, last paragraph, first sentence: 'The stakeholder perspectives is considered a separate...' should be changed to 'The stakeholder perspectives layer is considered a separate...'. |
| D06/DB06 | Completed. Changed in draft 7. |
In my dictionaries, 'judgment' is a preferred spelling, as opposed to 'judgement' as is used in section 10.13. |
| D06/RR01 | Completed. Much editorial material removed from draft 7. Annexes C and D are merged. Reduced the size of the document by about 30 pages. |
In my experience, the need to provide a common vocabulary and set of concepts for discussing Learning Technology Systems Architecture is primarily the need to be able to communicate the function and scope of products and services, both internally within a company and externally to customers and consumers. I feel the current document is too long, too complex, and has too much 'editorial' material to have any wide impact in this regard. |
| D06/RR02 | Pending. Preliminary response: Need more information on which ADL and IMS documents were attempted to map into LTSA framework. In the context of LTSA, APIs are the lowest layer, so an API specification isn't really an "architecture", per se, in the context of defining system architecture. Regardless, need more information from Robby, Claude, or Phil on *systems* (not APIs) that don't map to LTSA |
I tried to map the architecture which has been loosely discussed in ADL, IMS and other circles on to the normative layer of the draft document (Figure 4). The latest architectural discussions speak in terms of services, not resources. As far as I can tell, this is a different view than that taken by the LTSA document. I *may* be able map each 'learning service' to one or more boxes in Figure 4, but at the level of API's the data is flowing between systems, not data stores, and I believe it will take work to determine if the draft could be made to fit the direction in which learning technology may be moving over the next year. Since I have not done this work, and indeed since I don't have a crystal ball that would allow me to properly do the work, I feel that an abstain is the only appropriate response. |
| D06/BT01 | Completed. Changed in draft 7. |
Clause 1.2, page 9: The arrows make the intent of the sentences unclear, and this lack of clarity is exacerbated by the removal of the italicized clauses from the parentheses that they were in in draft 5. It would seem to be clearer to replace the parentheses, and replace the arrows with 'i.e., '. |
| D06/BT02 | Completed. Subclause 1.3 was removed in draft 7. See also disposition of BT04. |
In Clause 1.4, page 14, it states that Clause 1 is informative in its entirety. However, subclauses 1.3, 1.4, and 1.5 are individually described as informative, leading the naive reader to assume that subclauses 1.1 and 1.2 are, in fact, normative. |
| D06/BT03 | Completed. All terms listed in D06/BT03 are now identified as "informative", except for "learner" which is a normative part of LTSA. Changes incorporated into draft 7. |
In Clause 3, the choice of which definitions to identify as informative and not normative seems arbitrary. In particular, 3.25 (distance learning) is identified as informative, but 3.36 (nomadic learning) is not. I would suggest identifying the following subclauses as informative: 3.24 (developer), 3.33 (learner), 3.35 (learning experience), 3.36 (nomadic learning), and 3.37 (nomadicity). |
| D06/BT04 | Completed. Clause 1.3 was removed. Clause 5 had much wording removed. |
In Clause 5, page 25, Figure 3 seems to be essentially a duplicate of Figures 1 and 2. Is there a reason for the duplication? |
| D06/BT05 | No change. The terms in Clause 3 are definitions. In subclauses 10.7.*, the terms are further explained in the context of the methodology used for LTSA. |
Subclauses 10.7.2 and 10.7.3 seem to duplicate, in much greater detail, information already presented in Clause 3, subclauses 3.13, 3.17, 3.18, 3.22, 3.28, 3.38, 3.43, and 3.47. Is there a reason for the duplication? Further, Clause 3 is normative and Clause 10 is not, suggesting that the (much sparser) definitions in Clause 3 are the ones that count. |
| D06/BT06 | Completed. Annex D was removed in almost its entirety. |
The caption to Figure 48 on page 72 doesn't make sense ('Learner in not a computer.'). 'Learner is not a computer', maybe? |
| D06/BT07 | Completed. Annex D was removed in almost its entirety. |
Similarly for the caption to Figure 53 on page 75 ('... insight to best learning experience.'). '... insight to the best learning experience.'? '... insight to drive the learning experience.'? |
As per the 2000-12 1484.1 WG meeting, the following are comments received in the extended comment period to 2000-12-15: No comments we received.
| Comment # | Disposition Status | Comment Details/Change Description |
No comments were received.
The following are comments received after the 2000-12-15 deadline for Draft 6 (for incorporation into Draft 7). They will be resolved and incorporated into Draft 8 or 9.
| Comment # | Disposition Status | Comment Details/Change Description |
| Comment # | Disposition Status | Comment Details/Change Description |
| D06/DR01 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
The various descriptions of the 19 LTSA components are not consistent in their presentation in the normative text. Some components are described by what the component is. Some components are described by what to component does. Some descriptions are abstract while others are concrete. The most definitive definition is often in the figure title In general, the individual descriptions cannot be read in isolation, and they are not consistent in detail. Acceptable resolution 1) Rewrite the description of each component addressing all of the comments below. General comments: |
| D06/DR02 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
All components must be described consistently (and should be in boring standard's words). This includes using the same set of items and level of detail for each, presented in the same order. |
| D06/DR03 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
The consistency issues apply to wording, headers, text, figures, figure titles, etc. |
| D06/DR04 | Not yet completed. Preliminary response: Not all components are described similarly (see E-mail from F. Farance on 2001-01-02 11:33). Scheduled for draft 9. |
Each component's description must begin with a straight forward declarative description of what the component is (and only what it is). E.g., the xxx store is a data store element which contains ..., the yyy process is an active processing component for ... |
| D06/DR05 | Not yet completed. Preliminary response: Agree. Scheduled for Draft 9. |
The normative text should make sense if the figure is missing. |
| D06/DR06 | Not yet completed. Preliminary response: General agreement. Scheduled for Draft 9. |
Consistency: The description must include a description of the component as either a flow, process or store. The name must be expanded to include this consistently throughout the document: e.g., behavior flow. Each component's description must include a description of how the component operates or what function(s) it provides, i.e., what it does. Each component's description must include a description of how the component interacts with each the other elements it is connected to. There must be a separate description of the interaction for each connected element, for each flow/interaction direction. |
| D06/DR07 | Completed. Included in Draft 7. | Each component description must include the letter code used on the ICS. |
| D06/DR08 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
The document says component names are prefixed with LTSA. This is generally not true. The component descriptions must be modified to include this prefix throughout. |
| D06/DR09 | Not yet completed. Preliminary response: Appears to be inconsistent with other suggestions for retaining only normative wording and removing examples. Scheduled for Draft 9. |
Each component description must include multiple examples. |
| D06/DR10 | Not yet completed. Not yet investigated. Will work with Glossary WG. Scheduled for Draft 9. |
Each component description must be described independently, e.g., without circular definitions. |
| D06/DR11 | Completed. No action required by this item: it is just a preface to the other comments. |
Specific comments: --The following *outlines* the problems with each of the current component descriptions. "What it does" applies explicitly to the text. These issues present the broad nature of the problems with the description of each component, not all problems are detailed. |
| D06/DR12 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Learner entity: -- what it is -- OK -- what it does -- OK -- connectivity -- not clear -- examples -- not explicit -- Implementation description should be separate from what it does. |
| D06/DR13 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Learning preferences: -- what it is -- no description -- what it does -- no description -- connectivity -- not formally described -- examples -- none -- All of the description is a discussion of a negotiation process. -- This negotiation process is not part of the LTSA -- Use of external entities is confusing |
| D06/DR14 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Behavior: -- what it is -- weak description: "conveys the learner entity's component to the evaluation component" -- what it does -- why is coding relevant for the abstract architecture, why is this simply not just a flow (or should coding and encoding be part of every other flow component), why is evaluation process included in the data flow. -- connectivity -- OK -- examples -- couples encoding or evaluation rather than being standalone |
| D06/DR15 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Evaluation: -- what it is -- describe only in terms of what it does -- what it does -- OK -- connectivity -- OK -- examples -- describes use of context, not evaluation processing example |
| D06/DR16 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Performance information stored/retrieved" -- what it is -- no description -- what it does -- no description, text describes evaluation process -- connectivity -- described as one way -- examples -- none |
| D06/DR17 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Learner records: -- what it is -- OK -- what it does -- weak -- connectivity -- not all described -- examples -- intermixed with the description of what it is and what it does |
| D06/DR18 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Performance/preference info received by coach -- what it is -- no description -- what it does -- OK -- connectivity -- request path is not obvious -- examples -- none |
| D06/DR19 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Performance/preference info stored by coach -- what it is -- described only in terms of coach process -- what it does -- OK -- connectivity -- -- examples -- intermixed with rest of description |
| D06/DR20 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Assessment info -- what it is -- not described in text -- what it does -- described in terms of coach process why does coach do an "optimal" process -- connectivity -- -- examples -- none |
| D06/DR21 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Coach -- what it is -- is described as what it does, not what it is -- what it does -- description is scattered -- connectivity -- mixed in description of what it does -- examples -- none |
| D06/DR22 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Query -- what it is -- no description of what it is, described as what coach does -- what it does -- weak -- connectivity -- not explicit -- examples -- none |
| D06/DR23 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Learning resources -- what it is -- no description -- what it does -- OK -- connectivity -- not all flows described -- examples -- only one flow |
| D06/DR24 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Catalog information -- what it is -- described via process -- what it does -- not described -- connectivity -- not described -- examples -- none |
| D06/DR25 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Locator received by delivery -- what it is -- OK (figure title uses awkward example) -- what it does -- none -- connectivity -- none -- examples -- only one |
| D06/DR26 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Locator sent by delivery -- what it is -- no description -- what it does -- weak -- connectivity -- none -- examples -- only one |
| D06/DR27 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Learning content -- what it is -- intermixed with what it does unclear how the resource store process it as in: "retrieved by the learning resource" -- what it does -- intermixed with what it is -- connectivity -- none -- examples -- none |
| D06/DR28 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Delivery -- what it is -- what it does -- what it does -- OK -- connectivity -- not fully described -- examples -- weak |
| D06/DR29 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Interaction content -- what it is -- OK -- what it does -- OK -- connectivity -- OK -- examples -- none |
| D06/DR30 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Multimedia -- what it is -- sending is confusing, isn't it just presenting -- what it does -- weak -- connectivity -- OK -- examples -- none |
| D06/DR31 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
Performance and preference information is overloaded in both the learner records store and the two control flows between the coach process and the learner records store, i.e., a flow conveying two different kinds of information and relying on a single component to store different information. The result is confusing. Acceptable resolutions 1) Split into two sets of flows and two stores 2) Develop a single generic term to encompass both use preference and performance information as examples of this more abstract data flow and store. |
| D06/DR32 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
The description of locators versus catalog information is confusing. The coach process issues a query control flow to the learning resources process which returns a catalog information flow. The coach process then passes a locator dataflow to the delivery process, implying that the coach process creates the locator. While this may be true, the description is confusing. Also, it is unclear if what should be passed to the delivery process is the locator for the catalog info or the locator for the learning content. Acceptable resolutions: 1) Clarify, be explicit in detail |
| D06/DR33 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
The use of direction in the "Locator received by delivery" and "Locator sent by delivery" seems to imply a particular processing and ordering in the flow, rather than an abstract model (e.g., why not locator sent by coach). If the data flow is the same information, use the same term. A data flow is a component, used in a particular context. The component name should not include the content and processing or flow/processing direction Acceptable resolutions: 1) Use a term for the component which does not imply more than the data flow. 2) Modify all data flows to include all directional information and all contexts. |
| D06/DR34 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
"Performance information stored/retrieved by evaluation component". As above, the component should be title with a name which does not imply context. Acceptable resolutions: 1) Use a term for the component which does not imply more than the data flow. 2) Modify all data flows to include all directional information and all contexts. |
| D06/DR35 | Not yet completed. Not yet investigated. Scheduled for Draft 9. |
"Query" component is too generic a term. Many other dataflows in the architecture could be labeled query. Acceptable resolutions: 1) Use different, more specific term |
| D06/DR36 | Completed. Changed "submitter" to "claimant" in Draft 7. |
Submitter's name, submission date -- these fields imply that the ICS is being submitted to someone, i.e., some sort of registration or database. -- what is being submitted? -- to whom is it being submitted? -- if it is being submitted to LTSC, then what processes does the LTSC or the WG need to put into place to manage this? Acceptable resolutions: 1) drop these fields 2) reword to drop "submit" from entries, e.g., created by, created on. In addition, the introduction to the ICS in the appendix requires appropriate wording changes to describe the use and delivery/submission or creation of an ICS Alternative resolution: 1) detail the complete submission process for further comment and review by the WG |
| D06/DR37 | Completed. Added text to Draft 7 after Pro Forma ICS table. |
Digital signature/checksum -- what is this, i.e., what is being signed, e.g., the form or the implementation? -- what is the checksum algorithm? -- what is it computed from, e.g., an MD5 digest of the form? -- what is the purpose of the signature? -- if this is two fields, it should be detailed as such Acceptable resolutions: 1) drop signature/checksum field Alternative resolution: 1) detail the signature/checksum field for further comment and review by the WG |
| D06/DR38 | Completed. Added text to Draft 7 after Pro Forma ICS table. |
URL for Related resources -- what are the expected related resources? -- what is the purpose of this field? -- is there guidance for what should be provided? -- URL vs URI vs URN? -- one or many URL(s)? -- is this required? -- what if the related resources are not in electronic form? Acceptable resolutions: 1) drop URL field Alternative resolution: 1) detail the URL field for further comment and review by the WG |
| D06/DR39 | Completed. Added text to Draft 7 after Pro Forma ICS table. |
System and Subsystem Description of Implementation (Please attach documents) -- what is this? -- is this required? -- what documents are required? -- what is done with the documents -- who do they go to (i.e., are they submitted)? Attachment only makes sense if the form is being submitted to someone -- what if implementation descriptions are proprietary? Acceptable resolutions: 1) drop description/documentation field Alternative resolution: 1) detail the document field and the use of it and the related documents for further comment and review by the WG |
| D06/DR40 | Completed. Added to Draft 7 in Pro Forma ICS table. |
The Conformance section lists letter codes. -- why are these not listed in the ICS? Acceptable resolutions: 1) add letter fields Alternative resolution: 1) present justification for non inclusion for further comment and review by the WG |
| D06/DR41 | No change. Already discussed in WG. See E-mail from F. Farance on 2001-01-02 11:32. |
Should reduce content in LTSA to only normative portions. Options: 1) Reduce the formal normative standard to only the essential content and move the other material to separate documents. As appropriate, the WG can decide if these other documents are formal work of the WG (not as standards, but as the appropriate non standard documents produced by a WG) or can be informal, or returned to the market place for their development, maintenance and dissemination. 2) Resolve that the WG expend the effort to complete the standard in its current form. |
The following are comments received at the 2001-03 1484.1 WG meeting on Draft 7.
| Comment # | Disposition Status | Comment Details/Change Description |
| D07/WG01 | Completed. Added to Draft 8. |
Remove wording on bus diagrams because they aren't used. |
| D07/WG02 | Completed. Done in Draft 8. |
Move Methodology Annex to second to last Annex. Add note that Annex will be removed upon publication. |
| D06/WG03 | Pending. Need example from ADL and/or Claude. |
LTSA doesn't address certain systems. |