Author: Robert Hyatt
Date: 13:19:10 06/09/04
Go up one level in this thread
On June 09, 2004 at 13:44:25, Andrew Wagner wrote: >I wanted to respond to some common themes I saw in responses on this thread. > >1.) Regarding the readability of the XML. First of all, one of the scripts I >will write will convert the XML back to PGN. So there will be complete backward >compatibility there. If you like the PGN format, you can easily transform it >back to that. Secondly, remember that the idea of XML isn't to look nice. And >let's face it: How often do you really "read" PGN? You may look at the first few >moves of a game or whatever, but generally if you look at a PGN you're trying to >extract specific information. In this case, you can quickly and easily extract >that information by switching the transformation script to show whatever you're >trying to extract. The idea is to stuff all the information you can squeeze into >the XML file and let the transform scripts and whatever else is parsing it worry >about all the formatting stuff. By the way, by the time this is done, I'll >probably write my own C/C++ based XML parser with the idea of making it easily >portable to other programs. Assuming the interest is there. > >2.) Several have said that they dislike the algebraic format and would like to >see support of it discontinued. I don't understand this. What makes more sense >to me is to support both algebraic AND other notations. At least in the format. >Then you can write your parser to do whatever you want. The idea is MORE >flexibility, not less. For example, which is correct? "a2-a4" or "a2a4"? Is one >really better than the other? I'd personally prefer to allow either, and let the >transformation script figure it out. So a move might look like this: > ><Move PlyNum="3" Format="Algebraic"> > <MoveText>Nf3</MoveText> > <Time>1:02:33</Time> ></Move> > >Or a move list might look like this: ><MoveList Format="Algebraic"> 1.e4 e5 ...</MoveList> > >That's what I'm thinking, anyway. Of course, majority rules. I'm well aware that >for this project to succeed it has to be what the programmers want, so I am very >interested in any and all suggestions. Andrew Why not think about this in the reverse way: The moves have a single internal to XML format, but then they can be converted to anything someone wants. I personally prefer SAN because that is how books and things are published, excepting those that use figurine notation. But let's not allow XML to be all things to all people. Let's make it a standard with appropriate conversion utilities so that someone requiring the brain-dead e2e4 notation can extract the games in that format and use them... If we don't pick a single internal standard, then this isn't going to work, because I too will write my own parser, and I don't want to deal with multiple move formats. If I don't like what is being used, I want a tool that will convert to what I want. And since everyone will not agree on a single format, let's pick one for the standard and give conversion tools to make everyone happy. Parsing SAN is _not_ hard. There is public code to do that in the epd kit as well as inside Crafty itself. Since the PGN standard specifies algebraic and allows SAN as well, that seems like a reasonable start (note that Algebraic is the Ng1f3 type moves, not just g1f3) that is sometimes needed to resolve ambituities in SAN moves.)
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.