diff --git a/docs/odata-csdl-json/odata-csdl-json.html b/docs/odata-csdl-json/odata-csdl-json.html index 4c7205bf6..e6e202a4c 100644 --- a/docs/odata-csdl-json/odata-csdl-json.html +++ b/docs/odata-csdl-json/odata-csdl-json.html @@ -635,7 +635,7 @@

3.3

Edm.Date and Edm.DateTimeOffset follow XML-Schema-2 and use the proleptic Gregorian calendar, allowing the year 0000 (equivalent to 1 BCE) and negative years (year -0001 being equivalent to 2 BCE etc.). The supported date range is service-specific and typically depends on the underlying persistency layer, e.g. SQL only supports years 0001 to 9999.

Edm.Decimal with a Scale value of floating, Edm.Double, and Edm.Single allow the special numeric values -INF, INF, and NaN.

Edm.Stream is a primitive type that can be used as a property of an entity type or complex type, the underlying type for a type definition, or the binding parameter or return type of an action or function. Edm.Stream, or a type definition whose underlying type is Edm.Stream, cannot be used in collections or for non-binding parameters to functions or actions.

-

Some of these types allow facets, defined in section “Type Facets”.

+

Some of these types allow facets, defined in section “Type Facets”.

See rule primitiveLiteral in OData-ABNF for the representation of primitive type values in URLs and OData-JSON for the representation in requests and responses.

3.4 Type Facets

The facets in the following subsections modify or constrain the acceptable values of primitive typed model elements, for example a structural property, action or function parameter, action or function return type, or term.

diff --git a/docs/odata-csdl-json/odata-csdl-json.md b/docs/odata-csdl-json/odata-csdl-json.md index bbd9c5b2c..94e059bdc 100644 --- a/docs/odata-csdl-json/odata-csdl-json.md +++ b/docs/odata-csdl-json/odata-csdl-json.md @@ -610,7 +610,7 @@ parameter or return type of an [action](#Action) or underlying type is `Edm.Stream`, cannot be used in collections or for non-binding parameters to functions or actions. -Some of these types allow [facets](#TypeFacets), defined in section +Some of these types allow facets, defined in section "[Type Facets](#TypeFacets)". See rule `primitiveLiteral` in [OData-ABNF](#ODataABNF) for the diff --git a/docs/odata-csdl-xml/odata-csdl-xml.html b/docs/odata-csdl-xml/odata-csdl-xml.html index 5a99b05d3..4f19532fa 100644 --- a/docs/odata-csdl-xml/odata-csdl-xml.html +++ b/docs/odata-csdl-xml/odata-csdl-xml.html @@ -628,7 +628,7 @@

3.3

Edm.Date and Edm.DateTimeOffset follow XML-Schema-2 and use the proleptic Gregorian calendar, allowing the year 0000 (equivalent to 1 BCE) and negative years (year -0001 being equivalent to 2 BCE etc.). The supported date range is service-specific and typically depends on the underlying persistency layer, e.g. SQL only supports years 0001 to 9999.

Edm.Decimal with a Scale value of floating, Edm.Double, and Edm.Single allow the special numeric values -INF, INF, and NaN.

Edm.Stream is a primitive type that can be used as a property of an entity type or complex type, the underlying type for a type definition, or the binding parameter or return type of an action or function. Edm.Stream, or a type definition whose underlying type is Edm.Stream, cannot be used in collections or for non-binding parameters to functions or actions.

-

Some of these types allow facets, defined in section “Type Facets”.

+

Some of these types allow facets, defined in section “Type Facets”.

See rule primitiveLiteral in OData-ABNF for the representation of primitive type values in URLs and OData-JSON for the representation in requests and responses.

3.4 Type Facets

The facets in the following subsections modify or constrain the acceptable values of primitive typed model elements, for example a structural property, action or function parameter, action or function return type, or term.

diff --git a/docs/odata-csdl-xml/odata-csdl-xml.md b/docs/odata-csdl-xml/odata-csdl-xml.md index 214f42b4f..8e5e9d69f 100644 --- a/docs/odata-csdl-xml/odata-csdl-xml.md +++ b/docs/odata-csdl-xml/odata-csdl-xml.md @@ -550,7 +550,7 @@ parameter or return type of an [action](#Action) or underlying type is `Edm.Stream`, cannot be used in collections or for non-binding parameters to functions or actions. -Some of these types allow [facets](#TypeFacets), defined in section +Some of these types allow facets, defined in section "[Type Facets](#TypeFacets)". See rule `primitiveLiteral` in [OData-ABNF](#ODataABNF) for the diff --git a/docs/odata-json-format/odata-json-format.html b/docs/odata-json-format/odata-json-format.html index 05f0c8ad4..abc3f29ca 100644 --- a/docs/odata-json-format/odata-json-format.html +++ b/docs/odata-json-format/odata-json-format.html @@ -2017,7 +2017,7 @@

OData-VocCore. The annotation MAY include a retryLink property that can be used by the client to attempt to re-fetch the resource.

21.3.3 Collection Errors

Collections within a success payload can contain primitive values that are in error, or structured values that are in error, if the client has specified the continue-on-error preference. Such elements are annotated as described above. Primitive elements within a collection are annotated using the collectionAnnotations control information.

-

Services can return partial collections within a success payload, for example, if they encounter an error while retrieving the collection and the client has specified the continue-on-error preference. In this case, the service MUST include a nextLink. The nextLink can be used to attempt retrieving the remaining members of the collection and could return an error indicating that the remaining members are not available.

+

Services can return partial collections within a success payload, for example, if they encounter an error while retrieving the collection and the client has specified the continue-on-error preference. In this case, the service MUST include a nextLink. The nextLink can be used to attempt retrieving the remaining members of the collection and could return an error indicating that the remaining members are not available.

22 Extensibility

Implementations can add instance annotations of the form @namespace.termname or property@namespace.termname to any JSON object, where property MAY or MAY NOT match the name of a name/value pair within the JSON object. However, the namespace MUST NOT start with odata and SHOULD NOT be required to be understood by the receiving party in order to correctly interpret the rest of the payload as the receiving party MUST ignore unknown annotations not defined in this version of the OData JSON Specification.

diff --git a/docs/odata-json-format/odata-json-format.md b/docs/odata-json-format/odata-json-format.md index 40e4044df..2dc9d4d7e 100644 --- a/docs/odata-json-format/odata-json-format.md +++ b/docs/odata-json-format/odata-json-format.md @@ -3760,7 +3760,7 @@ the client has specified the `continue-on-error` preference. In this case, the service MUST include a [`nextLink`](#ControlInformationnextLinkodatanextLink). -The [`nextLink`](#ControlInformationnextLinkodatanextLink) can be used to attempt retrieving the remaining members of the collection and could return an error indicating that the remaining +The `nextLink` can be used to attempt retrieving the remaining members of the collection and could return an error indicating that the remaining members are not available. ------- diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html index c4a82eec6..13bcdd602 100644 --- a/docs/odata-protocol/odata-protocol.html +++ b/docs/odata-protocol/odata-protocol.html @@ -1269,7 +1269,7 @@

11.2.2 Requesting Individual Entities

To retrieve an individual entity, the client makes a GET request to a URL that identifies the entity, e.g. its read URL.

The read URL can be obtained from a response payload containing that instance, for example as a readLink or editLink in an OData-JSON payload. In addition, services MAY support conventions for constructing a read URL using the entity’s key value(s), as described in OData-URL.

-

The set of structural or navigation properties to return may be specified through $select or $expandsystem query options.

+

The set of structural or navigation properties to return may be specified through $select or $expand system query options.

Clients MUST be prepared to receive additional properties in an entity or complex type instance that are not advertised in metadata, even for types not marked as open.

Properties that are not available, for example due to permissions, are not returned. In this case, the Core.Permissions annotation, defined in OData-VocCore MUST be returned for the property with a value of None.

If no entity exists with the specified request URL, the service responds with 404 Not Found.

@@ -2605,22 +2605,22 @@

12.1.1 OData 4.0 Minimal Conformance Level

In order to conform to the OData 4.0 Minimal conformance level, a service:

    -
  1. MUST publish a service document at the service root (section 11.1.1)
    2. +
  2. MUST publish a service document at the service root (section 11.1.1)
  3. MUST return data according to the OData-JSON format
    4. -
  4. MUST use server-driven paging when returning partial results (section 11.2.6.7) and not use any other mechanism
    5. -
  5. MUST return the appropriate OData-Version header (section 8.1.5)
    6. +
  6. MUST use server-driven paging when returning partial results (section 11.2.6.7) and not use any other mechanism
    7. +
  7. MUST return the appropriate OData-Version header (section 8.1.5)
  8. MUST conform to the semantics the following headers, or fail the request
      -
    1. Accept (section 8.2.1)
      2. -
    2. OData-MaxVersion (section 8.2.7)
      3. +
    3. Accept (section 8.2.1)
      4. +
    4. OData-MaxVersion (section 8.2.7)
    9. -
  9. MUST follow OData guidelines for extensibility (section 6 and all subsections)
    10. -
  10. MUST successfully parse the request according to OData-ABNF for any supported system query options and either follow the specification or return 501 Not Implemented for any unsupported functionality (section 9.3.1)
    11. +
  11. MUST follow OData guidelines for extensibility (section 6 and all subsections)
    12. +
  12. MUST successfully parse the request according to OData-ABNF for any supported system query options and either follow the specification or return 501 Not Implemented for any unsupported functionality (section 9.3.1)
  13. MUST expose only data types defined in OData-CSDLXML
  14. MUST NOT require clients to understand any metadata or instance annotations (section 6.4), custom headers (section 6.5), or custom content (section 6.2) in the payload in order to correctly consume the service
    15. -
  15. MUST NOT violate any OData update semantics (section 11.4 and all subsections)
    16. +
  16. MUST NOT violate any OData update semantics (section 11.4 and all subsections)
  17. MUST NOT violate any other OData-defined semantics
    18. -
  18. SHOULD support $expand (section 11.2.5.2)
    19. +
  19. SHOULD support $expand (section 11.2.5.2)
  20. SHOULD publish metadata at $metadata according to OData-CSDLXML and MAY publish metadata according to OData-CSDLJSON (section 11.1.2)
  21. MUST support prefixed variants of supported headers and preference values
  22. MUST support enumeration and duration literals in URLs with the type prefix
    23. @@ -2703,8 +2703,8 @@

    section 11.2.6.6)
  23. MUST support batch requests according to the multipart format (section 11.7 and all subsections) and MAY support batch requests according to the JSON Batch format defined in OData-JSON
  24. MUST support the resource path conventions defined in OData-URL
    25. -
  25. SHOULD support asynchronous requests (section 11.6)
    26. -
  26. SHOULD support Delta change tracking (section 11.3)
    27. +
  27. SHOULD support asynchronous requests (section 11.6)
    28. +
  28. SHOULD support Delta change tracking (section 11.3)
  29. SHOULD support cross-join queries defined in OData-URL
  30. MAY support the $compute system query option (section 11.2.5.3)

diff --git a/docs/odata-protocol/odata-protocol.md b/docs/odata-protocol/odata-protocol.md index 1de29841d..f33d81c44 100644 --- a/docs/odata-protocol/odata-protocol.md +++ b/docs/odata-protocol/odata-protocol.md @@ -2696,7 +2696,7 @@ key value(s), as described in [OData-URL](#ODataURL). The set of structural or navigation properties to return may be specified through [`$select`](#SystemQueryOptionselect) or -[`$expand`](#SystemQueryOptionexpand)system query options. +[`$expand`](#SystemQueryOptionexpand) system query options. Clients MUST be prepared to receive additional properties in an entity or complex type instance that are not advertised in metadata, even for @@ -6343,33 +6343,33 @@ their intended scenario. In order to conform to the OData 4.0 Minimal conformance level, a service: -1. MUST publish a [service document](#ServiceDocumentRequest) at the +1. MUST publish a service document at the service root ([section 11.1.1](#ServiceDocumentRequest)) 2. MUST return data according to the [OData-JSON](#ODataJSON) format -3. MUST use [server-driven paging](#ServerDrivenPaging) when returning +3. MUST use server-driven paging when returning partial results ([section 11.2.6.7](#ServerDrivenPaging)) and not use any other mechanism -4. MUST return the appropriate [`OData-Version`](#HeaderODataVersion) +4. MUST return the appropriate `OData-Version` header ([section 8.1.5](#HeaderODataVersion)) 5. MUST conform to the semantics the following headers, or fail the request - 1. [`Accept`](#HeaderAccept) ([section 8.2.1](#HeaderAccept)) - 2. [`OData-MaxVersion`](#HeaderODataMaxVersion) ([section 8.2.7](#HeaderODataMaxVersion)) -6. MUST follow OData guidelines for [extensibility](#Extensibility) + 1. `Accept` ([section 8.2.1](#HeaderAccept)) + 2. `OData-MaxVersion` ([section 8.2.7](#HeaderODataMaxVersion)) +6. MUST follow OData guidelines for extensibility ([section 6](#Extensibility) and all subsections) 7. MUST successfully parse the request according to [OData-ABNF](#ODataABNF) for any supported system query options and either follow the specification or return -[`501 Not Implemented`](#ResponseCode501NotImplemented) for any +`501 Not Implemented` for any unsupported functionality ([section 9.3.1](#ResponseCode501NotImplemented)) 8. MUST expose only data types defined in [OData-CSDLXML](#ODataCSDL) 9. MUST NOT require clients to understand any metadata or instance annotations ([section 6.4](#VocabularyExtensibility)), custom headers ([section 6.5](#HeaderFieldExtensibility)), or custom content ([section 6.2](#PayloadExtensibility)) in the payload in order to correctly consume the service -10. MUST NOT violate any OData [update semantics](#DataModification) +10. MUST NOT violate any OData update semantics ([section 11.4](#DataModification) and all subsections) 11. MUST NOT violate any other OData-defined semantics -12. SHOULD support [`$expand`](#SystemQueryOptionexpand) ([section 11.2.5.2](#SystemQueryOptionexpand)) +12. SHOULD support `$expand` ([section 11.2.5.2](#SystemQueryOptionexpand)) 13. SHOULD publish metadata at `$metadata` according to [OData-CSDLXML](#ODataCSDL) and MAY publish metadata according to [OData-CSDLJSON](#ODataCSDL) ([section 11.1.2](#MetadataDocumentRequest)) @@ -6499,9 +6499,9 @@ properties according to the JSON Batch format defined in [OData-JSON](#ODataJSON) 12. MUST support the resource path conventions defined in [OData-URL](#ODataURL) -13. SHOULD support [asynchronous requests](#AsynchronousRequests) +13. SHOULD support asynchronous requests ([section 11.6](#AsynchronousRequests)) -14. SHOULD support [Delta change tracking](#RequestingChanges) ([section 11.3](#RequestingChanges)) +14. SHOULD support Delta change tracking ([section 11.3](#RequestingChanges)) 15. SHOULD support cross-join queries defined in [OData-URL](#ODataURL) 16. MAY support the `$compute` system query option ([section 11.2.5.3](#SystemQueryOptioncompute)) diff --git a/docs/odata-url-conventions/odata-url-conventions.html b/docs/odata-url-conventions/odata-url-conventions.html index eb63790c1..cd6f79f42 100644 --- a/docs/odata-url-conventions/odata-url-conventions.html +++ b/docs/odata-url-conventions/odata-url-conventions.html @@ -718,7 +718,7 @@

4.9 Addressing a Member within an Entity Collection

Collections of entities are modeled as entity sets, collection-valued navigation properties, or operation results.

For entity sets, results of operations associated with an entity set through an EntitySet or EntitySetPath declaration, or collection-valued navigation properties with a NavigationPropertyBinding or ContainsTarget=true specification, members of the collection can be addressed by convention by appending the parenthesized key to the URL specifying the collection of entities, or by using the key-as-segment convention if supported by the service.

-

For collection-valued navigation properties with navigation property bindings that end in a type-cast segment, a type-cast segment MUST be appended to the collection URL before appending the key segment.

+

For collection-valued navigation properties with navigation property bindings that end in a type-cast segment, a type-cast segment MUST be appended to the collection URL before appending the key segment.

Note: entity sets or collection-valued navigation properties annotated with the term Capabilities.IndexableByKey defined in OData-VocCap and a value of false do not support addressing their members by key.

4.10 Addressing a Member of an Ordered Collection

Collections can be annotated as ordered using the Core.Ordered term (see OData-VocCore). Individual items within an ordered collection of primitive or complex types can be addressed by appending a segment containing the zero-based ordinal to the URL of the collection. A negative ordinal number indexes from the end of the collection, with -1 representing the last item in the collection. Services MUST NOT specify a negative index when returning the address of a member of an ordered collection.

@@ -777,7 +777,7 @@

4.13 Addressing Each Member of a Collection

To apply a PATCH or DELETE request to each member of a collection, clients append the path segment /$each to a resource path identifying a collection.

-

To apply a bound action or function to each member of a collection, clients append the path segment /$each followed by a path segment identifying the bound action or function. The response is a collection of instances of the result type of the bound operation. If the bound operation returns a collection, the response is a collection of collections. System query options applied to the response can use $it to reference an item in the outermost collection, followed by /any, /all, or /$count.

+

To apply a bound action or function to each member of a collection, clients append the path segment /$each followed by a path segment identifying the bound action or function. The response is a collection of instances of the result type of the bound operation. If the bound operation returns a collection, the response is a collection of collections. System query options applied to the response can use $it to reference an item in the outermost collection, followed by /any, /all, or /$count.

The resource path of the collection preceding /$each MAY contain type-cast segments or filter path segments to subset the collection.

4.14 Addressing the Media Stream of a Media Entity

To address the media stream represented by a media entity, clients append /$value to the resource path of the media entity URL. Services may redirect from this canonical URL to the source URL of the media stream.

diff --git a/docs/odata-url-conventions/odata-url-conventions.md b/docs/odata-url-conventions/odata-url-conventions.md index 3d3107fef..30f9ed101 100644 --- a/docs/odata-url-conventions/odata-url-conventions.md +++ b/docs/odata-url-conventions/odata-url-conventions.md @@ -1106,7 +1106,7 @@ supported by the service. For collection-valued navigation properties with navigation property bindings that end in a [type-cast segment](#AddressingDerivedTypes), -a [type-cast segment](#AddressingDerivedTypes) MUST be +a type-cast segment MUST be appended to the collection URL before appending the key segment. Note: entity sets or collection-valued navigation properties annotated @@ -1285,7 +1285,7 @@ a collection. To apply a [bound action](#AddressingActions) or function to each member of a collection, clients append the path segment `/$each` followed by a -path segment identifying the [bound action](#AddressingActions) or +path segment identifying the bound action or function. The response is a collection of instances of the result type of the bound operation. If the bound operation returns a collection, the response is a collection of collections. System query options applied to diff --git a/lib/README.md b/lib/README.md index 40483f2b7..ebca07a42 100644 --- a/lib/README.md +++ b/lib/README.md @@ -96,6 +96,10 @@ The following scripts can be executed manually or as part of a GitHub Action: - a copy of the common [`styles`](../styles) folder - a copy of the document-specific `*/images` folder, if this exists. - [`npm run pdf`](build-pdf.mjs) runs the PDF conversion and writes the PDF document into the [`docs/*`](../docs) folder. +- [`npm run select []`](selector.mjs) selects parts of the generated HTML documents by executing a CSS selector and optionally an XPath expression relative to each match. For example, syntax errors in JSON code snippets can be detected with + ```sh + npm run select ".json .er" "self::*[.!='…']/text()" + ``` - [`npm test`](../test) runs a test suite. ## A note on diagrams diff --git a/lib/selector.mjs b/lib/selector.mjs new file mode 100644 index 000000000..30233f131 --- /dev/null +++ b/lib/selector.mjs @@ -0,0 +1,53 @@ +import puppeteer from "puppeteer"; +import iterator from "./iterator.js"; + +var docs = []; +iterator(function (srcname, name, variant) { + docs.push(name); +}); +var browser = await puppeteer.launch({ headless: "new" }); +var exit_code = 0; +for (var name of docs) { + var heading = undefined; + console.group(name); + var page = await browser.newPage(); + await page.goto(`${import.meta.dirname}/../docs/${name}/${name}.html`, { + waitUntil: "networkidle2", + }); + for (var r of await Promise.all( + ( + await Promise.all( + (await page.$$(process.argv[2])).map(async function (elem) { + var elems = process.argv[3] + ? await elem.$$("xpath/" + process.argv[3]) + : [elem]; + if (elems.length > 0) exit_code = 1; + return elems.map((elem) => + elem.evaluate(function (e) { + return { + heading: document.evaluate( + "preceding::*[self::h1|self::h2|self::h3|self::h4|self::h5|self::h6][1]", + e, + () => {}, + XPathResult.FIRST_ORDERED_NODE_TYPE, + ).singleNodeValue.textContent, + match: + e.nodeType === Node.ELEMENT_NODE ? e.outerHTML : e.nodeValue, + }; + }), + ); + }), + ) + ).flat(), + )) { + if (r.heading !== heading) { + if (heading) console.groupEnd(); + console.group(r.heading); + heading = r.heading; + } + console.log(r.match); + } + if (heading) console.groupEnd(); + console.groupEnd(); +} +process.exit(exit_code); diff --git a/odata-csdl/1 Introduction.md b/odata-csdl/1 Introduction.md index 406b1d714..3c3eb9088 100644 --- a/odata-csdl/1 Introduction.md +++ b/odata-csdl/1 Introduction.md @@ -486,7 +486,7 @@ parameter or return type of an [action](#Action) or underlying type is `Edm.Stream`, cannot be used in collections or for non-binding parameters to functions or actions. -Some of these types allow [facets](#TypeFacets), defined in section +Some of these types allow facets, defined in section "[Type Facets](#TypeFacets)". See rule `primitiveLiteral` in [OData-ABNF](#ODataABNF) for the diff --git a/odata-json-format/20 Instance Annotations.md b/odata-json-format/20 Instance Annotations.md index 57762cbb8..400e16f98 100644 --- a/odata-json-format/20 Instance Annotations.md +++ b/odata-json-format/20 Instance Annotations.md @@ -243,7 +243,7 @@ the client has specified the `continue-on-error` preference. In this case, the service MUST include a [`nextLink`](#ControlInformationnextLinkodatanextLink). -The [`nextLink`](#ControlInformationnextLinkodatanextLink) can be used to attempt retrieving the remaining members of the collection and could return an error indicating that the remaining +The `nextLink` can be used to attempt retrieving the remaining members of the collection and could return an error indicating that the remaining members are not available. ------- diff --git a/odata-protocol/11 Data Service Requests.md b/odata-protocol/11 Data Service Requests.md index 308e43f86..4c4ef6314 100644 --- a/odata-protocol/11 Data Service Requests.md +++ b/odata-protocol/11 Data Service Requests.md @@ -157,7 +157,7 @@ key value(s), as described in [OData-URL](#ODataURL). The set of structural or navigation properties to return may be specified through [`$select`](#SystemQueryOptionselect) or -[`$expand`](#SystemQueryOptionexpand)system query options. +[`$expand`](#SystemQueryOptionexpand) system query options. Clients MUST be prepared to receive additional properties in an entity or complex type instance that are not advertised in metadata, even for diff --git a/odata-protocol/12 Conformance.md b/odata-protocol/12 Conformance.md index f8de4d506..5a8c06149 100644 --- a/odata-protocol/12 Conformance.md +++ b/odata-protocol/12 Conformance.md @@ -44,33 +44,33 @@ their intended scenario. In order to conform to the OData 4.0 Minimal conformance level, a service: -1. MUST publish a [service document](#ServiceDocumentRequest) at the +1. MUST publish a service document at the service root ([section ##ServiceDocumentRequest]) 2. MUST return data according to the [OData-JSON](#ODataJSON) format -3. MUST use [server-driven paging](#ServerDrivenPaging) when returning +3. MUST use server-driven paging when returning partial results ([section ##ServerDrivenPaging]) and not use any other mechanism -4. MUST return the appropriate [`OData-Version`](#HeaderODataVersion) +4. MUST return the appropriate `OData-Version` header ([section ##HeaderODataVersion]) 5. MUST conform to the semantics the following headers, or fail the request - 1. [`Accept`](#HeaderAccept) ([section ##HeaderAccept]) - 2. [`OData-MaxVersion`](#HeaderODataMaxVersion) ([section ##HeaderODataMaxVersion]) -6. MUST follow OData guidelines for [extensibility](#Extensibility) + 1. `Accept` ([section ##HeaderAccept]) + 2. `OData-MaxVersion` ([section ##HeaderODataMaxVersion]) +6. MUST follow OData guidelines for extensibility ([section ##Extensibility] and all subsections) 7. MUST successfully parse the request according to [OData-ABNF](#ODataABNF) for any supported system query options and either follow the specification or return -[`501 Not Implemented`](#ResponseCode501NotImplemented) for any +`501 Not Implemented` for any unsupported functionality ([section ##ResponseCode501NotImplemented]) 8. MUST expose only data types defined in [OData-CSDLXML](#ODataCSDL) 9. MUST NOT require clients to understand any metadata or instance annotations ([section ##VocabularyExtensibility]), custom headers ([section ##HeaderFieldExtensibility]), or custom content ([section ##PayloadExtensibility]) in the payload in order to correctly consume the service -10. MUST NOT violate any OData [update semantics](#DataModification) +10. MUST NOT violate any OData update semantics ([section ##DataModification] and all subsections) 11. MUST NOT violate any other OData-defined semantics -12. SHOULD support [`$expand`](#SystemQueryOptionexpand) ([section ##SystemQueryOptionexpand]) +12. SHOULD support `$expand` ([section ##SystemQueryOptionexpand]) 13. SHOULD publish metadata at `$metadata` according to [OData-CSDLXML](#ODataCSDL) and MAY publish metadata according to [OData-CSDLJSON](#ODataCSDL) ([section ##MetadataDocumentRequest]) @@ -200,9 +200,9 @@ properties according to the JSON Batch format defined in [OData-JSON](#ODataJSON) 12. MUST support the resource path conventions defined in [OData-URL](#ODataURL) -13. SHOULD support [asynchronous requests](#AsynchronousRequests) +13. SHOULD support asynchronous requests ([section ##AsynchronousRequests]) -14. SHOULD support [Delta change tracking](#RequestingChanges) ([section ##RequestingChanges]) +14. SHOULD support Delta change tracking ([section ##RequestingChanges]) 15. SHOULD support cross-join queries defined in [OData-URL](#ODataURL) 16. MAY support the `$compute` system query option ([section ##SystemQueryOptioncompute]) diff --git a/odata-url-conventions/4 Resource Path.md b/odata-url-conventions/4 Resource Path.md index a15c2b82f..916bedc6e 100644 --- a/odata-url-conventions/4 Resource Path.md +++ b/odata-url-conventions/4 Resource Path.md @@ -655,7 +655,7 @@ supported by the service. For collection-valued navigation properties with navigation property bindings that end in a [type-cast segment](#AddressingDerivedTypes), -a [type-cast segment](#AddressingDerivedTypes) MUST be +a type-cast segment MUST be appended to the collection URL before appending the key segment. Note: entity sets or collection-valued navigation properties annotated @@ -834,7 +834,7 @@ a collection. To apply a [bound action](#AddressingActions) or function to each member of a collection, clients append the path segment `/$each` followed by a -path segment identifying the [bound action](#AddressingActions) or +path segment identifying the bound action or function. The response is a collection of instances of the result type of the bound operation. If the bound operation returns a collection, the response is a collection of collections. System query options applied to diff --git a/package.json b/package.json index 3b3813213..2f71ce2cf 100644 --- a/package.json +++ b/package.json @@ -7,6 +7,7 @@ "build": "node lib/build.js", "pdf": "node lib/build-pdf.js", "start": "node lib/server", + "select": "node lib/selector.mjs", "test": "c8 -r html -r text mocha", "clean-xxx": "node lib/clean.mjs odata-xxx/temp odata-xxx-v4.0" },