3

I've been told on StackOverflow this questions was off-topic so I'm asking here: From this webpage (ISO/IEC 22275:2018):

This International Standard defines the ECMAScript Specification Suite containing the ECMAScript programming language and its required and optional built-in libraries.

As I understand, ISO releases an ECMAScript standard every few years. It seems browsers vendors use the standard made by Ecma as their source of truth. And the ISO standard is just a copy of the Ecma one. I don't understand what is the role of the ISO/IEC committee? Why do we need several standards?

Also, on question about this quote from the ECMAScript wikipedia article:

This edition 5.1 of the ECMAScript standard is fully aligned with the third edition of the international standard ISO/IEC 16262:2011.

Why does Ecma has to make changes to their standard to please ISO if the ISO standard is a copy of the Ecma standard? Isn't Ecma the one in charge of ECMAScript? It's a bit confusing, but I'd love to make more sense about all of this.

Hugh
  • 141
  • 4
  • 1
    I don't know the reason in this case, but this kind of thing is quite common. For instance, Unicode is published by both the Unicode Consortium and a joint ISO/IEC committee; HTML is published by both WHATWG (as a "Living Standard") and W3C (as "HTML 5"). – IMSoP Feb 24 '21 at 11:43
  • 1
    It's also worth noting that the ISO standard in question has now been _withdrawn_, in favour of ISO 22275, which basically says "read these ECMA standards". That may give a hint as to the original motivation for a separate ISO standard - they wanted to be able to reference it within the ISO eco-system, and initially thought copy-and-paste was a reasonable way to do it. – IMSoP Feb 24 '21 at 11:53

1 Answers1

6

Standard-setting organizations in general

First, who are the actors of this standardization process?

  • ECMA is an industrial consortium, that associates a few big companies (about 37 of them, e.g. Microsoft, Google, IBM,, etc) in the domain of information and communications technology and consumer electronics. The standards it establishes are optional:

    It is not mandatory for Ecma members to implement any Ecma standard.

  • IEC is an international standard setting organisation, that associates entire countries (about 170) in the domain of electrical, electronic and information technologies. Each country is represented by a national committee that is representative of the national interests, in practice, public interests (government representatives/experts) and private interests (e.g. corporations).

  • ISO is an een larger standard setting organization, that associates countries without limitations on specific domaines.

The broader the interests represented in a standard setting organization, the more (and the longer) the discussions about the standard content. But also, the broader the influence of its adopted standards.

The effects of standardization

If ECMA produces a standard, other ECMA members may want to adopt it, for interoperability or efficiency purpose. But they don't have to. It's a non-binding private standard.

If after larger discussions on the base of an ECMA proposal, IEC or ISO comes to the conclusion that an important need is not well addressed, they might correct the standard. Once the ISO standard is out, all around the globe, ISO compliance will be expected. It might even be mandatory in some public context or in regulatory processes (see for example here about US, and here about EU where the international standards admitted in specifications are ISO, IEC and ITU as far as I understand).

Why would ECMA want to change?

When ECMA manages to push their standards more broadly via IEC or ISO, having their standard adopted by ISO is the paramount of success, since their privately decided standard made it through, world-wide. But if ISO changes something on the way, the ECMA initial standard is no longer aligned with the global reference standard. It would be too risky for ECMA members not to be compliant with the ISO standard they inspired. This is why ECMA may want to align back on ISO.

There is another reason as well: standards are like source code: they are version managed. So for the sake of sound version management, it might be interesting to bring the "ISO patch" to the trunc before working on a new version ;-)

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • Thanks a lot for your detailed answer. It makes a lot more sense now. So in practice, are browsers vendor trying to be fully compliant with [ISO/IEC 22275:2018](https://www.iso.org/standard/73002.html) when developing their JS engine? Is there any change that in the near feature, let's say, the US law requires browsers to be fully compliant with ISO22275? – Hugh Feb 25 '21 at 05:29
  • 1
    Unfortunately not. ECMAScript mandates Proper Tail Calls since 2015, but almost no ECMAScript engine implements them. In fact, some that *used to* implement them have actually removed them again. – Jörg W Mittag Feb 25 '21 at 07:22
  • 1
    @Hugh Law may require compliance with ISO or IEC standards but this is rare and usually in limited area (like safety and security). Mostly, the influence is less direct: typically, this happens, through specifications in public call for tenders. Or specification of a product that is used in a call for tender (e.g. frameworks or reference models). Browsers are rarely bought separately (Firefox and Chrome are free, Edge comes with the OS, ...). More relevant for node servers or software that is supposed to interoperate with other components (probably more relevant for ISO 16262). – Christophe Feb 25 '21 at 19:07
  • 1
    @Christophe: The ISO specification effort for Ruby was largely financed by the Japanese government agency responsible for the advancement of IT technologies, primarily to allow *other* Japanese government agencies whose rules require tools conforming to an international standard with multiple independent suppliers to use Ruby. It's more of a token gesture, since at the time Ruby had a big backwards-compatibility breaking cleanup process, and most implementations supported only the old version, one implementation supported only the new version, and no implementation supported both. – Jörg W Mittag Feb 25 '21 at 23:48
  • 1
    The goal was that no implementation had to change to be compliant with the spec, and thus the spec only specified features that existed identically in all implementations, which is actually only a pretty small subset of Ruby. In particular, text handling was completely redesigned between 1.8 and 1.9, and thus text handling couldn't be specified because whatever they would have chosen, at least one of the implementations would not have been compliant. And since the first release 13 years ago, the spec was never updated. – Jörg W Mittag Feb 25 '21 at 23:49