Thanks for documenting current usage, Andries. It helps to know which properties are being used and how. However, your focus on games gives a skewed picture of many properties that are crucial to SGF. Also, replacing prescriptions with recommendations is not the right direction: If we’re trying to make SGF more useful, and make it easier to write SGF parsers and apps dealing with SGF, we should be giving stronger recommendations, not relaxing the requirements for some of the properties.
> FF[4] has default character set Latin-1, while the great majority > of non-ASCII SGF files today are in some multibyte character set. > The default should now be UTF-8. Definitely. Using UTF-8 consistently would avoid a lot of issues. SGF parsers still need to deal with other encodings, but should be encouraged to always write UTF-8. > The result is found at > http://www.cwi.nl/~aeb/go/misc/sgf.html > <http://www.cwi.nl/~aeb/go/misc/sgf.html> . Some properties are crucial to describe Go games and problems in a standardized way, the main idea behind SGF. In particular: - Moves: BM (Bad Move), DO (Doubtful move), IT (Interesting move), TE (Tesuji) - Positions: GB (Good for Black), GW (Good for White), DM (Even Position), UC (Unclear position) These may not be used much, but when they are, they have specific meaning, and they need to remain a strong part of SGF going forward. There are a number of markup and display properties in SGF, so your comment about SGF not being about displaying games is misguided. SGF is used by many to create diagrams for Go books; FG (Figure), AR (Arrow), and LN (Line) don’t belong among obsolete properties. Properties for Go problems also need more standardization, not be thrown in the obsolete bucket. Some other properties are used mostly by SmartGo. For example. CH (Checkmark) and HO (Hotspot) are general ways for the user to mark positions of interest, and SmartGo provides tools to search for such position, or e.g. export diagrams of all positions marked in a certain way. These properties are actively used, not obsolete. It would be good if your document would clearly state which properties are part of the FF[4] standard and which ones you’re adding. For example, JD (Japanese Date) is not in FF[4], yet is listed as “standardized in this document”. It’s possible that such a property should be added, but any properties added to FF[4] need to be clearly marked so they can discussed. > In a few cases I do not know the meaning of some labels - information is > welcome. BS (Black Species) and WS (White Species) are valuable to distinguish computer players from human players (0 = human, > 0 for computers). These root properties are part of FF[3] and are still actively used in both SmartGo and SmartOthello (https://smartothello.com <https://smartothello.com/>). E was supposed to be used to indicate which stones were captured by a move, and should be part of that same node, but that was not a good idea. Use of that property should be discouraged (and it’s rightly not part of FF[4]). PB, PW: For Pair Go games, ranks should be part of BR, WR, also separated by "&". The alternate markup style you mention should be discouraged. This is an example where the SGF standard should provide more guidance, not provide multiple alternate ways of expressing the same thing. While we’re talking about SGF: The mistake of using a different coordinate system can’t be undone, but I’d like to encourage all programmers of SGF parsers to allow reading of standard coordinates (A1…T19). Anders Kierulf
_______________________________________________ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
