Author: Bruce Moreland
Date: 08:51:57 05/30/98
Go up one level in this thread
On May 30, 1998 at 04:11:01, Peter Klausler wrote:
>Some areas where PGN can be strengthened as an interchange
>mechanism:
>
>1) Specification of an escape convention to allow the '"'
> character in quoted strings and the '{' character in
> inline commentary
You escape it with a backslash -- \"
This is required by the standard now.
There are files out there that don't conform to this.
>2) A means of specifying "... with the idea of..." move
> sequences
Yes.
>3) A canonical mapping between Informator glyphs and NAGs
Yes yes, I really want this. I also sent this in to Steven, and I got
this cryptic thing back that said he didn't have time to talk to me,
but would "report results to Bob Hyatt", which is odd, because as far as
I know Bob doesn't care about PGN, last time I talked to him about it he
had no clue what the "things with the dollar signs" were.
>4) Integer values for tags (like WhiteElo) that have to be
> integers, instead of quoted strings
I think it's mostly fine the way it is now, you can have "?" or an
integer, and you can have some defined way of handling both.
I can see your point though. If someone puts "fred" in there, you don't
know what to do. You are trying to eat these files, and you'd have no
idea what to do with "fred", and no use for it, but you don't want to
destroy it, and you don't want to carry it around in your own format.
If it's not specified that the only valid values are "?" or an integer,
it should be, then you could either honk at the user on these, or
summarily destroy them.
>5) Death penalty for programmers who emit zeroes for castling
The standard says nothing specifically about zero-zero. Edwards has
said in a newsgroup post that zero-zero should mean "double forfeit". I
am against this. This result is so rare that it can be handled with "*"
in the result tag, and a comment, if need be. Much better that we be
able to suck up zero-zero when an errant user types it in.
>6) Making the redundant SetUp tag optional when the FEN tag is
> also present
I have absolutely no idea why this tag exists. It's a tag that tells
you that you shouldn't ignore another tag. If the value is zero, what
should you really do? As far as I can tell there is no defined
behavior.
I would propose simply rendering this tag obsolete and ignoring it.
>Further, the appearance of a revised PGN standard is an opportunity
>to enforce some stricter interpretations in importation routines.
>PGN '98 files should be distinguished with a distinct file type
>or (better) with some kind of internal marker. This would allow
>old sloppy PGN files to continue to be imported, while allowing
>new files to be held to a higher standard of adherence to the
>spec. I.e., the new PGN definition need not necessarily include
>the present language as a compatible subset, since it's easy
>enough for an extant parsing routine to handle both. Indeed,
>the new PGN language might well benefit from being defined as
>a restricted subset of the current language PLUS some syntactically
>distinguishable new capabilities; in this way, PGN files emitted
>under the new definition that don't use the new capabilities would
>still be compatible with the old standard.
>
>I am very enthusiastic about improving PGN (as a compiler writer
>by trade, I think it's in pretty good shape already) and will
>commit to supporting the new definition in CDB as soon as it
>is finalized.
I want to support the standard in my thing, too.
PGN is a big deal, Steven. Are you really going to listen to people, or
are you going to do your own thing and just announce it?
bruce
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.