Hello Markus,

On Thursday December 06 2018 18:05, you wrote to Fred Riccio:

 MR> This is what I've meant with the confusion about which "standard"
 MR> applies. Apparently Jerry's converter follows the undocumented feature
 MR> Carol mentioned. So it would extract additional addresses which aren't
 MR> intended for binkp for a node entry following the FTSC docs (if listed
 MR> take just the address in the IBN flag). How do we resolve this
 MR> dilemma?

We should not even try. Adding exceptions every time some idiot creates a
deviation from the established standard is undoable. Yes, in theory one could
create a flag to signal which interpretation of the INA flag is tio be used,
Schwartz or FTS-5001.  But than we'd have to agree on the flag. And then what
if someone uses the same flag with exactly the oppostie meaning. Well, we could
create another flag to signal which interpreation of the flag that signals
which interpreation of the INA flag is to be used. Etc, etc...

 MR> If all entries for Z1 nodes follow the undocumented feature
 MR> then I could add a special case to my tool to take also the addresses
 MR> listed in the INA flag. And Jerry would have to do the same, just the
 MR> other way around.

This is an unworkable situation. Once a standard is established, all shoukld
follow it and one should not create new interpretations that conflict with the
existing standard.

 MR> The frustating thing is that it's hard for sortware developers to know
 MR> about undocumented features.

It is not just hard, it is impossible to keep up with all the exceptions and
upgrade the software if there is no limit imposed on it.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303