Chronological Thread 

< Chronological >      < Thread >

---

I'm really not sure what the purpose of this email is?

The only part of the subject which fits in my reasonably wide mail
reader window is "Include_in_CellML_1.2 requested: [Tracker Item193]
CellML" which firstly makes me think there is no point reading it.

Then, the first bit of text provides a link to an inaccessible bug
tracker (The connection has timed out The server at
bioeng44.bioeng.auckland.ac.nz is taking too long to respond.) -
reinforcing the idea that this email should not have been sent to the
cellml-discussion mailing list. This also suggests the appropriate form
of a reply to this tracker email would be via the tracker, which is
currently not possible.

Finally, glancing at the "additional comments" section of the email it
looks like this might be some kind of strategy for how and when to
change the XML namespace of elements defined in the CellML
specifications - possibly following up on the discussion on the mailing
list a few weeks back. But there is no text defining whether this is an
actual proposal, an idea which may become a formal proposal, or simply a
draft of the text for some section in the 1.2 specification. Also, if
this is following up on the mailing list discussion then I would have
expected more additional comments to have been attached based on the
discussion on the mailing list - or at least links to that threaded
discussion.

Combined, these issues reiterate my previous comments that the as yet
unreleased, unusable, inaccessible bug tracker should not be sending any
emails to the cellml-discussion mailing list. Also, given there is no
community accessible or announced proposals of what other features are
under consideration in future versions of the CellML XML specification
there seems little point is asking for any particular feature to be
included in any specific version.


David.

cellml-tracker at cellml.org wrote:
> 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 mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [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.