ST property

STyle property: A new ST (STyle) property indicates which style is used for variations, and for text comments referring to variations. Each file should contain a STyle property, old files will get the default style of the reading application. Applications may offer to change the style online.
ST[1] .. Smart Go Board style: assigns letters a,b,... to the possible
         sucessors of the current move.
ST[2] .. mgt style: mgt assigns letters to the possible
         sucessors of the current move.
ST[3] .. xgoban style: xgoban assigns uppercase letters to variations of the
         current move (variation marks).
Comment MM: In xgoban style, should clicking on a letter go to that move (i.e. undo the current move, then execute move), instead of executing a move as usual? What is the difference between SGB and mgt style?

It seems xgoban already supports both styles

Comment Antoine: BTW, don't xgoban do what you describe ? I was pretty sure it would.

I don't like the STyle proposal, because it doesn't really solve the problem. In my opinion, the problem is that comments refer to points on the board by using 'a', 'b', 'c', A, B, C, or even : these references depend on how the system on which those comments were entered automatically generated letters on the board for the next moves or for the alternate moves. That's a UI issue that should not affect the file format. I think a better solution would be to define an escape sequence that can be embedded in comments to directly refer to points on the board. It's then up to the UI to change the comment to refer to whatever letter/number/ mark is displayed at that board point. One proposal would be \'pp' where pp is any board point.

Comment MM: In theory, you are right. In practice, I doubt people would use it. Can one support it through the interface? Ideas? And we have already many commented games with hard-coded 'A', 'B', ... in at least two styles. STyle is intended as a patch to make these comments understandible for all.

Syntax and Consistency Checks

Syntax and consistency checks are far from trivial, and probably beyond the needs of the average Smart Go user. But they are needed for big collections.

General Remarks on SGF direction


Problems in current Smart Go Board implementation

Brackets in text

'(' and ')' are written as '/(' and '/)', in contradiction to the spec. Why? Plain '(' and ')' generated by other programs are skipped during reading.
Comment Anders Kierulf: Using /( and /) in comments was originally a feature: it allowed programs to more easily parse the tree structure. But I agree it's probably more of a bug.

timing info

Tim Casey: IGS uses seconds for all of the timing info, and Smart Go uses 'ticks', which are internal and not very useful. I would suggest using seconds.
Martin Müller: Agree that Ticks is not useful. According to Anders' thesis, time should be seconds, as a real number. Maybe it is not implemented properly, using 'ticks' as a cheap approximation of 'real'? We need fractions of seconds for computer play and measurements, I think.

Reading real's

IGS writes Komi with trailing 0's, SGF does not parse that correctly. e.g. KM[0.500000]

Text preceding the first parenthesis

The old spec states: "Any text before the first opening parenthesis is reserved for future extensions and is ignored when reading a file." In SGB this is not true anymore, since it will now try to interpret such text as an Ishi file.