Fix contradiction in markup resolution #1084
Conversation
Previously, this stated that markup resolution MUST always succeed. However, resolution of `u:` options can fail, so that wasn't true.
|
I noticed this when looking at this test: https://github.com/unicode-org/message-format-wg/blob/main/test/tests/u-options.json#L37 |
There was a problem hiding this comment.
While the resolution of individual options can fail, this still holds:
message-format-wg/spec/formatting.md
Lines 410 to 412 in 9448040
In other words, overall resolution of markup will always succeed.
If there is some language in u: options or elsewhere that implies something different, that needs to be fixed rather than changing this.
|
I've revised the text. This does repeat text from the previous "Option resolution" section, but I think it bears repeating. |
| @@ -434,6 +434,9 @@ supported by the implementation, process them as specified. | |||
| Such `u:` options MAY be removed from the resolved mapping of _options_. | |||
| The resolution of _markup_ MUST always succeed. | |||
| As with _option resolution_ for _expressions_, | |||
There was a problem hiding this comment.
I think this could be confusing. The first normative statement (resolution of markup must always succeed) is a separate requirement. So I'd go:
| As with _option resolution_ for _expressions_, | |
| In addition, as with _option resolution_ in _expressions_, |
There was a problem hiding this comment.
I think the more appropriate fix here would be for the "Option Resolution" section to be moved to be directly under "Expression and Markup Resolution", as it pertains to markup resolution as well as function resolution, and for its first sentence to be corrected to note that.
Then we would not need to repeat the RFC2119 language that it already includes here.
Previously, this stated that markup resolution MUST always succeed. However, resolution of
u:options can fail, so that wasn't true.