[Pipet Devel] embedding queries in XML

[Carlos Maltzahn]

On Sun, 24 Jan 1999, J.W. Bizzaro wrote:

> > This is a lightweight approach to marking up data so that it can be passed
> > from app to app.  It is not a very formal approach, but it has been used to
> > coordinate some very large sequencing efforts.
> 
> I like what was suggested by someone on the team earlier, that the XML file
> can contain a list of queries to be performed and already performed.  In that
> sense, the XML files say "This is where I'm going.  And this is where I've
> been.  Can you help me?"  So if the player who catches the basketball doesn't
> know where to throw it to, he can read the name of the recipient and sender
> right off of the ball.

This sounds like a workflow system to me. Except the agents are now tools
instead of office workers.

> Why would a locus get an XML file it wasn't intended to get?  Maybe this idea
> is best suited for a router system.  Can each locus be a router?  Each one
> _should_ be.  Even if a locus was intended to get the data and do something
> with it, if the next step is to send the data somewhere else, it should know
> where to send it.

Again, this sounds like nodes in a distributed workflow system. Exceptions
can occur in each node and depending on the presence on matching exception
handler the node knows where to send the data next - or just raise a flag
and say "I don't know what to do with this, help me!" 

> Maybe the list of queries/commands can be put into the XML from the GCL
> Benchtop, at the start of the analysis.  This way, the GCL won't have to
> control every step.  Each locus won't have to ask the GCL where it should go
> next.  The XML data will know the path.
>
> Once again, I'm not sure how this would work with Paos.  Can you enlighten us
> Carlos?  Can an XML object be treated as a mobile object with a mission?

I assume that an XML object is an intermediate result in the execution of
some composition of analysis tools, correct? If you want to add XML
objects as agents who can actively seek their next tool, you need to
provide the environment to do that (there is a Python module that offers a
safe execution environment for such mobile objects). Those execution
environments would be like special shells that receive XML objects and
execute them. From the view point of Paos these shells would be Paos
clients. They submit status information to one or more Paos server and
receive notifications that either control the execution of tools or modify
the content of XML objects (such as routing information). Other clients of
Paos are GCL editors and monitors that visualize the whereabouts and
status of these mobile XML objects.

So I see Paos as control and monitoring infrastructure for shells which
receive and send XML objects from/to other shells and start and feed tools
according to these XML objects. I think you call these shells analysis
loci (correct?). But you could use the same shells as visualization loci. 
For me a visualization loci is just another glyph in a GCL construct. To
the user the only difference to an analysis loci is the fact that it
usually runs fairly local to the user and calls a tool that shows up as
a Gnome application that visualizes data.

Let me know whether this sounds right. 

Carlos