EMBOSS 1.12.0

[David Martin]

On Thu, 19 Apr 2001, Peter Rice wrote:

> David Martin wrote:
> >For full record keeping a full record should be kept. This can easily be
> >parsed out by any vaguely competent unix hack and allows for proper
> >traceability.
>
> Although we do also need to consider the user who will want to read the
> output. An option to skip (or to limit the size of) the header, definable
> by an environment variable (or .embossrc configuration) can keep them happy
> though.

EMBOSS_FORMAT fasta
does this for sequences. There is no reason why the default output cannot
be 'classic' (or for die-hard MS shops, 'powerpoint' or 'msword97'). XLST
looks to be very easy to do. Just write a suitable style sheet and add it
to the local implementation. It would even allow the data to be
checksummed and watermarked if required.. (but the end admin can implement
this quite easily if given a standard output to work with).


For an automated run where the data needs to be
warehoused and traceable the system can add another command line option
for post processing. It also allows remote operation of EMBOSS programs
with the end format being determined at the users point of contact.


>
> > Most of the DTD's out there are crap. I would go with one of our own to
> > start with. If designed well this can easily be transformed into any
> > format desired (HTML etc.) thus removing from the application writer the
> > need to cope with every possible format. A post-process transformation
> > can allow the user to specify an XSL stylesheet of choice (or DSSSL if
> > that route is chosen).
> >
> > If EMBOSS follows the following scheme:
> >
> > ACD parse
> >    V
> > Do the Science
> >    V
> > Generate output in XML (full record)
> >    V
> > Transform to the users desired form
> >
> > Then you can have the 'classical' form of output ie plain text,
> > HTML, short XML output, full (untransformed) output, SQL, MS Word (only
> > kidding), graphical output in whatever form (How about moving EMBOSS
> > graphics from PL_PLOT to SVG?)
>
> MS Word? That was originally planned - output files were going to have
> titles and headers and paragraphs so they could be written as plain text,
> HTML or RTF but the print functions were never implemented. Would be easy
> to do though :-)

Then dump it to XML, use XSLT to generate the various formats.

If EMBOSS can generate premade powerpoint slides of the output then it
really is on to a winner (because scientists are lazy beasts..)

>
> > This is not really very different to what happens with sequences which
> > have their own internal representation and are transformed to the required
> > format on output.
>
> Yup, that's what output reports will be for. A limited number of output
> formats for features, alignments, and so on - with the chance to choose the
> format you like best.
>

Indeed, with extensibility for local customisation so I can generate an MS
Word document with local crest, font, format etc should I so desire, or a
web page, or LaTeX output, or have it automatically generate a tutorial
script that shows the command line used and all the prompted options as it
would appear when driven from the comamnd line, or SQL to go straight into
the LIMS system, or email to the user, or ...

All down to the creativity of the admin who is working with a documented
output format for which there are plenty of tools available to do the
work. (EMBOSS still doesn't support BoulderIO format for sequences a la
primer3.)


..d