Maybe part of the job of a working group should be to both/either produce or
approve a reference implementation and/or a test for "interoperability"? I
always thought a spec should include an acceptance test. Contracts often
do.
If a company submits code that becomes reference code for interoperability
tests, that code is automatically interoperable and "certified". That might
mean more companies would spend money to produce working code. It might
mean that more working code gets submitted earlier, as the earliest approved
code would tend to become the reference. By code, I don't mean source,
necessarily.
Then there would be a more objective test for compliance and less dependence
on capitalization and the description.
++++++++++++++++++++++++++++++++
Meh. I know the IETF has a thing about these terms, and insofar as they
can
lead to the use of and/or overreliance on compliance testing rather than
interoperability testing, I agree with that sentiment.
OTOH, when it comes to actually, you know, writing code, this entire
attitude
is IMNSHO more than a little precious. Maybe I've missed them, but in my
experience our avoidance of these terms has not resulted in the magical
creation of a widely available perfect reference implementation that
allows me
to check interoperability. In fact in a lot of cases when I write code I
have
absolutely nothing to test against - and this is often true even when I'm
implementing a standard that's been around for many years.
Ned