[Nibbles]

Originally Posted by Greg Marra

For TBA, we set scores to -1 to indicate "unknown". I don't think this is a good strategy for the XML format. Maybe a "status" attribute? "future" "playing" "finished"? I am not sure entirely here how much information is too much.
...

We are not confined to integers here, wouldn't a literal "?" work for a played match, but unknown score? It would mean an extra sanity check that would have to be made when parsing the document though. Then again, if you want any support for unknown scores, it is an extra if/then you have to make. Most languages would convert a "?" to 0 or some legal value that doesn't throw an error (atoi in C, and PHP, at the very least), if no support for unknown scores are added.

Originally Posted by comphappy

Why do we not make a standard sqlite database, and then allow data from a standard XML file to be uploaded to it, could be written in java or python and tada its cross compatible magic. I fear inconstancies will stem from duplicate data.

SQLite would work great for this.

This isn't intended as a data storage mechanism, I would suggest reading why I went with XML back in my first post again. A relational database like SQLite also doesn't solve two of the requirements I am addressing: a human readable format, and an extendable format. XML would allow you to add your own data, like how many laps a team made, say, to each team element under an alliance element. To do the same in SQLite you would have to create a new table (how I am planning on doing it for my database), if you wanted to keep the data in a relational format (there are other ways you could store the data, but it wouldn't be a strict relational format).

And listing the teams in an event isn't redundant: it shows the teams that went to an event, regardless of if they played any matches or not. You have the exact same thing in a relational database, a table that links teams to an event.

CREATE TABLE `team_event` (
  `teamnum` int(10) unsigned NOT NULL,
  `eventid` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`teamnum`,`eventid`)
)

Even in a relational database, you have to put in some redundant data from time to time simply to speed things up. It is much faster to keep a column that keeps track of the number of private messages that you have, and update it every time you receive or delete a message, then it is to count every message in your inbox every time you want to know.