Fix broken internal xref links in reference docs

framework-docs/modules/ROOT/pages/core/aop/schema.adoc

@@ -10,7 +10,7 @@ of advice parameters.
 
 To use the aop namespace tags described in this section, you need to import the
 `spring-aop` schema, as described in xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration]
-. See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema]
+. See xref:core/appendix/xsd-schemas.adoc#xsd-schemas-aop[the AOP schema]
 for how to import the tags in the `aop` namespace.
 
 Within your Spring configurations, all aspect and advisor elements must be placed within

framework-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc

@@ -14,11 +14,11 @@ Spring distribution, you should first read the previous section on xref:core/app
 
 To create new XML configuration extensions:
 
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-schema[Author] an XML schema to describe your custom element(s).
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-namespacehandler[Code] a custom `NamespaceHandler` implementation.
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-parser[Code] one or more `BeanDefinitionParser` implementations
+. xref:core/appendix/xml-custom.adoc#xsd-custom-schema[Author] an XML schema to describe your custom element(s).
+. xref:core/appendix/xml-custom.adoc#xsd-custom-namespacehandler[Code] a custom `NamespaceHandler` implementation.
+. xref:core/appendix/xml-custom.adoc#xsd-custom-parser[Code] one or more `BeanDefinitionParser` implementations
   (this is where the real work is done).
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-registration[Register] your new artifacts with Spring.
+. xref:core/appendix/xml-custom.adoc#xsd-custom-registration[Register] your new artifacts with Spring.
 
 For a unified example, we create an
 XML extension (a custom XML element) that lets us configure objects of the type
@@ -553,7 +553,7 @@ Kotlin::
 
 This works nicely, but it exposes a lot of Spring plumbing to the end user. What we are
 going to do is write a custom extension that hides away all of this Spring plumbing.
-If we stick to xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-introduction[the steps described previously], we start off
+If we stick to xref:core/appendix/xml-custom.adoc#xsd-custom-introduction[the steps described previously], we start off
 by creating the XSD schema to define the structure of our custom tag, as the following
 listing shows:
 
@@ -580,7 +580,7 @@ listing shows:
 	</xsd:schema>
 ----
 
-Again following xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-introduction[the process described earlier],
+Again following xref:core/appendix/xml-custom.adoc#xsd-custom-introduction[the process described earlier],
 we then create a custom `NamespaceHandler`:
 
 [tabs]

framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc

@@ -179,7 +179,7 @@ infrastructure.
 
 NOTE: The preceding definition of the `dataSource` bean uses the `<jndi-lookup/>` tag
 from the `jee` namespace. For more information see
-xref:integration/appendix.adoc#xsd-schemas-jee[The JEE Schema].
+xref:integration/appendix.adoc#appendix.xsd-schemas-jee[The JEE Schema].
 
 NOTE: If you use JTA, your transaction manager definition should look the same, regardless
 of what data access technology you use, be it JDBC, Hibernate JPA, or any other supported

framework-docs/modules/ROOT/pages/testing/resttestclient.adoc

@@ -139,8 +139,8 @@ xref:integration/rest-clients.adoc#rest-restclient[`RestClient`] and `RestTestCl
 the same API up to the point of the call to `exchange()`. After that, `RestTestClient`
 provides two alternative ways to verify the response:
 
-1. xref:resttestclient-workflow[Built-in Assertions] extend the request workflow with a chain of expectations
-2. xref:resttestclient-assertj[AssertJ Integration] to verify the response via `assertThat()` statements
+1. xref:testing/resttestclient.adoc#resttestclient.workflow[Built-in Assertions] extend the request workflow with a chain of expectations
+2. xref:testing/resttestclient.adoc#resttestclient.assertj[AssertJ Integration] to verify the response via `assertThat()` statements
 
 
 
@@ -164,7 +164,7 @@ include-code::./RestClientWorkflowTests[tag=soft-assertions,indent=0]
 You can then choose to decode the response body through one of the following:
 
 * `expectBody(Class<T>)`: Decode to single object.
-* `expectBody()`: Decode to `byte[]` for xref:testing/resttestclient.adoc#resttestclient-json[JSON Content] or an empty body.
+* `expectBody()`: Decode to `byte[]` for xref:testing/resttestclient.adoc#resttestclient.json[JSON Content] or an empty body.
 
 
 If the built-in assertions are insufficient, you can consume the object instead and

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc

@@ -2,7 +2,7 @@
 = Context Configuration with Groovy Scripts
 
 To load an `ApplicationContext` for your tests by using Groovy scripts that use the
-xref:core/beans/basics.adoc#beans-factory-groovy[Groovy Bean Definition DSL], you can annotate
+xref:languages/groovy.adoc#beans-factory-groovy[Groovy Bean Definition DSL], you can annotate
 your test class with `@ContextConfiguration` and configure the `locations` or `value`
 attribute with an array that contains the resource locations of Groovy scripts. Resource
 lookup semantics for Groovy scripts are the same as those described for

framework-docs/modules/ROOT/pages/web/webflux/config.adoc

@@ -659,7 +659,7 @@ whether to decode the request path nor whether to remove semicolon content for
 path matching purposes.
 
 Spring WebFlux also does not support suffix pattern matching, unlike in Spring MVC, where we
-are also xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-suffix-pattern-match[recommend] moving away from
+are also xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[recommend] moving away from
 reliance on it.
 ====
 

framework-docs/modules/ROOT/pages/web/webmvc-test.adoc

@@ -1,6 +1,6 @@
 [[test]]
 = Testing
-[.small]#xref:web-reactive.adoc#webflux-test[See equivalent in the Reactive stack]#
+[.small]#xref:web/webflux-test.adoc[See equivalent in the Reactive stack]#
 
 This section summarizes the options available in `spring-test` for Spring MVC applications.
 

framework-docs/modules/ROOT/pages/web/webmvc/mvc-config/content-negotiation.adoc

@@ -10,8 +10,7 @@ By default, only the `Accept` header is checked.
 
 If you must use URL-based content type resolution, consider using the query parameter
 strategy over path extensions. See
-xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-suffix-pattern-match[Suffix Match]
-and xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[Suffix Match and RFD] for
+xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[Suffix Match and RFD] for
 more details.
 
 You can customize requested content type resolution, as the following example shows: