RE: 1.x or 2.x

All-

I remember fondly some of these same discussions when we tried to establish the
desired behaviour for ibischk in light of revision 2.x of the spec. We finally
came down to the notion that ibischk is more than merely a parser for ibis
models. It is a tool to check for adherence to the spec. So if we are
building, or attempting to build, verion 1.x compliant models we definitely
want the checking tool to test against the syntax and behaviour intended by the
version 1.x spec. Period. And absolutely and fully. Similarly if we are
testing a model intended to be version 2.x compliant we certainly want all the
things both demanded and allowed by the new spec to be demanded or allowed by
the tool. Thus the switch and the dual personality of the ibischk tool. It is
more than a parser. Now if you start discussing how a parser to be embedded in
a simulator should behave, it should be no more demanding than the rest of the
simulator insists on. In fact it should be as forgiving as the rest of the
simulator code will allow. Thus, for example the Interconnectix version allows
some thongs beyond the strict spec, as I remember. ( Bob Ross, please correct
me quick if I lied here! :-) ) Just to use it as a specific example.

Still if the ibischk tool does not meet the expectations or intentions of the
spec, it should change. We intended to free up a lot on the metric suffixes
allowed, but we still had a defined set. I suggest that that full set, but no
other should be allowed by ibischk, and leave the possibility of more freedom
yet to individual parsers attached to tools.

Just the $0.02 worth of one who was part of that spec. :-)

Thanks,
Bob Ward
Received on Fri Nov 29 15:03:42 1996