Description
The stability policy is too weak to be useful:
Consider the following.
- After v47 releases, implementation X defines its own custom function :unit. This formats unit names, like “mètre” in French, not amounts. Its literal operands are defined to be unit_identifier.
{{L'unité est :{|meter| :unit}formats as “L'unité est : mètre” in French- That is a valid message; it is well formed and meets the various semantic requirements.
Then
- In v48, LDML adds :unit as a standard function. It formats unit measures, like “3 meters”. Its literal operands are defined to be “-” <unit_identifier>.
- The formerly valid
{{L'unité est :{|meter| :unit}becomes no longer valid- It doesn’t conform to the requirements for a now-standard function
- (And will throw a Bad Operand error)
That is, our stability policy does not guarantee that new versions won't break old messages. Our current stability does not cover the standard functions, so it is only "weakly" stable.
What I think we want is something like the following:
Some definitions:
- Default functions {are defined already}. Custom functions are those that are not default functions.
- Default options are options on default functions that are those REQUIRED or OPTIONAL in this spec. Custom options are those that are not default options.
- Default attribute identifiers are those REQUIRED or OPTIONAL in this spec. Custom attributes are those that are not default attributes.
- Default markup identifiers are those REQUIRED or OPTIONAL in this spec. Custom markup identifiers are those that are not default markup.
A well-behaved implementation is one that never allows reserved identifiers for any of the following:
1. custom functions
2. custom options for standard functions
3. custom attributes
4. custom markup
If an implementation is well behaved, then upgrading to a new version of the spec will not break old messages. (this is not spec language, but that should be goal for a new stability guarantee).
Also change the note under custom-identifier to use SHOULDs.