From: Dagmar W. <dag...@un...> - 2010-06-12 16:51:48
|
Hej Frank and all. Frank Bergmann wrote: > Thanks for following up on this ... here some comments: > >> - turned the *algorithm* attribute into an element, as was discussed in >> Seattle, nested in a *listOfAlgorithms*. So now, one would write something >> like that: >> >> <uniformTimeCourse [..]> >> <listOfAlgorithms> >> <algorithm kisaoID="KiSAO:000000064" /> </listOfAlgorithms> >> </uniformTimeCourse> >> >> to define timecourse simulation that uses a particular algorithm. You can >> add 0 to many algorithms. >> >> > > Ok .. this is a bigger change than I wanted it to be! I was fine with > agreeing to have algorithm be an element, so that we could have it annotated > later on with all the properties that we would want to set on it. But a list > of algorithms really? Why do we need that? Would these be mutually > exclusive? Or what should we do if we list: > > Forward Euler, > Runge Kutta, > CVODE, > Gillespie > > This no longer allows me to distinguish whether I should carry out a > discrete or continuous simulation. (Or this is actually a specification of a > certain hybrid algorithm. But even then, that algorithm should have its own > description! And again only one algorithm would need to be referenced ) > Convinced. I changed it back to having only one algorithm per simulation, so <uniformTimeCourse [..]> <algorithm kisaoID="KiSAO:000000064" /> </uniformTimeCourse> (revision 150 if someone wants to check) > I'm still missing the most important one ... the fix to the ChangeXML ... > implementing adding of elements by having to replace an existing model > element with itself and another one is just plain wrong! It would be great > to have it separated out into: > > AddXML > ChangeXML > RemoveXML > > Or at least have an operation flag on the ChangeXML element! > I was not sure if there was an agreement here for having an "operation" attribute defining the type of change as one of add, delete, replace? Dagmar |