Since I complained recently about the IMS needing to open up more, it’s only fair that I should give credit when they actually do it. Chuck Severence, who now works part-time for the IMS, has a public test site up for people who want to test against a subset of the forthcoming Learning Tool Interoperability specification. Now, the full specification drafts are still non-public (to the extent that they even exist–LTI is still under active development) but, to be honest, hardly anybody reads the full spec anyway. What Chuck has done is much more useful because he’s providing sufficient documentation and tools for people to actually start building and testing LTI-compliant tools without a lot of extraneous gobbledygook. All it needs now is a feedback forum, and the IMS will suddenly have a very open and results-oriented (though perhaps not yet comprehensive) process for non-IMS members to provide feedback on specs in development.
Brilliant work. Really, a very big step forward.
On a side note, Chuck mentions the use of REST in the documentation. Thus far, the IMS has been pretty SOAP-heavy in its approach to web services. If the LTI group is indeed making judicious use of REST (which would make particular sense given the nature of what they’re trying to do) then that also is a Very Good Thing.
Michael – just to clarify – my new site is not technically a subset of the IMS LTI specification. The scope of Simple LTI is a subset of the *scope* of the LTI spec – and Simple LTI takes a very similar technical approach to IMS LTI 2.0. Because of the timing of my Google Summer of Code projects and the timing of the IMS LTI 2.0 spec – I needed to do *something* so those students could move forward. Simple LTI is just one vendor’s approach to this (i.e. me and all the pals I can round up). As a Sakai developer I want something that could be in use in limited production in Sakai (and wherever else) this Fall – hence I need to do something now. The beauty of this approach is that by staying close to IME LTI, I can help get the industry aligned in anticipation of the release of LTI – we can learn about real engineering issues in real-life situations based on real implementations – and use that to inform the IMS LTI process.
Just to be clear, Rob Abel has approved and encouraged what I am doing with Simple LTI – I sent him drafts of everything I did – I have not broken any IMS rules – the real draft is right where it should be particularly at its current maturity level. Since I work part-time for IMS – I need to stay pretty squeaky clean on the IMS rules.
I have been meaning to respond to your original post about open/closed – I gently disagree with you. There are times where it is good to have a small group, with each member having deep skin in the game discussing things without a public eye watching everything. The problem when very early thinking is happening – you need to try things and throw them away or change direction. I have now seen IMS LTI 2.0 change direction three times – each time for good reasons. If we had done it all in public all along – people would get upset each time we switched because then they have to rewrite things at some code and time. What we are seeing in the IMS LTI 2.0 working group right now is amazing progress – If the whole process was publicly wide open – I am convinced that the process would be much slower.
However the more things get settled – the more people that need to see the draft work – and IMS is set up to broaden the view of a document as it matured. You can argue that it should be faster or slower, or this or that spec waited too long to go public – but I am strongly convinced that the approach to start small and private and expand the eyeball count as the work matures is essential for nearly every engineering process which hopes to be successful.
I have done standards work in IEEE, IMS, JCP (Java COmmunity Process) and IETF (a little bit). Each of these processes to one degree or another follow the start with a few people and then grow the exposure of the document. Even though participation in JCP is free – being part of an expert-group and having access to the early work is very limited and “invitation only” – period. As part of the JSR-286 Expert Group (which got Steffan Hepper of IBM an award as Spec lead of the year in JCP) – private and a small deeply involved expert group was *essential* for over a year.
So for me, I separate the notion of pay-for-play from optimizing the engineering process. Each should be depated on its own merits – I think that you make a bit of a maistake connecting them.
Oh yeah – the IETF is the most open of the bunch – but heck – who wants to read and comments on the next rev of the Exterior Gateway Protocol (EGP) anyways? IETF could be wide open from the very beginning because of the massive barrier to even understanding what was being discussed. The deeper inside the cloud a technology is, the less it needs a quite time in which to incubate.
All in all – thanks for the plug. SimpleLTI should be fun – It is also an experiment for me about how to get standards implementations dispersed as quickly as possible. Perhaps I can use the experience I gain in SimpleLTI to have a nice suite of software ready to go when IMS LTI comes into the public eye – and we can get it implemented in real products at light speed.
Thanks for the clarifications, Chuck. To clarify my own position, I have not called for the IMS to open up absolutely every thread and comment related to specs-in-development. I’m agnostic on that point, and I understand your argument that sometimes you just need a little time to sort things out before going fully public. What I *am* calling for is a clear policy giving each working group individual discretion to open up their work where they think it to be useful and to engage in. I’m also calling for a larger dialogue within IMS about how far we can usefully go in the direction of making openness the default.
cool! too bad i have no use for this!
Michael – Thanks for the clarification. Your comments are something that I think are a path to improvement. The JCP process has taken just this step – the formal process is unchanged – but the rules of engagement for individuals in expert groups changed in the past five years.
As part of a JCP expert group, you still cannot share the draft – nor can you share the comments or discussion. But you *can* make statements that start like this “I am a member of the expert group and while this is only my personal opinion – I think that we are leaning more towards the X approach than the Y approach.”. Several years ago when a friend of mine was working on JSR-170 (Java Content Repository) I tried to buy him enough drinks to get him to spill some detail on the overall approach to metadata. He would not tell me *anything*. In another example, the JSR-168 spec was in the throes of finishing right when Sakai was starting and there was absolutely *no* information available – but I heard it might be like Jetspeed’s APIs (as compared to being like the Servlet APIs). I baked JSR-168 into the Sakai grant proposal *without knowing* which way things would go but hoping that the Jetspeed folks would win. A few months later JSR-168 finally came out and it was servlet-like instead of Jetspeed-like. Also JSR-168 was really much smaller scope wise than I hoped. I went through some unhappy times w.r.t. JSR-168 as a result and we did *not* use it as part of the backbone of Sakai because of that. Later I learned all of the fighting that happened and how things just got chopped down in 168 to the minimum that would let the spec progress – and it all made sense. And after I understood the back story – I have come back to really like JSR-168 because I realized that it did a few things well and I just had to extend it in non-portable ways.
So I don’t exactly know where this story goes – probably the best summary is that I see your point 🙂 Wide-openness of the 168 process would not have made things better – If I were allowed back in 2003 to be a peanut gallery on the expert group – I would just have contributed to the general shouting which was going on without helping much. That suggests JSR-168 being closely held made it possible to get the spec out – but at the same time – because nothing even leaked about the ongoing debate – my planning was messed up badly. A little leakage/permeability would have helped me a lot. Hmmm. SimpleLTI is kind of like that 🙂
P.S. Now I love JSR-168 and do most of my Sakai development in JSR-168 – mostly to test the Sakai support for JSR-168 on a daily basis. And my Simple LTI tool in Sakai is in JSR-168! Nerdy irony at its best.