Chronological Thread 

< Chronological >      < Thread >

---

Quoting Matt Halstead
<matt.halstead AT auckland.ac.nz>:
> An updated specification for a CellML 1.1 API is available :
>
> http://n2.bioeng5.bioeng.auckland.ac.nz/development/documentation/
> apifiles/APIideas.pdf

Quoting the spec:
> # the cellml version this model conforms to
> CellMLAttributeString cellml_version
Should this be a string? If so, then perhaps we should at least define how
versions are formatted, for example by stating it must be equal to either
"1.1"
or "1.0".
> ...
> # rdf metadata associated with object. Note: the object must have
> # a cemta:id for any RDF to be able to refer to it.
Just a minor nitpick, but still worth fixing before we release a final spec:
"cemta:id" => "cmeta:id"
> ...
> # return the model object this CellML object belongs to
> Model model_object()
As Matt and I discussed last Monday(and I thought agreed upon), cases like
this
should probably be a readonly attribute. Individual language bindings can map
attributes to functions as they desire(so in C++, a readonly attribute would
get mapped to a getter function).

> Model : NamedCellMLObject
> # interface to the manager for loading and keeping track of models.
> ModelManager model_manager
Given that we have agreed that the model manager should be an optional
"additional" module, I don't think it makes sense to reference it from Model.
Perhaps there should instead be a generalised interface where the API requests
a model load starts and ends(which is implemented either by the user or the
API
ModelManager class, and is called by the model API). This interface would need
to support asynchronous model loading(i.e. when the model API wants another
model to be loaded, e.g. an import, it asks the generalised interface to load
it.

Perhaps:
In the core API:

ModelRepresentation: A placeholder for any representation of the model(e.g. a
DOM model, or some way to get Sax events).


ModelLoadObserver
# Called when a model load is complete.
void ModelLoadComplete(CellMLAttributeString URI, ModelRepresentation rep)
# Called when a model load failed.
void ModelLoadFailed(CellMLAttributeString URI, CellMLAttributeString err)

# This is a virtual interface only(implemented by the application or another
# API).
ModelLoader
# Called by the API implementation when it needs to load a model.
# The application may call obs.ModelLoadComplete on the URI before
# returning from this call.
void LoadModel(CellMLAttributeString URI, ModelLoadObserver obs)

Model : NamedCellMLObject
# The model loader. This must be assigned by the application prior to
# instantiating any imports.
ModelLoader loader
...

In the model manager API...
ModelManager : ModelLoader
...

As a general comment about the whole specification, I think we should also
add a
paragraph explaining how close individual language bindings should follow the
specification. For example, details like what ExtensionObject is(I don't
believe that implementations should be forced to make it a valid identifier,
for example, and should instead consider it a placeholder for something the
application defines). A similar situation applies for CellMLAttributeString(as
there are probably types in most languages equivalent to this, and hence it
should merely be a placeholder).

Best Regards,
Andrew


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From matt.halstead at auckland.ac.nz Thu Feb 24 16:31:16 2005
From: matt.halstead at auckland.ac.nz (Matt Halstead)
Date: Thu Feb 24 16:33:33 2005
Subject: [cellml-discussion] Re: [team-cellml] API spec
In-Reply-To:
<1108951421.4219417d638eb AT www.bioeng.auckland.ac.nz>
References:
<7a4cde330b0a698a288abbce99d5674c AT auckland.ac.nz>

<1108951421.4219417d638eb AT www.bioeng.auckland.ac.nz>
Message-ID:
<d3fe445fdc2600c97a415e9cb687d840 AT auckland.ac.nz>


On 21/02/2005, at 3:03 PM, Andrew Miller wrote:

> Quoting Matt Halstead
> <matt.halstead AT auckland.ac.nz>:
>> An updated specification for a CellML 1.1 API is available :
>>
>> http://n2.bioeng5.bioeng.auckland.ac.nz/development/documentation/
>> apifiles/APIideas.pdf
>
> Quoting the spec:
>> # the cellml version this model conforms to
>> CellMLAttributeString cellml_version
> Should this be a string? If so, then perhaps we should at least define
> how
> versions are formatted, for example by stating it must be equal to
> either "1.1"
> or "1.0".

Yes

>> ...
>> # rdf metadata associated with object. Note: the object must have
>> # a cemta:id for any RDF to be able to refer to it.
> Just a minor nitpick, but still worth fixing before we release a final
> spec:
> "cemta:id" => "cmeta:id"
>>

Yes

>> ...
>> # return the model object this CellML object belongs to
>> Model model_object()
> As Matt and I discussed last Monday(and I thought agreed upon), cases
> like this
> should probably be a readonly attribute. Individual language bindings
> can map
> attributes to functions as they desire(so in C++, a readonly attribute
> would
> get mapped to a getter function).
>

Ok, yes, so we should be consistent about this through the spec.


>> Model : NamedCellMLObject
>> # interface to the manager for loading and keeping track of models.
>> ModelManager model_manager
> Given that we have agreed that the model manager should be an optional
> "additional" module, I don't think it makes sense to reference it from
> Model.

Agreed.

> Perhaps there should instead be a generalised interface where the API
> requests
> a model load starts and ends(which is implemented either by the user
> or the API
> ModelManager class, and is called by the model API).

Sure. Though it probably doesn't need to be a public interface now.

> This interface would need
> to support asynchronous model loading(i.e. when the model API wants
> another
> model to be loaded, e.g. an import, it asks the generalised interface
> to load
> it.
>
> Perhaps:
> In the core API:
>
> ModelRepresentation: A placeholder for any representation of the
> model(e.g. a
> DOM model, or some way to get Sax events).
>
>
> ModelLoadObserver
> # Called when a model load is complete.
> void ModelLoadComplete(CellMLAttributeString URI,
> ModelRepresentation rep)
> # Called when a model load failed.
> void ModelLoadFailed(CellMLAttributeString URI,
> CellMLAttributeString err)
>
> # This is a virtual interface only(implemented by the application or
> another
> # API).
> ModelLoader
> # Called by the API implementation when it needs to load a model.
> # The application may call obs.ModelLoadComplete on the URI before
> # returning from this call.
> void LoadModel(CellMLAttributeString URI, ModelLoadObserver obs)
>
> Model : NamedCellMLObject
> # The model loader. This must be assigned by the application prior
> to
> # instantiating any imports.
> ModelLoader loader
> ...
>
> In the model manager API...
> ModelManager : ModelLoader
> ...

Sure, I think this looks good.


>
> As a general comment about the whole specification, I think we should
> also add a
> paragraph explaining how close individual language bindings should
> follow the
> specification. For example, details like what ExtensionObject is(I
> don't
> believe that implementations should be forced to make it a valid
> identifier,
> for example, and should instead consider it a placeholder for
> something the
> application defines). A similar situation applies for
> CellMLAttributeString(as
> there are probably types in most languages equivalent to this, and
> hence it
> should merely be a placeholder).

Sure. The purpose of CellMLAttributeString is to document that Unicode
support is important.

I'll update the document and see where we are at. After that there
probably needs to be a syntax agreed on, I guess the Mozilla IDL?

There are also other issues that need more discussion from the current
spec. I'll try and make individual messages about them.

cheers
Matt


>
> Best Regards,
> Andrew
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion AT cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

---

• [cellml-discussion] API spec, Matt Halstead, 02/20/2005
  • [cellml-discussion] Re: [team-cellml] API spec, Andrew Miller, 02/21/2005
    • Message not available
      • [cellml-discussion] Re: [team-cellml] API spec, Andrew Miller, 02/25/2005

---

Archive powered by MHonArc 2.6.18.