First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
A list for the developers of CellML tools

Text archives Help


Re: [[cellml-dev] ] Feedback on libCellML design document


Chronological Thread 
  • From: Randall Britten <r.britten AT auckland.ac.nz>
  • To: cellml-tools-developers Mailing List <cellml-tools-developers AT lists.cellml.org>
  • Subject: Re: [[cellml-dev] ] Feedback on libCellML design document
  • Date: Wed, 11 Feb 2015 21:38:47 +0000
  • Accept-language: en-NZ, en-US
Hi Andre

Thanks for spotting the the remaining reference to Manager, I’ve fixed
that. (Note that it was corrected already in the C++ code and generated
doxygen
(http://codecurve.github.io/libcellml/namespacelibcellml.html#ae54ba0337454
7559e066efcf25ff4328, although this link will likely change next time
doxygen is regenerated.)

I’ve certainly given some thought to your suggestion for the handling of
imports, and still considering it. My hunch at this stage is still that
it will be preferable to use a Manager to handle issues that arise when
serialising multiple XML files that reference each other due to imports,
but I don’t think we can really decide either way until we actually start
working on those “use cases” (I’m not sure we’re using the term “use case”
strictly correctly, hence the quotes.).

Variable typing: As you know, I’ve been working off this draft spec:
http://codecurve.github.io/cellml-core-spec/, and this draft secondary
spec: http://codecurve.github.io/cellml-dae-events-secondary/, since they
are the only documents that represent a draft of CellML 1.2 as far as I
can tell, and have been available at various URLs for a few years now. I
am aiming to spend some time soon to see if it is possible to use tracker
item 55 as a draft spec as you suggested. (The draft spec at
http://cellml-specification.readthedocs.org/en/latest/ is not suitable
since it is essentially a CellML 1.1 specification (e.g. Still has
grouping, still has directionality of connections)). Note that tracker
item 47 (variable types) was completed in 2011, before it was removed from
tracker item 55, that is why it is in the draft spec, and hence the
libcellml design at this stage.

Regards,
Randall

On 10/02/15 9:18 pm, "David Nickerson"
<david.nickerson AT gmail.com>
wrote:

>Hi Randall,
>
>I see that an import class and variable typing is still in the draft
>design document. How are you going in considering my proposal that
>imports are no different to connections and are not required in the
>libCellML object model? Although imports and variables are not
>required for the first few use cases so no need to stall development
>until this is resolved.
>
>There is also still a reference to the Manager class in the
>implementation details section of the design doc.
>
>
>Cheers,
>Andre.
>
>
>On Mon, Feb 9, 2015 at 2:59 PM, Randall Britten
><r.britten AT auckland.ac.nz>
> wrote:
>> As was decided at last week¹s LibCellML meeting, I¹ve removed the
>>Manager.
>> We¹ll consider the manager again if it seems necessary when working
>> directly on a use case with imports. I¹ve also renamed ³Unit² to
>>³Units².
>>
>> Regards,
>> Randall
>>
>> On 4/02/15 11:11 pm, "David Nickerson"
>> <david.nickerson AT gmail.com>
>>wrote:
>>
>>>> I still think that Manager will be needed as a support class for
>>>>handling
>>>> some of the nuances that will crop up when serialising a group of
>>>>models
>>>> that are linked via imports. I think that some code for this would
>>>>shed
>>>> light on the issues.
>>>
>>>I think that is showing the reason for why you consider it necessary,
>>>but I don't see why libCellML would ever need to concern itself with
>>>serialising a group of models linked by imports? I'm not sure I even
>>>understand what that means or how it could be something that libCellML
>>>needs to worry about...perhaps as you say some code would shed light
>>>on this but I'm not seeing how. My preference would be to see the code
>>>base developed without a Manager until it can be shown that things
>>>simply don't work without such an object.
>>>
>>>Cheers,
>>>Andre.
>>
>
>
>
>--
>
>
>David Nickerson
>about.me/david.nickerson


Archive powered by MHonArc 2.6.18.

Top of page