As part of the ictk.sourceforge.net Java library I've implemented a
PGN reader/writer. While the PGN spec is rather simple, it's also
unclear. For example it does not seem to restrict the placement of {
} type comments. Thus some readers/writers will allow comments after
the TAG block and before the first move. Some will allow a comment
before the first move in a variation.

For example:
[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "1-0"]

{comment before move} 1.e4 1-0

[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "1-0"]

1.e4 e5 ({comment before variation} 1...c5 ) 1-0

My questions are these:
Is this allowable (or an evolution of) the PGN spec?
How often is this sort of thing implemented by readers?

and most of all:
What would you expect to happen to the variation comment if this
variation were promoted to the main line? Should it now become the
comment of the former main-line (now demoted to a variation)?

Obviously, keeping it as a comment before the move will _not_ work.
If the original looks like this:

1.e4 {best by test} e5 ({comment before variation} 1...c5) 1-0
Since the result would be:
1.e4 {best by test} {comment before variation} 1...c5 (1...e5) 1-0

While the spec doesn't seem to explicitly forbid it (it doesn't seem
to forbid much) it would probably break most readers.

Suggestions?

-jvarsoke

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JVarsoke wrote:

1.e4 e5 ({comment before variation} 1...c5 ) 1-0

My questions are these:
Is this allowable (or an evolution of) the PGN spec?

I think reading the "formal specification" you could argue that a
comment before the first move are not allowed (but then neither are
comments!), most parsers accept a comment before the first move in input
format (the spirit if not the letter of the standard).

Some people have chosen to put in a leading comment in a "tag" when
producing "export" format, I'm not sure this doesn't just lead to subtle
changes to files with time, which is probably best avoided.

Similarly comments before RAV moves should be allowed for similar reasons.

How often is this sort of thing implemented by readers?

and most of all:
What would you expect to happen to the variation comment if this
variation were promoted to the main line? Should it now become the
comment of the former main-line (now demoted to a variation)?

Probably, but we have no reason to think the comment will make "sense"
in the mainline, so whether comments are maintained in such situations
would depend on the, presumably human(?!), "editor".

1.e4 ( { white prefered to avoid d4 because of } 1. d4 ... )

Or the situation where there are recursion at the same level as a comment

1. e4 ( { A } 1. d4 ( { B } 1. g4 ))

Does that become "{A} {B} 1. g4" or "{B} 1. g4"


Obviously, keeping it as a comment before the move will _not_ work.
If the original looks like this:

1.e4 {best by test} e5 ({comment before variation} 1...c5) 1-0
Since the result would be:
1.e4 {best by test} {comment before variation} 1...c5 (1...e5) 1-0

While the spec doesn't seem to explicitly forbid it (it doesn't seem
to forbid much) it would probably break most readers.

I don't see a problem here, do you mean you think multiple comments
shouldn't be allowed? At least one reader isn't phased by multiple
comments

Suggestions?

I think anyone who has tried to write a parser (or maintain one as in my
case), or mechanically manipulate PGN, knows the specification is
imperfect (including from their comments the original authors).

You either live with being liberal with what you accept, and try and
print descriptive error messages and fail nicely, or join the ChessML lobby.

What is the prevailing opinion on revamping the PGN specification?
Especially the formal specification. I'm thinking can we refine the
formal specification to a point where the compliance of a file can be
assessed mechnically (except perhaps legal move issues), allowing
programmers to say "this far and no further" if they want, whilst still
reliably preserving all comment and variation information in the game.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/FJcgGFXfHI9FVgYRAjfKAJoC+EvnVlFBwCurp/pEwuxzmVlhlwCgmSKk
DKiKNtFyCXAk+ECubZgg21o=
=bxXG
-----END PGP SIGNATURE-----

In article , JVarsoke wrote:

You either live with being liberal with what you accept, and try and
print descriptive error messages and fail nicely, or join the ChessML lobby.

Yes. Unfortunately, ChessML isn't too popular. But I plan to
implement it later (way down on the TODO list).

ChessGML seems to be more popular which does not mean it's popular.

Which reminds me: I totally forgot to send me my chess opening
classification code. I am sorry. You can get a copy at
URL: https://sourceforge.net/projects/grue-cdb/ . If you're still
interested package ChessOpeningClassify has both jar and tar.gz files.

License is GPL.

--
Ari Makela http://arska.org/hauva/

"Deux fous gagnent toujours, mais trois fous, non!" - Alexander Alekhine

Simon Waters wrote:

I think reading the "formal specification" you could argue that a
comment before the first move are not allowed (but then neither are
comments!),

I doubt that that conclusion is correct. Chapter 5 says that
comments may appear in PGN data, though there's no formal definition
of that term. Informally, it is used in several places to indicate
'full' collections of PGN games, not just the movetext part.

Perhaps there's something else that suggests otherwise?
You're not thinking of annotations (i.e. NAG glyphs) ?

What is the prevailing opinion on revamping the PGN specification?
Especially the formal specification.

It's needed.


--
Anders Thulin http://www.algonet.se/~ath