- From: alan.garny at dpag.ox.ac.uk (Alan Garny)
- Subject: [cellml-dev] CellML API - GetAlternateVersion from the Model interface
- Date: Fri, 25 Sep 2009 11:19:06 +0100
Argh, I really wish it had been a problem with my code! Well, if anything,
thanks for reminding me about that tracker item, I had clearly forgotten
about it. I have changed its priority so that it is now set to "Highest
priority".
Alan
From: cellml-tools-developers-bounces at cellml.org
[
mailto:cellml-tools-developers-bounces at cellml.org] On Behalf Of Jonathan
Cooper
Sent: 25 September 2009 11:14
To: A list for the developers of CellML tools
Subject: Re: [cellml-dev] CellML API - GetAlternateVersion from the Model
interface
Hi Alan,
See
https://tracker.physiomeproject.org/show_bug.cgi?id=1331
Best wishes,
Jonathan
Alan Garny wrote:
Hi,
I have just been reminded about this mailing list for my CellML-related
'problems', so here goes.
I am currently working on generating a CellML object from the COR-like view
in OpenCell. Right now, I am able to create an empty CellML 1.0 object.
However, should the user specify an import statement in the COR-like view, I
would like to 'convert' that CellML 1.0 object to a CellML 1.1 object.
Unless I am mistaken, I believe that one should be able to do that using the
GetAlternateVersion method from the Model interface. At the moment, I have a
Bison rule that reads as follows:
_____
importstart: T_IMPORT T_URI T_AS {
// We are importing something, which means the model should be a CellML
1.1
// model (as opposed to a CellML 1.0 model, which is what it is by
default)
nsString cellMLVersion;
(*aCellMLOutput)->GetCellmlVersion(cellMLVersion);
if (cellMLVersion.Equals(NS_LITERAL_STRING("1.0")))
(*aCellMLOutput)->GetAlternateVersion(NS_LITERAL_STRING("1.1"),
aCellMLOutput);
};
_____
The above code works fine in that the CellML 1.0 model does become a CellML
1.1 model (as can be seen in the XML view), BUT the whole contents of the
CellML model disappears in the process. Say that I initially had the
following COR code:
_____
def model my_model as
enddef;
_____
This corresponds to the following CellML code:
_____
<?xml version="1.0"?>
<model xmlns= <
http://www.cellml.org/cellml/1.0>
"
http://www.cellml.org/cellml/1.0#" xml:base="" name="my_model"/>
_____
Then, say that I edit the COR-like view to read:
_____
def model my_model as
def import {uri: cellml.org} as
comp A as B;
unit C as D;
enddef;
enddef;
_____
This requires the CellML object to be 'converted to' CellML 1.1. However,
when switching to the XML view (something that will trigger the
'conversion'), I get:
_____
<?xml version="1.0"?>
<model xmlns= <
http://www.cellml.org/cellml/1.1>
"
http://www.cellml.org/cellml/1.1#" xml:base=""/>
_____
So, the model has been 'converted to' CellML 1.1, but everything is gone and
indeed, if you switch back to the COR-like view, you will (as you would
expect) get the following:
_____
def model as
enddef;
_____
So, does anyone know what I have done wrong, if anything? I have checked the
CellML test for GetAlternateVersion and it 'only' checks the CellML version,
a test which my current code would also pass, but which should in fact fail
(if we consider that the contents of the model has gone). It seems like
RecursivelyChangeVersionCopy might not be working? (I am currently looking
into it.)
Anyway, if any of you had some comments on the above or, most importantly, a
working solution to my problem, then please feel free to make yourself
heard. J
Cheers, Alan.
Dr Alan Garny
University of Oxford, Department of Physiology, Anatomy & Genetics
Sherrington Building, Parks Road, Oxford, OX1 3PT, England
http://noble.physiol.ox.ac.uk/people/agarny/
http://cor.physiol.ox.ac.uk/
_____
_______________________________________________
cellml-tools-developers mailing list
cellml-tools-developers at cellml.org
http://www.cellml.org/mailman/listinfo/cellml-tools-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<
http://www.cellml.org/pipermail/cellml-tools-developers/attachments/20090925/785f6622/attachment.htm>
Archive powered by MHonArc 2.6.18.