6 ms·
The data format bothers me. Why not use a standard one like JSON?
by chevreuil 12y ago
The data format bothers me. Why not use a standard one like JSON?
- nathancahill 12y agoThe size of JSON files is huge compared to delimited data. Languages like Python make it equally easy to consume delimited data and JSON, so it shouldn't matter much.
- MisterBastahrd 12y agoAt work I built a system to consume feeds of numerous automotive dealer inventories and the easiest to work with is always comma delimited. There are some people out there who have no business building an XML document, and unfortunately I've had to build adapters for many of them. It takes me a few hours to get set up to consume a new CSV feed and a few days for XML, not counting mapping their industry / category / manufacturer data to ours.
- shirkey 12y agoAgreed -- looking at the player data[1], IMO the format type is unrecognizable: ## GK / Goalkeepers Kawashima|Eiji Kawashima, 20 Mar 1983 Nishikawa|Shusaku Nishikawa, 18 Jun 1986 Gonda|Shūichi Gonda, 3 Mar 1989 ## DF / Defenders Inoha|Masahiko Inoha, 28 Aug 1985 G. Sakai|Gōtoku Sakai, 14 Mar 1991 Nagatomo|Yuto Nagatomo, 12 Sep 1986 Uchida|Atsuto Uchida, 27 Mar 1988 Konno|Yasuyuki Konno, 25 Jan 1983 Kurihara|Yuzo Kurihara, 18 Sep 1983 H. Sakai|Hiroki Sakai, 12 Apr 1990 Yoshida|Maya Yoshida, 24 Aug 1988 Masato Morishige, 21 May 1987 ## Japan F.C. Tokyo Comments as a double-hash, key fields are either player last name or occasionally first initial-space-last name, then three different delimiters of pipe, then comma, then tab. Choosing either a consistently delimited format or a more verbose JSON/YAML structure with clear metadata would seem to be a better approach. [1] https://github.com/openfootball/players/blob/master/asia/jp-japan/players.txt https://github.com/openfootball/players/blob/master/asia/jp-...
- wambotron 12y agoThey do have a json web service: http://footballdb.herokuapp.com/api/v1/event/en.2013_14/round/today http://footballdb.herokuapp.com/api/v1/event/en.2013_14/roun...