All good stuff John. Here's hoping that the proposed solutions are considered and who knows, even implemented.
Unfortunately for Unidata the situation as it exists still requires a workable approach and an easy way for users of the tools published by you to add/update these tables during their own development of models/observing systems. I have, in my own experience, had several groups ask about BUFR and GRIB encoding and how to handle something that's not yet dealt with using WMO published tables. I'm going to be working some with Java NetCDF on setting up what I consider to be a more flexible table handling approach and will be happy to pass that on if I can get it to a publishable standard. :-)
yes, id love to get that, and/or hear more about your plans.
im working on similar things in 4.3, heres the doc i have so far:
One thing missing from your paper is a valid date/time component for each table entry. Both GRIB and BUFR (since edition 3, version 13) allow for updates to existing table entries. One would require an ability to obtain a valid table for the reference time of the data being unpacked since the table may change within a single version published - I know, it's completely the wrong way to do anything like this but that is the reality.
Anyway, here's wishing all of you at Unidata the very best in 2012 and thanks again to you and your colleagues for taking time to interview me last year.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.