Revise SDL-0180 - Broaden Choice Uniqueness

[joeljfischer]

Introduction

This revises SDL-0180 to provide additional motivation and solution detail, downsides, and alternatives to make this proposal implementable.

Motivation

Adds additional detail to the "Motivation" section including use-cases:

Use-Case 1 (Choice Sets)

1. The app supports searching nearby restaurants.
2. The user uses a search / PerformInteraction (Keyboard) feature to input "McDonalds"
3. There is more than one McDonalds restaurant nearby, so the app wishes to create a PerformInteraction with the following choices:
   1. Choice.menuName = McDonalds, Choice.secondaryText = 0.9 mi
   2. Choice.menuName = McDonalds, Choice.secondaryText = 1.7 mi

This will result in a failure when attempting to show the PerformInteraction.

Use-Case 2 (Menus)

The developer wishes to display use the menu system like the following:

Nearby Restaurants (AddCommand)
McDonalds \ 0.3 miles away (AddCommand)
McDonalds \ 1.4 miles away \ Supports ordering from your car! (AddSubmenu)
McDonalds \ 2.4 miles away (AddCommand)

Where the "McDonalds" items are menu items related as sub-menu items of the "Nearby Restaurants" main menu items, either AddCommands or AddSubmenu interchangeably.

Proposed solution

Adds additional detail to the proposed solution section to describe how the de-duplicated strings will look:

1. Choice
2. Choice (1)
3. Choice (2)

Adds AddSubmenu as an affected RPC

Potential downsides

The previous version of this proposal described no downsides. This new version adds four:

1. This will add complexity to the app library choice set managers to work in a backward compatible way.
2. The core team will need to target fixes to remove the uniqueness requirement for choices and menu items.
3. If menu or choice set items are very long, preventing the duplicate by appending (x) may result in the string being too long for the menu space available. This will not be handled in the initial version of this update.
4. If the system is in use in a country that does not use Indo-Arabic numerals (1, 2, 3, 4...), Indo-Arabic numerals will still be used as the de-duplication method. Other numbering systems will not be handled in the initial version of this update.

Impact on existing code

The impact on existing code was updated to:

This will require a documentation update to tell developers how the system will work on various RPC versions, but will not require a minor version change on any platform.

Alternatives considered

The previous version of the proposal described no alternatives. This new version adds three:

1. Other methods of fixing duplicates in a backward compatible way are available instead of (x). For example: - x, or other options.
2. We could automatically reduce the length of the primary text string to account for the appended de-duplication string. For example, instead of turning "McDonalds" into "McDonalds (1)", if that string is now too long, we could turn it into "McD... (1)" or whatever is necessary to fit into the text. This would mitigate downside (3) and will be considered for future updates to this feature.
3. We could allow the developer to specify a series of strings that could be appended as a de-duplicator. This would allow for custom de-duplication and could mitigate downside 4. This will be considered for future updates to this feature.

[joeljfischer]

@jordynmackool @pelsila This revision proposal is ready for review