Bioperl: EMBL format without ID/AC/DE/OS
Sat, 15 Apr 2000 13:47:32 +0100 (BST)
On Thu, 13 Apr 2000, Matthew Pocock wrote:
> 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?
It does actually, but I bet you left keith behind as to what precisely to
do in terms of the perl to write. I'll chat to keith next week about how
to do this...
> Keith James wrote:
> > >>>>> "Francis" == Francis Ouellette <email@example.com> 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 -- firstname.lastname@example.org -- 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:
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://bio.perl.org/
For info about how to (un)subscribe, where messages are archived, etc: