> 3) Do you agree with the basic premise of the proposal, that is that > it is better to have a model which is partly expressed in CellML, than > to have a model which is entirely expressed in a more general > programming language?
yes. > 4) Do the best practice guidelines for CellML authors adequately > protect the utility of CellML as a model interchange format? I think so. > 5) Does the proposed approach fit well with the design of CellML? not really. The design philosophy of CellML is to utilise existing standards where possible. I seem to recall the original intention for the inclusion of required procedural code in a model was through the csymbol mechanism you describe, but the code referenced is defined in a standard format - with ECMAScript the preferred choice at that time. And I see now there is a ECMAScript for XML extension, E4X, which might be useful? By using a standard format for the external code (particularly if available support for that format is good), you could reasonably expect multiple applications to support your model. Although, similarly, if the support you describe is built into the CellML API (CCGS?) then you could also expect multiple applications to support a given model with external code. Maybe some examples of where the use of external code is required would be useful? David. _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
