Loading ...
Sorry, an error occurred while loading the content.

Re: ** SGF FF[5] **

Expand Messages
  • Arno Hollosi
    ... Could you describe the needs of an ordinary user? While creating FF[4] I posted to rec.games.go that I like suggestions by users about their needs. IIRC, I
    Message 1 of 6 , Feb 8, 1999
      John Fairbairn <JF@...> wrote:

      > There seems to be a trend to make the spec fit the needs of
      > the big fish - the databases, IGS, or Nihon Ki-in. Ordinary users seem
      > to have different needs.

      Could you describe the needs of an ordinary user?
      While creating FF[4] 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 in
      > ways that the spec won't let them.

      I argue that it's because of sloppy programs and not because of SGF.

      > Human nature demands that the spec should change to suit them,
      > rather than users be dragooned into complying with an increasingly
      > complex spec.

      I agree. But the spec itself should (almsot) be transparent to the user.
      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 a
      > single line of free text for whatever the database regards as key words.

      This is true. However, if you want to have interchangeable SGF games
      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) ...
      > ... 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

      These issues will be addressed in FF[5].
      Also, see Jan's suggestions for team players and other information.

      > "Played 1845-03-03 and through the night till 9pm the
      > following day" [nb putting 1845-03-03,04 would omit the interesting
      > point that they played non-stop].

      I think that this information should be put into GC and that DT
      should contain 1845-03-03,04.

      > (1) that FF5 would be an advance if it actually went backwards
      > a little bit - in particular it should allow free-form text where possible

      Yes. Many of us agree on this.

      > (3) the needs of ordinary users - people who enter game records,
      > not programmers or anyone else with too much of a vested interest

      I agree. As pointed out above, most users are concerned about the
      program interface and the functions provided.

      > (It would be of interest to know what the commonest "mistakes"
      > of ordinary users are.)

      Of users: formatting of game-info properties (as most programs don't
      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[4]).

      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[43] - during mailing/posting --
      which @#$% mail clients split words ??????).

      AGAIN: Standard call: Use SGFC to check the output of your application !!!

      > (2) most urgent effort is
      > needed to standardise tournament names and player names;

      True. But this is beyond the scope of the spec, though we could recommend
      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.

    Your message has been successfully submitted and would be delivered to recipients shortly.