I'm a little late to this discussion due to a day's downtime at my ISP end ...
I think Matthias has got the general picture right, as Ernie has already acknowledged. IMS Simple Sequencing is as powerful as SCORM when it comes to the functionality. In fact, SCORM essentially just adds a strictly specified front-end to IMS Simple Sequencing, which mandates a javascript client called "runtime environment". IMS Simple Sequencing explicitly does not specify the exact delivery UI (nor the platform used to implement the base sequencing functionality). For example, it doesn't specify whether a learning activity (learning object or assessment, for instance) should be presented as a link in a curriculum toolbar or be redirected to automatically. The good thing about this philosophy of theirs is that IMS Simple Sequencing becomes suitable for implementing in OpenACS (with its preference for server side scripting) and we don't have to customize our content to fit SCORM's javascript adapter.
However, Matthias, the following statement contains two misconceptions, IMHO:
" ... and I think as soon as LORS specifies and tracks a few values, like one for "every selection within the hierarchical webcontent tree is always allowed" and "value for success on return from activity, defaulted to success if content was visited" (I didn't yet look into the specs to identify the proper variable names but I'm sure they exist) then we had what IMS expects."
1) It is NOT enough to "specify and track a few values" to meet the expectations of IMS - there is a simple sequencing specification which must be followed to the letter if we are to comply with this global standard (which we should).
2) There is no reason to build this spec into the LORS package, since simple sequencing isn't necessarily dependent on learning objects being stored in this or that package - the simple sequencing package has to be integrated with Assessment, too, for example.
