Chronological Thread 

< Chronological >      < Thread >

---

Hi all,

I am looking for some input on how we bootstrap the CellML implementation. At
present, there is no way of loading URLs to get the initial model.

CORBA may or may not be involved when calling:
1) Calling the API directly from C, or using the C API in C++, or across a
non-CORBA interface to some language.
2) Calling the API across CORBA.

Also, the DOM may or may not be involved, as the API does not have anything
specific to DOM in it(although this implementation is built on top of the
DOM).

At some point, we are obviously going to need to do something different
between
these different situations(for example, a way of getting hold of the DOM, and
creating the model from the DOM). However, it seems to be desirable to
maximise
consistency between situations.

There are some existing technologies we need to consider:
1) DOM level 3 Load and Save, which is a W3C Recommendation. This provides a
mechanism to convert an XML document to a DOM, and vice versa. We would, of
course, still need a way to get the CellML document from the DOM.
2) The CORBA naming service. If you can get hold of the CORBA naming service
object, you can then pass in the name of the object(which in this case would
be
some interface which can then create CellML documents). Of course, you still
need to get the CORBA naming service object, so this may be an unnecessary
layer of complexity.


When CORBA is involved, the way that the initial non-CORBA negotiation is
performed differs depending on how the system is being used. We could use an
interface like this:
interface CellMLBootstrap
: XPCOM::IObject
{
oneway void ready(in ModelLoader ml);
};
which is implemented by the application, and used to pass the ModelLoader when
it is ready(this would make sense if, for example, the CellML API process was
being started at the request of the application). In other situations, we may
be able to publish the IOR string for an object, and users can then use this
IOR to load documents as required. Alternatively, we could publish the IOR for
the naming service, and have the ModelLoader at a standardised location in the
ModelLoader.

>From C, all we really need is a constructor function, perhaps to get hold of
>a
ModelLoader class.

However, what ModelLoader should support is unclear. It would probably be
specific to the DOM(or Sax, or whatever other API to the document is being
used) version, and need to provide ways of loading DOM documents, and creating
models from DOM documents. In the CORBA case, we probably don't want to force
the DOM documents to reside in the same POA as the model, so we need a way for
the API to ask the application to provide it with a DOM Document for an
import.

Best regards,
Andrew Miller


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From ak.miller at auckland.ac.nz Fri Aug 12 16:15:55 2005
From: ak.miller at auckland.ac.nz (Andrew Miller)
Date: Fri Aug 12 16:15:58 2005
Subject: [cellml-discussion] Model loader interface
Message-ID:
<1123820155.42fc227b89ea7 AT www.bioeng.auckland.ac.nz>

As discussed at the last CellML meeting, here is my draft of the interfaces
for
loading CellML documents:

module cellml_api
{
/**
* An interface for loading a CellML model by URL.
*/
interface ModelLoader
{
/**
* Loads a model from the given URL, using the local URL loader.
* Note that this operation may be unavailable(or restricted to certain
* URLs) due to security restrictions on some remotely hosted model
* loaders.
* @param URL The URL from which to load the model.
* @return The loaded CellML model.
* @raises CellMLException if the model cannot be loaded.
*/
Model loadFromURL(in dom::DOMString URL)
raises(CellMLException);


/**
* An error message describing the cause of the last CellMLException.
* The error message is formatted code/param1/param2/.../paramn
* Valid error codes are...
* noperm (The user does not have permission to load URLs of this kind).
* badurl (The URL was malformed).
* servererror/info A server error occurred. Info is an optional, method
* specific parameter, and for HTTP it should be the server error
number.
* badxml/line/column/msg The XML was malformed. Line an column give the
* location in the file at which the error occurred. msg is the message
* from the processor stating what is wrong.
* notcellml The model did not have a cellml::model document element in
* either the CellML 1.0 or CellML 1.1 namespace.
*/
readonly attribute dom::DOMString lastErrorMessage;
};

/**
* A DOM specific interface for loading a Document by URL.
*/
interface DOMURLLoader
{
/**
* Loads an XML formatted document from a given URL into a DOM. This may
* be restricted to certain URLs due to security restrictions on some
* remotely hosted URL loaders.
* @param URL The URL from which to load the document.
* @return The loaded document.
* @raises CellMLException if the model cannot be loaded.
*/
dom::Document loadDocument(in dom::DOMString URL)
raises(CellMLException);

/**
* An error message describing the cause of the last CellMLException.
* The error message is formatted code/param1/param2/.../paramn
* Any error message the application desires may be placed in
* lastErrorMessage and it will be passed on to other API
* lastErrorMessage attributes.
*
* An API provided implementation may return the following error message
* types:
* noperm (The user does not have permission to load URLs of this kind).
* badurl (The URL was malformed).
* servererror/info A server error occurred. Info is an optional, method
* specific parameter, and for HTTP it should be the server error
number.
* badxml/line/column/msg The XML was malformed. Line an column give the
* location in the file at which the error occurred. msg is the message
* from the processor stating what is wrong.
*/
readonly attribute dom::DOMString lastErrorMessage;
};

/**
* A DOM specific interface for loading a CellML model with more control.
*/
interface DOMModelLoader
: ModelLoader
{
/**
* Loads the DOM for the model from the specified URL using the supplied
* DOMURLLoader. If further URLs need to be loaded(for example, to satisfy
* imports), the supplied loader will be used.
* @param url The URL from which to load.
* @param loader The URL loader to load the model and any imports needed.
* @return The loaded model.
* @raises CellMLException if there is an error loading the model or the
* DOM document.
*/
Model createFromDOM(in dom::DOMString url, in DOMURLLoader loader)
raises(CellMLException);
};

/**
* A DOM specific interface that provides everything an application needs to
* bootstrap the CellML API.
*/
interface DOMBootstrap
{
/**
* The model loader used to load models.
*/
readonly attribute DOMModelLoader modelLoader;

/**
* The local DOMImplementation. This may not always be available, and when
* it isn't, nil should be returned.
*/
readonly attribute dom::DOMImplementation domImplementation;

/**
* The local URL loader. This may not always be available, and when
* it isn't, nil should be returned.
*/
readonly attribute DOMURLLoader localURLLoader;
};
};

Any comments would be welcome.

Best regards,
Andrew Miller


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From ak.miller at auckland.ac.nz Fri Aug 26 16:35:05 2005
From: ak.miller at auckland.ac.nz (Andrew Miller)
Date: Fri Aug 26 16:35:06 2005
Subject: [cellml-discussion] RDF API
Message-ID:
<1125030905.430e9bf9047f4 AT www.bioeng.auckland.ac.nz>

Hi all,

I have been looking into RDF APIs that we could use to provide the placeholder
cellml_api::RDF. Unfortunately, there has never been any API recommended by
the
W3C, although there are a number of different APIs in use. The Mozilla one
seems
to be the only one I can find the uses IDLs to define the API.

Does anyone have any opinion on how we should go about manipulating RDF?

Best regards,
Andrew Miller


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From matt.halstead at auckland.ac.nz Fri Aug 26 17:05:33 2005
From: matt.halstead at auckland.ac.nz (Matt Halstead)
Date: Fri Aug 26 17:05:48 2005
Subject: [cellml-discussion] RDF API
In-Reply-To:
<1125030905.430e9bf9047f4 AT www.bioeng.auckland.ac.nz>
References:
<1125030905.430e9bf9047f4 AT www.bioeng.auckland.ac.nz>
Message-ID:
<2A730386-5C50-44E2-B318-D8F661442836 AT auckland.ac.nz>


On 26/08/2005, at 4:35 PM, Andrew Miller wrote:

> Hi all,
>
> I have been looking into RDF APIs that we could use to provide the
> placeholder
> cellml_api::RDF. Unfortunately, there has never been any API
> recommended by the
> W3C, although there are a number of different APIs in use. The
> Mozilla one seems
> to be the only one I can find the uses IDLs to define the API.
>
> Does anyone have any opinion on how we should go about manipulating
> RDF?

Yes, we leave it as XML fragments for now and deal with it when we
come to thinking about handling metadata. We are likely to want to
add a CellML specific API for metadata based on either RDF schemas,
or OWL ontologies. The CellML metadata editor does have an interface
for handling the metadata, and that might be a good place to review
some of this when the time comes.

cheers
Matt



>
> Best regards,
> Andrew Miller
>
>
> ----------------------------------------------------------------
> 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] Bootstrapping the CellML implementation, Andrew Miller, 08/11/2005

---

Archive powered by MHonArc 2.6.18.