I was wondering if there is any future plans of a Webservice, XML or some kind of “hook” into the MSA?
Since I have the luxury of having web at my tournament locations, I’ve been using the MSA’s latest published ratings for my tournaments.
It would be neat to be able to have an “update” from the site prior to these events would be great!
Could the USCF run a weekly file dump to some file format to be downloaded?
Well, I was thinking that we should still use the Golden Database in SwissSys for biographical info on players and verifying USCF membership. However, couldn’t we hand over-ride the rating as per MSA? I run my tourneys in a computer room, so I also have internet access during events.
On another note, would it be so terrible to allow OTB rated events to use peer-to-peer software to simulate the chessboard and clock? I have more PCs than boards and clocks so this would help my club a lot!
I do this now for unrated events to accomodate more club members. We run Linux in the PC lab so we use xboard or eboard.
Regards,
AJG
I enjoy having the latest list, however, sometimes I get into a hurry and while searching for a player on MSA to see if they have the latest rating and an up-to-date membership, I might select on a player with the same last name thinking it’s them, and defaulting it to their USCF number.
But having the latest membership information might be the most important reason for getting this functionality going.
There’s going to be a new version of the rating supplement files released fairly soon.
This will be a unified format that combines the information currently in the supplement update file and the Gold Master file into a single standard.
This way when we issue a ratings supplement file, in addition to those members whose rating has changed since the last supplement we can also include new unrated USCF members, renewing members, etc. We will also be able to indicate USCF ID’s that are no longer active because of such things as duplicate ID’s and deceased members.
We will continue to release supplement files using the current file format for as long as necessary.
There should be a new Gold Master with the August supplement data available fairly soon. (This time it will be in the proper Gold Master format. It has already been tested with Swiss-Sys and I hope to have the testing with WinTD completed in the next day or two so that it can be posted this week.)
That’s great news!
Sounds like you guys are on the right track.
Hi Mike:
I doubt I am the last director that still uses a dial-up connection. I hope you can find a way to limit the size of the new suplement update format to something under 1-2 MB after being zipped.
Regards, Ernie
I don’t know that I can promise that. The combined format has a few more fields in it than the current supplement format does, and I"m also increasing the length of the player name field, because limiting it to 17 characters causes too many truncations. (For example, the suffix field, which contains JR and SR, does not always fit.)
Also, if the intent is to include renewals as well as those with updated ratings, the number of records in a typical supplement update will go up, which means the size of the file will go up too.
The best solution would be to only include the fields that are needed.
dBase doesn’t support records with variable numbers of fields. XML would, but to be honest the overhead for XML is much greater than that for the dBase format, so I don’t know if we would save any space.
A tab-delimited format would probably be the most space-efficient, especially of there was a record type indicator.
Possible record types might include:
A. An updated rating but no change in membership information
B. An updated rating including membership information
C. Updated membership information only
D. A change in status, such as a duplicate ID or a deceased member
Another possiblity would be dynamic updates, where you indicate the date of your last update and the computer generates a file that has only the records you need to get current again.
However, that is not something that is likely to get implemented soon, it would go on the ‘nice to have’ list, not on the ‘must have’ list, and I don’t expect to get to the niceties until late October or November, at best.
Maybe you could use field type indicators instead of record type indicators, at least for the dynamic updates.
Since name and ID would (I assume) always be there, they could occupy the first 2 field positions and would not require a field type indicator. Other fields could be present only where information has changed. For these other fields, the scheme could go something like this:
A – regular rating
B – previous regular rating
C – quick rating
D – previous quick rating
E – expiration date
F – state
G – ID has changed, see XXXXXXXX
H – deceased
For example, a member’s record might look like this:
Doe, John (tab) 12345678 (tab) A1800 (tab) B1799 (tab) FNE
– which would mean that John Doe’s regular rating has changed from 1799 to 1800, that he is now from Nebraska, and that other information (quick rating, expiration) has not changed.
Or:
Doe, John (tab) 12345678 (tab) G13579246
– meaning that John Doe’s incorrect ID of 12345678 has now been corrected to 13579246.
Or:
Morphy, Paul (tab) A2800 (tab) H
– to indicate that Morphy had a 2800 rating but is now deceased.
Bill Smythe
I think you need to be careful because adding one or two fields will increase the filesize substantually.
1 field could change a dialup download a few minutes.
But I love the idea of having as much data as possible available. Having a personal best would be great to have for stat junkies like myself.
Any step forward for this is a great step in the right direction. Hopefully SwissSys and WinTD will put out updates to accomidate these quickly.
Will each field be atomic ? e.g. the current files have ratings fields which contain a /nn when the rating is provisional. Pairing software needs to parse this field in order to retrieve only the rating value. I don’t use Windows so SwissSys, et al, is not an option but there is software available that will read standard flat files.
As for the record type indicator, you would have to grep out the records you need into another file. Can’t the different record types be stored in different files?
Steve