[Pipet Devel] from Justin

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/
--