You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/modeling-guide.md
+13-13Lines changed: 13 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
The goal of the specification is to be used by different languages, from dynamically typed to statically typed.
4
4
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.
6
6
7
7
The specification is written in [TypeScript](https://www.typescriptlang.org/), you can find all
8
8
the basic types [here](https://www.typescriptlang.org/docs/handbook/basic-types.html),
@@ -106,8 +106,8 @@ property: UserDefinedValue
106
106
107
107
### Numbers
108
108
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:
111
111
112
112
```ts
113
113
typeshort=number
@@ -120,8 +120,8 @@ type double = number
120
120
121
121
### Strings
122
122
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:
125
125
126
126
```ts
127
127
typeScrollId=string
@@ -233,7 +233,7 @@ class Foo {
233
233
```
234
234
235
235
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:
237
237
238
238
```ts
239
239
/**@variants internal tag='<field-name>' */
@@ -313,8 +313,8 @@ or:
313
313
314
314
#### Container
315
315
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`.
318
318
319
319
The syntax is:
320
320
@@ -333,7 +333,7 @@ class FooContainer {
333
333
}
334
334
335
335
```
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,
337
337
for example `AggregationContainer` and its `aggs` and `meta` properties.
338
338
339
339
An annotation allows distinguishing these properties from container variants:
@@ -365,7 +365,7 @@ class AggregationContainer {
365
365
366
366
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.
367
367
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"}}`.
369
369
370
370
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).
371
371
@@ -386,7 +386,7 @@ Following you can find a list of the supported tags:
386
386
387
387
#### `@since`
388
388
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.
390
390
You can specify an additional `@since` tag for every property that has been added afterwards.
391
391
If the tag is not defined, it's assumed that the property has been added with the API the first time
392
392
@@ -470,7 +470,7 @@ class Request {
470
470
471
471
#### `@codegen_name`
472
472
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
474
474
for request bodies where the document is the entire body.
0 commit comments