SCORM - the issue of shareable content

Perhaps we should develop the SFORM specification (Shareable Food Object
Reusability Model). A SFO is the smallest trackable (something you
order from a waiter) unit that you can re-use. OK, so now you serve the
end-user some pepper. Follow it up as the next course with some salt.
The next SFO will be the fish. And so on. This is a highly re-usable
and since you can put it on paper, metal, or porcelain plates, it is
highly interoperable.

If we think of side-dishes, perhaps a SFO makes more sense. But
remember, that under the SFORM specification, the LMS is responsible for
navigation from one SFO to the next. One SFO cannot access another SFO
while it is still open. So the pairing of a good wine with a complex
dish becomes contrary to the specification.

If instead we restrict the "re-usability" part of the SFORM to assets,
it makes a heck of a lot more sense. Serve water with every course of
the meal. A salt shaker (glossary) is provided with each course.
Interoperability means you can serve this meal on a boat, an airplane,
at home, or in a restaurant.

In terms of a "repository", it can be as simple as a folder on a hard
drive containing graphics - if you have a tool to preview each, they
become easily reusable. The course designer has to be intimately
familiar with any object they plan to re-use, or they will produce
unusable content. This whole process needs to be about the learner, NOT
the developer; however, the SCORM specification readers tend to be
developers focusing on their own short-term needs. If the development
tools that these people have are difficult to use (e.g. using Notepad to
create HTML pages), then SCORM takes on the common meaning: I need to do
everything to avoid having to create new content - so I will create very
generic material that I can reinsert into every course. For example:

----------------------------------------------------------
Emergency Exit Manual
---------------------
Welcome to this vehicle. In case of a fire, accident, flood, snowstorm,
heat wave, or other emergency, please place your head between your
knees, or crawl to the nearest exit, or wait for a rescuer, or update
your last will and testament. Our
pilot/captain/conductor/autopilot/director/engineer has been
specifically trained on how to use this
boat/plane/car/bicycle/submarine. Thank you for
flying/riding/driving/jumping/shopping with us.

Test: Have you have been properly prepared? a. yes b. no c. all of the
above.
----------------------------------------------------------

If on the other hand, the developer has a tool that makes it easy to
create and repackage content (e.g. an authoring tool like ReadyGo -
equivalent to PPT for presentation), SCORM takes on much more of a
meaning about interoperability. Reusability is done upstream, during
content assembly/packaging. It takes less than a minute for the
software to repackage an entire course and create the necessary manifest
files. Now the barrier to reusing portions of one course in another
course are much lower, and it becomes easier and more cost-effective to
create coherent, instructionally sound courses driven by learner needs
rather than by developer limitations.

Why isn't "interoperability" part of the name "SCORM"?