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).

[Erwy]

L'effet perfide, c'est qu'un "nouveau" standard qui serait meilleur (au sens des 7 points cités) n'a que peut de chance de s'imposer s'il existe déjà un standard, même moins bon .

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

[jmini]

Sur un sujet proche mais légèrement différent (quoi que), je vous recommande ces deux billets autour des facteurs clés dans la réussite d'une API (de service de site web) :

* Eric Wahlforss, SoundCloud API : “le point de basculement est pour bientôt”
* Alex Payne, Twitter API : “Nous voulons être le bus des messages du web”

[trenton]

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).

Mouais, le cas du Ogg Vorbis est particulier, il est principalement freiné par des entreprises en position dominante qui n'ont aucun intérêt à voir un concurrent arriver sur un marché juteux. Et non pas parce qu'il n'a pas les qualités requises.

[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...

[GrandFather]

Je ne suis pas bien sur que ODF en serait là si OpenOffice n'avait pas eu autant de succès.

C'est évident. C'est bien d'ailleurs pour cela que je le citais, comme l'une des rares exceptions au fait qu'il est de plus en plus rare que ce soit l'usage qui dicte la norme plutôt que le contraire.

De là a dire que les gens ce sont interessés a ODF grace à la popularité de OpenOffice...

Je crois qu'on peut l'affirmer, au moins pour les premiers temps. Mais ça ne remet pas en cause pour autant la qualité intrinsèque du standard, ça ne fait qu'illustrer la pertinence du point N°5 de la liste de Bosworth.

[pseudocode]

Je crois qu'on peut l'affirmer, au moins pour les premiers temps. Mais ça ne remet pas en cause pour autant la qualité intrinsèque du standard, ça ne fait qu'illustrer la pertinence du point N°5 de la liste de Bosworth.

Hum... c'est pas tant le fait que "ca fonctionne" (point n°5 de Bosworth), mais plutot le fait que "c'est populaire" (point n°1 de Pseudocode)

[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...

[souviron34]

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.

C'est totalement faux..

Le point 6 signifie simplement rétro-compatibilité..

Ce qui veut simplement dire admettre une version précédente...

Cela peut se faire en code compilé comme en protocole...

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à je suis d'accord, mais c'est à pondérer (très fortement) par la capacité "marketing"...

Java n'est pas forcément (pas de troll) meilleur que Motif (et même plus pauvre sous bien des aspects) , mais le marketing fin des années 90 début des années 2000 a été beaucoup mieux fait.. On en a églament d emultiples exemples avec les différentes technos , langages, méthodes, etc etc..

Disons que je mettrais la phrase en sens inverse : un standard de fait s'impose quand il est à la fois utile, fonctionnel, et qu'il n'y a pas d'équivalent. Mais un standard de fait peut être relégué au rang de viellerie par un standard imposé (par le W3C par exemple , ou ISO, ou ...M$ , Google, ...)


Maintenant, sur les 7 points, je suis 100% d'accord


Et c'est bien ce qui me rend triste dans l'évolution d'un grand nombre de produits ou de normes (ou de sites (voir la discussion "faut-il interdire Explorer 6" ?)). De plus en plus de versions de langages et de "normes" deviennent incompatibles avec les précédentes, et / ou les développeurs les utilisant se foutent de la rétro-compatibilité, ce qui amène à une instabilité générale, une fuite en avant, et une ré-écriture et obsolecence générale...

[pseudocode]

Et c'est bien ce qui me rend triste dans l'évolution d'un grand nombre de produits ou de normes (ou de sites (voir la discussion "faut-il interdire Explorer 6" ?)). De plus en plus de versions de langages et de "normes" deviennent incompatibles avec les précédentes, et / ou les développeurs les utilisant se foutent de la rétro-compatibilité, ce qui amène à une instabilité générale, une fuite en avant, et une ré-écriture et obsolecence générale...

Il faut dire également qu'avoir un logiciel qui utilise un "standard" est devenu un plus (voir une obligation) pour décrocher des marchés. Et face à cela, il y a 2 moyens : Implémenter un standard existant ou faire standardiser son format/protocole actuel.

(Toute ressemblance avec des évènements récents sur les suite bureautique serait bien sur totalement fortuit )

[Erwy]

(Toute ressemblance avec des évènements récents sur les suite bureautique serait bien sur totalement fortuit )

Pour les deux suites que je connais OOo et office, les standard ont été soumis (après le temps de délivrance c'est autre chose...) avant ou en même temps que la livraison de leur suite bureautique, on ne peut donc pas parlé de format protocole "actuel" vu qu'il n'existait pas avant.
Pour soumettre un format, il faut l'avoir suffisamment "travaillé" pour qu'il ait une chance de passer au travers du protocole de normalisation.
On peut s'y casser les dents à fournir n'importe quoi.

[souviron34]

Il faut dire également qu'avoir un logiciel qui utilise un "standard" est devenu un plus (voir une obligation) pour décrocher des marchés. Et face à cela, il y a 2 moyens : Implémenter un standard existant ou faire standardiser son format/protocole actuel.

oui, mais le problème de fond est que les "organismes de standardisation" sont phagocytés par des représentants ayant un intérêt partiulier (même cas que le comité de l'OMS ou en France pour la grippe A, d'ailleurs)..

Je me suis fait proprement jeter pour avoir soumis une proposition à un tel comité international (sous des prétextes totalement fallacieux et que je peux prouver tels), alors qu'en privé des représentants de ce comité international (dont le créateur du comité et son sous-directeur) trouvaient que c'était parfaitement justifié...

Les intérêts financiers de grands groupes sont les plus souvents à l'origine de "standards", par leur participation "essentielle" aux origanismes de normalisation, et le fait (si on n'est pas dans le circuit universitaire) de proposer quelque chose à l'un de ces organismes est quasi voué à l'échec..

[GrandFather]

De plus en plus de versions de langages et de "normes" deviennent incompatibles avec les précédentes, et / ou les développeurs les utilisant se foutent de la rétro-compatibilité, ce qui amène à une instabilité générale, une fuite en avant, et une ré-écriture et obsolecence générale...

Tu peux être plus explicite concernant ces ruptures technologiques ? Parce que les normes ISO, IEEE ou les standards RFC (pour la plupart) ou OASIS, pour ne prendre que ces exemples, ont jusqu'ici été plus un facteur de pérennité et de compatibilité ascendante dans l'industrie informatique qu'un facteur d'instabilité, il me semble...