FOR IMMEDIATE RELEASE

CONTACT
=======
David Goodger
- [[mailto:dgoodger@...]]
- [[http://gotools.sourceforge.net]]


THE GO TOOLS PROJECT: Launch of Open-Source Web Site
====================================================

Kitchener, Ontario, Canada -- 2000-03-27

Announcing the official launch of The Go Tools Project at
[[http://gotools.sourceforge.net]], a new resource for go players. The
mission of the Go Tools Project is:

- To encourage, develop, and distribute open-source software and tools
   related to the game of go.

- To maintain a set of links to other go-related open-source development
   projects and resources.

All go players will benefit from SGF Summarizer, a multi-platform program
(written in Python) which extracts game information from multiple go game
records and produces output suitable for importing into a spreadsheet or
database. This enables easy manipulation at the game level: sorting,
searching, totalling, etc.

Go programmers will benefit from these Python modules:

- the Smart Game Format Parser Library, a general-purpose SGF parser; and

- the Type Class Library, which implements abstract superclasses to emulate
   Python's built-in data types.

Go-playing Macintosh users will benefit from automatic extraction of go
game records from e-mail messages. There's a standalone applet, and
scripts for MS Outlook Express.

The Go Tools Project is looking for other open-source projects (any
language, any platform, but hopefully multi-platform) to host or link to.

For additional information, downloadable files, and documentation, please
visit [[http://gotools.sourceforge.net]].

                    # # #

--
David Goodger    davidg on NNGS (4k*), IGS (6k*), GoClub.org (1k)
The Go Tools Project (open-source): http://gotools.sourceforge.net

--- In sgf-std@onelist.com, awalker@xx.xxx wrote:
> I recently began programming for the 3Com's Palm Computing platform
> and have a question. Seeing a whole lot of talk about a new standard
> being released, I am questioning wether or not to begin developing a
> Palm implementation of the "old" standard, or wait until the new one
> is finalized.

You will probably be interested in the PilotGOne product, an SGF
recorder and playback program for PalmOS distributed under the GPL.

   <http://www.skarpsey.demon.co.uk/pilotgone.html>

I am tooling up to make some modifications to this program (isn't
Free Software great!), including upgrading its SGF knowledge from FF[1]
to FF[4]; I have just joined the list so hope to be able to make FF[5]
changes as well.

  \
   `\
_o__) BIGNOSE

Hi all,

I'd like to inform you that two more games have been added to the
SGF spec by request of Tim Prime <tdprime@...>.
They are: Octi (GM[19]) and Gess (GM[20])
See: http://www.red-bean.com/sgf/

Also, for those interested in an XML file format for Go (GM[1]) games,
have a look at a new discussion group on egroups called GoXML.
See: http://www.egroups.com/group/GoXML


/Arno

Does a ")" have to be escaped with a "\)". I want knwo if  a ":)" is
valid as part of a comment.

Thanks,
Mike

> Does a ")" have to be escaped with a "\)". I want knwo if  a ":)" is
> valid as part of a comment.

The only mandatory characters to be escaped are "\" and "]".
If you use composite datatypes then ":" has to be escaped as well.
So ":)" is a valid part.

However the spec allows escaping any other character as well.
So C[\H\e\l\l\o\ \w\o\r\l\d\! \:\)] is valid SGF as well.

/Arno

--- In sgf-std@y..., Arno Hollosi <ahollosi@x> wrote:
>
> > Does a ")" have to be escaped with a "\)". I want knwo if  a ":)"
is
> > valid as part of a comment.
>
> The only mandatory characters to be escaped are "\" and "]".
> If you use composite datatypes then ":" has to be escaped as well.
> So ":)" is a valid part.
>
> However the spec allows escaping any other character as well.
> So C[\H\e\l\l\o\ \w\o\r\l\d\! \:\)] is valid SGF as well.
>
> /Arno

I've noticed that Anders Kierulf's SmartGo always escapes ":". I
think that this is a good practice (and maybe should me made
manditory). Without doing this, future extension to datatypes is
possibly ambiguous. For example, the proposed FF[5] change to CA -
changing from SimpleText to Composed.

--- In sgf-std@y..., vladdu@xxxxxxx.xxx wrote:
> Hello!
>
> As the original author of the mail mr van der Steen posted here
from the
> computer-go mailing list, I am happy to see something is moving! :-
)
>
> I was about to write a sample draft DTD myself, but the one mr
Hollosi has
> posted is much better.
>
> A first look at it brings up a question: Should the XML format
mimic
> the SGF one, or should it use the new possibilities? What I mean
is that
> a general "node" in SGF can correspond to several different in
XML. The best
> example would be the initial node describing the game information.
Of course,
> having a more or less exact match would make it possible to use
both formats
> with the same tree structure...
>
> And a proposal for the name: 3 letter names are more useful as
filename
> extensions, so what about XGF? could mean eXtended Game Format, or
eXtrasmart
> Game Format... :-)
>
> cheers,
> /Vlad

Is anyone doing anything on this front?

> Is anyone doing anything on this front?

Many people have asked about an XML version. Over 2 years ago a group of
people set out to define such a file format (AFAIK up until now they only
have produced a requirements document).

I have dismissed XML until recently. Now, as I know core XML technologies by
heart (because of my job), I think it is a good idea. Also, now I have the
necessary knowledge of XML that I feel up to the task.

Actually, one week ago (independent of Vlad's email) I set out to start
define an XML format plus an API on top of the DOM. I don't want to present
my ideas prematurely, because I'd don't want to waste everyone's time with
unready rubbish.

Give me three more weeks and I will show you what I have got.

Btw, Vlad: I thought about naming it XGF just as you wrote your email ;o)

/Arno

p.s. please disregard SGFML (currently on the web site), I didn't have a clue
about XML back then.

--
  SL: http://senseis.xmp.net/ -- a pot of go at the end of the rainbow
GTL: http://gtl.jeudego.org/ -- have your own games reviewed
SGF: http://www.red-bean.com/sgf/ -- smart game file format

Hi XML junkies,

I have uploaded an early pre-alpha draft of a proposal for an XML file format
to http://www.red-bean.com/sgf/xml/ called XGF v0.1

Sorry, no documentation there currently. I reckon it's only for hardcore XML
freaks. Let me know what you think.

/Arno

Hi, Arno
Hi, All

Why do you choose <Black at="d17" /> , and not just <Black>d17</Black>
(similar to <BoardSize>19x19</BoardSize>)?

Regards, Francois Mizessyn

Arno Hollosi wrote :

>
> Hi XML junkies,
>
> I have uploaded an early pre-alpha draft of a proposal for an XML file
> format
> to http://www.red-bean.com/sgf/xml/ called XGF v0.1
>
> Sorry, no documentation there currently. I reckon it's only for
> hardcore XML
> freaks. Let me know what you think.
>
> /Arno

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the sgf-std
group.

   File        : / Looking for fast Internet service?
   Uploaded by : thedslguy2002 <thedslguy2002@...>
   Description : Click above to learn what DIRECTV has to offer.

You can access this file at the URL

http://groups.yahoo.com/group/sgf-std/files/%20Looking%20for%20fast%20Internet%2\
0service%3F

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

thedslguy2002 <thedslguy2002@...>

Sorry for the spam. I've disabled the spam account. Also, the file
upload and other features are shut down.

/Arno

Just to be certain, extra parenthesis are still 'well-formed' SGF?
For example:

(;N[A](;N[B](;N[C](;N[D]))(;N[E])))

is the same tree as:

(;N[A];N[B](;N[C];N[D])(;N[E]))

and should be handled correctly by all parsers?

--

Not that it could possibly be changed at this point, but I'm curious:
Why the use of semicolons in addition to parenthesis. In the latter,
we save parenthesis; one for each non-branched node, but have
unnecessary semicolons on branched nodes. In the former case all of
the semicolons are excessive. Why not:

(N[A](N[B](N[C](N[D]))(N[E])))

.. which in this particular case is the shortest representation. For
non-branching game records the standard way is best. Is this savings
the reasoning?

The difficulty comes when trying to output SGF without requiring
foreknowledge of whether a particular node has siblings. That is,
with methods like WriteNodeStart(), WriteProperty(), …,
WriteNodeEnd
() where start A, start B, end B, end A implies that B is a child of
A. This is how I'm used to dealing with XML serialization.

Trying to maintain the simplified SGF in a forward-only writer
requires buffering until either a close or a sibling is seen.
Whereas the non-simplified version can be spewed to the underlying
stream immediately.

Ashley,

sorry for the delay in answering.

> Just to be certain, extra parenthesis are still 'well-formed' SGF?
> (;N[A](;N[B](;N[C](;N[D]))(;N[E])))
> is the same tree as:
> (;N[A];N[B](;N[C];N[D])(;N[E]))
> and should be handled correctly by all parsers?

Correct. It does not matter that a branch does not have any siblings.

> Not that it could possibly be changed at this point, but I'm curious:
> Why the use of semicolons in addition to parenthesis.

I guess this comes from the EBNF definition:

   Collection = GameTree { GameTree }
   GameTree   = "(" Sequence { GameTree } ")"
   Sequence   = Node { Node }
   Node       = ";" { Property }

> In the former case all of the semicolons are excessive.
> Why not: (N[A](N[B](N[C](N[D]))(N[E])))

Because in a game of 250 moves you would have to add 250 closing parenthesis
at the end.

> For non-branching game records the standard way is best. Is this savings
> the reasoning?

I think so. Furthermore, non-branching games are the majority of all
game-records. Even the records of the Go Teaching Ladder contain only about 5
branches on average.

> The difficulty comes when trying to output SGF without requiring
> foreknowledge of whether a particular node has siblings.

Is that foreknowledge not always present? Don't all SGF programs have some
internal tree structure in which they hold moves (aka XML-DOM model)? If your
program has an internal tree-structure writing SGF is easy:

    WriteTree(Root)
    End

    WriteTree(Node)
       Write(Node)
       for each child of Node
          WriteTree(child)
       end for
    end

In case of SGF filters (aka XML-SAX model) that don't add new branches just
keep the paranthesis, even if they become superfluous afterwards. It doesn't
heart the parsers.

/Arno

I'm posting this for Jan. My answer in the next email.

/Arno

----------  Forwarded Message  ----------

Subject: Question about printing annotated SGF
Date: Mon, 22 Jul 2002 23:38:00 +0200
From: Jan van der Steen <J.van.der.Steen@.....>

I have a question about printing annotated SGF.
Let's imagine the SGF file:

     (
     ;
     FF[4]
     SZ[2]
     B[aa]CR[aa]
     W[bb]CR[bb]
     FG[]
     )

What would this print? Let me give the choices:

     @ .    1 .    1 .
     . O    . 2    . O

     A      B      C

So would the stones be marked with circles, numbers
or a mix of them?

Right now I prevent the overwriting of numbered stones
since it would possibly obscure the numbering (as in the
above example) and thus prevent the replaying of the game
from the print, so I produce output "B".

The SGF style given as an example is produced by KGS and
the rationale as I was told was that while replaying the
game with cgoban the last move would be indicated with a
circle. This also seems to assume that after each move
in an interactive representation all other annotations
should be removed from the diagram presentation, is that correct?

best regards,
Jan van der Steen

-------------------------------------------------------

Hello,

>     (; FF[4] SZ[2]
>     B[aa]CR[aa]
>     W[bb]CR[bb]
>     FG[]
>     )

Nitpicking: there's at least 1 semicolon missing here - two moves in a node
are not allowed.

> This also seems to assume that after each move
> in an interactive representation all other annotations
> should be removed from the diagram presentation, is that correct?

Correct. Otherwise you would have too much markup on the board. E.g. only
because I comment that a group is weak in node 45 (and mark that group with
e.g. squares) doesn't mean that the group should stay marked until the end of
the game.

Markup is only valid (should only be displayed) in the node it appears.
Exceptions to this rule are the "inherit"-style properties, such as DD, VW.

> The SGF style given as an example is produced by KGS and
> the rationale as I was told was that while replaying the
> game with cgoban the last move would be indicated with a
> circle.

I don't like KGS' CR properties - but that's my personal opinion. I believe
that it is up to the application to mark the last move, if the user likes to
have it that way. And I cannot think of one SGF editor prior to KGS that
didn't mark the last move.

> What would this print? Let me give the choices:
>
>     @ .    1 .    1 .
>     . O    . 2    . O
>
>     A      B      C
> Right now I prevent the overwriting of numbered stones
> since it would possibly obscure the numbering (as in the
> above example) and thus prevent the replaying of the game
> from the print, so I produce output "B".

Strictly speaking, variation C is correct. Variation A is not an option
because the black move and its markup are in the previous node. Variation B
also has its merits for the reason you mention. (But for interactively
replaying the game printing is not an argument, is it?).

From the pragmatic point of view both B and C are ok. As the CR markup doesn't
hold any essential information, people using style B applications will be
used to the way the last move is displayed.

The drawback of B is that if e.g. you mark a whole group - and the current
move is part of that group - it won't show the markup. E.g. assume me
referring to the "4 marked stones" but you only seeing 3 marked stones,
because one of the stones is the current move and its markup isn't shown.

One thing I have seen is printing the automatic "latest-move" markup above all
other markup. Furthermore it was small enough so that other markup could
still be seen. In your case this would mean printing "2" above CR and both 2
and CR are visible. Of course, this breaks down when the latest move is
marked with a label (LB).

Hope that helps
/Arno

As I think this might be of interest to all I also forward Jan's reply.

/Arno

----------  Forwarded Message  ----------

Subject: Re: Question about printing annotated SGF
Date: Tue, 23 Jul 2002 09:53:32 +0200
From: Jan van der Steen <J.van.der.Steen@....>

Hi Arno,

Thanks for your forwarding and reply, here is mine...

  |> >     (; FF[4] SZ[2]
  |> >     B[aa]CR[aa]
  |> >     W[bb]CR[bb]
  |> >     FG[]
  |> >     )
  |>
  |> Nitpicking: there's at least 1 semicolon missing here -
  |> two moves in a node are not allowed.

Serves me right, I entered the code by hand.

  |> > This also seems to assume that after each move
  |> > in an interactive representation all other
  |> > annotations should be removed from the diagram
  |> > presentation, is that correct?
  |>
  |> Correct. Otherwise you would have too much markup on
  |> the board. E.g. only because I comment that a group
  |> is weak in node 45 (and mark that group with e.g.
  |> squares) doesn't mean that the group should stay
  |> marked until the end of the game.

Ok, fair enough. In an interactive representation it's as if
there is an FG[] after every move, right?

However, the example I gave had one FG[] attached to the final
move, this was intentional. I was discussing the print to paper
containing various moves:

  (
  ;
   FF[4]
   SZ[2]
   B[aa]CR[aa]
  ;
   W[bb]CR[bb]
   FG[]
  )

  @ .    1 .    1 .
  . O    . 2    . O

  A      B      C

As I understand your explanation this would either print B or C?
Or could one argue that annotations are included in the diagram
unless they would obscure other information and are removed after
the FG[] has been processed (similar to interactive mode with FG
at each move)?

  |> From the pragmatic point of view both B and C are
  |> ok. As the CR markup doesn't hold any essential
  |> information, people using style B applications will
  |> be used to the way the last move is displayed.

Is CR a special markup, different from MA, or SQ for example?

Jan

> Ok, fair enough. In an interactive representation it's as if
> there is an FG[] after every move, right?

You might put it that way, although it is not really what this is about. SGF
standard always assumed that properties are only valid in the context of the
current node. FG[] is used to mark where figures begin and where they end.

> Is CR a special markup, different from MA, or SQ for example?

No. I was just implying that it only marks the current move and thus is not
important. Markup holding special information would be e.g. TB, TW (territory
markup).

> However, the example I gave had one FG[] attached to the final
> move, this was intentional. I was discussing the print to paper
> containing various moves:

Well, actually FG[] should be at the beginning because the spec clearly
states:
	 The figure property is used to divide a game into
	 different figures for printing: a new figure starts at the
	 node containing a figure property.

See also: http://www.red-bean.com/sgf/examples/

> Or could one argue that annotations are included in the diagram
> unless they would obscure other information and are removed after
> the FG[] has been processed (similar to interactive mode with FG
> at each move)?

The spec is vague at that point. I think up to (and including) FF4 printing
was never a strong point of SGF, although FF4 made some progress in that
direction (FG, PM, VW).

For interactive representation it is clear: remove markup once you leave the
node. Printing applications may have different needs that are currently not
addressed in SGF. Here it is left to the application how to handle this.

The problem is of course, how would your application handle something like
this: (;FG[];LB[aa:1];LB[aa:2];LB[bb:1])

Two problems: 'aa' holds two different markups in two different nodes and
referring to '1' may be ambiguous too: is it 'aa' or 'bb'? In the context of
"interactive displaying" there's no problem as at every node only one label
is visible, thus no ambiguity. In the example files at red-bean I therefore
moved all relevant markup to the last node of the figure.

The real problem is: if you have an SGF file that was edited with printing at
the back of your mind, it will avoid ambiguities. Thus showing all markup
that occurs between two FG[] properties is straight-forward. One could argue
that you could also move all markup to the last node like I did for the
example files.

However, if you have an SGF file that was edited for online representation
(e.g. GTL reviews) you cannot assume that markup will not overlap. Printing
in that case either produces "errors" or needs some kind of user interaction.

My personal opinion is that printing should always involve some kind of dialog
with the user where they can set various kinds of options. Showing "all
markup" or just the "markup of the latest move" being one of those options.

/Arno

Arno Hollosi wrote:

>
> > The SGF style given as an example is produced by KGS and
> > the rationale as I was told was that while replaying the
> > game with cgoban the last move would be indicated with a
> > circle.
>
> I don't like KGS' CR properties - but that's my personal opinion. I believe
> that it is up to the application to mark the last move, if the user likes to
> have it that way. And I cannot think of one SGF editor prior to KGS that
> didn't mark the last move.
>

I agree with that. I had to change my code only to handle KGS' files,
and I think it is not a good thing.

jf


--
  _________________________________________
/ do you play Go?                         \
|http://jeanfrancois.menon.free.fr/rubygo |
\                                         /
  -----------------------------------------
         \   ^__^
          \  (oo)\_______
             (__)\       )\/\
                 ||----w |
                 ||     ||

hi, writing a parser. confused about the diagram at
http://www.red-bean.com/sgf/var.htm. the doc says this is a pre-order
traversal and the psuedo-code says visit the node, then visit the children.
the normal definition of pre-order is node, left (down) subtree, right
(next) subtree (i am using binary trees).

this does not give correct result. i find that one must visit the right
(next) node before the (left) down node (otherwise, the ;C[a];C[b] would
come out wrong). i have the diagram labeled "One variation at move 3" in
core as:

1-----2
         |
         3-----4-----5-----6
         |
         3'----4'

the doc also says that "the first line of play is the main line". but the
"line" in this case has a step in it (and could be a long staircase).

so is the doc a bit misleading or am i perhaps confused?

thanks

---
ray tayek http://home.attbi.com/~rtayek/ actively seeking telecommuting work
vice chair orange county java users group http://www.ocjug.org/
mailto:chair@...
hate spam? http://samspade.org/ssw/

> the normal definition of pre-order is node, left (down) subtree, right
> (next) subtree (i am using binary trees).

Ok, so pre-order makes (only) sense for binary trees. In SGF multi-branch
trees are possible. But the principle holds true. First the node, next the
subtrees.

> this does not give correct result. i find that one must visit the right
> (next) node before the (left) down node (otherwise, the ;C[a];C[b] would

Ah, I see. You are implying that if you turn the diagram clockwise, then
pre-order is left first (the variation) instead of right (the main line).

Well, just don't look at the pictures like that :o) I think the first picture
(the black&white one) gives the order rather nicely. And the other ones are
correct too, if you not just turn them clock-wise but flip them once too.

Speaking in pre-oder terminology: the main line is always the left most
sub-tree.

I thought the page would make variations easier to understand, rather than
causing confusion.

/Arno

At 10:48 PM 8/27/02 +0200, you wrote:
> > the normal definition of pre-order is node, left (down) subtree, right
> > (next) subtree (i am using binary trees).
>
>Ok, so pre-order makes (only) sense for binary trees. In SGF multi-branch
>trees are possible. But the principle holds true. First the node, next the
>subtrees.

yes, i was confused about the sgf tree (it is not a binary tree).


>Speaking in pre-oder terminology: the main line is always the left most
>sub-tree.

yes, the thing that threw me was that now matter how many subtrees you were
in, the all end up being the main line down the binary tree.

and printing in preorder does not do the right thing. you need to do it the
way gnugo and smarto go do it. i ended up printing sgf the way they do (see
below).

the doc was very helpful. i was just confused :(

thanks

          void toSgf(Indent indent,Writer writer)
                  {
                  try
                          {
                          writer.write(indent.indent()+'(');
                          writer.write(toString());
                          Node n=left;
                          for(;n!=null&&n.right==null;n=n.left)
                                  writer.write(n.toString());
                          indent.in();
                          for(;n!=null;n=n.right)
                                  { writer.write(eoln);
n.toSgf(indent,writer); }
                          indent.out();
                          writer.write(')');
                          }
                  catch(IOException e) { throw new RuntimeException(e); }
                  }


---
ray tayek http://home.attbi.com/~rtayek/ actively seeking telecommuting work
vice chair orange county java users group http://www.ocjug.org/
mailto:chair@...
hate spam? http://samspade.org/ssw/

The standard state for FF[4]:
Property value: private properties may use one of the value types defined in
this document or define their own value type. When using a private value type
the application has to escape every "]" with a leading "\". Otherwise the file
would become unparseable. Should the value type be a combination of two
simpler types then it's suggested that your application uses the Compose type.

This is the only requirement that I can find on the value of a private property.

As I understand it, the only character that it is necessary to escape is "]".
The
"\" the escape character does not need to be escaped. Does this imply that
private properties can not escape the "\", even if they would like to? If they
could wouldn't it make it hard to interpret?

PP[\\]MA[dd] - Where PP is a private property.

I thought that it was necessary to escape "\" until I reread the specification.

Regards,
Mikael Thulin

PS How does current applications handle this?

yago do not support LB?

LB[kk:a]C[
*****************

i read some file list above,it means marking point KK as a and comment in
blankC[.

but yago do not support this format,why?

Mikael,

> As I understand it, the only character that it is necessary to escape is
> "]". The "\" the escape character does not need to be escaped. Does this
> imply that private properties can not escape the "\", even if they would
> like to? If they could wouldn't it make it hard to interpret?

There are no rules what you can or cannot do inside a private property. Now I
agree that omitting to mention that '\' has to be escaped is a mistake, but
hardly one, which is incorrectable. IIRC, SGFC treats '\' as a general escape
char, thus in e.g. 'XX[\\]B[aa]' the property value of XX is "\\" (not
"[\\]B[aa").

I think that just about every program handles it in the same way. Anyway, this
was clearly the intention of the spec. I will clarify that '\' itself has to
be escpaed as well.


/Arno

p.s. apart from that, having a private property that contains something like
[...\\] looks like a pathologic case to me.

> yago do not support LB?
>
> LB[kk:a]C[
> *****************
>
> i read some file list above,it means marking point KK as a and comment in
> blankC[.

The above does not look like correct SGF to me.
Let's assume it is LB[kk:a]C[...comment text...]
the LB property marks point kk as 'a'. And the comment text is shown somewhere
(not on the board).

If Yago does not support the LB property that's a problem of Yago, not a
problem of the SGF standard. Please contact the author of Yago directly about
your problem.

/Arno

hello,

I have some questions when recording IGS games to sgf files:

1) I try to take advantages of the SGF 5  otions, while keeping
compatibility with sgf4
so I make the OT properyt like this:


(;FF[4]KM[5.5]HA[4]OT[300][OP:A:300][OM:A:25][NO:A:1]

the behavior of my application is to read the first (sgf4) prop
(OT[300]) and override it with the second if it is present. I would like
to know if it is a correct behavior. Some sgf readers seems to refuse to
open a file with this header.

2) To store a maximum of information given by IGS, I add some private
properties. Should I submit them somewhere to ask them to be added in a
future version of the SGF standard?

jf


--
  _________________________________________
/ do you play Go?                         \
|http://jeanfrancois.menon.free.fr/rubygo |
\                                         /
  -----------------------------------------
         \   ^__^
          \  (oo)\_______
             (__)\       )\/\
                 ||----w |
                 ||     ||

> 1) I try to take advantages of the SGF 5  otions, while keeping
> compatibility with sgf4

You are aware that FF5 is not defined yet? What is on the pages is a summary
of the discussion that happened two years ago. Some Japanese programs adopted
the FF5 draft, but I think that's premature. I don't think that the
discussion about FF5 had reached a point where we could make it a new
standard.

> (;FF[4]KM[5.5]HA[4]OT[300][OP:A:300][OM:A:25][NO:A:1]
> the behavior of my application is to read the first (sgf4) prop
> (OT[300]) and override it with the second if it is present. I would like
> to know if it is a correct behavior. Some sgf readers seems to refuse to
> open a file with this header.

That's because it's not valid FF4. I guess the best thing is to mark this file
as FF5 (which I don't think is a good idea either, see above).

> 2) To store a maximum of information given by IGS, I add some private
> properties. Should I submit them somewhere to ask them to be added in a
> future version of the SGF standard?

If you think that these properties add features which you feel are important
for everyone, post your proposal here. Otherwise just use non-standard names
which don't occur in the specification yet.

/Arno

p.s. does someone know which programs add "S4" properties? This is a *big*
violation of the spec, which states that properties consist only of A-Z.
Files with "S4" properties are unreadable for many other applications. If you
know not only the program but the author as well, please contact him/her
about that issue.

> p.s. does someone know which programs add "S4" properties? This is a *big*
> violation of the spec, which states that properties consist only of A-Z.
> Files with "S4" properties are unreadable for many other applications. If you
> know not only the program but the author as well, please contact him/her
> about that issue.

I bet you know many common and uncommon violations against the standard.
Do you keep them listed somewhere? Would it be possible to have a peek at
that list. The S4 property didn't bother my application but I guess that there
is
plenty of common violations that will.

Regards,
Mikael Thulin

PS I have noticed that there are many files at jansteens homepage that contains
illegal "variations", like ( ;B[me];W[ep](;B[eo];W[dp]);B[cp];W[do]). I have
a hard time deciding on how to treat them. They are indeed broken. However
the ones at jansteen can be fixed by just removing those illegal parenthesis. I
not totally found of that as it might create an non valid record, in other
cases.
Does anyone know the origin of those files (application/user/etc). Any
suggestion
on how handle them, except throwing them away?