Fix broken anchors (#1290)

modules/ROOT/pages/appendix/gql-conformance/additional-cypher.adoc

@@ -72,10 +72,10 @@ Either the pattern already exists, or it needs to be created.
 | xref:expressions/list-expressions.adoc#list-comprehension[List comprehension]
 | Syntactic construct for creating a `LIST` based on existing lists.
 
-| xref:values-and-types/maps.adoc#cypher-map-comprehension[Map projection]
+| xref:expressions/map-expressions.adoc#map-projection[Map projection]
 | Constructs `MAP` projections from nodes, relationships, and other `MAP` values.
 
-| xref:values-and-types/lists.adoc#cypher-pattern-comprehension[Pattern comprehension]
+| xref:expressions/list-expressions.adoc#pattern-comprehension[Pattern comprehension]
 | Syntactic construct for creating a `LIST` based on matchings of a pattern.
 |===
 
@@ -389,12 +389,12 @@ It is only supported in the xref:clauses/use.adoc[`USE`] clause.
 | xref:functions/spatial.adoc#functions-point[`point()`]
 | Returns a 2D or 3D point object, given two or respectively three coordinate values in the Cartesian coordinate system or WGS 84 geographic coordinate system.
 
-| xref:functions/spatial.adoc#functions-point-distance[`point.distance()`]
+| xref:functions/spatial.adoc#functions-distance[`point.distance()`]
 | Returns a `FLOAT` representing the distance between any two points in the same CRS.
 If the points are in the WGS 84 CRS, the function returns the geodesic distance (i.e., the shortest path along the curved surface of the Earth).
 If the points are in a Cartesian CRS, the function returns the Euclidean distance (i.e., the shortest straight-line distance in a flat, planar space).
 
-| xref:functions/spatial.adoc#functions-point-withinBBox[`point.withinBBox()`]
+| xref:functions/spatial.adoc#functions-withinBBox[`point.withinBBox()`]
 | Returns true if the provided point is within the bounding box defined by the two provided points.
 
 |===

modules/ROOT/pages/appendix/gql-conformance/index.adoc

@@ -47,4 +47,4 @@ For more information, see xref:syntax/parsing.adoc#_using_unicodes_in_cypher[Par
 * Cypher supports the following mandatory GQL property types: `BOOLEAN` (`BOOL`), `FLOAT` footnote:[The `FLOAT` type in Cypher always represents a 64-bit double-precision floating point number.], `INTEGER` (`SIGNED INTEGER`, or `INT`)footnote:[The `INTEGER` type in Cypher always represents a 64-bit `INTEGER`.], and `STRING` (`VARCHAR`).
 +
 Cypher also supports the following optional GQL property types: `DATE`, `DURATION`, `LIST<INNER_TYPE NOT NULL>` (`ARRAY<INNER_TYPE NOT NULL>`, `INNER_TYPE LIST`, or `INNER_TYPE ARRAY`)footnote:[The `INNER_TYPE` cannot be a `LIST` type.], `LOCAL DATETIME` (`TIMESTAMP WITHOUT TIME ZONE`), `LOCAL TIME` (`TIME WITHOUT TIME ZONE`), `POINT`, `ZONED DATETIME` (`TIME WITH TIME ZONE`), and `ZONED TIME` (`TIMESTAMP WITH TIME ZONE`).
-For more information, see xref:values-and-types/property-structural-constructed.adoc#_property_types[Values and types -> property types].
+For more information, see xref:values-and-types/property-structural-constructed.adoc#property-types[Values and types -> property types].

modules/ROOT/pages/appendix/gql-conformance/supported-mandatory.adoc

@@ -18,12 +18,12 @@ The below table is instead listed in order of their appearance in the link:https
 
 | 4.13
 | GQL object types
-| xref:values-and-types/property-structural-constructed.adoc#structural-types[Structural types],  xref:values-and-types/property-structural-constructed.adoc#type-synonyms[Types and their synonyms].
+| xref:values-and-types/property-structural-constructed.adoc#structural-types[Structural types],  xref:values-and-types/property-structural-constructed.adoc#types-synonyms[Types and their synonyms].
 | Includes: `NODE` (`ANY NODE`, `VERTEX`, `ANY VERTEX`) and `RELATIONSHIP` (`ANY RELATIONSHIP`, `EDGE`, `ANY EDGE`).
 
 | 4.16
 | Predefined value types
-| xref:values-and-types/property-structural-constructed.adoc#property-types[Property types], xref:values-and-types/property-structural-constructed.adoc#type-synonyms[Types and their synonyms].
+| xref:values-and-types/property-structural-constructed.adoc#property-types[Property types], xref:values-and-types/property-structural-constructed.adoc#types-synonyms[Types and their synonyms].
 | Includes: `BOOLEAN` (`BOOL`), `FLOAT`, `INTEGER` (`SIGNED INTEGER`, `INT`), and `STRING` (`VARCHAR`).
 
 Cypher supports the boolean type predicate for `true`, `false`, and `null` but does not support the GQL keyword `UNKNOWN`.
@@ -122,7 +122,7 @@ The only way to guarantee row order in Neo4j is to use xref:clauses/order-by.ado
 
 | 16.17
 | <sort specification list>
-| xref:clauses/order-by.adoc#order-nodes-in-descending-order[Order results in ascending or descending order]
+| xref:clauses/order-by.adoc#ascending-descending-order[Ascending and descending order]
 |
 
 | 16.19
@@ -137,7 +137,7 @@ The only way to guarantee row order in Neo4j is to use xref:clauses/order-by.ado
 
 | 19.4
 | <exists predicate>
-| xref:functions/predicate.adoc#function-exists[`exists()`]
+| xref:functions/predicate.adoc#functions-exists[`exists()`]
 |
 
 | 19.5
@@ -173,7 +173,7 @@ In Cypher, current user details can be seen using the link:{neo4j-docs-base-uri}
 
 | 20.9
 | <aggregate function>
-| xref:functions/aggregating.adoc#functions-avg[`avg()`], xref:functions/aggregating.adoc#functions-count[`count()`], xref:functions/aggregating.adoc#functions-max[`max`], xref:functions/aggregating.adoc#functions-mind[`min()`], xref:functions/aggregating.adoc#functions-sum[`sum()`]
+| xref:functions/aggregating.adoc#functions-avg[`avg()`], xref:functions/aggregating.adoc#functions-count[`count()`], xref:functions/aggregating.adoc#functions-max[`max`], xref:functions/aggregating.adoc#functions-min[`min()`], xref:functions/aggregating.adoc#functions-sum[`sum()`]
 | Cypher and GQL handle `null` values differently for the `sum()` function when queries return 0 rows. 
 For example, `RETURN sum(<expr>)` on an empty table returns `null` in GQL, but in Cypher it returns `0`.
 

modules/ROOT/pages/clauses/clause-composition.adoc

@@ -974,7 +974,7 @@ materialize the table of intermediate results before executing the next clause.
 This approach would consume a lot of memory for materializing the tables of intermediate results and would generally not perform well.
 
 Instead, Cypher will in general try to interleave the execution of clauses.
-This is called xref::planning-and-tuning/execution-plans.adoc#laze-eager-evaluation[lazy evaluation].
+This is called xref::planning-and-tuning/execution-plans.adoc#lazy-eager-evaluation[lazy evaluation].
 It only materializes intermediate results when needed.
 In many read-write queries it is unproblematic to execute clauses interleaved, but when it is not,
 Cypher must ensure that the table of intermediate results gets materialized at the right time(s).

modules/ROOT/pages/clauses/index.adoc

@@ -275,7 +275,7 @@ These comprise clauses to create, show, and drop indexes and constraints.
 |===
 | Clause | Description
 
-m| xref:indexes/search-performance-indexes/managing-indexes.adoc#indexes-syntax[CREATE \| SHOW  \| DROP INDEX]
+m| xref:indexes/syntax.adoc[CREATE \| SHOW  \| DROP INDEX]
 | Create, show or drop an index.
 
 m| xref::constraints/syntax.adoc[CREATE \| SHOW \| DROP CONSTRAINT]

modules/ROOT/pages/clauses/match.adoc

@@ -147,7 +147,7 @@ For a list of all label expressions supported by Cypher, see xref:patterns/refer
 
 The `MATCH` clause allows you to specify relationship patterns of varying complexity to retrieve from a graph.
 Unlike a node pattern, a relationship pattern cannot be used in a `MATCH` clause without node patterns at both ends.
-For more information about relationship patterns, see xref:patterns/fixed-length-patterns#relationship patterns[Patterns -> Relationship patterns].
+For more information about relationship patterns, see xref:patterns/fixed-length-patterns#relationship-patterns[Patterns -> Relationship patterns].
 
 [NOTE]
 Relationships will only be matched once inside a single pattern.

modules/ROOT/pages/clauses/merge.adoc

@@ -422,7 +422,7 @@ Instead, a new `Movie` node is created.
 === Merge on an undirected relationship
 
 `MERGE` can also be used without specifying the direction of a relationship.
-Cypher will first try to xref:clauses/match.adoc#_match_on_an_undirected_relationship[match the relationship in both directions].
+Cypher will first try to match the relationship in both directions.
 If the relationship does not exist in either direction, it will create one left to right.
 
 .Query

modules/ROOT/pages/constraints/syntax.adoc

@@ -137,7 +137,7 @@ Where `<TYPE>` is one of the following property types:
 
 Allowed syntax variations of these types are listed in  xref::values-and-types/property-structural-constructed.adoc#types-synonyms[Types and their synonyms].
 
-For examples on how to create property type constraints, see  xref:constraints/managing-constraints.adoc#create-property-type-constraint[Create, show, and drop constraints -> Create property type constraints].
+For examples on how to create property type constraints, see  xref:constraints/managing-constraints.adoc#create-property-type-constraints[Create, show, and drop constraints -> Create property type constraints].
 
 
 [role=label--enterprise-edition]

modules/ROOT/pages/deprecations-additions-removals-compatibility.adoc

@@ -814,7 +814,7 @@ label:new[]
 SET n:$(label)
 REMOVE n:$(label)
 ----
-| Added the ability to dynamically reference labels in xref:clauses/set.adoc#set-set-a-dynamic-label-on-a-node[SET] and xref:clauses/remove.adoc#remove-remove-a-label-dynamically-from-a-node[REMOVE] clauses.
+| Added the ability to dynamically reference labels in xref:clauses/set.adoc#dynamic-set-node-label[SET] and xref:clauses/remove.adoc#dynamic-remove-node-label[REMOVE] clauses.
 
 a|
 label:functionality[]
@@ -1400,7 +1400,7 @@ IS [NOT] [NFC \| NFD \| NFKC \| NFKD] NORMALIZED
 RETURN "string" IS NORMALIZED
 ----
 
-| Introduction of an xref::expressions/predicates/string-operators.adoc#string-normalization-operator[IS NORMALIZED] operator.
+| Introduction of an xref::expressions/predicates/string-operators.adoc#string-normalization-operators[IS NORMALIZED] operator.
 The operator can be used to check if a `STRING` is normalized according to the specified normalization form, which can be of type `NFC`, `NFD`, `NFKC`, or `NFKD`.
 
 a|
@@ -1553,7 +1553,7 @@ label:updated[]
 SHOW VECTOR INDEXES
 ----
 
-| Extended xref:indexes/search-performance-indexes/managing-indexes.adoc#indexes-list-indexes[`SHOW INDEXES`] with easy filtering for vector indexes.
+| Extended xref:indexes/semantic-indexes/vector-indexes.adoc#show-vector-indexes[`SHOW INDEXES`] with easy filtering for vector indexes.
 This is equivalent to `SHOW INDEXES WHERE type = 'VECTOR'`.
 
 a|
@@ -2260,7 +2260,7 @@ CREATE CONSTRAINT name FOR ()-[r:TYPE]-() REQUIRE r.prop IS RELATIONSHIP KEY
 ----
 a|
 
-Added relationship xref:constraints/managing-constraints.adoc#create-key-constraint[key] and xref:constraints/managing-constraints.adoc#create--property-uniqueness-constraint[property uniqueness] constraints.
+Added relationship xref:constraints/managing-constraints.adoc#create-key-constraints[key] and xref:constraints/managing-constraints.adoc#create-property-uniqueness-constraints[property uniqueness] constraints.
 
 a|
 label:functionality[]

modules/ROOT/pages/expressions/map-expressions.adoc

@@ -297,7 +297,7 @@ RETURN map{.a, .c} AS projectedMap
 1+d|Rows: 1
 |===
 
-In the below query, a map projection with property selectors is used to xref:functions/list.adoc#functions-collect[`collect`] only the `title` and `release` year of each movie. 
+In the below query, a map projection with property selectors is used to xref:functions/aggregating.adoc#functions-collect[`collect`] only the `title` and `release` year of each movie. 
 
 .Map projection with a key selector
 [source, cypher]

modules/ROOT/pages/expressions/string-operators.adoc

@@ -151,7 +151,7 @@ RETURN reduce(acc = '', item IN list| acc || item) AS result
 1+d| Rows: 1
 |===
 
-The following query uses the xref:functions/scalar.adoc#functions-head[`head()`] function to start the accumulator with the first `item` in the `list`, while the xref:functions/scalar.adoc#functions-tail[`tail()`] function returns the remaining items in the `list`.
+The following query uses the xref:functions/scalar.adoc#functions-head[`head()`] function to start the accumulator with the first `item` in the `list`, while the xref:functions/list.adoc#functions-tail[`tail()`] function returns the remaining items in the `list`.
 The `reduce()` function then concatenates these items with commas.
 
 .Add prefix and a separator (`,`) in a `STRING` concatenated from `STRING` values in a `LIST`

modules/ROOT/pages/functions/index.adoc

@@ -591,7 +591,7 @@ These functions are used to specify 2D or 3D points in a geographic or cartesian
 |===
 | Function | Signature | Description
 
-1.1+| xref::functions/spatial.adoc#functions-point-cartesian-2d[`point()`]
+1.1+| xref::functions/spatial.adoc#functions-point[`point()`]
 | `point(input :: MAP) :: POINT`
 |  Returns a 2D or 3D point object, given two or respectively three coordinate values in the Cartesian coordinate system or WGS 84 geographic coordinate system.
 
@@ -617,7 +617,7 @@ If the points are in a Cartesian CRS, the function returns the Euclidean distanc
 |===
 | Function | Signature | Description
 
-1.1+| xref::functions/temporal/duration.adoc#functions-duration[`duration()`]
+1.1+| xref::functions/temporal/duration.adoc#functions-durations[`duration()`]
 | `duration(input :: ANY) :: DURATION`
 | Constructs a `DURATION` value.
 
@@ -672,11 +672,11 @@ Values of the xref::values-and-types/temporal.adoc[temporal types] -- `DATE`, `Z
 | `datetime(input = DEFAULT_TEMPORAL_ARGUMENT :: ANY) :: ZONED DATETIME`
 | Creates a `ZONED DATETIME` instant.
 
-1.1+| xref::functions/temporal/index.adoc#functions-datetime-timestamp[`datetime.fromEpoch()`]
+1.1+| xref::functions/temporal/index.adoc#functions-datetime-fromepoch[`datetime.fromEpoch()`]
 | `datetime.fromEpoch(seconds :: INTEGER \| FLOAT, nanoseconds :: INTEGER \| FLOAT) :: ZONED DATETIME`
 | Creates a `ZONED DATETIME` given the seconds and nanoseconds since the start of the epoch.
 
-1.1+| xref::functions/temporal/index.adoc#functions-datetime-timestamp[`datetime.fromEpochMillis()`]
+1.1+| xref::functions/temporal/index.adoc#functions-datetime-fromepochmillis[`datetime.fromEpochMillis()`]
 | `datetime.fromEpochMillis(milliseconds :: INTEGER \| FLOAT) :: ZONED DATETIME`
 | Creates a `ZONED DATETIME` given the milliseconds since the start of the epoch.
 

modules/ROOT/pages/functions/list.adoc

@@ -345,7 +345,7 @@ A `LIST<RELATIONSHIP>` containing all the `RELATIONSHIP` values in the `PATH` `p
 |===
 
 | Any `null` element in `original` is preserved.
-| See also xref:functions/string.adoc#functions-reverse[String functions -> reverse].
+| See also xref:functions/string.adoc#functions-reverse[String functions -> `reverse()`].
 
 |===
 

modules/ROOT/pages/functions/string.adoc

@@ -401,7 +401,7 @@ RETURN replace("hello", "l", "w", 1)
 |===
 
 | `reverse(null)` returns `null`.
-| See also xref:functions/list.adoc#functions-reverse[List functions -> reverse].
+| See also xref:functions/list.adoc#functions-reverse-list[List functions -> `reverse()`].
 
 |===
 

modules/ROOT/pages/functions/vector.adoc

@@ -32,7 +32,7 @@ For more details, see the {link-vector-indexes}#similarity-functions[vector inde
 | `vector.similarity.cosine(null, b)` returns `null`.
 | `vector.similarity.cosine(a, null)` returns `null`.
 | Both vectors must be of the same dimension.
-| Both vectors must be {link-vector-indexes}#indexes-vector-similarity-cosine[*valid*] with respect to cosine similarity.
+| Both vectors must be {link-vector-indexes}#similarity-functions[*valid*] with respect to cosine similarity.
 | The implementation is identical to that of the latest available vector index provider (`vector-2.0`).
 | `vector.similarity.cosine()` returns the neighborhood of nodes along with their respective cosine similarity scores, sorted in descending order of similarity.
 The similarity score range from `0` and `1`, with scores closer to `1` indicating a higher degree of similarity between the indexed vector and the query vector.
@@ -62,7 +62,7 @@ For more details, see the {link-vector-indexes}#similarity-functions[vector inde
 | `vector.similarity.euclidean(null, b)` returns `null`.
 | `vector.similarity.euclidean(a, null)` returns `null`.
 | Both vectors must be of the same dimension.
-| Both vectors must be {link-vector-indexes}#indexes-vector-similarity-euclidean[*valid*] with respect to Euclidean similarity.
+| Both vectors must be {link-vector-indexes}#similarity-functions[*valid*] with respect to Euclidean similarity.
 | The implementation is identical to that of the latest available vector index provider (`vector-2.0`).
 | `vector.similarity.euclidean()` returns the neighborhood of nodes along with their respective Euclidean similarity scores, sorted in descending order of similarity.
 The similarity score range from `0` and `1`, with scores closer to `1` indicating a higher degree of similarity between the indexed vector and the query vector.

modules/ROOT/pages/indexes/search-performance-indexes/managing-indexes.adoc

@@ -417,7 +417,7 @@ point.distance(n.prop, center) < = distance
 |===
 
 The above set of predicates can be extended with the use of type constraints.
-See xref:indexes/search-performance-indexes/using-indexes.adoc#index-compatibility-type-constraints[Index compatibility and type constraints] for more information.
+See xref:indexes/search-performance-indexes/using-indexes.adoc#type-constraints[The impact of indexes on query performances -> Property type constraints] for more information.
 
 [TIP]
 To learn more about the spatial data types supported by Cypher, see the page about xref:values-and-types/spatial.adoc[Spatial values].

modules/ROOT/pages/indexes/syntax.adoc

@@ -290,7 +290,7 @@ CALL db.index.vector.queryRelationships(indexName :: STRING, numberOfNearestNeig
 The `numberOfNearestNeighbours` refers to the number of nearest neighbors to return as the neighborhood.
 The `query` vector refers to the `LIST<FLOAT>` in which to search for the neighborhood.
 
-For more information, see xref:indexes/semantic-indexes/vector-indexes.adoc#indexes-vector-query[Vector indexes - Query vector indexes].
+For more information, see xref:indexes/semantic-indexes/vector-indexes.adoc#query-vector-index[Vector indexes - Query vector indexes].
 
 [[drop-index]]
 == DROP INDEX

modules/ROOT/pages/patterns/non-linear-patterns.adoc

@@ -3,6 +3,7 @@
 
 Cypher can be used to express non-linear patterns, either by equijoins (an operation in which more than one node relationship in a path is the same) or by more complicated graph patterns consisting of multiple path patterns.
 
+[[equijoins]]
 == Equijoins
 
 An equijoin is an operation on paths that requires more than one of the nodes or relationships of the paths to be the same.

modules/ROOT/pages/planning-and-tuning/execution-plans.adoc

@@ -54,7 +54,7 @@ CREATE (pmr:Station {name: 'Peckham Rye'}),
   (s7)-[:NEXT {distance: 1.4}]->(s6)
 ----
 
-The example query uses a xref:patterns/variable-length-patterns.adoc#quantified-path-pattern[quantified path pattern] to count the number of possible path patterns between the start `Station`, `Denmark Hill`, and the end `Station`, `Clapham Junction`:
+The example query uses a xref:patterns/variable-length-patterns.adoc#quantified-path-patterns[quantified path pattern] to count the number of possible path patterns between the start `Station`, `Denmark Hill`, and the end `Station`, `Clapham Junction`:
 
 .Query
 [source, cypher]

modules/ROOT/pages/planning-and-tuning/operators/index.adoc

@@ -338,7 +338,7 @@ Tests for the presence of a pattern predicate in queries containing multiple pat
 |
 |
 
-| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-node-by-element-id-seek[NodeByElementIdSeek]
+| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-node-by-elementid-seek[NodeByElementIdSeek]
 | Reads one or more nodes by id from the node store, specified via the function xref::functions/scalar.adoc#functions-elementid[elementId()].
 | label:yes[]
 |
@@ -926,7 +926,7 @@ As the direction is unspecified, two rows are produced for each relationship as
 |
 |
 
-| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-varlength-expand-pruning-bfs[VarLengthExpand(Pruning,BFS)]
+| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-breadth-first-varlength-expand-pruning-bfs-all[VarLengthExpand(Pruning,BFS)]
 | Traverses variable-length relationships from a given node and only returns unique end nodes.
 |
 |

modules/ROOT/pages/subqueries/collect.adoc

@@ -31,7 +31,7 @@ CREATE
 == Simple `COLLECT` subquery
 
 Variables introduced by the outside scope can be used in the `COLLECT` subquery without importing them.
-In this regard, `COLLECT` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#call-importing-variables[which do require importing].
+In this regard, `COLLECT` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#import-variables[which do require importing].
 The following query exemplifies this and outputs the owners of the dog named `Ozzy`:
 
 [source, cypher]