@eemeli

Note the second sentence there, which is specifically reserving a part of the non-namespaced function and option names for implementations and users, beyond even what's left to them in the namespaced identifiers. Yes, this text was originally written before we'd defined : namespaces, but it also was not modified in #834, where much of the text around it was refactored.

We explicitly want to allow user-defined functions to have non-namespaced options and non-weird option values. That's why that text was (and is) like that. This section is saying what users/implementations can do to standard and optional functions in the registry. If my proposed text is too strong and you think we should SHOULD instead of MUST, suggest that?

This PR presents a different type of requirement on implementations: We're no longer stating what future spec versions might do, but mandating how they MUST behave and what they might allow their users to do.

I think the requirements here were implicit in our stance about the standard function registry: you can't claim conformance if you don't implement these functions with (at least) these options. The stability policy says that we will never remove any of these. But we might add to the list over time. We don't require that implementations provide additional functions or that they support user-defined ones.

The proposed text also requires the swallowing of errors even in places where errors are non-fatal, disallowing them from being emitted even via a side-channel. This does not match our existing behaviour e.g. in option resolution, where we specifically allow for emitting errors for unresolved values while still requiring that the option resolution as a whole succeeds.
The proposed text does not require errors to be swallowed. It requires that specific ones not be produced. That's instead of trying to require that each and every functions and each and every option be positively implemented or have some specific effect.

Notice that these requirements are highly targeted. For standard functions we prohibit Unknown Function. That is, the function must exist. For standard options we prohibit Bad Option for that identifier. We don't prohibit Bad Option for a bad value (this might be clarified).

We ought to allow an implementation to signal that it doesn't support an option or option value while still emitting some formatted output, if we want to include the options currently proposed in #915.

This might be possible? I would tend to add an Unsupported Operation error instead of trying to smoosh everything into Bad Option. It's the difference between searching high-and-low for why my bog standard message doesn't work ("I'm sure I spelled currencyDisplay correctly!!") and finding out that the value variant is unimplemented on this platform.

I'm toying with adding:

The potential problem is the word "unsupported"

I think some examples would help.

In all cases, we want to very significantly reduces the chances of collisions. We could explore — in the future — reducing it further by putting a requirement like java does, based on domain names, but that is clearly way beyond what we should be discussing now.

Non-standard function

• We don't want this to be :list, but rather mozilla:list
• It doesn't need namespaced options or option values, since it defines all of them.

Non-standard option on standard function

• We don't want this to be :number invert, but rather :number mozilla:invert
• It doesn't need namespaced option values, since it defines all of them

Non-standard option value on standard function standard option

• We don't want* this to be :number style=rational, but rather :number style=mozilla:rational

* A key feature for me is that we should distinguish enum options (whose option values are expected to be one of a fixed set of identifiers) from non-enum options, like regex=|[a-z]{3,8}(-[a-z]{3,8})*|. The former would be easy to namespace option values for, while the latter get trickier. I think this distinction is too last-minute for making into 46.1, but would make our approach more cohesive.

I agree with most of your comment @macchiati except:

Non-standard option value on standard function standard option

• We don't want* this to be :number style=rational, but rather :number style=mozilla:rational

An option value can be a literal or a variable.

We don't permit : in unquoted literals nor do we have namespacing in option values as a feature. I don't think we need to introduce namespacing either. Non-standard option values will produce Bad Option errors on implementations that don't recognize the value. The suggestion of introducing a character like underscore that we (the Unicode "we") promise not to use in standard/optional (reserved name) values could help, e.g. :number style=mozilla_rational or :number style=_moz_rational. But I don't think we need to overbake it here.

Sorry, I should have written style=|mozilla:rational|

However, you have a good point. Having a namespace option in option values is unnecessary, because and implementation can always use a namespaced option instead.

That is, instead of :number style=rational, they can use :number mozilla:style=rational

That is much cleaner, and means they are not polluting the standard option's values. What we can the do is simply impose the requirement that:

OLD

Implementations MAY accept additional option values for options defined here,
although care needs to be exercised to ensure interoperability
and to avoid collisions with future standardization.
There is no namespace mechanism for option values,
however, the stability policy for this specification

NEW
Implementations MUST not implement additional option values for standard options of standard functions. Instead, the implementations can use a standard function with a namespaced option that has the additional option values. For example:

1) :number style=rational // must no be used unless some version of this standard has rational as an option value
2) :number foo:style=rational // legitimate, since there is a different namespace.

This lets any parser of the message containing (2) know that there is a special option supported by 'foo'.

That is, instead of :number style=rational, they can use :number mozilla:style=rational

That is much cleaner, and means they are not polluting the standard option's values. What we can the do is simply impose the requirement that:

Meh. Using namespaced options that overlap built-in values leads to conflicts with the non-namespaced variety ({$n :number style=foo ns:style=bar}) as well as the need for messages to be refactored to add/remove namespaces (let's avoid breaking people's translation memories to the degree possible).

I tend to think that namespaced options are fine for implementations to add a feature like icu:skeleton to a function.

For options that we define, we probably should have a "policy" (not in the stability policy) that we will try to avoid adding option values (to avoid breaking existing conformant implementations) but not guarantee that we won't.

So... that means I'd tend to say something like:

If an implementer feels the need for other/different values, they should come to us and ask for it.

@eemeli can you check and see if the changes reflect your understanding?

Merging per agreement in 2024-11-11 call.