Check that all serverless docs have prereqs and context attribute

_topic_maps/_topic_map.yml

@@ -550,7 +550,7 @@ Topics:
   - Name: Configuring the OpenShift CLI
     File: configuring-cli
   - Name: Managing CLI profiles
-    File: managing-cli-profiles  
+    File: managing-cli-profiles
   - Name: Extending the OpenShift CLI with plug-ins
     File: extending-cli-plugins
     Distros: openshift-enterprise,openshift-origin
@@ -3162,10 +3162,6 @@ Topics:
     File: about-serverless
   - Name: About OpenShift Serverless Functions
     File: serverless-functions-about
-  - Name: Knative Serving components
-    File: serverless-serving-components
-  - Name: Knative Eventing components
-    File: serverless-eventing-components
   - Name: Event sources
     File: knative-event-sources
   - Name: Channels

modules/about-knative-eventing.adoc

@@ -0,0 +1,25 @@
+// Module included in the following assemblies
+//
+// * /serverless/about-serverless.adoc
+
+:_content-type: CONCEPT
+[id="about-knative-eventing_{context}"]
+= Knative Eventing
+
+Knative Eventing on {product-title} enables developers to use an link:https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture[event-driven architecture] with serverless applications.
+
+An event-driven architecture is based on the concept of decoupled relationships between event producers and event consumers. Event producers create events, and event _sinks_, or consumers, receive events.
+
+Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and sinks. These events conform to the link:https://cloudevents.io[CloudEvents specifications], which enables creating, parsing, sending, and receiving events in any programming language.
+
+Knative Eventing supports the following use cases:
+
+Publish an event without creating a consumer:: You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events.
+
+Consume an event without creating a publisher:: You can use a trigger to consume events from a broker based on event attributes. The application receives events as an HTTP POST.
+
+To enable delivery to multiple types of sinks, Knative Eventing defines the following generic interfaces that can be implemented by multiple Kubernetes resources:
+
+Addressable resources:: Able to receive and acknowledge an event delivered over HTTP to an address defined in the `status.address.url` field of the event. The Kubernetes `Service` resource also satisfies the addressable interface.
+
+Callable resources:: Able to receive an event delivered over HTTP and transform it, returning `0` or `1` new events in the HTTP response payload. These returned events may be further processed in the same way that events from an external event source are processed.

modules/about-knative-serving.adoc

@@ -1,11 +1,22 @@
-:_content-type: ASSEMBLY
-[id="serverless-serving-components"]
-= Knative Serving components
-:context: serverless-serving-components
-include::modules/common-attributes.adoc[]
-include::modules/serverless-document-attributes.adoc[]
+// Module included in the following assemblies
+//
+// * /serverless/about-serverless.adoc
 
-toc::[]
+:_content-type: CONCEPT
+[id="about-knative-serving_{context}"]
+= Knative Serving
+
+Knative Serving on {product-title} enables developers to write link:https://www.redhat.com/en/topics/cloud-native-apps[cloud-native applications] using link:https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless[serverless architecture].
+
+Knative Serving supports deploying and managing cloud-native applications. It provides a set of objects as Kubernetes custom resource definitions (CRDs) that define and control the behavior of serverless workloads on an {product-title} cluster.
+
+Developers use these CRDs to create custom resource (CR) instances that can be used as building blocks to address complex use cases. For example:
+
+* Rapidly deploying serverless containers.
+* Automatically scaling pods.
+
+[id="about-knative-serving-resources_{context}"]
+== Knative Serving resources
 
 Service:: The `service.serving.knative.dev` CRD automatically manages the life cycle of your workload to ensure that the application is deployed and reachable through the network. It creates a route, a configuration, and a new revision for each change to a user created service, or custom resource. Most developer interactions in Knative are carried out by modifying services.
 

modules/serverless-api-versions.adoc

@@ -1,3 +1,8 @@
+// Module included in the following assemblies:
+//
+// * serverless/serverless-release-notes.adoc
+
+:_content-type: CONCEPT
 [id="serverless-api-versions_{context}"]
 = About API versions
 

modules/serverless-deprecated-removed-features.adoc

@@ -1,3 +1,8 @@
+// Module included in the following assemblies:
+//
+// * serverless/serverless-release-notes.adoc
+
+:_content-type: REFERENCE
 [id="serverless-deprecated-removed-features_{context}"]
 = Deprecated and removed features
 

modules/serverless-rn-1-16-0.adoc

@@ -2,6 +2,7 @@
 //
 // * /serverless/serverless-release-notes.adoc
 
+:_content-type: REFERENCE
 [id="serverless-rn-1-16-0_{context}"]
 = Release Notes for Red Hat {ServerlessProductName} 1.16.0
 

modules/serverless-rn-1-17-0.adoc

@@ -2,6 +2,7 @@
 //
 // * /serverless/serverless-release-notes.adoc
 
+:_content-type: REFERENCE
 [id="serverless-rn-1-17-0_{context}"]
 = Release Notes for Red Hat {ServerlessProductName} 1.17.0
 

modules/serverless-rn-1-18-0.adoc

@@ -2,6 +2,7 @@
 //
 // * /serverless/serverless-release-notes.adoc
 
+:_content-type: REFERENCE
 [id="serverless-rn-1-18-0_{context}"]
 = Release Notes for Red Hat {ServerlessProductName} 1.18.0
 

modules/serverless-rn-1-19-0.adoc

@@ -2,6 +2,7 @@
 //
 // * /serverless/serverless-release-notes.adoc
 
+:_content-type: REFERENCE
 [id="serverless-rn-1-19-0_{context}"]
 = Release Notes for Red Hat {ServerlessProductName} 1.19.0
 

modules/serverless-rn-1-20-0.adoc

@@ -2,6 +2,7 @@
 //
 // * /serverless/serverless-release-notes.adoc
 
+:_content-type: REFERENCE
 [id="serverless-rn-1-20-0_{context}"]
 = Release Notes for Red Hat {ServerlessProductName} 1.20.0
 

modules/serverless-rn-template-module.adoc

@@ -2,6 +2,7 @@
 //
 // * /serverless/serverless-release-notes.adoc
 
+:_content-type: REFERENCE
 [id="serverless-rn-<version>_{context}"]
 = Release Notes for Red Hat {ServerlessProductName} <version>
 // add a version, e.g. 1.20.0

serverless/discover/about-serverless.adoc

@@ -18,32 +18,16 @@ Developers on {ServerlessProductName} can use the provided Kubernetes native API
 
 The set of supported features, configurations, and integrations for {ServerlessProductName}, current and past versions, are available at the link:https://access.redhat.com/articles/4912821[Supported Configurations page].
 
-[id="about-serverless-serving"]
-== Knative Serving
+// Knative Serving
+include::modules/about-knative-serving.adoc[leveloffset=+1]
 
-Knative Serving on {product-title} enables developers to write link:https://www.redhat.com/en/topics/cloud-native-apps[cloud-native applications] using link:https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless[serverless architecture].
+// Knative Eventing
+include::modules/about-knative-eventing.adoc[leveloffset=+1]
 
-Knative Serving supports deploying and managing cloud-native applications. It provides a set of objects as Kubernetes custom resource definitions (CRDs) that define and control the behavior of serverless workloads on an {product-title} cluster.
+You can propagate an event from an xref:../../serverless/discover/knative-event-sources.adoc#knative-event-sources[event source] to multiple event sinks by using:
 
-Developers use these CRDs to create custom resource (CR) instances that can be used as building blocks to address complex use cases. For example:
-
-* Rapidly deploying serverless containers.
-* Automatically scaling pods.
-
-[id="about-serverless-eventing"]
-== Knative Eventing
-
-Knative Eventing on {product-title} enables developers to use an link:https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture[event-driven architecture] with serverless applications.
-
-An event-driven architecture is based on the concept of decoupled relationships between event producers and event consumers. Event producers create events, and event  xref:../../serverless/develop/serverless-event-sinks.adoc#serverless-event-sinks[_sinks_], or consumers, receive events.
-
-Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and sinks. These events conform to the link:https://cloudevents.io[CloudEvents specifications], which enables creating, parsing, sending, and receiving events in any programming language.
-
-Knative Eventing supports the following use cases:
-
-Publish an event without creating a consumer:: You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events.
-
-Consume an event without creating a publisher:: You can use a trigger to consume events from a broker based on event attributes. The application receives events as an HTTP POST.
+* xref:../../serverless/discover/serverless-channels.adoc#serverless-channels[channels] and subscriptions, or
+* xref:../../serverless/develop/serverless-using-brokers.adoc#serverless-using-brokers[brokers] and xref:../../serverless/develop/serverless-triggers.adoc#serverless-triggers[triggers].
 
 [id="additional-resources_about-serverless"]
 == Additional resources

serverless/discover/serverless-eventing-components.adoc

@@ -1,19 +0,0 @@
-:_content-type: ASSEMBLY
-[id="serverless-eventing-components"]
-= Knative Eventing components
-include::modules/common-attributes.adoc[]
-include::modules/serverless-document-attributes.adoc[]
-:context: serverless-eventing-components
-
-toc::[]
-
-To enable delivery to multiple types of sinks, Knative Eventing defines the following generic interfaces that can be implemented by multiple Kubernetes resources:
-
-Addressable resources:: Able to receive and acknowledge an event delivered over HTTP to an address defined in the `status.address.url` field of the event. The Kubernetes `Service` resource also satisfies the addressable interface.
-
-Callable resources:: Able to receive an event delivered over HTTP and transform it, returning `0` or `1` new events in the HTTP response payload. These returned events may be further processed in the same way that events from an external event source are processed.
-
-You can propagate an event from an xref:../../serverless/discover/knative-event-sources.adoc#knative-event-sources[event source] to multiple event sinks by using:
-
-* xref:../../serverless/discover/serverless-channels.adoc#serverless-channels[channels] and subscriptions, or
-* xref:../../serverless/develop/serverless-using-brokers.adoc#serverless-using-brokers[brokers] and xref:../../serverless/develop/serverless-triggers.adoc#serverless-triggers[triggers].

serverless/serverless-getting-started.adoc

@@ -1,8 +1,8 @@
 :_content-type: ASSEMBLY
-include::modules/serverless-document-attributes.adoc[]
 [id="serverless-getting-started"]
 = Getting started with {ServerlessProductName}
 :context: serverless-getting-started
 include::modules/common-attributes.adoc[]
+include::modules/serverless-document-attributes.adoc[]
 
 toc::[]

serverless/serverless-release-notes.adoc

@@ -1,9 +1,9 @@
 :_content-type: ASSEMBLY
-include::modules/serverless-document-attributes.adoc[]
 [id="serverless-release-notes"]
 = {ServerlessProductName} Release Notes
 :context: serverless-release-notes
 include::modules/common-attributes.adoc[]
+include::modules/serverless-document-attributes.adoc[]
 
 toc::[]