11 Apr 95 08:42, Paul Edwards wrote to andrew clarke:

DN>> PID: MaltEd/2 1.0.b6

PE>> I just thought I'd let you know that I am sending a message to 
PE>> the FTSC Chair to complain about your lack of compliance with 
PE>> the PID spec.

PE>> It's the "6" that's non-compliant BTW.

ac>> Does it really matter?

PE> If you think it doesn't matter, then the PID spec should be
PE> changed to make it free-format, that way EVERYONE is happy,
PE> if that is what EVERYONE wants!

If you want a free-format, then you're probably better off ignoring the
PID spec and sticking with the tearline.  PID was designed "to minimize
the excessive amount of information some programs put on the tear lines
 ...".  While I agree with this principle, I don't think FSC-46 should
go as far as specifying a distint sub-identifiers for a program
identifier as does the current version of the specification.

I never said it didn't matter, but there must be a limit to how far you
can take the practice of "reductio ad absurdium" (reduction to the
absurd).

PE> I certainly don't mind the PID spec being changed.

Fine - provided it maintains its usefulness and does not invalidate
previous specifications.


PE> However, the way it is worded at the moment, it tells you very 
PE> precisely what it should be, so that it can be used, e.g. to 
PE> translate "g" into "gamma" if you want to
display it in an 
PE> expanded form.

Such translation should be done at the risk of the programmer, IMO.  My
understanding of FSC-46 has always been that the PID kludge was never
designed for any other use than human consumption; viewing purposes
only (displayed but not parsed).

PE> People's lack of compliance means that such code would break. I 
PE> fail to see why people should have to code around other people's
PE> inability to conform to the specs.

Because this is the real world.  Folks are always bound to either
blatantly or inadvertanty ignore/misuse/misunderstand specification at
one time or another.  Programmers should be aware of this, and do their
best to ensure their code does not break when such instances occur.

PE> Or more to the point, I am happy to do validation that makes
PE> sure anything non-conformant gets a general error of "grunged 
PE> message", and we all know what happens to grunged messages.

Non-conformant != Grunged.

I would hope you would attempt to process any damaged mail manually if
your system were to receive it.


ZeeYa...
Andrew.

---