A list for the developers of CellML tools

Text archives Help


RE: [[cellml-dev] ] libCellML handling of non-valid CellML - discussion request


Chronological Thread 
  • From: "Alan Garny" <alan.garny AT inria.fr>
  • To: <cellml-tools-developers AT lists.cellml.org>
  • Subject: RE: [[cellml-dev] ] libCellML handling of non-valid CellML - discussion request
  • Date: Fri, 16 Jan 2015 10:58:21 +0100
  • Organization: INRIA

> > Regarding connections: first and foremost, I am all in favour of an
> > API that looks like what David described (i.e. “[provide] a much
> > cleaner, more intuitive, and flexible interface for application
> > developers”). However, I have typical cases where access to a
> > DOM-based structure would also be useful.
> My view would be that if you want a DOM based representation of a CellML
> XML file then you should probably use an XML library directly rather than an
> abstracted DOM view via libCellML :) Exactly as you have said for working
> with your pretty CellML view in OpenCOR, which is really a pretty view of
> CellML XML.

Fair point, not least since this is indeed the approach I took (although I
originally did so because the current CellML API doesn't keep track of the
order of CellML elements).

> > One such case is the CellML Annotation view in OpenCOR. In that view,
> > we want to be able to annotate any CellML element and, whether we/I
> > like it or not, that includes connection elements.
> LibCellML won't be doing anything with RDF or annotations, so not too much
> of a problem for libCellML. One issue that might be worth discussing is how
> to assign cmeta:id's to serialised XML elements that are not directly
> represented in the object model - if that is even something that should be
> in
> the scope of libCellML.

OK, so if I understand correctly, for my CellML Annotation view too I should
probably rely on an XML library rather than libCellML so that I could access
connection elements, and use an RDF library to do the annotation (since I
agree it should have nothing to do with libCellML). Now, that does indeed
leave the issue of cmeta:id's. If they were not to be in the object model and
some CellML elements of a CellML file were to have a cmeta:id associated with
them, then simply to load that CellML file with libCellML and serialise it
back (without doing anything to the model) would result in the cmeta:id's
being lost. This is effectively what happens with COR's CellML API... So, I
would imagine that we want cmeta:id's to be in the scope of libCellML.

> > Now, assuming we cannot access connections, what would happen in the
> > following scenario: say that you have 4 components (A1, A2, B1 and B2)
> > that are all siblings. Say that both A1 and B1 define the exact same
> > variable V
> I think you mean to say that A1.V and B1.V have the same name, they are
> obviously not the same variable and would each have distinct objects.

Yes, of course, sorry for the confusion.

> > and that this variable contains the result of some calculation (with
> > different results for A1.V and B1.V). Next, say that A2 and B2 need to
> > use the result of A1.V and B1.V, respectively. Now, since I don’t have
> > access to connections, how would I tell libCellML that A2.V is
> > connected to A1.V and that B2.V is connected to B1.V?
> I would imagine something along the lines of either A1.V = A2.V or
> A1.v.isEquivalentTo(A2.V).

OK, fair enough.

> It is important to remember that a connection is
> nothing more than an equivalency relationship (with unit
> conversion) between two variables and I believe it is that relationship
> that is
> the important piece of information to represent in the libCellML object
> model
> and API. I see that relationship being a property of the variables.

OK, I now understand where you guys are coming from, and it makes sense. I
guess I was just being 'lazy' and wanted everything in libCellML, so that I
don't have to use various libraries to handle CellML files, although I have
already started doing that (for the Pretty CellML view in OpenCOR). (Now,
when it comes to the CellML Annotation view in OpenCOR, I can see that
switching from the CellML API to libCellML might involve quite a bit of
work...)

> Also, when
> talking about the result of a calculation or using the value of any
> variable you
> are really meaning the instantiation of the model into a simulation, which
> is
> also something that is currently out of scope for libCellML.

I am hoping that it's only temporarily out of scope?

Alan




Archive powered by MHonArc 2.6.18.

Top of page