Fix typo on several documentation files (#5113)
This commit is contained in:
Родитель
fbb0dd2add
Коммит
1d7726a6d1
|
@ -28,7 +28,7 @@ Bot Builder provides the most comprehensive experience for building conversation
|
|||
Please see [here](https://aka.ms/BotBuilderOverview) for an overview of the end-to-end bot development workflow. To get started, you can create a bot with [Azure Bot Service](https://docs.microsoft.com/en-us/azure/bot-service/bot-service-quickstart?view=azure-bot-service-4.0). Click [here](https://account.azure.com/signup) if you need a trial Azure subscription.
|
||||
|
||||
## Documentation
|
||||
Visit azure.com for the primary [Azure Bot Service documentation page](https://docs.microsoft.com/en-us/azure/bot-service/) to learn about building bots using Bot Builder. There is additional documentation on the SDK, oriented towards contributors. The SDK currently supports four programing language:
|
||||
Visit azure.com for the primary [Azure Bot Service documentation page](https://docs.microsoft.com/en-us/azure/bot-service/) to learn about building bots using Bot Builder. There is additional documentation on the SDK, oriented towards contributors. The SDK currently supports four programming language:
|
||||
- [.NET](https://github.com/Microsoft/botbuilder-dotnet/wiki)
|
||||
- [JavaScript](https://github.com/microsoft/botbuilder-js/wiki)
|
||||
- [Python](https://github.com/Microsoft/botbuilder-python/wiki)
|
||||
|
@ -102,4 +102,3 @@ Licensed under the [MIT](LICENSE) License.
|
|||
|
||||
|
||||
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
|
||||
|
||||
|
|
|
@ -1173,7 +1173,7 @@ Actions support dynamic typing. An implementer of an action expresses a list of
|
|||
|
||||
Entities sent within the semantic action have a specific meaning, defined by their name. For example, an action may be named `findRoute` with entities named `source` and `destination`. Sometimes, additional entities are available that do not fit a specific meaning within the action. The root [`entities`](#Entities) array is a suitable location to transmit these entities.
|
||||
|
||||
`A7745`: Senders MAY send entities not listed in the action definition in the [`entities`](#Entities) array in the activity root. Senders SHOULD NOT send these entities in the semnatic action.
|
||||
`A7745`: Senders MAY send entities not listed in the action definition in the [`entities`](#Entities) array in the activity root. Senders SHOULD NOT send these entities in the semantic action.
|
||||
|
||||
The `$instance` field carries metadata about the source of each entity. The keys of this object are identical to the entity names as peers. The values of each key is the corresponding instance metadata of type [`semanticEntityInstance`](#Semantic-entity-instance).
|
||||
|
||||
|
@ -1253,7 +1253,7 @@ The `semanticEntityInstance` type references to source information about where t
|
|||
## 2018-09-27 - dandris@microsoft.com
|
||||
|
||||
* Revised reference descriptions and links
|
||||
* Clarified syntatic rules, revised `A2003`, added `A2007`
|
||||
* Clarified syntactic rules, revised `A2003`, added `A2007`
|
||||
* Removed `A7743` as redundant
|
||||
* Removed ordering requirement for semantic action entities (`A7741`)
|
||||
* Added `$instance` to semantic action entities
|
||||
|
|
|
@ -104,7 +104,7 @@ Cards are identified by a MIME-compatible [[5](#References)] content-type. These
|
|||
|
||||
### Transformations and display
|
||||
|
||||
Displaying a card within a client user interface frequently requires the implementer to make specific decisions about how to order and constrain content to match the visual style of the enclosing design. Further, this specification anticipates that these limitations are largely unavoidable and aims to assist implementers in choosing a path that makes graceful degredation of functionality possible.
|
||||
Displaying a card within a client user interface frequently requires the implementer to make specific decisions about how to order and constrain content to match the visual style of the enclosing design. Further, this specification anticipates that these limitations are largely unavoidable and aims to assist implementers in choosing a path that makes graceful degradation of functionality possible.
|
||||
|
||||
This section provides guidance on which transformations best achieve the goal of preserving the intent of the card.
|
||||
|
||||
|
@ -483,4 +483,4 @@ The `value` field contains the objective component of the fact. The value of the
|
|||
|
||||
## 2018-07-05 - dandris@microsoft.com
|
||||
|
||||
* Initial draft
|
||||
* Initial draft
|
||||
|
|
|
@ -100,11 +100,11 @@ Manifests are valid in the ".man" file format described in this section.
|
|||
|
||||
### .man file format
|
||||
|
||||
`M2100`: Valid .man files MUST be a serialized JSON enitity.
|
||||
`M2100`: Valid .man files MUST be a serialized JSON entity.
|
||||
|
||||
`M2101`: Writers SHOULD use UTF-8 encoding for all .man files. Writers SHOULD NOT include byte-order marks (BOM) in .man files. Readers MAY reject .man files that include BOM or encoding other than UTF-8.
|
||||
|
||||
`M2102`: For legibilty, writers SHOULD pretty-format JSON so it includes newlines and whitespace.
|
||||
`M2102`: For legibility, writers SHOULD pretty-format JSON so it includes newlines and whitespace.
|
||||
|
||||
## Use in APIs
|
||||
|
||||
|
@ -156,13 +156,13 @@ The value of the `endpoint` field is a URL [[5](#References)] within a string.
|
|||
|
||||
The `iconUrl` field contains the URL of the bot's icon. The value of the `iconUrl` is a URI [[5](#References)] within a string.
|
||||
|
||||
Registries typically expect icon URLs with HTTP or HTTPS schemes, and some registries require HTTPS. For this reason, HTTPS is the most interoperable way to deliver icons. However, alternative delivery mechanisms, such as local files or Data URIs (as defined in [RFC 2397](https://tools.ietf.org/html/rfc2397) [[7](#References)]) may be supported by some regsitries.
|
||||
Registries typically expect icon URLs with HTTP or HTTPS schemes, and some registries require HTTPS. For this reason, HTTPS is the most interoperable way to deliver icons. However, alternative delivery mechanisms, such as local files or Data URIs (as defined in [RFC 2397](https://tools.ietf.org/html/rfc2397) [[7](#References)]) may be supported by some registries.
|
||||
|
||||
`M4100`: Registries SHOULD accept `iconUrl` values of HTTPS scheme.
|
||||
|
||||
### Authentication connections
|
||||
|
||||
Some registars accept definitions for authentication providers that bots can use at runtime to collect sign-in and access consent from users. The configuration for this information is stored in the `authenticationConnections` field. The `authenticationConnections` field is an array of type [`authenticationConnection`](#Authentication-connection)
|
||||
Some registrars accept definitions for authentication providers that bots can use at runtime to collect sign-in and access consent from users. The configuration for this information is stored in the `authenticationConnections` field. The `authenticationConnections` field is an array of type [`authenticationConnection`](#Authentication-connection)
|
||||
|
||||
## Action fields
|
||||
|
||||
|
@ -188,7 +188,7 @@ This section refers to *publishing fields*. *Publishing fields* are the set of f
|
|||
|
||||
`M4800`: Writers SHOULD only include publishing fields applicable to the registry where the manifest is intended to be consumed. If the manifest is not intended for consumption within a registry, writers SHOULD NOT include any publishing fields.
|
||||
|
||||
Regsitries accept extended registration data published as extra fields in the manifest root.
|
||||
Registries accept extended registration data published as extra fields in the manifest root.
|
||||
|
||||
`M4801`: Registries MAY define zero or more top-level field names with corresponding type and meaning.
|
||||
|
||||
|
@ -352,13 +352,13 @@ The `name` field contains a name used to identify the authentication connection
|
|||
|
||||
#### Authentication connection service provider ID
|
||||
|
||||
The `serviceProviderId` field identifies the authentication service providing sign-in functionality. The value of the `serviceProviderId` is of type string and the valid values (and their meanings) are definde by the registry accepting the manifest.
|
||||
The `serviceProviderId` field identifies the authentication service providing sign-in functionality. The value of the `serviceProviderId` is of type string and the valid values (and their meanings) are defined by the registry accepting the manifest.
|
||||
|
||||
#### Authentication connection client ID
|
||||
|
||||
The `clientId` field contains the identifier sent to the authentication service when requesting sign-in. The value of the `clientId` field is of type string.
|
||||
|
||||
#### Authnetication connection client secret
|
||||
#### Authentication connection client secret
|
||||
|
||||
The `clientSecret` field contains the client secret sent to the authentication service when requesting sign-in. The value of the `clientSecret` field is of type string.
|
||||
|
||||
|
@ -449,4 +449,4 @@ Bot Framework defines 13 channels. The list of channels may change over time. Ea
|
|||
* `sms`
|
||||
* `webchat`
|
||||
|
||||
Tooling used to interact with the Bot Framework service, such as the [Bot Service Azure CLI](https://github.com/Microsoft/botbuilder-tools/tree/master/AzureCli), expect manifests in this format.
|
||||
Tooling used to interact with the Bot Framework service, such as the [Bot Service Azure CLI](https://github.com/Microsoft/botbuilder-tools/tree/master/AzureCli), expect manifests in this format.
|
||||
|
|
|
@ -112,7 +112,7 @@ Transcripts are valid either in a well-defined ".transcript" file format, define
|
|||
|
||||
The .transcript format is JSON and allows emitters to choose whether to generate a flat array of activities or a complex object containing a flat array. This choice allows for both efficiency and extensibility.
|
||||
|
||||
`T2100`: Valid .transcript files MUST be a serialized JSON entity. That entity MUST be either a flat array of activies or a complex object containing a `transcript` field.
|
||||
`T2100`: Valid .transcript files MUST be a serialized JSON entity. That entity MUST be either a flat array of activities or a complex object containing a `transcript` field.
|
||||
|
||||
`T2101`: Processors MUST support both the array- and the object-based serialization described in `T2100`.
|
||||
|
||||
|
@ -169,4 +169,4 @@ Additionally, some fields become less important. For example, the [`channelId](b
|
|||
|
||||
## 2018-06-15 - dandris@microsoft.com
|
||||
|
||||
* Initial draft
|
||||
* Initial draft
|
||||
|
|
Загрузка…
Ссылка в новой задаче