CommentSeFormentLesStandards

Les standards (tels que RSS, ATOM, …) semblent se former dans un processus d'amalgame.

Il existe quelques besoins de communication qui doivent prendre place qui on besoin d'appartenir à différents morceaux.

La question est : "Comment arrivera la communication ?"

Les gens viennent ensemble à la table avec beaucoup de différentes idées.

PointsImage

Quelqu'un n'aime pas les accolades bouclées. Quelque groupe n'aime pas le XML. Un grope aime le XML. Un groupe pousse le YAML. Quelques personnes haïssent les abréviations. Ces personnes veulent utiliser des tableaux, parce c'est ce qu'elles ont par défaut das leurs éditeurs.

Il existe tous ces petits facteurs.

Mais, il y a une poussée pour que ces pièces parviennent à se parler les unes avec les autres, et à la fin, ce ne sont que des robots parlants à des robots dans tous les sens. Ainsi, les personnes négocient "mec, le relent de X est épouvantable" pour"…mais j'ai réellement besoin de cette fonctionnalité dans le langage, ou elle ne peut pas éventuellement fonctionner pour moi."

PointsConcentrationArrowsImage

Des sous-camps se forment à l'intérieur des camps et les sous-camps fusionnent jusqu'à ce nous ayons simplement quelques points bien définis.

Ici, en lisant de gauche à droite, nous voyons les groupes s'accumuler ensemble.

PointsConcentrationImage

A la fin ici, nous avons simplement trois standards.

A ce stade, vous pouvez simplement écrire des adaptateurs entre les différents standards.

Parfois, un moyen de faire complètement les choses dépasse les autres. (ex : réglage modem N-8-1.)

Parfois, les formats ont des choses à leur propos qui sont impossibles à détruire vers les autres formats. OGG n'est pas aussi populaire que le MP3, mais il ne mourra pas parce que c'est un format libre et MP3 ne l'est pas.

Ce processus est probablement comparable à la formation des langages humains. C'est probablement une affaire très pragmatique et très fouillis.

Discussion

Je peux me tromper ; C'est simplement ma compréhension, fondée sur ce qu'ai vu se passer.

Salut Lion. J'ai fait fonctionner des standards ci et là durant les dix dernières années et en plus vers différents groupes de travail dans lesquels j'ai été impliqué, j'en ai aussi regardé une dizine d'autres. D'un point de vue plutôt informel tes diagrammes collent vraiment aux processus qui se passent dans un groupe de travail, mais ce n'est pas tout à fait à ce point un processus organique, ni fondé généralement sur des préférences personnelles ou business (au moins dans les meilleurs groupes de travail), c'est plus une question de prendre une approche de discipline ingénierie, où le groupe démarre par solliciter des exigences techniques spécifiques (souvent dues à des besoins organisationnels existants), fixe des objectifs de production, puis commence le processus laborieux de donner forme aux détails, étape par étape avec les différentes partie du travail distribuées aux différents membres du groupe de travail. Parce qu'aucun standard (ou pseudo-standard) n'existe dans un vide, ceci comprend aussi généralement tous les autres standards en rapport et toutes les autres formes de documentation qui entrent dans la construction du nouveau. Parfois, ceux-ci ne sont pas encore standardisés, mais peuvent être sous différents formats en versions préliminaires.

Dans tous les cas, le processus (quand il est bien fait) est plus un processus légal et d'ingénierie qui comprend un grande gestion de communication intense, technique et de coopération. Dans les groupes où la majorité des acteurs semblent partager un objectif commun et un sens des buts, et où les exigences sont bien prises en considération, le planning de travail et des objectifs raisonnables, et chaque personne qui a des tâches les produit à temps, ceci peut progresser rapidement. Dans les cas où n'importe lequel de ces composants échoue, tout l'ensemble craque. Parfois le problème provient de facteurs externes, comme quand disons, un directeur de l'organisation des standards rentre avec des exigences qui ne font pas partie des processus du groupe de travail.

Quand un membre du groupe ou de son organisation mécène a des besoins d'affaire qui ne sont pas directement adressés dans les exigences (comme dans le cs de la négociation ou de secrets de compétition), ils peut y avoir une obscurité délibérée et une obstruction. Il y a eu un nombre d'exemples bien connus où des sociétés ont participé dans des standards afin de les corrompre ou de ralentir leurs progrès. J'ai même vu des exemples où les éditeurs des spécifications du groupe refusait d'implémenter les modifications entenus préalablement par le groupe , même après des demandes répétées (dans ce cas dus à ce qu'il travaillait pour une société bien conneu qui avait déjà implémentée la spécification avant qu'elle ne soit finie). Il y a quelques groupes de travail qui ont été essorés sur les mêmes tâches pendant beaucoup d'années et ne finiront probablement jamais leurs travaux, ceci du à soit des ruptures dans la communication, des objectifs non réalistes, ne pas avoir un sens clair des exigences ou de la mission, manque de quelque leadership solide, (et c'est absolument nécessaire) our parce que leurs environnements changent plus vite qu'ils ne peuvent suivre. Travailler dans ces circonstances est simplement mon pire cauchemar (tout comme se lever le matin, regarder aux alentours et m'apercevoir que je dors avec Dick Cheney).

Wow ! Génial !

Je vois que je ne parle à ce sujet que d'une simple petite facette de la formation des standards.

Ton explication est vraiment vraiment bonne ; J'aimerais la mettre en diagramme, et faire que ce soit le texte central de la page.

Quand j'ai écrit la chose au-dessus, je pensais plus à :

  • MP3 vs OGG vs différents encodages audio
  • le zoo RSS/Atom zoo
  • XML-RPC, SOAP

Je ne pensais pas tant à la manière dont les standards de forment à l'intérieur d'eux-mêmes (comment un standard particulier naît et émerge) mais plus à propos de la façon dont de multiples standards interagissent l'un avec l'autre, comment ils en viennent à des standards multiples se chevauchant.

Murray, as tu eu une occasion de regarder ProamInternetCommunicationsAlliance ? C'est une sorte de longue page, parce qu'il y a quelques idées différentes dedans à propos de ce que pourrait être PICA. Mais en tout cas, nous serions intéressés par ton feedback.

J'ai esquissé quelques systèmes (sur papier) pour PICA ; Nous avons vraiment beson de nettoyer cette page. J'ai commencé à retirer l'idée de TechnologyUnion en dehors du coeurs de PICA.

Je continue simplemnt à la faire fonctionner à l'intérieur des spécifications de l'interface qui pourrait vraiment faire usage de quelque chose comme PICA. Je pense que j'en ai au moins 10 flottant aux alentours - le filtrage XML-RPC, le HTTP Pipe, ULI sur XML-RPC/POST/GET, ULI dans Python, Local Names, le Local Names Store, Lookup, et les interfaces Services, le système de liste de bannissement wiki, les BlocsCodeMachine et le Wiki et MoteurWiki encodé à l'intérieur des BlocsCodeMachine

Lion, the thing is, each of those specifications you listed (only a few are products of an actual "standards" authority) came about under very different circumstances, developed by very different groups of people, etc. For example, if I remember correctly, MP3 is standardized by the MPEG committee out of ISO, but had a lot of technological input from a German company named Fraunhofer Institute (see Patents and MP3), who have since claimed intellectual property (patents) over various parts of the standard, and demanded licensing fees of those developing MP3 encoder software. These people are probably not atypical, but played both sides of the standards fence: they provided input into a standard but also wanted to maintain control over its IP. Ugly. They are contributing to the de-legimization of MP3, which is plainly stupid. They should be thinking in the broader term of how what they're doing is allowing Microsoft's proprietary format to gain traction, whereas if they backed off, MP3 would simply be the sole standard — it's a better technology and the wider public know the term, i.e., we call them "MP3 players."

You perhaps know the storied history of RSS, which couldn't possibly have been managed more poorly. It's a terrible mess, and the proprietary and egotistical interests involved have only made it worse. I've not been following Atom for awhile, but I understand it is an attempt to get out from underneath the RSS zoo. I wish it success, but it probably won't succeed because, like the letters "MP3", "RSS" now has the public eye. I'd suggest changing the name of Atom to "RSS 3.0" if it wants to gain any traction. If I blow my nose I use a Kleenex, even if those "facial tissues" were made by a different company. (Have you ever said, "hold on, I need to use a facial tissue?") Getting that kind of brand visibility means RSS will likely survive even if it is a mess. But the mess is very damaging and slows down technological development for no good reasons.

SOAP is a really ugly hack thrown at the W3C by Microsoft, and cleverly marketed as a good idea and implementation. In reality, it would normally have died a painful and bloody death except for being propped up by Redmond, like some banana republic backed by the CIA or the Vatican. Same deal with UDDI and WSDL (see The Battle Over Web Services or Google on "web services battle"). Basically this is the United Nations versus IBM and Microsoft. Guess who wins?

I did allude to the fact that no specifications (which I generally prefer to call them when speaking generally about things that aren't actually the products of standards bodies) exist in a vacuum. Atom wouldn't exist except for the mess-up of RSS, OGG wouldn't exist except for Fraunhofer pushing its weight around. These are all external factors, but it's external factors that generally create the environment in which these specifications are developed. Standards bodies should (IMO) be by nature conservative, and take a long time to develop things, simply because standards should be stable. It often takes time to do things right. Then again, sometimes the situation calls for a quick solution, and sometimes the problem has a simple solution. Take the XML SAX specification, which was spit out in a single email by David Megginson. By contrast, the W3C created the DOM via a working group, and DOM 1, 2 and 3 are all a big mess. They're functional, but ugly. And over-engineered. But they're also different things. Something like MP3 by its very nature has a ton of heavy-duty research involved, the kind of research that has legitimate patent-ability. Not the kinds of patents we see for software, such as the one granted for a pull down menu that launches a program, or the idea of clicking on a link. So it's understandable why Fraunhofer is asserting their patent rights, but they should probably have not brought that IP to ISO in the first place. And so we end up with OGG. As above, OGG should change their name to "MP5" or something to gain traction in the public eye.

Just for the record:

 * Standards bodies:  IETF, ISO, IEC, NISO, BSI, ANSI
 * Industry consortia or trade organizations:  W3C, OASIS, IEEE, AMA, Unicode Consortium

Then again, a "standard" is often what people consider a standard. IEEE considers that they create "standards," so who am I to argue with them? I generally think there's a lot more to it than that, but admittedly standardization is as much a social process as a legal or technical one. Perhaps a better way to think of this is that a "standard" exists within a specific context. That context might be a social or industry group, community, etc. and just means "we've come to an agreement about something." But when a putative "standards body" has either no formal processes (such as Robert's Rules or ways to fairly arbitrate disagreements), a bad history of not following its own processes (when they even exist), has problems with working groups being taken over by cabals of corporate representatives in order to push through a specific agenda, etc. these things smack of what industry consortia probably should be doing (making back door agreements), but they shouldn't call them "standards." SOAP should never be considered a standard. Maybe soap-on-a-rope.

BTW, feel free to refactor any of this. I didn't mean to clutter up your page.

LangueFrançaise PageTranslation HowStandardsForm

EditNearLinks: MoteurWiki

Languages: