Pourquoi les programmeurs ignoreraient-ils les normes ISO? [fermé]


18

Une des choses que je rencontre est souvent des problèmes causés par les programmes qui ne sont pas conformes à la norme ISO normess.

Un exemple serait de ne pas utiliser les tableaux de pays ISO mais de créer leurs propres raccourcis, ce qui va bien pour les États-Unis (États-Unis) ou les Pays-Bas (NL) mais va de manière spectaculaire pour le Royaume-Uni (GB, pas UK) ou l'Espagne (ES, pas SP) et beaucoup d'autres pays.

Comme autre exemple, les notations de date internes. Pourquoi quelqu'un enregistrerait-il une date au 01/02/2014? Il n'est pas clair si c'est le 1er février ou le 2 janvier, alors que si vous utilisez la norme ISO, vous stockez simplement le 2014-02-01 * et c'est sans ambiguïté le 1er février.

Ma question: quand et pourquoi un programmeur devrait-il créer ses propres constructions alors qu'une norme ISO est disponible?

* Stockez le 2014-02-01 et formatez la date en conséquence lorsque vous la montrez à un utilisateur final.


64
Parce qu'ils ne les connaissent pas ou les ont oubliés! Il y a des millions de normes ISO .... Connaissez-vous tout ISO26262?
Basile Starynkevitch

11
Habituellement, un manque d'expérience en tant que programmeur vous fait faire des choses dont vous ne réalisez pas les conséquences. Généralement, un rapide "Je vais le faire comme ça" est pensé instantanément sans aucune évaluation pour savoir s'il existe déjà quelque chose pour cela ou non.
dammkewl

13
De plus, de nombreuses normes ISO ne sont pas si faciles à trouver (elles coûtent généralement beaucoup d'argent, et trouver le dernier projet n'est pas si simple!).
Basile Starynkevitch

64
La grande chose au sujet des normes est qu'il y a tellement de choix!
Jörg W Mittag

5
Parmi les choses les plus étranges, il y a les programmes qui forcent un utilisateur non anglais sur un utilisateur de langue locale non anglais à changer ses paramètres locaux à l'échelle du système en points décimaux afin de fonctionner correctement. Sans parler des programmes qui refusent de fonctionner ou produisent simplement des ordures sous des caractères non anglais (russe, japonais, grec), sans parler des systèmes RTL (hébreu, arabe). Il y a de l'ignorance, je suppose.
JensG

Réponses:


63

N'attribuez jamais à la malveillance ce qui s'explique adéquatement par la stupidité. - Robert J. Hanlon .

Ça, et un manque de communication.

Donc, ce n'est pas une conspiration de sentiments anti-ISO qui fait penser aux gens "Je sais, je vais utiliser le Royaume-Uni au lieu de GB", ni une tendance à "qu'ils connaissent mieux", ni même le sentiment que la norme n'est pas bonne . Ce sera entièrement parce qu'ils ne savent tout simplement pas que c'est là et qu'ils devraient l'utiliser.

Je veux dire, pour certaines personnes, s'il n'est pas intégré à Visual Studio , il pourrait tout aussi bien ne pas exister. Pour certains autres, peut-être qu'ils ne veulent tout simplement pas l'ensemble complet ou qu'il est trop difficile de récupérer la liste définitive, alors ils ne font que créer leur propre sous-ensemble pour résoudre leur situation immédiate. Pour d'autres, la valeur par défaut est ce qui est utilisé - donc le formatage de la date n'est pas "formaté en ISO, ou même dans les paramètres régionaux du pays", il est "formaté dans tout ce qui sort" et si cela leur convient, alors c'est du travail fait (c'est généralement un critique des programmeurs américains).


20
Cela n'aide pas que beaucoup de normes ISO soient chères et / ou difficiles à obtenir ... Même si vous en avez vraiment envie!
heltonbiker

aaaa-mm-jj ... n'est pas cher
halfbit

11
@halfbit: cher à l'achat, peu coûteux en ressources informatiques. Sérieusement, parcourez leur magasin . Vous voulez la norme à virgule flottante ? Ce sera 178 francs.
user2357112 prend en charge Monica

32

Lorsque je programme en Ruby, j'ignore généralement toujours la norme ISO Ruby. Pourquoi? Parce que c'est incroyablement restrictif! ISO Ruby est un sous-ensemble minimal de l'intersection de Ruby 1.8 et Ruby 1.9. La version actuelle de Ruby, qui est prise en charge par toutes les implémentations Ruby (ou du moins le sera très bientôt) est Ruby 2.1, et elle possède de nombreuses fonctionnalités qui facilitent la programmation. La programmation en ISO Ruby est un PITA.

Lorsque je programme en C #, j'ignore également ISO C #, qui est un sous-ensemble de C # 2.0 (et plus important encore, la bibliothèque de classes ISO est un sous-ensemble extrêmement petit du .NET BCL), et à la place je programme en C # 5.0 et je ne Je ne me limite pas à utiliser uniquement les bibliothèques spécifiées dans l'ISO CLI, à la place j'utilise le sous-ensemble commun de bibliothèques disponibles dans .NET 4.5.2 et Mono 3.4.0.

Et lorsque je fais de la conception Web, je préfère de loin utiliser HTML5 plutôt qu'ISO HTML (qui est un petit sous-ensemble de HTML 4.01 Strict), encore une fois, car HTML5 est beaucoup plus riche en fonctionnalités qu'un sous-ensemble restreint d'une ancienne version de HTML.

Il y a donc de bonnes raisons d'ignorer les normes ISO.


9
Cela dépend, avec C, C ++, Fortran ... la situation est très différente.
Vladimir F

1
Cela semble moins comme «ignorer» comme le veut la question, et plus comme «choisir un outil qui fait ce dont vous avez besoin». Si vous avez besoin de fonctionnalités C # 5.0, il n'est pas plus logique d'utiliser ISO C # que d'utiliser ISO C ou ISO Fortran; ce n'est tout simplement pas l'outil que vous avez demandé, et ISO n'a pas d'équivalent. Votre exemple implique également de s'en tenir à des normes bien définies, mais pas à celles ISO.
Leushenko

3
@Leushenko, je ne suis pas d'accord; l'OP semble penser que vous devriez toujours suivre les normes ISO, point final. +1 pour un contre-exemple effronté de ce «devrait».
djechlin

3
Très bien, mais je pense que la question parlait vraiment des normes ISO pour la représentation des données, pas des normes ISO pour les langages de programmation.
Aaronaught

4
Certains soutiennent que (certaines) normes ISO sont un parfait exemple de l'anti-modèle "Design by Committee" ...
heltonbiker

22

Selon votre exemple, "GB" est le code de pays pour le Royaume-Uni. Cependant, "UK" était en même temps le code standard MARC (US Library of Congress), bien que je pense que ce soit obsolète. Et l'IANA utilise .ukpour le domaine de premier niveau pour le Royaume-Uni.

Donc, si quelque chose n'est pas conforme à une norme ISO, cela ne signifie pas qu'aucune norme n'est utilisée; cela peut simplement signifier qu'une norme différente est utilisée. (Comme @ Jörg l'a noté dans un commentaire, la bonne chose à propos des normes est qu'il y a tellement de choix.) Dans ce cas, la question devient vraiment quelle norme serait la plus appropriée pour le domaine de problème, l'environnement, etc. ?

Les réponses à cette question seraient probablement largement basées sur l'opinion et dégénéreraient rapidement en un débat "religieux". Mais la conformité aux normes ISO n'est pas nécessairement toujours la meilleure réponse. Par exemple, si un logiciel doit s'interfacer avec des bases de données de bibliothèque, les normes MARC pourraient être un choix plus approprié que l'ISO. Si la plupart des logiciels de votre organisation font les choses d'une certaine manière, vous voudrez peut-être vous en tenir à cette approche, au moins à court terme - c'est la «norme» de votre organisation, après tout.


De plus, les normes évoluent / changent. Ce qui était conforme hier peut ne pas l'être aujourd'hui.


Et, même si je ne voudrais pas exclure l'ignorance et / ou la paresse comme cause des problèmes que vous signalez ... le développeur n'a peut-être tout simplement pas eu assez de temps pour les résoudre.


15

La conformité à une norme ISO n'est pas toujours une activité gratuite. Si une norme particulière n'est pas déjà implémentée dans la boîte à outils qu'elle utilise, un programmeur est confronté au choix nécessaire: est-ce moins cher de l'implémenter correctement maintenant, ou de ne pas implémenter la norme et de gérer les conversions plus tard?

Il est facile de dire "hé, vous devez toujours appliquer la norme", mais tout a un coût. Et il y a de bonnes raisons pour lesquelles un programmeur peut ne pas vouloir implémenter une norme ISO.

  • Le client peut suivre une norme propriétaire ou non ISO. Mieux vaut tenir compte de la norme à laquelle un client s'attend que de laisser des maux de tête involontaires à votre successeur en cachant une mise en œuvre supplémentaire en plus de ce que le client veut et de votre langue.
  • Il peut y avoir beaucoup de données existantes et une conversion ou un saut de format peut ne pas être encore possible. Si vous avez vingt ans de contacts avec les clients et de contrats avec des dates-heures locales, vous ne voulez pas nécessairement changer tous ces centaines de millions de champs en dates standard ISO jusqu'à ce que vous puissiez le faire correctement.
  • L'adhésion à la norme peut imposer un coût plus élevé que l'avantage prévu. Si vous traitez des entrées entièrement aux États-Unis, par exemple, le code ISO-3166-2 à cinq caractères (US-NY) correspond à trois caractères inutiles par rapport au code postal américain standard (NY).

1
Mis à part les processus agiles, il est toujours moins coûteux d'inclure une fonctionnalité - y compris une norme ISO - pendant la phase de conception / spécification que pendant la phase de mise en œuvre / maintenance, car la phase de conception ne représente que 10% du travail. Il s'agit simplement d'une inversion de la loi des rendements décroissants - semblable à la façon dont l'identification et la correction d'un défaut de production peuvent coûter jusqu'à 10 fois plus que s'il a été trouvé à la suite d'un test unitaire ou d'un test d'acceptation. Si vous avez une raison solide pour ne pas utiliser la norme ISO du tout , c'est très bien; si vous dites que vous l'appliquerez plus tard, vous mentez.
Aaronaught

@Aaronaught: Pensez-vous que je devrais préciser que par "conversion", je voulais dire une conversion de fichier externe, plutôt qu'une réécriture interne?
DougM

Si c'est ce que vous vouliez dire, je voudrais certainement clarifier. Ce n'est normalement pas aussi simple, car l'ISO définit plus de normes pour les types de données que les types de fichiers, et beaucoup, sinon la plupart des développeurs traitent d'applications qui ne traitent pas de documents ou de "fichiers" en soi. Si, par exemple, vous stockez une date ou un code pays non ISO dans une base de données (et ne stockez pas la date ISO ou le code pays correspondant), le coût de la conversion sera très élevé. D'un autre côté, si vous parlez simplement d'importer un type de fichier spécifique à l'industrie, vous pouvez le faire à tout moment.
Aaronaught

+1 "... vous ne voulez pas nécessairement changer tous ces centaines de millions de champs ... jusqu'à ce que vous puissiez le faire correctement." Exactement.
David

14

Dans le cas des programmeurs / concepteurs de bases de données inexpérimentés , c'est parce qu'ils ne savent pas. Ils ont tendance à réinventer la roue parce qu'ils ne connaissent pas un groupe de personnes couvrant des industries, ont déjà discuté de la question et ont proposé une norme approuvée par tous ceux qui ont participé, souvent après de très longues discussions, révisions, etc. Récemment, un collègue J'ai fait preuve d'incrédulité lorsque je lui ai dit qu'il existait une norme ISO pour savoir si une semaine donnée était considérée comme la dernière semaine d'une année ou la première de l'année suivante ( ISO 8601 ). Il ne croyait pas qu'il existait une norme concernant quelque chose d'aussi spécifique. Je lui ai dit que l'exactitude de nombreuses demandes dépendait de cette norme.

Dans le cas des programmeurs / concepteurs de bases de données expérimentés , c'est le mépris causé par le «savoir mieux» , le syndrome non inventé ici et / ou la grandiosité. Ils ne font pas confiance à l'ISO ou à tout autre organisme normalisé car ils considèrent que le code ISO n'est "pas assez stable" , ce qui signifie qu'il changera un jour. Ils créent donc leurs propres codes / identificateurs inventés ici ou auto-incrémentés qui entravent l'interopérabilité, ce qu'ils ignorent également. Voir cette question similaire , bien que la conception de la base de données soit inclinée. Ils donnent des raisons comme:

Je ne veux pas nécessairement que ma conception de base de données dépende d'un tas de tiers (IATA, ISO), quelle que soit la stabilité de leurs normes. Ou, je ne veux pas du tout dépendre d'une norme particulière.

entrez la description de l'image ici

Curieusement, ceux qui ne respectent pas les normes utilisent des ports USB standard, achètent des DVD et BluRays de taille standard et conduisent des voitures avec des pneus conformes aux normes.


12
-1 pour votre caricature de programmeurs anti-ISO expérimentés.
djechlin

4
@djechlin Les phrases entre guillemets sont littérales à partir de vraies réponses à la question liée. Vous pouvez même rechercher dans la page pour voir que ce sont de véritables opinions. De plus, tous les programmeurs expérimentés ne détestent pas les normes.
Tulains Córdova

2
@djechlin Dans ma réponse, il y a une question liée, recherchez "voir cette question similaire". Le mot "question" a un lien. Là, vous pouvez rechercher les phrases exactes entre guillemets.
Tulains Córdova

2
@djechlin le lien est dans la réponse, pas la question, vous l'avez ici: programmers.stackexchange.com/questions/204340/…
Tulains Córdova

5
D'un autre côté, la personne qui a écrit cette réponse déforme la question liée; le problème n'était pas avec les personnes ne voulant pas utiliser les normes, mais avec dépendant de la stabilité d'une norme particulière comme clé primaire . La plupart des concepteurs de bases de données expérimentés tenteront aujourd'hui de vous éloigner des «clés naturelles», point final, car elles se révèlent presque inévitablement moins naturelles que vous ne l'aviez supposé à l'origine. C'est simplement un argument pour découpler la conception de la base de données physique des données logiques - personne n'a dit de ne pas utiliser du tout les normes.
Aaronaught

10

Eh bien, les gens ont tendance à ignorer les normes ISO: par exemple, vous avez écrit

si vous utilisez la norme ISO, vous stockez simplement 20140201 * et c'est sans équivoque le 1er février.

mais le rendu entièrement conforme à ISO8601 est en fait 2014-02-01 . (voir aussi xkcd 1179 )


7
La norme ISO8601 autorise les formats AAAA-MM-JJ et AAAAAMMJJ pour des représentations complètes de la date du calendrier.
Pieter B

1
En effet; d'où mon écriture "pleinement conforme". 20140201 est le format "de base" de la norme.
Clément

8
ISO permet le format de base et étendu, les deux sont entièrement conformes.
Pieter B

10
ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.classique
WernerCD

8

L'une des raisons est que le domaine d'application et les utilisateurs peuvent ne pas utiliser eux-mêmes ces normes. Même lorsque certains domaines utilisent certaines normes, certains d'entre eux ont pu faire des choix différents des normes ISO, souvent pour des raisons historiques.

Si vos utilisateurs utilisent déjà "UK" dans leurs procédures existantes (1) pour faire référence à "Royaume-Uni de Grande-Bretagne et d'Irlande du Nord", cela n'a pas nécessairement de sens d'utiliser "GB" dans leurs structures de données (surtout si ce que vous par pays n'est pas tout à fait un pays "ISO", par exemple la séparation des nations britanniques ou des différences subtiles avec les îles anglo-normandes, etc.). Bien sûr, vous pourriez avoir un mappage entre le stockage interne d'une présentation, mais parfois, c'est un peu exagéré. Vous programmez rarement pour des raisons de programmation, vous devez souvent vous adapter à votre environnement. (2)

Vous devez également vous rappeler que ces normes ont évolué en parallèle avec les logiciels. Vous devez souvent vous développer dans le contexte d'autres logiciels, dont certains peuvent être imparfaitement conçus, dont certains peuvent encore être affectés par des décisions héritées.

Même si vous regardez les formats de stockage de données internes, certaines ambiguïtés sont difficiles à résoudre. Par exemple, pour autant que je sache, Excel utilise un nombre décimal pour représenter les horodatages: il utilise un entier comme nombre de jours depuis une date de référence, puis ce qui est après la décimale représente la fraction des 24 heures pour vous donner l'heure. .. Le problème est que cela vous empêche de prendre en compte les fuseaux horaires ou l'heure d'été (23h ou 25h par jour), et Excel convertira toute date / heure en ce format interne par défaut. Que vous souhaitiez ou non utiliser le format ISO devient sans importance si un autre logiciel avec lequel vous devez travailler ne vous laisse pas le choix.

(1) Je ne parle pas ici de "procédures de programmation".

(2) Ne me demandez pas non plus pourquoi les gens n'utilisent pas ces normes dans leur vie quotidienne. Je veux dire YYYYmmdd est clair, dd / mm / YYYY est clair, mais commander une date avec un ordre de granularité moyen, petit et grand comme mm / dd / YYYY, cela n'a tout simplement pas de sens :-).


1
Ha! Tu sais ce qui n'a pas de sens? Des virgules où les décimales devraient être! ;)
Darkwater23

@ Darkwater23 Ha, ça ne me dérange pas de toute façon, c'est juste une convention et ça n'a pas besoin de sens. C'est juste que j'ai toujours trouvé que mm / dd / YYYY semblait manquer de logique, pourquoi ne pas aller jusqu'à mm-MM-dd-HH-YYYY pour les horodatages ;-) Mais bon, je suis d'accord, c'est juste la voie ça l'est, donc nous devons vivre avec.
Bruno

2
@ Darkwater23 En fait, une norme ISO utilise un symbole unicode étrange (ceci :) pour le séparateur décimal sur les claviers , et je pensais que les graduations simples ( ') étaient également normalisées pour le regroupement des chiffres (bien que je ne puisse pas le trouver maintenant)
Izkata

+1 pour avoir souligné une autre raison pour laquelle l'heure d'été est une perte de temps.
ctrl-alt-delor

1
@richard Cela ne me dérange pas nécessairement DST de toute façon, mais les programmeurs devraient sûrement chercher à stocker leurs horodatages avec des informations de fuseau horaire autant que possible. Il n'est pas rare qu'une application soit utilisée sur plusieurs fuseaux horaires (indépendamment de l'heure d'été), en veillant à ne laisser que peu de place à l'ambiguïté lorsque vous stockez un horodatage devrait faire partie de la conception initiale. (Ce n'est peut-être pas toujours applicable, mais dans le doute, cela vaut toujours la peine d'être pris en compte.) Bien sûr, c'est un problème compliqué (pas seulement +01 heure par exemple, mais la localité peut aussi avoir de l'importance, selon l'utilisation).
Bruno

8

Pourquoi ne devrais-je pas utiliser les codes de pays ISO 3166-1 alpha-2 ?

Parce que j'utilise les codes de pays STANAG 1059 ... et que le Royaume-Uni est le code du Royaume-Uni (au lieu de GB selon ISO 3166-1).

Sinon, je pourrais utiliser les codes de pays FIPS - encore une fois, UK est le code de pays pour le Royaume-Uni.

Il existe de nombreuses normes (ISO et non ISO) et parfois un domaine particulier utilise / exige une norme incompatible avec la norme ISO.


7

Le stockage de 20140201 n'est pas du tout sans ambiguïté. Ce n'est que lorsque vous incluez les connaissances qui suivent la norme ISO que cela devient sans ambiguïté. Il en va de même pour le 01/02/2014: lorsque vous incluez la connaissance que le format est mm / jj / aaaa, il est également parfaitement sans ambiguïté.

Tant que l'application n'a pas à s'interfacer avec une autre application, n'importe quelle norme bien documentée peut fonctionner aussi bien.

Il y a un compromis entre ce qui est facile pour les humains (j'ai tendance à utiliser 1-2-2014) et les ordinateurs (qui seraient encore mieux avec une représentation binaire au lieu d'ISO). Les programmeurs débutants ont tendance à s'en tenir à ce qu'ils peuvent facilement comprendre, plus les programmeurs commencent à voir les avantages du stockage orienté ordinateur.


4
D'accord. Je serais plus concerné par l'ISO si j'écrivais une demande de consommation internationale. Mes applications pour l'Amérique centrale n'ont pas besoin de frais généraux ou de restrictions.
Darkwater23

4
En écrivant «Tant que l'application n'a pas à s'interfacer avec une autre application», vous avez donné une bonne raison d'utiliser la norme ISO.
Tulains Córdova

5
Votre profil ne répertorie pas votre emplacement, donc je ne sais pas si votre date d'échantillonnage est en janvier ou février.
djechlin

6
-1 pour supposer qu'il n'interfère pas avec d'autres applications. Cela est contraire à l'ensemble de l'industrie de la programmation.
djechlin

18
@Jeff: Je n'ai JAMAIS vu de date codée YYYYDDMM à d'autres fins que de prétendre qu'un tel codage est possible. Avez-vous?
supercat

5

Un point qui n'a pas été soulevé jusqu'à présent est l'adéquation culturelle des normes internationales.

Considérez la norme internationale pour les mesures. Présentons-les aux utilisateurs aux États-Unis. Je ne suis pas sûr que tous vos utilisateurs américains seront satisfaits des kilomètres, des kilogrammes et des litres.

Considérez que les normes internationales sont écrites par les gouvernements. Si le gouvernement espagnol choisit de ne pas reconnaître la langue basque, comment obtient-il une spécification ISO? C'est particulièrement un problème avec les dialectes et les créoles des groupes marginalisés.

Même les codes de pays peuvent être problématiques: la Crimée a-t-elle désormais son propre code de pays? Des formules sont finalement trouvées (par exemple, "ex-République yougoslave de Macédoine"), mais votre candidature peut nécessiter une certaine place jusqu'à la fin de la diplomatie ou de la guerre.

Considérez que les normes internationales sont écrites avec des applications particulières à l'esprit. Ceux-ci peuvent ne pas correspondre entièrement à votre application. Par exemple, si vous stockez une langue en vue d'envoyer des lettres, vous souhaiterez peut-être coder les aveugles de manière distincte, même s'ils sont capables de parler, par exemple, l'anglais américain. Les organismes statistiques sont bien conscients de la nécessité de spécifier la signification exacte d'une variable (alias les «métadonnées» de la variable) car ils rencontrent tous les cas marginaux possibles lors d'un recensement de la population. Une partie de cette rigueur vaut bien pour les champs de base de données.

Le dernier point est qu'en faisant ce genre de choix, votre programme peut faire une déclaration politique. Cette réalité peut perturber le plus beau du code (par exemple, vous pouvez avoir besoin de plusieurs noms de langue pour la même langue).


Je pense que la plupart des aveugles pourraient demander à quelqu'un de leur lire une lettre. Ce n'est pas comme si vous étiez la première personne (ou entreprise) à leur envoyer une lettre.
Wildcard

5

D'après mon expérience, les programmeurs ne parviennent pas à utiliser les normes ISO pour diverses raisons, par exemple:

  • "Je ne savais pas qu'il y avait une norme ISO" (cesse d'être une raison valable une fois qu'on vous le dit!)
  • "La norme est inaccessible (ne peut pas trouver / se permettre une copie)" (vraiment ??)
  • «La norme est trop restrictive» (généralement si la norme dit «non», alors il y a une bonne raison. Ignorez-la à vos risques et périls!)
  • "La norme n'inclut pas la dernière fonctionnalité / bibliothèque" (aucune norme n'inclut TOUTES les bibliothèques que vous voudrez utiliser, alors respectez la norme pour les choses qu'elle comprend / couvre et soyez cohérent avec la norme pour les choses que ce n'est pas le cas)
  • "La norme est trop lourde à mettre en œuvre" (excuse largement surutilisée mais voir ci-dessous)

La seule raison que j'accepte de la part de mon personnel, comme n'étant pas une excuse boiteuse, est "la norme n'est vraiment pas un bon" ajustement "" - étayée par des preuves. Parfois, la complexité de la norme ISO applicable est hors de proportion avec le problème / la solution. Parfois, le contexte dans lequel vous implémenterez votre solution est considérablement différent de celui supposé par la norme. Et parfois, la norme peut être améliorée - c'est ainsi que les progrès se produisent.

Plus souvent qu'autrement, le non-respect de la norme ISO peut être attribué à l'inexpérience, à la paresse ou à l'arrogance. J'ai le regret de dire que les programmeurs anglophones sont particulièrement coupables de paresse en matière d'internationalisation et que nos collègues américains ont tendance à percevoir l'ISO comme "une chose européenne non pertinente" (excuses à la minorité à laquelle cela ne s'applique pas).


5
Ce n'est pas nécessairement une chose européenne non pertinente, c'est une chose non pertinente à moins que vous ayez besoin d'interagir avec quelqu'un qui les suit. À quelle fréquence les Européens suivent-ils les normes ANSI sans autre raison que leur apparence?
stonemetal

1

L'ISO a beaucoup de normes. Tout comme le CCITT / UIT. Certaines de ces normes sont des normes "ambitieuses", tandis que d'autres sont des fonctionnalités minimales requises. Il n'est pas souvent clair qui est lequel.

Je me souviens dans les années 80 de demander pourquoi certains fournisseurs d'équipement implémentent un sous-ensemble de la norme alors que d'autres fournisseurs implémentent un sous-ensemble différent. C'est à ce moment-là que les normes sont souvent fixées avant que quelque chose fonctionne. Et les fournisseurs choisissent souvent délibérément de ne pas mettre en œuvre de normes afin de nuire à l'interopérabilité, ce qui leur confère alors un avantage.

C'est pourquoi j'aime les RFC IETF. Ils ne deviennent même pas des RFC tant qu'il n'y a pas 3 implémentations indépendantes de la RFC.


2
Le modèle «consensus approximatif et code courant» de l'IETF a été bien abandonné depuis au moins dès 1995. J'étais trop impliqué dans l'IETF à cette époque et le modèle était «une spécification que j'ai éternuée et pas même une implémentation de référence ". C'était bien quand le standard "code en cours d'exécution" était en place au lieu de trouver comment implémenter un protocole totalement sous-spécifié et le faire fonctionner avec d'autres implémentations qui devaient deviner autant que vous.
msw

1
Lorsque j'ai commencé à utiliser les RFC IETF, j'ai utilisé ceux développés bien avant 1995. Les spécifications du code en cours d'exécution sont les meilleures. Sinon, vous vous retrouvez avec trop d'ingénieurs en cartographie à tour d'ivoire rêvant de spécifications sans la responsabilité de les faire fonctionner.
Jay Godse

1

Si je crée une base de données Oracle et que je souhaite stocker des dates, je vais utiliser le type de données Oracle DATE. Je ne saurai pas ou ne me soucierai pas si Oracle est conforme ou non à la norme ISO. Il s'agit vraiment d'un cas de ma conformité à une norme différente (celle d'Oracle) et non pas tellement à l'écart de la norme ISO. Voir la réponse de @ David.

Dans certains cas, au moment où je me suis rendu compte qu'il y avait une norme ISO pour quelque chose que j'avais conçu, le coût du retour en arrière et de la refonte aurait été prohibitif, ou du moins était vu de cette façon.

À court terme, plus de code de travail est produit en utilisant les normes disponibles ou en en inventant de nouvelles que par une recherche minutieuse des normes existantes. L'inconvénient se produit lorsqu'une intégration à grande échelle nécessite une interopérabilité. Cela se produit presque toujours dans le contexte d'un projet ultérieur.


1
Je ne connais pas Oracle, mais lorsque j'utilise SQL Server ou MySQL, j'utilise aussi bien sûr leurs types de données de date respectifs lors du stockage des dates. Mais lors de l'écriture de requêtes avec des dates, ils reconnaissent tous les deux très bien yyyymmdd là où il y a un problème lorsque vous utilisez une date locale.
Pieter B

C'est un bon point. La norme pour le stockage et la norme pour l'interface peuvent être différentes.
Walter Mitty
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.