- 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.