Default naming scheme, behavior for all concepts

[vishwacsena]

Default names

This specification outlines the default naming convention for all concepts in composer.

All triggers, actions start with a default name but is user editable.

Bot

There is no default name for a Bot. User must explictly provide a name.

Dialog

There is no default name for a dialog. User must explicitly provide a name.

Trigger

• Only Intent trigger has a name property.
• Default name for a trigger will be its type name - e.g. IntentTrigger
• In case there already exists a trigger with the name, add a number increment as suffix - e.g. IntentTrigger, IntentTrigger1, IntentTrigger2, ...
• All trigger names within a specific dialog must be unique.
• In case of intent trigger, the intent name will default to the trigger name.
• If user renames the trigger in the trigger's property editor, then the intent name is also updated.
• If user changes the intent name of a trigger in all-up view and/ or if this intent is used as a reference in another intent, then ask the user for the intended behavior -
  • Update all references to the new name
  • Keep reference as is

Input/ prompt actions

• Default name for an input action will be its type name - e.g. NumberInput, TextInput, ChoiceInput, ConfirmInput, DateTimeInput, OAuthInput, AttachmentInput
• In case there already exists an input action with that name, add a number increment as suffix - e.g. NumberInput, NumberInput1, NumberInput2, ...
• All input names tied to a specific dialog must be unique.
• The intent name for an input default to the input name.
• The prompt LG template name defaults to the input name.
• The unrecognized prompt LG template name defaults to <input-name>.unrecognized.prompt
• The invalid prompt LG template name defaults to <input-name>.invalid.prompt
• If user renames the input in the input's property editor, then the intent name is also updated, LG template names are also updated.
• If user changes the intent name of an input in the all-up view or changes the LG template name tied to an input in the all-up view and/ or if the intent or lG template is used as a reference in another intent/ LG template, then ask the user for the intended behavior -
  • Update all references to the new name
  • Keep reference as is

SendActivity

• Default name is sendActivity, add an increment as suffix to de-dupe - e.g. SendActivity, SendActivity1, SendActivity2, ...
• The default LG template name is the name of the SendActivity action
• If user renames the send activity in its property editor, then the LG template name is also updated.
• If user changes the LG template name in all-up view and/ or if this LG template is used as a reference in other intents or templates, then ask the user for the intended behavior -
  • Update all references to the new name
  • Keep reference as is

All other actions

• Name is available, defaults to ActionType, add a number increment suffix to de-dupe
• These names are just for organizational purposes and readaibility and do not have any runtime implications.

Note: This impacts the current naming scheme used for LG templates in send activity action. With this change, we will no longer use our current naming scheme bfd-<ID>

[yochay]

Default name for a trigger will be its type name - e.g. IntentTrigger, UnknownIntentTrigger, EventTrigger, ConversationUpdateTrigger.

• Can we have multiple ConversationUpdateTrigger or UnknownIntentTrigger triggers? If not, we should 1) call that out and make sure we don't show / allow conflict configuration; 2) call out which triggers can be multiple, like Event and Intent.

The intent name for an input default to the input name.
The prompt LG template name defaults to the input name.

• Do we add sofix or prefix for the LG for a given intent? In the future, when searching for a 'term' search results might find multiple object across different location. Do we care?

for SendActivity

• today, all LG is in one Common file, we'll have template name collision with SendActivity1 ...SendActivityN. Should we add a dialog prefix/ sofix or something else?
• it will be good to claim all SendActivity templates have unique name across the entire app. This will also help in the future with search and other language features like multi-lang

FYI - @vishwacsena , @benbrown , @cwhitten , @sangwoohaan

[vishwacsena]

@yochay

Can we have multiple ConversationUpdateTrigger or UnknownIntentTrigger triggers? If not, we should 1) call that out and make sure we don't show / allow conflict configuration; 2) call out which triggers can be multiple, like Event and Intent.

Yes. You can albeit with slightly different constraints. In fact all our triggers support constraints and so you can even have the same intent event with slightly different constraints.

Do we add sofix or prefix for the LG for a given intent? In the future, when searching for a 'term' search results might find multiple object across different location. Do we care?

I'd think search we support (in the future) is able to present content grouped by area - e.g. you could in theory have a dialog name and intent name be the same and so even outstide of LG we need the ability for search results to indicate what type of content was a match.

today, all LG is in one Common file, we'll have template name collision with SendActivity1 ...SendActivityN. Should we add a dialog prefix/ sofix or something else?
it will be good to claim all SendActivity templates have unique name across the entire app. This will also help in the future with search and other language features like multi-lang

Good call about our current LG situation. We need to move to one .lg file per dialog for public preview. I'll file a separate ticket to track that. Also in general, these are just the default names that we go with and are user editable/ configurable. If I need better search results, I'd name them in a way I can identify them and so the user is in control. Like I said above for search though, we should plan and design for search results to include type (dialog, LU, LG, settings etc) of the matched content. Should there be more than one match in the same type, then we should indicate the containing dialog name. Filed this ticket to track the move to one .lg file per dialog.

[cwhitten]

Vishwac to get updated scope

[vishwacsena]

@cwhitten - discussed and updated scope w/ @sangwoohaan.

@sangwoohaan - can you please add link to the design?

@cwhitten - leaving this assigned to you for resourcing.

[sangwoohaan]

Related issue raised during Hackathon #976

[sangwoohaan]

LU/LG name changing UX flow (in the magenta boxes) :https://www.figma.com/file/04DymSq4xElhOBdAyutvvTbq/Composer-SH-06.19?node-id=1741%3A910

[a-b-r-o-w-n]

What if we also prepended the trigger name to templates defined within that trigger?