Chronological Thread 

< Chronological >      < Thread >

---

Andrew Miller <ak.miller at auckland.ac.nz> has asked for
Include_in_CellML_1.2:
Tracker Item 193: CellML namespaces policy for CellML 1.2 (and beyond)
http://bioeng44.bioeng.auckland.ac.nz:8000/cellml_tracker/show_bug.cgi?id=193

------- Additional Comments from Andrew Miller <ak.miller at auckland.ac.nz>
In CellML 1.1, all elements in CellML 1.0 were re-introduced in the CellML 1.1
namespace, so there is no mixing of elements between the two namespaces in a
particular document.

This creates a rather significant cost in terms of both implementation (where
implementors have to check for all namespaces if they are to support a new
version of CellML, even for elements which have not changed their semantics at
all). It also has adverse effects on the compatibility of documents from one
version of the specification to the next, because a valid CellML 1.0 document
is never a valid CellML 1.1 document because the namespaces are wrong, and a
valid CellML 1.1 document is never a valid CellML 1.0 document even if it
doesn't use imports, because again, the namespaces are wrong.

If we were to keep elements in the namespace when their semantics last
changed,
and keep elements in the old namespaces as being valid (but constrained to the
old semantics), this would allow us to keep backwards compatibility (because a
valid CellML 1.1 model would still be a valid CellML 1.2 model, although in
some cases features may be deprecated and eventually removed, such as the
reaction element), and it would also allow us to keep forwards compatibility
when it makes sense (a valid CellML 1.2 model which doesn't use any new CellML
1.2 features should be a valid CellML 1.1 model).

Tools will be able to detect if they can support a model by using the
following
rule: reject any model which contains any elements in an unrecognised
namespace
starting with http://www.cellml.org/cellml as being a model coded in an
unsupported future version of CellML.

A new namespace is allocated for each version of CellML, but only a limited
number of elements are actually in that namespace, most elements remain in the
same namespace as in the previous version of CellML.

If a new element is added in a particular version of CellML, it is added to
the
specification and will be in the namespace of the specification when it was
added.

An element may be removed from the specification by marking it deprecated for
some period of time, and eventually just removing it from a future
specification. This ensures that tools which output valid models will be
compatible with tools which read in models as long as the tools implemented
specifications which came out within a certain period of time of each other
and
do not output any deprecated elements.

Changes to the semantics of elements (including, for example, adding a new
attribute into an element) work like this: the element with the old semantics
is kept in the original namespace, but another element with the new semantics
and with the same local name is added, but in the new namespace. If the new
semantics are significantly better than the old semantics in all cases, then
the old element is marked deprecated. If the new semantics extend the old
semantics but in some cases are no better, then tools are encouraged to output
the element in the original format unless they want to use a feature only
available under the new semantics.

---

• [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 193] CellML namespaces policy for CellML 1.2 (and beyond), cellml-tracker at cellml.org, 10/04/2007
  • [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item193] CellML namespaces policy for CellML 1.2 (and beyond), David Nickerson, 10/04/2007

---

Archive powered by MHonArc 2.6.18.