[moby] [MOBY-dev] Re: Problems with Biomoby services in Taverna 1.2

[Mark Wilkinson]

I agree that the CommonSubs code does not facilitate every possibility
allowed by the MOBY API, but the API should be considered canonical :-)

I think that CommonSubs needs to be **completely** re-written, and in
fact, this was one of the issues that came up at the last meeting - that
we need to have some common implementation-independent API that we can
all code to such that all possible message types can be intuitively
created and unpacked in any language.

Though I don't object to you adding that subroutine to the CVS (I
haven't checked it for sanity, only for intent) I think it would be
useful for us to operate on a higher-level at some point soon and decide
what functions we *need*, and then decide how to build them, rather than
adding functions on an ad hoc basis as we have been so far.

For example, I might be tempted to have a function that built service
responses in the following way:

$OUT = CommonSubs::ServiceOutput->new(some header information - service
provision info goes here);
$OUT->addOutput(invocation_id => $id, simple => $simple);
$OUT->addOutput(invocation_id => $id, collection => \@simples);
$OUT->addOutput(invocation_id => $id2, simple => $simple2);
etc. etc.

That would cover all possibilities and would be more intuitive than the
existing mechanism...

???

He who codes, wins!

M




On Fri, 2005-07-08 at 10:49 +0200, Dirk Haase wrote:
> On Friday 08 July 2005 08:45, Heiko Schoof wrote:
> > Well, if I understand you correctly, Mark, than I was right all along
> > in that they way I see collections is the way they should be seen. Then
> > the problem is that that is not clear enough to everybody else, and
> > that possibly the examples in the API are misleading, because it's been
> > used in such a different way. It's definitely something that needs to
> > be fixed before release 1.0.
> 
> Not only the examples are misleading, actually at least the PERL API is 
> lacking a suitable method to construct an output consisting of several 
> 'Simple's. One can not simply concat the output of multibple 'simpleResponse' 
> calls, as this would create several mobyData blocks.
> 
> In order to fill this gap, I created a new method 'multiSimpleResponse' (see 
> below) within CommonSubs.pm which is more or less identical to 
> 'collectionResponse' except that it obviously leaves out the moby:Collection 
> tag. The provided articleName is put into each 'Simple' tag which should be 
> appropriate.
> 
> Any objections?
> 
> Regards,
> dirk
> 
> =head2 multiSimpleResponse
> 
>  name     : multiSimpleResponse
>  function : wraps a set of simple articles in the appropriate mobyData 
> structure
>  usage    : return responseHeader . &multiSimpleResponse(\@objects, 
> 'MyArticleName', $queryID) . responseFooter;
>  args     : (in order)
>             \@objects - (optional) a listref of MOBY Objects as raw XML
>             $article  - (optional) an articeName for this article
>             $queryID  - (optional, but strongly recommended) the mobyData ID
>                         to which you are responding
>  notes    : as required by the API you must return a response for every input.
>             If one of the inputs was invalid, you return a valid (empty) MOBY
>             response by calling &multiSimpleResponse(undef, undef, $queryID).
> 
> =cut
> 
> 
> sub multiSimpleResponse {
>         my ( $data, $articleName, $qID ) = @_;    # articleName optional
>         my $content = "";
>         $data ||= [];
>         $qID  ||= '';
>         $articleName ||="";
>         unless ( ( ref( $data ) =~ /array/i ) && $data->[0] )
>         {    # we're expecting an arrayref as input data,and it must not be 
> empty
>                 return "<moby:mobyData moby:queryID='$qID'/>";
>         }
>         foreach ( @{$data} ) {
>                 if ( $_ ) {
>                         $content .= "
>                 <moby:Simple articleName='$articleName'>$_</moby:Simple>
>             ";
>                 } else {
>                         $content .= "
>                 <moby:Simple/>
>             ";
>                 }
>         }
>         return "
>         <moby:mobyData moby:queryID='$qID'>
>                 $content
>         </moby:mobyData>
>         ";
> }
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
Mark Wilkinson
Asst. Professor
Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics
iCAPTURE Centre
St. Paul's Hospital
Vancouver, BC