be-strict-fr
Soyez stricts dans ce que vous envoyez, mais généreux dans ce que vous recevez
"Be strict in what you send, but generous in what you receive" est un principe en informatique (renvoyant initialement à l'e-mail) qui suggère que les systèmes (tels que les relais d'e-mails ou les parseurs de microformats) devraient être très stricts en s'assurant que leur sortie se conforme aux standards, mais flexibles pour interpréter les données reçues, ce qui peut ne pas adhérer au standard approprié, mais dont le sens est encore non ambigu.
C'est une variante de la Loi de Postel, "Soyez libéral dans ce que vous acceptez, et conservateur dans ce que vous envoyez".
Histoire
Voir hcard-brainstorming-fr pour un exemple sur la façon dont cela pourrait s'appliquer. Andy Mabbett
(Quelqu'un aurait une meilleure explication, des références, ou l'étymologie ?) Andy Mabbett
- Ayant développé durant de nombreuses années et implémenté des standards, AMHA il y à la fois des plus et des moins à la Loi de Postel. Tantek 08:23, 26 Mar 2007 (PDT)
- Que perçois-tu comme inconvénients (tout spécialement dans le contexte des microformats)? Andy Mabbett 08:34, 26 Mar 2007 (PDT)
- Beaucoup de la complexité de construire une implémentation HTML (parseur, browser, mise en page de tableau) table-formatter) a été blâmé sur l'adoption de la loi de Postel par les premiers implémenteurs de navigateurs. Il est maintenant en fait impossible de construire un nouveau navigateur à partir de zéro sans mettre plusieurs millions de dollars en investissement temps passé et ressources d'ingénierie, en dépit du fait que le premier navigateur ait été construit par un seul homme, Tim Berners-Lee. En fait, suivre la loi de Postel peut avoir l'impact d'élever la barrière à l'entrée au développement d'implémentation à un tel point que ce sera prohibitif pour les individuels ou les petites équipes, et seulement possible par les grosses sociétés. Il est non désirable d'obliger implicitement aux ressources d'une grande entreprise (et de ce fait en être dépendant) afin de construire les implémentations des microformats, qui sont actuellement implémentables (ont été implémentées) tant par des individus que des petites équipes. Tantek 08:46, 26 Mar 2007 (PDT)
- Ainsi, à un certain degré : sois généreux en ce que tu reçois - dans la raison? Andy Mabbett 08:57, 26 Mar 2007 (PDT)
- En outre, la Loi de Postel a été tenu responsable pour rendre l'interopérabilité plus difficile dans le cas du HTML, ou plutôt, a même découragé l'interopérabilité, parce que différentes implémentations ont "libéralement/généreusement" traité différemment les erreurs (le HTML invalide) au fil du temps. Tantek 08:46, 26 Mar 2007 (PDT)
- Resolu, dans notre cas, en documentant ici les solutions ? Andy Mabbett 08:58, 26 Mar 2007 (PDT)
- Peut-être. Le principe plus important peut être l'équilibre de simplicité entre l'auteur et l'implémenteur. Je pense que nous (la communauté des microformats) sommes encore en train d'évaluer le niveau optimal de cet équilibre, mais je crois que nous sommes sur la bonne route. En demandant simplement à quelque auteurs de faire qu'il soit raisonnablement facile pour les implémenteurs d'implémenter. Tantek 09:01, 26 Mar 2007 (PDT)
- Resolu, dans notre cas, en documentant ici les solutions ? Andy Mabbett 08:58, 26 Mar 2007 (PDT)
- Beaucoup de la complexité de construire une implémentation HTML (parseur, browser, mise en page de tableau) table-formatter) a été blâmé sur l'adoption de la loi de Postel par les premiers implémenteurs de navigateurs. Il est maintenant en fait impossible de construire un nouveau navigateur à partir de zéro sans mettre plusieurs millions de dollars en investissement temps passé et ressources d'ingénierie, en dépit du fait que le premier navigateur ait été construit par un seul homme, Tim Berners-Lee. En fait, suivre la loi de Postel peut avoir l'impact d'élever la barrière à l'entrée au développement d'implémentation à un tel point que ce sera prohibitif pour les individuels ou les petites équipes, et seulement possible par les grosses sociétés. Il est non désirable d'obliger implicitement aux ressources d'une grande entreprise (et de ce fait en être dépendant) afin de construire les implémentations des microformats, qui sont actuellement implémentables (ont été implémentées) tant par des individus que des petites équipes. Tantek 08:46, 26 Mar 2007 (PDT)
- Que perçois-tu comme inconvénients (tout spécialement dans le contexte des microformats)? Andy Mabbett 08:34, 26 Mar 2007 (PDT)