[Pipet Devel] Another XML proposal - Part 3.

J.W. Bizzaro bizzaro at bc.edu
Wed Mar 31 04:15:30 EST 1999


Humberto Ortiz Zuazaga wrote:
> 
> Yes, I propose a DTD for each kind of relationship, where for example a
> structural alignment could have a structural alignment DTD, and that DTD
> allowed for embedding a multi-sequence alignemnt entity that in turn contained
> several protein sequence entities, structure entities, each protein sequence
> could contain a set of reference entities.  Each entity could be in a
> different DTD.

I am assuming that multiple DTD's doesn't mean multiple files, one per DTD.

> 
> We also need a DTD for page or canvas composition of multiple display loci,
> for embeding a figure in a figure, for example.

Okay.
> 
> The gatekeeper can also handle finding appropriate loci:

Okay, now we _are_ talking about Locus IAB ;-)

> 
> workspace says I have a BICML nucleotide sequence v4.1 object, I want to
> perform a restriction map with these enzymes and see the sizes of the digested
> fragments.
> 
> A tacg locus on server.example.com can reply saying, I can do the analysis,
> please send me the sequence, and the enzymes you want off of this list, to
> view the output you need a locus that can display v3.5 digest files, here is a
> url for a gnome-python locus for a compatible viewer.

That's an excellent point.  I have been assuming that the Workspace will only
use loci (including Locus IAB) that have the appropriate capabilities.  On the
remote end, as with Locus IAB, the programs may be more up to date than those on
the user's machine.

I guess Locus IAB can tell the Workspace (locus database) that is has native
v4.1 capabilities, but can provide a script to handle the older v3.5.  If v3.5
is the only option for the user's version of Loci, it will have to use it (but
it would use v4.1 if at all available).

> Again, we dont have to pass back the UI code, just a URL to it, the workspace
> may well already have a copy locally.

Hmmmm.  Either way, we're still talking about transferring a script.

> I think it's a bad idea to embed the
> python code in the xml.  It violates the principle that the DTDs should stick
> to the point, and it really gets ugly when you consider the security
> implications.

I wasn't talking about anything that would require a DTD, just a marker to say
<thescript> </thescript>.

> Locus will ship with loci for displaying many kinds of DTDs,
> and a site manager may well not allow the workspace to download untrusted
> code.

Security is an issue for executing _any_ code from a remote source, whether or
not it happens to be in the same file as the XML.

> With my proposal, the worspace just has to locate any locus that can
> display the result DTD, you may well have several sequence viewers on your
> machine already.

It's true that there may be more than one locus (viewer) to handle the same
job.  It will be an intresting challenge to get the Workspace to figure this out
without the user's help.

But I don't see how pointing to a URL for the GUI script will be any more
secure.

> That's what I mean. An analysis locus can just say my output is in BICML v3.2
> format, here is the url for a viewer if you don't have one.  The workspace
> then chooses whether or not to retreive the UI code.

Oh.  But how about the UI code is in the same file, as originally planned, but
Loci/Workspace will have a setting to not execute the UI code if it comes from
the Internet or from an unknown URL.

Won't this work too?  I just want to keep everything in the same data stream.

> I argue that all our data structures should be representable as XML.  This
> would let people write loci in any language, export individual components for
> other tools, and facilitate exchange of data.

Add that to my list:

    PAOS -> for active communication about the internals of Loci
    XML  -> for archiving and translating bio data AND LOCI INTERNALS

> 
> Storing data in python specific or binary formats restricts your options.

Yes.

> 
> Hopefully, we'll soon be able to embed Loci figures in our gnome word
> processor papers!

Hmmmm.  I suppose, if someone writes a translator :-)

BTW, I have been including the GNOME API to take advantage of GNOME features
like ORBit and even the GNUmeric spreadsheet, which can be accessed via
ORBit/CORBA.


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



More information about the Pipet-Devel mailing list