Two good points. Thanks for the quick response.

My response would be that for every platform, there usually is an XML/SAX/DOM library so, lexing, parsing, character encoding, would automatically be taken care of. These libraries are quite easy to use; have you ever tried to read someone else's lexer/parser, much less debug it? Using XML would encourage implementations across the many OS/language platforms while also supporting internationalization.

Extensions could be handled with namespaces. You don't have to worry about issues such as newlines/CR.

I think that many implementation issues would be solved using XML.

Regards, Alan

-----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Sunday, August 12, 2001 12:02 PM To: Cabrera, Alan; GTP Mailing List Subject: Re: [gtp] GTP Goals, ver. 2

For UTF-8 vs. ascii, the beauty of it is that ASCII is a subset of UTF-8 and all non-ascii characters show up as strings of bytes >127 in UTF-8. That means that having the base command set in ASCII but comments in UTF-8 lets people write 100% ASCII lexers if they want, and they only need to worry about UTF-8 if they have non-ascii comments coming in. If they don't care about non-ascii comments looking garbled, then they can write a purely ascii parser and everything works fine.

For XML, my question to you is: how would XML be better than what people are talking about now? XML has a few definite drawbacks (XML is much more complex than what has been discussed here so far, so you would need to use an XML library to parse GTP, and integrating another library into your program always requires more time and work). Usually XML's benefit is that you can deduce the structure of your communication without knowing anything about the content, but in the case of GTP, how would that make our lives any easier?

Cabrera, Alan wrote:

What was wrong with my idea of using UTF-8 instead of ASCII? Also, what about XML? Do you have any thoughts on this or am I way out in left field?

Regards, Alan

-----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Sunday, August 12, 2001 2:15 AM To: GTP Mailing List Subject: [gtp] GTP Goals, ver. 2

OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts...

• I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments."
• I clarified many of the points to say more precisely what they mean.
• I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written.
• I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together.
• A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.)
• Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work.

Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome!

---

GTP Goals version 2

Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform.

1. Usable to play games vs. other programs head to head. If the protocol requires some kind of arbiter, that's OK, but see III.1.
2. Usable for regression tests on programs.
3. Usable for playing go on a server.
4. Usable to write full featured interfaces.

Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.

1. Simple to implement, debug and understand; all commands are ASCII, all human text (comments etc.) is UTF-8, exactly one line per command, each command gets an exactly one line response.
2. Possible to create bridges that let GMP programs play head to head vs. GTP programs in tournaments. Note that GTP and GMP will not necessarily have the same feature set - just the possibility of playing against each other is necessary.
3. There must be a minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement.
4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features.

Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open

source.

1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP).
2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game?
3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other.

Part IV - Additional Programs. These are programs that are not necessary for us to call GTP "done" but would be useful to have publicly available.

1. A sample GTP program that understands all of the commands.
2. GTP bridges for various servers.
3. GUIs and other human-usable front ends so that programmers who write GTP programs can automatically play against their programs, query their programs as to evaluations, etc.
4. A GTP test system/test library to determine whether or not a program is emitting legal GTP.

---