[Pipet Devel] Another XML proposal - Part 1.

[J.W. Bizzaro]

Justin Bradford wrote:

> Although, just so no one is confused, the XML format is really only for
> transfer (data) and storage (both data and Loci info).
> Actual Loci info will be kept in the Paos object as attributes rather than
> an XML stream that has to be parsed all the time. It will be written out
> to XML for non-Paos storage.
> Generic data will always be handled by the Loci framework as XML (since
> it's basically meaningless to it), and the data specific tools will handle
> it internally in whatever way is appropriate (hash table, binary tree,
> etc).

We have gone back and forth on this point.  I just want to leave open the
possibility that "workflow data", which is the "Loci info" you are referring to,
may be _actively_ transferred as XML.

If the workflow data is only for archiving, I guess there is some point along
the pathway where the decision is made to start reading/writing workflow as
XML.  Is this something then that we want turned on and off along the path?

If it is kept "on", it will make for a more robust system, in case of a Loci
crash or OS crash.

Just a thought.

> > I retrieve a nucleotide sequence from Genbank, in genbank format, it
> > is parsed into several XML objects: a nucleotide sequence object, several
> > bibliographic reference objects, a protein sequence object for the
> > "/translation=" feature found in the original genbank file.
> 
> Exactly. I believe the translation component is the gatekeeper, in Loci
> terminology.

The "Gatekeeper" is the "Internet Application Broker" or "Locus IAB".  You're
talking about the "Document Translator" or "Locus DT".  (Don't you love these
names? ;-)  I'd actually like to take on the GenBank translation part of this,
since I made a GenBank parser once.

> 
> > Each xml object is displayed on the benchtop by the apropriate locus.
> > Now I click on the button to perform a restriction map of my sequence.
> 
> I haven't thought about the UI much yet.

Each seperable XML object (biodata) will be displayed on the benchtop...as a box
or button.  And yes, you can click on it (maybe even a right-mousebutton click)
to bring up a list of loci/tools that can perform work on that type of data
(this is where we need a local database of available loci and what they can do).

> 
> > The workspace contacts the restriction map locus, which returns an XML
> > object describing the parameters and options this restriction map
> > locus requires or supports.
> 
> _That_ is an interesting idea. I had just been assuming a generic
> interface for types of loci (for example, a restriction map locus has
> three arguments and it doesn't vary), but rather than having a bunch of
> hardcoded loci types, we can query the locus for it's interface (of course
> we'll want to cache interfaces).

Ohhh yes!  This is the database I was just talking about.  Maybe it's a part of
the benchtop, but it keeps track of all loci available to the user and what they
can do.  But instead of the locus being queried when it is about to be used, it
is queried when it becomes accessible to the workspace.

This is important for hot-plugging loci.  The user can add loci while Loci is
running.  Maybe at a certain time interval, the workspace (database part)
queries all accessible loci, and the loci return values informing the workspace
what they can do.

> 
> > An option handling locus can then prompt
> > me for the enzymes I want to cut with, the output format I prefer,
> > etc.
> 
> Going back to Jeff's idea about embedding python in XML, a locus could
> return an interface description with UI code to handle the query
> configuration (probably optional for exotic cases; most of the time it
> would be generic fields with default UI handlers).

Yep.

> 
> > The restriction map locus can now return the results as several xml
> > objects:  a bibliographic reference object describing the algorithm
> > used to perform the analysis; a result object containing the requested
> > results; a locus object containing the gnome-python source code for
> > a gui-locus that can display the results.
> 
> Before we go overboard with passing interface code around though, I'd like
> to strongly encourage the presence of powerful, high-level widgets in the
> workspace app. We don't want to be passing around a generic sequence
> viewer all the time.

Absolutely correct!  I did not want to be passing 100k Python modules to
recreate common code.  I think we should have high-level widgets that may really
be mostly C-GTK binaries wrapped in Python.  Python-GTK bindings (by James
Henstridge) can be used where the user may not have a particular C-GTK
megawidget in their Loci library.

> 
> > The workspace can check if it already has a gui-locus that can display
> > the results, and pases the results to it, or downloads the code and
> > generates the gui-locus.
> 
> Like I said just above, I'd like to see a nice API (from the loci
> perspective) for the UI stuff. Ranging from low-level building block
> widgets

...PyGTK...

> to higher-level generic viewers,

...C-GTK...

> as well as the ability to plug-in
> additional generic viewers. That way if you're always using some
> non-standard locus gui, you can just load the script locally (and even
> replace it with faster compiled code).

I'm not exactly sure what you mean here.


TO BE CONTINUED....


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro at bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/

I have always appreciated your ability to ________, whenever
there has been a blank to fill.
--