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

"Long" property names?

Expand Messages
  • William M. Shubert
    Hi. I have a question for all the SGF programmers out there. In the next version of the KGS server, the files that are available on the web archives will be
    Message 1 of 8 , Apr 2, 2004
    • 0 Attachment
      Hi. I have a question for all the SGF programmers out there.

      In the next version of the KGS server, the files that are available on
      the web archives will be the same files that the server itself uses to
      track games (in the past I had two copies of each game). KGS needs a few
      custom SGF properties. In the past I stripped these properties out as I
      wrote the downloadable version of the SGF file, but soon these will
      appear in the games that people download.

      Now here's my qusetion. These properties currently have fairly mundane
      SGF-like names (DE, SB, SW, and DS). I'd like to make it clearer to
      people who see the files that these are KGS-specific extensions.
      According to the standard, it is customary but not required to use two
      letter property names. I am considering making all these five letters
      names, "KGSDE", "KGSSB", "KGSSW", and "KGSDS". I like this since it
      reduces the risk of collisions if other tools have custom SGF
      extensions, and it makes it clear when somebody looks at the file where
      the heck these nonstandard properties came from (think for example about
      the S4 problem Arno brought up not long ago!)

      Now here's my question. Does anybody know how well other SGF programs
      work when they see a long property name? If they throw away the property
      or ignore it, then that's fine with me, the only problem is if they
      actually crash or reject the file - I don't want to crash anybody's SGF
      parser, and I would like my SGF files to be readable!

      And in general, what do people think of this? Should I keep the 2-letter
      cryptic-but-typical property names, or would the 5-letter versions be
      preferred?

      Thanks for any input on this. I want to do what makes it easiest and
      best for everybody else, for me either way is fine. :-)
      Bill Shubert (wms@...)
    • Rui Jiang
      MultiGo is OK with arbitary length tag id. So I am fine with long property names. I would suggest we agree on leaving length 2 tags as reserved tags for SGF
      Message 2 of 8 , Apr 2, 2004
      • 0 Attachment
        MultiGo is OK with arbitary length tag id. So I am fine with long property names. I would suggest we agree on leaving length 2 tags as reserved tags for SGF standard (total 676),  and any extension should be longer than 2, maybe follow the convention like:
         
        <APPNAME><TAGID>
         
        as you are going to use.
         
        So far I have tested:
         
        WinMGT: OK
        gGo: OK
        JagoClient: OK
        Go Assistant: OK
         
        But maybe some other older applications might break.  
         
         
        ----- Original Message -----
        Sent: Friday, April 02, 2004 2:22 PM
        Subject: [sgf-std] "Long" property names?

      • David Fotland
        Many Faces will put something in the output window, like Unrecognized property KGSXX preserved and ignored , but has no problem with long properties.
        Message 3 of 8 , Apr 2, 2004
        • 0 Attachment
          Many Faces will put something in the output window, like
          "Unrecognized property KGSXX preserved and ignored", but has
          no problem with long properties.

          At 02:22 PM 4/2/2004 -0800, you wrote:
          >Hi. I have a question for all the SGF programmers out there.
          >
          >In the next version of the KGS server, the files that are available on
          >the web archives will be the same files that the server itself uses to
          >track games (in the past I had two copies of each game). KGS needs a few
          >custom SGF properties. In the past I stripped these properties out as I
          >wrote the downloadable version of the SGF file, but soon these will
          >appear in the games that people download.
          >
          >Now here's my qusetion. These properties currently have fairly mundane
          >SGF-like names (DE, SB, SW, and DS). I'd like to make it clearer to
          >people who see the files that these are KGS-specific extensions.
          >According to the standard, it is customary but not required to use two
          >letter property names. I am considering making all these five letters
          >names, "KGSDE", "KGSSB", "KGSSW", and "KGSDS". I like this since it
          >reduces the risk of collisions if other tools have custom SGF
          >extensions, and it makes it clear when somebody looks at the file where
          >the heck these nonstandard properties came from (think for example about
          >the S4 problem Arno brought up not long ago!)
          >
          >Now here's my question. Does anybody know how well other SGF programs
          >work when they see a long property name? If they throw away the property
          >or ignore it, then that's fine with me, the only problem is if they
          >actually crash or reject the file - I don't want to crash anybody's SGF
          >parser, and I would like my SGF files to be readable!
          >
          >And in general, what do people think of this? Should I keep the 2-letter
          >cryptic-but-typical property names, or would the 5-letter versions be
          >preferred?
          >
          >Thanks for any input on this. I want to do what makes it easiest and
          >best for everybody else, for me either way is fine. :-)
          > Bill Shubert (wms@...)
        • Rui Jiang
          It s good to know about the compatibilities of other programs, cause I am also considering add my own tags. e.g., I would really suggest add a tag suggesting
          Message 4 of 8 , Apr 3, 2004
          • 0 Attachment
            It's good to know about the compatibilities of other programs, cause I am
            also considering add my own tags. e.g., I would really suggest add a tag
            suggesting the structure of the SGF file, i.e., whether it is branch style
            (like joseki) or game with variants style (real game with variant branches
            in the middle), so that MultiGo can show it in the correct format when user
            opens it. Currently there is a button to switch between these two modes, but
            it is manually. Or a structural reform of SGF, to allow nodes in the middle
            like:

            ;B[..]
            ;W[..]
            (;B[];W[..] ... )
            ;B[..]
            ;W[..]
            (;B[];W[..] ... )

            which is more natual for game comment style SGF files. Go Assistant used to
            do this. But this will break almost all other applications.

            Rui

            ----- Original Message -----
            From: "David Fotland" <FOTLAND@...>
            To: <sgf-std@yahoogroups.com>
            Sent: Friday, April 02, 2004 9:28 PM
            Subject: Re: [sgf-std] "Long" property names?


            >
            > Many Faces will put something in the output window, like
            > "Unrecognized property KGSXX preserved and ignored", but has
            > no problem with long properties.
            >
            > At 02:22 PM 4/2/2004 -0800, you wrote:
            > >Hi. I have a question for all the SGF programmers out there.
            > >
            > >In the next version of the KGS server, the files that are available on
            > >the web archives will be the same files that the server itself uses to
            > >track games (in the past I had two copies of each game). KGS needs a few
            > >custom SGF properties. In the past I stripped these properties out as I
            > >wrote the downloadable version of the SGF file, but soon these will
            > >appear in the games that people download.
            > >
            > >Now here's my qusetion. These properties currently have fairly mundane
            > >SGF-like names (DE, SB, SW, and DS). I'd like to make it clearer to
            > >people who see the files that these are KGS-specific extensions.
            > >According to the standard, it is customary but not required to use two
            > >letter property names. I am considering making all these five letters
            > >names, "KGSDE", "KGSSB", "KGSSW", and "KGSDS". I like this since it
            > >reduces the risk of collisions if other tools have custom SGF
            > >extensions, and it makes it clear when somebody looks at the file where
            > >the heck these nonstandard properties came from (think for example about
            > >the S4 problem Arno brought up not long ago!)
            > >
            > >Now here's my question. Does anybody know how well other SGF programs
            > >work when they see a long property name? If they throw away the property
            > >or ignore it, then that's fine with me, the only problem is if they
            > >actually crash or reject the file - I don't want to crash anybody's SGF
            > >parser, and I would like my SGF files to be readable!
            > >
            > >And in general, what do people think of this? Should I keep the 2-letter
            > >cryptic-but-typical property names, or would the 5-letter versions be
            > >preferred?
            > >
            > >Thanks for any input on this. I want to do what makes it easiest and
            > >best for everybody else, for me either way is fine. :-)
            > > Bill Shubert (wms@...)
            >
            >
            >
            >
            > SGF spec: http://www.red-bean.com/sgf/
            > Contact: Arno Hollosi <ahollosi@...>
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
          • Denis Lambot
            As others said, the problem with custom properties is that they can become a problem when the specification are extended with new properties. So there is
            Message 5 of 8 , Apr 4, 2004
            • 0 Attachment
              As others said, the problem with custom properties is that they can become a problem when the specification are extended with new properties. So there is always the possibility of a clash between the existing custom properties and the new one.
               
              To solve this problem, may I suggest a practice which is common in Internet protocol for custom properties (e.g. in SMPT Mail header, MIME type, and some others). The idea is to prefix the custom properties with "X-". This prefix is reserved for custom properties and new version of the specification never use "X-" for new properties.
               
              We can further take the convention to have "X-<APPNAME>-<TAG>. So for the KGS custom properties this would be X-KGS-DE, X-KGS-SB, ...
               
              -----Message d'origine-----
              De : Rui Jiang [mailto:ruijiang2000@...]
              Envoyé : samedi 3 avril 2004 06:06
              À : sgf-std@yahoogroups.com
              Objet : Re: [sgf-std] "Long" property names?

              MultiGo is OK with arbitary length tag id. So I am fine with long property names. I would suggest we agree on leaving length 2 tags as reserved tags for SGF standard (total 676),  and any extension should be longer than 2, maybe follow the convention like:
               
              <APPNAME><TAGID>
               
              as you are going to use.
               
              So far I have tested:
               
              WinMGT: OK
              gGo: OK
              JagoClient: OK
              Go Assistant: OK
               
              But maybe some other older applications might break.  
               
            • William M. Shubert
              The problem is, Denis, that - is not allowed in SGF properties, so this will beak all existing FF[4] sgf applications. I think that anything we do *must*
              Message 6 of 8 , Apr 4, 2004
              • 0 Attachment
                The problem is, Denis, that "-" is not allowed in SGF properties, so
                this will beak all existing FF[4] sgf applications. I think that
                anything we do *must* work on FF[4] parsers that follow the spec,
                otherwise we are making up our own non-backward-compatible standard
                instead.

                I was even more cautious than this, wanting to avoid KGSXX properties if
                other apps didn't accept them (since, although they are fine by the
                FF[4] spec, they are quite different from all the standard properties).
                As it happens, the only app so far that doesn't accept them is my very
                own CGoban 1! I don't mind that so much, people still use it but it
                wouldn't be hard to fix in this case.

                On Sun, 2004-04-04 at 10:55, Denis Lambot wrote:
                > As others said, the problem with custom properties is that they can
                > become a problem when the specification are extended with new
                > properties. So there is always the possibility of a clash between the
                > existing custom properties and the new one.
                >
                > To solve this problem, may I suggest a practice which is common in
                > Internet protocol for custom properties (e.g. in SMPT Mail header,
                > MIME type, and some others). The idea is to prefix the custom
                > properties with "X-". This prefix is reserved for custom properties
                > and new version of the specification never use "X-" for new
                > properties.
                >
                > We can further take the convention to have "X-<APPNAME>-<TAG>. So for
                > the KGS custom properties this would be X-KGS-DE, X-KGS-SB, ...
                >
                > -----Message d'origine-----
                > De : Rui Jiang [mailto:ruijiang2000@...]
                > Envoyé : samedi 3 avril 2004 06:06
                > À : sgf-std@yahoogroups.com
                > Objet : Re: [sgf-std] "Long" property names?
                >
                >
                > MultiGo is OK with arbitary length tag id. So I am fine with long
                > property names. I would suggest we agree on leaving length 2 tags as
                > reserved tags for SGF standard (total 676), and any extension should
                > be longer than 2, maybe follow the convention like:
                >
                > <APPNAME><TAGID>
                >
                > as you are going to use.
                >
                > So far I have tested:
                >
                > WinMGT: OK
                > gGo: OK
                > JagoClient: OK
                > Go Assistant: OK
                >
                > But maybe some other older applications might break.
                * Bill Shubert (wms@...)
              • Rui Jiang
                Yeah, - won t work. But I like the X prefix. ... From: William M. Shubert To: sgf-std@yahoogroups.com Sent: Sunday, April 04, 2004 12:12 PM Subject: RE:
                Message 7 of 8 , Apr 4, 2004
                • 0 Attachment
                  Yeah, "-" won't work. But I like the "X" prefix.
                   
                  ----- Original Message -----
                  Sent: Sunday, April 04, 2004 12:12 PM
                  Subject: RE: [sgf-std] "Long" property names?

                • Arno Hollosi
                  ... I use it :-) Speaking about old SGF programs: personally I would not mind at all, if long property names broke old SGF applications. It would lead to
                  Message 8 of 8 , Apr 6, 2004
                  • 0 Attachment
                    William M. Shubert wrote:
                    > I was even more cautious than this, wanting to avoid KGSXX properties if
                    > other apps didn't accept them (since, although they are fine by the
                    > FF[4] spec, they are quite different from all the standard properties).
                    > As it happens, the only app so far that doesn't accept them is my very
                    > own CGoban 1!

                    I use it :-)

                    Speaking about old SGF programs: personally I would not mind at all, if
                    long property names broke old SGF applications. It would lead to people
                    updating their applications (which have fewer bugs - I hope). Of course,
                    you would have to take some heat, Bill.

                    Go ahead and use long property names. SGFC has an artificial limit at
                    about 100 letters for property names :-)

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