Discussion :

[Erwy]

Conception d' un format/procotole : les 7 clés du succès par Adam Bosworth

Adam Bosworth a été vice président d'une division de Google jusqu'à récemment. Il a été très impliqué dans la conception et l'implémentation de nombreux standards comme par exemples ODBC, OLE DB ou XML. Il a aussi participé à l'élaboration de XML Schema qu'il considère comme un semi-succès (échec).
De toutes ces expériences ,réussite comme échec, il a fait récemment le point.

Sur son blog, il refait le point sur les 7 clés du succès de conception d'un standard en format/protocole:

1. Garder le standard aussi simple et « stupide » que possible:
   les probabilités d'échec sont au moins le carré du degré de complexité de la norme mais aussi le carré de la taille du comité de rédaction de la norme.
   
2. Les données échangées doivent être lisibles et faciles à comprendre:
   les standards sont adoptés par des ingénieurs fabriquant du code pour les implémenter. Ils ne peuvent le réaliser que s'ils peuvent facilement le comprendre (voir point 1) et facilement le tester. C'est pourquoi, au cours des 15 dernières années, les normes basées sur du texte comme HTTP, HTML, XML, et ainsi de suite ont gagné.
   
3. Les standards fonctionnent mieux quand ils sont «*ciblés*»:
   Une partie du génie du web, c'est que Tim Berners-Lee a correctement séparé le protocole (HTTP) de ce que le navigateur devrait afficher (HTML). C'est un peu comme la séparation d'une enveloppe et de la lettre à l'intérieur, elle est fondamentale et nécessaire. Les normes qui incluent tous les niveaux ou les couches entassés en un ensemble ont tendance à échouer.
   
4. Les standards devraient utiliser des encoding précis:
   ODBC a été précis sur les types de données.
   
5. Toujours avoir une implémentation pratique effectivement utilisée dans le cadre de conception de la norme:
   Il est difficile de savoir si quelque chose fonctionne réellement ou peut être modifié dans un but pratique jusqu'à ce que vous ayez réellement à le faire.
   
6. Faire passer en Hystérésis (définition ) face à l'imprévu:
   C'est quelque chose que les formats web font particulièrement bien. S'il y a quelque chose dans HTTP que le récepteur ne comprend pas, il l'ignore. Il ne bloque pas. S'il y a quelque chose en HTML que le navigateur ne comprend pas, il l'ignore. Il ne bloque pas.
   
7. Faire une publication libre et publique sur le Web avec de nombreux exemples sur le site même:
   Les ingénieurs sont seulement des êtres humains. Ils apprennent par l'exemple et si le standard est conforme aux points ci-dessus, les exemples seront clairs et précis.

Source
Adam Bosworth’s Weblog

Lire aussi

La rubrique XML/XSL et SOAP (actu, forum, tutos) de Développez

Et vous ?

Que pensez-vous de cette analyse ? Certains points vous paraissent superflus ou au contraire cette liste vous paraît-elle incomplète ?
Voyez-vous des exemples qui confirment ou infirment cette analyse ?

[r0d]

Je ne parviens pas bien à appréhender la portée de ces recommandations. Cela concerne seulement les standard destinés au web?
Parce que par exemple, le point 6 est inapplicable à la plupart des langages compilés.

[Erwy]

je ne suis pas sûr de répondre à ta question ,ni que j'interpète correctement, mais je ne pense pas qu'il faille y voir systématiquement l'interprétation du langage le HTML qu'il donne en exemple est un langage déclaratif, il ne fait pas de traitement.Je vois plutot çadans le traitement des données .
Par exemple , en XSLT le cas ou la donnée demandée n'existe pas ne lui pose pas problème, il se contente de ne rien faire.
Je crois que tu as un certains langages fonctionnels qui fonctionne de la même façon dans ce cas.

[GrandFather]

Cela concerne seulement les standard destinés au web?

Pas spécifiquement le web, mais tous les standards de communication et d'interopérabilité entre systèmes hétérogènes. Ce que sont ODBC, HTTP, XML, AJAX (à l'élaboration duquel a également contribué Bosworth).

Les normes de langages de développement rentrent effectivement difficilement dans ce cadre, même si le principe n°1 dit principe « KISS » (Keep It Simple Stupid) pourrait être appliqué avantageusement à certaines...

[pseudocode]

Conception de standard: les 7 clés du succès

Hum... Le titre devait plutôt être :

"Conception d' un format/procotole : les 7 clés qui en feront (peut-etre) un standard"

Un standard s'impose "de fait". Les 7 points listés permettent une plus large adoption et donc favorisent l'éligibilité d'une spécification au rang de standard. Mais ce n'est pas obligatoire.

On ne peut pas vraiment dire que le JPEG/MPEG respecte les points cités, et pourtant c'est un standard incontournable.

[Erwy]

On ne peut pas vraiment dire que le JPEG/MPEG respecte les points cités, et pourtant c'est un standard incontournable.

Il les respecte peut être plus que ces concurrents ?

J'ai néanmoins édité le titre en ce sens

[pseudocode]

Il les respecte peut être plus que ces concurrents ?

Les standards "de fait" s'imposent naturellement lorsqu'ils sont à la fois utiles, fonctionnels et surtout - surtout - quand il n'y a pas d'équivalents sur le marché.

L'effet perfide, c'est qu'un nouveau format qui serait meilleur (au sens des 7 points cités) n'a que peu de chances de s'imposer s'il existe déjà un standard, même moins bon (exemple Ogg Vorbis/Theora contre Mpeg 3/4).

[GrandFather]

Un standard s'impose "de fait". Les 7 points listés permettent une plus large adoption et donc favorisent l'éligibilité d'une spécification au rang de standard. Mais ce n'est pas obligatoire.

C'était vrai il y a peut-être encore quinze ans, ça l'est beaucoup moins aujourd'hui. Les technologies largement utilisées et issues d'une initiative isolée, et qui accèdent au rang de standard sans que ça en soit le but premier sont devenues très rares ; le seul exemple « récent » qui me vienne à l'esprit est la normalisation ISO de OpenDocument, format XML qui dérive directement de celui des documents OpenOffice 1.x.

Ca s'explique assez simplement, l'innovation étant devenue difficile et nécessitant toujours plus de moyens, il est moins dangereux de concevoir des standards que de se lancer dans des expérimentations hasardeuses à large échelle. Quitte à ce que le standard soit peu ou pas adopté du tout.

[pseudocode]

Je suis plus ou moins d'accord.
Si on prend les technos de validation de XML on a comme premier standard les DTD. Ensuite vient les XML Schema (qui ne respectent pas vraiment le point 1 ce qui explique leur semi-succès), puis viendront les Relax NG qui, si on en croit leurs utilisateurs (je n'ai jamais pratiqué, donc sans avis) sont plus simple et plus efficace que les XML Schema.

XML Schema a bien remplacé les DTD dans de nombreux cas (car il permet plus de chose) par contre les Relax NG me semblent minoritaires (jamais croisés). D'ou mon + ou - d'accord

Oui, il arrive que les développeurs choisissent de migrer vers un nouveau standard quand il y a un avantage indéniable (simplicité, liberté, ...). Ca arrive d'autant plus que si l'ancien standard est particulièrement mal foutu.

Mais si le nouveau format est plus-ou-moins équivalent pour le développeur, le cout de la migration n'en vaut pas la peine et l'ancien standard reste prédominant.

C'était vrai il y a peut-être encore quinze ans, ça l'est beaucoup moins aujourd'hui. Les technologies largement utilisées et issues d'une initiative isolée, et qui accèdent au rang de standard sans que ça en soit le but premier sont devenues très rares ; le seul exemple « récent » qui me vienne à l'esprit est la normalisation ISO de OpenDocument, format XML qui dérive directement de celui des documents OpenOffice 1.x.

Je ne suis pas bien sur que ODF en serait là si OpenOffice n'avait pas eu autant de succès. De là a dire que les gens ce sont interessés a ODF grace à la popularité de OpenOffice...

[Thorna]

Conception d' un format/procotole : les 7 clés du succès
Garder le standard aussi simple et « stupide » que possible:
les probabilités d'échec sont au moins le carré du degré de complexité de la norme mais aussi le carré de la taille du comité de rédaction de la norme.

Oui oui oui... H323 et SIP sont 2 excellents exemples de la simplicité, garantie du succès...

[thelvin]

Hmm, je suis très d'accord avec pratiquement tout ce qui se dit dans son article et qui se résume dans ce post.

Mais

[*] Faire passer en Hystérésis (définition ) face à l'imprévu:

Surtout pas malheureux !

Enfin, disons plutôt, il ne faut pas le dire comme ça.

Souvent la récupération d'erreur est une bonne chose. En effet, de nombreux formats le prouvent, comme http, html, et, au fond, pas mal de formats xml en partie aussi.

Mais pas toujours.

Cette décision ne doit pas être systématique. Elle doit être le résultat d'une étude du risque d'accepter des données incorrectes parce qu'on n'a rejeté que ce qui avait l'air incorrect. Il n'est pas toujours possible de protéger un protocole de cela. Et si le protocole peut servir à l'échange d'à peu près n'importe quoi, accepter la partie mais pas le tout peut avoir des conséquences graves.

Il est très important de choisir le juste milieu entre bloquer sur toute invalidité et ignorer tout ce qu'on "comprend pas." Au pire rejeter systématiquement est un choix assez sécurisant, mais qui provoquera des lourdeurs dans le format et défavorisera son adoption (sauf si c'est justement ce qu'on attend de lui.)

Surtout pas le dire comme ça.


Le reste de l'article, je l'ai lu en diagonale, mais il me semble que j'abonde dans son sens.