Bioperl: EMBL format without ID/AC/DE/OS

Matthew Pocock mrp@sanger.ac.uk
Thu, 13 Apr 2000 11:07:57 +0100


Hi.

One way to do this would be to parse in a ParseErrorHandler object when
creating the parser (or the tied file handle, or whatever it is now). The
parser would check in a paranoid manner everything that may be incorrect,
and then inform the ParseErrorHandler. The handler would then choose to
correct the problem, throw a warning, throw an exception, or add something
to a log, or whatever. Two implementations of ParseErrorHandler could be
bundled in the distribution - a fixated exception thrower, and one that is
constructed with a user-supplied code-block that will choose what to do. If
the no-args constructor for the parser defaults to using the paranoid
implementation, then existing code will run unaltered.

Does this sound workable?

Keith James wrote:

> >>>>> "Francis" == Francis Ouellette <francis@cmmt.ubc.ca> writes:
>
>     Francis> On 12 Apr 2000, Keith James wrote:
>
>     >> Any objections (philosophical or practical)?
>
>     Francis> a philosophical one (and comment applies to GB or EMBL,
>     Francis> or any format for that matter):
>
>     Francis> I think it is the begining of a very slippery and
>     Francis> dangerous slope to start agreeing to change a format that
>     Francis> 1) is not controled by you 2) is a standard for many
>     Francis> others who expect certain format to work with their
>     Francis> tools.
>
> Absolutely. I certainly wouldn't expect anyone to change their
> expectations of what EMBL or Genbank format should be.
>
>     Francis> An alternative way of thinking about the "let's not make
>     Francis> this ID line mandatory" model, could be to have
>     Francis> user-controled severity failure levels, e.g. "standard"
>     Francis> bioperl would have maximum error level if critical fields
>     Francis> are missing, such as ID, AC, DE, or OS.  But one could
>     Francis> see a system where the bioperl users could set that to a
>     Francis> different level which would not result in a 'fatal error'
>     Francis> (game over), but maybe a 'warning' (beware of results) or
>     Francis> an 'info' (everything is cool) messages. This ould be
>     Francis> explicitly noted, and users would know why.
>
> You expressed this better than I did. The current implementation gives
> fatal errors by default, with no means of relaxing the standard. I
> would like some user control over the acceptable standard along with
> an audit of what's missing.
>
> Keith
>
> --
>
> Keith James  --  kdj@sanger.ac.uk  --  http://www.sanger.ac.uk/Users/kdj
> The Sanger Centre, Wellcome Trust Genome Campus, Hinxton, Cambs CB10 1SA
> =========== Bioperl Project Mailing List Message Footer =======
> Project URL: http://bio.perl.org/
> For info about how to (un)subscribe, where messages are archived, etc:
> http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
> ====================================================================

=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://bio.perl.org/
For info about how to (un)subscribe, where messages are archived, etc:
http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
====================================================================