Is there an up-to-date DBF file format reference based on the new MUIR implementation? I’ve seen this old reference:
but it seems both incomplete and inaccurate in some areas.
The specific detail I wanted to check at the moment is whether all of the length limits are still accurate, or if any (or all?) fields support more.
Thanks!
There was a minor correction made to the 2C draft format this fall, resolving an inconsistency found during the MUIR testing, but otherwise, neither format has changed in years.
I don’t anticipate any changes to the DBF formats, but I do think there will be an API for uploading events some time later this year.
API for uploading of the DBF’s or uploading the data/json?
Seems like a lot effort diverted towards something that is a nice to have vs something that doesn’t work or is missing?? Though DBFs may be an awkward/outdated format it is a pretty trivial use/format of DBF (and all the existing major players have implemented).
More likely an API with a json data structure than just uploading the 3 DBFs.
I would settle for support for all of the fields in the spec before anything big on the API front. 
The main issue with the DBF’s is that you need a collection of three files to describe a tournament (and, in practice, three files that use the same name convention for each tournament). JSON can combine the header, sections (array of) and player detail (array of with array of games within) into a single file which can easily be given a descriptive name.
Since both WinTD and SwisSys now use JSON for their native files, the amount of work to adapt those to transmit rating reports in JSON would be relatively light. The workload would be higher at US Chess since, unlike DBF, there is a lot of software that can create JSON files which might tempt people to try do-it-yourself rating reports (which would require all kinds of extra steps at the receiving end to make sure the input is valid.)
there are several challenges with accepting JSON formatted results. The structure should be relatively easy to parse, but the data still has to be checked for validity and consistency. That means affiliate, TD and player IDs all have to be valid and current (as of the event), but it also means that if A plays B, then the results and colors need to be consistent. Cross round pairing makes this a bit more challenging, and accepting a true RR structure might be even harder, because that’s not the format in which it will eventually be stored in the MUIR database.
However, most of these validation issues also exist with the DBF format.
I would think the only thing that might be substantially different would be the handling of an open-ended list of TD’s. That could be done in JSON as an array rather than as a long text field. (Though perhaps it might be useful to handle both).
Of course, FIDE’s TRF format has fixed width text columns. (How very 1970’s). Easy to do with FORTRAN, not so much with almost any more modern programming language.
AI is more than happy to manage grunt work of transfer of formats and keep it as more of an abstraction or convert to/from externally. 
Even if the fixed record format has record variants, big/little endian swaps, EBCDIC conversions, and packed/zone decimal conversions, NaN’s – AI doesn’t complain.
I really like the JSON formats for WinTD and SwissSys – pretty easy to extract things that aren’t provided in the UI exports.
One other thing.. Do I need WinTD update (g) to make this work?? Craig
I can’t answer that, but having the most recent version of your pairing program is generally recommended, because it will address recent rule changes, bug fixes, security issues, etc.
When there’s a resolution to the automated access to the supplement files issue, I’m sure the major pairing programs will put out updates quickly to incorporate the new access procedures, whatever they turn out to be.