CAMEL-20410: documentation fixes for base files

docs/components/modules/ROOT/partials/component-configure-options.adoc

@@ -8,28 +8,36 @@ Camel components are configured on two separate levels:
 
 === Configuring Component Options
 
-The component level is the highest level which holds general and common configurations that are inherited by the endpoints.
-For example a component may have security settings, credentials for authentication, urls for network connection and so forth.
+At the component level, you set general and shared configurations that are, then, inherited by the endpoints. It is the highest configuration level.
 
-Some components only have a few options, and others may have many. Because components typically have pre configured defaults
-that are commonly used, then you may often only need to configure a few options on a component; or none at all.
+For example, a component may have security settings, credentials for authentication, urls for network connection and so forth.
 
-Configuring components can be done with the xref:manual::component-dsl.adoc[Component DSL],
-in a configuration file (application.properties|yaml), or directly with Java code.
+Some components only have a few options, and others may have many.
+Because components typically have pre-configured defaults that are commonly used, then you may often only need to configure a few options on a component; or none at all.
+
+You can configure components using:
+
+* the xref:manual::component-dsl.adoc[Component DSL].
+* in a configuration file (`application.properties`, `*.yaml` files, etc).
+* directly in the Java code.
 
 === Configuring Endpoint Options
 
-Where you find yourself configuring the most is on endpoints, as endpoints often have many options, which allows you to
-configure what you need the endpoint to do. The options are also categorized into whether the endpoint is used as consumer (from)
-or as a producer (to), or used for both.
+You usually spend more time setting up endpoints because they have many options.
+These options help you customize what you want the endpoint to do.
+The options are also categorized into whether the endpoint is used as a consumer (_from_), as a producer (_to_), or  both.
 
-Configuring endpoints is most often done directly in the endpoint URI as path and query parameters. You can also use
-the xref:manual::Endpoint-dsl.adoc[Endpoint DSL] and xref:manual::dataformat-dsl.adoc[DataFormat DSL]
+Configuring endpoints is most often done directly in the endpoint URI as _path_ and _query_ parameters.
+You can also use the xref:manual::Endpoint-dsl.adoc[Endpoint DSL] and xref:manual::dataformat-dsl.adoc[DataFormat DSL]
 as a _type safe_ way of configuring endpoints and data formats in Java.
 
-A good practice when configuring options is to use xref:manual::using-propertyplaceholder.adoc[Property Placeholders],
-which allows to not hardcode urls, port numbers, sensitive information, and other settings.
-In other words placeholders allows to externalize the configuration from your code, and gives more flexibility and reuse.
+A good practice when configuring options is to use xref:manual::using-propertyplaceholder.adoc[Property Placeholders].
+
+Property placeholders provide a few benefits:
+
+* They help prevent using hardcoded urls, port numbers, sensitive information, and other settings.
+* They allow externalizing the configuration from the code.
+* They help the code to become more flexible and reusable.
 
-The following two sections lists all the options, firstly for the component followed by the endpoint.
+The following two sections list all the options, firstly for the component followed by the endpoint.
 // component-configure options: END

docs/components/modules/ROOT/partials/component-endpoint-options.adoc

@@ -32,7 +32,7 @@ The {doctitle} endpoint is configured using URI syntax:
 {syntax}
 ----
 
-with the following path and query parameters:
+With the following _path_ and _query_ parameters:
 
 === Path Parameters ({pathparametercount} parameters)
 
@@ -54,7 +54,7 @@ endif::[]
 === Query Parameters ({queryparametercount} parameters)
 
 ifeval::[{queryparametercount} == 0]
-The {doctitle} endpoint has no query parameters.
+The {doctitle} endpoint has no _query_ parameters.
 endif::[]
 
 ifeval::[{queryparametercount} != 0]
@@ -70,7 +70,7 @@ ifeval::[{apicount} != 0]
 
 == API Parameters ({apicount} APIs)
 
-The {doctitle} endpoint is an API based component and has additional parameters based on which API name and API method is used.
+The {doctitle} endpoint is an API-based component and has additional parameters based on which API name and API method is used.
 The API name and API method is located in the endpoint URI as the `{apiSyntax}` path parameters:
 
 [subs='+attributes']
@@ -110,8 +110,8 @@ The {apiname} API is defined in the syntax as follows:
 {scheme}:{apiname}/methodName?[parameters]
 ------
 
-The {methodcount} method(s) is listed in the table below, followed by detailed syntax for each  method.
-(API methods can have a shorthand alias name which can be used in the syntax instead of the name)
+The {methodcount} method(s) is(are) listed in the table below, followed by detailed syntax for each method.
+(API methods can have a shorthand _alias_ name which can be used in the syntax instead of the name)
 
 [width="100%",cols="2,2,6a",options="header"]
 |===
@@ -144,7 +144,7 @@ In addition to the parameters above, the {name} API can also use any of the <<#_
 
 Any of the parameters can be provided in either the endpoint URI, or dynamically in a message header.
 The message header name must be of the format `Camel{pascalcasescheme}.parameter`.
-The `inBody` parameter overrides message header, i.e. the endpoint parameter `inBody=myParameterNameHere`
+The `inBody` parameter overrides message header, i.e., the endpoint parameter `inBody=myParameterNameHere`
 would override a `Camel{pascalcasescheme}.myParameterNameHere` header.
 
 %endif::[]