Forum .LRN Q&A: Re: SCORM runtime environment and IMS Simple Sequencing
Yes I was thinking outside integration through service contracts. The assessment package will have to be able to communicate a student's test result to the sequenced curriculum package. So I view the sequencing package as the client in this case. As Stan and the rest of us figured, it doesn't seem right to have Assessment using SS for its internal sequencing of its questions. SS is not a general sequencing service.
Ernie,
Regarding what I said over a year ago, you should have commented there and then if you didn't agree 😊 Anyway, it is still true that there is no need for a public API until someone develops a second "curriculum front-end" to SS in addition to the one that the SS package itself will have. If, however, you or anyone else decide to go ahead and build a client-side UI according to the SCORM standard the SS API will of course be made public, either by opening the SS Tcl API or by implementing service contracts.
As for LORS being a library for IMS specifications ... I'm sure the two specs that are in there are needed to make LORS the learning object repository that it is. This doesn't mean, of course, that it's motivated to put all present and future implementations of various IMS specs in there. In the case of the SS spec we actually have in mind building a separate package (which may or may not end up being split into several packages) with its own UI for designing sequences and also a navigation UI (toolbar) which will persist throughout your sequenced journey. Because SS will be made up of these integral parts and will not be a strict service it is not well suited to be contained in another package.
It appears to me you want to turn LORS into a "super package" covering all IMS and SCORM related features. 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. As far as possible we want to modularize the toolkit functionality and instead assemble vertical applications like .LRN when there is such a need.
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
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:
https://openacs.org/forums/message-view?message_id=100182
In the case of the SS spec we actually have in mind building a
separate package (which may or may not end up being split into
several packages) with its own UI for designing sequences and also a
navigation UI (toolbar) which will persist throughout your sequenced
journey.
What will you be sequencing? And why wouldn't this things that you will be sequencing and controling for, be acs_objects or content?
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. For instance, I
wanted to export about 8000 pictures I have in a photo-album instance on
a OpenACS 4.6 server I have. Using the IMS CP library, I managed to
export all the content and put it in a content package, than then I can
import into LORS, or even better, I could write an interface for
photo-album so it can process IMS CP packages directly.
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.
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.
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.
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.
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
