Several others will be seeking to ensure specialisations are possible for other programs, but these 2 will focus the core grounp work over the next few weeks. We should not rush out the next version until input from 3 can be rolled into our thinking. SPAR 0.2 was meant to be just an increment of the outstanding issues list added to the current documen t after we had quick feedback. However another version so soon after the meeting that does not alter in terms of the core model could be misinterpreted. The main RFC stage between 0.2 and 0.3 is then 2 months each rather than the originally planned 3 months, but that is not too bad.
Uncertainty needs to be built in more widely than in numeric values.
But it may be possible to make progress on sharing SOME information by employing a basic mechanism of allowing specs. I suggested a new design guideline to addres sthis in a previous message. Quite crucially, I understand that Tom Garvey confirmed during the Wednesday morning breakout session that he agreed that SPAR should just be an interlingua and not attempt to be the basis for implementation structures. This is contrary to the way I understaood his guidance befopre, and conflicts with some of the issues we were asked to address such as efficiency and so on.