{^} ACTION REQUIRED -- ballot of error handling

[aphillips]

Per the discussion in the 2024-07-15 teleconference (along with preceding calls on the same topic), there has been a call for voting on the resolution of error handling in the LDML46 version of the specification.

WORKING GROUP BALLOT

Please read the instructions CAREFULLY before responding.

Please carefully read the design document before responding. Please make pull requests against the design document for the addition of material facts or corrections.

Update (2024-07-17)

Apologies to all: I failed to publish the discussion thread. Please see #831 for that.

Balloting Instructions

Using the SINGLE TRANSFERABLE VOTE process, rank your choice(s) for error behavior.

The deadline is 1700 (5 PM) in the America/Los_Angeles time zone on Sunday, 21 July 2024 Votes received after the deadline will be considered at the discretion of the chair.

• A group member in good standing MAY submit exactly one vote consisting of a ranked set of choices up until the deadline.
• A group member MAY edit, change, or delete their vote up until the deadline.
• Votes MUST be submitted as a comment on this github issue. Group members who cannot submit a comment on this issue should contact the chair (@aphillips) for assistance.
• Votes MUST contain a stack ranked list of candidate options.
• Votes MUST only contain votes for candidate options. Write in votes are not acceptable.
• A vote MUST have at least one item in order to be counted and MAY rank as many items as desired.
• Only ranked votes will be counted. That is, do not submit a vote equating two entries.
• Group members MUST NOT comment on the votes of others in this issue. "Electioneering" or non-voting commentary is not permitted in the issue except the chair may seek clarification of a vote. Use #831 to discuss.

Candidates

The candidates are:

(1) MUST signal errors and MUST provide fallback (2) MUST signal errors or MUST provide fallback (3) MUST signal errors and SHOULD provide fallback (4) SHOULD signal errors and MUST provide fallback (5) Error handling is not a normative requirement

Candidate Descriptions

(1) MUST signal errors and MUST provide fallback

• Implementations MUST provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
• Implementations MUST provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
• An implementation is not conformant unless it provides access to both behaviors. It is compliant to do both in a single formatting attempt.

(2) MUST signal errors or MUST provide fallback

• Implementation MUST either signal an error or errors or provide a fallback representation of a message in a given formatting attempt.
  • A single given message formatting attempt containing one or more errors can produce either error signaling (such as throwing an exception or returning an error code) or return a fallback string.
  • It is compliant to do both in a single formatting attempt. It is compliant to implement signaling and fallback separately (same as (1)). It is not compliant to do neither.

(3) MUST signal errors and SHOULD provide fallback

• Implementations MUST provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
• Implementations SHOULD provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
• Implementations are conformant if they only signal errors.

(4) SHOULD signal errors and MUST provide fallback

• Implementations SHOULD provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
• Implementations MUST provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
• Implementations are conformant if they only provide a fallback representation of a message.

(5) Error handling is not a normative requirement

• Implementations are not required by MF2 to signal errors or to provide access to a fallback representation.
  • The specification provides guidance on error conditions; on what error types exist; and what the fallback representation is.

[aphillips]

(chair hat off)

My vote:

5 > 2 > 3

[gibson042]

1 >>> 4 > 3 >> 2 > 5

[eemeli]

1 > 4 > 2 > 5

[macchiati]

I can't really answer unless the question is a bit more clear.

1. "for signaling errors" - If this were "Must provide a mechanism for detecting errors" I would pick a higher number. That is, it could be satisfied by throwing an exception, or by having an additional return parameter, or by providing a separate function to query whether there was an error.

2. I think the question might depend on the type of errors (This division doesn't align with the typology in the spec, because it is "behavior based" based.)

   1. no matter what the input parameters are — eg syntax errors like{$abc $def}
   2. call-site mismatch errors — eg format(myDateMessage, date="Einstein"), or missing input parameter
   3. others

Definitely for #1 I don't think there has to be a fallback message result

On Tue, Jul 16, 2024 at 1:33 PM Eemeli Aro @.***> wrote:

1 > 4 > 2 > 5

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/message-format-wg/issues/830#issuecomment-2231779518, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMCZGT6CJEFJTXZ2VDLZMV7SFAVCNFSM6AAAAABK7IXHSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRG43TSNJRHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[alerque]

I believe discussion on this topic should be in #782 or #795 which is where the topic came up and it became clear there was not consensus. The issue above seems to have a broken link to some issue number for discussion, perhaps the correct issue number could be edited in there and then these comments hidden so it can be votes only again.

[aphillips]

Thanks @alerque. @macchiati I have copied your comment to #831 before hiding it here.

[macchiati]

3 > 5 Comment in https://github.com/unicode-org/message-format-wg/issues/831#issuecomment-2233941004

On Wed, Jul 17, 2024 at 10:25 AM Addison Phillips @.***> wrote:

Thanks @alerque https://github.com/alerque. @macchiati https://github.com/macchiati I have copied your comment to #831 https://github.com/unicode-org/message-format-wg/issues/831 before hiding it here.

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/message-format-wg/issues/830#issuecomment-2233825913, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMCGDW5RKZXDFNGCONTZM2SJHAVCNFSM6AAAAABK7IXHSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZTHAZDKOJRGM . You are receiving this because you were mentioned.Message ID: @.***>

[sffc]

1 ~>> 3 > 5 > 4 > 2

Note: My signs are the ones we use in ICU4X-TC

• '=' for no preference
• '~>` for very weak preference
• '>' for normal preference
• '~>>' for strong preference, but not veto
• '>>' for very strong/veto preference

[nordzilla]

1 > 4 > 3 > 5 > 2

[echeran]

3 > 5 > 2 > 1 > 4

[catamorphism]

1 > 3 > 4 > 2 > 5

[lucacasonato]

I do not know if I have good standing after two meetings yet, but in case I do, my vote is:

4 > 2 > 1 > 5 > 3

[harmitgoswami]

Ditto with above, but my vote is:

1 > 3 > 4 > 2 > 5

[aphillips]

(chair hat on)

For clarity: good-standing means anyone who is a member of the WG and not otherwise declared as not in good standing. There is no requirement to have attended even one teleconference or made any other contribution.

[mradbourne]

1 > 4 > 3 > 2 > 5

[aphillips]

Candidate (1) has 7 top votes (out of 11 voting) and finishes in first. Using STV methodology, candidate (3) finished second and (4) was third.

[mihnita]

2 > 5 > 3 > 4 > 1