Nickerson, David Phillip wrote:
> Hi all,
>
> Just wondering if there is some reason why math editing has been added as a 
> PCEnv milestone independent of model editing/creation? In particular, given 
> the stated benefit of math editing is the creation of models without editing 
> XML - how can that be achieved without a more complete editing solution?
>   
Because the milestones are supposed to be relative to the current trunk, 
and the model editing is already implemented in the trunk.
> It would be good to see a complete plan for model editing and how the current 
> math editing milestone fits into that plan. Even just in regard to editing 
> math, how will it work with editing equations from imported components?
It would change the in-memory representation of the imported model. The 
question then is, how do we save that representation (this is something 
that needs work, but it is a somewhat different feature).
>  what happens if you edit an equation in such a way that you break or 
> invalidate the variable interfaces/connections in a particular component?
The current editor requires you to explicitly set up the interfaces and 
connections, so you would need to fix the interfaces to match the 
equations. Validation is on the longer term roadmap, and would identify 
issues like this.

In the longer term, it would also be nice to have other ways of editing 
the model which were simpler to use.
>  or add a new variable to an equation deep inside an import hierarchy?
You would change the equation, and then have to add the variable 
everywhere where you wanted it, and set up the connections. The idea of 
the initial editor is that it closely parallels CellML, but makes it 
easier to create syntactically valid models (it doesn't automatically 
change one part of the model when you change others).

This sort of editing isn't for everyone, but there is no reason why we 
can't also provide other views of the same thing (e.g. some users might 
prefer an SVG based view, where you drag lines to make connections 
between components).
>  etc...
>
> Seems that so far the discussion on math editing has centred on re-inventing 
> a new syntax to enable a perceived "easy" method for doing so, but there has 
> been little discussion on the implications for providing an interface that 
> allows the fundamental data in a CellML model to be changed independent of 
> all the supporting information.
>   
A text editor already provides such an interface, we are simply making 
it less tedious to produce models (and providing some structural 
restrictions from CellML, e.g. you can only put variables inside 
components). It is certainly possible to create models which do not 
validate (or work in the integrator), simply because CellML has some 
complicated requirements for validity (such as interface directionality 
constraints), and it wouldn't make sense to force the user to atomically 
keep everything consistent. Allowing invalid transitional models, just 
as you might create an invalid C++ program as a transitional step while 
you are modifying a program, doesn't seem like a big problem. Once we 
have a validator available to PCEnv, we could use this to warn the user 
if they try to save an invalid model.

Best regards,
Andrew

_______________________________________________
cellml-discussion mailing list
[email protected]
http://www.cellml.org/mailman/listinfo/cellml-discussion

Reply via email to