Chronological Thread 

< Chronological >      < Thread >

---

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] Developing a set of milestones for future releases of the PCEnv, Andrew Miller, 12/04/2006
  • [cellml-discussion] Developing a set of milestones for futurereleases of the PCEnv, Nickerson, David Phillip, 12/06/2006
    • [cellml-discussion] Developing a set of milestones for futurereleases of the PCEnv, Andrew Miller, 12/06/2006
      • [cellml-discussion] Developing a set of milestones for futurereleases of the PCEnv, Shane Blackett, 12/06/2006
        • [cellml-discussion] Developing a set of milestones for futurereleases of the PCEnv, Andrew Miller, 12/06/2006
          • [cellml-discussion] Developing a set of milestones for futurereleases of the PCEnv, Shane Blackett, 12/06/2006

---

Archive powered by MHonArc 2.6.18.