The OSP group was discussion options for workflow and Mark Breuker opened up the topic of using IMS Learning Design to solve workflow problems. While I have not discussed this much except with a few pals – using IMS LD as workflow a pet idea of mine.
So I wrote up this response.

I have felt for a very long time that we should use IMS LD as the workflow core of Sakai. With a couple of comments and caveats:
– IMS LD is more than just workflow – it contains some workflow and a simple language to express trigger conditions and a name space for triggers, etc. – this is the part of IMS LD that I would take and implement.
– I wish CopperCore could be pulled in – I bet we could get a non-GPL version if we asked nicely. I don’t think that we need all of what CopperCore is – we need some bits and pieces that implement the general workflow bits. The good news is that we could look at CC and redo the bits if the license could not be worked out.
– I think that we need to keep the IMS LD workflow bits separate from the IMS LD loader and player – this is where people kind of get religious and want to argue about IMS LD’s “pedagogy” – this is a fun argument which is endless – particularly because it is not technical. I think that it is a flaw in the IMS LD spec that these things are mixed together in the same spec – it has limited the uptake of LD because many people look at the pedagogy first and have a negative or non-positive reaction – then they look no further and miss the real nuggets of value in the spec.
– I am guessing that if we were to start to try to use the workflow bits of IMS LD – we should expect to find places where improvement is needed – this is cool – we should expect to extend where needed and then feed back those improvements into the IMS LD spec.
The overall issue here is that it is not as simple as the sentence “Use IMS LD for workflow.” This will take quite a bit of thinking, iteration, and resources to make it happen in my opinion. The problem is that no one will pay for this as best I can tell because there is so much up front investment before there is real payoff – it is simpler to whip up some ad hock workflow and solve the itch of the moment in something like portfolio, resources, melete, assignments, or mneme. Because then with a pretty fixed bit of work – the immediate needs are met and the cost-benefit to the stakeholders is reasonable – but we keep pushing back the time that a general purpose workflow solution is deeply integrated into Sakai.
Taking on a general workflow in Sakai requires a long-term commitment that does not have the immediate payoff that most of the resources working on Sakai are not willing to invest at this time.
Many others have many opinions on Workflow in Sakai. This is only *my* personal opinion.