Have the specifications for the file formats been published yet? By this I mean the tab delimited or csv or whatever the standard is, not the Dbase format.
Thanks.
Steve
I don’t want to publish a tab-delimited format until I know when I will have time to program handling it. Right now that’s not a high priority, because we have a working upload format (dBase).
Mike Nolan
Mike,
I understand the priorities behind getting applications running smoothly. But as I have mentioned in the past, I do not use Windows, so consequently the programs that do produce the dBase format files do not run on my OS.
Assuming that the same fields will be required in the tab delimited files, can you tell me the order, data type, and length restriction of the fields that are in the dBase files or point me to a site that has that information?
Thanks.
Steve
Steve, would you believe I don’t even HAVE a copy of the dBase standard as it currently exists?
Nobody at the USCF office seems to have a copy of that document anymore or knows where to find the file, mostly because of turnover in the MIS department. (It might be among the 30,000 files on the website, for all I know!)
That makes updating the current format standard more work, because it’s a lot faster to add a few fields to an existing document than to write a new one from scratch. However, if I do wind up having to write a standard from scratch, it’ll probably cover both the dBase and a tab-delimited standard, because both will have the same fields, with the same data restrictions, in the same order.
Now that the old ratings system programming is (in theory) retired from active duty, that might make it a bit easier, because I probably don’t have to document a few ‘features’ of the old file standard.
For example, the section number field is not an integer, it’s a two character right justified LEFT BLANK FILLED field!
The upload program doesn’t care if it’s an integer or a text field, as long as it contains a number from 1 to 99 it’ll work. (Technically, it’d probably handle a number larger than 99, but I’ve never tried creating an upload file to test that.)
There’s a description of the three file structures at:
georgejohn.bcentralhost.com/ … _files.htm
I’m not sure if that’s the current description.
I don’t think the format has been revised since it was first defined, so I think the structure is correct. I’m not as sure about some of the comments, but they’re not as crucial (and some of the usages may have changed anyway), but I think I can use that as a starting point.
Thanks!
Thanks. The link is great.
Now, can anyone send me a sample of the three files from a recent tournament so that I can actually see values entered into these fields. It looks like some are generated by the pairing software and I need to see what format the date fields are actually stored in. I’m pretty sure Open Office can open the dbf files plus Linux/Unix has great string manipulation utilities so I should be able to figure out exactly what is going on.
Thanks in advance.
Steve
coladons@yahool.com
Here’s a hex dump of a sample event with dummy data in all the USCF ID fields using the current format.
In Swiss-Sys, at least, the event ID is filled in using the event ending date and ‘001’ as the last 3 digits. However, the event ID is being changed in the new database (going from 9 digits to 12), and the upload program doesn’t reallly look at that field, as it will generate a unique 12 digit event ID.
(I’m hoping this will display decently here)
I should have something put together with the new fields that are being added to the dBase files fairly soon, possibly later today. I would highly recommend you incorporate those additional fields in any file generating program you write.
---- thexport.dbf ----
0000 03 69 01 10 01 00 00 00 01 02 96 00 00 00 00 00 .i… …
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0020 48 5f 45 56 45 4e 54 5f 49 44 00 43 00 00 00 00 H_EVENT_ ID.C…
0030 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 48 5f 4e 41 4d 45 00 00 00 00 00 43 00 00 00 00 H_NAME… …C…
0050 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #… …
0060 48 5f 54 4f 54 5f 53 45 43 54 00 4e 00 00 00 00 H_TOT_SE CT.N…
0070 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0080 48 5f 42 45 47 5f 44 41 54 45 00 44 00 00 00 00 H_BEG_DA TE.D…
0090 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00a0 48 5f 45 4e 44 5f 44 41 54 45 00 44 00 00 00 00 H_END_DA TE.D…
00b0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00c0 48 5f 52 43 56 5f 44 41 54 45 00 44 00 00 00 00 H_RCV_DA TE.D…
00d0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00e0 48 5f 45 4e 54 5f 44 41 54 45 00 44 00 00 00 00 H_ENT_DA TE.D…
00f0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0100 48 5f 41 46 46 5f 49 44 00 00 00 43 00 00 00 00 H_AFF_ID …C…
0110 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0120 48 5f 43 49 54 59 00 00 00 00 00 43 00 00 00 00 H_CITY… …C…
0130 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0140 48 5f 53 54 41 54 45 00 00 00 00 43 00 00 00 00 H_STATE. …C…
0150 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0160 48 5f 5a 49 50 43 4f 44 45 00 00 43 00 00 00 00 H_ZIPCOD E…C…
0170 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0180 48 5f 43 4f 55 4e 54 52 59 00 00 43 00 00 00 00 H_COUNTR Y…C…
0190 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01a0 48 5f 53 45 4e 44 43 52 4f 53 00 43 00 00 00 00 H_SENDCR OS.C…
01b0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01c0 48 5f 53 43 48 4f 4c 41 53 54 00 43 00 00 00 00 H_SCHOLA ST.C…
01d0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01e0 48 5f 53 45 43 52 45 43 30 31 00 4e 00 00 00 00 H_SECREC 01.N…
01f0 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0200 0d 20 30 35 30 31 30 31 30 30 31 53 41 4d 50 4c . 050101 001SAMPL
0210 45 20 45 56 45 4e 54 20 20 20 20 20 20 20 20 20 E EVENT
0220 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 31 1
0230 32 30 30 35 30 31 30 31 32 30 30 35 30 31 30 31 20050101 20050101
0240 32 30 30 35 30 31 31 36 32 30 30 35 30 31 31 36 20050116 20050116
0250 41 39 39 39 39 39 39 39 4e 4f 57 48 45 52 45 20 A9999999 NOWHERE
0260 20 20 20 20 20 20 20 20 20 20 20 20 20 53 53 30 SS0
0270 30 30 30 30 20 20 20 20 20 55 53 41 20 20 20 20 0000 USA
0280 20 20 20 20 20 20 20 20 20 20 20 20 20 20 4e 20 N
0290 20 20 20 20 20 20 31 1a
---- tsexport.dbf ----
0000 03 69 01 10 01 00 00 00 c1 01 39 00 00 00 00 00 .i… …9…
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0020 53 5f 45 56 45 4e 54 5f 49 44 00 43 00 00 00 00 S_EVENT_ ID.C…
0030 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 53 5f 53 45 43 5f 4e 55 4d 00 00 43 00 00 00 00 S_SEC_NU M…C…
0050 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0060 53 5f 53 45 43 5f 4e 41 4d 45 00 43 00 00 00 00 S_SEC_NA ME.C…
0070 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0080 53 5f 4b 5f 46 41 43 54 4f 52 00 43 00 00 00 00 S_K_FACT OR.C…
0090 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00a0 53 5f 52 5f 53 59 53 54 45 4d 00 43 00 00 00 00 S_R_SYST EM.C…
00b0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00c0 53 5f 43 54 44 5f 49 44 00 00 00 43 00 00 00 00 S_CTD_ID …C…
00d0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00e0 53 5f 41 54 44 5f 49 44 00 00 00 43 00 00 00 00 S_ATD_ID …C…
00f0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0100 53 5f 54 52 4e 5f 54 59 50 45 00 43 00 00 00 00 S_TRN_TY PE.C…
0110 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0120 53 5f 54 4f 54 5f 52 4e 44 53 00 4e 00 00 00 00 S_TOT_RN DS.N…
0130 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0140 53 5f 4c 53 54 5f 50 41 49 52 00 4e 00 00 00 00 S_LST_PA IR.N…
0150 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0160 53 5f 44 54 4c 52 45 43 30 31 00 4e 00 00 00 00 S_DTLREC 01.N…
0170 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0180 53 5f 4f 50 45 52 00 00 00 00 00 43 00 00 00 00 S_OPER… …C…
0190 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01a0 53 5f 53 54 41 54 55 53 00 00 00 43 00 00 00 00 S_STATUS …C…
01b0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01c0 0d 20 30 35 30 31 30 31 30 30 31 20 31 53 45 43 . 050101 001 1SEC
01d0 54 49 4f 4e 20 20 31 46 52 31 39 39 39 39 39 39 TION 1F R1999999
01e0 39 31 39 39 39 39 39 39 39 53 20 33 20 20 20 34 91999999 9S 3 4
01f0 20 20 20 20 20 20 31 55 55 23 1a 1U U#.
---- tdexport.dbf ----
0000 03 69 01 10 04 00 00 00 01 02 4b 00 00 00 00 00 .i… …K…
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0020 44 5f 45 56 45 4e 54 5f 49 44 00 43 00 00 00 00 D_EVENT_ ID.C…
0030 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 44 5f 53 45 43 5f 4e 55 4d 00 00 43 00 00 00 00 D_SEC_NU M…C…
0050 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0060 44 5f 50 41 49 52 5f 4e 55 4d 00 43 00 00 00 00 D_PAIR_N UM.C…
0070 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0080 44 5f 52 45 43 5f 53 45 51 00 00 43 00 00 00 00 D_REC_SE Q…C…
0090 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00a0 44 5f 4d 45 4d 5f 49 44 00 00 00 43 00 00 00 00 D_MEM_ID …C…
00b0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00c0 44 5f 52 4e 44 30 31 00 00 00 00 43 00 00 00 00 D_RND01. …C…
00d0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00e0 44 5f 52 4e 44 30 32 00 00 00 00 43 00 00 00 00 D_RND02. …C…
00f0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0100 44 5f 52 4e 44 30 33 00 00 00 00 43 00 00 00 00 D_RND03. …C…
0110 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0120 44 5f 52 4e 44 30 34 00 00 00 00 43 00 00 00 00 D_RND04. …C…
0130 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0140 44 5f 52 4e 44 30 35 00 00 00 00 43 00 00 00 00 D_RND05. …C…
0150 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0160 44 5f 52 4e 44 30 36 00 00 00 00 43 00 00 00 00 D_RND06. …C…
0170 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0180 44 5f 52 4e 44 30 37 00 00 00 00 43 00 00 00 00 D_RND07. …C…
0190 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01a0 44 5f 52 4e 44 30 38 00 00 00 00 43 00 00 00 00 D_RND08. …C…
01b0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01c0 44 5f 52 4e 44 30 39 00 00 00 00 43 00 00 00 00 D_RND09. …C…
01d0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
01e0 44 5f 52 4e 44 31 30 00 00 00 00 43 00 00 00 00 D_RND10. …C…
01f0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0200 0d 20 30 35 30 31 30 31 30 30 31 20 31 20 20 20 . 050101 001 1
0210 31 31 31 39 39 39 39 39 30 31 57 20 20 20 33 57 11199999 01W 3W
0220 20 20 20 32 57 20 20 20 34 20 20 20 20 30 20 20 2W 4 0
0230 20 20 30 20 20 20 20 30 20 20 20 20 30 20 20 20 0 0 0
0240 20 30 20 20 20 20 30 20 20 20 20 30 20 30 35 30 0 0 0 050
0250 31 30 31 30 30 31 20 31 20 20 20 32 31 31 39 39 101001 1 21199
0260 39 39 39 30 32 57 20 20 20 34 4c 20 20 20 31 42 99902W 4L 1B
0270 20 20 20 30 20 20 20 20 30 20 20 20 20 30 20 20 0 0 0
0280 20 20 30 20 20 20 20 30 20 20 20 20 30 20 20 20 0 0 0
0290 20 30 20 20 20 20 30 20 30 35 30 31 30 31 30 30 0 0 05010100
02a0 31 20 31 20 20 20 33 31 31 39 39 39 39 39 30 33 1 1 31 19999903
02b0 4c 20 20 20 31 57 20 20 20 34 55 20 20 20 30 20 L 1W 4U 0
02c0 20 20 20 30 20 20 20 20 30 20 20 20 20 30 20 20 0 0 0
02d0 20 20 30 20 20 20 20 30 20 20 20 20 30 20 20 20 0 0 0
02e0 20 30 20 30 35 30 31 30 31 30 30 31 20 31 20 20 0 05010 1001 1
02f0 20 34 31 31 39 39 39 39 39 30 34 4c 20 20 20 32 4119999 904L 2
0300 4c 20 20 20 33 4c 20 20 20 31 20 20 20 20 30 20 L 3L 1 0
0310 20 20 20 30 20 20 20 20 30 20 20 20 20 30 20 20 0 0 0
0320 20 20 30 20 20 20 20 30 20 20 20 20 30 1a 0 0 0.
Steve, if you’re trying to produce a dBase3-format file from scratch, the following information might be helpful. It’s the result of some detective work I did (kind of like solving a cryptogram) on the dBase files produced by, and for, pairing software such as Swis-Sys and WinTD. You might want to look at Mike’s hex dumps with one eye, and my comments below with the other eye, simultaneously.
It appears that dBase3 files are divided into five sections, as follows:
(1) First there is a 32-byte overall header record. This record includes such information as record count, record length, and start-of-main-data pointer.
(2) Then there are one or more 32-byte field header records. There is one such record for each field name in the main file. Each field header record includes the name and size of the field.
(3) Then there is a single byte of 0D hex (carriage return), optionally followed by a single byte of 00 hex. (The files from USCF do not include this 00 byte; those produced by Win-TD do.)
(4) The main data records follow, each of length NN, where NN is specified in the overall header record.
(5) The file ends with a single byte of 1A hex (end-of-file marker).
The 32-byte overall header record consists of:
Byte 0: Always 03 hex. I suspect this is a version number, as we are dealing with dBASE3 files.
Bytes 1-3: File date:
Byte 1: File year minus 1900 (0-255, representing 1900-2155 respectively).
Byte 2: File month (1-12).
Byte 3: File day (1-31).
Bytes 4-7: Record count (4 bytes, low byte first). This is the total number of main data records.
Bytes 8-9: Start-of-main-data pointer (2 bytes, low byte first). This points to the byte immediately following the 0D in (3) above, or immediately following the 00 if the 00 is present.
Bytes 10-11: Record length (2 bytes, low byte first). This gives the length of each main data record. All main data records are the same length.
Bytes 12-31: Always 00 hex.
The 32-byte field header records each consist of:
Bytes 0-10: Field name, up to 10 characters, padded with trailing null characters out to length 11 (thus there is always at least one trailing null). Legal characters in the field name appear to be uppercase letters, digits, and underscores.
Byte 11: Always “C” or “D”. I don’t know what this is for. Possibly “D” means numeric and “C” means non-numeric, but it seems safe to always use “C”.
Bytes 12-15: Always 00 hex.
Byte 16: Field size (1 byte).
Bytes 17-31: Always 00 hex.
The main data records consist of a space character (I don’t know why) followed by the values (in character form) for each field. Thus, the sum of the field sizes specified in the field header records, plus one (to allow for the space), will always add up to the record length specified in the overall header record.
I don’t know whether this is helpful, but it could be, at least if you’re a stick-shift sort of programmer, as I suspect you may be.
Bill Smythe
Bill,
Yes it is as I knew there would be a header record(s) for each file but had no clues as to what they would be. I have to thank Mike for the hex dump also.
It would be so much easier if the required fields could be determined and the layout of the file(s) defined. ASCII text files (csv, tab-delimited, etc) are just so much easier to work with.
Thanks.
Steve
A discussion draft is now available for the revised rating report files standard. The draft covers both a dBase and a tab-delimited version.
The URL is:
secure.uschess.org/TD_Affil/fileformat.php
This draft is subject to revision and there is no implementation date for the new format in either dBase or tab-delimited form yet.
Thanks Mike. Just a couple of quick clarifications (tab-delimited).
In the Tournament Header File (THEXPORT) the value for the H_FORMAT field will probably change for a tab-delimited file?
Can you indicate which fields are mandatory. And those that are not can be empty? field1field2field4 would indicate an empty field for field3.
In the Tournament Section File (TSEXPORT), there will be one record for each section in the tournament, e.g. a tournament with three sections, OPEN, U1800, U1500 would have a file containg 3 records.
In the Tournament Detail File (TDEXPORT),
Sorry, I hit the submit button by accident. Here is the complete reply:
In the Tournament Header File (THEXPORT) the value for the H_FORMAT field will probably change for a tab-delimited file?
Can you indicate which fields are mandatory. And those that are not can be empty? field1field2field4 would indicate an empty field for field3.
In the Tournament Section File (TSEXPORT), there will be one record for each section in the tournament, e.g. a tournament with three sections, OPEN, U1800, U1500 would have a file containg 3 records.
In the Tournament Detail File (TDEXPORT), there will be a varying number of records depending on the number of sections and the number of players for each section. The file would have a varying number of fields for each section. So, going along with our 3 section tournament, OPEN having 10 players and 5 rounds, U1800 having 10 players and 4 rounds, and U1500 having 20 players and 4 rounds, there would be a total of 40 records in the file. The records for the OPEN section would contain 10 fields, those for the U1800 and U1500 sections would contain 9 fields.
Am I reading the file format correctly.
Thanks.
Steve
Steve, I don’t see any reason why H_FORMAT needs to be different for dBase and tab-delimited files. The data is the same, and I can tell if it’s a valid dBase or tab-delimited file by checking it.
I’ll flag the fields that can be empty, most of them require data in them.
There should be exactly ONE header record.
The number of section records must be equal to the number of sections indicated in the header record.
The number of detail records must be equal to the number of players in all sections. (Note that if a USCF member has more than one pairing number, he or she also has more than one record in the detail file.)
For the dBase detail file, the number of rounds fields will have to match the largest number of rounds in any section. For the tab-delimited version, the number of fields in a record can vary more easily.
Some of the pairing programs will skip a pairing number if there were no ratable games, such as for no-shows. That’s not permissable at this time.
The program can redo all the data to renumber everyone so that the pairing numbers are consecutive from 1 on, or it can put a dummy ID in for the no-shows.
The ID ‘25000000’ has been set up for no-shows.
Thanks Mike. It looks like I’m pretty much in sync.
Ok
Ok
Yes.
Yes
Yes
This could be done for the tab-delimeted also if required. But it probably makes more sense to just have the number of fields to satisfy the number of rounds.
Ok
So the use of the reserved ID for no-shows is optional?
Great work, Mike!
Steve Coladonato had some good questions. I have a few, too.
For numeric fields, will the USCF software be fussy as to how these are formatted? For example, if there are 5 sections in a tournament, can the H_TOT_SECT field be either “05”, “space-5”, or “5-space”? And in the tab-delimited case, can it be just 5, without the extra character?
Likewise, in the tab-delimited version, for H_CITY could the data be just OMAHA rather than OMAHA followed by 16 spaces?
Along the same lines, if a player’s pairing number is 7, can D_PAIR_NUM be either “7”, “07”, “007”, or “0007”, in each case with an appropriate number of either leading and/or trailing blanks?
In D_NAME, is the space after the comma in “SMITH, JOHN” required, forbidden, optional, recommended, frowned upon, or just what?
Just a little nit-picking – it’s my style, you know. Congrats on making the format available for discussion.
Bill Smythe
Leading and trailing blanks are not required and will be trimmed off if present.
The old dBase format required that section numbers be a two character, left space filled field. The new database doesn’t have that absurd requirement.
For fields coded as numeric, as long as a valid number is present, I don’t care if there are leading zeroes, etc.
The preferred format for names is to have a comma and a space
between the LN and the FN, which is they way they are formatted for the rating supplement files.
However, I will probably tokenize names before checking them, so that JOHN SMITH and SMITH, JOHN will both match if the USCF has SMITH for the last name and JOHN (or even JOHN W) for the first name.
I may even check for reversed FN/LN situations, they’re fairly common.
There must be a valid USCF ID in each detail record. 25000000 has been set aside for no-shows that don’t have a valid USCF ID.
Currently the validation program will complain if a player is not a current member even if there are no ratable games for that person. I need to change that to skip the current membership checking section if there are no ratable games or (more likely) to override the non-current membership error.
Thanks again, Mike, and great work as always.
There is one area where, in my opinion, there is considerable room for improvement – the double round robin.
You have used L for 0 out of 2, D for 0.5 out of 2, and W for 1 out of 2, inventing (or borrowing from Swis-Sys) new symbols for 1.5 out of 2, and for 2 out of 2. There are also new symbols for the forfeit versions of these (forfeit win plus forfeit draw, and 2 forfeit wins).
This seems messy. A better solution seems available, given that, in round robin tournaments, the opponent number is unnecessary.
The D_RNDnn fields are five characters long (e.g. “W0007”). Since only one of the five characters will be used in a round robin, why not simply allow multiple results per field, e.g. “WW” or “WD” or “XX” or “XZ”? That way, you could accommodate not only double round-robins, but also triple, quadruple, and quintuple round-robins, with no proliferation of strange characters and no field-size-overflow problems.
I think this way would have several advantages:
-
It would be more intuitive, and the crosstables would be more human-readable.
-
It would be possible to distinguish individual results. For example, with the existing format W could mean either a win followed by a loss, or a loss followed by a win, or two draws. Likewise, % could mean either win-draw or draw-win. Of course, it makes no difference rating-wise, but could be of interest historically. “GM Browne defeated GM Yermolinsky in the first game, but Yermo got his revenge in the back half of their match.”
-
What happens if the first game is played, and the second is forfeited? Your scheme has no symbol for that possibility, even though it happens all the time. When the National Open blitz event used to be a double round-robin, each year there were several cases where a player, after losing the first game, forfeited the second and dropped out of the tournament. With my proposal, this case is taken care of – “WX” for one player and “LF” for the other.
-
This format would handle triple and quadruple (and even quintuple) round-robins as well as double.
Comments?
Conspicuously absent from the draft standard for the detail file are two fields:
The state of the player and his or her current rating.
I’m not sure if either are worth adding to the standard, since I think having the name will clear up many if not most ID issues.