Why are we introducing “extensions” into The Standard?

[tychonievich]

In #393 @Norwegian-Sardines asked

My question here is, Why are we introducing “extensions” into The Standard? Shouldn’t we be setting a “Standard”?

Also, Should The Standard copy or implement a specific application’s implementation of a possible solution -or- should The Standard implement a solution that is of its own making? The Standard can use as input a design suggestion from other implementations but those implementations may not be complete, language independent, or neutral and open enough for all applications to implement within their system!

That seems like a broader topic than that one issue and worth discussing here.

Also, I'll clarify (as @Norwegian-Sardines did in the #393 discussion) that this is about standards committee-introduced extensions, not vendor-introduced extensions which arguably have a different purpose.

[tychonievich]

Reasons I see that the GEDCOM steering group and working groups might introduce an extension rather than a standard:

• Design flexibility. Extensions let us try out a particular design, see if it works, and modify or abandon it in backwards-incompatible ways if it's not working as well as we'd hoped or a better design comes up.
• Vendor buy-in. Standards need to balance moving quickly enough not to become irrelevant yet not so quickly that applications have trouble keeping up. Extensions provide a way to see if there is an appetite for a new feature before making it standard.
• Messaging. If new features first appear in the standard, often lag between a standard release and vendors implementing it, giving the public image of "the newest standard is unstable". Putting them first in extensions gives vendors a chance to implement them before they become standard, hopefully giving the public image of "the newest standard is usable" instead.

One of the most successful other standards groups for interoperability between mutually-competing products, the W3C, also uses extensions in a similar way, with working groups publishing working drafts and vendors implementing them behind extension flags with years of design tweaks before either scrapping the proposal or deciding there is enough buy-in to make it standard, resulting in highly successful messaging.

GEDCOM traditionally has not run in this way. From 3.0 to 7.0 it has operated by a small group of developers working on the next version, getting feedback on it from a few vendors, and then releasing it as a standard. In my opinion, this has resulted in designs I think would be a bit cleaner if we could tweak them a bit, standards being released with some features almost no vendors want or use, and a public perception that the newest standard won't be widely supported.

Personally, I'd like to change that. I think an extension-first process could help. Whether extension-first should be limited to big new features like https://github.com/dthaler/gedcom-citations and https://github.com/fisharebest/gedcom-name is part of what #393 is asking. Whether it should include small tweaks like #230 is what #394 is asking.