Author: Robert Hyatt
Date: 10:26:38 09/10/03
Go up one level in this thread
On September 09, 2003 at 18:33:22, Steven Edwards wrote:
>Greetings:
>
>It was some ten years ago back in 1994 that the CDS (Chess Data Standards: SAN,
>FEN, EPD, and PGN) took their current form after months of newsgroup discussions
>and megabytes of email exchange. Prior to the adoption of the CDS, the exchange
>of chess data and the interoperatabilty of chess softawre was greatly impeded by
>the lack of standards and the prevalence of secret and non-free proprietary
>formats.
>
>Although the CDS are now used by (nearly) all archives and all programs, it does
>not mean that the current form of the standards is the best. Certainly there
>are places where extensions can be made and where unneeded items deprecated and
>eventually deleted. To make a revision work, there is a requirement for input
>from the experienced chess programmer community just as there was such a need
>ten years ago. Therefore, I once again issue the call for online (here in CCC)
>and email discussion on the CDS topic. (Including "CDS" in the subject line
>helps in this process.)
>
>Here are some of my ideas:
>
>SAN: Looks fine; I don't see any need for changes. There is the possibility to
>extend the piece identfier letter semantics to accommodate heterodox /
>unorthodox chess.
>
>
>FEN: One deficiency exists for which I take responsibility; the en passant
>target square semantics should indicate a non null value only if an active color
>pawn attacks the passed-over target square. A change here will improve position
>database operation and can also have a positive effect on internal transposition
>management. Also, there is the possibility of extending the castling
>availability semantics to accommodate heterodox / unorthodox chess.
>
>
>EPD: There are several items of concern:
>
>1. Currently, the first four EPD fields match the first four FEN fields. This
>was done to save space with the idea that the "hmvc" and "fmvn" EPD operations
>could provide the extra information if needed. This is rather arbitrary and I
>suggest that every EPD record have the same first six fields as a does a FEN
>record. Alternatively, EPD opcodes can be defined for the (current) first four
>EPD fields and so there would be NO required fields at the start of an EPD
>record.
>
>2. Representations of string/symbolic data in operands is inconsistent with
>respect to the need for quoting. This is also the case with PGN tag values. A
>uniform rule is needed for both.
>
>3. Representations of time and date value operands needs to be formalized along
>with a provision for sub-second decimal resolution.
>
>4. The centipawn evaluation operand type needs a mate score indication
>correction.
>
>5. The centipawn evaluation operand type probably needs to be deprecated and
>replaced with a pawn evaluation operand type with a provision for sub-pawn
>decimal resolution.
>
>6. The time control operand type needs to be extended and formalized. PGN has a
>problem with this as well.
>
>7. A formal XML schema could be useful. Likewise for PGN.
>
>8. Removal of record length limitations.
>
>9. Explicit support for 64 bit integer values (decimal and hexadecimal) as
>operands.
>
>10. Inclusion of progam-to-program comand protocol opcodes.
>
>
>PGN: Again, several areas need re-examination.
>
>1. Adding the Broket Form to the movetext. A broket form is a single EPD
>operation delimited by angle brackets ("brokets"). This is a far better
>approach to embedding metadata than the cuurent use of comments.
>
>2. Deprecation of the use of a period of each White move number. The use of a
>period here has little, if any, need and just consumes space.
>
>3. Removal of all mention of "canonical representation". It was an attempt to
>support matching PGN movetexts based on simple string comparisons. Unneeded.
>
>4. Formalization of the PGN tag name set, including any PGN tag names that have
>become popular "in the wild" and deprecating those which are rarely, if ever,
>used.
>
>5. Formalization of PGN tag value semantics. Part of this includes the use of
>"*" to indicate an unknown value, just as it already does for a game result.
>
>6. Removal of the binary representation standard. This is unneeded as the use
>of fast and portable text compression tools is now commonplace.
>
>7. Adding some kind of formal way of representing attributes for aggregates af
>PGN game data.
One thing I really dislike is resumption of moves. IE
23. e3 (some comment) then 23... black's next real move. The "..." looks
ugly. In many old annotations, the better form 23. ... black's move makes more
sense.
But in any case, nn... is ugly...
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.