|
146 | 146 | A user agent need not construct a link unless a client application requests
|
147 | 147 | that link. JSON Hyper-Schema can also be used on the server side to generate
|
148 | 148 | other link serializations or representation formats at runtime, or pre-emptively
|
149 |
| - follow links to faciliate server push usage. |
| 149 | + follow links to facilitate server push usage. |
150 | 150 | </t>
|
151 | 151 |
|
152 | 152 | <section title="Terminology">
|
|
267 | 267 | which is also used to illustrate points in the
|
268 | 268 | <xref target="implementation">"Implementation Requirements"</xref>, and to
|
269 | 269 | show the output generated by <xref target="examples">examples</xref>.
|
270 |
| - It is RECOMMENDED that implementations be capable of producting output |
271 |
| - in this format to faciliated testing. The URI of the JSON Schema |
| 270 | + It is RECOMMENDED that implementations be capable of producing output |
| 271 | + in this format to facilitated testing. The URI of the JSON Schema |
272 | 272 | describing the recommended output format is
|
273 | 273 | <eref target="http://json-schema.org/draft-7-wip/hyper-schema-output#">
|
274 | 274 | http://json-schema.org/draft-7-wip/hyper-schema-output#</eref>
|
|
372 | 372 | Implementations MUST be able to construct the link context's URI, and
|
373 | 373 | (if necessary for full identification), a JSON Pointer in string representation
|
374 | 374 | form as per <xref target="RFC6901">RFC 6901, section 5</xref> in place of
|
375 |
| - a URI fragment. The process for construcing a URI based on a URI template |
| 375 | + a URI fragment. The process for constructing a URI based on a URI template |
376 | 376 | is given in the <xref target="uriTemplating">URI Templating</xref> section.
|
377 | 377 | </t>
|
378 | 378 | <section title="anchor" anchor="anchor">
|
|
501 | 501 | making use of instance data. Additionally, with
|
502 | 502 | <xref target="hrefSchema">"hrefSchema"</xref>, this template can identify
|
503 | 503 | a set of possible target resources to use based on client input.
|
504 |
| - The full process of resolvling the URI template, with or without client |
| 504 | + The full process of resolving the URI template, with or without client |
505 | 505 | input, is covered in the <xref target="uriTemplating">URI Templating</xref>
|
506 | 506 | section.
|
507 | 507 | </t>
|
|
521 | 521 |
|
522 | 522 | <section title="Adjusting URI Template resolution">
|
523 | 523 | <t>
|
524 |
| - The keywords in this section are used when resolving all URI Tempaltes |
| 524 | + The keywords in this section are used when resolving all URI Templates |
525 | 525 | involved in hyper-schema: "base", "anchor", and "href". See the
|
526 | 526 | <xref target="uriTemplating">URI Templating</xref> section for the complete
|
527 | 527 | template resolution algorithm.
|
|
530 | 530 | Note that when resolving a "base" template, the attachment point from
|
531 | 531 | which resolution begins is the attachment point of the "href" or "anchor"
|
532 | 532 | keyword being resolved which requires "base" templates to be resolved,
|
533 |
| - not the attachment point of the "base" kewyord itself. |
| 533 | + not the attachment point of the "base" keyword itself. |
534 | 534 | </t>
|
535 | 535 | <section title="templatePointers" anchor="templatePointers">
|
536 | 536 | <t>
|
|
927 | 927 | </t>
|
928 | 928 | <t>
|
929 | 929 | And implementation MUST support looking up links by either their
|
930 |
| - attachement pointer or context pointer, either by performing the look-up |
| 930 | + attachment pointer or context pointer, either by performing the look-up |
931 | 931 | or by providing the set of all links with both pointers determined
|
932 | 932 | so that user agents can implement the look-up themselves.
|
933 | 933 | </t>
|
@@ -1083,7 +1083,7 @@ for varname in T:
|
1083 | 1083 | </t>
|
1084 | 1084 | <figure>
|
1085 | 1085 | <preamble>
|
1086 |
| - "InputForm" represents whatevers sort of input mechanism is appropriate. |
| 1086 | + "InputForm" represents whatever sort of input mechanism is appropriate. |
1087 | 1087 | This may be a literal web form, or may be a more programmatic construct
|
1088 | 1088 | such as a callback function accepting specific fields and data types,
|
1089 | 1089 | with the given initial values, if any.
|
@@ -1209,11 +1209,11 @@ for varname in templateData:
|
1209 | 1209 | The requirements around discovering links based on their context, or
|
1210 | 1210 | using the context of links to identify collections, present unique
|
1211 | 1211 | challenges when used with streaming parsers. It is not possible to
|
1212 |
| - authoritatively fulfill these requirments without processing the entire |
| 1212 | + authoritatively fulfill these requirements without processing the entire |
1213 | 1213 | schema and instance documents.
|
1214 | 1214 | </t>
|
1215 | 1215 | <t>
|
1216 |
| - Such implementations MAY chooose to return non-authoritative answers |
| 1216 | + Such implementations MAY choose to return non-authoritative answers |
1217 | 1217 | based on data processed to date. When offering this approach,
|
1218 | 1218 | implementations MUST be clear on the nature of the response, and MUST
|
1219 | 1219 | offer an option to block and wait until all data is processed and
|
@@ -1356,8 +1356,8 @@ for varname in templateData:
|
1356 | 1356 | </t>
|
1357 | 1357 | <t>
|
1358 | 1358 | This appendix provides guidance on how to define links for use with each
|
1359 |
| - common HTTP method, and how collection resources impose additional constarints |
1360 |
| - on the use of HTTP POST. Additionaly, guidance is provided on hinting at |
| 1359 | + common HTTP method, and how collection resources impose additional constraints |
| 1360 | + on the use of HTTP POST. Additionally, guidance is provided on hinting at |
1361 | 1361 | HTTP response header values and describing possible HTTP request headers
|
1362 | 1362 | that are relevant to the given resource.
|
1363 | 1363 | </t>
|
|
0 commit comments