Do not promise stability with all options

[eemeli]

This is a follow-up to #798 (comment), and it's intended to solve the following issue: We should allow for the 2.0 set of default function options to be extensible by later versions of the specification. To take one example, we currently explicitly leave out currency from the :number options, and only say that implementations "SHOULD avoid" creating an option that conflicts with its possible meaning.

This means that an expression {42 :number currency=dollaridoos} is currently technically valid, and does not emit any errors -- the "dollaridoos" value is ignored. This severely restricts what can be done in the future, as the Stability Policy promises that:

Updates to this specification will not change the syntactical meaning, the runtime output, or other behaviour of valid messages written for earlier versions of this specification that only use functions defined in this specification.

I propose that we relax this promise to only apply to messages that use default function option values that we actually define, and not any other option values.

[aphillips]

Recall that there is a function registry that we're creating and it's versioned. We need to incorporate stability for the function registry. While this wording is fine for the limited purpose of fixing the current text, I think we need to separate the output guarantee and function registry promised from the syntax guarantee intended here.

[eemeli]

This is not only intended to provide a guarantee about the syntax; the mention of "runtime output, or other behaviour" is explicitly included.

[aphillips]

I get it. The problem is that "the runtime output" can't be stabilized--CLDR data changes all the time! And "other behavior" is too nebulous. We also don't want to promise things like "the selection won't change" or "the formatting won't change". Much of what happens in an MF2 message is actually controlled by the locale, data, and local implementation of the functions.

I think an overhaul is probably warranted?

Suggested change

	that only use functions defined in this specification
	and options explicitly defined for them.
	Updates to this specification will not make any well-formed or valid _message_ invalid.
	Functions and options defined in this version of this specification shall not be removed. Options and option values can be added. Existing options and option values will not be removed.

[eemeli]

I think that an overhaul as you propose is a separate PR. I'd be happy to consider it, but it needs to be considered in the wider context of the whole stability policy.

Would you be comfortable with us adopting this smaller change first, and then reworking a greater part of the policy? I continue to prefer smaller steps that improve the spec, even if we do identify while taking them that further subsequent steps will be needed.

[aphillips]

No, I don't think so. Is this PR obsolete in light of #834 and the changes we're making for #634/the function registry?

[eemeli]

This can be closed if/once #834 is merged.

[aphillips]

closed in 2024-08-26 call