be-strict
Be strict in what you send, but generous in what you receive
"Be strict in what you send, but generous in what you receive" is a principle in computing (originally referring to e-mail), which suggests that systems (such as e-mail relays or microformat parsers) should be very strict in making sure that their output conforms to standards, but flexible in interpreting data received, which may not adhere to the relevant standard, but whose meaning is still unambiguous.
It is a variant of Postel's Law, "be conservative in what you do, be liberal in what you accept from others".
Background
See hcard-brainstorming#ADR with no children for an example of how this might be applied. Andy Mabbett
(Anyone got a better explanation, references, or etymology?) Andy Mabbett
- Having had many years developing and implementing standards, IMHO there are both plusses and minusses to Postel's law. Tantek 08:23, 26 Mar 2007 (PDT)
- What do you perceive are the disadvantages (especially in the context of microformats)? Andy Mabbett 08:34, 26 Mar 2007 (PDT)
- Much of the complexity of building an HTML implementation (AKA/EG parser, browser, table-formatter) has been blamed on the adoption of Postel's Law by early browser implementers. It is now effectively impossible to build a new browser from scratch without putting in a multimillion dollar investment of time and engineering resources, in spite of the fact that the first browser was built by a single individual, Tim Berners-Lee. Essentially, following Postel's Law can have the impact of raising the barrier to entry to implementation development so high as to be prohibitive to individuals or small teams, and only possible by large corporations. It is undesirable to implicitly require the resources of a large corporation (and thus be dependent on) in order to build microformats implementations, which are currently implementable (have been implemented) by both individuals and small teams. Tantek 08:46, 26 Mar 2007 (PDT)
- So, a matter of degree: be generous in what you receive - within reason? Andy Mabbett 08:57, 26 Mar 2007 (PDT)
- Additionally, Postel's Law has been blamed for making interoperability more difficult in the case of HTML, or rather, even discouraging interoperability, as different implementations "liberally/generously" have treated errors (invalid HTML) differently over time. Tantek 08:46, 26 Mar 2007 (PDT)
- Resolved, in our case, by documenting solutions here ? Andy Mabbett 08:58, 26 Mar 2007 (PDT)
- Perhaps. The more important principle may be the balance of simplicity between publisher and implementer. I think we (the microformats community) are still figuring the optimal level of this balance, but I believe we are on the right track. Asking just a little of publishers in order to make it reasonably easy for implementers to implement. Tantek 09:01, 26 Mar 2007 (PDT)
- Resolved, in our case, by documenting solutions here ? Andy Mabbett 08:58, 26 Mar 2007 (PDT)
- Much of the complexity of building an HTML implementation (AKA/EG parser, browser, table-formatter) has been blamed on the adoption of Postel's Law by early browser implementers. It is now effectively impossible to build a new browser from scratch without putting in a multimillion dollar investment of time and engineering resources, in spite of the fact that the first browser was built by a single individual, Tim Berners-Lee. Essentially, following Postel's Law can have the impact of raising the barrier to entry to implementation development so high as to be prohibitive to individuals or small teams, and only possible by large corporations. It is undesirable to implicitly require the resources of a large corporation (and thus be dependent on) in order to build microformats implementations, which are currently implementable (have been implemented) by both individuals and small teams. Tantek 08:46, 26 Mar 2007 (PDT)
- What do you perceive are the disadvantages (especially in the context of microformats)? Andy Mabbett 08:34, 26 Mar 2007 (PDT)