PGN upddate and revisions
Steven Edwards
Hash: SHA1
Greetings all:
This is Steven Edwards, author of the Portable Game Notation Standard,
and I am now using chessn...@earthlink.net as my PGN related
e-mail address. You may verify the PGP signature on this article as
an assurance of its authenticity.
I am now re-activating my participation in chess standards development
as I feel that, after some eight years of usage, the PGN standard and
related formats have gained more than sufficient acceptance in their
current forms. So now it is time to discuss possible extensions and
perhaps a few depreciations.
==========
A side comment of broket notation in PGN move text: broket notation is
an exact mapping to EPD records. In an EPD record, the piece position
field, the active color field, the castling availability field, and
the en passant file field are the first four fields of each record.
These fields are followed by zero or more operations that further
describe the position. A broket form is the same as an EPD record
except that:
1) The first four fields of the EPD record are taken from the current
position context of the movetext and so do not appear in the broket
form;
2) The broket form is delimited by a leading "<" character and by a
trailing ">" character;
3) The broket form may extend over multiple lines.
So, the EPD specification is isomorphic to the PGN broket form
specification.
==========
As always, PGN must be free for all to use. Also, it has to retain
its portability across platforms and its independence from any
particular commercial vendor.
I will be monitoring this newsgroup for PGN articles and have my
newsreader flag any such that have "PGN" in the Subject line.
Similarly, I will have my mail client file all e-mail with "PGN" in
the Subject line for later review.
== Steven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
iD8DBQE86sKZWaTbH3GWUQURAo5yAJ0cBzUP9OjdFEkI9A9vzhfgtOd8vQCcCltL
Xr5SQJ56bPcJM84QlO4aZ9Y=
=vKHe
-----END PGP SIGNATURE-----
Paul Onstad
Howdy Steven, good to have you back, and good that any future changes to PGN
should have a public audience.
-Paul
Steven Edwards
Hash: SHA1
As Paul Onsted wrote, it is important that future revisions to PGN
must include a public discussion period. In fact, those of you who
were reading the chess newsgroups back in the 1992-1994 time frame
will recall the many polls and extensive discussion articles. I
personally received uncounted hundreds, perhaps thousands of e-mails
on the chess standards topics; I read every one of them and replied to
most.
I would ask that, as before, those wishing to assist in the effort
should carefully consider their requests for features. It is
important for the standard to be accepted, so there is motivation to
try and keep the majority of users satisfied. However, this does not
mean that neo-PGN (I'm thinking about a release with software in early
2003) is to become a oversized standard with intenal overlaps and
difficult to reconcile feature sets. Many of us in the professional
computer science world have served on various standards committees and
most of us can recall the frustration at the difficult to avoid
feature creep that only adds to baroque and bloated implementations.
==========
There is one change to the FEN (Forsyth-Edwards Notation) position
description standard that I now endorse, one that was suggested by a
number of users and implementors. This is the fourth field of the FEN
record, the en passant target square. Currently, this field is either
the single character "-" (indicating no en passant target square), or
a two character square coordinate (e.g., "e3" or "c6"). If the field
content is a target square it is (in the current standard) always the
vacant square passed over by a double square pawn advance on teh
immediately previous move. This remains true in the FEN change except
that no target square appears (a "-" appears instead) if there is no
legal en passant capture in the described position. I have tested
this change extensively in a number of application contexts and it
significantly increases efficiency in applying hash coding for
transposition tables and external position databases.
Note that the fourth field of a FEN record is the same as the fourth
field of an EPD record, so the change applies there as well.
==========
A minor emendation of the broket form: as reported earlier, a broket
form is simply zero or more EPD operations delimeted by brokets (angle
brackets). However, the last EPD operation in a broket form does not
require a terminating semicolon. This is different from an EPD record
where each EPD operation including the last one (if present) requires
a terminating semicolon. A BNF refresher:
EPD-record ::= fixed-fields [operation-sequence] // all on one line
fixed-fields ::= ppd actc cast epsq
ppd ::= {piece placement data}
actc ::= w|b {active color; side to move}
cast ::= {castling availability}
epsq ::= {em passant target square}
operation-sequence ::= operation [operation-seqence]
operation ::= opcode-mnemonic [operand-sequence] ;
operand-sequence ::= operand [operand-sequence]
The EPD fixed fields are exactly the same as the first four (of six)
FEN fields. An opcode mnemonic is any one of the standard set of EPD
opcode names. The format of an operand vaies according to the types
accepted by a particular EPD opcode and in some cases, the position of
the operand in the operand sequence.
== Steven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
iD8DBQE86uL1WaTbH3GWUQURAqaOAKCFEXmxznvcaAkV40J/+rtQxUOvaQCg3/vp
fRsS6rvs6O+gIjzEHTkB4UY=
=iYdP
-----END PGP SIGNATURE-----
Dann Corbit
A depth-in-plies analyzed field. Crafty calls it acd. Hiarcs calls it dep.
It is not codified by the standard, and it would be very nice to have.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm
The Drunken Lord
Steven Edwards
"Dann Corbit" <dco...@connx.com> wrote:
> Requested extension for EPD:
> A depth-in-plies analyzed field. Crafty calls it acd. Hiarcs calls it dep.
> It is not codified by the standard, and it would be very nice to have.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The "acd" opcode means "analysis count depth" and is the correct
mnemonic to use to measure depth of analysis.
There is probably going to be some work required for a unification of
the various EPD opcodes.
== Steven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
iD8DBQE86wlQWaTbH3GWUQURArWAAJsEZAq1ca2ClcICni6FsR01U+pGBQCgqcSe
2w9LKYHeT3LpnZNKCNz36u4=
=3CJs
-----END PGP SIGNATURE-----
Paul Onstad
> <snip> Many of us in the professional
> computer science world have served on various standards committees and
> most of us can recall the frustration at the difficult to avoid
> feature creep that only adds to baroque and bloated implementations.
That has been my observation too. No standard can handle all contingencies
and stay in character. Any change pushing the limit should be weighed of
it's necessity--not simply because it can be done.
> There is one change to the FEN (Forsyth-Edwards Notation) position
> description standard that I now endorse, one that was suggested by a
> number of users and implementors. This is the fourth field of the FEN
> record, the en passant target square. Currently, this field is either
> the single character "-" (indicating no en passant target square), or
> a two character square coordinate (e.g., "e3" or "c6"). If the field
> content is a target square it is (in the current standard) always the
> vacant square passed over by a double square pawn advance on teh
> immediately previous move. This remains true in the FEN change except
> that no target square appears (a "-" appears instead) if there is no
> legal en passant capture in the described position. I have tested
> this change extensively in a number of application contexts and it
> significantly increases efficiency in applying hash coding for
> transposition tables and external position databases.
It was only recently that I realized and made this same improvement to my
original parser.
PGN has served the chess community very well but I'll add my one (mostly
moot, and in hindsight) criticism which applies to Event and Site. First of
all, and in my opinion, they were misordered. Early on a lot of damage was
done to games by taking the traditional tournament line (Site/Event) and
separating it. At that time, even the largest databases had severe
restrictions on data length (to save indexing) and we ended up with many
scores with place names of little else but "It." (It could have been
"London.")
Since that time, the indexing problem has been solved but now Event and Site
are either duplicated--or put fully in Event. This is the natural outcome of
the ordering but quite misleading.
If ever a chess standard were to approach this situation again, I almost
think going back to the combined form would be better. The problem that
tends to prevent "correct" use is of course searching.
-Paul
Ed Seedhouse
<chessn...@earthlink.net> wrote:
With all due respect, and I don't by any means intend this as a
criticisism of your or anyone else's past efforts, I think it is time
to "bag" pgn and move on to a more universal standard. I think the
obvious, and probably best, way to go at the present time is to XML.
So I think you should consider developing a good XML schema for Chess,
and possibly even the development of a true chess markup language
using XML. Then we need to work on getting it adopted as a standard.
Once again I am not meaning to criticise "pgn" or the effort people
put into developing it, for which effort I am truly grateful.
Paul Onstad
>
> On Wed, 22 May 2002 00:16:28 GMT, Steven Edwards
> <chessn...@earthlink.net> wrote:
>
> With all due respect, and I don't by any means intend this as a
> criticisism of your or anyone else's past efforts, I think it is time
> to "bag" pgn and move on to a more universal standard.
Perhaps, and except for 9,999 games out of 10,000.
>I think the
> obvious, and probably best, way to go at the present time is to XML.
Is that the one Microsoft likes? That would be my first reason to avoid it.
I don't believe there should be any "language" involved as they're changing
constantly and, in time, many become extinct.
Multibyte character sets OTOH, like the original ASCII build from the bottom
up and have a future. They can be converted to ASCII with simple
calls....just like RTF. They could even appear much like the PGN we are used
to.
In the meantime, PGN, just as it is....the basic product, is going to be
around a long time to come. Most of us don't want our chess with two dozen
computer-generated comments after every move. When I encounter those things,
it means there's a NORMAL32 run coming up to strip them.
-Paul
Guy Macon
Ed Seedhouse <eseed...@shaw.ca> wrote:
>With all due respect, and I don't by any means intend this as a
>criticisism of your or anyone else's past efforts, I think it is time
>to "bag" pgn and move on to a more universal standard. I think the
>obvious, and probably best, way to go at the present time is to XML.
>
>So I think you should consider developing a good XML schema for Chess,
>and possibly even the development of a true chess markup language
>using XML. Then we need to work on getting it adopted as a standard.
A google search on "XML" and "Chess" turns up a lot of work that has
already been done.
From: http://www.oasis-open.org/cover/chessML.html
"Chess Markup Language (ChessML) design motivation: "...there is the
well documented, non proprietary and very intuitive PGN format
['Portable Game Notation'] for chess which can be imported and
exported by almost all chess databases and chess programs. PGN
itself uses the ECO Codes as an internal encoding scheme for different
chess openings. ECO Codes in PGN are an equivalent to ENTITIES in
XML. Also XML documents usually are very easy to understand (if its
DTD is 'good'). But PGN does not provide any of the features of a
markup language like XML or SGML. So it is natural to look for an
implementation of PGN in XML. Indeed ChessML is an extension of
this idea. It uses the rich structure of XML and so it has many
more capabilities than PGN itself.""
From http://www.saremba.de/chessgml/
and http://www.saremba.de/chessgml/why.htm
"Chapter 4. What's wrong with PGN?
It may be a bit surprising that I'm going to assert that PGN has major
deficiencies although I stated earlier that it has been the decisive
factor for the fast spreading of chess games on the Internet. This only
appears to be a contradiction:"
"Everyone would agree that PGN is a simple format. Is it really? PGN
is easy to read for humans, but for computer software it's only
syntactically simple. For processing the moves of a game (written
in SAN, Standard Algebraic Notation), a program needs to know about
the semantics, i.e. the rules of the game. This is usually taken for
granted, but the consequence is that it excludes most standard software
from processing PGN. (Don't believe me? Give Winword a PGN file and
tell it to produce long algebraic notation with figurines, with a
diagram added after every 5th move. Hey, this would be a nice challenge
for a VBA hacker contest!)"
"In general, no piece of software that was not specifically designed
for the processing of PGN and chess moves can do anything reasonable
with a PGN file."
"If you have wondered what was meant by the term conceptual framework
you will now see that the lack of such a framework for PGN constitutes
a major deficiency. For example, the PGN standard is talking about
things like handling of the newline character (section 3.2.2),
lexicographical issues (section 4), tokenizing (section 7) etc.
All these topics have nothing to do with chess, and therefore they
should be handled where they belong: by specialized, basic standards
that do nothing else but dealing with these topics."
"Talking about these things in the definition of a chess-specific
format is not only a cosmetic mistake; it implies that you cannot
base your chess-specific software on a general library that implements
these basic standards, but you have to hand-craft everything on your
own. This is not only an inconvenience for programmers of chess
software but – more importantly – prevents more demanding features
from being implemented."
"Just in case you don't believe me, let's take an example: the
deplorable situation of incorrectly spelled names in PGN. There is
no German grandmaster called Robert Huebner; his last name is Hübner.
Interestingly, this correct spelling would even be possible with PGN.
The German umlaut ü ist character 228 in the ISO-Latin1 character set,
and the standard states (in section 4.1)"
"«PGN data is represented using a subset of the eight bit ISO 8859/1
(Latin 1) character set. ... the 64 code values from 192 to 255 are
mostly alphabetic printing characters with various diacritical marks;
their use is encouraged for those languages that require such
characters.»"
"But because PGN does not have a foundation consisting of appropriate
base standards, there is no generally available, cross-platform
software support for the handling of these characters in PGN. In
consequence, the whole chess world is effectively limited to what
the English-speaking subset of mankind considers to be characters
– which is a very narrow view from the perspective of this subset's
complement."
"It's even worse with characters outside the ISO-Latin1 set. Rumours
are that a few chessplayers on this planet still read and write
cyrillic. For these people, PGN even falls short on its own design
criteria which include the statement:"
"«The system must be international. Chess software users are found in
many countries and the system should be free of difficulties caused
by conventions local to a given region.» (Section 2.2)"
"PGN is not free of these difficulties but instead introduces them –
not for the computer, but for the humans."
"Talking about the lack of a sound foundation formed by standards that
are more general and wider in their approach, another problem comes
to mind: PGN's complete lack of any concept of structure or hierarchy.
Yes, you can put several games into one PGN file that can be
arbitrarily long – but what is that good for? There is no method
whatsoever to build larger units like, say, all games of a tournament,
a team event or a collection of a master's games. Neither is there any
possibility to add text describing a tournament, a round, a game or
something else."
"As an example, look at the PGN files distributed by Mark Crowther in
The Week in Chess: They contain masses of games of several tournaments
(many of them in their entirety), but without any structure, with the
descriptive text being relegated to an external (ASCII or HTML) file.
Would you accept a printed chess periodical to separate the tectual
content from the games in a comparable fashion? Such a labour of
love deserves a better and more expressive data format."
"To summarize the statements made above, let me state my central
assertion:"
"PGN is deficient by design, because it is not embedded in a larger
conceptual infrastructure; this applies to theory (related and
supporting standards) as well as to practice (standard software tools
that would deal with the syntactical details and leave only the
semantic aspects to chess software)."
"The conclusion is that PGN is a dead end and cannot be used as a
basis for a future, more powerful standard"
***************************************************
I picked a couple of XML chess games as examples.
The first is feature-poor but quite readable.
The second has lot's of features but is really
quite awful as afr as human readability is
concerned. I think we can do better.
Here are the examples:
http://www.oasis-open.org/cover/chessML.html
<?xml version="1.0" encoding="ISO-8859-1" ?>
- <chessgame event="IBM Kasparov vs. Deep Blue Rematch" site="New York, NY USA" date="1997.05.03" round="1" white="Kasparov, Garry" black="Deep Blue" opening="Reti - King's Indian attack, Keres variation" result="1-0">
- <move>
<white>N g1-f3</white>
<black>P d7-d5</black>
</move>
- <move>
<white>P g2-g3</white>
<black>B c8-g4</black>
</move>
- <move>
<white>P b2-b3</white>
<black>N b8-d7</black>
</move>
- <move>
<white>B c1-b2</white>
<black>P e7-e6</black>
</move>
- <move>
<white>B f1-g2</white>
<black>N g8-f6</black>
</move>
- <move>
<white>O-O</white>
<black>P c7-c6</black>
</move>
- <move>
<white>P d2-d3</white>
<black>B f8-d6</black>
</move>
- <move>
<white>N b1-d2</white>
<black>O-O</black>
</move>
- <move>
<white>P h2-h3</white>
<black>B g4-h5</black>
</move>
- <move>
<white>P e2-e3</white>
<black>P h7-h6</black>
</move>
- <move>
<white>Q d1-e1</white>
<black>Q d8-a5</black>
</move>
- <move>
<white>P a2-a3</white>
<black>B d6-c7</black>
</move>
- <move>
<white>N f3-h4</white>
<black>P g7-g5</black>
</move>
- <move>
<white>N h4-f3</white>
<black>P e6-e5</black>
</move>
- <move>
<white>P e3-e4</white>
<black>R f8-e8</black>
</move>
- <move>
<white>N f3-h2</white>
<black>Q a5-b6</black>
</move>
- <move>
<white>Q e1-c1</white>
<black>P a7-a5</black>
</move>
- <move>
<white>R f1-e1</white>
<black>B c7-d6</black>
</move>
- <move>
<white>N d2-f1</white>
<black>P d5-e4 x</black>
</move>
- <move>
<white>P d3-e4 x</white>
<black>B d6-c5</black>
</move>
- <move>
<white>N f1-e3</white>
<black>R a8-d8</black>
</move>
- <move>
<white>N h2-f1</white>
<black>P g5-g4</black>
</move>
- <move>
<white>P h3-g4 x</white>
<black>N f6-g4 x</black>
</move>
- <move>
<white>P f2-f3</white>
<black>N g4-e3 x</black>
</move>
- <move>
<white>N f1-e3 x</white>
<black>B c5-e7</black>
</move>
- <move>
<white>K g1-h1</white>
<black>B e7-g5</black>
</move>
- <move>
<white>R e1-e2</white>
<black>P a5-a4</black>
</move>
- <move>
<white>P b3-b4</white>
<black>P f7-f5</black>
</move>
- <move>
<white>P e4-f5 x</white>
<black>P e5-e4</black>
</move>
- <move>
<white>P f3-f4</white>
<black>B h5-e2 x</black>
</move>
- <move>
<white>P f4-g5 x</white>
<black>N d7-e5</black>
</move>
- <move>
<white>P g5-g6</white>
<black>B e2-f3</black>
</move>
- <move>
<white>B b2-c3</white>
<black>Q b6-b5</black>
</move>
- <move>
<white>Q c1-f1</white>
<black>Q b5-f1 x+</black>
</move>
- <move>
<white>R a1-f1 x</white>
<black>P h6-h5</black>
</move>
- <move>
<white>K h1-g1</white>
<black>K g8-f8</black>
</move>
- <move>
<white>B g2-h3</white>
<black>P b7-b5</black>
</move>
- <move>
<white>K g1-f2</white>
<black>K f8-g7</black>
</move>
- <move>
<white>P g3-g4</white>
<black>K g7-h6</black>
</move>
- <move>
<white>R f1-g1</white>
<black>P h5-g4 x</black>
</move>
- <move>
<white>B h3-g4 x</white>
<black>B f3-g4 x</black>
</move>
- <move>
<white>N e3-g4 x+</white>
<black>N e5-g4 x+</black>
</move>
- <move>
<white>R g1-g4 x</white>
<black>R d8-d5</black>
</move>
- <move>
<white>P f5-f6</white>
<black>R d5-d1</black>
</move>
- <move>
<white>P g6-g7</white>
</move>
</chessgame>
From http://www.saremba.de/chessgml/
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE game PUBLIC "-//A.Saremba//DTD chessgml//EN" "chess.dtd">
<!-- $Id: Rubinstein-Teichmann.xml,v 1.4 2000/03/12 22:39:53 sar Exp $ -->
<game type="chess" variant="classic">
<gameinfo round-nr="12">
<eventinfo>
<event>Großes Internationales Schachmeister-Turnier</event>
<site>Karlsbad</site>
</eventinfo>
<date day="05" month="09" year="1907"/>
<opponents>
<white>
<player>
<person cbuffId="Rubinstein Akiba">
<surname>Rubinstein</surname>
<firstname>Akiba</firstname>
</person>
</player>
</white>
<black>
<player>
<person cbuffId="Teichmann Richard">
<surname>Teichmann</surname>
<firstname>Richard</firstname>
</person>
</player>
</black>
</opponents>
<result res="1-0" why="resigned"/>
</gameinfo>
<moves ply-count="45">
<mp><m c="w"><p c="w" n="p"/><d2/><d4/></m>
<m c="b"><p c="b" n="p"/><d7/><d5/></m>
</mp>
<mp><m c="w"><p c="w" n="n"/><g1/><f3/></m>
<m c="b"><p c="b" n="p"/><e7/><e6/></m>
</mp>
<mp><m c="w"><p c="w" n="p"/><c2/><c4/></m>
<m c="b"><p c="b" n="n"/><g8/><f6/></m>
</mp>
<mp><m c="w"><p c="w" n="b"/><c1/><g5/></m>
<m c="b"><p c="b" n="b"/><f8/><e7/></m>
</mp>
<mp><m c="w"><p c="w" n="n"/><b1/><c3/></m>
<m c="b"><p c="b" n="n"/><b8/><d7/></m>
</mp>
<mp><m c="w"><p c="w" n="p"/><e2/><e3/></m>
<m c="b" spec="0-0"><sq n=""/><sq n=""/></m>
</mp>
<mp><m c="w"><p c="w" n="q"/><d1/><c2/></m>
<m c="b"><p c="b" n="p"/><b7/><b6/></m>
</mp>
<mp><m c="w" capt="1"><p c="w" n="p"/><c4/><d5/></m>
<m c="b" capt="1"><p c="b" n="p"/><e6/><d5/></m>
</mp>
<mp><m c="w"><p c="w" n="b"/><f1/><d3/></m>
<m c="b"><p c="b" n="b"/><c8/><b7/></m>
</mp>
<mp><m c="w" spec="0-0-0"><sq n=""/><sq n=""/></m>
<m c="b"><p c="b" n="p"/><c7/><c5/></m>
</mp>
<mp><m c="w"><p c="w" n="p"/><h2/><h4/></m>
<m c="b"><p c="b" n="r"/><a8/><c8/></m>
</mp>
<mp><m c="w"><p c="w" n="k"/><c1/><b1/></m>
<m c="b"><p c="b" n="r"/><f8/><e8/></m>
</mp>
<mp><m c="w" capt="1"><p c="w" n="p"/><d4/><c5/></m>
<m c="b" capt="1"><p c="b" n="r"/><c8/><c5/></m>
</mp>
<mp><m c="w"><p c="w" n="n"/><f3/><d4/></m>
<m c="b"><p c="b" n="n"/><f6/><e4/></m>
</mp>
<mp><m c="w" capt="1"><p c="w" n="b"/><d3/><e4/></m>
<m c="b" capt="1"><p c="b" n="p"/><d5/><e4/></m>
</mp>
<mp><m c="w"><p c="w" n="n"/><d4/><b5/></m>
<m c="b"><p c="b" n="b"/><b7/><a6/></m>
</mp>
<mp><m c="w"><p c="w" n="q"/><c2/><a4/></m>
<m c="b" capt="1"><p c="b" n="b"/><a6/><b5/></m>
</mp>
<mp><m c="w" capt="1"><p c="w" n="n"/><c3/><b5/></m>
<m c="b" capt="1"><p c="b" n="b"/><e7/><g5/></m>
</mp>
<mp><m c="w" capt="1"><p c="w" n="p"/><h4/><g5/></m>
<m c="b"><p c="b" n="r"/><e8/><e7/></m>
</mp>
<mp><m c="w"><p c="w" n="r"/><d1/><d4/></m>
<m c="b"><p c="b" n="q"/><d8/><a8/></m>
</mp>
<mp><m c="w"><p c="w" n="p"/><b2/><b4/></m>
<m c="b"><p c="b" n="r"/><c5/><c8/></m>
</mp>
<mp><m c="w"><p c="w" n="n"/><b5/><d6/></m>
<m c="b"><p c="b" n="p"/><b6/><b5/></m>
</mp>
<mp><m c="w" capt="1"><p c="w" n="n"/><d6/><c8/></m>
</mp>
</moves>
<setofcomments lang="de">
<source>Georg Marco (Turnierbuch)</source>
<comment type="m" nr="7" where="aft" c="w">
<text>Von <playerName>Marshall</playerName> mit Vorliebe angewendet, ist
dieser Zug in neuer Zeit
auch von anderen Meistern oft versucht worden, zuweilen in Verbindung
mit baldigem <m c="w" spec="0-0-0"><sq n=""/><sq n=""/></m>.
Daß die lange Rochade für Weiß
nichts Bedenkliches an sich hat, gilt längst als ausgemacht. Man gewinnt
diese Überzeugung u.a. aus dem Studium der Partien
<playerName>Dr. Tarrasch</playerName> – <playerName>Schlechter</playerName>
(Ostende 1907) oder aus der 4. Wettpartie <playerName>Rubinstein</playerName>
– <playerName>Teichmann</playerName> (Wien 1908).
</text>
</comment>
<comment type="m" nr="7" where="aft" c="b">
<text>“Die beste Verteidigung”, sagt <playerName>Schlechter</playerName>
(“Deutsche Schachzeitung” 1908,
Seite 10) “ist doch wohl <m c="b"><c7/><c5/></m> nebst Besetzung
(nach <m c="b"><b7/><b6/></m> und
<m c="b"><p c="b" n="b"/><c8/><b7/></m>) der c-Linie,” Gerade dies
strebt aber <playerName>Teichmann</playerName> an. Es müßte
also gezeigt werden, warum seine
Zugfolge ungünstig sei und welche Reihenfolge vorzuziehen wäre.</text>
</comment>
<comment type="m" nr="8" where="aft" c="w">
<text>Auch an dieser Stelle mag <playerName>Schlechters</playerName> Geist
zitiert werden: “Wenn Weiß
die Absicht hatte, lang zu rochiren, so hätte er besser diesen Abtausch
unterlassen, denn nach <m c="w" capt="1"><c4/><d5/></m>
erlangt Schwarz durch c7–c5–c4 nicht nur die Majorität der Bauern
am Damenflügel, sondern auch einen Königsangriff.”</text>
</comment>
<comment type="m" nr="10" where="aft" c="w">
<text><playerName>Schlechter</playerName> bemerkt hier ohne Angabe von
Gründen, daß
<mp nr="10"><m c="w"><p c="w" n="r"/><a1/><d1/></m></mp>
sehr in Betracht komme. Wahrscheinlich glaubt er, daß nach
<mp nr="10"><m c="b"><c7/><c5/></m></mp>
<mp nr="11"><m c="w" capt="1"><d4/><c5/></m></mp>,
der Bauer <d5/> dem Schwarzen Verlegenheiten bereiten dürfte.</text>
</comment>
<comment type="m" nr="11" c="b">
<moveEval eval="poor"/>
</comment>
<comment type="m" nr="11" where="aft" c="b">
<text>“Ganz verfehlt,” sagt <playerName>Schlechter</playerName>.
“Der Turm richtet in der c-Linie nichts
aus.” Die richtige Spielweise war Gegenangriff mit
<m c="b"><c5/><c5/></m>
<m c="b"><a7/><a6/></m>
<m c="b"><b6/><b5/></m> und <m c="b"><b5/><b4/></m>
und es ist sehr fraglich, wer zuerst ankommt.</text>
</comment>
<comment type="m" nr="13" where="aft" c="b">
<text><mp nr="13"><m c="b" capt="1"><b6/><c5/></m></mp> sieht wegen
<mp nr="14"><m c="w" capt="1"><p c="w" n="b"/><g5/><f6/></m>
<m c="w" capt="1"><p c="b" n="n"/><d7/><f6/></m></mp>
<mp nr="15"><m c="w"><p c="w" n="b"/><d3/><c4/></m></mp>
bedenklich aus. Aber auch nach
<m c="b" capt="1"><p c="b" n="r"/><c8/><c5/></m>
ist Schwarz in Verlegenheiten.</text>
</comment>
<comment type="m" nr="14" c="b">
<moveEval eval="poor"/>
</comment>
<comment type="m" nr="14" where="aft" c="b">
<text>Die Öffnung der d-Linie wird dem Schwarzen verderblich.
<m c="b"><a7/><a6/></m> nebst
<m c="b"><b6/><b5/></m> hatte noch immer viel für sich.
Es ist interessant und lehrreich, wie rasch nun unter den Keulenschlägen
<playerName>Rubinstein</playerName>s die schwarze Armee zusammenbricht.</text>
</comment>
<comment type="m" nr="16" c="w">
<moveEval eval="good"/>
</comment>
<comment type="m" nr="16" where="aft" c="w">
<text>Droht nebenbei auch <m c="w"><p c="w" n="n"/><b5/><d6/></m>.</text>
</comment>
<comment type="m" nr="17" c="w">
<moveEval eval="good"/>
</comment>
<comment type="m" nr="19" where="aft" c="w">
<text>Es ist den gelehrtesten Kritikern entgangen, daß
<mp nr="19"><m c="w"><p c="w" n="n"/><b5/><d6/></m></mp> noch schrecklicher
war z.B. </text>
<var>
<mp nr="19"><m c="b"><p c="b" n="r"/><e8/><e5/></m></mp>
<mp nr="20"><m c="w"><p c="w" n="n"/><d6/><b7/></m>
<m c="b"><b6/><b5/></m></mp>
<mp nr="21"><m c="w"><p c="w" n="q"/><a4/><d4/></m>
<ilcomment type="m"><moveEval eval="good"/></ilcomment></mp>
</var><text><playerName>. Rubinstein</playerName>s Fortsetzung ist aber klarer
und das ist im Turnier die Hauptsache.</text>
</comment>
<comment type="m" nr="21" c="w">
<moveEval eval="good"/>
</comment>
<comment type="m" nr="21" where="aft" c="b">
<text>Auf <m c="b" capt="1"><p c="b" n="r"/><c5/><g5/></m> wird
<mp nr="22"><m c="w"><p c="w" n="n"/><b5/><c7/></m>
<m c="b"><p c="b" n="q"/><a8/><c8/></m></mp>
<mp nr="23"><m c="w"><p c="w" n="n"/><c7/><d5/></m></mp> verderblich.</text>
</comment>
<comment type="m" nr="22" where="aft" c="b">
<text>Nur aus Verzweiflung. Auf <m c="b"><p c="b" n="r"/><c8/><c7/></m>
würde <m c="w"><p c="w" n="n"/><d6/><f5/></m> folgen.</text>
</comment>
<comment type="m" nr="23" where="aft" c="w">
<text><mp nr="23"><m c="b" capt="1"><b5/><a4/></m></mp> ist wegen
<mp nr="24"><m c="w" capt="1" chk="1"><p c="w" n="n"/><c8/><e7/></m>
<m c="b"><p c="b" n="k"/><g8/><f8/></m></mp>
<mp nr="25"><m c="w" capt="1"><p c="w" n="r"/><d4/><d7/></m></mp>
aussichtslos.</text>
</comment>
<diagrams>
<diagram why="orig" where="aft" c="w" nr="14">
<diarow r="8"> <dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="b" n="q"/></dsq><dsq c="w"><p c="b" n="r"/></dsq><dsq c="b"/><dsq c="w"><p c="b" n="k"/></dsq><dsq c="b"/></diarow>
<diarow r="7"> <dsq c="b"><p c="b" n="p"/></dsq><dsq c="w"><p c="b" n="b"/></dsq><dsq c="b"/><dsq c="w"><p c="b" n="n"/></dsq><dsq c="b"><p c="b" n="b"/></dsq><dsq c="w"><p c="b" n="p"/></dsq><dsq c="b"><p c="b" n="p"/></dsq><dsq c="w"><p c="b" n="p"/></dsq></diarow>
<diarow r="6"> <dsq c="w"/><dsq c="b"><p c="b" n="p"/></dsq><dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="b" n="n"/></dsq><dsq c="w"/><dsq c="b"/></diarow>
<diarow r="5"> <dsq c="b"/><dsq c="w"/><dsq c="b"><p c="b" n="r"/></dsq><dsq c="w"><p c="b" n="p"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="b"/></dsq><dsq c="w"/></diarow>
<diarow r="4"> <dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="n"/></dsq><dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="p"/></dsq></diarow>
<diarow r="3"> <dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="n"/></dsq><dsq c="w"><p c="w" n="b"/></dsq><dsq c="b"><p c="w" n="p"/></dsq><dsq c="w"/><dsq c="b"/><dsq c="w"/></diarow>
<diarow r="2"> <dsq c="w"><p c="w" n="p"/></dsq><dsq c="b"><p c="w" n="p"/></dsq><dsq c="w"><p c="w" n="q"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="p"/></dsq><dsq c="w"><p c="w" n="p"/></dsq><dsq c="b"/></diarow>
<diarow r="1"> <dsq c="b"/><dsq c="w"><p c="w" n="k"/></dsq><dsq c="b"/><dsq c="w"><p c="w" n="r"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"/><dsq c="w"><p c="w" n="r"/></dsq></diarow>
</diagram>
<diagram why="orig" nr="23" c="w" where="bef">
<diarow r="8"> <dsq c="w"><p c="b" n="q"/></dsq><dsq c="b"/><dsq c="w"><p c="b" n="r"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"/><dsq c="w"><p c="b" n="k"/></dsq><dsq c="b"/></diarow>
<diarow r="7"> <dsq c="b"><p c="b" n="p"/></dsq><dsq c="w"/><dsq c="b"/><dsq c="w"><p c="b" n="n"/></dsq><dsq c="b"><p c="b" n="r"/></dsq><dsq c="w"><p c="b" n="p"/></dsq><dsq c="b"><p c="b" n="p"/></dsq><dsq c="w"><p c="b" n="p"/></dsq></diarow>
<diarow r="6"> <dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="n"/></dsq><dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"/></diarow>
<diarow r="5"> <dsq c="b"/><dsq c="w"><p c="b" n="p"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="p"/></dsq><dsq c="w"/></diarow>
<diarow r="4"> <dsq c="w"><p c="w" n="q"/></dsq><dsq c="b"><p c="w" n="p"/></dsq><dsq c="w"/><dsq c="b"><p c="w" n="r"/></dsq><dsq c="w"><p c="b" n="p"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"/></diarow>
<diarow r="3"> <dsq c="b"/><dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="p"/></dsq><dsq c="w"/><dsq c="b"/><dsq c="w"/></diarow>
<diarow r="2"> <dsq c="w"><p c="w" n="p"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"><p c="w" n="p"/></dsq><dsq c="w"><p c="w" n="p"/></dsq><dsq c="b"/></diarow>
<diarow r="1"> <dsq c="b"/><dsq c="w"><p c="w" n="k"/></dsq><dsq c="b"/><dsq c="w"/><dsq c="b"/><dsq c="w"/><dsq c="b"/><dsq c="w"><p c="w" n="r"/></dsq></diarow>
</diagram>
</diagrams>
</setofcomments>
</game>
Ed Seedhouse
wrote:
>Ed Seedhouse wrote:
>> With all due respect, and I don't by any means intend this as a
>> criticisism of your or anyone else's past efforts, I think it is time
>> to "bag" pgn and move on to a more universal standard.
>>I think the obvious, and probably best, way to go at the present time is to XML.
>Is that the one Microsoft likes?
Ah, the "poisoned well" fallacy.
Well, Netscape, Oracle, the world wide web consortium, and most of the
industry support XML as well. In fact the latest version of HTML,
XHTML, is an XML application.
>That would be my first reason to avoid it.
Even the devil can occasionally be right.
>I don't believe there should be any "language" involved as they're changing
>constantly and, in time, many become extinct.
That lets out "pgn" too, then because it is a markup language in much
the same sense that html is.
>Multibyte character sets OTOH, like the original ASCII build from the bottom
>up and have a future. They can be converted to ASCII with simple
>calls....just like RTF. They could even appear much like the PGN we are used
>to.
The trouble is that pgn is not well designed from a data storage and
retrieval point of view. That's not a knock on the designers, it's
just a recognition of the fact that we know a fair bit more about how
to design data storage and retrieval formats than we did when pgn was
first designed.
>In the meantime, PGN, just as it is....the basic product, is going to be
>around a long time to come.
True, but it seems a waste to put more time and energy into updating
what is, basicly, a broken format. Leave it be and move on to a
better fundmental design. If the job is done right, eventually the
chess world will convert to the new standard because it will be
better.
>Most of us don't want our chess with two dozen
>computer-generated comments after every move. When I encounter those things,
>it means there's a NORMAL32 run coming up to strip them.
What in heavens name has that to do with the merits of demerits of
pgn?
Ed Seedhouse
<_Email_Address_is_@_www.guymacon.com_> wrote:
>
>Ed Seedhouse <eseed...@shaw.ca> wrote:
>
>>With all due respect, and I don't by any means intend this as a
>>criticisism of your or anyone else's past efforts, I think it is time
>>to "bag" pgn and move on to a more universal standard. I think the
>>obvious, and probably best, way to go at the present time is to XML.
>A google search on "XML" and "Chess" turns up a lot of work that has
>already been done.
Glad to know this. That's the way to go, in my opinion.
Anders Thulin
> I don't believe there should be any "language" involved as they're changing
> constantly and, in time, many become extinct.
XML isn't a language. It's largely a meta-language: a way to describe the
syntax (only syntax!) of a data file.
It's really SGML in rather condensed forms.
And it does rather force the developer to formulate an unambiguous
markup grammar. That leads to most developers doing nothing but that.
Design is actually more important, as is formulating the semantics of
the markupped data.
> up and have a future. They can be converted to ASCII with simple
> calls....just like RTF.
That would be rather uninteresting, unless they also can be converted
into other national character sets with simple calls. Just getting away
from the remarkable US-centricity of PGN would be a major step in the right
direction.
--
Anders Thulin a...@algonet.se http://www.algonet.se/~ath
Paul Onstad
> >In the meantime, PGN, just as it is....the basic product, is going to be
> >around a long time to come.
>
> True, but it seems a waste to put more time and energy into updating
> what is, basicly, a broken format. Leave it be and move on to a
> better fundmental design. If the job is done right, eventually the
> chess world will convert to the new standard because it will be
> better.
I agree in sense but not in language. I do not consider PGN to be a "broken
format" but then I don't feel it is due for an overhaul either. Leave it as
it is but do transfer the burden of developing computer implementations to a
new format. Each will be there for quite different purposes.
> >Most of us don't want our chess with two dozen
> >computer-generated comments after every move. When I encounter those things,
> >it means there's a NORMAL32 run coming up to strip them.
>
> What in heavens name has that to do with the merits of demerits of
> pgn?
It's just that when I see a common chess score dressed up like a Russian
general, I have this wish to discover the game again.
-Paul
Paul Onstad
I have no argument with that last statement which is what multibyte
characters are all about.
Perhaps XML is one consideration....would it support Chinese? like
multibyte?
-Paul
Paul Onstad
Good post and persuasive (for certain purposes) BUT...
> I picked a couple of XML chess games as examples.
> The first is feature-poor but quite readable.
> The second has lot's of features but is really
> quite awful as afr as human readability is
> concerned. I think we can do better.
> Here are the examples:
>
> http://www.oasis-open.org/cover/chessML.html
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> - <chessgame event="IBM Kasparov vs. Deep Blue Rematch" site="New York, NY USA" date="1997.05.03" round="1" white="Kasparov, Garry" black="Deep Blue" opening="Reti - King's Indian attack, Keres variation" result="1-0">
> - <move>
> <white>N g1-f3</white>
> <black>P d7-d5</black>
> <?xml version="1.0" encoding="iso-8859-1"?>
> <m c="b"><p c="b" n="p"/><d7/><d5/></m>.....
If you think either is an improvement over PGN when a human's looking,
forget it.
..More proof there'll always be a place for something the eye can parse.
-Paul
Ed Seedhouse
wrote:
>If you think either is an improvement over PGN when a human's looking,
>forget it.
Of course it isn't. That's not the point of XML anyway. XML allows
computers to parse data efficiently into a form that people can easily
read. Furthermore we already have a perfectly human readable
standard, algebreic notation. "pgn" suffers because it tries to do
both things at the same time, when they are fundamentally incompatable
in the first place. You store data on machines, so you design the
data format to store well on machines. Then you design an interface
to allow the machine to display it in a readible format for people.
>..More proof there'll always be a place for something the eye can parse.
Well I certainly am not going to read a chess book in either XML or
pgn format, if I can help it.
XML allows us to separate content from presentation, and that is what
it is designed to do. It's hardly fair to blame it for not doing what
it wasn't designed to do in the first place.
Guy Macon
Clarification; when I mentioned that one example was more readable
than the other, I did not mean to imply that a human would ordinarily
be reading the raw XML. That would be like using a text editor to
read the raw HTML that defines a web page. What I was getting at is
that some XML schemas are easier for a human to understand if he ever
has a need to look at the raw XLM. Sorry for being unclear.
Guy Macon
>>time is to XML.
>
>Is that the one Microsoft likes? That would be my first reason to avoid it.
Microsoft hates XML just as they hate every open standard.
Example: StarOffice uses XML as it's native format. MS Word uses a
propriatary format but will work (almost) with many standard formats.
Guy Macon
>Perhaps XML is one consideration....would it support Chinese? like
>multibyte?
Yes.
Paul Onstad
I had a chance to spend more time browsing the links Guy Macon had provided.
I could not get over the impression that I was looking at implementations,
not nascent standards. If WinWord places a crosstable on top and then
diagrams every 5th move for all games in a tournament then something has
been accomplished but have I been released in any substantial way from the
tedious <haha> job of programming?
I was at Compuserve in 1994 when PGN was released (we had no warning) but
within three months we had converted to the PGN standard. Some of the Chess
XML projects have been at it since 1999 and have progressed little beyond
demos.
Still, from what I saw, there seems little doubt that XML will provide all
sorts of web presentations but that is far from saying it will become the
common currency of chess. The criticisms of PGN were just not strong enough,
i.e., is TWIC longing for some method of associating games just because of a
(somewhat annoying) tradition of separating tournaments with simple headers?
I don't think so. Everyone's software that acknowledges TWIC simply drops
the headers and puts the games in a database; they're associated from then
on. Likewise, anyone who wants (my software at least) can put in "Hübner"
any time they want to. I suspect the only reason some convert to an English
representation is that they're still using some DOS software(?).
The older NTR (Nunn's Text Reader) format was almost identical to that which
you'd find in a book or magazine so something was lost in the presentation
with PGN--but NTR had a fatal flaw which effected even the simplest game and
that was the ambiguous hyphen. The slight compromise effecting PGN's
appearance still allows it to be the most suitable format for presenting
games in messages like these. IOW, the common currency. It's size will
continue to make it the most suitable, non-proprietary, archive format for
downloads.
We'll no doubt see some good things coming from XML/chess but based on the
apparent complexity of such projects, I fear serving on an XML chess
*standards* committee could be a very painful experience ;-)
-Paul
Anders Thulin
> Perhaps XML is one consideration....would it support Chinese? like
> multibyte?
It can support the full Unicode set.
Ed Seedhouse
wrote:
>Ed Seedhouse wrote:
>I had a chance to spend more time browsing the links Guy Macon had provided.
>I could not get over the impression that I was looking at implementations,
>not nascent standards. If WinWord places a crosstable on top and then
>diagrams every 5th move for all games in a tournament then something has
>been accomplished but have I been released in any substantial way from the
>tedious <haha> job of programming?
Actually I am beginning to believe that it would be better for an XML
schema to be developed for board games in general, not just chess
games. Call it "BGML" for "Board Game Markup Language", if you like.
There are a multitude of chesslike games, and many other board games
like Draughts and Othello whose moves may be recorded by simply
specifying the start square and the end square of any move. They all
share many things in common - enough things to make a workable common
standard quite possible.
Such a standard seems to me to be more likely to succeed since it
would be useful to more people.
Ed Seedhouse
wrote:
>Actually I am beginning to believe that it would be better for an XML
>schema to be developed for board games in general, not just chess
>games. Call it "BGML" for "Board Game Markup Language", if you like.
After writing this I did a google search and, guess what?
http://www.vilab.com/bgml/home.html
Anders Thulin
> Actually I am beginning to believe that it would be better for an XML
> schema to be developed for board games in general, not just chess
> games.
There's a trick to doing things: it's doing as little as necessary.
Defining a chess markup language is far more difficult than it seems:
it's not about getting the game score right, it's about understanding just
what "Agram" is, and how, in any way, it differs from "Zagreb". Or how
"Lt. Georges Cartier" differs from "Tartakover". And which of those is
'right'. Or not, as the case may be.
That is going to be the same for all these games.
Solve it for chess, and the rest will be easy.
It may be that the database style we're accustomed to, that centers
around the game score, is not the solution, this time.
Jason Varsoke
Off the top of my head I came up with a few things I believe a new PGN
standard should address officially:
1) A "null" move - PGN is not only used for games but also for
instructive annotation. Many authors state "following any move from
Black, White plays e4#". The chessbase files support this and the
lack of support by the PGN Standard means many programs (including
SCiD) cause games to be non-transferable between these programs.
2) Support of computer numberic evaluations in the move text. Often
these are added to the annotation field, but computer evaluations are
so common they deserve there own seperate delimeter(?) so that parsers
can easily pick them out (to either throw away or make use of).
3) Similarly, as much of the internet is interested in Blitz chess and
other fast time controls it makes sense that the important element of
Time be added to a game notation. As the world championships and many
other tournaments are decided on Rapid and Speed chess it would be
valuable to see that the reason Karpov made the game ending blunder is
not because he is now a poor player but that he had only 4seconds on
his clock. Many are of the opinion that the quality of high-level
chess has diminished with these faster games becoming more popular. I
think it crucial that Time information be preserved so future chess
players may weigh this information in their assessment of today's
chess performance.
Again, this could be added to the move annotation but I believe it
deserves a seperately parsable region of the PGN so programs may
ignore or retreive the information easily.
4) The [TimeControl] tag should be added to teh standard 9 tags that
all PGN should have. Again, I don't think the loss of time control
information adversly affects future critique of games.
Thanks for your consideration of these additions,
-jvarsoke
Guy Macon
Paul Onstad <pon...@visi.com> wrote:
>I had a chance to spend more time browsing the links Guy Macon had provided.
>I could not get over the impression that I was looking at implementations,
>not nascent standards.
Exactly right. XML is a standard that, in my opinion, a replacement
for PGN should follow, but clearly that's not enough. There are a wide
variety of XML-compliant ways (AKA Schemas) to represent chess, and it's
a common first project for someone learning XML. To my way of thinking,
the computer chess community can do a much better job than anything that
I have seen done so far. The real hurdle is either convincing the
author of XBoard and WinBoard (Tim Mann) to use XML in designing a
replacement for PGN or getting someone else to write something as good
as what Tim has written. Without that, the whole idea is a W.O.M.B.A.T.
(Waste Of Money, Brains, And Time.) and is dead in the water.
XML is just the starting point. Somebody has to do some real designing
in order to come up with a standard.
I would like to propose the name XPGN for any such schema. This follows
the convention used when converting HTML to XHTML. In fact, a look at
how HTML was recast into XML-Compliant XHTML would be a good thing to
search on for anyone interested in this idea.
Guy Macon
An interesting link off of that one is http://www.red-bean.com/sgf/
and http://www.red-bean.com/sgf/user_guide/index.html (Smart Game
Format) which is used to describe games of GO.
Guy Macon
If whoever does the schema does it right, everything but text comments
will display in English, Russian, Chinese, or pictures of chessmen
with no change to the Chess-XML (XPGN?) file.
That's the basic idea behind XML - seperating content from display.
Guy Macon
Jason Varsoke <jvar...@hotmail.com> wrote:
>
>Off the top of my head I came up with a few things I believe a new PGN
>standard should address officially:
>
>1) A "null" move - PGN is not only used for games but also for
>instructive annotation. Many authors state "following any move from
>Black, White plays e4#". The chessbase files support this and the
>lack of support by the PGN Standard means many programs (including
>SCiD) cause games to be non-transferable between these programs.
Hmmm. I really like the idea, but how would a program that displays
a game display this?
>2) Support of computer numberic evaluations in the move text. Often
>these are added to the annotation field, but computer evaluations are
>so common they deserve there own seperate delimeter(?) so that parsers
>can easily pick them out (to either throw away or make use of).
One nice thing about the XML standard is that all programs must ignore
any element that they do not recognize. Of course it would be a Good
Thing to suggest a standard way of descibing numeric evaluations, number
of plies searched to, etc rather than have each chess engine roll thier
own...
>3) Similarly, as much of the internet is interested in Blitz chess and
>other fast time controls it makes sense that the important element of
>Time be added to a game notation. As the world championships and many
>other tournaments are decided on Rapid and Speed chess it would be
>valuable to see that the reason Karpov made the game ending blunder is
>not because he is now a poor player but that he had only 4seconds on
>his clock. Many are of the opinion that the quality of high-level
>chess has diminished with these faster games becoming more popular. I
>think it crucial that Time information be preserved so future chess
>players may weigh this information in their assessment of today's
>chess performance.
A suggested method for adding time info would also be a Good Thing.
The question is, what format? Time used on each move? Time until
the end of current time control? Time since the start of the game?
(note that a program can take any of those and calculate the others)
Anders Thulin
> If whoever does the schema does it right, everything but text comments
> will display in English, Russian, Chinese, or pictures of chessmen
> with no change to the Chess-XML (XPGN?) file.
This will be one of the points of contentions during the design of
a XML-markup labguage for chess: should it be for information exchange
only, or for the purpose of display?
Anders Thulin
> Jason Varsoke <jvar...@hotmail.com> wrote:
>>1) A "null" move - PGN is not only used for games but also for
>>instructive annotation.
>
> Hmmm. I really like the idea, but how would a program that displays
> a game display this?
Annotations should be displayed in the style the user specifies.
> One nice thing about the XML standard is that all programs must ignore
> any element that they do not recognize.
Even non-validating processors must report problems, or they don't conform.
At least if I understand chapter 5.1 of the specification correctly.
And it makes some kind of sense, or there would be no point in
having a DOCTYPE specification, if it didn't specify anything
(such as the grammar and elements used).
Paul Onstad
> Off the top of my head I came up with a few things I believe a new PGN
> standard should address officially:
>
> 1) A "null" move - PGN is not only used for games but also for
> instructive annotation. Many authors state "following any move from
> Black, White plays e4#". The chessbase files support this and the
> lack of support by the PGN Standard means many programs (including
> SCiD) cause games to be non-transferable between these programs.
Null moves might be a good addition....if there was agreement on what
parsers should do with them.
> 2) Support of computer numberic evaluations in the move text. Often
> these are added to the annotation field, but computer evaluations are
> so common they deserve there own seperate delimeter(?) so that parsers
> can easily pick them out (to either throw away or make use of).
Since such evaluations are put in all the time, I don't see what the problem
is in getting at them. I think it's just that the different chess engine
interfaces might treat them differently is all.
> 3) Similarly, as much of the internet is interested in Blitz chess and
> other fast time controls it makes sense that the important element of
> Time be added to a game notation. As the world championships and many
> other tournaments are decided on Rapid and Speed chess it would be
> valuable to see that the reason Karpov made the game ending blunder is
> not because he is now a poor player but that he had only 4seconds on
> his clock. Many are of the opinion that the quality of high-level
> chess has diminished with these faster games becoming more popular. I
> think it crucial that Time information be preserved so future chess
> players may weigh this information in their assessment of today's
> chess performance.
> Again, this could be added to the move annotation but I believe it
> deserves a seperately parsable region of the PGN so programs may
> ignore or retreive the information easily.
Time per move is very common and easily accessible. As before, it may depend
which (eg, sensory board) vendor puts it in.
> 4) The [TimeControl] tag should be added to teh standard 9 tags that
> all PGN should have. Again, I don't think the loss of time control
> information adversly affects future critique of games.
Preferring my PGN wider than it is tall, I would *not* want to see this.
OTOH, where it's desired (and reported), it's just a simple matter of
putting it in.
BTW, there are seven basic tags, not nine. Were it done over again, I'd even
drop Round. It makes no sense for online and correspondence games.
-Paul
Paul Onstad
I like 'XPGN'. That's not trying to overwrite 'PGN' with 'PGN2'.
As you suggest, maybe someone in the closer chess community has to write a
very generalized application that incorporates a sort of proto-standard just
to get their feet wet and provide something that can be responded to. With
so many possible directions, it's otherwise difficult to settle on a
suitable reference point. If it were kept simple--just PGN with a promise--I
think it could act as a springboard for new ideas.
-Paul (belling the cat and I don't program in summers :)
Ed Seedhouse
wrote:
> This will be one of the points of contentions during the design of
> a XML-markup labguage for chess: should it be for information exchange
> only, or for the purpose of display?
There's no point doing an XML schema for chess or anything else if
it's for anything other than information exchange. The whole *point*
of XML is to separate content from presentation.
One of the problems with .pgn, in my opinion, is that it allows the
use of piece symbols in notation like "1. Nf3". Since different
languages use different piece symbols, right away we allow
incompatable notations. Chess moves can *always* be described by
specifying the start square and the end square for the move, including
castling and en passant. Therefore I think the only notation allowed
in such a standard should be to specify the start and end squares for
the move. So "1. g1-f3: should be allowed, but "1. Ng1-f3" shouldn't.
Similarly in describing positions we should avoid allowing symbols for
the pieces. This can be done, for example, by numbering the pieces
from 1 to 6 with an extra bit for colour. So a white pawn on a2 could
be written "01a2" and a black pawn on a7 could be written "11a7".
A schema for describing chess or any other game should be language
neutral, in other words.
Paul Onstad
reason we might want XPGN just to take the burden off of PGN:
[Courtesy of Thorsten Czub by way of M. Sharpe]
[Event "?"]
[Site "?"]
[Date "2002.04.29"]
[Round "1"]
[White "Hiarcs 8"]
[Black "Shredder6 Paderborn"]
[Result "1-0"]
[ECO "C44"]
[Annotator "-0.20"]
[PlyCount "179"]
[EventDate "2002.04.28"]
{64MB, Hiarcs8.ctg. } 1. e4 {[%emt 0:00:00]} e5 {[%emt 0:00:01]} 2. Nf3
{[%emt 0:00:00]} Nc6 {[%emt 0:00:01]} 3. c4 {[%emt 0:00:00]} Bc5 {
[%emt 0:03:11]} 4. Nc3 {[%emt 0:00:00]} d6 {[%emt 0:06:08]} 5. d3 {
[%emt 0:00:00]} f5 {(Sge7). letzter Buchzug [%emt 0:04:23]} 6. Bg5 {
127kN/s [%eval -20,12] [%emt 0:06:00]} Nge7 {[%emt 0:00:44]} 7. Be2 {
123kN/s [%eval -22,12] [%emt 0:05:08]} O-O {[%emt 0:00:19]} 8. O-O {
119kN/s [%eval -11,12] [%emt 0:04:47]} Be6 {(h6) [%emt 0:00:00]} 9. Qb3 {
70kN/s [%eval -20,11] [%emt 0:05:08]} Qd7 {(Tb8) [%emt 0:05:04]} 10. Nd5 {
132kN/s [%eval -22,11] [%emt 0:03:05]} b6 {(Tab8) [%emt 0:05:50]} 11. Bxe7 {
127kN/s [%eval -5,10] [%emt 0:02:42]} Nxe7 {[%emt 0:00:56]} 12. Ng5 {
68kN/s [%eval 0,12] [%emt 0:01:28]} Rac8 {(Lf7) [%emt 0:06:24]} 13. Nxe6 {
141kN/s [%eval 5,11] [%emt 0:02:12]} Qxe6 {[%emt 0:00:00]} 14. Nxe7+ {
141kN/s [%eval -10,12] [%emt 0:04:58]} Qxe7 {[%emt 0:00:13]} 15. exf5 {
147kN/s [%eval -3,12] [%emt 0:01:24]} Qg5 {(Dh4) [%emt 0:03:23]} 16. Qd1 {
169kN/s [%eval 30,12] [%emt 0:02:33]} Bd4 {[%emt 0:02:32]} 17. Rb1 {
147kN/s [%eval 36,13] [%emt 0:00:00]} Rb8 {(Tcd8) [%emt 0:05:05]} 18. Bg4 {
157kN/s [%eval 35,12] [%emt 0:01:43]} c6 {(a5) [%emt 0:02:36]} 19. b4 {
144kN/s [%eval 46,12] [%emt 0:04:02]} Rf6 {(d5) [%emt 0:03:55]} 20. g3 {
129kN/s [%eval 55,12] [%emt 0:04:01]} Rff8 {(g6) [%emt 0:06:59]} 21. Kg2 {
134kN/s [%eval 69,12] [%emt 0:03:33]} Kh8 {(d5) [%emt 0:05:02]} 22. f4 {
134kN/s [%eval 98,12] [%emt 0:04:02]} Qf6 {(exf4) [%emt 0:00:21]} 23. Qf3 {
80kN/s [%eval 111,12] [%emt 0:03:57]} Rbc8 {(c5) [%emt 0:00:00]} 24. fxe5 {
131kN/s [%eval 116,12] [%emt 0:03:52]} dxe5 {[%emt 0:04:10]} 25. Qe2 {
79kN/s [%eval 119,13] [%emt 0:00:00]} Rcd8 {[%emt 0:01:12]} 26. Bf3 {
137kN/s [%eval 123,13] [%emt 0:01:43]} Rd6 {(c5) [%emt 0:08:11]} 27. Qd2 {
142kN/s [%eval 131,12] [%emt 0:03:20]} a6 {(Dh6) [%emt 0:06:01]} 28. Be4 {
131kN/s [%eval 138,12] [%emt 0:02:53]} Qe7 {(Df7) [%emt 0:02:53]} 29. Qc2 {
122kN/s [%eval 137,12] [%emt 0:03:58]} Rh6 {(Tdf6) [%emt 0:03:46]} 30. h4 {
130kN/s [%eval 137,12] [%emt 0:04:03]} Qd7 {(Thf6) [%emt 0:03:31]} 31. Qa4 {
129kN/s [%eval 141,12] [%emt 0:02:58]} Qc8 {[%emt 0:00:35]} 32. Rbe1 {
128kN/s [%eval 138,12] [%emt 0:02:27]} Bc3 {[%emt 0:04:24]} 33. Rc1 {
132kN/s [%eval 145,14] [%emt 0:00:21]} Bb2 {[%emt 0:06:48]} 34. Rc2 {
84kN/s [%eval 139,15] [%emt 0:00:00]} Bd4 {[%emt 0:00:11]} 35. c5 {
12kN/s [%eval 138,14] [%emt 0:05:26]} b5 {(bxc5) [%emt 0:01:53]} 36. Qa3 {
88kN/s [%eval 131,13] [%emt 0:06:21]} Rf7 {(Thf6) [%emt 0:02:52]} 37. Re2 {
130kN/s [%eval 149,12] [%emt 0:03:44]} Rf8 {(Thf6) [%emt 0:00:05]} 38. Qa5 {
132kN/s [%eval 158,13] [%emt 0:05:51]} Rg8 {(Db7) [%emt 0:00:01]} 39. a4 {
128kN/s [%eval 161,13] [%emt 0:06:09]} Rf8 {[%emt 0:06:06]} 40. Ra2 {
133kN/s [%eval 163,13] [%emt 0:00:00]} Rhf6 {[%emt 0:01:51]} 41. g4 {
121kN/s [%eval 152,12] [%emt 0:02:29]} Rh6 {(g6) [%emt 0:04:44]} 42. h5 {
134kN/s [%eval 180,12] [%emt 0:03:21]} Rg8 {(Lc3) [%emt 0:06:03]} 43. Rh1 {
137kN/s [%eval 209,12] [%emt 0:02:51]} Rf6 {(Le3) [%emt 0:03:45]} 44. Re2 {
129kN/s [%eval 166,12] [%emt 0:11:12]} Rgf8 {[%emt 0:03:39]} 45. Qb6 {
112kN/s [%eval 172,12] [%emt 0:00:00]} Bc3 {(Tg8) [%emt 0:04:00]} 46. Rb1 {
135kN/s [%eval 177,11] [%emt 0:01:46]} R8f7 {(Da8) [%emt 0:02:49]} 47. axb5
{
137kN/s [%eval 188,11] [%emt 0:02:22]} axb5 {[%emt 0:04:22]} 48. Rb3 {
141kN/s [%eval 193,14] [%emt 0:00:00]} Bd4 {[%emt 0:03:15]} 49. Ra3 {
43kN/s [%eval 193,14] [%emt 0:00:16]} Rb7 {[%emt 0:02:35]} 50. Qa6 {
63kN/s [%eval 183,14] [%emt 0:00:16]} h6 {[%emt 0:02:41]} 51. Rea2 {
150kN/s [%eval 175,13] [%emt 0:02:46]} Kh7 {[%emt 0:00:20]} 52. Qa8 {
171kN/s [%eval 175,13] [%emt 0:03:27]} Rb8 {[%emt 0:00:00]} 53. Qa7 {
122kN/s [%eval 166,15] [%emt 0:05:48]} Rb7 {[%emt 0:00:00]} 54. Qa6 {
3kN/s [%eval 166,14] [%emt 0:04:13]} Be3 {[%emt 0:03:30]} 55. Kh1 {
147kN/s [%eval 158,13] [%emt 0:02:03]} Qc7 {(Lf4) [%emt 0:03:46]} 56. Qa8 {
158kN/s [%eval 155,14] [%emt 0:04:40]} Rb8 {[%emt 0:00:00]} 57. Qa7 {
42kN/s [%eval 155,14] [%emt 0:03:30]} Rb7 {[%emt 0:02:27]} 58. Qa5 {
68kN/s [%eval 145,14] [%emt 0:04:11]} Qc8 {[%emt 0:00:00]} 59. Qa8 {
142kN/s [%eval 145,13] [%emt 0:04:07]} Rb8 {[%emt 0:00:00]} 60. Qa6 {
150kN/s [%eval 149,13] [%emt 0:03:25]} Qg8 {(Dc7) [%emt 0:05:12]} 61. Qa7 {
144kN/s [%eval 153,12] [%emt 0:04:09]} Bd4 {(Dd8) [%emt 0:02:19]} 62. Kg2 {
135kN/s [%eval 168,12] [%emt 0:04:06]} Rd8 {(Tc8) [%emt 0:04:06]} 63. Re2 {
147kN/s [%eval 168,12] [%emt 0:03:26]} Rb8 {[%emt 0:03:39]} 64. Rc2 {
131kN/s [%eval 168,13] [%emt 0:00:00]} Qc8 {(Tf7) [%emt 0:05:06]} 65. Qa6 {
153kN/s [%eval 163,12] [%emt 0:03:38]} Rb7 {(Dd7) [%emt 0:01:44]} 66. Kf1 {
157kN/s [%eval 164,13] [%emt 0:03:13]} Qc7 {[%emt 0:05:54]} 67. Qa5 {
143kN/s [%eval 160,14] [%emt 0:00:00]} Qc8 {[%emt 0:05:18]} 68. Qa8 {
76kN/s [%eval 159,14] [%emt 0:00:00]} Rb8 {[%emt 0:00:16]} 69. Qa6 {
2kN/s [%eval 159,13] [%emt 0:03:28]} Qe8 {(Dc7) [%emt 0:03:06]} 70. Re2 {
127kN/s [%eval 159,13] [%emt 0:03:15]} Qd8 {(Kh8) [%emt 0:09:21]} 71. Kg2 {
145kN/s [%eval 150,13] [%emt 0:05:01]} Kg8 {(Dc7) [%emt 0:00:00]} 72. Rea2 {
146kN/s [%eval 160,12] [%emt 0:04:09]} Kh7 {(Le3) [%emt 0:00:19]} 73. Qa7 {
114kN/s [%eval 160,13] [%emt 0:04:46]} Qf8 {(Dc8) [%emt 0:00:00]} 74. Ra6 {
83kN/s [%eval 173,13] [%emt 0:04:33]} Rc8 {[%emt 0:06:51]} 75. Rb6 {
121kN/s [%eval 183,14] [%emt 0:00:00]} Bc3 {[%emt 0:02:46]} 76. Qa3 {
21kN/s [%eval 184,13] [%emt 0:01:11]} Qg8 {(Ld4) [%emt 0:01:31]} 77. Ra6 {
153kN/s [%eval 191,13] [%emt 0:03:13]} Bd4 {[%emt 0:00:00]} 78. Ra7 {
139kN/s [%eval 189,13] [%emt 0:05:32]} Kh8 {[%emt 0:00:00]} 79. Qc1 {
117kN/s [%eval 214,12] [%emt 0:04:52]} Rff8 {(Db3) [%emt 0:09:11]} 80. R2a6
{
140kN/s [%eval 259,12] [%emt 0:02:43]} Qb3 {(Ta8) [%emt 0:07:12]} 81. g5 {
147kN/s [%eval 284,11] [%emt 0:03:07]} Bb2 {[%emt 0:01:01]} 82. Qb1 {
150kN/s [%eval 312,11] [%emt 0:01:20]} hxg5 {[%emt 0:02:18]} 83. Ra2 {
155kN/s [%eval 391,13] [%emt 0:00:55]} Qxb4 {[%emt 0:08:56]} 84. Qxb2 {
156kN/s [%eval 435,14] [%emt 0:00:00]} Qxb2+ {[%emt 0:03:30]} 85. Rxb2 {
142kN/s [%eval 463,15] [%emt 0:00:00]} Rf6 {(Kg8) [%emt 0:06:22]} 86. Kg3 {
172kN/s [%eval 583,15] [%emt 0:02:42]} Kg8 {[%emt 0:04:07]} 87. Kg4 {
177kN/s [%eval 634,16] [%emt 0:00:00]} Rf7 {(Kh8) [%emt 0:04:41]} 88. Rba2 {
199kN/s [%eval 755,15] [%emt 0:04:10]} Rcc7 {(Tf6) [%emt 0:01:18]} 89. Rxc7
{
212kN/s [%eval 880,14] [%emt 0:03:02]} Rxc7 {[%emt 0:03:38]} 90. Ra6 {
120kN/s [%eval 930,15] [%emt 0:00:00]} 1-0
Once PGN reaches such a state, it is not going to matter much if headers
look similar, as they would in XML.
Then (my own suggestion), here would be a PGN header basis for XML:
[Tournament "?"]
[Site "?"]
[Event "?"]
[Date "2002.04.29"]
[White "Hiarcs 8"]
[Black "Shredder6 Paderborn"]
[Result "1-0"]
[Round "1"]
[ECO "C44"]
[Annotator "-0.20"]
[PlyCount "179"]
[EventDate "2002.04.28"]
[...]
Note that a Tournament line has been added and Round moved down (optional
just like ECO). Tournament is either/or with Site/Event. (Note also that
Site precedes Event.) This could, in time, wean headers of Site/Event
entirely.
..add in null moves; a way to incorportate misplaced pieces....and pretty
soon we've included most of what has been talked about.
I think also, as Ed just suggested, that coordinate notation (no piece
abbreviations) might be the way to go--but that presents the interesting
problem of getting back to short algebraic--which, turned 180 degrees, was
the original "problem" for parsing PGN!
-Paul
Kenneth Sloan
> ...
> A schema for describing chess or any other game should be language
> neutral, in other words.
>
This is an argument which requires taste, style, and judgement. You
object to the symbol "N" to refer to a Knight, preferring "2" instead.
I can understand that.
But, you uncritically allow "a2" to refer to a square. Is this "language
neutral"? Why not use "12" instead?
In formats such as this, you should consider three things:
a) internal representation
b) output
c) input
Part a) can, and should be, absolutely language neutral. But, parts b)
and c) should allow language specific options. And...parts b) and c)
may well be DIFFERENT.
--
Kenneth Sloan sl...@uab.edu
Computer and Information Sciences (205) 934-2213
University of Alabama at Birmingham FAX (205) 934-5473
Birmingham, AL 35294-1170 http://www.cis.uab.edu/info/faculty/sloan/
Ed Seedhouse
>Ed Seedhouse <eseed...@shaw.ca> writes:
>> A schema for describing chess or any other game should be language
>> neutral, in other words.
>This is an argument which requires taste, style, and judgement. You
>object to the symbol "N" to refer to a Knight, preferring "2" instead.
>I can understand that.
>But, you uncritically allow "a2" to refer to a square. Is this "language
>neutral"? Why not use "12" instead?
Good point. I was also in error in stating that every move in a chess
game can be notated with just the start and end square. There is an
exception for promoting a pawn, where we need to specify the piece
promoted to.
>In formats such as this, you should consider three things:
> a) internal representation
> b) output
> c) input
>Part a) can, and should be, absolutely language neutral. But, parts b)
>and c) should allow language specific options. And...parts b) and c)
>may well be DIFFERENT.
XML is just a storage format. The problems of entry and output are
things it isn't designed to deal with, though once the storage format
is known they aren't hard problems.
Guy Macon
Ed Seedhouse <eseed...@shaw.ca> wrote:
>Similarly in describing positions we should avoid allowing symbols for
>the pieces. This can be done, for example, by numbering the pieces
>from 1 to 6 with an extra bit for colour. So a white pawn on a2 could
>be written "01a2" and a black pawn on a7 could be written "11a7".
>
>A schema for describing chess or any other game should be language
>neutral, in other words.
I personally don't consider the sequence a-b-c-d-e-f-g-h to be
language neutral... <grin> It *is* a lot more universal than
the sequence K-Q-R-B-N-P, though. I can't find a chesspiece
with an english name than starts witn "N"...
By seperating content from presentation, it shouldn't matter how
you map characters to squares or pieces. (It would be a Good Thing
to pick a mapping that is somewhat like what one sees in chess
publications, just in case someone cares to look at the source,)
TibetianTick
> Jason Varsoke wrote:
>
> > 2) Support of computer numberic evaluations in the move text. Often
> > these are added to the annotation field, but computer evaluations are
> > so common they deserve there own seperate delimeter(?) so that parsers
> > can easily pick them out (to either throw away or make use of).
>
> Since such evaluations are put in all the time, I don't see what the problem
> is in getting at them. I think it's just that the different chess engine
> interfaces might treat them differently is all.
Well, this is exactly my point; the evaluation is often included but
there is no standard way for a parser to determine what it's looking
at. The annotation { 0.25 } could really be anything, time it took
for the move, evaluation of the position, time still left on the
clock, or a quarter bet placed at that move. If there were a standard
(and optional) format the info could be parsed easily without having
to guess. Remeber, just because it's in the standard doesn't mean you
have to include it.
Thanks for posting the XPGN; I wasn't aware of that standard.
-tt
Jason Varsoke
> A suggested method for adding time info would also be a Good Thing.
> The question is, what format? Time used on each move? Time until
> the end of current time control? Time since the start of the game?
> (note that a program can take any of those and calculate the others)
As you point out none of the forms lose any information. And since
all can be translated into any of the others the decision can only be
made on preference for the form that is most important when looking at
the PGN in txt form. I'd suggest Time Left on the clock would be
prefered since that's what's most important to any chess player.
Oh, I take that all back. The 'botvinnik clock' (I think that's what
it's called makes the decision for us. This type of clock is like a
'fischer clock' but the increment cannot be carried over to the next
move. On each move your clock stops for X seconds instead of X
seconds being added to your clock. Since this is the case we must
choose Time Taken for each move to accurately support this clock.
of course, this wouldn't support a clock type that adds a random
number of seconds to your clock, but then again suck randomness should
not be introduced into such a deterministic game.
-jvarsoke
Guy Macon
TibetianTick <s_pam...@hotmail.com> wrote:
>
>Paul Onstad <pon...@visi.com> wrote...
>>
>> Jason Varsoke wrote:
>>
>> > 2) Support of computer numberic evaluations in the move text. Often
>> > these are added to the annotation field, but computer evaluations are
>> > so common they deserve there own seperate delimeter(?) so that parsers
>> > can easily pick them out (to either throw away or make use of).
>>
>> Since such evaluations are put in all the time, I don't see what the problem
>> is in getting at them. I think it's just that the different chess engine
>> interfaces might treat them differently is all.
>
Actually, it's a name I proposed for a possible future standard.
>Well, this is exactly my point; the evaluation is often included but
>there is no standard way for a parser to determine what it's looking
>at. The annotation { 0.25 } could really be anything, time it took
>for the move, evaluation of the position, time still left on the
>clock, or a quarter bet placed at that move. If there were a standard
>(and optional) format the info could be parsed easily without having
>to guess. Remember, just because it's in the standard doesn't mean you
>have to include it.
In XML, the optional format is already there. Example, if the format
for evaluations was defined as follows:
<evaluation>0.25</evaluation>
Then Dr. Hyatt could later decide to store his evaluation data as
<evaluation class= "Crafty">0.25</evaluation>
without causing any problems to any software that does not understand
what a Crafty is (or what an evaluation is!).
Mike Leahy - Bookup
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings all:
>
> This is Steven Edwards, author of the Portable Game Notation Standard,
> and I am now using chessn...@earthlink.net as my PGN related
> e-mail address. You may verify the PGP signature on this article as
> an assurance of its authenticity.
>
> I am now re-activating my participation in chess standards development
> as I feel that, after some eight years of usage, the PGN standard and
> related formats have gained more than sufficient acceptance in their
> current forms. So now it is time to discuss possible extensions and
> perhaps a few depreciations.
>
> ==========
>
> A side comment of broket notation in PGN move text: broket notation is
> an exact mapping to EPD records. In an EPD record, the piece position
> field, the active color field, the castling availability field, and
> the en passant file field are the first four fields of each record.
Hey Steven,
How about these radical ideas...
Eliminate the active color field. All positions would
be White to move.
Normalize the positions. If castling is not possible,
flip and/or mirror the position until the White king
is in the lower righthand corner of the board.
Bookup does this to find every single transposition.
The position with WKb6 WPb7 BKb8 and White to move is
the same as the position with BKg3 BPg2 WKg1 and
Black to move.
Also, do not allow the en passant flag when the en
passant capture is not legal! Setting this flag
willy nilly after each double pawn push means that
the position after 1.d4 d5 2.Nf3 comes out different
from 1.Nf3 d5 2.d4.
My two cents.
Mike Leahy
"The Database Man!"
http://www.bookup.com