PDN 3.0 Standard Review Request

[MichelG]

* 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.

I feel it should be included in the standard. All microsoft software (and i think all linux as well) supports unicode, and it prevents problems with names and comments that are not dutch or english. If you write your program in visual studio 2000 or later, this should not add complexity to the reader.

I suggest to do it the way microsoft writes texts, by using a byte order mark. (See http://nl.wikipedia.org/wiki/UTF-8)

Example that is not possible in ascii, with a chinese and a russian name:

Code: Select all

[White "壩方案"] 
[Black "плотина программы"] 
[Result "*"] 
[Date "2011.10.03"] 
[Event ""] 
[Site ""] 
[Round "?"] 
1. 32-28 19-23 2. 28x19 13x24 3. 33-28 * 

Michel

[Ed Gilbert]

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

I didn't explain it well, but what I was actually looking for was the PDN docs that used to be on 10x10.org before the 3.0 descriptions appeared. It's not very important, but if the files are still on the server I'd like to take a look if you can give me a link.

-- Ed

[Rein Halbersma]

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.

AFAIK, all PDN files in practice have an empty line in between games. Why not define a sequence of 2 or more "\n" tokens as a game separator? This should still allow text editors to use hard line wrapping (i.e. a single "\n") between moves. This way, one could simply ignore the *-separator or the end-of-game result altogether, so it would be backwards compatible as well. Of course, it would require to redefine the skip-all-whitespace grammar rule.

Rein

[Wieger Wesselink]

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?

Hi Piet, thanks for your comments. The PDN checker indeed gives a warning for [WhiteTime ""]. This is an oversight from my part. I use regular expressions to check the format of time and date values, but did not allow the empty string. I will correct that. Also I will make it explicit in the standard that the empty string is always allowed for a tag value.

You wrote spaces in the notation of the plus draw: "1+ - 1-". Are these spaces obligatory or optional?

I wonder how tournaments with special results and rules should be handled. How much of this does belong to the standard? Obviously the plus draw needs to be defined by the standard, since it is being used in official FMJD tournaments. But I'm less sure about the "Hiltex results".

What do you mean by "Nested tags in comments"? Can you give a small example that is not accepted by the standard? Note that this is different from nested comments.

[Wieger Wesselink]

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

I didn't explain it well, but what I was actually looking for was the PDN docs that used to be on 10x10.org before the 3.0 descriptions appeared. It's not very important, but if the files are still on the server I'd like to take a look if you can give me a link.

-- Ed

In a previous version comments were allowed to have embedded curly braces using escape characters "\{" and "\}". But I removed it from the draft standard, since I wasn't convinced that there is much need for it. Previous versions are no longer online.

[Ed Gilbert]

I have some questions about writing Result tags.

Which of the following 3 statements is true, according to the 3.0 standard?

1) The Result tag values 1-1, 0-2, 2-0 should always be used for writing PDN if the game type is international draughts, and the values 1/2-1/2, 0-1, 1-0 should always be used for English checkers.

2) Result tags should always be written using the values 1/2-1/2, 0-1, 1-0, regardless of the game type.

3) A program writing PDN can choose to write either format of Result tag values, regardless of the game type.

A related question, if the answer to the above question is either 1) or 2):
If a program reads a PDN file that contains the Result value 1-1, but the game type is 8x8 English checkers, if that program subsequently outputs the game as PDN, should it output the Result value as 1/2-1/2, or exactly as it read it, 1-1?

-- Ed

[sancoder]

A word about FEN notation.
In russian checkers fields are named as follows:
a1, c1, e1, g1, b2, d2, ...

I have tried to specify the field by such a name, but PDN checker rejects this.
I think, there is a problem here. Moves are specified as c3-d4 f6-g5, and this is ok.

Another problem is that PDN checker gives me warnings on this example.

Code: Select all

[White "WhiteTest"]
[Black "BlackTest"]
[Event "EventTest"]
[Result "*"]
[GameType "26"]
[FEN "W:W29,30,31,32,25,26,27,28,21,22,23,24:B9,10,11,12,5,6,7,8,1,2,3,4"]
1.c3-d4 f6-g5 2.d4-c5 b6:d4 3.e3:c5 d6:b4 4.a3:c5 g5-f4

Why?

Also, I vote for UTF-8 as the main encoding for files.
The problem I see is about compatibility. If the old program cannot parse the PDN file with a BOM, it will be not desired.
The alternative way is to base64-encode the name as in the e-mail programs.

[MichelG]

Also, I vote for UTF-8 as the main encoding for files.
The problem I see is about compatibility. If the old program cannot parse the PDN file with a BOM, it will be not desired.
The alternative way is to base64-encode the name as in the e-mail programs.

Base64 enconding the names will make them unreadable/unwritable to a human entering the game, so i think that is undesirable.

I think most programs will ignore the BOM. To them, it should just be a series of random characters at the start of the file. I tried an UTF-8 file with dam 2.1, and it can read it; the window displaying the games is a bit messy and the names are unreadable, but the game is imported.

Michel

[TAILLE]

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?

I agree we need to specify whether the game use or not the Plus draw rule. Does that mean we have to define another game type? The point is that the result 1-1 (or 1/2-1/2) does not give any hint on the use of this rule.

[ildjarn]

- Why are leading zeroes explicitly disallowed in moves (01-07 is an illegal syntax) but allowed in FEN?
- How does one indicate there are no pieces of a certain colour? Should this be allowed? (It can be useful in diagrams to show a certain structure, but for games it's probably a bit useless)
- Last game doesn't need a game ending tag (*). Is this intended? It'd make adding games to a PDN file later slightly easier (you don't have to check if the last game is properly closed before pasting the new game)

[TAILLE]

According to Nemesis PDN defintion :

SIMPLIFIED JUMP FORMAT:
When the start-to-finish move sequence is not ambiguous, (i.e. there
exists at most 1 legal move with that start and finishing squares),
the move definition can be simplified to the following:
[[SQ_START][DELIMITER][SQ_FINISH]]

Seeing the word "can" in the above sentence my question is the following:
For PDN 3.0 standard, is the long notation acceptable even for unambiguous moves?
Note that for a human body the long notation is really needed if a lot of pieces have to be captured!

[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?

Hi Piet, thanks for your comments. The PDN checker indeed gives a warning for [WhiteTime ""]. This is an oversight from my part. I use regular expressions to check the format of time and date values, but did not allow the empty string. I will correct that. Also I will make it explicit in the standard that the empty string is always allowed for a tag value.

You wrote spaces in the notation of the plus draw: "1+ - 1-". Are these spaces obligatory or optional?

I wonder how tournaments with special results and rules should be handled. How much of this does belong to the standard? Obviously the plus draw needs to be defined by the standard, since it is being used in official FMJD tournaments. But I'm less sure about the "Hiltex results".

What do you mean by "Nested tags in comments"? Can you give a small example that is not accepted by the standard? Note that this is different from nested comments.

Spaces should be optional I think. I don't like 1--1+.
Also you could consider to have the results all numeric. Plus-draws you could possible show with 1.1-0.9?
Results of the earlier Hiltex-tournaments are accepted by FMJD in the ratinglists (although I think that the results 1.01 - 0.99 etc. are adjusted to 1-1, when the rating is calculated.
In my opinion there must be room for different results in the Result-tag, so new experiments (maybe the FMJD does this in the future? ) can be shown with the right results.
To specify this as a new GameType seems to me overdone. Basic rules stay the same.

Nested tags is a mistake. I mean nested variations in comments. Sorry.

[Wieger Wesselink]

I have some questions about writing Result tags.

Which of the following 3 statements is true, according to the 3.0 standard?

1) The Result tag values 1-1, 0-2, 2-0 should always be used for writing PDN if the game type is international draughts, and the values 1/2-1/2, 0-1, 1-0 should always be used for English checkers.

2) Result tags should always be written using the values 1/2-1/2, 0-1, 1-0, regardless of the game type.

3) A program writing PDN can choose to write either format of Result tag values, regardless of the game type.

A related question, if the answer to the above question is either 1) or 2):
If a program reads a PDN file that contains the Result value 1-1, but the game type is 8x8 English checkers, if that program subsequently outputs the game as PDN, should it output the Result value as 1/2-1/2, or exactly as it read it, 1-1?

-- Ed

Nothing is specified, so in practice this means option 3). In practice both 1-1, 0-2, 2-0 and 1/2-1/2, 0-1, 1-0 are used for international draughts. If there was a requirement, I would choose for 1).

[Wieger Wesselink]

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.

AFAIK, all PDN files in practice have an empty line in between games. Why not define a sequence of 2 or more "\n" tokens as a game separator? This should still allow text editors to use hard line wrapping (i.e. a single "\n") between moves. This way, one could simply ignore the *-separator or the end-of-game result altogether, so it would be backwards compatible as well. Of course, it would require to redefine the skip-all-whitespace grammar rule.

Rein

A small problem with this approach is that often there is an empty line between the tags and the moves of a game. It is then no longer clear when two "\n" tokens should be interpreted as a game separator.

[Wieger Wesselink]

A word about FEN notation.
In russian checkers fields are named as follows:
a1, c1, e1, g1, b2, d2, ...

I have tried to specify the field by such a name, but PDN checker rejects this.
I think, there is a problem here. Moves are specified as c3-d4 f6-g5, and this is ok.

Another problem is that PDN checker gives me warnings on this example.

Code: Select all

[White "WhiteTest"]
[Black "BlackTest"]
[Event "EventTest"]
[Result "*"]
[GameType "26"]
[FEN "W:W29,30,31,32,25,26,27,28,21,22,23,24:B9,10,11,12,5,6,7,8,1,2,3,4"]
1.c3-d4 f6-g5 2.d4-c5 b6:d4 3.e3:c5 d6:b4 4.a3:c5 g5-f4

Why?

Also, I vote for UTF-8 as the main encoding for files.
The problem I see is about compatibility. If the old program cannot parse the PDN file with a BOM, it will be not desired.
The alternative way is to base64-encode the name as in the e-mail programs.

Hi sancoder, thanks for noticing this! The PDN checker seems to have an error in the check for spaces in alpha-numeric moves. I will fix this next week (right now I don't have the opportunity to look at it). The grammar itself seems to be correct.