> For instance just say that the file is UTF-8 & uses > CAN and most of your problems go away.
What is CAN, I never heard this before. > However, suppose we separate the movelist from the commentary > ... > 2. the commentary - which is fundamentally sequential - can be stored in > an extended type of HTML perhaps. Provided it is possible to identify the > actual move from text & variations, rendering of the commentary could > almost be managed by CSS. If the moves were in divs (or spans) with unique > Ids corresponding to move-ply then it is maybe just plain HTML In fact this is too complicated for my purpose, you are thinking one step ahead, but the only thing I want is to interchange/store data without any loss in a simple way, and PGN is not providing this. In my opinion you are proposing a format for more elaborated purposes, online rendering for example. But the intended format should not be expected to provide more than this store & interchange capability. For other purposes other formats will be invented. Due to my experience it is not a problem to have a special format for each special purpose, in this way you can keep each format simple and clean. If a format is simple and clean, writing a parser in general is not more than a finger exercise (indeed it's always a bit time consuming, especially testing). Gregor
