[Pipet Devel] Another XML proposal - Part 3.

[Humberto Ortiz Zuazaga]

> > Yes, I propose a DTD for each kind of relationship
> 
> I am assuming that multiple DTD's doesn't mean multiple files, one per DTD.

I hope not, but don't know enough about XML yet.

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

Perhaps not.  Say I'm doing an analisis on a locus that returns multiple 
alingments.  I get my results back with the url for a multiple sequence 
viewer, but I already have one installed from a trusted source.  I won't need 
to get a new one.

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

But that's what I mean.  What does <thescript> have to do with describing 
nucleotide sequences?

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

Presumably, any loci shipped with the Locus distribution are safe.

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

No, say I want to view a multiple alignment.  If I have the any appropriate 
display locus already installed from a trusted source, then I won't need to 
execute _any_ remote source.

It's like with HTML.  If I write valid HTML 4.0, then it doesn't matter what 
browser a user views it with, or where he got it from, it's sufficient that 
the user has a compliant browser.

I say all loci should return results that say "This is valid bicml nucleotide 
sequence v4.2"

I don't want a locus to say "Best viewed with Internet Genome Explorer 10.3".

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

No, I specifically think putting the UI code into the data stream is bad.  
After the first time I get the UI, why should I keep downloading it?  Imagine 
having to download netscape everytime you wanted to view a html file.

As a matter of fact, an analysis locus doesn't even have to publish the url 
for a display locus in every result, we can use the AppBroker (can we call her 
the Matchmaker instead? she facilitates the exchange of loci) to keep track of 
where to get a display locus for the results.

So if I write a new analysis locus and want to make it available to the 
community I can publish the location of the analysis locus (source or service) 
and the output formats.  Display loci publish the input formats they support, 
and the AppBroker can make sure your workspace has the appropriate display 
locus, or help you locate one, or find a translation locus that can do the 
conversion for you.

-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz at neurobio.upr.clu.edu