[Pipet Devel] from Justin

[J.W. Bizzaro]

Justin Bradford wrote:
> 
> The benefit is that individual node/tools/components/etc don't ever have
> to worry about parsing XML and making up their own structures to hold
> it. They always get these interfaces. Plus it will make it easy to export
> interfaces (via CORBA or some simpler plug-in interface).

Related to this, I have been thinking about the different XML's needed to markup
all sorts of biodata.  Should Loci have a static set of DTD's for biodata?  What
if someone is working in a more unusual area of biology?  Can new DTD's/XML's be
"plugged" into Loci?

I think if individual loci are responsible for supplying or identifying their
own XML translators, Loci will be much more flexible.

The way I have been developing the Workspace, functional loci are built up from
smaller components.  I mentioned earlier how a command-line can be built by
connecting widgets/forms together.  In the same fashion, an analysis locus will
have to be constructed from smaller components.  What are they?


        Biodata in XML format
                 |
                 |
                 |/
            XML parser (generic?)
                 |
                 |
                 |/
       Translator of biodata
        to CLP usable format
                 |
                 |
                 |/
        command-line program              
                 |
                 |
                 |/
      Translator of CLP biodata
             to XML format
                 |
                 |
                 |/
             XML writer (generic?)
                 |
                 |
                 |/
        Biodata in XML format


These components are represented in the Workspace and can be connected as part
of a WFD.  It is up to the user to put compatible parts together in the right
order.  This is actually locus development, but pre-built loci can be stored and
shared.

The translators are unique and may be the most difficult part to engineer.  The
input translators must know (1) what the input XML/DTD is and (2) what format
the CLP requires.  The output translator works in the opposite manner.  Loci
will actually need a huge collection of translators for it to be very usable;
the more flexible the translator, the better.  Fortunately, like everything else
in Loci, they can be retrieved from a remote repository.

> Also, we can take advantage of Python to make these things more versatile.
> For instance we could have:
> obj1.doc = [NODE, 'foo',
>             [NODE, 'bar',
>              [OBJECT, obj2],    # a reference to another python object
>             ]
>            ]
> 
> obj2.doc = [NODE, 'stuff',
>             [DATA, 'zxzxzxzxzxzx'],
>             ....
>            ]

Are you saying we should have a text file formatted like this, to be parsed by a
Python interpreter?


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