Forum .LRN Q&A: Re: SCORM runtime environment and IMS Simple Sequencing

> Regarding what I said over a year ago, you should have commented 
> there and then if you didn't agree 😊

And I did:

https://openacs.org/forums/message-view?message_id=100674

That can hardly have been a comment on what I wrote since your message is dated 6 days earlier. In fact, my posting was an answer to your *question* in your posting (although in a new thread). And you never reacted on that answer.

Even I suggest you a way to implement an open API. In addition, 
I pointed out to you how the fellows from Carnegie Mellon have gone about implementing their own engine:

Yes you did, and I also explained to you why I didn't think it was *needed* to implement an open API. Carnegie Mellon has implemented SS, so what? We already have all the details needed in order to build an implementation from a canonical source, namely the original IMS SS spec.

What will you be sequencing? And why wouldn't this things that you will be sequencing and controling for, 
be acs_objects or content?

The general idea is that we will be sequencing "learning activities" which would indeed be either plain acs_objects or content_items and which would be mapped to one of several things: a learning object in the LORSm, a test in Assessment, or an "auxillary resource" (basically any URL), for example. (It is given by the IMS SS spec that you are sequencing "learning activities" which need to have a bunch of specific attributes that defines the sequencing rules. So you are not sequencing the content per se.)

If implemented like that, then you can abstract it to a point that anyone can
use it.

For instance, take the IMS MD specification in LORS. Any acs_object can
have LOM metadata. Is it needed? For sure not for all objects, but it is
open for people to use it.

The IMS CP implementation can be used by other packages. 

[...]

So basically any package can make use of the IMS specs. AND, LORS is a
set of libraries, that LORSm uses to implement a repository of learning
objects using the IMS specs given by LORS.

However, for some reason, I can't really understand why you think
otherwise about IMS SS.

As I've said before ... I recognize that it makes sense to gather the implementations of *those two* IMS specs in LORS but that the same is *not* the case with IMS SS, and here's why: SS is designed to handle learning sequences. Its rules and conditions are very specific to this purpose (not suitable for use in Assessment, for instance). We intend to build a navigation and user tracking UI (based on the principles of the Curriculum toolbar) which will display universally accross package borders. And, more importantly, We intend to build a central (within the SS package) front-end for designing learning sequences (that is, "curriculums", not courses) where we map content in different packages to learning activities in a sequence, defined as a branched hierarchical tree-structure with sequencing rules. This SS front-end would be canonical because there would be no need for other packages to have their own SS front-ends, specific only to their type of content. The central SS front-end would be able to handle the mapping of all content throughout the toolkit to learning activities. Hence there would be no obvious need for a public SS API ...

> It appears to me you want to turn LORS into a "super package" 
> covering all IMS and SCORM related features.

First, I never said that. Whether they are in one of 10 packages I
really don't really care. What I want to see is e-learning
specifications implemented and any packages being able to use them. One
package, 10 packages, I don't care.

Great. As you can see you will be able to use SS through the provided UI (but not through an API - unless of course you really need that. Then it could be refactored and "opened up").

> I don't think this would be such a good idea. It would be better, I
> think, if LORS remains what it says it is: a learning object
> repository.

I think you are a bit confused:

  LORS = set of libraries that implement IMS CP and MD (no UI)
  LORSm = uses LORS to implement a repository of LOs.

This is what I would like to see:

  LORSm = LORS + IMS SS (from your package) to allow people to deliver
ordered and controlled sequences of learning objects.

OK then, *LORSm* should remain a learning object repository. As explained above, people will be able to deliver ordered and controlled sequences of learning objects but using a general SS front-end instead of a LORSm-tied one.

> As far as possible we want to modularize the toolkit functionality
> and instead assemble vertical applications like .LRN when there is
> such a need.

And that's the whole point! 

But I can't see how you want to achieve modularity if each package has to
implement the same methods and can't reuse them.

As said above, the very point is that each package *won't* have to implement the same methods (SS). As I said to Malte, no other package should need the SS methods for its internal operations. And if a user were to set up a learning sequence mapping only to LOs in LORSm (say) s/he would still use the central SS front-end to do this.

Again, if you don't think you can implement an IMS SS engine that people can
use... well, there's not much choice for us but to do it. 

Your arguments that it can't be done are just not good enough. The fellows from
Carnegie Mellon have outline all the specs for implementing it as an IMS SS
engine (that's the document I sent you over a year ago), so it can be
implemented

Your choice,

Ernie

This is really an amazing insult. I've never said we can't do things your way, I've only said I don't think it would be the right way to do it. We actually think we are able to write a SS package that people can use, but it is still not clear that code outside of SS needs to use it, that's all. You don't convince us with your arguments. You should focus on motivating why there is a need for a public SS API, why LORSm should be turned into a sequencing front-end, why there would be a need for multiple front-ends to SS, why a client-side front-end would be better, why we can't use the IMS SS spec itself as a blueprint for our implementation, etc., instead of trying to distort what we are actually saying.