Indeed, I am always trying to separate variant- and piece naming from FEN
representation. In SMIRF I made a first approach to that using X-FEN as
published. But including Janus or Optimized Chess produced a lot of
encoding problems, just by having different piece type letters. I learned,
that this was an unnecessary complication, which should be avoided. Think
on different piece names and abbreviating letters in different countries
for traditional chess. Those are part of the PRESENTATION of the game,
thus belonging to the GUI. Piece letters on the surface simply are a
comment to the underlying pieces, thus not being absolute. But a
calculating engine has no need to communicate multi language wise, it
simply has to use well introduced unique international (english) letters
PNBRQK. That is, why I have not yet included SMIRF's current
representation of Janus or Optimized Chess into the X-FEN concept, because
that has been the wrong approach. X-FEN has to be extended to include a lot
of variants in a generic and universal way. Variant names are only
comments, even though I know, that Winboard handles it as a definition.
But have a look at Chess, Chess960 and castlingless random chess. Having
X-FEN will cover all of them doubtlessly, thus avoiding any need to
explain more than X-FEN to fully describe a position. Chess960 as a
variant title then therefore merely is a comment. A lot of variants
include each other, e.g. think of CRC. Sometimes it is not to be decided
to which variant a position belongs, and there is in fact no need to.
Moreover this would not make any sense, as in Shredder FEN that is
creating confusion encoding identical positions by different FEN strings.
All Chess positions e.g. could be regarded as Chess960 positions.
