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.