First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2


Chronological Thread 
  • From: david.nickerson at nus.edu.sg (David Nickerson)
  • Subject: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2
  • Date: Thu, 20 Dec 2007 00:30:32 +0800
> * Remove the CellML Subset / "fully MathML capable software" - instead,
> delegate
> the exact description of what mathematical expressions are allowed in
> models
> to secondary specifications which refine the mathematics allowed in
> CellML to
> the point that the secondary specification can realistically be completely
> implemented for all cases.
>
> This will allow for tools to support multiple secondary specifications if
> they deal with more than one problem domain.

this seems to be a good direction to be heading.

> * Remove the recommended prefixes for namespaces in the normative
> specification, although this could go in the informative specification
> as a
> suggestion. This should help ensure that no one relies on things having a
> particular prefix, which the current specification doesn't go out of its
> way to prevent.

I don't see this as being a problem, but have no reason not to take it
out of the normative specification.

> * Make CellML identifiers like _1a valid. The 1.1 specification currently
> contradicts itself on whether this identifier is valid.

agreed.

> * Assume attributes without an explicit prefix are in the empty
> namespace, in
> accordance with 6.2 of the namespaces in XML document. This means that
> it would
> be invalid to explicitly put an attribute in the CellML namespaces.
> <model xmlns="http://www.cellml.org/cellml/1.1#";
> xmlns:cellml="http://www.cellml.org/cellml/1.1#";
> cellml:name="test">...</model>
> would be invalid, while
> <model xmlns="http://www.cellml.org/cellml/1.1#"; name="test">...</model>
> remains valid. This seems to be consistent with how people have actually
> implemented CellML processing software.

yep - sounds like how it should be defined.

> * Software will be required to identify cases (and report an error) where
> future CellML elements are present (unrecognised namespaces starting with
> http://www.cellml.org/cellml/).

I think this one needs a bit of elaboration. I'm guessing this applies
to all software which claims to be CellML 1.2 compliant/conformant to
some degree, right? and would need to tie in with applications
supporting the secondary specifications with regard to the type of
MathML they support...

> * It will be valid to define presentation MathML from within extension
> elements.
> This should be legitimate content for an extension element.

didn't realise this was currently not allowed. Definitely good to allow
it. On a related note, I presume it currently is and will continue to be
valid to also provide presentation MathML using the annotation mechanism
within MathML?

> * Software will no longer be encouraged to alert the user to unrecognised
> extension elements. Extension elements shouldn't contain information
> which is
> essential to the model processing, so there is no need to warn the user.

agreed.

> * In CellML 1.1, only one connection element can be present for all
> variables
> being connected for a particular pair of components. This restriction can
> make coding models unnecessarily hard and there is no evidence that it
> reduces the implementation burden. Therefore, it makes sense to remove
> this
> restriction. It will still not be possible to connect the same
> variables more
> than once.

I don't recall the discussion on this issue ever being resolved, but
this would imply that some resolution was achieved somewhere?

> * The current specification says:
> "A variable with either a private_interface or public_interface attribute
> value of "in" must be mapped to no more than one other variable in the
> model. [ Note that a similar restriction does not apply to variables with
> interface values of "out". An output variable can be mapped to multiple
> input variables in various components in the current model. ]"
>
> The problem with this is that it doesn't properly account for mappings
> where
> a variable is forwarded into an encapsulated block. As an example,
> consider
> the following encapsulation hierarchy (higher components encapsulate lower
> ones)...
>
> A
> |
> B
> / \
> C D
>
> Suppose that component A has, for variable v, public_interface="none",
> private_interface="out", and B has for variable v, public_interface="in",
> private_interface="out" (connected to A), and C and D have
> public_interface="in",
> private_interface="none", both of which are connected to B.
>
> There is no reason why this should not be valid. However, the
> specification
> contradicts itself on whether this is allowed. On one hand, because B has
> private_interface="out", it "can be mapped to multiple input variables in
> various components in the current model.", but because it has a public
> interface of in, it "must be mapped to no more than one other variable
> in the
> model".
>
> This can be fixed by firstly defining the interpretation of
> connections and
> interfaces, and then adding constraints based on that which actually
> describe
> which connections are allowed to each set of variables.

will be interesting to see how such a definition ties in with the idea
of input variables becoming output variables based on the way the
components are hooked together :)

> * CellML 1.1 provides facilities for the support of scripting. While we
> probably shouldn't rule this out in the next version, it should be
> delegated
> to the secondary specifications mentioned above.

you mean the inclusion of ECMA script code via the csymbol mathml element?

> * The reaction element will be removed from the specification. The
> informative
> specification will provide alternative ways to represent the same
> information
> without breaking tools which are not reaction aware, making CellML
> more domain
> independent.

While I still have reservations about the abruptness of the removal of a
core CellML element and the fact that discussion on this issue was never
resolved, I see that no one else is concerned and so have no issues with
this change.

> * metre and meter, and litre and liter will be described as being equivalent
> to one another, instead of being separate, dimensionally incompatible
> units.

good.

> * The multiplier and prefix attribute part of the units conversion
> formula were
> incorrect in the CellML 1.1 specification, when compared to the
> examples. The
> 1.2 specification will describe units conversions correctly.

sweet.

> * Units conversion on connections is not mandatory in CellML 1.1. This will
> result in different results in different packages. In CellML 1.2 it will
> be mandatory.

makes sense, especially given the support in the api implementation.

> * Software will not be permitted to automatically (i.e. without asking the
> user) insert constants into the mathematics in an attempt to correct any
> units inconsistencies identified, but will of course be able to report
> on any
> errors identified.

will need to see further details on such a constraint, especially in
regard to software with little or no user interaction.

> * Containment information will no longer be permitted, nor will user defined
> relationships. Only a single encapsulation tree will be permitted.
> Instead,
> in the informative version of the specification, users will be
> encouraged to
> represent such information as RDF in metadata.

Same comments as for the removal of the reaction element.

> * Import semantics will be changed so that each import element creates one
> separate instance of the model, and a given unit or component can only be
> imported once per import element. This is required to avoid various
> consistency problems that arise otherwise - see the earlier mailing list
> thread on this.

yep.

> * Add support for non-scalar mathematics, subject to what the secondary
> specification allows.

I think this deserves a more detailed proposal in order to understand
the full implications of such a change.



Andre.


Archive powered by MHonArc 2.6.18.

Top of page