PDN 3.0 Standard Review Request

[Rein Halbersma]

PDN 3.0 Standard Review Request
--------------------------------

This is a request to review Wieger Wesselink's PDN 3.0 draft standard. The goal of this review is to arrive at an official standard that is recognized by the World Draughts Federation (FMJD).

The review period starts October 1st 2011 and ends January 31st 2012.

The documentation is available here: http://10x10.org/pdn/
An online PDN 3.0 checker is available here: http://10x10.org/pdn/test/
Earlier draft versions were discussed at this thread at the FMJD forum: http://laatste.info/bb/viewtopic.php?t=2544

The PDN 3.0 draft standard attempts to give a formal definition of PDN, portable draughts notation. It is more formal than previous versions in the sense that grammars are defined, and additional restrictions are documented. It also defines some extensions for setting up positions and for specifying clock times after a move in a game.

The 10x10.org website also gives concrete implementations for 3 different parser generators (DParser, Grammatica, TPG) on 3 different platforms (C, Java & Python). Other parser generators with similar capabilities should also be able to accomodate this grammar. In particular, preliminary research suggests that the given grammar specifications in DParser, Grammatica, TPG are most likely also implementable with Bison/Flex, ANTLR or Boost.Spirit that are available on C/C++ platforms.

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 can be submitted on this thread. There is also room for questions and discussion about the PDN 3.0 draft standard.

The review procedure is as follows: at the conclusion of the review period, the Review Manager will post a message to the World Draughts Forum saying if the PDN 3.0 proposal has been accepted or rejected. A rationale is also helpful, but its extent is up to the Review Manager. If there are suggestions, or conditions that must be met before final inclusion, they should be stated.

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

[Ed Gilbert]

I have made one pass over the docs, and I have a few minor comments.

Tags
----
- "+Draws" were used in the most recent world championship tournament. It seems like the PDN standard should define a result code handle these results.
- I've been using null strings ("") for mandatory tags that have no value, instead of "-" or "?". I don't like "-". "?" is ok, but "" may be slightly more convenient because you don't have to erase the question mark to edit the value, and (for me) the meaning is just as clear.

PDN Reading Grammar
-------------------
- Maybe the reading grammar should allow leading zeroes in square numbers. There are probably existing game files that have these.
- The ".doc" format that Ton Tillmans sends out after Culemborg computer tournaments (is this the Truus format?) has spaces embedded within moves. Examples: 6- 9, or 6x 8. Maybe the reading grammer should accommodate these.
- Are nested comments not allowed? They seem to not be allowed if I am reading the grammar correctly. Weren't they accepted in PDN 2.0? I guess the 3.0 standard should state explicitly whether nested comments are allowed or not.

Setup Commands
--------------
I like the /FEN capability to handle games with missing or illegal moves. We needed something like this during the 2011 world championships.

Game Separator
--------------
- I like using asterisk as the game separator, and not allowing asterisk as a strength indicator. I do not like the option of placing an asterisk strength indicator after a move with no white space. The presence or absence of white space is too subtle and will be missed by most casual users/writers.
- I also agree that using result codes as game separators is bad. But it should be accepted by a forgiving reading grammar for compatibility with legacy programs.

FEN Tag
-------
Using a square number range, e.g. [FEN "W:W31-50:B1-20"], is going to break all existing parsers. Is it worth this headache? I have never tried to write a FEN tag manually. Whenever I have used a FEN tag it was always written by a program. This shortcut seems targetted for people writing FEN tags manually, but I doubt that happens much.

-- Ed

[Ed Gilbert]

I forgot to add...

Tags
----
My personal preference is that Site and Round not be mandatory tags. To me it assumes a formal tournament game of some sort, which is often not the case.

--Ed

[TAILLE]

Hi,

I do not quite understand what is acceptable or not for ambiguous moves.

White to play

In the above example white has the choice between 2 moves. Let's suppose white would like to capture 44, 30, 8 and 11. In the following notations which are correct and which are not?
49x35x24x2x16
49x35x19x2x16
49x35x13x2x16
49x24x2x16
49x19x2x16
49x13x2x16
49x35x2x16
49x35x24x16
49x35x19x16
49x35x13x16
49x35x16
49x24x16
49x19x16
49x13x16
49x2x16

I guess many human bodies will choose the 49x35x16 notation but it is only an assumption of mine!

[Wieger Wesselink]

Hi Ed, thanks for your remarks!

Tags
----
- "+Draws" were used in the most recent world championship tournament. It seems like the PDN standard should define a result code handle these results.

Right, this needs to be added. However, I'm not aware of an official notation for plus draws. Should it be "1+-1-"?

- I've been using null strings ("") for mandatory tags that have no value, instead of "-" or "?". I don't like "-". "?" is ok, but "" may be slightly more convenient because you don't have to erase the question mark to edit the value, and (for me) the meaning is just as clear.

Null strings are valid, and personally I prefer that above "?". In PGN "?" is used to denote an unknows value, and "-" is used to denote 'no value'. I already removed the "-", and if there is a general consensus about it, the "?" notation can be removed as well.

PDN Reading Grammar
-------------------
- Maybe the reading grammar should allow leading zeroes in square numbers. There are probably existing game files that have these.
- The ".doc" format that Ton Tillmans sends out after Culemborg computer tournaments (is this the Truus format?) has spaces embedded within moves. Examples: 6- 9, or 6x 8. Maybe the reading grammer should accommodate these.
- Are nested comments not allowed? They seem to not be allowed if I am reading the grammar correctly. Weren't they accepted in PDN 2.0? I guess the 3.0 standard should state explicitly whether nested comments are allowed or not.

The reading grammar does accept zeroes in square numbers, and spaces embedded in moves. Perhaps I should add a comment about it. Nested comments are not allowed. In PDN 2.0 I did not see a reference to this.

Game Separator
--------------
- I like using asterisk as the game separator, and not allowing asterisk as a strength indicator. I do not like the option of placing an asterisk strength indicator after a move with no white space. The presence or absence of white space is too subtle and will be missed by most casual users/writers.
- I also agree that using result codes as game separators is bad. But it should be accepted by a forgiving reading grammar for compatibility with legacy programs.

Interestingly, I saw that the PGN notations of the world cup chess 2011 also uses an asterisk to separate games.

FEN Tag
-------
Using a square number range, e.g. [FEN "W:W31-50:B1-20"], is going to break all existing parsers. Is it worth this headache? I have never tried to write a FEN tag manually. Whenever I have used a FEN tag it was always written by a program. This shortcut seems targetted for people writing FEN tags manually, but I doubt that happens much.

The number ranges are often used in draughts publications. In my opinion PDN is also meant to be a format that people can enter manually. However, I don't have a strong preference for it, so the number range notation can be removed if needed.

[Wieger Wesselink]

Hi,

I do not quite understand what is acceptable or not for ambiguous moves.

White to play

In the above example white has the choice between 2 moves. Let's suppose white would like to capture 44, 30, 8 and 11. In the following notations which are correct and which are not?
49x35x24x2x16
49x35x19x2x16
49x35x13x2x16
49x24x2x16
49x19x2x16
49x13x2x16
49x35x2x16
49x35x24x16
49x35x19x16
49x35x13x16
49x35x16
49x24x16
49x19x16
49x13x16
49x2x16

I guess many human bodies will choose the 49x35x16 notation but it is only an assumption of mine!

Hi,

good catch, your example shows that this has to be made more precise. Personally I would choose to forbid skipping any squares in the long notation. So only the notations with 5 squares are valid. What do others think about this?

[TAILLE]

Hi,

Hi,

I do not quite understand what is acceptable or not for ambiguous moves.

White to play

In the above example white has the choice between 2 moves. Let's suppose white would like to capture 44, 30, 8 and 11. In the following notations which are correct and which are not?
49x35x24x2x16
49x35x19x2x16
49x35x13x2x16
49x24x2x16
49x19x2x16
49x13x2x16
49x35x2x16
49x35x24x16
49x35x19x16
49x35x13x16
49x35x16
49x24x16
49x19x16
49x13x16
49x2x16

I guess many human bodies will choose the 49x35x16 notation but it is only an assumption of mine!

Hi,

good catch, your example shows that this has to be made more precise. Personally I would choose to forbid skipping any squares in the long notation. So only the notations with 5 squares are valid. What do others think about this?

For the moment Damy does not accept in the notation a square with no direction change. That means that the three following notations are not recognized:
49x35x24x2x16
49x35x19x2x16
49x35x13x2x16
Damy recognizes only the notation 49x35x2x11.
Of course developments are always possible to recognize other notations but it could be a very time consuming job and I am not quite motivated for that.
In know that on very very rare occasions it might happen that Damy does not recognize a specific notation. In that case I have to change it manually.
This standard may help on condition it does not lead to heavy developments

[MichelG]

Some things from a first look at the standard:

• I don't see any use for a move strength indicator in the write-standard, as this is already covered by the NAG's. Also, what is the program to make of this: "23-29! $2", where the movestrength indicator does not correspond to the NAG?
• The standard does not seem to specificy the character set that it is using. I believe the previous versions used ISO-8859-1, but shouldn't we move to something international, like utf-8 unicode?
• I don't see a reason to change the FEN definition. The old one works fine and no one benefits from the new range definition. If you have strong urge to make them shorter, make them binary, then uuencode them.
• The standaard doesn't specify how to handle escape codes. What if you want to use a bracket "}" inside your comments or tags?. I guess it should be "\}", but it doesn't say.

At least in my case (dragon 3.0 and earlier), NAG's break the reader. Dragon 4.0 will be able to handle them though.

Michel

[TAILLE]

Oops, my previous post was not that clear

Damy generates only squares with direction changes i.e.
49x35x2x16

but Damy is able to recognize
49x35x24x2x16
49x35x19x2x16
49x35x13x2x16
49x35x2x16

[Ed Gilbert]

Wieger, is there a link to the pdn 2.0 docs that used to be on 10x10.org? I can't find them now?

Personally I would choose to forbid skipping any squares in the long notation. So only the notations with 5 squares are valid. What do others think about this?

I agree with this. I think a forgiving reader should also accept any subset of these squares that unambiguously describes the move.

-- Ed

[TAILLE]

Wieger, is there a link to the pdn 2.0 docs that used to be on 10x10.org? I can't find them now?

Personally I would choose to forbid skipping any squares in the long notation. So only the notations with 5 squares are valid. What do others think about this?

I agree with this. I think a forgiving reader should also accept any subset of these squares that unambiguously describes the move.

-- Ed

Hi Ed,

In my example I think it is not a great problem to generate in Damy a notation with 5 squares instead of the notation 49x35x2x16.
BTW Kingsrow accepts the notation 49x35x13x2x16 but not the 49x35x19x2x16 and 49x35x24x2x16 notations
Does that mean you are ready to enhance Kingsrow on that point?

[Ed Gilbert]

BTW Kingsrow accepts the notation 49x35x13x2x16 but not the 49x35x19x2x16 and 49x35x24x2x16 notations
Does that mean you are ready to enhance Kingsrow on that point?

Gerard, I was not aware that it wasn't accepting those forms of the move. That is a bug that I should fix.

-- Ed

[Wieger Wesselink]

Wieger, is there a link to the pdn 2.0 docs that used to be on 10x10.org? I can't find them now?

Personally I would choose to forbid skipping any squares in the long notation. So only the notations with 5 squares are valid. What do others think about this?

I agree with this. I think a forgiving reader should also accept any subset of these squares that unambiguously describes the move.

-- Ed

The PDN 2.0 standard can be found at http://www.nemesis.info/pdn2.txt. It is abbreviated as [Nemesis] in the draft standard.

[Wieger Wesselink]

Some things from a first look at the standard:

• I don't see any use for a move strength indicator in the write-standard, as this is already covered by the NAG's. Also, what is the program to make of this: "23-29! $2", where the movestrength indicator does not correspond to the NAG?
• The standard does not seem to specificy the character set that it is using. I believe the previous versions used ISO-8859-1, but shouldn't we move to something international, like utf-8 unicode?
• I don't see a reason to change the FEN definition. The old one works fine and no one benefits from the new range definition. If you have strong urge to make them shorter, make them binary, then uuencode them.
• The standaard doesn't specify how to handle escape codes. What if you want to use a bracket "}" inside your comments or tags?. I guess it should be "\}", but it doesn't say.

At least in my case (dragon 3.0 and earlier), NAG's break the reader. Dragon 4.0 will be able to handle them though.

Michel

Thanks for your comments, Michel.

* You're right that the move strength indicators are redundant. A possible reason for wanting to keep them is that they are human readable, whereas the NAG's are not.

* I did not specify a character encoding. If people think this is necessary it can be added. I have no knowledge about this subject myself.

* If people have problems with it, the range notation in FEN tags will be removed. As I mentioned above, a reason for adding it is that it is a common notation in draughts publications.

* If there is a need for escape codes, they can be added to the standard. Do PGN or other PDN standards mention something about this?

[Piet Bouma]

I have tested some pdn files which I produce in Toernooibase/Tournamentbase in the pdn checker.

I agree with Ed that Null values the best can be reproduced by “”. (I use at the moment “-“) However with
[WhiteTime “”]
I get a warning in the pdn checker, while Wieger says here that this should be valid.
And, I agree again with Ed, for the ‘plus’ draws I think there should be a solution:
1+ - 1- is I think the best way.
But also the “Hiltex results”, f.e. 1.02 – 0.98 or 1.03 – 0.97 etc., (although the Hiltex tournament is not on the calendar anymore) should be in my opinion in the pdn-standard.
They give also warnings in the pdn checker.

For replay of the Plus draws and Hiltex results from pdn it is necessary to know that this results were used. Otherwise you will find it unbelievable that players continue playing in an endgame which is a draw.
Nested tags in comments: I think (I’am not sure), that the analyse-module of Turbodambase produces them in .pdn. To show more variations in comments it is a method to do so. Or do you see other solutions to produce more variations in comments Wieger?