First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
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: David Nickerson <david.nickerson AT gmail.com>
  • To: cellml-tools-developers AT lists.cellml.org
  • Subject: Re: [[cellml-dev] ] libCellML handling of non-valid CellML - discussion request
  • Date: Sat, 17 Jan 2015 16:07:05 +1300
>
> 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).
>

yep - my view is that if you are developing an application that needs
to be dealing directly with the XML then you should deal directly with
the XML not via libCellML. I believe it is important to make sure the
scope of libCellML doesn't blow out of control like that of the CellML
API did.

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

not quite. I do think libCellML should be able to keep track
internally of external data (RDF, extensions, etc) so that such losses
would not occur. Whether there should be API to enable access to such
data in libCellML, I don't know. Its maybe not too hard to imagine
some fairly generic code to extract XML snippets? Again, something
that would be useful to discuss when looking at the libCellML object
model and API as a whole (I see it is down as 2.2 under Milestone 2 in
the libCellML roadmap).

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

yes, it will be a lot of work - but it will also be a more useful tool
at the end of the day. This is one reason why I believe we should only
be developing one annotation tool that can be reused/embedded into
many different applications.

libCellML is, in my view, a library for interacting/working with
CellML Models - not files. Its perhaps a subtle distinction, but quite
an important one.

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

generating procedural code might be in the scope of libCellML
(Milestone 3), but we also want to ensure that common utilities that
build on top of libCellML are also developed and available (see 2
under Milestone 3 of the roadmap).


Cheers,
Andre.

Archive powered by MHonArc 2.6.18.

Top of page