A list for the developers of CellML tools

Text archives Help


[cellml-dev] r3031 - in CellML_DOM_API/branches/CeLEDS: . CeLEDS CeLEDS/languages CeLEDS/sources interfaces


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] r3031 - in CellML_DOM_API/branches/CeLEDS: . CeLEDS CeLEDS/languages CeLEDS/sources interfaces
  • Date: Thu, 29 Jan 2009 14:19:21 +1300

Hi Adam,

This looks good, a few comments are inline (I'm focusing on reviewing
the interface for now)...

> Added: CellML_DOM_API/branches/CeLEDS/interfaces/CeLEDS.idl
> ===================================================================
> --- CellML_DOM_API/branches/CeLEDS/interfaces/CeLEDS.idl
> (rev 0)
> +++ CellML_DOM_API/branches/CeLEDS/interfaces/CeLEDS.idl 2009-01-29
> 00:40:00 UTC (rev 3031)
> @@ -0,0 +1,60 @@
> +#include "CellML_APISPEC.idl"
> +/**
> + * CeLEDS (CellML Language Export Definition Service) provides a
> + * service for returning language definitions required by components
> + * involved in export of CellML models to various programming languages.
> + * Language definitions are stored in XML files.
> + */
> +module cellml_services
> +{
> + /**
> + * Language definition component for a specific language, eg
> + * MaLaES Tags or CCGS Patterns. Stored as a map of keys and values
> + * which are both strings.
> + */
> + interface langDefComponent
>
The convention so far is to use upper-case letters for interface names.

> + : XPCOM::IObject
> + {
> + /**
> + * Create a single string in the format used by MaLaES
> + * from all tags.
> + */
> + wstring createMalString();
> + /**
> + * Return the value for a given key.
> + */
> + wstring getValue(in wstring key);
> + };
> +
> + interface langDefGenerator
> + : XPCOM::IObject
> + {
> + /**
> + * Creates a CeLEDS language definition component object from the XML
> language definition file.
> + * @param componentNameSpace XML namespace for element to retrieve
> dictionary entries from
> + */
> + langDefComponent getComponent(in wstring componentNameSpace);
>
A generic namespace facility might be a bit too generic to be the
interface we expose (or we could have a two layer interface where we
have a generic interface and other interfaces built on top of it). It is
not clear how helpful the lower level interface would be compared to
standard DOM, however.

Providing MAL strings is a good idea, but it again seems like we are
mixing different levels of generality on an interface; it is
simultaneously a general purpose interface and also one which, depending
on the namespace given to getComponent, gets something specific to
MaLaES. Also, component might not be a good name since it already used
in CellML to mean something different.

It might be slightly easier for the user if we provide the actual
MaLaESTransform object instead of just the string (this means that
CeLEDS would depend on MaLaES, but that is probably reasonable).

We could similarly have code generation facilities which use all the
available information, although if we did that we would want to do it in
such a way that it is possible to disable CCGS but enable and use CeLEDS
(MaLaES is more general than CCGS, and so there are probably cases where
this makes sense). A clean way to do this could be to have a generic
interface and a MaLaES-specific one, and use another IDL file for the
CCGS specific parts (which would build on the generic interface and
simply convert to procedural code for a given model without the need to
setup any parameters).

Best wishes,
Andrew

> + };
> +
> + interface CeLEDSBootstrap
> + : XPCOM::IObject
> + {
> + /**
> + * Creates a CeLEDS langDefGenerator object from XML language
> definition file.
> + * @param URL URL of XML file to load.
> + */
> + langDefGenerator createLangGenerator(in wstring URL);
> + /**
> + * Creates a CeLEDS langDefGenerator object from XML language
> definition file.
> + * @param XMLText XML file as a string
> + */
> + langDefGenerator createLangGeneratorFromText(in wstring XMLText);
> + /**
> + * Error loading XML file.
> + * If this is set the language generator will be null.
> + */
> + readonly attribute wstring loadError;
> +
> + };
> +
> +};
>
> _______________________________________________
> automated-notifications mailing list
> automated-notifications at cellml.org
> http://www.cellml.org/mailman/listinfo/automated-notifications
>




  • [cellml-dev] r3031 - in CellML_DOM_API/branches/CeLEDS: . CeLEDS CeLEDS/languages CeLEDS/sources interfaces, Andrew Miller, 01/29/2009

Archive powered by MHonArc 2.6.18.

Top of page