Chronological Thread 

< Chronological >      < Thread >

---

Alan Garny wrote:
>> At the break-away session on the versioning strategy for CellML (which
>> followed the Auckland CellML meeting today) we discussed the future of
>> how we would version CellML, including whether we would put all elements
>> for the next version of CellML in a completely different namespace, or
>> only the elements that had changed.
>>
>> A summary of the discussion is up at
>> http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/
>> under "Breakaway session on versioning strategy for CellML". Note that
>> the participants at the session have not had a chance to correct errors
>> in it yet, and it may not yet accurately reflect everyone's view.
>> However, it does lay out the options, and so may provide a starting
>> point for any suggestions or comments from the community.
>>
>> Please send and such suggestions or comments to the CellML discussion
>> mailing list prior to the 3rd October 2007.
>>
>
> That all seems reasonable to me, just one comment:
>
> - At the moment, CellML doesn't explicitly support the rem element
> (remainder function in MathML), even though CellML does allow its use (at
> the risk of ending in a situation where a model may work fine in a given
> CellML tool -- that supports the rem element --, but not in a nother -- that
> doesn't support the rem element --). Now, say that we officially want CellML
> to 'support' the rem element, how do we go about doing that?
>
A lot of things are valid CellML but are not supported by everyone
(really, the only thing widely supported are systems of ODEs). CellML
provides the overarching structure for describing these things, and we
need to start to narrow down exactly what tools should be supporting as
well, using compatibility documents or something like that which
describe a feasible subset of CellML to implement. The could be more
than one of these, but we don't want there to be too many similar
documents. However, I think we should keep them away from the core of
CellML, because CellML's generality is quite useful when it comes to
expanding into new types of problems (for example, constitutive laws,
PDE systems, and so on).

Best regards,
Andrew

> Otherwise, Matt wrote:
>
>
>> ... You might want to scan a document to see what
>> "versions" the model conforms up to, but one of the nice things about
>> pushing these new elements/attributes into new namespaces is that you
>> can still treat a model as say 1.1 even if it contains 1.2 elements
>> and attributes...
>>
>
> Treat that model in what way? Surely, if a model uses some 1.2 elements,
> then there must be a reason to it. Therefore, a 1.2 model cannot be treated
> as a 1.1 model, or did I miss something?
>
> Alan.
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

---

• [cellml-discussion] CellML Versioning Strategy, Andrew Miller, 09/19/2007
  • Message not available
    • [cellml-discussion] CellML Versioning Strategy, Matt Halstead, 09/19/2007
      • [cellml-discussion] CellML Versioning Strategy, Andrew Miller, 09/19/2007
        • [cellml-discussion] CellML Versioning Strategy, Matt Halstead, 09/19/2007
  • [cellml-discussion] CellML Versioning Strategy, Alan Garny, 09/20/2007
    • [cellml-discussion] CellML Versioning Strategy, Andrew Miller, 09/20/2007
      • [cellml-discussion] CellML Versioning Strategy, David Nickerson, 09/20/2007
  • Message not available
    • [cellml-discussion] CellML Versioning Strategy, Matt Halstead, 09/20/2007
      • [cellml-discussion] CellML Versioning Strategy, Andrew Miller, 09/20/2007

---

Archive powered by MHonArc 2.6.18.