[MOBY] Re: [MOBY-dev] MOBY 0.49 API online... nearly stable!

[Mark Wilkinson]

On Thu, 2003-04-03 at 11:05, Martin Senger wrote:
> "In BioMOBY, there are three catagories of input/output parameters..."
> 
>    Suggestion: call in consistentlly 'input/output data' (as also used
>    in other places of the APi document(

okay.


> "There are two forms of Primary parameter (...Simple...Collection)"
> 
>    It confuses me. Does it mean that a service can have more input
>    parameters, each of them can be a collection? In that case why do
>    you allow to have different types in one collection? Or does it
>    mean that a service can have only (zero or) one primary parameter
>    which can be a collection? In such case the variatey of element types
>    is reasonable.

I agree, I should add a couple of sentences explaining it; it is implied
in the example, and it is clear in the XML for service registration, but
I never state it as clearly as I should:  A "collection" is considered a
single piece of input data, but that single piece of input data is
composed of many objects.  A 'simple' input is a single object.  There
can be any number and any combination of simple and/or collection data
inputs to a service.

> "There is currently only one form of Secondary input"
> 
>    Can a service have more that one secondary input? It should
>    have. Why there is no collection of them? Generally speaking, I
>    would not make difference between primary and secondary data (or
>    parameters, whatever you decide to call them) in their structures. The
>    difference should be in their usage (for example, the secondary data
>    are not used for the service discovery). Why not to make it simpler
>    and why not to have the same structure for both - with just a single
>    attribute specifying this is primary and this is secondary?

There is no equivalent of a "collection" for Secondary inputs, though as
with the Primary inputs, there may be any number of Secondary inputs to
a service.


> "the authority (service provider URI)"
> 
>    I suggest to use consistently only one term (authority, service
>    authority, provider, service provider,...).

I need to spend more time in general explaining what we mean by
"authority", as it might be confusing to many people... especially since
we assign authority to a transformation rather than a datatype.

> "expandObjects: this flag will cause MOBY Central to traverse the
> Class ontology to find services that operate not only on the Object
> Class you are querying, but also any parent types or sub-objects of
> that Object Class."
> 
>    Are you sure that this is correct? It seems to me that using this
>    flag will return *all* services because all data types inherit from a
>    base type 'Object'. So a service operating on 'Sequence objects'
>    operates also on 'Object'. But perhaps it's enough to say where the
>    traversal ends.

In practice it doesn't return all services (as we know from the existing
MOBY prototype, which already has this functionality).  The reason is
that a service provider registers themselves as a consumer of complex
objects, and the ontologly traversal only goes "up", so unless you are
registered as a consumer of more simple objects in the path of the
traversal you will not be discovered.

it does, however, return a whole lot more services than one might
expect!  We know that from experience also ;-)   As a consequence, one
of the critical functionalities in any client will have to be a way to
present these services to the user in some coherent manner.

 
> "The Query object structure is as follows:
>    <inputObjects>
>       <Input>
>          <!-- one or more Simple or Complex Primary Parameters -->
>    </Input>"
> 
>    Do I really need to include the whole Parameter definition? On
>    another place the API says that I can query "by name from the Class
>    ontology". It seems better to me.

Well... effectively you are querying by Class name, since the only
things in a Simple parameter is Class name and optional namespace...

I'm just trying to re-use object structures as much as possible to make
client design simpler.

 
> "registerService...all elements except secondaryParameter are required"
> 
>    Why? I can imagine a service without any inputs (or using only
>    default inputs). For example, "show me, what you have".

hmmm... that's a service type that i had never considered...  I'll have
to think about that.

> "findService
>     * There are additional details..."
> 
>    Missing link with additional details.

i haven't written them yet :-)


> "Output XML (by category):
>      moby: 
>          <Service>
>               <![CDATA[WSDL document here]]..."
> 
>    A WSDL document is a valid XML piece - therefore is there any
>    reason why to wrap it in a CDATA? We had this discussion already
>    about embedding the XSD and it seemed to be resolved. You may
>    remember that CDATA around the XML document may cause interoperability
>    problems.

right.  copy/paste error.

 M