Gafford & Blackmon - PerformanceSCORM

This paper clearly states the requirements of Life Cycle Support of content (data) in relation to almost any product where some form of technical documentation and/or training is required.  The requirements stated for SCORM 2.0 arise from real business requirements.  [I hope the stakeholders that are party to this process will correct any errors/misconceptions I introduce in these comments.]

Having thought carefully about the SCORM 2.0 requirements suggested by this paper there are some important follow up questions for the authors and the community deciding final requirements set.

The suggestions are practical and will contribute to a solution for the communities of practice in which these problems exist, however, the paper assumes that SCORM should accept the responsibility for all of the requirements.  The LETSI community needs to spend some time answering the primary question, "what is in scope for SCORM and what is not?"  Some of the requirements stated in this paper (and a range of others) are implementation issues and are not specifically SCORM issues.

The paper states three top-level requirements for SCORM 2.0

1.    Support for modern content management practices.  This is an area that would require clarification as to why the issues stated are actually SCORM issues.  For example, the connection between content authoring tools and repositories of learning content is not a SCORM issue but a normal application integration issue that is not related to a learning technology standard/profile.  Perhaps the most important question to ask is, "what is SCORM currently doing that negatively impacts this requirement and can it avoid doing so in SCORM 2.0?  (Cross domain scripting springs readily to mind).  While the functions related to configuration management are actually application function/service functionality and again not specifically SCORM functions, the same question should be asked, "what is SCORM currently doin that negatively impacts these requirements?"

2.  Allow a community of practice to develop and reference its own aggregation model.  This is a deep issue and an important one for SCORM going forward.  The paper suggests that SCORM 2.0 provide support for both S1000D and DITA structured content formats, however, it is not clear if the principle is to be able to add more over time.  The issue would appear to unfold as follows:
     a)  A single aggregation and metadata approach would be better for interoperability but it may not meet the needs of all communities; especially where metadata is concerned.  Metadata as currently specified is not able to meet the requirements of any community.
     b)  Both content formats suggested have their own models for content structure and aggregation in the form of an XML application. Given the separation of authoring/editing from aggregation and then rendering to a specified format the real issue would appear to be whether SCORM supports more than one content format natively or not since the XML content could probably be processed/transformed into almost any other format.  Supporting more than one content format natively within a delivery application may be a challenge in terms of complexity, cost and performance, however, there needs to be more work done to determine the impact on vendors and other stakeholders.
     c)   A final observation on this would be the interrelationship of CoP and reusability.  The users of the S1000D standard are a very specialized community that is significant in terms of size and geographical reach.  It is not likely that the content produced in this format would be consumed anywhere else except within this community.  On that basis, a profile or adaptation of SCORM for a particular community would seem very reasonable.  For other communities where reuse of content is less predictable and where sharing across community boundaries is likely, having multiple content formats would most likely be a negative impact on the 'ilities'.  What an S1000D-community-specific profile actually means in terms of implementation will need further discussion due the different ways in which it might be achieved and the fact that we don't yet know what SCORM 2.0 actually looks like.

Will SCORM 2.0 specify a single method for aggregation and sequencing?  If community-specific profiles were allowed, how might this be achieved and supported in terms of conformance testing?

3.  Integrate SCORM 2004-based content development editors with repositories (S1000D CSDB and/or DITA enabled).  While useful, as mentioned in the first item this does not appear to be a SCORM issue but rather an application integration issue.

4.  The paper dedicates a number of sections to the requirements for supporting issues related to the content life cycle within the product development community.  Most of the issues appear to be business process issues rather than SCORM issues.  [Please correct me if I am incorrect on this point]  There is no question that metadata is central to assisting the business processes, however, aside from ensuring that SCORM supports metadata requirements more effectively that it does now, there would not appear to be a direct implication for SCORM.  (Maybe the lack of metadata support is the real point being made...).  The other points raised appear to be implementation issues/choices and it seems that there are existing applications that are able to satisfy the requirements.  Nonetheless, if an S1000D profile were available it may resolve such issues.

Would a community-specific profile lead to a longer term separation of that community from the larger SCORM community?  If so, what are the likely outcomes?  Should these considerations impact short term objectives in a way that is constructive to the various stakeholders?

I had a conversation with Wayne at Implementation Fest that brought up an interesting question that cuts to the heart of the design of SCORM 2.0. He proposes in his paper that SCORM 2.0 allow CoP to replace parts of the SCORM spec with specs of their own choosing. In his example, he wants to replace the content aggregation specification with something similar from the S1000D community. I tried to talk him out of it and may or may not have won the argument, but the question it raised is this: "Should SCORM 2.0 seek to loosely couple its individual parts so that they can be swapped out?". In general, I think that a tight coupling of the parts or "books" of SCORM makes for a better specification with more interoperability. But, if we are looking at the Core SCORM model that encourages CoP to profile SCORM, I think we need to look at what those communities will need and how that relates to the architectural design of SCORM 2.0. If CoP will benefit from a loose coupling, that will have an impact on the architecture of SCORM 2.0.

There is and never will be a universal fit for all, but I agree with Mike's point of there being danger in decoupling the parts of SCORM that do currently work. Perhaps that's what the driver should be for determining Core SCORM? What works should be part of Core SCORM....what doesn't work, should be looked at later. Baby vs. the Bathwater....

What is missing from SCORM is yet another area. I believe data readiness and life cycle logistics / configuration management fall into this area.

Based on the feedback we've seen to this call for papers is that many people have realized SCORM's potential, but not all of the -illities have been achievable and not all of them are necessarily applicable. I believe that too many community-specific profiles will definitely lead to a longer term separation of that community from the larger SCORM community. Let's address the simple things that we know work and that will apply to all communities of practice first. One of the reasons why SCORM has been so controversial is because it included too many things that were not applicable to all. I like the concept of Core SCORM, but perhaps there should be solid foundation and regulatory control over the communities of practices that are established beyond the Core?