.. _libCellMLCurrentThinking:

==============================
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 <https://www.w3.org/XML/>`_ serialisation structure.
- Validation is quite separate (you are free to make invalid `CellML <https://www.cellml.org/>`_ models).
- Public API treats MathML as strings only.

  - Internal to the code generation we are currently creating our own `MathML <https://www.w3.org/Math/>`_ 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.