diff --git a/docs/odata-csdl-json/odata-csdl-json.html b/docs/odata-csdl-json/odata-csdl-json.html index 5b55de43..f5ea66c0 100644 --- a/docs/odata-csdl-json/odata-csdl-json.html +++ b/docs/odata-csdl-json/odata-csdl-json.html @@ -791,7 +791,7 @@

3.3 Pr

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 a binding or non-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.

-

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

+

Some of these types allow facets, defined in section 3.4.

Representation of primitive type values within a URL is defined by the rule primitiveLiteral in OData-ABNF. Representation within request and response bodies is format specific.

@@ -961,7 +961,7 @@

Path Expressions” for details.

+

as the type of a primitive term, or the type of a property of a complex type (recursively) that is exclusively used as the type of a term. See section 14.4.1 for details.

3.7 Annotations

@@ -2966,7 +2966,7 @@

14.4.1.1 Path S

Example 60: absolute path to an entity set

/My.Schema.MyEntityContainer/MyEntitySet
-

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section “Path Evaluation”.

+

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section 14.4.1.2.

Example 61: relative path to a property

Address/City
diff --git a/docs/odata-csdl-json/odata-csdl-json.md b/docs/odata-csdl-json/odata-csdl-json.md index 2e9229e1..17096bae 100644 --- a/docs/odata-csdl-json/odata-csdl-json.md +++ b/docs/odata-csdl-json/odata-csdl-json.md @@ -638,8 +638,7 @@ parameter or return type of an [action](#Action) or `Edm.Stream`, or a type definition whose underlying type is `Edm.Stream`, cannot be used in collections. -Some of these types allow facets, defined in section -"[Type Facets](#TypeFacets)". +Some of these types allow facets, defined in [section 3.4](#TypeFacets). Representation of primitive type values within a URL is defined by the rule `primitiveLiteral` in [OData-ABNF](#ODataABNF). Representation within request and response bodies is format specific. @@ -915,7 +914,7 @@ be used anywhere a corresponding concrete type can be used, except: as the type of a primitive term, or the type of a property of a complex type (recursively) that is exclusively used as the type of a term. See -section "[Path Expressions](#PathExpressions)" for details. +[section 14.4.1](#PathExpressions) for details. ## 3.7 Annotations @@ -4264,8 +4263,7 @@ Example 60: absolute path to an entity set ::: Paths not starting with a forward slash are interpreted relative to the -annotation target, following the rules specified in section "[Path -Evaluation](#PathEvaluation)". +annotation target, following the rules specified in [section 14.4.1.2](#PathEvaluation). ::: example Example 61: relative path to a property diff --git a/docs/odata-csdl-xml/odata-csdl-xml.html b/docs/odata-csdl-xml/odata-csdl-xml.html index 8738d952..da7033c6 100644 --- a/docs/odata-csdl-xml/odata-csdl-xml.html +++ b/docs/odata-csdl-xml/odata-csdl-xml.html @@ -787,7 +787,7 @@

3.3 Pr

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 a binding or non-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.

-

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

+

Some of these types allow facets, defined in section 3.4.

Representation of primitive type values within a URL is defined by the rule primitiveLiteral in OData-ABNF. Representation within request and response bodies is format specific.

@@ -941,7 +941,7 @@

Path Expressions” for details.

+

as the type of a primitive term, or the type of a property of a complex type (recursively) that is exclusively used as the type of a term. See section 14.4.1 for details.

3.7 Annotations

@@ -2859,7 +2859,7 @@

14.4.1.1 Path S

Example 60: absolute path to an entity set

/My.Schema.MyEntityContainer/MyEntitySet
-

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section “Path Evaluation”.

+

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section 14.4.1.2.

Example 61: relative path to a property

Address/City
diff --git a/docs/odata-csdl-xml/odata-csdl-xml.md b/docs/odata-csdl-xml/odata-csdl-xml.md index c30e25bb..fcca80a1 100644 --- a/docs/odata-csdl-xml/odata-csdl-xml.md +++ b/docs/odata-csdl-xml/odata-csdl-xml.md @@ -581,8 +581,7 @@ parameter or return type of an [action](#Action) or `Edm.Stream`, or a type definition whose underlying type is `Edm.Stream`, cannot be used in collections. -Some of these types allow facets, defined in section -"[Type Facets](#TypeFacets)". +Some of these types allow facets, defined in [section 3.4](#TypeFacets). Representation of primitive type values within a URL is defined by the rule `primitiveLiteral` in [OData-ABNF](#ODataABNF). Representation within request and response bodies is format specific. @@ -847,7 +846,7 @@ be used anywhere a corresponding concrete type can be used, except: as the type of a primitive term, or the type of a property of a complex type (recursively) that is exclusively used as the type of a term. See -section "[Path Expressions](#PathExpressions)" for details. +[section 14.4.1](#PathExpressions) for details. ## 3.7 Annotations @@ -4195,8 +4194,7 @@ Example 60: absolute path to an entity set ::: Paths not starting with a forward slash are interpreted relative to the -annotation target, following the rules specified in section "[Path -Evaluation](#PathEvaluation)". +annotation target, following the rules specified in [section 14.4.1.2](#PathEvaluation). ::: example Example 61: relative path to a property diff --git a/docs/odata-json-format/odata-json-format.html b/docs/odata-json-format/odata-json-format.html index 6186ceea..2b89ccdb 100644 --- a/docs/odata-json-format/odata-json-format.html +++ b/docs/odata-json-format/odata-json-format.html @@ -485,7 +485,7 @@

control information needed (or desired) in the payload depends on the client application and device. The metadata parameter can be applied to the Accept header of an OData request to influence how much control information will be included in the response.

Other Accept header parameters (e.g., streaming) are orthogonal to the metadata parameter and are therefore not mentioned in this section.

-

If a client prefers a very small wire size and is intelligent enough to compute data using metadata expressions, the Accept header should include metadata=minimal. If computation is more critical than wire size or the client is incapable of computing control information, metadata=full directs the service to inline the control information that normally would be computed from metadata expressions in the payload. metadata=none is an option for clients that have out-of-band knowledge or don't require control information.

+

If a client prefers a very small wire size and is intelligent enough to compute data using metadata expressions, the Accept header should include metadata=minimal. If computation is more critical than wire size or the client is incapable of computing control information, metadata=full directs the service to inline the control information that normally would be computed from metadata expressions in the payload. metadata=none is an option for clients that have out-of-band knowledge or don’t require control information.

In addition, the client may use the include-annotations preference in the Prefer header to request additional control information. Services supporting this MUST NOT omit control information required by the chosen metadata parameter, and services MUST NOT exclude the nextLink, deltaLink, and count if they are required by the response type.

If the client includes the OData-MaxVersion header in a request and does not specify the metadata format parameter in either the Accept header or $format query option, the service MUST return at least the minimal control information.

Note that in OData 4.0 the metadata format parameter was prefixed with odata.. Payloads with an OData-Version header equal to 4.0 MUST include the odata. prefix. Payloads with an OData-Version header equal to 4.01 or greater SHOULD NOT include the odata. prefix.

@@ -523,7 +523,7 @@

editLink: the link used to edit/update the entity, if the entity is updatable and the id does not represent a URL that can be used to edit the entity
  • navigationLink: the link used to retrieve the values of a navigation property
  • associationLink: the link used to describe the relationship between this entity and related entities
    • -
  • type: the type of the containing object or targeted property if the type of the object or targeted property cannot be heuristically determined from the data value, see section “Control Information: type (odata.type)”.
    • +
  • type: the type of the containing object or targeted property if the type of the object or targeted property cannot be heuristically determined from the data value, see section 4.6.3.

    • Media entities and stream properties may in addition contain the following control information:

      @@ -566,7 +566,7 @@

      metadata parameter to specify the amount of metadata included in the response.

      Requests and responses MUST include the IEEE754Compatible parameter if Edm.Int64 and Edm.Decimal numbers are represented as strings.

      -

      Requests and responses MAY add the streaming parameter with a value of true or false, see section “Payload Ordering Constraints”.

      +

      Requests and responses MAY add the streaming parameter with a value of true or false, see section 4.5.

    4.2 Message Body

    @@ -669,7 +669,7 @@

    4.6.2 Control Information: metadataEtag (odata.metadataEtag)

     -

    The metadataEtag control information MAY appear in a response in order to specify the entity tag (ETag) that can be used to determine the version of the metadata of the response. If an ETag is returned when requesting the metadata document, then the service SHOULD set the metadataEtag control information to the metadata document's ETag in all responses when using metadata=minimal or metadata=full. If no ETag is returned when requesting the metadata document, then the service SHOULD NOT set the metadataEtag control information in any responses.

    +

    The metadataEtag control information MAY appear in a response in order to specify the entity tag (ETag) that can be used to determine the version of the metadata of the response. If an ETag is returned when requesting the metadata document, then the service SHOULD set the metadataEtag control information to the metadata document’s ETag in all responses when using metadata=minimal or metadata=full. If no ETag is returned when requesting the metadata document, then the service SHOULD NOT set the metadataEtag control information in any responses.

    For details on how ETags are used, see OData-Protocol.

    @@ -755,7 +755,7 @@

    URL of the entity; see OData-Protocol.

    The readLink control information contains the read URL of the entity or collection; see OData-Protocol.

    The editLink and readLink control information is ignored in request payloads and not written in responses if metadata=none is requested.

    -

    The default value of both the edit URL and read URL is the entity's entity-id appended with a cast segment to the type of the entity if its type is derived from the declared type of the entity set. If neither the editLink nor the readLink control information is present in an entity, the client uses this default value for the edit URL.

    +

    The default value of both the edit URL and read URL is the entity’s entity-id appended with a cast segment to the type of the entity if its type is derived from the declared type of the entity set. If neither the editLink nor the readLink control information is present in an entity, the client uses this default value for the edit URL.

    For updatable entities:

     -

    For media entities and stream properties at least one of the control information mediaEditLink and mediaReadLink MUST be included in responses if they don't follow standard URL conventions as defined in OData-URL, section 4.6 and OData-URL, section 4.14, or if metadata=full is requested.

    +

    For media entities and stream properties at least one of the control information mediaEditLink and mediaReadLink MUST be included in responses if they don’t follow standard URL conventions as defined in OData-URL, section 4.6 and OData-URL, section 4.14, or if metadata=full is requested.

    The mediaEditLink control information contains a URL that can be used to update the binary stream associated with the media entity or stream property. It MUST be included for updatable streams if it differs from standard URL conventions relative to the edit link of the entity.

    The mediaReadLink control information contains a URL that can be used to read the binary stream associated with the media entity or stream property. It MUST be included if its value differs from the value of the associated mediaEditLink, if present, or if it doesn’t follow standard URL conventions relative to the read link of the entity and the associated mediaEditLink is not present.

    The mediaContentType control information MAY be included; its value SHOULD match the media type of the binary stream represented by the mediaReadLink URL. This is only a hint; the actual media type will be included in the Content-Type header when the resource is requested. The presence of mediaContentType with value null MAY be used to indicate the absence of a binary stream.

    @@ -1374,7 +1374,7 @@

    14

    15 Delta Payload

     -

    The non-format specific aspects of the delta handling are described in the section “Requesting Changes” in OData-Protocol.

    +

    The non-format specific aspects of the delta handling are described in OData-Protocol, section 11.3.

    15.1 Delta Responses

     @@ -2360,7 +2360,7 @@

    19.6 Bat

    19.7 Asynchronous Batch Requests

     -

    A batch request that specifies the respond-async preference MAY be executed asynchronously. This means that the “outer” batch request is executed asynchronously; this preference does not automatically cascade down to the individual requests within the batch. After successful execution of the batch request the response to the batch request is returned in the body of a response to an interrogation request against the status monitor resource URL, see section “Asynchronous Requests” in OData-Protocol.

    +

    A batch request that specifies the respond-async preference MAY be executed asynchronously. This means that the “outer” batch request is executed asynchronously; this preference does not automatically cascade down to the individual requests within the batch. After successful execution of the batch request the response to the batch request is returned in the body of a response to an interrogation request against the status monitor resource URL, see OData-Protocol, section 11.6.

    A service MAY return interim results to an asynchronously executing batch. It does this by responding with 200 OK to a GET request to the monitor resource and including a nextLink control information in the JSON batch response, thus signaling that the response is only a partial result. A subsequent GET request to the next link MAY result in a 202 Accepted response with a location header pointing to a new status monitor resource.

    Example 60: referencing the example 55 above again, assume that the request is sent with the respond-async preference. This results in a 202 response pointing to a status monitor resource:

    diff --git a/docs/odata-json-format/odata-json-format.md b/docs/odata-json-format/odata-json-format.md index 47c0af26..2dccc6fe 100644 --- a/docs/odata-json-format/odata-json-format.md +++ b/docs/odata-json-format/odata-json-format.md @@ -365,7 +365,7 @@ incapable of computing control information, directs the service to inline the control information that normally would be computed from metadata expressions in the payload. [`metadata=none`](#metadatanoneodatametadatanone) -is an option for clients that have out-of-band knowledge or don\'t +is an option for clients that have out-of-band knowledge or don't require control information. In addition, the client may use the `include-annotations` @@ -464,8 +464,7 @@ The full list of control information that may appear in a - [`type`](#ControlInformationtypeodatatype): the type of the containing object or targeted property if the type of the object or targeted property cannot be heuristically determined from - the data value, see section - "[Control Information: type (odata.type)](#ControlInformationtypeodatatype)". + the data value, see [section 4.6.3](#ControlInformationtypeodatatype). Media entities and stream properties may in addition contain the following control information: @@ -577,8 +576,7 @@ parameter if `Edm.Int64` and `Edm.Decimal` numbers are represented as strings. Requests and responses MAY add the `streaming` parameter with -a value of `true` or `false`, see section -"[Payload Ordering Constraints](#PayloadOrderingConstraints)". +a value of `true` or `false`, see [section 4.5](#PayloadOrderingConstraints). ## 4.2 Message Body @@ -796,7 +794,7 @@ response in order to specify the entity tag (ETag) that can be used to determine the version of the metadata of the response. If an ETag is returned when requesting the metadata document, then the service SHOULD set the `metadataEtag` control information to the metadata -document\'s ETag in all responses when using +document's ETag in all responses when using [`metadata=minimal`](#metadataminimalodatametadataminimal) or [`metadata=full`](#metadatafullodatametadatafull). @@ -998,7 +996,7 @@ is ignored in request payloads and not written in responses if [`metadata=none`](#metadatanoneodatametadatanone) is requested. -The default value of both the edit URL and read URL is the entity\'s +The default value of both the edit URL and read URL is the entity's [entity-id](#ControlInformationidodataid) appended with a cast segment to the type of the entity if its type is derived from the declared type of the entity set. If neither the `editLink` @@ -1085,7 +1083,7 @@ if [`metadata=none`](#metadatanoneodatametadatanone) is requested. For [media entities](#MediaEntity) and [stream properties](#StreamProperty) at least one of the control information `mediaEditLink` and `mediaReadLink` MUST be included -in responses if they don\'t follow standard URL conventions as defined +in responses if they don't follow standard URL conventions as defined in [OData-URL, section 4.6](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#AddressingaProperty) and [OData-URL, section 4.14](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#AddressingtheMediaStreamofaMediaEntity), or if [`metadata=full`](#metadatafullodatametadatafull) @@ -2101,7 +2099,7 @@ Example 33: collection of entity references # 15 Delta Payload The non-format specific aspects of the delta handling are described in -the section "Requesting Changes" in [OData-Protocol](#ODataProtocol). +[OData-Protocol, section 11.3](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#RequestingChanges). ## 15.1 Delta Responses @@ -3630,8 +3628,7 @@ preference does not automatically cascade down to the individual requests within the batch. After successful execution of the batch request the response to the batch request is returned in the body of a response to an interrogation request against the status monitor resource -URL, see section "Asynchronous Requests" in -[OData-Protocol](#ODataProtocol). +URL, see [OData-Protocol, section 11.6](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#AsynchronousRequests). A service MAY return interim results to an asynchronously executing batch. It does this by responding with `200 OK` to a diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html index 351e72e9..67b5040b 100644 --- a/docs/odata-protocol/odata-protocol.html +++ b/docs/odata-protocol/odata-protocol.html @@ -849,7 +849,7 @@

    7 Formats

    In the case that both the Accept header and the $format system query option are specified on a request, the value specified in the $format query option MUST be used.

    If the service does not support the requested format, it replies with a 406 Not Acceptable error response.

    Services SHOULD advertise their supported formats in the metadata document by annotating their entity container with the term Capabilities.SupportedFormats, as defined in OData-VocCap, listing all available formats and combinations of supported format parameters.

    -

    The media types for the JSON and XML representation of the metadata document are described in section “Metadata Document Request”.

    +

    The media types for the JSON and XML representation of the metadata document are described in section 11.1.2.

    The format specification OData-JSON describes the media type and the format parameters for non-metadata requests and responses.

    For non-metadata requests, if neither the Accept header nor the $format query option are specified, the service MAY respond to requests in any format.

    Client libraries MUST retain the order of objects within an array in JSON responses, and elements in document order for XML responses, including CSDL documents.

    diff --git a/docs/odata-protocol/odata-protocol.md b/docs/odata-protocol/odata-protocol.md index 58f57789..693825de 100644 --- a/docs/odata-protocol/odata-protocol.md +++ b/docs/odata-protocol/odata-protocol.md @@ -881,8 +881,7 @@ as defined in [OData-VocCap](#ODataVocCap), listing all available formats and combinations of supported format parameters. The media types for the JSON and XML representation of the metadata -document are described in section "[Metadata Document -Request](#MetadataDocumentRequest)". +document are described in [section 11.1.2](#MetadataDocumentRequest). The format specification [OData-JSON](#ODataJSON) describes the media type and the format parameters for non-metadata requests and responses. diff --git a/docs/odata-temporal-ext/odata-temporal-ext.html b/docs/odata-temporal-ext/odata-temporal-ext.html index b2210f48..e5101e38 100644 --- a/docs/odata-temporal-ext/odata-temporal-ext.html +++ b/docs/odata-temporal-ext/odata-temporal-ext.html @@ -352,7 +352,7 @@
    1.2.1.5 Snapshot Entity Set
    -

    An entity in a snapshot entity set represents a temporal object at a specified point in time. When the entity is addressed via a resource path (directly or via related resources), the point in time must be specified, see section “Propagation of Temporal Query Options” for details on how to determine this point in time.

    +

    An entity in a snapshot entity set represents a temporal object at a specified point in time. When the entity is addressed via a resource path (directly or via related resources), the point in time must be specified, see section 4.2.1 for details on how to determine this point in time.

    The entity’s id and its canonical URL are independent of this point in time. Hence, they are sufficient to reference the entity but not address it. In other words: the entity can be considered a function that maps each point in time to an instance of the entity type. That function can be referenced but only its values can be addressed.

    Without a point in time, statements about individual structural or navigation properties of the entity or even about its existence cannot be made, and change tracking is not possible.

    Snapshot entity sets MUST be annotated with a Timeline of type TimelineSnapshot.

    @@ -1828,8 +1828,8 @@

    4.2.4 Interaction with Standard System Query Options

    -

    For snapshot entity sets the point in time for representing data is determined following the rules in section “Propagation of Temporal Query Options” and evaluated first, then all other system query options are evaluated on the data valid at that point in time, including the query option $apply defined in OData-Aggregation.

    -

    For timeline entity sets the interval for filtering data is determined following the rules in section “Propagation of Temporal Query Options” and evaluated as an additional criterion for $filter in the evaluation sequence defined in OData-Protocol, section 11.2.1, which is evaluated after the query option $apply.

    +

    For snapshot entity sets the point in time for representing data is determined following the rules in section 4.2.1 and evaluated first, then all other system query options are evaluated on the data valid at that point in time, including the query option $apply defined in OData-Aggregation.

    +

    For timeline entity sets the interval for filtering data is determined following the rules in section 4.2.1 and evaluated as an additional criterion for $filter in the evaluation sequence defined in OData-Protocol, section 11.2.1, which is evaluated after the query option $apply.

    Example 16: retrieve employee history over a period of application time and filter on job title

    GET /api-2/Employees?$expand=history(
diff --git a/docs/odata-temporal-ext/odata-temporal-ext.md b/docs/odata-temporal-ext/odata-temporal-ext.md
index 0d5ca29d..680d0dfe 100644
--- a/docs/odata-temporal-ext/odata-temporal-ext.md
+++ b/docs/odata-temporal-ext/odata-temporal-ext.md
@@ -231,7 +231,7 @@ alternatively express the used time slice semantics via
 An entity in a snapshot entity set represents a [temporal object](#TemporalObject)
 at a specified point in time. When the entity is addressed via a
 resource path (directly or via related resources), the point in time
-must be specified, see section "[Propagation of Temporal Query Options](#PropagationofTemporalQueryOptions)"
+must be specified, see [section 4.2.1](#PropagationofTemporalQueryOptions)
 for details on how to determine this point in time.
 
 The entity's id and its canonical URL are independent of this point in
@@ -1838,13 +1838,13 @@ beginning of each employee time slice:
 
 For [snapshot entity sets](#SnapshotEntitySet)
 the point in time for representing data is determined following the
-rules in section "[Propagation of Temporal Query Options](#PropagationofTemporalQueryOptions)"
+rules in [section 4.2.1](#PropagationofTemporalQueryOptions)
 and evaluated *first*, then all other system query options are evaluated
 on the data valid at that point in time, including the query option
 `$apply` defined in [OData-Aggregation](#ODataAggregation).
 
 For timeline entity sets the interval for filtering data is determined
-following the rules in section "[Propagation of Temporal Query Options](#PropagationofTemporalQueryOptions)"
+following the rules in [section 4.2.1](#PropagationofTemporalQueryOptions)
 and evaluated as an additional criterion for `$filter` in the evaluation
 sequence defined in [OData-Protocol, section 11.2.1](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#SystemQueryOptions),
 which is evaluated _after_ the query option `$apply`.
diff --git a/odata-csdl/1 Introduction.md b/odata-csdl/1 Introduction.md
index eb014837..385a4ae0 100644
--- a/odata-csdl/1 Introduction.md	
+++ b/odata-csdl/1 Introduction.md	
@@ -525,8 +525,7 @@ parameter or return type of an [action](#Action) or
 `Edm.Stream`, or a type definition whose
 underlying type is `Edm.Stream`, cannot be used in collections.
 
-Some of these types allow facets, defined in section
-"[Type Facets](#TypeFacets)".
+Some of these types allow facets, defined in [section ##TypeFacets].
 
 Representation of primitive type values within a URL is defined by the rule `primitiveLiteral` in [OData-ABNF](#ODataABNF).
 Representation within request and response bodies is format specific.
@@ -888,7 +887,7 @@ be used anywhere a corresponding concrete type can be used, except:
 
 as the type of a primitive term, or the type of a property of a complex
 type (recursively) that is exclusively used as the type of a term. See
-section "[Path Expressions](#PathExpressions)" for details.
+[section ##PathExpressions] for details.
 
 ## ##subsec Annotations
 
diff --git a/odata-csdl/14 Vocabulary and Annotation.md b/odata-csdl/14 Vocabulary and Annotation.md
index e2002b22..c55ed3bc 100644
--- a/odata-csdl/14 Vocabulary and Annotation.md	
+++ b/odata-csdl/14 Vocabulary and Annotation.md	
@@ -1348,8 +1348,7 @@ Example ##ex: absolute path to an entity set
 :::
 
 Paths not starting with a forward slash are interpreted relative to the
-annotation target, following the rules specified in section "[Path
-Evaluation](#PathEvaluation)".
+annotation target, following the rules specified in [section ##PathEvaluation].
 
 ::: example
 Example ##ex: relative path to a property
diff --git a/odata-json-format/15 Delta Payload.md b/odata-json-format/15 Delta Payload.md
index 339682b5..3b24945b 100644
--- a/odata-json-format/15 Delta Payload.md	
+++ b/odata-json-format/15 Delta Payload.md	
@@ -4,7 +4,7 @@
 # ##sec Delta Payload
 
 The non-format specific aspects of the delta handling are described in
-the section "Requesting Changes" in [OData-Protocol](#ODataProtocol).
+[OData-Protocol, section "Requesting Changes"]($$$OData-Protocol$$$#RequestingChanges).
 
 ## ##subsec Delta Responses
 
diff --git a/odata-json-format/19 Batch Requests and Responses.md b/odata-json-format/19 Batch Requests and Responses.md
index 378a8e8a..da57a286 100644
--- a/odata-json-format/19 Batch Requests and Responses.md	
+++ b/odata-json-format/19 Batch Requests and Responses.md	
@@ -442,8 +442,7 @@ preference does not automatically cascade down to the individual
 requests within the batch. After successful execution of the batch
 request the response to the batch request is returned in the body of a
 response to an interrogation request against the status monitor resource
-URL, see section "Asynchronous Requests" in
-[OData-Protocol](#ODataProtocol).
+URL, see [OData-Protocol, section "Asynchronous Requests"]($$$OData-Protocol$$$#AsynchronousRequests).
 
 A service MAY return interim results to an asynchronously executing
 batch. It does this by responding with `200 OK` to a
diff --git a/odata-json-format/3 Requesting the JSON Format.md b/odata-json-format/3 Requesting the JSON Format.md
index 3031d42e..774ce520 100644
--- a/odata-json-format/3 Requesting the JSON Format.md	
+++ b/odata-json-format/3 Requesting the JSON Format.md	
@@ -54,7 +54,7 @@ incapable of computing control information,
 directs the service to inline the control information that normally
 would be computed from metadata expressions in the payload.
 [`metadata=none`](#metadatanoneodatametadatanone)
-is an option for clients that have out-of-band knowledge or don\'t
+is an option for clients that have out-of-band knowledge or don't
 require control information.
 
 In addition, the client may use the `include-annotations`
@@ -153,8 +153,7 @@ The full list of control information that may appear in a
 - [`type`](#ControlInformationtypeodatatype):
   the type of the containing object or targeted property if the type of
   the object or targeted property cannot be heuristically determined from
-  the data value, see section
-  "[Control Information: type (odata.type)](#ControlInformationtypeodatatype)".
+  the data value, see [section ##ControlInformationtypeodatatype].
 
 Media entities and stream properties may in addition contain the
 following control information:
diff --git a/odata-json-format/4 Common Characteristics.md b/odata-json-format/4 Common Characteristics.md
index fed9b030..98448833 100644
--- a/odata-json-format/4 Common Characteristics.md	
+++ b/odata-json-format/4 Common Characteristics.md	
@@ -29,8 +29,7 @@ parameter if `Edm.Int64` and `Edm.Decimal` numbers
 are represented as strings.
 
 Requests and responses MAY add the `streaming` parameter with
-a value of `true` or `false`, see section
-"[Payload Ordering Constraints](#PayloadOrderingConstraints)".
+a value of `true` or `false`, see [section ##PayloadOrderingConstraints].
 
 ## ##subsec Message Body
 
@@ -248,7 +247,7 @@ response in order to specify the entity tag (ETag) that can be used to
 determine the version of the metadata of the response. If an ETag is
 returned when requesting the metadata document, then the service SHOULD
 set the `metadataEtag` control information to the metadata
-document\'s ETag in all responses when using
+document's ETag in all responses when using
 [`metadata=minimal`](#metadataminimalodatametadataminimal)
 or
 [`metadata=full`](#metadatafullodatametadatafull).
@@ -450,7 +449,7 @@ is ignored in request payloads and not written in responses if
 [`metadata=none`](#metadatanoneodatametadatanone)
 is requested.
 
-The default value of both the edit URL and read URL is the entity\'s
+The default value of both the edit URL and read URL is the entity's
 [entity-id](#ControlInformationidodataid) appended with a cast
 segment to the type of the entity if its type is derived from the
 declared type of the entity set. If neither the `editLink`
@@ -537,7 +536,7 @@ if [`metadata=none`](#metadatanoneodatametadatanone) is requested.
 For [media entities](#MediaEntity) and [stream
 properties](#StreamProperty) at least one of the control information
 `mediaEditLink` and `mediaReadLink` MUST be included
-in responses if they don\'t follow standard URL conventions as defined
+in responses if they don't follow standard URL conventions as defined
 in [#OData-URL#AddressingaProperty]
 and [#OData-URL#AddressingtheMediaStreamofaMediaEntity], or if
 [`metadata=full`](#metadatafullodatametadatafull)
diff --git a/odata-protocol/1 Introduction.md b/odata-protocol/1 Introduction.md
index ff404fdd..e8a0d0b6 100644
--- a/odata-protocol/1 Introduction.md	
+++ b/odata-protocol/1 Introduction.md	
@@ -565,8 +565,7 @@ as defined in [OData-VocCap](#ODataVocCap), listing all available
 formats and combinations of supported format parameters.
 
 The media types for the JSON and XML representation of the metadata
-document are described in section "[Metadata Document
-Request](#MetadataDocumentRequest)".
+document are described in [section ##MetadataDocumentRequest].
 
 The format specification [OData-JSON](#ODataJSON) describes the media
 type and the format parameters for non-metadata requests and responses.
diff --git a/odata-temporal-ext/1 Introduction.md b/odata-temporal-ext/1 Introduction.md
index 2a7044c0..8a9abd44 100644
--- a/odata-temporal-ext/1 Introduction.md	
+++ b/odata-temporal-ext/1 Introduction.md	
@@ -82,7 +82,7 @@ alternatively express the used time slice semantics via
 An entity in a snapshot entity set represents a [temporal object](#TemporalObject)
 at a specified point in time. When the entity is addressed via a
 resource path (directly or via related resources), the point in time
-must be specified, see section "[Propagation of Temporal Query Options](#PropagationofTemporalQueryOptions)"
+must be specified, see [section ##PropagationofTemporalQueryOptions]
 for details on how to determine this point in time.
 
 The entity's id and its canonical URL are independent of this point in
diff --git a/odata-temporal-ext/4 Temporal Requests.md b/odata-temporal-ext/4 Temporal Requests.md
index 00bd6f1e..3d785603 100644
--- a/odata-temporal-ext/4 Temporal Requests.md	
+++ b/odata-temporal-ext/4 Temporal Requests.md	
@@ -433,13 +433,13 @@ beginning of each employee time slice:
 
 For [snapshot entity sets](#SnapshotEntitySet)
 the point in time for representing data is determined following the
-rules in section "[Propagation of Temporal Query Options](#PropagationofTemporalQueryOptions)"
+rules in [section ##PropagationofTemporalQueryOptions]
 and evaluated *first*, then all other system query options are evaluated
 on the data valid at that point in time, including the query option
 `$apply` defined in [OData-Aggregation](#ODataAggregation).
 
 For timeline entity sets the interval for filtering data is determined
-following the rules in section "[Propagation of Temporal Query Options](#PropagationofTemporalQueryOptions)"
+following the rules in [section ##PropagationofTemporalQueryOptions]
 and evaluated as an additional criterion for `$filter` in the evaluation
 sequence defined in [#OData-Protocol#SystemQueryOptions],
 which is evaluated _after_ the query option `$apply`.