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

Re: SGF onion skin

Expand Messages
  • William M. Shubert
    This onion skin idea got me thinking. In a way I like it, in a way I don t. Overall, I m not sure where I stand. One thing I know that I diskike is numbering
    Message 1 of 2 , Feb 1, 1999
      This onion skin idea got me thinking. In a way I like it, in a way I don't.
      Overall, I'm not sure where I stand.

      One thing I know that I diskike is numbering the skins. What makes "1" and
      different from "2", for example? Can we have a parameter more important than
      2, less than 1, and call it skin "1.5"? (I'm being silly but I hope you see
      my point.) Why don't we name the skins? I can think of four right now:

      * Skin "Needed-To-Replay-Games": M, PB, PW, etc.
      * Skin "Needed-To-Annotate-Games-And-Problems-And-Stuff": AE/AB/AW, TR,
      SQ, etc.
      * Skin "Needed-To-Print-Games": DD, etc.
      * Skin "Private-Properties": All others.

      I like this better because giving each skin a name makes it clear what
      belongs in that skin, and also makes it easy for programmers to decide which
      skins to implement, based on how they expect their software to be used. For
      example, something like NNGS's Gobot, which only replays saved games, would
      only know the "Needed-To-Replay-Games" skin. My program (cgoban) which I
      intend to be used to annotate and view other's annotations would need the
      annotation skin also. A program which is intended to help book publishers,
      who want to create go diagrams, would use the "needed-to-print" skin too.

      How does this sound for the "skins" idea? (PS - I recommend we change the
      name from onion skins to something else. Skins makes me think of a different
      outside on the same inside, which isn't what this is about at all).

      > From: Arno Hollosi <ahollosi@...-graz.ac.at>
      > Hi again,
      > I didn't have much time lately, so I couldn't finish the udpate
      > of the FF[4] spec as already discussed in this list (TM+OT,
      > less restrictive handling of gameinfo properties, ...)
      > Also we talked about adding a page for "private properties".
      > So that other people don't use their names, or can implement
      > those properties which they find useful, etc. Shigeru's proposal
      > could be added to that "private properties" page.
      > As you know, I'm rather reluctant to add new properties to the
      > 'official' part of FF[4], as every programmer would have to add
      > them to their programs. Which is a lot of work, for features
      > which might be used seldomly. Furthermore the SGF standard would
      > grow more and more complex and harder to maintain.
      > Reading through Shigeru's mail I remembered an idea I had quite
      > a time ago: SGF onion skin concept. This means, that we assign
      > every property a "skin" number. The innermost skin comprises
      > the core properties which should be implemented by every SGF client.
      > Such properties are: B,W,AB,AW,AE,GM,SZ,C,PB,PW,BR,WR,DT,KM,RE,TR,MA.
      > Every other skin extends the functionality, but is less "important"
      > than the previous skin. Take as an example the board markup:
      > Skin 0 (core): TR, MA, LB
      > Skin 1: CR, SQ, AR, TB, TW
      > Skin 2: DD, LN, SL
      > Skin 3: private properties
      > The onion skin concept should be a help for programmers to decide
      > which properties their program should support.
      > Furthermore the properties should be divided into functional
      > categories, like board-markup, timing, game-info, moves, annotations,
      > etc.
      > Private properties would be integrated into the spec as skin 3, and
      > clearly marked as "unofficial" extensions. There should be a note
      > on which program uses these properties and how common the property
      > is (if it's supported by more than one program).
      > That would make it easy to document private properties in the spec.
      > Everyone could decide if their program should support a certain property
      > based on which other programs support those properties and the intended
      > usage.
      > That way we could keep the core and common properties (skin 0 & skin 1)
      > small and give those power users (skin 2 & skin 3) a well defined set
      > of properties for every purpose. For example, Shigeru's timing properties
      > would be documented in the spec as skin 3 properties. And if time shows
      > that they are useful and are widely adopted, then they could move to the
      > official part at skin 2.
      > What do you think about it?
      > /Arno
      > ------------------------------------------------------------------------
      > To unsubscribe from this mailing list, or to change your subscription
      > to digest, go to the ONElist web site, at http://www.onelist.com and
      > select the User Center link from the menu bar on the left.
      > ------------------------------------------------------------------------
      > SGF spec: http://www.sbox.tu-graz.ac.at/home/h/hollosi/sgf/
      > Moderator: Arno Hollosi <ahollosi@...>

      Bill Shubert (wms@...)
    Your message has been successfully submitted and would be delivered to recipients shortly.