Jeu de Dames - Site officiel de la Fédération Française de Jeu de Dames

Bonjour et excuses pour avoir écrit en anglais,

Dear draughts programmers,

A happy 2012 to all of you!

This is a reminder that the review period for Wieger Wesselink's PDN 3.0 draft standard will end on January 31st, which is in 4 weeks from tomorrow. After the initial posting of the review request, there was a good number of questions and discussions. According to my bookkeeping, Wieger has addressed every question raised in this forum. However, there are still some open points (see summary below).

Changes/additions
Code:
*) When writing PDN, leading zeroes should be disallowed in FEN tags. This is to make
it consistent with move notation.

*) In alpha-numeric moves the separator may not be omitted, so a3b4 is not allowed.


Questions
Code:
*) How should a 'plus draw' be recorded in PDN?

*) Should there be a table of valid results for every game type? I.e. 1-1, 0-2, 2-0
for international draughts, 1/2-1/2, 0-1, 1-0 for English draughts, etc.

*) Several tournaments used experimental results. For example we have 1.01 - 0.99 in
Goes, we have 1 1/2 - 1/2 in the 'Delft' system, there have been tournaments with 3-0
instead of 2-0, the Sport Accord Mind Games used 12-0, etc. Should the PDN standard
deal with those results? If so, how?

*) Should we always use "" to denote an unknown value of a PDN tag? Currently there
are some exceptions defined in the standard where a "?" should be used instead.

*) Should the PDN standard prescribe a character set? For example UTF-8?

*) Should the long notation be accepted even for unambiguous moves? For example
33x24x25 instead of 33x25?

*) Should the move separator in alpha-numeric moves be optional (for example a3b4)?
It turns out this can be achieved even in LL parsers, at the cost of additional
complexity of the grammar.


I would invite all the posters from this thread -as well as other interested and knowledgeable readers- to submit their reviews and votes in the coming 4 weeks. As a reminder, I re-post the review instructions from the original request below, but if you feel there is little to write in your review, a simple vote of ACCEPT or REJECT is also adequate.

Quote:
Reviews may answer the following questions:

* What is your evaluation of the documentation?
* What sections in the PDN 3.0 draft need to be improved? Please be as specific as possible.
* Are there any provisions in the grammar that prevent implementation in a popular parser generator (Bison/Flex, Boost.Spirit, ANTLR)?
* Are there any legacy PDN files that are not properly parsed by the proposed grammar specification?
* Did you try to use the grammar? With what compiler/parser generator/platform? Did you have any problems?
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

Of course, 'informal reviews' and discussion are also welcome.

And finally, every review should answer this question:

* Do you think the PDN 3.0 draft standard should become an official FMJD standard? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. A vote to accept the standard may be conditional.


Reviews and votes can be submitted on this thread viewtopic.php?f=53&t=3448

On behalf of World Draughts Federation FMJD,

Wieger Wesselink – pdn 3.0 Draft Submitter
Rein Halbersma – Review Manager
Marcel Kosters – Review Wizard
Frank Teer – FMJD Secretary General

The review period for Wieger Wesselink's draft proposal for the PDN 3.0 standard ended on February 1st. There were no official votes on this forum, but I think there has been a very constructive discussion about some of the subtleties. To the best of my knowledge, Wieger has adequately and constructively answered all questions.

Therefore, it is my great pleasure to announce that this standard has been CONDITIONALLY ACCEPTED.

Let me be the first to congratulate Wieger for his very valuable contributions. Let me also thank the reviewers on the various forums and by email for their insightful comments. I have received several private and public comments on the thoroughness of the documentation and the quality of Wieger's proposal. From private discussions with Wieger last summer (prior to the publication of the draft proposal), I can also personally attest to the exhaustive testing on a huge number of existing PDN files that Wieger went through in order to come up with a quality draft proposal.

The received comments have all been considered into my conditions for the accepted standard. Three main guidelines have been used:
1) Backward compatibility with existing PDN files out there.
2) Recognition of the differences between the various draughts variants throughout the world. This criterion is reflective of the diversity that the FMJD has to support.
3) When in doubt: "do as the chess guys do", i.e. take the PGN standard as a guideline.
Below I list the conditions in a Decision/Rationale/Action format.

Code:

Decision: UTF-8 will be the mandatory character set in writing.
Rationale: Backward compatibility (see the comments from sancoder and MichelG on the FMJD forum).
Action: expand the documentation to explain this.


Code:

Decision: a draughts variant's "native" type is the mandatory result format in writing.
Rationale: reflective of the diversity in draughts. This means that the 1-0 1/2-1/2 0-1 result format is not to be used with international draughts (see comments by Ed Gilbert on the FMJD forum).
Action: expand the documentation to include a table of the native result format for each draughts variant.


Code:

Decision: "exotic" results type (plus-draws, 3-0 wins, fractional points, Delft and Beijing formats) are supported through a ResultFormatTag in the game header.
Rationale: reflective of the diversity in draughts.
Action: expand the documentation to include a table of values for the ResultFormatTag.


Code:

Decision: elapsed time per move is as a comment in the DGT format (i.e. using the keywords %clk, %emt, %egt, etc.).
Rationale: backward compatibility and the existing practice in chess.
Action: expand the grammar to specify the comments keywords.


Code:

Decision: matches with accumulating time usage (Georgiev-idea) are treated as separate games. The resulting asymmetric time controls at the start of each game are handled through a pair of TimeControlWhite and TimeControlBlack tags.
Rationale: backward compatibility with existing PDN files (notably TurboDambase), while also enabling the full animation of the move-by-move time progress during such matches (e.g. on Toernooibase, see the comments by Piet Bouma on the FMJD forum).
Action: expand the grammar to specify the new tags.


Code:

Decision: a draughts variant's "native" notation (alphanumeric vs. numeric and the move and capture separators) is the mandatory format for writing.
Rationale: reflective of the diversity in draughts. This means that Russian and Czech draughts have to be written in the alphanumeric format, that Russian captures have to use ":", and that Thai captures have to use "-".
Action: expand the documentation to include a table of these formats and separators.


Code:

Decision: the move separators are optional for reading, mandatory for writing in numeric format and only optional for writing in alpha-numeric format.
Rationale: backward compatibility with existing PDN files (see comment by sancoder on the FMJD forum). Note that non-conforming programs that are writing numeric moves without separators, should use double-digit numeric values to at least maintain reading conformance. So 0106 can be read but 01-06 or 1-6 are mandatory for writing.
Action: expand the grammar and the documentation.


Code:

Decision: captures can contain the full capture sequence in reading, but are only allowed to do so in writing for ambiguous captures.
Rationale: backward compatibility with existing (mostly Czech) PDN files (see comments by Gerard Taille on the FMJD forum).
Action: expand the documentation to reflect these semantics.


Code:

Decision: disambiguated capture sequences have to specify the entire sequence of turning points. A turning point is either the square immediately behind a captured piece, or the square where a turn of direction was made. Leaving out a turning point that is not necessary for the disambiguation is forbidden.
Rationale: backward compatibility with existing PDN files and simplicity.
Action: expand the documentation to reflect these semantics.


The course of events is now that Wieger will implement the modifications above in the coming weeks, and that the resulting PDN 3.0 grammar and documentation become the new FMJD standard.

On behalf of the World Draughts Federation FMJD,

Wieger Wesselink - PDN 3.0 draft submitter
Rein Halbersma – Review Manager
Marcel Kosters – Review Wizard
Frank Teer – FMJD Secretary General