NOTE: The bufrtables mailing list is no longer active. The list archives are made available for historical reasons.
Dear Eva and Milan, I must admit I'm confused now. While I certainly agree that it's possible, and perhaps even preferable, to be able to change the characteristics of an existing descriptor when a table version number is incremented, I don't recall that we ever formally agreed to adopt this as the new practice. Eva, I have read your 3.1.1(1) document, and I do recall when we previously discussed the problems of these particular radiation descriptors; however, I don't recall (nor do I see any mention in the final reports from any of our previous meetings?) where we agreed to this change in practice. As you mentioned, in the past we've always kept existing descriptors frozen and just deprecated and replaced them with new descriptors whenever subsequent problems were discovered. And while I certainly remember past instances where we've discussed the shortcomings (e.g. Table B classes rapidly filling up) of this type of approach, I just don't remember where we ever formally agreed to change it. I apologize if my memory on this point is faulty, and if that is the case could you please point me (and the rest of this mailing list as well!) to any relevant documentation? Personally, I have no problem with allowing descriptor characteristics to change between table versions. I do think it is workable and has several benefits, which is probably why I didn't object if/when we did previously agree to this as a group. In my below email I was only trying to describe the current policy (at least as I understood it) to my colleagues on the mailing list. As you mentioned, the big issue involved with changing this would be that the Secretariat would now have to maintain all of the old versions of the tables (and in a machine-readable format! :-) somewhere on the WMO web server. Assuming Joel is agreeable to that, then I believe the majority of my colleagues here in the U.S. would agree to it as well. Thanks and best regards, -JeffMilan Dragosavac wrote:
Dear Eva and Jeff,I think that there is no problem to change data width, reference value and scale for different Master table version numbers of tables used.If we could not do this the whole concept of master table version numbers and local table versions would be meaningless. The only requirement is that once the entry is in any of the tables and used,it must stay as such in that version of the tables. However the only setback is that Secretariat must keep track of all versions even if most entries in the next version is the same as in the previous.That is the way we are going to correct radiation elements in the version 14.Regards Milan Milan Dragosavac ECMWF Shinfield Park, Reading, Berkshire, RG2 9AX, UK Tel: (+44 118) 949 9403 Fax: (+44 118) 986 9450 Telex: 847908 ECMWF G E-mail: milan.dragosavac@xxxxxxxxx Eva Cervena wrote: > Hello Jeff,> > You are right that scale, reference value and data width of a descriptor> cannot be changed between table versions, but these parameters may> be changed with introducing of a new version of the Master Table!!!> It is the reason, why the number of version is included in Section 1.> The information on the time of introduction of the descriptor may be > useful, but it is not essential at all.> > I would like to refer to my Doc. 3.1.1(1), available at > http://www.wmo.int/pages/prog/www/ISS/Meetings/CT-MTDCF-ET- > DRC_Geneva2008/DocPlan.html, where a change of data> width and reference value of several descriptors from Class 14 is> proposed to be introduced with a new table version. And this document> has been already discussed and you did not express any objections to> the proposed approach.> > Up to now, however, this ability of BUFR has not been much used,> i.e. the out-dated descriptors were deprecated and replaced > by new ones. Using this approach, the management of the tables > is simplified and only the last tables may be implemented in the SW. > But the deprecated element descriptors may be included in several > D-descriptors and these would have to be also deprecated, and soon> we would end up with saturated tables full of deprecated descriptors.> > With regards,> Eva> > Dr Eva Cervena> Czech Hydrometeorological Institute>
bufrtables archives: