Frequently Asked Questions

Is this a replacement of PGN?
This format seems complicated to me.
If the format would be universal, you should consider multidimensional chessboard (3D) and maybe other board games, similar to chess.
I don't really see the need for the XML format.
XML is certainly going to bloat things badly, size-wise.
PGN is human-readable, which I consider an advantage. I like to be able to look at individual games, and wading through the XML stuff is a pain.
The basic problem remains. If someone wants to use your new format, they are going to have to write/add code to their engine, just as they do for PGN.
Why did you choose to go with XML rather than using something more modern and readable, but equally easy to parse like JSON or YAML?
I'm not so sure that the proposed format will get any wide acceptance.

1. Is this a replacement of PGN?

Not at all, I've developed a format for data interchange between modern applications, and this is a different goal. It's absolutely impossible to transfer chess games from ChessBase to Scidb or vice versa via PGN, PGN does not know about the existence of the various languages in the world, and PGN does only know the existence of post commentaries and NAGs. But ChessBase and Scidb are quite more elaborated than PGN can support. In general a chess game is ruined with the transfer via PGN between ChessBase and Scidb.

2. This format seems complicated to me.

C/CIF is defined for data interchange, and it is planned that this format is useful for any application. This is not an easy thing, because I don't know about the features of any application. So the format is defined in a way that any application can add extensions without a violation of the defined standard, and it is expected that this format is already providing all the esseentials without the need of extensions. And some details are in fact super-complicated, for example the application independent mapping of country codes. But the C/CIF library will provide many useful functions for the mapping.

3. If the format would be universal, you should consider multidimensional chessboard (3D) and maybe other board games, similar to chess.

Also the support of multidimensional chess is possible, although this requires a little trick: the boards will be connected to one board, with an appropriate mapping of the moves, and an adopted piece description.

4. I don't really see the need for the XML format.

XML is only the human readable version, and it's the basis for the definition. XML looks bloated, but the basis for C/CIF is the structure, and XML is not bloating the structure, it is the appropriate format for defining structured formats. Furthermore XML is fitting 100% to the binary format (and the binary format is the primary format).

For me it's important to have a tool which satisfies the following goals:

It can be used as a human readable format, although this is only sugar.
It fits 100% to the binary format.
It can be used to define the format.
It can be used to describe the format.
It can be used to talk about a structure.
It can be used to test a structure.
It is easy to parse.
It is easy to write.
There are many tools for this format.
It is well known and well accepted, this also means that everybody is understanding this format.
It's an appropriate format to write C/CIF examples (nobody could read the binary format).
Mapping between the text format (XML) and the binary format is easy, straight forward, and performant.

XML is satisfying this, and when mapped to the binary format, which has the same structure, all the bloating will disappear.

5. XML is certainly going to bloat things badly, size-wise.

CIF (the XML format) is not the primary format - CIF is defining the format - and I'm optimistic that the primary format CCIF (a compact binary format) will produce much smaller archives than PGN.

6. PGN is human-readable, which I consider an advantage. I like to be able to look at individual games, and wading through the XML stuff is a pain.

The user normally will not see the content of C/CIF files, so it must not be human readable. The fact that also an human readable format exists is only an addition. I think the crux is to distinguish between PGN and C/CIF. I've developed a format for data interchange between modern applications, and this is a different goal.

For such tasks like viewing the archive by humans PGN is more appropriate. But is seems that there is a good chance to convert the CAN notation to SAN without too much effort. This means it might be possible to build a simple viewer for the C/CIF format, displaying the very appreciated SAN notation.

7. The basic problem remains. If someone wants to use your new format, they are going to have to write/add code to their engine, just as they do for PGN.

I agree that for applications like a chess engine C/CIF is currently not of interest, but probably this might depend on the supported chess variants of the engine. In fact for chess applications like chess databases PGN is not usable for a loss-free data interchange. Even some basic features, for example multilingual comments, are not supported by PGN.

But this project will also provide a minimal library (supporting the required extent for PGN) especially designed for chess engines will be provided, and I expect that many chess engined will integrate the support.

8. Why did you choose to go with XML rather than using something more modern and readable, but equally easy to parse like JSON or YAML?

JSON or YAML might be the modern format, but both does not provide the elaborated features required for the definition of CIF. Strictly speaking both formats (JSON and YAML) are designed for specialized document formats (for example Markup languages for the Wiki), and are not useful for the data format of C/CIF. Furthermore XML fits 100% to the binary format, and the binary format is the primary format of C/CIF, the text format is only and addition.

9. I'm not so sure that the proposed format will get any wide acceptance.

I'm not sure, too, but everything needs a start. In fact, there exists no alternative to C/CIF for the transfer of chess archives between modern chess databases like Scidb or ChessBase. Moreover this format is the result from the experience with the developing a chess database application since more than seven years.

Topics