Re: PGN Specification Revision

Adam Blinkinsop wrote:

I used the RFC's definitions of printing characters, an attempt to
avoid conflict by bowing to another standard. Do you think the set
should be defined differently?

I think the term should follow the character set standard you refer to.
If Latin-1, then the term should probably be 'graphic character', and
so on. This is a nasty area, since you essentially have to have a copy
of the official standards text. (I tend to go for the ECMA standards
when I can get away with it: some ISO standards are relabelled ECMA
standards, and many ECMA standards can be downloaded for free. Google
for "ECMA 94", for instance. Terminology tends to remain unaltered over
this relabelling, but section and page numbering does change.)

Absolutely. The thing is, any parser that works to spec will be
working with the "import" format, which doesn't care how many
tokens-per-line there are.

I interpret the document differently: input format is intended to
cover data that may have been created by hand, and is for that reason
less formal. A PGN reader should be able to handle import format, but
there is nothing that says that it must parse all input files as if they
were input format. Export format files should be checked to export format
standards on input: if I import a PGN file expected to be of archive standard
into a database without verifying that it indeed follows archive format,
I may import a file of lower quality than intended.

If I wrote a PGN reader, I'd probably made this user-defineable.

But most PGN utilities do what you say: accept import format as input,
and do little more than a token acknowledgement at archive format on
output. I have PGN files with nested {}-comments -- should be
impossible to produce except by hand, and should definitely be possible
to detect as an error on input.

(This is one of those areas where I wish there had been some
explicit statement about format: '%PGN 1.0 ARCHIVE' as first line
could flag an archive file. Without it, it's treated as an import
file.)

However, the problem you raise is a moot
one: export data is required to place the move immediately after the
period (no spaces). Unnecessary, if you ask me.

From an engineering point of view, it is. But from a standards point
of view, well ... . If you're trying to restate PGN more clearly
and less ambiguously, you shouldn't change it. (This is where
I thought you were). But if you do change it, you should probably not
use 'PGN' as name of the format, unless you also make it clear that you
have made changes, and made it very clear what those changes are,
and possibly even explain why those changes do no lead to
incompatibilities.

I don't see any problems with a 'moot points in PGN and my
interpretation of them': that's what every PGN utility should have.
That could very well include deliberate departures ... but then such
a document won't seem to be a format specification.

No matter -- I'll save my hostile specification reading mode for later.

--
Anders Thulin ath*algonet.se http://www.algonet.se/~ath

.

Relevant Pages

  • Re: [kde] smb://
    ... follow the RFC for urls which is the way standards are set. ... a format I can't handle, I ask them for it in a format I can. ... application (that costs $$$ to buy, and my time to install) under one OS ... KDE should push for some method of registering URL ...
    (KDE)
  • Re: [opensuse] document incompatibilities
    ... conform to HIS standards will win you no friends in the office. ... closed format recovering something usable in this situation was often ... took up excessive resources when it went wrong. ... environment you are in), its up to YOU to make your software ...
    (SuSE)
  • Re: Database Model - Class, objects and interaction [LONG]
    ... open info exchange format. ... normally find in a standards document. ... form than a standard API :-), but in any case I think the term is ... If there is an ODBC client C, and a database server S with ODBC ...
    (comp.object)
  • Re: Word 2003 XML
    ... So there are many sites That are written that have information Mac users could use, but can't get at it because FronTPage was used to design it, And therefore Only IE users can view it. ... If Microsoft really had made a life's work out of not using any standards, ... group chose the XML format that Microsoft adopted over the open format ...
    (microsoft.public.mac.office.word)
  • Re: pgn alternative
    ... >> it is trivially readable and writable by humans. ... >> convert between PGN and your format. ... > with this hybrid between the Fianchetto and Schliemann defences to the ...
    (rec.games.chess.computer)
Loading