Re: ** SGF FF **
- John Fairbairn <JF@...> wrote:
> There seems to be a trend to make the spec fit the needs ofCould you describe the needs of an ordinary user?
> the big fish - the databases, IGS, or Nihon Ki-in. Ordinary users seem
> to have different needs.
While creating FF I posted to rec.games.go that I like suggestions by
users about their needs. IIRC, I got about 5 replies, ALL of which were
about program issues and not file format issues. To me it seems that
there are only few programs which are truly user-friendly.
> Arno tells me that most SGF files he gets from other people are incorrect.Apart from the usual DT[Jan 4th 1991] or RE[Black wins] most errors are
made by the programs. Most of the time when using variations. Is
reading/writing variations really so tough? The range of errors that
I come across never ceases to amaze me.
Standard call: Use SGFC to check the output of your application !!!
> That tells me that most users want to prepare their files inI argue that it's because of sloppy programs and not because of SGF.
> ways that the spec won't let them.
> Human nature demands that the spec should change to suit them,I agree. But the spec itself should (almsot) be transparent to the user.
> rather than users be dragooned into complying with an increasingly
> complex spec.
But this is the task of applications. Of course the spec should make
it easy to create SGF compliant applications.
Coming back to the "big fishes": this is why I think "property sets"
are a good idea. "Little users" use the basic sets which suit there
needs. And the "big fishes" use extended sets to store all the
information they want to store.
> but I don't see why the search engine could not be programmed to scan aThis is true. However, if you want to have interchangeable SGF games
> single line of free text for whatever the database regards as key words.
you would need to specify those key words. Otherwise everyone would
have to write a conversion program for their database. And if we can
agree on key words, why not make them properties, such as EV & RO?
> ... the old handicap system (B-B-W) ...These issues will be addressed in FF.
> ... DT date a major problem ...
> ... EV and RO a problem in various ways ...
> ... find RE a problem ...
> ... TM: Don't forget that players may be given different times
Also, see Jan's suggestions for team players and other information.
> "Played 1845-03-03 and through the night till 9pm theI think that this information should be put into GC and that DT
> following day" [nb putting 1845-03-03,04 would omit the interesting
> point that they played non-stop].
should contain 1845-03-03,04.
> (1) that FF5 would be an advance if it actually went backwardsYes. Many of us agree on this.
> a little bit - in particular it should allow free-form text where possible
> (3) the needs of ordinary users - people who enter game records,I agree. As pointed out above, most users are concerned about the
> not programmers or anyone else with too much of a vested interest
program interface and the functions provided.
> (It would be of interest to know what the commonest "mistakes"Of users: formatting of game-info properties (as most programs don't
> of ordinary users are.)
provide a specific interface that does the formatting for them).
The most errornous property is TM (if entered manually - not on
sever games for apparent reasons), closly followed by DT and RE.
Other "errors" are e.g. making sibling variations in an application
which displays variations as childs. (Done by removing move with AE and
making new move within one node - illegal since FF).
Of programs: variations in all forms: empty variations "()", Ishi style
variations (sgf2misc), completely trashed variations (some versions of
WinMGT), basically everything you can make wrong with '(' and ')'.
Other errors include multiple properties (e.g. two C in one node),
wrong values (e.g. LB[1:bc] instead of LB[bc:1], or LB[bc:]), splitted
property ID's (e.g. W (linebreak) L - during mailing/posting --
which @#$% mail clients split words ??????).
AGAIN: Standard call: Use SGFC to check the output of your application !!!
> (2) most urgent effort isTrue. But this is beyond the scope of the spec, though we could recommend
> needed to standardise tournament names and player names;
using your dictionary. I can't think of a way to enforce this. If the
"big fish" adopt that recommendation then step by step those names will
be accepted. E.g. it's my experience that Jan's spelling is regarded
as a de-facto standard by many users.