Re: [bufrtables] More on table versions

• To: John Caron <caron@xxxxxxxxxxxxxxxx>
• Subject: Re: [bufrtables] More on table versions
• From: Jeff.Ator@xxxxxxxx
• Date: Wed, 13 Aug 2008 13:22:47 -0400

----- Original Message -----
From: John Caron <caron@xxxxxxxxxxxxxxxx>
Date: Tuesday, August 12, 2008 7:47 pm
Subject: Re: [bufrtables] More on table versions

Interesting example in para 2; we have seen messages that use elements from subsequent versions. I take this to mean that producers aren't always that careful with what version they say they're using. If the message is otherwise well-formed, I hate to reject it. However, immediate feedback to the producer could fix the problem.

True, not all producers are careful with updating their version numbers
when they make changes, so that's definitely something to consider when
deciding how rigorous to be in your own processing.  As far as feedback
to the producer, this can certainly be done, but from my own experience
that doesn't always mean it will get corrected anytime soon, especially
in the case of some remote observing site which may be running software
developed and deployed on some fixed schedule by a separate contract vendor.

I hadn't fully realized that new table C operators are similar to a format change, so the edition number has to increase. Ill have to digest that a bit more.

What I meant was that a new table C operator requires changes to
everyone's BUFR encoding/decoding software in order to be able to handle
it, so in that respect it can be viewed as similar to a BUFR format
change, since they both require changes to the software itself and not
just to the tables.