Date: Thu, 1 May 1997 16:11:15 -0400
From: Jens Yllman <jens.yllman@mailbox.swipnet.se>
Subject: Re: Summary of recent discussion

 Hello.

 So, I should not have moves in the firtst, root, node. And the root node
should not be empty. But my program should be able to handle that when I
read files. Should we correct such things when we save changes?

 A question to you out there. If there is no setup or move for, lets say, 4
nodes. Do you step to that posision in the file when you have loaded it.
And diplay that part for the user? Or do you have empty, not changing,
steps/nodes/moves that the user have to step through befor he reaches the
"real" information? Could it be that you want to display comments in steps
before the actual moves starts. And if you read this type of file and makes
changes to it and save it. Should we save the old begining or convert it to
a more "normal" look. This is more style questions then standard questions.

 I'm sorry I've not been active here before and now starts to ask questions
just before Arno wants to realese the standard.

 Jens yLlman

At 05.36 1997-04-30 -0400, you wrote:
>
>Reading through the recent emails I came to the conclusion that
>the draft should be changed as follows:
>
>- faulty game-info properties may remain where they are
>  (i.e. moving to GC not mandatory)
>  They should be corrected if possible though.
>
>- Date format:
>  I like Robert's last proposal: DT[simpletext] with following format:
>  * partial dates possible (yyyy, yyyy-mm)
>  * if game was played on more than one day, the other dates
>    should be seperated by a comma.
>    > Interpretation: From left to right.
>    > Left-most must contain yyyy
>    > mm-dd or mm acquires the last preceding yyyy.
>    > dd acquires the last preceding mm and the last preceding yyyy.
>    > If xx follows yyyy-mm-dd or mm-dd or dd, then xx is dd.
>    > If xx follows yyyy-mm or mm, then xx is mm.
>    At first glance this may look complicated but it's actually rather 
>    easy and logical.
>
>- I've looked up the RFC number for the CA property.
>  It's RFC 1345. Default charset is: 'ISO-8859-1' aka 'Latin1'.
>  If you don't want to read through RFC 1345:
>  Basically CA uses the same names as MIME messages in
>  their 'charset=' field (in Content-Type).
>
>- proposal for FG & DS
>  * DS numbering should be changed to:
>    0 - don't number, 1 - use numbers, 2 - use modulo 100 numbers
>    (just like Robert suggested)
>  * Flags for FG:
>    o print coordinates
>    o ???? (any ideas for other flags)
>
>
>Martin Mueller writes:
>> The first point can be facilitated by offering rigorous test suites, or
>> even a reference implementation.
>
>SGFC (the syntax checker & convert tool I wrote) is VERY rigorous and can
>be regarded as a reference. I'll upload a new version within the next days.
>
>
>Yens Yllman writes:
>> This text says, "Root nodes are the first nodes of gametrees". Can
>> there be more then one root node in a gametree?
>No.
>> And is there always a root node?
>Yes - every tree contains at least one node -> there's a first node :)
>
>> As I see it FF[] is not optional when you want FF[4].
>> So that should always be in the root node.
>Correct.
>
>> But if I use default values for all root properties. And no gameinfo.
>> And the first thing I have to put in the file is a move. How should that 
>> be handled?
>> Should I put a EMPTY node first? Is empty nodes possible?
>
>Empty nodes are allowed. Storing moves in the root node is allowed too
>but it's bad style - one wants to start with the initial board setting,
>i.e. empty boards for even games and handicap stones for h-games ->
>AB[]'s for setting up the handicap position should be stored in root node.
>
>
>
>Comments welcome
>/Arno
>
>