Discussion :

[souviron34]

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

les anciennes, c'est exact..

Pour les nouvelles, ben justement les trucs HTML ... tout le paquet de choses ajoutées ou modifiés ne sont pas accompagnées de "règles de bonne conduite" disant qu'il est fortement recommandé d'être tout de même compatible avec les versions antérieures...

Pour ISO, c'est un peu pareil en ce qui concerne les méthodologies...

Mais je parlais plus de trucs comme XML, ou plutôt pour ce que je connais GML, et les choses comme ça..

Je rappelle que l'un des points mentionnés parmi les 7 est la simplicité et la lisibilité.. Quand on a besoin d'un cours pour comprendre un protocole, c'est qu'il n'est pas simple (d'autant plus que l'autre règle est qu'il soit lisible...)

[pseudocode]

Mais je parlais plus de trucs comme XML, ou plutôt pour ce que je connais GML, et les choses comme ça..

Tu peux aussi parler des protocoles réseaux : téléphonie mobile, sans fil, ...

Les normes se suivent et ne se ressemblent pas.

[GrandFather]

Mais je parlais plus de trucs comme XML, ou plutôt pour ce que je connais GML, et les choses comme ça..

Pour XML, depuis 1998 on commence à les discerner les bons usages, ainsi que les anti-patterns d'ailleurs puisque rien n'est parfait en ce bas monde, mon bon monsieur... XML n'a pas été vraiment une rupture, puisqu'il est issu de SGML, tout comme HTML. Il estcependant bien plus simple que son ancêtre (comme quoi les normes ne sont pas forcément de plus en plus complexes), et d'un usage bien plus large.

[pseudocode]

Pour XML, depuis 1998 on commence à les discerner les bons usages, ainsi que les anti-patterns d'ailleurs puisque rien n'est parfait en ce bas monde, mon bon monsieur... XML n'a pas été vraiment une rupture, puisqu'il est issu de SGML, tout comme HTML. Il estcependant bien plus simple que son ancêtre (comme quoi les normes ne sont pas forcément de plus en plus complexes), et d'un usage bien plus large.

Mouais... entre SOAP/REST ou XML/JSON, je pense qu'on commence a voir les limites du mantra "XML est la solution pour tout".

[Erwy]

XML sont but c'est l'interroperabilité et aussi la réutilisation de données dans un but qui peut être différents de celui voulu à l'origine.
REST et JSON sont spécialisé dans une tache et une technologie.Tant qu'on n'a pas besoin de faire autre chose ils sont parfaits, si on en sort , au mieux c'est l'usine à gaz au pire, on oublie.

Si XML avait atteint ses "limites", on verrait moins de standards basés dessus ou au moins moins d'implémentation . C'est exactement l'inverse depuis des années.

cela fait plus de 6 ans que je pratique ce type de techno et depuis mes débuts tout les mois je lis que XML "a atteint ces limites", j'ai même lu vers 2005-2006 (voir plus ancien, c'est le travers des archives du web , quand on dit une annerie, cela reste longtemps visible...) des messages de gens sérieux et fortement diplomé annonçant que XML était condamné à une fin rapide.....

Ceux qui portent ce type de jugement ont un point communs.Leur spécialité n'est pas la donnée et son traitement, et il ne comprennent généralement pas que les informations qu'ils utilisent dans leur domaine particulier, ou il est toujours facile de spécialisé et optimisé un format de donnée, peut être tout aussi utile ailleurs, mais ou ce format si "spécialisé et optimisé" oppose une fin de non recevoir

[GrandFather]

Mouais... entre SOAP/REST ou XML/JSON, je pense qu'on commence a voir les limites du mantra "XML est la solution pour tout".

Tu ne m'aurais pas un peu lu en diagonale, par hasard ?

C'est exactement mon propos : il a fallu du temps pour discerner à partir de la norme les usages où XML apportait une réelle plus-value de ceux où il n'en apportait pas, voire était contre-productif. Le fait qu'il soit extrêmement répandu dix ans après tendrait à prouver que la première catégorie supplante de loin la seconde.

Au passage, REST n'a pas supplanté SOAP, loin de là. Il en est par contre une alternative intéressante pour les catégories de problèmes qui ne feraient qu'une utilisation minimaliste des possibilités de SOAP. A noter également que SOAP (HTTP & SMTP) est plus indépendant du protocole que REST (HTTP uniquement).

Pour XML et JSON, il est vrai que JSON a remplacé XML, et avec profit, pour ce qui était de faire de l'AJAX. Maintenant, si tu souhaite récupérer ton flux de données pour le traiter dans un autre contexte, il faut que l'autre plate-forme dispose de fonctions de lecture et de décodage JSON, et qu'elles soient compatibles avec le résultat qu'on en attend... ce que XML permet « nativement ».

Franchement, en terme d'interopérabilité XML a parfaitement rempli son contrat.

[pseudocode]

Pour XML et JSON, il est vrai que JSON a remplacé XML, et avec profit, pour ce qui était de faire de l'AJAX. Maintenant, si tu souhaite récupérer ton flux de données pour le traiter dans un autre contexte, il faut que l'autre plate-forme dispose de fonctions de lecture et de décodage JSON, et qu'elles soient compatibles avec le résultat qu'on en attend... ce que XML permet « nativement ».

Franchement, en terme d'interopérabilité XML a parfaitement rempli son contrat.

Hum... l'interop via SOAP n'est pas vraiment une réussite pour ma part.

Exemple de la semaine dernière : appeler un web-service tomcat/axis depuis dotNet. Impossible de retourner/lire un objet avec un attribut "tableau d'entiers" Après lecture des specs, il apparait qu'il y a plusieurs moyens pour encoder un tableau en SOAP. Et bien sur, Axis et dotNet n'ont pas pris le même.

Pour ma part, le fautif c'est la spec : 2 moyens de faire la même chose, c'est un de trop. Ce qui est dénoncé dans le point #4 de la liste. Et pourtant c'est un standard. Va comprendre...

[Erwy]

Pour ma part, le fautif c'est la spec : 2 moyens de faire la même chose, c'est un de trop. Ce qui est dénoncé dans le point #4 de la liste. Et pourtant c'est un standard. Va comprendre...

Je n'ai trouvé que la recommandation pour soap 1.2
http://www.w3.org/TR/2001/WD-soap12-...011002/#arrays
Je n'ai pas particulièrement vu 2 façon de faire.Maintenant cette spec date de 2007, ce qui peut être récent en terme d'implémentation,est ce qu'il n'y aurait pas plutot un problème de version de SOAP et non de spécification ?

Ce genre de problème existe bien, je le connais dans XML Schema ou pour un cas particulier il existe deux méthodes exclusives pour comprendre la spec et donc la réaliser.
XML Schema est d'ailleurs un des contre-exemples repris dans l'article sur ce qui peut causer le (semi-)echec d'une spécification.

[GrandFather]

Pour ma part, le fautif c'est la spec : 2 moyens de faire la même chose, c'est un de trop. Ce qui est dénoncé dans le point #4 de la liste. Et pourtant c'est un standard. Va comprendre...

On peut aussi y voir une faiblesse de l'implémentation qui, en allégeant le travail du développeur de la charge d'avoir à tout définir via le WSDL et en automatisant le maximum de choses, lui impose un cadre plus rigide que ce que permet la norme. A décharge, WSDL ne doit pas être, comme les W3C XML Schémas, ce qu'il y a de plus facile à implémenter...

[pseudocode]

Je n'ai trouvé que la recommandation pour soap 1.2
http://www.w3.org/TR/2001/WD-soap12-...011002/#arrays
Je n'ai pas particulièrement vu 2 façon de faire.Maintenant cette spec date de 2007, ce qui peut être récent en terme d'implémentation,est ce qu'il n'y aurait pas plutot un problème de version de SOAP et non de spécification ?

Auquel cas, si la version est aussi importante pour un format d'interop, la spec devrait forcer un check et imposer de générer une erreur "Incompatible SOAP version". Mais en fait, non. Le problème c'est que l'un des 2 (axiz ou dotnet) a créé un type complexe intermédiaire (ArrayOfInt) alors que l'autre utilise directement "SOAP-ENC:arrayType".

Enfin, pour quitter SOAP et en revenir a la discussion, les standards ne suivent pas forcément les règles. Un format devient "un standard" lorsqu'il est adopté massivement, que ce soit grâce a sa "beauté" ou parce que c'est le seul disponible pour répondre à la problématique. Exemple: Flash.

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