From d5deee46e50d9affa67ab8703b0a066f63862ada Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Heiko=20Thei=C3=9Fen?= <heiko.theissen@sap.com>
Date: Fri, 6 Sep 2024 11:06:35 +0200
Subject: [PATCH] Converted OData-Data-Agg sections 3.1 and 3.2

---
 .../odata-data-aggregation-ext.html           | 26 +++++++++----------
 .../odata-data-aggregation-ext.md             | 26 +++++++++----------
 ...1 Fundamentals of Input and Output Sets.md | 24 ++++++++---------
 .../3.2 Basic Aggregation.md                  |  2 +-
 4 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html
index df23c93ab..e57d91225 100644
--- a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html
+++ b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html
@@ -1599,7 +1599,7 @@ <h1 id="3-system-query-option-apply"><a name="SystemQueryOptionapply" href="#Sys
 </summary>
 <p>A <em>set transformation</em> (<em>transformation</em> for short) is an operation on an input set that produces an output set. A <em>transformation sequence</em> is a sequence of set transformations, separated by forward slashes to express that they are consecutively applied. A transformation sequence may be invoked using the system query option <code>$apply</code>. The input set of the first set transformation is the collection addressed by the resource path. The output set of each set transformation is the input set for the next set transformation. The output set of the last set transformation in the transformation sequence invoked by the system query option <code>$apply</code> is the result of <code>$apply</code>. This is consistent with the use of service-defined bound and composable functions in path segments. Set transformations may also appear as a parameter of certain other set transformations defined below.</p>
 <p>The system query option <code>$apply</code> MUST NOT be used if the resource path addresses a single instance.</p>
-<p>The system query option <code>$apply</code> is evaluated first, then the other system query options are evaluated, if applicable, on the result of <code>$apply</code>, see <a href="#ODataProtocol">OData-Protocol, section 11.2.1</a>. Stability across requests for system query options <code>$top</code> and <code>$skip</code> <a href="#ODataProtocol">OData-Protocol, sections 11.2.6.3 and 11.2.6.4</a> is defined in <a href="#StableTotalOrderBeforeskipandtop">section 3.3.7</a>.</p>
+<p>The system query option <code>$apply</code> is evaluated first, then the other system query options are evaluated, if applicable, on the result of <code>$apply</code>, see <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#SystemQueryOptions">OData-Protocol, section “System Query Options”</a>. Stability across requests for system query options <code>$top</code> and <code>$skip</code> <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#SystemQueryOptiontop">OData-Protocol, sections “<code>$top</code>” and “<code>$skip</code>”</a> is defined in <a href="#StableTotalOrderBeforeskipandtop">section 3.3.7</a>.</p>
 <p>Each set transformation:</p>
 <ul>
 <li>carries over the input type to the output set such that it fits into the data model of the service.</li>
@@ -1620,13 +1620,13 @@ <h2 id="31-fundamentals-of-input-and-output-sets"><a name="FundamentalsofInputan
 <details open><summary>
 <h3 id="311-type-structure-and-context-url"><a name="TypeStructureandContextURL" href="#TypeStructureandContextURL">3.1.1 Type, Structure and Context URL</a></h3>
 </summary>
-<p>All input sets and output sets in one transformation sequence are collections of the <em>input type</em>, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource <a href="#ODataProtocol">OData-Protocol, section 10</a>. Individual instances in an input or output set can have a subtype of the input type. (See <a href="#subinputtype">example 74</a>.) The transformation sequence given as the <code>$apply</code> system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set.</p>
+<p>All input sets and output sets in one transformation sequence are collections of the <em>input type</em>, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#ContextURL">OData-Protocol, section “Context URL”</a>. Individual instances in an input or output set can have a subtype of the input type. (See <a href="#subinputtype">example 74</a>.) The transformation sequence given as the <code>$apply</code> system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set.</p>
 <p>The <em>structure</em> of an instance that occurs in an input or output set is defined by the names of the structural and navigation properties that the instance contains. Instances of an input type can have different structures, subject to the following rules:</p>
 <ul>
 <li>Declared properties of the input type or a nested or related type thereof or of a subtype of one of these MUST have their declared type and meaning when they occur in an input or output set.</li>
 <li>Single- or collection-valued primitive properties addressed by a property path starting at a non-transient entity MUST keep their values from the addressed resource path collection throughout the transformation sequence. Likewise, single- or collection-valued navigation property paths starting at a non-transient entity MUST keep addressing the same non-transient entities as in the addressed resource path collection.</li>
 <li>Instances in an output set need not have all declared or dynamic properties that occurred in the input set.</li>
-<li>Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an <em>alias</em>, it is a simple identifier (see <a href="#ODataCSDL">OData-CSDL, section 17.2</a>). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other.</li>
+<li>Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an <em>alias</em>, it is a simple identifier (see <a href="https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html#SimpleIdentifier">OData-CSDL, section “Simple Identifier”</a>). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other.</li>
 </ul>
 <p>Here is an overview of the structural changes made by different transformations:</p>
 <ul>
@@ -1636,14 +1636,14 @@ <h3 id="311-type-structure-and-context-url"><a name="TypeStructureandContextURL"
 <li>During <a href="#Transformationsjoinandouterjoin">join</a>, one instance with a collection of related instances is replaced by many copies, each of which is related via a dynamic property to one of the related instances.</li>
 <li>During <a href="#Transformationconcat">concatenation</a>, the same instances are transformed multiple times and the output sets with their potentially different structures are concatenated.</li>
 </ul>
-<p>An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type <a href="#ODataCSDL">OData-CSDL, sections 6.3 and 9.3</a> and it is handled in the same way.</p>
-<p>If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The <code>{select-list}</code> in the context URL <a href="#ODataProtocol">OData-Protocol, section 10</a> MUST describe only properties that are present or annotated as absent (for example, if <code>Core.Permissions</code> is <code>None</code> <a href="#ODataProtocol">OData-Protocol, section 11.2.2</a>) in all instances of the collection, after applying any <code>$select</code> and <code>$expand</code> system query options. The <code>{select-list}</code> SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the <code>{select-list}</code> MUST consist of just the instance annotation <code>AnyStructure</code> defined in the <code>Core</code> vocabulary <a href="#ODataVocCore">OData-VocCore</a>. (See <a href="#anystructure">example 75</a>.)</p>
+<p>An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type <a href="$$$OData-CSDL$$$#OpenEntityType">OData-CSDL, sections “Open Entity Type”</a> and ["Open Complex Type"]($$$OData-CSDL$$$#OpenComplexType) and it is handled in the same way.</p>
+<p>If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The <code>{select-list}</code> in the context URL <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#ContextURL">OData-Protocol, section “Context URL”</a> MUST describe only properties that are present or annotated as absent (for example, if <code>Core.Permissions</code> is <code>None</code> <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#RequestingIndividualEntities">OData-Protocol, section “Requesting Individual Entities”</a>) in all instances of the collection, after applying any <code>$select</code> and <code>$expand</code> system query options. The <code>{select-list}</code> SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the <code>{select-list}</code> MUST consist of just the instance annotation <code>AnyStructure</code> defined in the <code>Core</code> vocabulary <a href="#ODataVocCore">OData-VocCore</a>. (See <a href="#anystructure">example 75</a>.)</p>
 </details>
 <details open><summary>
 <h3 id="312-sameness-and-order"><a name="SamenessandOrder" href="#SamenessandOrder">3.1.2 Sameness and Order</a></h3>
 </summary>
 <p>Input sets and output sets are not sets of instances in the mathematical sense but collections, because the same instance can occur multiple times in them. In other words: A collection contains values (which can be instances of structured types or primitive values), possibly with repetitions. The occurrences of the values in the collection form a set in the mathematical sense. The <em>cardinality</em> of a collection is the total number of occurrences in it. When this text describes a transformation algorithmically and stipulates that certain steps are carried out <em>for each occurrence</em> in a collection, this means that the steps are carried out multiple times for the same value if it occurs multiple times in the collection.</p>
-<p>A collection addressed by the resource path is returned by the service either as an ordered collection <a href="#ODataProtocol">OData-Protocol, section 11.4.10</a> or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with <code>$root</code>, which occur, for example, as the first parameter of a <a href="#HierarchicalTransformations">hierarchical transformation</a>.</p>
+<p>A collection addressed by the resource path is returned by the service either as an ordered collection <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#ManagingMembersofanOrderedCollection">OData-Protocol, section “Managing Members of an Ordered Collection”</a> or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with <code>$root</code>, which occur, for example, as the first parameter of a <a href="#HierarchicalTransformations">hierarchical transformation</a>.</p>
 <p>But when such a collection is transformed by the <code>$apply</code> system query option, additional cases can arise that are neither ordered nor totally unordered. For example, the <a href="#Transformationgroupby"><code>groupby</code></a> transformation retains any order within a group but not between groups.</p>
 <div class="example">
 <p>⚠ Example 6: Request the top 10 sales per customer. The processing of the request can be parallelized per customer and the responses per customer can be interleaved in the overall response. This means that for any given customer, their top 10 sales appear in the desired order, though not consecutively.</p>
@@ -1654,15 +1654,15 @@ <h3 id="312-sameness-and-order"><a name="SamenessandOrder" href="#SamenessandOrd
 <p>When transformations are defined in the following sections, the algorithmic description sometimes contains an <em>order-preserving loop</em> over a collection. Such a loop processes the occurrences in an order chosen by the service in such a way that <span class="math inline">\(u_1\)</span> is processed before <span class="math inline">\(u_2\)</span> whenever <span class="math inline">\(u_1\)</span> precedes <span class="math inline">\(u_2\)</span>. Likewise, in an <em>order-preserving sequence</em> <span class="math inline">\(u_1,…,u_n\)</span> we have <span class="math inline">\(i&lt;j\)</span> whenever <span class="math inline">\(u_i\)</span> precedes <span class="math inline">\(u_j\)</span>.</p>
 <p>A collection can be <em>stable-sorted</em> by a list of expressions. In the stable-sorted collection an occurrence <span class="math inline">\(u_1\)</span> precedes <span class="math inline">\(u_2\)</span> if and only if either</p>
 <ul>
-<li><span class="math inline">\(u_1\)</span> precedes <span class="math inline">\(u_2\)</span> according to the rules of <a href="#ODataProtocol">OData-Protocol, section 11.2.6.2</a> or</li>
+<li><span class="math inline">\(u_1\)</span> precedes <span class="math inline">\(u_2\)</span> according to the rules of <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#SystemQueryOptionorderby">OData-Protocol, section “System Query Option <code>$orderby</code></a> or</li>
 <li>these rules do not determine a precedence in either direction between <span class="math inline">\(u_1\)</span> and <span class="math inline">\(u_2\)</span> but <span class="math inline">\(u_1\)</span> preceded <span class="math inline">\(u_2\)</span> in the collection before the sort.</li>
 </ul>
 <p>Stable-sorting of an ordered collection produces another ordered collection. A stable-sort does not necessarily produce a total order, the sorted collection may still contain two occurrences whose relative order does not matter. The transformation <a href="#Transformationorderby"><code>orderby</code></a> performs a stable-sort.</p>
-<p>The output set of a <a href="#BasicAggregation">basic aggregation</a> transformation can contain instances of an entity type without entity-id. After a <a href="#Transformationconcat"><code>concat</code></a> transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in <a href="#ODataURL">OData-URL, section 5.1.1.1.1</a> is refined here. Instances of structured types are <em>the same</em> if</p>
+<p>The output set of a <a href="#BasicAggregation">basic aggregation</a> transformation can contain instances of an entity type without entity-id. After a <a href="#Transformationconcat"><code>concat</code></a> transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#Equals">OData-URL, section “Equals”</a> is refined here. Instances of structured types are <em>the same</em> if</p>
 <ul>
 <li>both are instances of complex types and both are null or both have the same structure and same values with null considered different from absent or</li>
-<li>both are instances of entity types without entity-id (transient entities, see <a href="#ODataProtocol">OData-Protocol, section 4.3</a>) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or</li>
-<li>(1) both are instances of the same entity type with the same entity-id (non-transient entities, see <a href="#ODataProtocol">OData-Protocol, section 4.1</a>) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition).
+<li>both are instances of entity types without entity-id (see <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#TransientEntities">OData-Protocol, section “Transient Entities”</a>) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or</li>
+<li>(1) both are instances of the same entity type with the same entity-id (non-transient entities, see <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#EntityIdsandEntityReferences">OData-Protocol, section “Entity-Ids and Entity References”</a>) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition).
 <ul>
 <li>If this is fulfilled, the instances are called <em>complementary representations of the same non-transient entity</em>. If this case is encountered at some recursion level while the sameness of non-transient entities <span class="math inline">\(u_1\)</span> and <span class="math inline">\(u_2\)</span> is established, a merged representation of the entity <span class="math inline">\(u_1=u_2\)</span> exists that contains all properties of <span class="math inline">\(u_1\)</span> and <span class="math inline">\(u_2\)</span>. But if the instances both occur in the last output set, services MUST represent each with its own structure in the response payload.</li>
 <li>If the first condition is fulfilled but not the second, the instances are not the same and are called <em>contradictory representations of the same non-transient entity</em>. (<a href="#contradict">Example 103</a> describes a use case for this.)</li>
@@ -1678,13 +1678,13 @@ <h3 id="312-sameness-and-order"><a name="SamenessandOrder" href="#SamenessandOrd
 <h3 id="313-evaluation-of-data-aggregation-paths"><a name="EvaluationofDataAggregationPaths" href="#EvaluationofDataAggregationPaths">3.1.3 Evaluation of Data Aggregation Paths</a></h3>
 </summary>
 <p>This document specifies how a <a href="#DataAggregationPath">data aggregation path</a> that occurs in a request is evaluated by the service. If such an evaluation fails, the service MUST reject the request.</p>
-<p>For a data aggregation path to be a common expression according to <a href="#ODataURL">OData-URL, section 5.1.1</a>, its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection <span class="math inline">\(A\)</span>, even if it has arbitrary collection-valued segments itself.</p>
+<p>For a data aggregation path to be a common expression according to <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#CommonExpressions">OData-URL, section “Common Expressions”</a>, its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection <span class="math inline">\(A\)</span>, even if it has arbitrary collection-valued segments itself.</p>
 <p>To this end, the following notation is used in the subsequent sections: If <span class="math inline">\(A\)</span> is a collection and <span class="math inline">\(p\)</span> a data aggregation path, optionally followed by a type-cast segment, the result of such a path evaluation is denoted by <span class="math inline">\(\Gamma(A,p)\)</span> and defined as the unordered concatenation, possibly containing repetitions, of the collections <span class="math inline">\(γ(u,p)\)</span> for each <span class="math inline">\(u\)</span> in <span class="math inline">\(A\)</span> that is not null. The function <span class="math inline">\(γ(u,p)\)</span> takes a non-null value and a path as arguments and returns a collection of instances of structured types or primitive values, depending on the type of the final segment of <span class="math inline">\(p\)</span>. It is recursively defined as follows:</p>
 <ol type="1">
 <li>If <span class="math inline">\(p\)</span> is an empty path, let <span class="math inline">\(B\)</span> be a collection with <span class="math inline">\(u\)</span> as its single member and continue with step 9.</li>
 <li>Let <span class="math inline">\(p_1\)</span> be the first segment of <span class="math inline">\(p\)</span> and <span class="math inline">\(p_2\)</span> the remainder, if any, such that <span class="math inline">\(p\)</span> equals the concatenated path <span class="math inline">\(p_1/p_2\)</span>.</li>
 <li>If <span class="math inline">\(p_1\)</span> is a type-cast segment and <span class="math inline">\(u\)</span> is of its type or a subtype thereof, let <span class="math inline">\(v=u\)</span> and continue with step 8.</li>
-<li>If <span class="math inline">\(p_1\)</span> is a type-cast segment and <span class="math inline">\(u\)</span> is not of its type or a subtype thereof, let <span class="math inline">\(B\)</span> be an empty collection and continue with step 9. (This rule follows <a href="#ODataURL">OData-URL, section 4.11</a> rather than <a href="#ODataCSDL">OData-CSDL, section 14.4.1.1</a>.)</li>
+<li>If <span class="math inline">\(p_1\)</span> is a type-cast segment and <span class="math inline">\(u\)</span> is not of its type or a subtype thereof, let <span class="math inline">\(B\)</span> be an empty collection and continue with step 9. (This rule follows <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#AddressingDerivedTypes">OData-URL, section “Addressing Derived Types”</a> rather than <a href="https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html#PathSyntax">OData-CSDL, section “Path Syntax”</a>.)</li>
 <li>Otherwise, <span class="math inline">\(p_1\)</span> is a non-type-cast segment. If <span class="math inline">\(u\)</span> does not contain a structural or navigation property <span class="math inline">\(p_1\)</span>, let <span class="math inline">\(B\)</span> be an empty collection and continue with step 9.</li>
 <li>If <span class="math inline">\(p_1\)</span> is single-valued, let <span class="math inline">\(v\)</span> be the value of the structural or navigation property <span class="math inline">\(p_1\)</span> in <span class="math inline">\(u\)</span>. If <span class="math inline">\(v\)</span> is null, let <span class="math inline">\(B\)</span> be an empty collection and continue with step 9; otherwise continue with step 8.</li>
 <li>Otherwise, <span class="math inline">\(p_1\)</span> is collection-valued. Let <span class="math inline">\(C\)</span> be the collection addressed by the structural or navigation property <span class="math inline">\(p_1\)</span> in <span class="math inline">\(u\)</span>, and let <span class="math inline">\(B=\Gamma(C,p_2)\)</span>. Then continue with step 9.</li>
@@ -1835,7 +1835,7 @@ <h5 id="32134-standard-aggregation-method-average"><a name="StandardAggregationM
 <details open><summary>
 <h5 id="32135-standard-aggregation-method-countdistinct"><a name="StandardAggregationMethodcountdistinct" href="#StandardAggregationMethodcountdistinct">3.2.1.3.5 Standard Aggregation Method <code>countdistinct</code></a></h5>
 </summary>
-<p>The aggregation method <code>countdistinct</code> can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#Equals">OData-URL, section 5.1.1.1.1</a>.</p>
+<p>The aggregation method <code>countdistinct</code> can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in <a href="https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#Equals">OData-URL, section “Equals”</a>.</p>
 <p>The result property MUST have type <code>Edm.Decimal</code> with <code>Scale</code> 0 and sufficient <code>Precision</code>.</p>
 <div class="example">
 <p>Example 13:</p>
diff --git a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md
index 6735a51f1..17da34b61 100644
--- a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md
+++ b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md
@@ -1007,7 +1007,7 @@ A _set transformation_ (_transformation_ for short) is an operation on an input
 
 The system query option `$apply` MUST NOT be used if the resource path addresses a single instance.
 
-The system query option `$apply` is evaluated first, then the other system query options are evaluated, if applicable, on the result of `$apply`, see [OData-Protocol, section 11.2.1](#ODataProtocol). Stability across requests for system query options `$top` and `$skip` [OData-Protocol, sections 11.2.6.3 and 11.2.6.4](#ODataProtocol) is defined in [section 3.3.7](#StableTotalOrderBeforeskipandtop).
+The system query option `$apply` is evaluated first, then the other system query options are evaluated, if applicable, on the result of `$apply`, see [OData-Protocol, section "System Query Options"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#SystemQueryOptions). Stability across requests for system query options `$top` and `$skip` [OData-Protocol, sections "`$top`" and "`$skip`"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#SystemQueryOptiontop) is defined in [section 3.3.7](#StableTotalOrderBeforeskipandtop).
 
 Each set transformation:
 - carries over the input type to the output set such that it fits into the data model of the service.
@@ -1033,13 +1033,13 @@ The definitions of italicized terms made in this section are used throughout thi
 
 ### <a name="TypeStructureandContextURL" href="#TypeStructureandContextURL">3.1.1 Type, Structure and Context URL</a>
 
-All input sets and output sets in one transformation sequence are collections of the _input type_, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource [OData-Protocol, section 10](#ODataProtocol). Individual instances in an input or output set can have a subtype of the input type. (See [example 74](#subinputtype).) The transformation sequence given as the `$apply` system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set.
+All input sets and output sets in one transformation sequence are collections of the _input type_, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource [OData-Protocol, section "Context URL"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#ContextURL). Individual instances in an input or output set can have a subtype of the input type. (See [example 74](#subinputtype).) The transformation sequence given as the `$apply` system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set.
 
 The _structure_ of an instance that occurs in an input or output set is defined by the names of the structural and navigation properties that the instance contains. Instances of an input type can have different structures, subject to the following rules:
 - Declared properties of the input type or a nested or related type thereof or of a subtype of one of these MUST have their declared type and meaning when they occur in an input or output set.
 - Single- or collection-valued primitive properties addressed by a property path starting at a non-transient entity MUST keep their values from the addressed resource path collection throughout the transformation sequence. Likewise, single- or collection-valued navigation property paths starting at a non-transient entity MUST keep addressing the same non-transient entities as in the addressed resource path collection.
 - Instances in an output set need not have all declared or dynamic properties that occurred in the input set.
-- Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an _alias_, it is a simple identifier (see [OData-CSDL, section 17.2](#ODataCSDL)). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other.
+- Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an _alias_, it is a simple identifier (see [OData-CSDL, section "Simple Identifier"](https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html#SimpleIdentifier)). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other.
 
 Here is an overview of the structural changes made by different transformations:
 - During [aggregation](#BasicAggregation) or [nest](#Transformationnest), many instances are replaced by one instance, properties that represent the aggregation level are retained, and others are replaced by dynamic properties holding the aggregate value of the many instances or a transformed copy of them.
@@ -1048,15 +1048,15 @@ Here is an overview of the structural changes made by different transformations:
 - During [join](#Transformationsjoinandouterjoin), one instance with a collection of related instances is replaced by many copies, each of which is related via a dynamic property to one of the related instances.
 - During [concatenation](#Transformationconcat), the same instances are transformed multiple times and the output sets with their potentially different structures are concatenated.
 
-An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type [OData-CSDL, sections 6.3 and 9.3](#ODataCSDL) and it is handled in the same way.
+An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type [OData-CSDL, sections "Open Entity Type"]($$$OData-CSDL$$$#OpenEntityType) and ["Open Complex Type"]($$$OData-CSDL$$$#OpenComplexType) and it is handled in the same way.
 
-If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The `{select-list}` in the context URL [OData-Protocol, section 10](#ODataProtocol) MUST describe only properties that are present or annotated as absent (for example, if `Core.Permissions` is `None` [OData-Protocol, section 11.2.2](#ODataProtocol)) in all instances of the collection, after applying any `$select` and `$expand` system query options. The `{select-list}` SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the `{select-list}` MUST consist of just the instance annotation `AnyStructure` defined in the `Core` vocabulary [OData-VocCore](#ODataVocCore). (See [example 75](#anystructure).)
+If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The `{select-list}` in the context URL [OData-Protocol, section "Context URL"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#ContextURL) MUST describe only properties that are present or annotated as absent (for example, if `Core.Permissions` is `None` [OData-Protocol, section "Requesting Individual Entities"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#RequestingIndividualEntities)) in all instances of the collection, after applying any `$select` and `$expand` system query options. The `{select-list}` SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the `{select-list}` MUST consist of just the instance annotation `AnyStructure` defined in the `Core` vocabulary [OData-VocCore](#ODataVocCore). (See [example 75](#anystructure).)
 
 ### <a name="SamenessandOrder" href="#SamenessandOrder">3.1.2 Sameness and Order</a>
 
 Input sets and output sets are not sets of instances in the mathematical sense but collections, because the same instance can occur multiple times in them. In other words: A collection contains values (which can be instances of structured types or primitive values), possibly with repetitions. The occurrences of the values in the collection form a set in the mathematical sense. The _cardinality_ of a collection is the total number of occurrences in it. When this text describes a transformation algorithmically and stipulates that certain steps are carried out _for each occurrence_ in a collection, this means that the steps are carried out multiple times for the same value if it occurs multiple times in the collection.
 
-A collection addressed by the resource path is returned by the service either as an ordered collection [OData-Protocol, section 11.4.10](#ODataProtocol) or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with `$root`, which occur, for example, as the first parameter of a [hierarchical transformation](#HierarchicalTransformations).
+A collection addressed by the resource path is returned by the service either as an ordered collection [OData-Protocol, section "Managing Members of an Ordered Collection"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#ManagingMembersofanOrderedCollection) or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with `$root`, which occur, for example, as the first parameter of a [hierarchical transformation](#HierarchicalTransformations).
 
 But when such a collection is transformed by the `$apply` system query option, additional cases can arise that are neither ordered nor totally unordered. For example, the [`groupby`](#Transformationgroupby) transformation retains any order within a group but not between groups.
 
@@ -1074,15 +1074,15 @@ An order of a collection is more precisely defined as follows: Given two differe
 When transformations are defined in the following sections, the algorithmic description sometimes contains an _order-preserving loop_ over a collection. Such a loop processes the occurrences in an order chosen by the service in such a way that $u_1$ is processed before $u_2$ whenever $u_1$ precedes $u_2$. Likewise, in an _order-preserving sequence_ $u_1,…,u_n$ we have $i<j$ whenever $u_i$ precedes $u_j$.
 
 A collection can be _stable-sorted_ by a list of expressions. In the stable-sorted collection an occurrence $u_1$ precedes $u_2$ if and only if either
-- $u_1$ precedes $u_2$ according to the rules of [OData-Protocol, section 11.2.6.2](#ODataProtocol) or
+- $u_1$ precedes $u_2$ according to the rules of [OData-Protocol, section "System Query Option `$orderby`](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#SystemQueryOptionorderby) or
 - these rules do not determine a precedence in either direction between $u_1$ and $u_2$ but $u_1$ preceded $u_2$ in the collection before the sort.
 
 Stable-sorting of an ordered collection produces another ordered collection. A stable-sort does not necessarily produce a total order, the sorted collection may still contain two occurrences whose relative order does not matter. The transformation [`orderby`](#Transformationorderby) performs a stable-sort.
 
-The output set of a [basic aggregation](#BasicAggregation) transformation can contain instances of an entity type without entity-id. After a [`concat`](#Transformationconcat) transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in [OData-URL, section 5.1.1.1.1](#ODataURL) is refined here. Instances of structured types are _the same_ if
+The output set of a [basic aggregation](#BasicAggregation) transformation can contain instances of an entity type without entity-id. After a [`concat`](#Transformationconcat) transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in [OData-URL, section "Equals"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#Equals) is refined here. Instances of structured types are _the same_ if
 - both are instances of complex types and both are null or both have the same structure and same values with null considered different from absent or
-- both are instances of entity types without entity-id (transient entities, see [OData-Protocol, section 4.3](#ODataProtocol)) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or
-- (1) both are instances of the same entity type with the same entity-id (non-transient entities, see [OData-Protocol, section 4.1](#ODataProtocol)) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition).
+- both are instances of entity types without entity-id (see [OData-Protocol, section "Transient Entities"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#TransientEntities)) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or
+- (1) both are instances of the same entity type with the same entity-id (non-transient entities, see [OData-Protocol, section "Entity-Ids and Entity References"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html#EntityIdsandEntityReferences)) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition).
   - If this is fulfilled, the instances are called _complementary representations of the same non-transient entity_. If this case is encountered at some recursion level while the sameness of non-transient entities $u_1$ and $u_2$ is established, a merged representation of the entity $u_1=u_2$ exists that contains all properties of $u_1$ and $u_2$. But if the instances both occur in the last output set, services MUST represent each with its own structure in the response payload.
   - If the first condition is fulfilled but not the second, the instances are not the same and are called _contradictory representations of the same non-transient entity_. ([Example 103](#contradict) describes a use case for this.)
 
@@ -1094,13 +1094,13 @@ Collections are _the same_ if there is a one-to-one correspondence $f$ between t
 
 This document specifies how a [data aggregation path](#DataAggregationPath) that occurs in a request is evaluated by the service. If such an evaluation fails, the service MUST reject the request.
 
-For a data aggregation path to be a common expression according to [OData-URL, section 5.1.1](#ODataURL), its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection $A$, even if it has arbitrary collection-valued segments itself.
+For a data aggregation path to be a common expression according to [OData-URL, section "Common Expressions"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#CommonExpressions), its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection $A$, even if it has arbitrary collection-valued segments itself.
 
 To this end, the following notation is used in the subsequent sections: If $A$ is a collection and $p$ a data aggregation path, optionally followed by a type-cast segment, the result of such a path evaluation is denoted by $\Gamma(A,p)$ and defined as the unordered concatenation, possibly containing repetitions, of the collections $γ(u,p)$ for each $u$ in $A$ that is not null. The function $γ(u,p)$ takes a non-null value and a path as arguments and returns a collection of instances of structured types or primitive values, depending on the type of the final segment of $p$. It is recursively defined as follows:
 1. If $p$ is an empty path, let $B$ be a collection with $u$ as its single member and continue with step 9.
 2. Let $p_1$ be the first segment of $p$ and $p_2$ the remainder, if any, such that $p$ equals the concatenated path $p_1/p_2$.
 3. If $p_1$ is a type-cast segment and $u$ is of its type or a subtype thereof, let $v=u$ and continue with step 8.
-4. If $p_1$ is a type-cast segment and $u$ is not of its type or a subtype thereof, let $B$ be an empty collection and continue with step 9. (This rule follows [OData-URL, section 4.11](#ODataURL) rather than [OData-CSDL, section 14.4.1.1](#ODataCSDL).)
+4. If $p_1$ is a type-cast segment and $u$ is not of its type or a subtype thereof, let $B$ be an empty collection and continue with step 9. (This rule follows [OData-URL, section "Addressing Derived Types"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#AddressingDerivedTypes) rather than [OData-CSDL, section "Path Syntax"](https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html#PathSyntax).)
 5. Otherwise, $p_1$ is a non-type-cast segment. If $u$ does not contain a structural or navigation property $p_1$, let $B$ be an empty collection and continue with step 9.
 6. If $p_1$ is single-valued, let $v$ be the value of the structural or navigation property $p_1$ in $u$. If $v$ is null, let $B$ be an empty collection and continue with step 9; otherwise continue with step 8.
 7. Otherwise, $p_1$ is collection-valued. Let $C$ be the collection addressed by the structural or navigation property $p_1$ in $u$, and let $B=\Gamma(C,p_2)$. Then continue with step 9.
@@ -1276,7 +1276,7 @@ results in
 
 ##### <a name="StandardAggregationMethodcountdistinct" href="#StandardAggregationMethodcountdistinct">3.2.1.3.5 Standard Aggregation Method `countdistinct`</a>
 
-The aggregation method `countdistinct` can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in [OData-URL, section 5.1.1.1.1](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#Equals).
+The aggregation method `countdistinct` can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in [OData-URL, section "Equals"](https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html#Equals).
 
 The result property MUST have type `Edm.Decimal` with `Scale` 0 and sufficient `Precision`.
 
diff --git a/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md b/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md
index b37161b7c..c873351f9 100644
--- a/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md	
+++ b/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md	
@@ -7,7 +7,7 @@ A _set transformation_ (_transformation_ for short) is an operation on an input
 
 The system query option `$apply` MUST NOT be used if the resource path addresses a single instance.
 
-The system query option `$apply` is evaluated first, then the other system query options are evaluated, if applicable, on the result of `$apply`, see [OData-Protocol, section 11.2.1](#ODataProtocol). Stability across requests for system query options `$top` and `$skip` [OData-Protocol, sections 11.2.6.3 and 11.2.6.4](#ODataProtocol) is defined in [section ##StableTotalOrderBeforeskipandtop].
+The system query option `$apply` is evaluated first, then the other system query options are evaluated, if applicable, on the result of `$apply`, see [OData-Protocol, section "System Query Options"]($$$OData-Protocol$$$#SystemQueryOptions). Stability across requests for system query options `$top` and `$skip` [OData-Protocol, sections "`$top`" and "`$skip`"]($$$OData-Protocol$$$#SystemQueryOptiontop) is defined in [section ##StableTotalOrderBeforeskipandtop].
 
 Each set transformation:
 - carries over the input type to the output set such that it fits into the data model of the service.
@@ -33,13 +33,13 @@ The definitions of italicized terms made in this section are used throughout thi
 
 ### ##subsubsec Type, Structure and Context URL
 
-All input sets and output sets in one transformation sequence are collections of the _input type_, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource [OData-Protocol, section 10](#ODataProtocol). Individual instances in an input or output set can have a subtype of the input type. (See [example ##subinputtype].) The transformation sequence given as the `$apply` system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set.
+All input sets and output sets in one transformation sequence are collections of the _input type_, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource [OData-Protocol, section "Context URL"]($$$OData-Protocol$$$#ContextURL). Individual instances in an input or output set can have a subtype of the input type. (See [example ##subinputtype].) The transformation sequence given as the `$apply` system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set.
 
 The _structure_ of an instance that occurs in an input or output set is defined by the names of the structural and navigation properties that the instance contains. Instances of an input type can have different structures, subject to the following rules:
 - Declared properties of the input type or a nested or related type thereof or of a subtype of one of these MUST have their declared type and meaning when they occur in an input or output set.
 - Single- or collection-valued primitive properties addressed by a property path starting at a non-transient entity MUST keep their values from the addressed resource path collection throughout the transformation sequence. Likewise, single- or collection-valued navigation property paths starting at a non-transient entity MUST keep addressing the same non-transient entities as in the addressed resource path collection.
 - Instances in an output set need not have all declared or dynamic properties that occurred in the input set.
-- Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an _alias_, it is a simple identifier (see [OData-CSDL, section 17.2](#ODataCSDL)). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other.
+- Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an _alias_, it is a simple identifier (see [OData-CSDL, section "Simple Identifier"]($$$OData-CSDLJSON$$$#SimpleIdentifier)). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other.
 
 Here is an overview of the structural changes made by different transformations:
 - During [aggregation](#BasicAggregation) or [nest](#Transformationnest), many instances are replaced by one instance, properties that represent the aggregation level are retained, and others are replaced by dynamic properties holding the aggregate value of the many instances or a transformed copy of them.
@@ -48,15 +48,15 @@ Here is an overview of the structural changes made by different transformations:
 - During [join](#Transformationsjoinandouterjoin), one instance with a collection of related instances is replaced by many copies, each of which is related via a dynamic property to one of the related instances.
 - During [concatenation](#Transformationconcat), the same instances are transformed multiple times and the output sets with their potentially different structures are concatenated.
 
-An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type [OData-CSDL, sections 6.3 and 9.3](#ODataCSDL) and it is handled in the same way.
+An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type [OData-CSDL, sections "Open Entity Type"]($$$OData-CSDL$$$#OpenEntityType) and ["Open Complex Type"]($$$OData-CSDL$$$#OpenComplexType) and it is handled in the same way.
 
-If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The `{select-list}` in the context URL [OData-Protocol, section 10](#ODataProtocol) MUST describe only properties that are present or annotated as absent (for example, if `Core.Permissions` is `None` [OData-Protocol, section 11.2.2](#ODataProtocol)) in all instances of the collection, after applying any `$select` and `$expand` system query options. The `{select-list}` SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the `{select-list}` MUST consist of just the instance annotation `AnyStructure` defined in the `Core` vocabulary [OData-VocCore](#ODataVocCore). (See [example ##anystructure].)
+If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The `{select-list}` in the context URL [OData-Protocol, section "Context URL"]($$$OData-Protocol$$$#ContextURL) MUST describe only properties that are present or annotated as absent (for example, if `Core.Permissions` is `None` [OData-Protocol, section "Requesting Individual Entities"]($$$OData-Protocol$$$#RequestingIndividualEntities)) in all instances of the collection, after applying any `$select` and `$expand` system query options. The `{select-list}` SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the `{select-list}` MUST consist of just the instance annotation `AnyStructure` defined in the `Core` vocabulary [OData-VocCore](#ODataVocCore). (See [example ##anystructure].)
 
 ### ##subsubsec Sameness and Order
 
 Input sets and output sets are not sets of instances in the mathematical sense but collections, because the same instance can occur multiple times in them. In other words: A collection contains values (which can be instances of structured types or primitive values), possibly with repetitions. The occurrences of the values in the collection form a set in the mathematical sense. The _cardinality_ of a collection is the total number of occurrences in it. When this text describes a transformation algorithmically and stipulates that certain steps are carried out _for each occurrence_ in a collection, this means that the steps are carried out multiple times for the same value if it occurs multiple times in the collection.
 
-A collection addressed by the resource path is returned by the service either as an ordered collection [OData-Protocol, section 11.4.10](#ODataProtocol) or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with `$root`, which occur, for example, as the first parameter of a [hierarchical transformation](#HierarchicalTransformations).
+A collection addressed by the resource path is returned by the service either as an ordered collection [OData-Protocol, section "Managing Members of an Ordered Collection"]($$$OData-Protocol$$$#ManagingMembersofanOrderedCollection) or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with `$root`, which occur, for example, as the first parameter of a [hierarchical transformation](#HierarchicalTransformations).
 
 But when such a collection is transformed by the `$apply` system query option, additional cases can arise that are neither ordered nor totally unordered. For example, the [`groupby`](#Transformationgroupby) transformation retains any order within a group but not between groups.
 
@@ -74,15 +74,15 @@ An order of a collection is more precisely defined as follows: Given two differe
 When transformations are defined in the following sections, the algorithmic description sometimes contains an _order-preserving loop_ over a collection. Such a loop processes the occurrences in an order chosen by the service in such a way that $u_1$ is processed before $u_2$ whenever $u_1$ precedes $u_2$. Likewise, in an _order-preserving sequence_ $u_1,…,u_n$ we have $i<j$ whenever $u_i$ precedes $u_j$.
 
 A collection can be _stable-sorted_ by a list of expressions. In the stable-sorted collection an occurrence $u_1$ precedes $u_2$ if and only if either
-- $u_1$ precedes $u_2$ according to the rules of [OData-Protocol, section 11.2.6.2](#ODataProtocol) or
+- $u_1$ precedes $u_2$ according to the rules of [OData-Protocol, section "System Query Option `$orderby`]($$$OData-Protocol$$$#SystemQueryOptionorderby) or
 - these rules do not determine a precedence in either direction between $u_1$ and $u_2$ but $u_1$ preceded $u_2$ in the collection before the sort.
 
 Stable-sorting of an ordered collection produces another ordered collection. A stable-sort does not necessarily produce a total order, the sorted collection may still contain two occurrences whose relative order does not matter. The transformation [`orderby`](#Transformationorderby) performs a stable-sort.
 
-The output set of a [basic aggregation](#BasicAggregation) transformation can contain instances of an entity type without entity-id. After a [`concat`](#Transformationconcat) transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in [OData-URL, section 5.1.1.1.1](#ODataURL) is refined here. Instances of structured types are _the same_ if
+The output set of a [basic aggregation](#BasicAggregation) transformation can contain instances of an entity type without entity-id. After a [`concat`](#Transformationconcat) transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in [OData-URL, section "Equals"]($$$OData-URL$$$#Equals) is refined here. Instances of structured types are _the same_ if
 - both are instances of complex types and both are null or both have the same structure and same values with null considered different from absent or
-- both are instances of entity types without entity-id (transient entities, see [OData-Protocol, section 4.3](#ODataProtocol)) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or
-- (1) both are instances of the same entity type with the same entity-id (non-transient entities, see [OData-Protocol, section 4.1](#ODataProtocol)) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition).
+- both are instances of entity types without entity-id (see [OData-Protocol, section "Transient Entities"]($$$OData-Protocol$$$#TransientEntities)) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or
+- (1) both are instances of the same entity type with the same entity-id (non-transient entities, see [OData-Protocol, section "Entity-Ids and Entity References"]($$$OData-Protocol$$$#EntityIdsandEntityReferences)) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition).
   - If this is fulfilled, the instances are called _complementary representations of the same non-transient entity_. If this case is encountered at some recursion level while the sameness of non-transient entities $u_1$ and $u_2$ is established, a merged representation of the entity $u_1=u_2$ exists that contains all properties of $u_1$ and $u_2$. But if the instances both occur in the last output set, services MUST represent each with its own structure in the response payload.
   - If the first condition is fulfilled but not the second, the instances are not the same and are called _contradictory representations of the same non-transient entity_. ([Example ##contradict] describes a use case for this.)
 
@@ -94,13 +94,13 @@ Collections are _the same_ if there is a one-to-one correspondence $f$ between t
 
 This document specifies how a [data aggregation path](#DataAggregationPath) that occurs in a request is evaluated by the service. If such an evaluation fails, the service MUST reject the request.
 
-For a data aggregation path to be a common expression according to [OData-URL, section 5.1.1](#ODataURL), its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection $A$, even if it has arbitrary collection-valued segments itself.
+For a data aggregation path to be a common expression according to [OData-URL, section "Common Expressions"]($$$OData-URL$$$#CommonExpressions), its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection $A$, even if it has arbitrary collection-valued segments itself.
 
 To this end, the following notation is used in the subsequent sections: If $A$ is a collection and $p$ a data aggregation path, optionally followed by a type-cast segment, the result of such a path evaluation is denoted by $\Gamma(A,p)$ and defined as the unordered concatenation, possibly containing repetitions, of the collections $γ(u,p)$ for each $u$ in $A$ that is not null. The function $γ(u,p)$ takes a non-null value and a path as arguments and returns a collection of instances of structured types or primitive values, depending on the type of the final segment of $p$. It is recursively defined as follows:
 1. If $p$ is an empty path, let $B$ be a collection with $u$ as its single member and continue with step 9.
 2. Let $p_1$ be the first segment of $p$ and $p_2$ the remainder, if any, such that $p$ equals the concatenated path $p_1/p_2$.
 3. If $p_1$ is a type-cast segment and $u$ is of its type or a subtype thereof, let $v=u$ and continue with step 8.
-4. If $p_1$ is a type-cast segment and $u$ is not of its type or a subtype thereof, let $B$ be an empty collection and continue with step 9. (This rule follows [OData-URL, section 4.11](#ODataURL) rather than [OData-CSDL, section 14.4.1.1](#ODataCSDL).)
+4. If $p_1$ is a type-cast segment and $u$ is not of its type or a subtype thereof, let $B$ be an empty collection and continue with step 9. (This rule follows [OData-URL, section "Addressing Derived Types"]($$$OData-URL$$$#AddressingDerivedTypes) rather than [OData-CSDL, section "Path Syntax"]($$$OData-CSDLJSON$$$#PathSyntax).)
 5. Otherwise, $p_1$ is a non-type-cast segment. If $u$ does not contain a structural or navigation property $p_1$, let $B$ be an empty collection and continue with step 9.
 6. If $p_1$ is single-valued, let $v$ be the value of the structural or navigation property $p_1$ in $u$. If $v$ is null, let $B$ be an empty collection and continue with step 9; otherwise continue with step 8.
 7. Otherwise, $p_1$ is collection-valued. Let $C$ be the collection addressed by the structural or navigation property $p_1$ in $u$, and let $B=\Gamma(C,p_2)$. Then continue with step 9.
diff --git a/odata-data-aggregation-ext/3.2 Basic Aggregation.md b/odata-data-aggregation-ext/3.2 Basic Aggregation.md
index 893820457..bb7d3962e 100644
--- a/odata-data-aggregation-ext/3.2 Basic Aggregation.md	
+++ b/odata-data-aggregation-ext/3.2 Basic Aggregation.md	
@@ -165,7 +165,7 @@ results in
 
 ##### ##subsubsubsubsec Standard Aggregation Method `countdistinct`
 
-The aggregation method `countdistinct` can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in [OData-URL, section 5.1.1.1.1]($$$OData-URL$$$#Equals).
+The aggregation method `countdistinct` can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in [OData-URL, section "Equals"]($$$OData-URL$$$#Equals).
 
 The result property MUST have type `Edm.Decimal` with `Scale` 0 and sufficient `Precision`.