chore: Name component parameters as type Reusable Parameter Object

versions/1.0.0.md

@@ -57,9 +57,9 @@ The Workflows Specification can articulate these workflows in a human-readable a
       - [Components Object](#components-object)
         - [Fixed Fields](#fixed-fields-8)
         - [Components Object Example](#components-object-example)
-      - [Parameter Reference Object](#parameter-reference-object)
+      - [Reusable Parameter Object](#reusable-parameter-object)
         - [Fixed Fields](#fixed-fields-9)
-        - [Parameter Reference Object Example](#parameter-reference-object-example)      
+        - [Reusable Parameter Object Example](#reusable-parameter-object-example)      
       - [Criterion Object](#criterion-object)
         - [Fixed Fields](#fixed-fields-10)
         - [Criterion Object Example](#criterion-object-example)          
@@ -325,7 +325,7 @@ Field Name | Type | Description
 <a name="stepOperationId"></a>operationId | `string` | The name of an existing, resolvable operation, as defined with a unique `operationId` and existing within one of the `sourceDescriptions`. The referenced operation will be invoked by this workflow step. If multiple (non `workflowsSpec` type) `sourceDescriptions` are defined, then the `operationId` MUST be specified using a [runtime expression](#runtime-expressions) (e.g., `$sourceDescriptions.<name>.<operationId>`) to avoid ambiguity or potential clashes. This field is mutually exclusive of the `operationRef` and `workflowId` fields respectively.
 <a name="stepOperationRef"></a>operationRef | `string` | A relative or absolute URI reference to an OAS operation. This field is mutually exclusive of the `operationId` and `workflowId` fields respectively. A complete [URI Template](https://www.rfc-editor.org/rfc/rfc6570) SHOULD be used. The operation being referenced MUST be described within one of the `source` descriptions.
 <a name="stepWorkflowId"></a>workflowId | `string` | The [workflowId](#fixed-fields-2) referencing an existing workflow within the Workflows Description. If multiple `workflowsSpec` type `sourceDescriptions` are defined, then the `workflowId` MUST be specified using a [runtime expression](#runtime-expressions) (e.g., `$sourceDescriptions.<name>.<workflowId>`) to avoid ambiguity or potential clashes. The field is mutually exclusive of the `operationId` and `operationRef` fields respectively.
-<a name="stepParameters"></a>parameters | [[Parameter Object](#parameter-object) \| [Parameter Reference Object](#parameter-reference-object)] | A list of parameters to pass to an operation or workflow as referenced by `operationId`, `operationRef`, or `workflowId`. If a Parameter Reference Object is provided, it MUST link to parameters defined in [components/parameters](#components-object) defined in the current Workflows document.
+<a name="stepParameters"></a>parameters | [[Parameter Object](#parameter-object) \| [Reusable Parameter Object](#reusable-parameter-object)] | A list of parameters to pass to an operation or workflow as referenced by `operationId`, `operationRef`, or `workflowId`. If a Reusable Parameter Object is provided, it MUST link to parameters defined in the [components/parameters](#components-object) of the current Workflows document.
 <a name="dependsOn"></a>dependsOn | [`string`] | A list of steps that MUST be completed before this step can be processed. This helps to ensure workflow steps are executed in the correct order and that dependent steps are not processed in parallel. The values provided MUST be the be the `stepId` which uniquely references a step.
 <a name="stepSuccessCriteria"></a>successCriteria | [[Criterion Object](#criterion-object)] | A list of assertions to determine the success of the step. Each assertion is described using a [Criterion Object](#criterion-object). All assertions `MUST` be satisfied for the step to be deemed successful.
 <a name="stepOnSuccess"></a>onSuccess | [[Success Action Object](#success-action-object)] | An array of success action objects that specify what to do upon step success. If omitted, the next sequential step shall be executed as the default behavior. If multiple success actions have similar `criteria`, the first sequential action matching the criteria SHALL be the action executed.
@@ -594,19 +594,19 @@ components:
 }
 ```
 
-#### Parameter Reference Object
+#### Reusable Parameter Object
 
 A simple object to allow reusable parameters from multiple steps in the Workflows Description.
 
 ##### Fixed Fields
 Field Name | Type | Description
 ---|:---:|---
-<a name="parameterReferenceName"></a>name | `{expression}` | **REQUIRED**. A [runtime expression](#runtime-expressions) used to reference the desired parameter.
-<a name="parameterReferenceValue"></a>value | `string` | A value by default MUST override that of the referenced parameter. 
+<a name="reusableParameterName"></a>name | `{expression}` | **REQUIRED**. A [runtime expression](#runtime-expressions) used to reference the desired parameter.
+<a name="reusableParameterValue"></a>value | `string` | A value by default MUST override that of the referenced parameter. 
 
 This object cannot be extended with additional properties and any properties added SHALL be ignored.
 
-##### Parameter Reference Object Example
+##### Reusable Parameter Object Example
 
 ```yaml
   name: $components.parameters.page