Chronological Thread 

< Chronological >      < Thread >

---

Dear Andrew

In section 7.1.2.d the draft specification state:
The type attribute. If the attribute is present, the value MUST be a URI. The
URI MAY be http://www.cellml.org/cellml/1.2#real, which SHALL be interpreted
as indicating that the variable is real valued. If the attribute is absent,
this should be treated as if the URI was
http://www.cellml.org/cellml/1.2#real. In either of these two cases, the
units attribute MUST be present.
I think that this approach is unwieldy and inconsistent, and would prefer
something akin to the definition of units where users may define new units
names. While we probably won't permit this in CellML 1.2, I think that it is
important to structure the type attribute to make it simple to take this
route. Rather than requiring the value of the type attribute be a URL, I
suggest that we require it to be a valid CellML identifier in the namespace
of type reference. Initially we will restrict this to "real_type" and
"logical_type" or "boolean_type", but will perhaps offer further predefined
types (e.g. "integer_type", "complex_type", "rational_type", "set_type",
"list_type", "function_type", "array_of_real_type", "array_of_integer_type")
or even user-defined types.

Best wishes
Poul

On 2011-02-09, at 13:39, Andrew Miller wrote:

> On 02/02/11 18:36, Lucian Smith wrote:
>> * Andrew Miller<ak.miller at auckland.ac.nz> [2011-02-02 03:27] writes:
>>> Hi all,
>>>
>>> I've just put up an unofficial draft CellML specification up at
>>> http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/toplevel.xhtml
>>> to prototype what some of the new features could look like.
>>>
>>> This version has the following features:
>>> Backwards and forwards compatibility with CellML 1.1.
>>> A new attribute, type, on variables. It defaults to real, but can
>>> alternatively point to a URL defining the type (it is up to secondary
>>> specifications to define the meaning of URLs other than the one for real
>>> values defined in the specification).
>>>
>>> The source for generating the specification and creating your own draft
>>> version is up at http://repo.or.cz/w/cellml-draft-miller.git - the
>>> andrews-preferred-version branch was used to generate the XHTML linked to.
>>
>> The section on MathML was a little vague--are *all* valid MathML
>> constructs valid CellML constructs, or only a subset?
>
> Hi all,
>
> All valid MathML constructs are, under the draft, valid according to that
> draft if they occur in the correct part of the model. The specification
> allows secondary specifications to be defined which narrow down CellML
> models to a set which can be implemented by a solver in their entirety.
>
>>
>> Also, I didn't see anything in there about events--are those being
>> deferred again?
>
> This is not a final draft, it is an unofficial one to add specific things
> to previous drafts.
>
> Supporting the same types of models that 'events' would support was one of
> the motivations for adding the type attribute - it is likely that not much
> else is needed in the primary specification. Events can essentially be
> supported as mathematical expressions - either using piecewise or logical
> operators, combined with an infinitesimal delay (a csymbol - something that
> would be defined in a secondary specification).
>
> For example, to halve x when it gets to 20, the mathematics might look like:
> (infinitesimallyDelayed(x) < 20) or (x = infinitesimallyDelayed(x) / 2)
>
> Like all equations in the model, this is an assertion. In this case, it is
> that either x was less than 20 an instant before now, or x is now half of
> what it was before. This declarative form could be converted into an
> imperative form (assign to x if it ever becomes less than 20) by tools.
>
>>
>> My only other suggestion is that eventually you'll want pictures in there
>> ;-)
>
> The intention is to make a normative specification, containing only the
> formal description of CellML, with has no extraneous material, as the
> authoritative specification, and an informative one based on that, which
> would not be the authoritative, but would be easier to read.
>
> Best wishes,
> Andrew
>
>>
>> -Lucian
>> _______________________________________________
>> cellml-discussion mailing list
>> cellml-discussion at cellml.org
>> http://lists.cellml.org/mailman/listinfo/cellml-discussion
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.cellml.org/pipermail/cellml-discussion/attachments/20110216/93199b9b/attachment-0001.htm>

---

• [cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables, Andrew Miller, 02/02/2011
  • [cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables, Lucian Smith, 02/02/2011
    • [cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables, Andrew Miller, 02/09/2011
      • [cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables, Poul Nielsen, 02/16/2011

---

Archive powered by MHonArc 2.6.18.