For the bit I've been reading, Tin Can is not really the next SCORM but instead is taking the bits that most people are using about it (reporting mainly) and getting rid of all the painful content development that goes with it.
Tin Can is very light in comparison and is mean to be a lot more flexible than the rigidities of SCORM.
I guess you can think of Tin Can, on the server side, as a service that listens to clients that post events to it (ie: "Don completed the lesson"). These events are collected in the Learning Recording Store (LRS) and then can be used by other application to determine scores, grades, competencies, etc.
Tin Can completely (and purposely) ignores where these events happen, which pushes the LRS to work more like a online service than a "LMS piece" and that's why all thes mobile app people are so happy about this.
Additionally, Tin Can doesn't enforce a particular ontology like SCORM does. Nor it forces content developers to follow a strict API or content packaging.
So I guess summarizing, Tin Can just gets the bits that most people were using about SCORM (record scores and reporting) and gets rid of all the other difficult bits giving full flexibility to the content designer to do them as he/she finds fit.
I get the sense that the absence of support could be a big disadvantage for .LRN.
Well, this would depend on the content you will be deploying.
You could deploy content into .LRN and -for my understanding, the LRS could be in some other server (cloud?). Therefore there wouldn't be a real need to add an LRS into .LRN though.
Ernie
