Re: [SED-ML-discuss] Tracker for minor issues in L1V2 draft? listOfTasks needs to contain AbstractTask not Task

[Frank T. B. <fbe...@ca...>]

> There doesn't seem to be an issue tracker for the L1V2 draft document, 
> aside from the proposals tracker; I'm not sure if the proposals tracker 
> is the right place for issues that don't change the intent of the 
> specification but instead ask for details to be corrected, so I'm 
> sending this here. I suggest that a L1V2 Draft tracker be created.
> 

we can do that. thanks! But please feel also free to let us know about all issue here (or at the editors list), and we will address them as fast as possible.  

> I'm working on implementing the Nested Tasks proposal in the SED-ML 
> Processing Service (for those who haven't come across it before, that is 
> the C++ implementation of SED-ML that currently ships with the CellML 
> API), and am taking a close look for any issues with the specification 
> as I do this.
> 

Great, thank you!

> I've found one issue with the L1V2 draft on the website already: 
> previously, in L1V1, there was just Task, and listOfTasks was a list of 
> Task. The specification introduces a new class of task, RepeatedTask, 
> and a new abstract base class, AbstractTask, which RepeatedTask 
> specialises. Presumably, the intention is that listOfTasks now becomes a 
> list of AbstractTasks rather than Tasks. However, the specification 
> still says it is a list of Tasks (page 69, line 241; UML diagram, page 
> 35, section 2.3.8.7).
> 

Sorry, as I tried to indicate in the last mail. The UML diagrams in the draft have not yet been updated. 

> The other issue that I can see is that subTasks need to reference a task 
> defined in listOfTasks, which means that people will put things under 
> listOfTasks that don't make sense as a task on their own, solely so they 
> can refer to them from a subTask.

I actually think these tasks could also make sense standing by themselves. But I'd be happy to discuss things. 

> Some software (e.g. non-graphical 
> software) is just going to want to run all the tasks, and so it is 
> unhelpful if there are tasks that are not useful simulation experiments 
> in their own right that are not distinguished from the useful simulation 
> experiments.

What I do, is to analyze what output is requested, and only run those tasks that are needed to produce output. But of course that is a tool decision. 

Frank