EMBOSS 1.12.0

Peter Rice peter.rice at uk.lionbioscience.com
Thu Apr 19 08:02:11 UTC 2001

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

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

> 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 :-)

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

Peter Rice, LION Bioscience Ltd, Cambridge, UK
peter.rice at uk.lionbioscience.com +44 1223 224723

More information about the emboss-dev mailing list