Skip to content

Commit 17a3f63

Browse files
[7.16] Fixes minor typos in modeling guide
Co-authored-by: Lisa Cawley <[email protected]>
1 parent 487d7d9 commit 17a3f63

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

docs/modeling-guide.md

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
The goal of the specification is to be used by different languages, from dynamically typed to statically typed.
44
To achieve this goal the specification contains a series of custom types that do not have a meaning
5-
for the target language, but they should be translated to the most approriate construct.
5+
for the target language, but they should be translated to the most appropriate construct.
66

77
The specification is written in [TypeScript](https://www.typescriptlang.org/), you can find all
88
the basic types [here](https://www.typescriptlang.org/docs/handbook/basic-types.html),
@@ -106,8 +106,8 @@ property: UserDefinedValue
106106

107107
### Numbers
108108

109-
The numeric type in TypeScript is `number`, but given that this specification target mutliple languages,
110-
it offers a bunch of alias that represents the type that should be used if the language supports it:
109+
The numeric type in TypeScript is `number`, but given that this specification targets mutliple languages,
110+
it offers a bunch of aliases that represent the type that should be used if the language supports it:
111111

112112
```ts
113113
type short = number
@@ -120,8 +120,8 @@ type double = number
120120
121121
### Strings
122122
123-
The string type in TypeScript is `string`. It's ok to use it in the spec, but to offer a more developer
124-
friendly specification, we do offer a set of aliases based on which string we do expect, for example:
123+
The string type in TypeScript is `string`. It's okay to use it in the spec, but to offer a more developer
124+
friendly specification, we do offer a set of aliases based on which string we expect, for example:
125125
126126
```ts
127127
type ScrollId = string
@@ -233,7 +233,7 @@ class Foo {
233233
```
234234

235235
If the variant type is internal you should configure the parent type with
236-
the `@variants` js doc tag. teh syntax is:
236+
the `@variants` js doc tag. The syntax is:
237237

238238
```ts
239239
/** @variants internal tag='<field-name>' */
@@ -313,8 +313,8 @@ or:
313313

314314
#### Container
315315

316-
The container variant is used for all the types that contains all the
317-
variants inside the defintion. An example is `QueryContainer`.
316+
The container variant is used for all the types that contain all the
317+
variants inside the definition. An example is `QueryContainer`.
318318

319319
The syntax is:
320320

@@ -333,7 +333,7 @@ class FooContainer {
333333
}
334334

335335
```
336-
Some containers have properties associated to the container that are not part of the list of variants,
336+
Some containers have properties associated with the container that are not part of the list of variants,
337337
for example `AggregationContainer` and its `aggs` and `meta` properties.
338338

339339
An annotation allows distinguishing these properties from container variants:
@@ -365,7 +365,7 @@ class AggregationContainer {
365365

366366
In many places Elasticsearch accepts a property value to be either a complete data structure or a single value, that value being a shortcut for a property in the data structure.
367367

368-
A typical example can be found in queries such as term query: `{"term": {"some_field": {"value": "some_text"}}}` can also be written as `{"term": {"some_field": "some_text"}}`.
368+
A typical example can be found in queries such as term query. `{"term": {"some_field": {"value": "some_text"}}}` can also be written as `{"term": {"some_field": "some_text"}}`.
369369

370370
This could be modelled as a union of `SomeClass | string`, but this notation doesn't capture the relation between the string variant and the corresponding field (`value` in the above example).
371371

@@ -386,7 +386,7 @@ Following you can find a list of the supported tags:
386386

387387
#### `@since`
388388

389-
Every API already has a `@since` tag, which describes when an API has been added.
389+
Every API already has a `@since` tag, which describes when an API was added.
390390
You can specify an additional `@since` tag for every property that has been added afterwards.
391391
If the tag is not defined, it's assumed that the property has been added with the API the first time
392392

@@ -470,7 +470,7 @@ class Request {
470470

471471
#### `@codegen_name`
472472

473-
A custom name that can be used to display the property. Useful in Enums an
473+
A custom name that can be used to display the property. Useful in Enums and
474474
for request bodies where the document is the entire body.
475475

476476
```ts
@@ -539,7 +539,7 @@ export interface Request extends RequestBase {
539539

540540
#### `@deprecated`
541541

542-
Use if an endpoint or property is deprecated, you should add the version as well.
542+
Use if an endpoint or property is deprecated; you should add the version as well.
543543

544544
```ts
545545
class Foo {

0 commit comments

Comments
 (0)