Summary

Currently, the specification requires a driver to choose from one of the proposed ways to model summary vs verbose bulk write results in the API: "Drivers MUST implement this in one of the following ways". Let's use "SHOULD" instead of "MUST".

Let's improve the second proposed approach: "Implement the insertResults, updateResults, and deleteResults fields as optional types and document that they will be unset when verboseResults is false." Making all these fields optional independently does not seem to make sense, because they are guaranteed to either all be present, or all be absent. Instead, the specification may propose to pack them in a single value, which always have these fields, while itself being optonal.

Motivation

Who is the affected end user?

The people who implement and maintain drivers, as well as end-users who may have to deal with a sub-optimal API.

How does this affect the end user?

They can be annoyed by the sub-optimal API.

How likely is it that this problem or use case will occur?

Not applicable.

If the problem does occur, what are the consequences and how severe are they?

It affects usability.

Is this issue urgent?

It better be addressed before more drivers implement the new bulk write API.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.

Acceptance Criteria

The specification does not infringe on the driver devs ability to model API in a way that makes best sense for the driver.