Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

That looks like a sensible approach to me, and fits within the current
style and implementation of the API. Is there a reason for using
'makeFlattener()'? It would seem more consistent with the other
services to use 'createFlattener()'.

I'm also wondering if perhaps we could use this service to start using
more meaningful names for things and rather than MoFS simply use
ModelFlatteningService in full?

While I am not sure if we should follow suit, it might be worth
looking at the libSBML approach of having a generic converter which is
implemented in several task specific interfaces
(http://sbml.org/Software/libSBML/docs/cpp-api/class_s_b_m_l_converter.html).
This would have the benefit of flexibility in regard to arbitrary
conversions, such as decomposing 1.0 models into 1.1 or converting 1.1
models into 1.2 models. Model flattening is then just another
conversion task.


Cheers,
Andre.

On Wed, Jun 12, 2013 at 8:09 AM, Andrew Miller <ak.miller at auckland.ac.nz>
wrote:
> Hi all,
>
> I've been looking at what an API for flattening CellML 1.1 models into
> CellML 1.0 models should look like. I think we want to allow for future
> expansion so we can flatten models with different options (for example, we
> could have an off-by-default option that also changes encapsulation to suit
> original COR) without breaking backwards compatibility, so I think we want a
> two tier system where you ask the service for a flattener (which you can
> customise through attributes) and then run the flattening. We could go for a
> third level and have a 'flattening result' interface, but I'm not sure if
> that will be useful enough to justify the additional complexity it adds.
>
> Please let me know what you think of the interface design below.
>
> Best wishes,
> Andrew
>
> /**
> * @file
> * The MoFS, or Model Flattening Service, allows CellML 1.1 models with
> imports
> * to be 'flattened' to a CellML 1.0 model where all the content from the
> * imports is placed in one file.
> */
> #include "CellML_APISPEC.idl"
>
> module mofs
> {
> /**
> * Represents a particular set of options for model flattening.
> * (note that initially there are no options, but this design allows for
> * future expansion).
> */
> interface ModelFlattener
> : XPCOM::IObject
> {
> /**
> * Flattens a CellML 1.1 model into a CellML 1.0 model with all imported
> * components and their dependencies in one file.
> * @param aModel The model to flatten.
> * @raises cellml_api::CellMLException if an error in the model prevents
> * flattening. lastError will
> contain
> * details.
> */
> cellml_api::Model flatten(in cellml_api::Model aModel)
> raises(cellml_api::CellMLException);
>
> /**
> * Contains an error explaining the last failure to flatten a model.
> */
> readonly attribute wstring lastError;
> };
>
> interface ModelFlatteningService
> : XPCOM::IObject
> {
> /**
> * Creates a new model flattener with default options.
> */
> ModelFlattener makeFlattener();
> };
> };
>
> _______________________________________________
> cellml-tools-developers mailing list
> cellml-tools-developers at cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-tools-developers

---

• [cellml-dev] A standard model flattening API?, Andrew Miller, 06/12/2013
  • [cellml-dev] A standard model flattening API?, David Nickerson, 06/12/2013
    • [cellml-dev] A standard model flattening API?, Andrew Miller, 06/12/2013

---

Archive powered by MHonArc 2.6.18.