Current Thinking for libCellML

This document simply outlines some of the current rationale that has an influence on how the codebase is developed.

• Temporarily dealing with external documents that are stored on the local file system (relative to the current CellML model document).

  • Allows testing of the most common model import scenario (local files addressed with a relative URL).

  • Absolves libcellml from fetching files and communicating across the Internet.

  • Expect to provide another layer that would perform this role as a libCellML I/O library, which would allow the removal of this temporary inclusion.

  • No avenue to retrieve remote external references.

• Serialise and deserialise from a string.

• Present a useful interface not one tied to the XML serialisation structure.

• Validation is quite separate (you are free to make invalid CellML models).

• Public API treats MathML as strings only.

  • Internal to the code generation we are currently creating our own MathML object model based on an abstract syntax tree.

  • Minimal implementation to support the immediate requirement of code generation.

  • Expect to provide another layer that would handle MathML as a separate thing, potentially linking back to the advanced functionality envisions for symbolic analysis of the model.

  • Internal to the validator, the MathML strings are parsed into a DOM for use in schema validation against the MathML schema.