Re: [Toad-devel] File format for tournament information

[Janne Jalkanen]

Hi ho!

(A short introduction first: I am Janne Jalkanen, a 5 kyu go player
from Finland.  I am a relatively novice tournament director, having
run one 60+ player go tournament this year.)

> I'm neither an expert or big fan of XML, but my feeling is that this is
> exactly the type of data that XML is really useful for. It is very nice to

Yes, I agree that this is *exactly* in the domain of XML.  From a pure
technical perspective, considering anything else than XML for a
storage format would be strange.

For example, you could easily transform the plain XML storage files
into XHTML for web viewing by using a (simple?) XSLT transformation,
without any external applications - something that has actually been
talked about in the Finnish go community with respect to GoWiki (a
bastardisation of my own JSPWiki engine).  It would be immensely
useful to be able to just upload the files onto a WikiPage, and have
them instantly transformed into XHTML code.

However, there are some other limitations, such as compatibility with
previous programs, available code, etc, that might force a different
format.

But I digress.

I think that what we first need is a really solid list of
requirements, prioritized.  Ben has a good start, and let me add a few
of my own ones off the top of my head.

* Compatibility with Gerlach's MacMahon pairing program (essential)
  * Importing and exporting TUR files is going to be important -
    especially if the Toad SW breaks during a tournament.  Before
    that, it may be difficult to convince tournament directors to try
    out Toad, if they have no backup available.

* The ability to ignore any setting (such as nominal rank) during
  pairing.  (useful)

* A *far* better UI than the Gerlach program.  This is something in
  which I can probably be of help in. (essential)

* Portable - The same program should run on a variety of platforms.
  There should *not* be multiple binaries for different systems - let
  the platform provider fight with the portability issues. (essential)
  * Consequently, speed is not really the issue here.

* Some sort of a MacMahon algorithm module (essential)

* Deadline: Mid-Feb 2004.  I have a big tournament coming up :-)
  (tongue-in-cheek-with-a-hint-of-seriousness)

Perhaps it would be useful to establish some sort of a document
repository/slash Wiki for development?  Gathering the requirements
must be done to a central, single location.

I'll come back with some more requirements once I 

As for language?  Well, my first priority is in Java - I have been a
professional Java developer for a few years.  Python I know only a
bit, so my usefulness is lessened somewhat.  But I am not going to
fight strongly one way or the other (except if someone suggests a
Windows-only solution :-) - it is up to the main developer to decide.

-- 
Janne Jalkanen              //!
address@hidden   // !            Faith manages.
         <*>             \X/  !