Optimised Algebraic Notation

[dangi12012]

People don't care about SAN in PGN, that's complete nonsense.

Indeed, the typical user doesn't care. Whoever tries to implement a PGN parser is forced to care, though.

What people care about is that there is a format that can be exported and imported in any chess software, and it just works. Any new "improved" format would break this number one feature.

Yes, that's what I was trying to point out.

The setting for long or short notation is just a GUI option for the users with no relation to the file content format.

Not only for the user, also from a programmers viewpoint it's probably just one branch when parsing a move. Trouble for the user is, that unless the developer of whatever software he's using to import PGN chooses to provide that option he can't read "new" PGN files that use a different move notation. There would have to be some consensus among avtive developers to change most freeware programs to provide the option. Elsewise all complaining about how crap SAN is will not help. I have a hunch that it's not going to happen...

You had something before PGN. It died too. So change is possible.
The thing is you cant rely on json or something existing because you need it to be "human readable" and easy to parse. So really you just need pgn without ommitting any data (dont rely on whats on the board) and thats all thats needed. Each move should speak for itself without a complex code behind it.

It can rely on a board but really source and target should be enough with a special case for: PROMOTION, EP, CASTLING

[hgm]

People don't care about SAN in PGN, that's complete nonsense.

Indeed, the typical user doesn't care. Whoever tries to implement a PGN parser is forced to care, though.

What people care about is that there is a format that can be exported and imported in any chess software, and it just works. Any new "improved" format would break this number one feature.

Yes, that's what I was trying to point out.

The setting for long or short notation is just a GUI option for the users with no relation to the file content format.

Not only for the user, also from a programmers viewpoint it's probably just one branch when parsing a move. Trouble for the user is, that unless the developer of whatever software he's using to import PGN chooses to provide that option he can't read "new" PGN files that use a different move notation. There would have to be some consensus among avtive developers to change most freeware programs to provide the option. Elsewise all complaining about how crap SAN is will not help. I have a hunch that it's not going to happen...

So it is really just about a hand full of software developers who are too lazy to make the miniscule extra effort required to parse PGN (and in particular SAN, because the rest of PGN syntax is completely trivial)? A group that would like to conspire to force something upon humanity that will not be welcomed?

Sounds like MicroSoft practice...

[R. Tomasi]

People don't care about SAN in PGN, that's complete nonsense.

Indeed, the typical user doesn't care. Whoever tries to implement a PGN parser is forced to care, though.

What people care about is that there is a format that can be exported and imported in any chess software, and it just works. Any new "improved" format would break this number one feature.

Yes, that's what I was trying to point out.

The setting for long or short notation is just a GUI option for the users with no relation to the file content format.

Not only for the user, also from a programmers viewpoint it's probably just one branch when parsing a move. Trouble for the user is, that unless the developer of whatever software he's using to import PGN chooses to provide that option he can't read "new" PGN files that use a different move notation. There would have to be some consensus among avtive developers to change most freeware programs to provide the option. Elsewise all complaining about how crap SAN is will not help. I have a hunch that it's not going to happen...

So it is really just about a hand full of software developers who are too lazy to make the miniscule extra effort required to parse PGN (and in particular SAN, because the rest of PGN syntax is completely trivial)? A group that would like to conspire to force something upon humanity that will not be welcomed?

Sounds like MicroSoft practice...

Where do you get the idea anyone is forcing anything upon you or others from? And it's not exactly the lazy thing to do, isn't it? After all there's no way around parsing existing PGN anyways, right?

Microsoft practice would rather be to stick with some badly designed API / standard to maintain backwards compatibility with a 16bit OS...

[hgm]

The long term goal here seems to be to eliminate PGN. If not, it is an even worse crime against humanity: you would have created two mutually incompatible standards that would coexist forever, and all serious developers would have to implement both of them. XBoard accepts an extremely wide range of move notations (e.g. g1f3, g1-f3, g1xf3, Ng1f3, Ng1-f3, Ngf3, Ng-f3, N1f3, N1-f3, N-f3, Nf3, G1-F3, 8b6c, 8b-6c, 8bx6c, N8b-6c, N-6c plus some stuff I cannot easily post here because it involves Japanese kanji in UTF-8 or ShiftJIS encoding), and is extremely tolerant versus garbage in between the moves. But the garbage must not accidentally mimic PGN elements; enclosing moves in {braces} would be fatal, as they would then be considered comments.

[leanchess]

The thing is you cant rely on json or something existing because you need it to be "human readable" and easy to parse.

JSON is exceptionally easy to parse using an external library. As for readability, it can be formatted to become fairly readable.

YAML is a possible alternative, but it's somewhat less abundant.

XML is the worst, but that didn't stop Gregor Cramer of Scidb fame from trying.

I still believe a PGN replacement is long overdue. Too bad Tord Romstad didn't follow through on his promise.

[R. Tomasi]

I still believe a PGN replacement is long overdue.

I think an extension to PGN may be enough. Something similar to the mechanism used for SetUp positions: An additional Tag ["PGNversion"], if present in the file it could indicate that the file is using a specific format for the movetext (and maybe other new features, depending on the version).

Winboard - telling by HGMs last post - for example, should be able to read it without any changes at all if the format used in the movelist does not contain curly brackets.

[Fulvio]

Trouble for the user is, that unless the developer of whatever software he's using to import PGN chooses to provide that option he can't read "new" PGN files that use a different move notation. There would have to be some consensus among avtive developers to change most freeware programs to provide the option.

I don't think it would make a difference.
SCID already reads both PGNs with moves SAN (Nf3) or uci (g1f3) which is better in my opinion.
The problem is that from the user's point of view there are only disadvantages (a PGN that in some programs would not be readable) and no advantages.

[leanchess]

I think an extension to PGN may be enough. Something similar to the mechanism used for SetUp positions: An additional Tag ["PGNversion"], if present in the file it could indicate that the file is using a specific format for the movetext (and maybe other new features, depending on the version).

Winboard - telling by HGMs last post - for example, should be able to read it without any changes at all if the format used in the movelist does not contain curly brackets.

IMHO a mere extension won't solve the problem, since any new software would be forced to deal with the many PGN quirks.

I've been also looking at PGN derivatives like PSN and PDN. They could all be replaced by a single properly defined format.

[hgm]

I still believe a PGN replacement is long overdue. Too bad Tord Romstad didn't follow through on his promise.

Thank you for this link. I must say, though, that the objections raised by Tord versus PGN are rather trivial, if not to say silly. That there is no standard for annotating score-depth info within comments... The obvious solution then is to define such a standard, but not mess with anything else, so it remains fully backward compatible with PGN. Extending a standard in an area it formerly left undefined is always OK. Making a point of variations before or after the move is just silly, as a move takes almost no space, so that the this would hardly change the location of the comment. And since his idea was that the format was not intended for human reading, it is up to the software how to display comments w.r.t. the moves they belong to. The demand for ANSI latin-1 encoding has already been abandoned wherever this is not convenient. Mark-up codes in the comments? Well, the PGN standard allows that. It just looks annoying if you would read it as plain text, but if you want to do that there is no reason not to use it in PGN comments.

PSN was of course a silly invention, born from some innate desire in the Shogi community to do everything in an incompatible way. Of course Shogi games can be perfectly recorded as PGN / SAN, and this is exactly what WinBoard does. (With the minimal extension that + does not mean check but promotion there.) I never looked at PDN.

[Ras]

Trouble for the user is, that unless the developer of whatever software he's using to import PGN chooses to provide that option he can't read "new" PGN files that use a different move notation.

Exactly, which is why the "new" format would not be used unless all developers of all software, both free and commercial, agreed to add support for that format at the same time. Note that these are the devs who already have a PGN parser in their software and hence don't have to care anymore whether writing a parser is "cumbersome". Especially commercial authors don't even have any interest in making the market easier to enter for new competitors. But even if they did, people have tons of PGNs around and will not be willing to convert them all because things just work already. On top of that, GUI authors would still have to implement a SAN parser because CECP engines may also use SAN.

I have a hunch that it's not going to happen...

Me neither.