Author: Russell Reagan
Date: 13:41:14 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 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.
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.