Change general parameter element to specific ISA-95 object names to enable "Corresponds to" relationship for SegmentParameter in OperationsSchedule.xsd and JobOrderParameter in WorkSchedule.xsd

[CharlieG021163]

Background
In ISA-95, The Segment Parameter object in Segment Requirement (950002) and Job Order Parameter object in Job Order (950004) have a cross-model "Corresponds to" relationship to the BOTH Parameter Specification object in Operations Segment and Process Segment Parameter object in Process Segment.

B2MML uses a ParameterType in the Common.xsd for
a general "Parameter" element used in
OperationsSegmentType, ProcessSegmentType, and WorkDefintionType
as well as ParmeterType is used for
SegmentParameter in SegmentRequirementType and JobOrderParameter in JobOrderType.

The parameter specification and parameter segment specification objects in 950002 are the specification objects that the parameter requirement objects in operations schedule (segment requirement/parameter requirement) and work schedule (work request/job order requirement) are defined by.
The "Parameter" element cannot be referenced explicitly as the Parameter Specification object (Operation Segment) OR Process Segment Parameter object (Process Segment) by WorkDefinitionType, SegmentRequirementType, and JobOrderType .
The IDType in the ParameterType is not explicit enough to define how to apply the general Parameter to a specification vs. a requirement object context.
The ParameterType in Common.xsd is used as the type for all parameter elements which creates circular reference due to the use of the general Parameter element.

These two specification objects require explicit elements in the ParameterType to not create a circular reference of requirement to requirement or a specification to a specification.
B2MML use of "ParameterType" for both the specification and requirement objects which allows the user to incorrectly reference the context of the object. I have seen many project teams confuse the general "parameter" element and ParameterType as simply an attribute of the parent object and NOT in the context of the referenced master data specification for requirement object.

ParameterType is confusing specification vs. requirement objects. Making the specification types explicit makes its general use much easier to understand.

Supporting Documents
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 5.8.3 Process segment parameter (Process Segment)
Clause 6.1.6 Parameter specification (Operations Definition /Operations Segment)
Clause 6.2.5 Segment parameter (Operations Schedule /Segment Requirement)
Clause 6.7 Parameter specification (Work Definition)
Clause 7.7 Job order parameter (Work Schedule / Job Order)

Impacted Types and Solution
B2MML-Common.xsd

• ParameterType
  950002
• Parameter element in ProcessSegmentType (ProcessSegment.xsd)
• Parameter element in OperationsSegmentType (OperationsDefintion.xsd)
• SegmentParameter element in SegmentRequirementType (OperationsSchedule.xsd)
  950004
• Parameter element in WorkDefinitionType (WorkDefintion.xsd)
• JobOrderParameter element in JobOrderType (WorkSchedule.xsd) (no change required)

1. ProcessSegment.xsd: complexType name = "ProcessSegmentType",
   CHANGE: element name = "Parameter"
   TO: "ProcessSegmentParameter"
2. OperationsDefintions.xsd: complexType name = "OperationsSegmentType",
   CHANGE: element name = "Parameter"
   TO: "ParameterSpecification"
3. WorkDefintions.xsd: complexType name = "WorkDefinitionType",
   CHANGE: element name = "Parameter"
   TO: "ParameterSpecification".
4. Common.xsd: complexType name = "ParameterType"
   ADD ParameterSpecificationID element and ProcessSegmentParameterID element

[racheliurui]

Agree with proposed change 1 and 2.

For proposed change 3, I couldn't understand why?
If it's used to specifically identify the ID type, then add a element something like IDType to represent the ID is a ParameterSpecificationID or ProcessSegmentParameterID is good enough and easy to reuse the type when we have other types need to use ParameterType.

<xsd:element name="IDType" type="String"/>

And the ID Type can be ParameterSpecificationID or ProcessSegmentParameterID.

[CharlieG021163]

1. I am not sure I understand your suggestion on change 3. IDType is not explicit enough to know how to apply the general Parameter type to a specification vs. a requirement object context.
   The parameter specification and parameter segment specification are the specification objects that the parameter requirement objects in operations schedule (segment requirement/parameter requirement) and work schedule (work request/job order requirement) are defined by.
2. I believe that these two specification objects should be explicit in the ParameterType. B2MML use of "ParameterType" for both the specification and requirement objects which makes the user not understand the context of the object. I have seen many project teams confuse the parameter element and ParameterType as simply an attribute of the parent object and NOT in the context of a requirement actual object.
   In current B2MML since a general ParameterType is used in OperationsSegmentType and ProcessSegmentType, SegmentParameter (SegmentRequirementType) and JobOrderParameter (JobOrderType), it cannot reference the explicit Parameter Specification (Operation Segment) or Process Segment Parameter (Process Segment) as a specification to a requirement.
   ParameterType is confusing specification vs. requirement objects. Making the specification object explicit in the type makes its general use much easier to understand.

[racheliurui]

Agreed

[CharlieG021163]

Updated Original Comment. Ready for MESA Submission

[Dennis-Brandl]

I agree to the change.