Author: Anthony Cozzie
Date: 17:22:13 06/09/04
Go up one level in this thread
On June 09, 2004 at 16:41:14, Russell Reagan wrote: >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 > >Regarding move notations, simplicity is paramount. The burden of notation >conversion lies with the GUI. Consider the success of the UCI protocol. I >attribute this mainly to its simplicity. The engine produces moves in coordinate >notation and the GUI handles the conversion to the user's desired format. Any >decent GUI will already have functionality to handle this conversion, so there >is no extra work for the GUI programmers. > >Including every notation under the sun is destined for failure for several >reasons. Either the GUIs will not support it because the added benefit over >existing standards isn't worth the extra work, or they will not add full support >for the standard (which is almost as bad as not supporting it at all, or maybe >worse). > >Standards are useful because they make guarantees. People like guarantees. If >the standard isn't supported, there are no guarentees. In that case, at least >the users know there are no guarentees. If the standard is only partially >supported, now there are no guarentees, but the user doesn't know that, which is >even worse. > >My preference is for a single, simple, unambiguous move notation. This probably >means coordinate notation. It is easy to implement, and any chess program >(engine or GUI) will already support it. Requiring SAN only makes it more >difficult for someone who wants to support your standard. If you want people to >support it, make it easy for them to do so. Realize that parsing long san is exactly the same amount of work as parsing coordinant notation. anthony
This page took 0 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.