Naturally Occurring Standards

An anonymous reader writes "The phrase 'de facto standard' can denote anything from proprietary tyranny to a healthy, vibrant, market. What makes a standard viable without the formal blessing of a standards organization? Should you use such informal standards, or ignore them?"

Comments

Tests

[BWJones]

What makes a standard viable without the formal blessing of a standards organization?

The tests would be: "Does that standard meet the needs of disparate groups of people who may be using a tool for different purposes within an organized framework? Is the standard accessible? Also critically important: "does that standard lock one into a narrowly defined structure that is difficult to extend or modify as needs change? Is the standard backwards/forwards compatible? To answer your final question, standards become formalized when they begin to meet these tests and are adopted by appropriate shareholders. This of course is aside from issues of criteria definition, or guidelines which often begin to take on lives of their own and bastardize "standards".

Re:Tests

[Frater 219]

I'm going to take that subject line in a completely different direction. The difference between an informal "standard" and a formal one is that conformance to a formal standard can be tested.

Indeed, that's what the word "standard" meant of old. A standard is a pole, a stick -- such as a flagpole, hence the term "standard-bearer". However, more usefully, a standard is also a measuring-stick. (Another word for a well-sized stick is canon, which gives us the word canonical, meaning correct or orthodox, as well as cane, a walking-stick.) The purpose of a measuring-stick is to see if someone or something measures up -- if it is standards-compliant. Standards equals testing.

A real IT standard spells out required behaviors of the implementation. In a standards-compliant C compiler, the function printf accepts certain formatting codes, and generates specified formatting therefrom. A C compiler which (say) inserts extra decimal places when formatting a floating-point number is not just wrong, but provably wrong. You can write a test suite based on the C99 standard that enumerates every possible printf formatting code, and tests that the implementation does the right thing.

A standard can also spell out what is at fault in a failure. The DNS standards spell out the consequences of lame delegation. The SMTP email standards spell out responsibility for message delivery -- if your mail server accepts a message from a sending system, it is required to deliver it or transmit a bounce message. If you reject the message, it is up to the sending system to transmit the bounce. If the sender complains that their mail was not received and they got no bounce message, an inspection of the server logs can show which system is at fault by being out of compliance with the standard. Again, testing is of the essence here: one system is measuring up; the other is not.

An informal "standard" is an invitation to arguments over what is "acceptable" behavior. A formal standard that spells out exactly what is to be sent over the wire (or recorded in the file, or accepted in source code) can still be a source of debate, but at least the participants can accept that there can be right and wrong answers.