be-strict: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(insert quote)
m (Reverted edits by CaricElbas (Talk) to last version by Brian)
 
(7 intermediate revisions by 5 users not shown)
Line 3: Line 3:
"'''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.  
"'''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.  


See [[hcard-brainstorming#ADR with no children]] for an example of how this might be applied.
It is a variant of [http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law Postel's Law], "''be conservative in what you do, be liberal in what you accept from others''".


(Anyone got a better explanation, references, or etymology?)
==Background==
* I believe this is a variant of [http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law Postel's Law], "''be conservative in what you do, be liberal in what you accept from others''". Having had many years developing and implementing standards, IMHO there are both plusses and minusses to Postel's law. [[User:Tantek|Tantek]] 08:23, 26 Mar 2007 (PDT)
 
See [[hcard-brainstorming#ADR with no children]] for an example of how this might be applied. [[User:AndyMabbett|Andy Mabbett]]
 
(Anyone got a better explanation, references, or etymology?) [[User:AndyMabbett|Andy Mabbett]]
 
*Having had many years developing and implementing standards, IMHO there are both plusses and minusses to Postel's law. [[User:Tantek|Tantek]] 08:23, 26 Mar 2007 (PDT)
**What do you perceive are the disadvantages (especially in the context of microformats)? [[User:AndyMabbett|Andy Mabbett]] 08:34, 26 Mar 2007 (PDT)
**What do you perceive are the disadvantages (especially in the context of microformats)? [[User:AndyMabbett|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. [[User:Tantek|Tantek]] 08:46, 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. [[User:Tantek|Tantek]] 08:46, 26 Mar 2007 (PDT)
Line 12: Line 17:
*** 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. [[User:Tantek|Tantek]] 08:46, 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. [[User:Tantek|Tantek]] 08:46, 26 Mar 2007 (PDT)
****Resolved, in our case, by documenting solutions here ? [[User:AndyMabbett|Andy Mabbett]] 08:58, 26 Mar 2007 (PDT)
****Resolved, in our case, by documenting solutions here ? [[User:AndyMabbett|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. [[User:Tantek|Tantek]] 09:01, 26 Mar 2007 (PDT)
==References==
==References==
*[http://en.wikipedia.org/wiki/Robustness_Principle Robustness Principle]
*[http://en.wikipedia.org/wiki/Robustness_Principle Robustness Principle]

Latest revision as of 10:40, 5 January 2009

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)

References