etpartners/b2mmlv7beta

b2mmlv7beta for review

b2mmlv7beta's Issues

ADD: NEW B2MML-ErrorMessage.XSD

ERDi, MESA:
Background
B2MML does not have an error handling schema. A basic set of error handling logic should be considered by MESA as starting point for users.

Solution
ADD: B2MML-ErrorMessage.XSD
This is an extension schema to help standardize the error handling logic.

Change MaterialSublotProperty element to MaterialLotProperty for MaterialSubLotType in Material.xsd to align with updated 950002

MESA

MESAInternational/B2MML-BatchML#43

Background

In Material Model, Per 950002, Both material lot and material sub lot objects apply the same material lot property object and instances in their definition. Thus in updated ISA-950002, there's no such model called MaterialSublotProperty,
In Material.xsd / MaterialSublotType, CHANGE MaterialSublotProperty element to MateralLotProperty reflect the property type.

Supporting Document

ISA-950002 JWG5 CDV01 version (2019 12)
Table 72 – Material sublot relationship roles

Impacted Types

B2MML-Material.xsd

• MaterialSubLotType

Update TestSpecificationType elements in TestSpecification.xsd (if OperationsTest.xsd is not used) to align with updated 950002

MESAInternational/B2MML-BatchML#47

Background, Related to #101

Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.

Solution
IF MESA does not except the OperationsTest.xsd change, the following changes are recommended to TestSpecification.xsd.

CHANGE: "TestPropertyMeasurementType" with "PropertyMeasurementType"
Multiple changes to TestSpecificationType to align with updated 950002 Operations Test Model's Test Specification object.

complexType name = "TestSpecificationType" element name = "EvaluatedProperty",
CHANGE: type = "TestSpecificationEvaluatedPropertyType" to "EvaluatedPropertyType"

complexType name = "TestSpecificationType"
CHANGE: element name = "PhysicalSample"
TO: "PhysicalSampleRequired"

complexType name = "TestSpecificationType",
ADD: element name = "OperationsTestRequirementID"

complexType name = "TestSpecificationType",
ADD: element name = "TestableObjectID"

Supporting Document

950002 JWG5 CDV01 version (2019 12)
Clause 5.9.7 Evaluated property
Clause 5.9.4 Test specification, Table 103 – Test specification relationship roles

Impacted Types

B2MML-TestSpecification.xsd

• TestSpecificationType

Add TestSpecification element to MaterialSubLotType in Material.xsd to align with updated 950002

Refer to #10 where this issue and solution are part of the complete explanation and solution across all types. Duplicate with closed #13 and #14.

Background and Solution
ERDi, MESA: Material.xsd, MaterialSubLotType:
ADD TestSpecificationID
to align with updated 950002, Operations Test Model.
This also aligns with the OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinition. MESA may not do. ERDi should.

Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.7.8 Material sublot, Table 72 – Material sublot relationship roles
Clause 5.9.3 Testable object and testable object property, Table 100 Instances of testable object

b2mmlv7beta/Schema/B2MML-Material.xsd

Line 347 in 8ce6f9e

<xsd:element name = "TestSpecificationID" type = "IdentifierType"

==================

Add MaterialDefinitionPropertyID to MaterialLotPropertyType in Material.xsd to align with updated 950002

MESA

MESAInternational/B2MML-BatchML#38

Background

To align with the updated 950002, There is 0..* "maps to" association relationship from MaterialLotProperty to MaterialDefinitionProperty. The mapping relationship is missing from the current B2MML schema.

Supporting Document

ISA-950002 JWG5 CDV01 version (2019 12)
Table 70 – Material lot property relationship roles

Impacted Types and Solution

B2MML-Material.xsd
complexType name = "MaterialLotPropertyType",
ADD element name = "MaterialDefinitionPropertyID" type = "MaterialDefinitionPropertyIDType". This aligns to updated ISA-950002 JWG5 CDV01 version (2019 12).

Delete WorkflowSpecificationTypeType from WorkflowSpecification.xsd to align with updated 950004

Background
WorkflowSpecification.xsd
DELETE complexType name = "WorkflowSpecificationTypeType",
In the B2MML, this is an abstract type that simply refers only to two types, WorkflowSpecificationNodeTypeType and WorkflowSpecificationConnectionTypeType.
It is simply not needed especially since these types are individually exchanged as first order objects as master data.
Second, the name, WorkflowSpecificationType, is confusing to user since it implies that there are different types of a Workflow Specification which there is not in the updated ISA-950004.

Impact Analysis

• WorkflowSpecificationTypeType as part of master data, is exchanged between different systems.
  So those interfaces used to exchange WorkflowSpecificationTypeType information will be removed.
• WorkflowSpecificationTypeType is referenced by WorkflowSpecificationInformationType, Global element, Transaction elements, and TransactionTypes element.
• Conclusion, the impact of deleting this type is required simplify schema and reduce use confusion.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause, 6.16.1 Workflow specification model, Figure 5 – Workflow specification model
Clause 6.16.8 Workflow specification node type, Table 43 – Workflow specification node type relationship roles
Clause 6.16.10 Workflow specification connection type, Table 47 – Workflow specification connection type relationship roles

Impacted Types and Solution
Related Issues: #43, #45, #46, #47, #48
B2MML-WorkflowSpecification.xsd

1. Global Element
   1.1. DELETE: <xsd:element name = "WorkflowSpecificationType" type = "WorkflowSpecificationTypeType" />
2. Transaction Elements
   2.1. DELETE: All transaction elements for WorkflowSpecificationType
3. Simple & Complex Types
   3.1. DELETE: complexType name = "WorkflowSpecificationTypeType"
4. WorkflowSpecificationTypeType Transaction Types
   4.1. DELETE: All transaction types for WorkflowSpecificationTypeType

B2MML-Extension.xsd

1. DELETE: <xsd:group name = "WorkflowSpecificationType">

Represent OperationsMaterialBill as 1st order object and OperationsSegment as target role in composite relationship from OperationsDefinition in OperationsDefinition.xsd to align with updated 950002

Background and Solutions
ERDi, MESA: OperationsDefnition.xsd
In the Updated 950002 Operations Definition Model, Operations Definition object has an "Has associated" association relationship to Operations Material Bill object which is a first order object. B2MML does not represent Operations Material Bill as a 1st order object.

B2MML is missing the target element for the "has associated" relationship to the Operations Material Bill from Both "OperationsSegmentType" and "OperationsDefinitionType" in OperationsDefinition.xsd.

Operations Definition has a "Contains" composite relationship to Operations Segment as the target role so it is not a 1st order object but master data contained in an Operations Definition; B2MML needs to delete the Operations segment transaction types.

Above are required to align with updated 950002 Operations Definition Model.
So the following changes are required:

1. complexType name = "OperationsDefinitionType
   ADD: <xsd:element name = "OperationsMaterialBillID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>

2. complexType name = "OperationsSegmentType
   ADD: <xsd:element name = "OperationsMaterialBillID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>

3. complexType name = "OperationsDefinitionInformationType"
   ADD: <xsd:element name = "OperationsMaterialBill" type = "OperationsMaterialBillType" minOccurs = "0" maxOccurs = "unbounded"/>

4. Global Elements
   ADD: <xsd:element name = "OperationsMaterialBill" type = "OperationsMaterialBillType" />

5. Transaction Elements
   ADD: transaction elements for OperationsMaterialBillType

6. ADD: OperationsMaterialBill Transaction Types

7. DELETE: OperationsSegment Transaction Types
   Deleted Operations segment transaction types since it a composite relationship to OperationsDefinition.

Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.1.1 Operations definition model, Figure 20 – Operations definition model
Clause 6.1.2 Operations definition, Table 145 – Operations definition relationship roles
Clause 6.1.5 Operations segment, Table 151 – Operations segment relationship roles
Clause 6.1.3 Operations material bill, Table 147 – Operations material bill relationship roles

Impacted Types and Solution
B2MML-OperationsDefinition.xsd

• OperationsDefinitionInformationType
• OperationsDefinitionType
• OperationsSegmentType
• Global Elements, xsd:element name = "OperationsMaterialBill" type = "OperationsMaterialBillType"
• Transaction Elements, OperationsMaterialBillType
• OperationsMaterialBill Transaction Types
• OperationsSegment Transaction Types

Remove EvaluatedPropertyReference from xxxPropertyType to align with updated 950002 Operations Test Model

Background
ERDi, MESA: Refers to #49, #95, #101
In the updated 950002 Operations Test Model, the relationship source role name is not a required element for the "Corresponds to" unidirectional relationship from the Evaluated Property object (source) (under the Test Specification object) to the xxxProperty object (target, Testable Object Property). There is No reference attribute.
In B2MML, the EvaluatedPropertyReference element is not necessary and creates a circular reference since the Testable Object Property has a composite relationship to the Testable object which has the "specifies" relationship to associated TestSpecification element. The TestSpecifictionID identifies the defined the EvaluateProperty(s) by it composite relationship.

Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.5.3 Equipment class property, Table 41 – Equipment class property relationship roles
Clause 5.5.5 Equipment property, Table 45 – Equipment property relationships
Clause 5.6.3 Physical asset class property, Table 51 – Physical asset class property relationship roles
Clause 5.6.5 Physical asset property. Table 55 – Physical asset property relationship roles
Clause 5.7.3 Material class property, Table 62 – Material class property relationship roles
Clause 5.7.5 Material definition property, Table 66 – Material definition property relationship roles
Clause 5.7.7 Material lot property, Table 70 – Material lot property relationship roles
Clause 5.9.1 Operations test model, Figure 16- Operations test model
Clause 5.9.7 Evaluated property, Table 109 – Evaluated property relationship roles
Clause 5.11.3 Operations event class property, Table 128 – Operations event class property relationship roles
950004 JWG5 CDV01 version (2019 12)
Clause 6.16.3 Workflow specification property, Table 33 – Workflow specification property relationship roles

Impacted Types and Solution
From the following types:
DELETE: <xsd:element name = "EvaluatedPropertyReference" type = "EvaluatedPropertyReferenceType" minOccurs = "0"/>

1. B2MML - Equipment.xsd
   -EquipmentPropertyType
   -EquipmentClassPropertyType
2. B2MML - Material.xsd
   -MaterialClassPropertyType
   -MaterialDefinitionPropertyType
   -MaterialLotPropertyType
3. B2MML-PhysicalAsset.xsd
   -PhysicalAssetClassPropertyType
   -PhysicalAssetPropertyType
4. B2MML-Personnel.xsd
   -PersonnelClassPropertyType
   -PersonPropertyType
5. B2MML-OperationsEvent.xsd
   -OperationsEventClassPropertyType
6. B2MML-WorkflowSpecification.xsd
   -WorkflowPropertyType, #49 DELETED WorkflowPropertyType which DELETED EvaluatedPropertyReference element.

Update WorkDefinitionType to align with updated 950004

Background
Align complexType name = "WorkDefintionType" in WorkDefinition.xsd to align with updated 950004 Work Definition Model.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.4 Work definition,

• Table 24 – Work definition relationship roles
• Table 25 – Work definition attributes (common in work master and work directive)

Impacted Types and Solution
B2MML-WorkDefinition.xsd

• "WorkDefinitionType"

Align with updated 950004 Table 24 – Work definition relationship roles. Elements moved to WorkMasterType.
DELETE: element name = "OperationsDefinitionID"
DELETE: element name = "OperationsSegmentID"
DELETE: element name = "ProcessSegmentID"
DELETE: element name = "WorkflowSpecification"

Align with updated 950004 Table 25 – Work definition attributes (common in work master and work directive)
CHANGE: #61 element name = "Parameter"
TO: "ParameterSpecification"

Update WorkflowSpecificationInformationType in WorkflowSpecification.xsd to align with updated 950004

MESAInternational/B2MML-BatchML#48

Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model by having "WorkflowSpecificationInformationType" address the 1st order objects used as master data.

Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.16.1 Workflow specification model, Figure 5 – Workflow specification model

Impacted Types and Solution
Related Issues: ##45, #46, #47, #48, #50
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationInformationType"
CHANGE: element name = "WorkflowSpecificationType" type = "WorkflowSpecificationTypeType"
TO: "WorkflowSpecificationNodeType" type = "WorkflowSpecificationNodeTypeType"

ADD: element name = "WorkflowSpecificationConnectionType" type = "WorkflowSpecificationConnectionTypeType" minOccurs = "0" maxOccurs = "unbounded"/>

Update xxxActualType in OperationsPerformanceTypes.xsd to align with updated 950002

Background and Solution

To align the XXXActualTypes in the OperationsPerformanceTypes.xsd, B2MML requires the following:
CHANGE element name = "xxxActual" to "xxxActualChild"; #12
DELETE = element name = "TestSpecification".

Impacted Types

B2MML-OperationsPerformanceTypes.xsd

• OpPersonnelActualType
• OpMaterialActualType
• OpEquipmentActualType
• OpPhysicalAssetActualType

Supporting Document

950004 JWG5 CDV01 version (2019 12)
Clause 6.3.6 Personnel actual, Table 208 – Personnel actual relationship roles
Clause 6.3.8 Equipment actual, Table 212 – Equipment actual relationship roles
Clause 6.3.10 Physical asset actual, Table 216 – Physical asset actual relationship roles
Clause 6.3.12 Material actual, Table 220 – Material actual relationship roles

Update WorkflowSpecificationNodeTypeType to align with updated ISA-950004

MESAInternational/B2MML-BatchML#49

Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.7 Workflow specification node type.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.8 Workflow specification node type
Table 43 – Workflow specification node type relationship roles
Table 44 – Workflow specification node type attributes

Impacted Types and Solution
Related Issues #48, #50, #51
complexType name = "WorkflowSpecificationNodeTypeType"

1. Global Element
   1.1. ADD <xsd:element name = "WorkflowSpecificationNodeType" type = "WorkflowSpecificationNodeTypeType" />

2. Transaction Elements
   2.1. ADD: All transaction elements for WorkflowSpecificationNodeType

3. Simple & Complex Types
   3.1. ADD: to incorporate new proposed element

• #11 element name = "Version", type = "VersionType" minOccurs = "0"/>
• #9 element name = "EffectiveFrom", type = "DateTimeType" minOccurs = "0" />
• #9 element name = "EffectiveTo", type = "DateTimeType" minOccurs = "0" />
  3.2. CHANGE: #51
• element name = "Property", type = "WorkflowSpecificationPropertyType"
  TO: "WorkflowSpecifictionNodeTypeProperty", type = "WorkflowSpecificationNodeTypePropertyType"
  3.3. ADD: Align with updated 950004 Workflow Specification Model.
• element name = "HierarchyScope", type = "HierarchyScopeType" minOccurs = "0"/>
  Align with updated 950002 best practice to apply Hierarchy Scope to 1st class objects. This addition was added. Comment approved by ISA-95 Committee at October 28th meeting.

4. WorkflowSpecificationNodeTypeType Transaction Types
   4.1. ADD All transaction types for WorkflowSpecificationNodeTypeType

ERDi design rule for element name cases

In the BHP JSON, the design rule was to use camel case for element names, B2MML does not. What is the ERDI design rule?

Design rule for elements for the source element of a unidirectional relationship

ERDi Decision:
What is design rule for AMIRA / ERDi Protobuf and JSON implementions?

Background
In updated 950002 and 950004 models, 95 Committee agreed that the standard's convention is show the logical direction of all UML model relationships. Most relationships in models are unidirectional from a source object to a target object where the UML and XML best practice is applied with only the naming of target role element in the relationship role table for each object.
The current B2MML 7.0 beta is very inconsistent by having both source and target elements for unidirectional relationships in many types and having no source element in many types.

Solution
MESA Solution: Since updated 950002 relationship role naming convention only names the target element and not source element, the existing instances of source elements in B2MML shall not be deleted to align with the updated standard but shall change the element name to XXXSourceID to make the role explicit in the object and it B2MML type to be schematically correct, MESA B2MML implementation is inconsistent in it use of source elements across the schema.

ERDi Options: Recommend B2MML adopt a consistent design principle in its implementation of either:

1. Delete the source elements across the schema in the 95 unidirectional relationships.
2. Add the source elements across the schema in the 95 unidirectional relationships in schema to a naming convention of XXXSourceID from XXXXID. This change that has been incorporated throughout ERDi implementation on GitHub.

Example: EquipmentClassType, element name = "EquipmentID" type = "IdentifierType".
This the source in a unidirectional relationship in updated ISA-95 part 2 and B2MML represents it as a bidirectional relationship by having this element. This applies across all resource types.
The following elements are the current B2MML source elements for various relationships that are changed to the Option 1 naming convention:

Impacted Types and Solutions

• TYPE
  - Updated ELEMENT
• OperationalLocationClassType
  - OperationalLocationSourceID
• PersonnelClassType
  - PersonSourceID
• EquipmentClassType
  - EquipmentSourceID
• PhysicalAssetClassType
  - PhysicalAssetSourceID
• MaterialClassType
  - MaterialDefinitionSourceID
• MaterialDefinitionType
  - MaterialLotSourceID
• ProcessSegmentType
  - WorkMasterSourceID
  - OperationsSegmentSourceID
  - SegmentRequirementSourceID
• OperationsEventClassType
  - OperationsEventDefinitionSourceID
• OperationsDefinitionType
  - WorkMasterSourceID
• OperationsSegmentType
  - WorkMasterSourceID
• ResourceNetworkConnectionTypeType
  - ResourceNetworkConnectionSourceID
• WorkMasterType
  - JobOrderSourceID
• WorkDirectiveType
  - JobOrderSourceID

Add specific property types to replace common WorkflowSpecificationPropertyType for WorkflowSpecificationNode, NodeType, Connection, and ConecectionType in WorkflowSpecification.xsd to align with updated 950004

Background

1. The Common type, WorkflowProperty, in B2MML 7.0 Beta was used for all Workflow Specification Property Types. This named type is the explicit object name in the updated 950004 Workflow Specification Model for the property object of the Workflow Specification object.
2. WorkflowSpecificationPropertyType must only be used for WorkflowSpecificationType and be replace with specific property types for each object type to align with updated 950004 Workflow Specification model. This reduces use confusion and make explicit the property mappings from instance to type definition.
3. The common property type schema make relationship elements between the common group schema very confusing for the B2MML user.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.5 Workflow specification node property
Table 37 – Workflow specification node property relationship roles
Table 38 – Workflow specification node property attributes
Clause 6.16.7 Workflow specification connection property,
Table 41 – Workflow specification connection property relationship roles
Table 42 – Workflow specification connection property attributes
Clause 6.16.9 Workflow specification node type property
Table 45 – Workflow specification node type property relationship roles
Table 46 – Workflow specification node type property attributes
Clause 6.16.11 Workflow specification connection type property
Table 49 – Workflow specification connection type property relationship roles
Table 50 – Workflow specification connection type property attribute

Impacted Types and Solution
B2MML-WorkflowSpecification.xsd

1. complexType name = WorkflowSpecificationPropertyType
   This Common property type shall be only apply to WorkflowSpecificationType and not to all property types; It shall be replaced with specific property types to align with updated 950004 Workflow Specification model.

2. ADD:

• complexType name = "WorkflowSpecificationNodePropertyType".
• complexType name = "WorkflowSpecificationNodeTypePropertyType".
• complexType name = "WorkflowSpecificationConnectionPropertyType".
• complexType name = "WorkflowSpecificationConnectionTypePropertyType".

B2MML-Extension.xsd

1. ADD: <xsd:group name = "WorkflowSpecificationNodeProperty">
2. ADD: <xsd:group name = "WorkflowSpecificationNodeTypeProperty">
3. ADD: <xsd:group name = "WorkflowSpecificationConnectionProperty">
4. ADD: <xsd:group name = "WorkflowSpecificationConnectionTypeProperty">

Update OpSegmentDataType in OperationsPerformanceTypes.xsd to align with updated 950002

MESA

MESAInternational/B2MML-BatchML#42

Background and Solution

As defined in updated 950002,
ADD: element name = "HierarchyScope"
CHANGE #12 element name = "SegmentData" to "SegmentDataChild"

Supporting Document

ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.3.5 Segment data
Table 206 – Segment data relationship roles
Table 207 – Segment data attributes

Impacted Types

B2MML-OperationsPerformanceTypes.xsd

• OpSegmentDataType

Nested Properties: "Child" should be appended to the element name that are nested under parent properties.

Background and Solution
To align with updated 950002 and 950004, the defined relationship role names for the "Contains" and "Is made up of" nested association relationships in the Relationship Role Tables for many information models append "Child" to the target role element name nested under parent properties.
In B2MML, current child elements are not explicitly named to distinguish between parent verses child objects in implementations.
In B2MML with any nested structures like equipment hierarchy, there's an assumption that the nesting is from Parent to Child

			<p:HierarchyScope>
				<p:EquipmentID>CompanyA</p:EquipmentID>
				<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				<p:HierarchyScope>
					<p:EquipmentID>SiteB</p:EquipmentID>
					<p:EquipmentLevel>Site</p:EquipmentLevel>
				</p:HierarchyScope>
			</p:HierarchyScope>

The issue is, in many cases, users would think the nested property is actually from Child to Parent. how can user tell what's wrong with below payload? (Nested from Child to Parent).

			<p:HierarchyScope>
				<p:EquipmentID>SiteB</p:EquipmentID>
				<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				<p:HierarchyScope>
					<p:EquipmentID>CompanyA</p:EquipmentID>
					<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				</p:HierarchyScope>
			</p:HierarchyScope>

By introducing Child to the tag naming, it becomes explicit the nested tag is referring a child of the current tag.

			<p:HierarchyScope>
				<p:EquipmentID>CompanyA</p:EquipmentID>
				<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				<p:HierarchyScopeChild>
					<p:EquipmentID>SiteB</p:EquipmentID>
					<p:EquipmentLevel>Site</p:EquipmentLevel>
				</p:HierarchyScope>
			</p:HierarchyScope>

Impacted Types

As this proposed change impacts a lot of elements' name, the list of impacted types are not listed here but will be commented with the changelog.

MaterialLotType: MaterialTestSpecificationID should be MaterialLotType: TestSpecificationID

**Refer to #10 where this issue and solution are part of the complete explanation and solution across all types. Duplicate with closed #13 and #15. **
ERDi, MESA: MaterialLotType: MaterialTestSpecificationID should be deprecated and replaced by TestSpecificationID to align with updated Part 2, Operations Test Model. This also aligns with the OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinition. MESA may not do. ERDi should.

Master Data Identification: Add PublishDate, EffectiveStartDate, EffectiveEndDate to align with updated 950002 & 950004.

Background
ERDi, MESA: Related #11
When the updated 950002 and 950004 first order objects are used to exchange the various forms of MOM Master Data, a version element in the B2MML Types used for Master Data instances is often required. In some use cases where there are multiple versions of a Master Data instance (ISA-95 1st order object) simultaneously used across a supply chain, the version attribute requires additional identification header information to differentiate each version as identification.
In the ISA95 October 2019 Meeting, an approved C. Gifford comment added 1) new text to the updated 950002 Clause 4.5.5. Object identification and 2) the Version attribute to all 1st order objects. The added text states that additional identification attributes/elements shall be used with Version attribute as required by the implementation.
The recommended identification attribute set is ID, Version, Published Date, Effective Start Date (Start Time) and Effective End Date (End Time) as typical for Master Data of MOM process and resource definitions used by planning and job order execution. Versioned Master Data are time constrained in applications without changing the ID to maintain change history. Some iSA-95 1st order objects have existing attributes of Start Time or End Time for EffectiveStartDate and EffectiveEndDate respectively. These existing similar attributes shall remain as is.

Solution
This issue and associated commits are to ADD the PublishedDate, EffectiveStartDate, and EffectiveEndDate elements to the following Resource Class and Definition Types to support the updating of a Master Data instance as its properties and/or attributes are changed.
Some B2MML types already have one or all three of these elements.
Issue #11 and associated commits are to ADD the version element.

EXAMPLE (or Similar)
complexType name = "MaterialClassType",
ADD element name = "PublishedDate" type = "DateTimeType"
ADD element name = "EffectiveStartDate" type = "DateTimeType"
ADD element name = "EffectiveEndDate" type = "DateTimeType"

Impacted Types:
Equipment.xsd:
EquipmentClassType DONE
EquipmentType DONE

Material.xsd:
MaterialClassType DONE
MaterialDefinitionType DONE

PhysicalAsset.xsd:
PhysicalAssetClassType DONE
PhysicalAssetType DONE

Personnel.xsd:
PersonnelClassType DONE
PersonType DONE

MasterDataProfile.xsd:
MasterDataProfileHeaderType DONE
CHANGE: element name = "ReleaseDate" TO: "PublishedDate"
ADD element name = "EffectiveStartDate" type = "DateTimeType"
ADD element name = "EffectiveEndDate" type = "DateTimeType"

OperationalLocation.xsd:
OperationalLocationClassType DONE
OperationalLocationType DONE

OperationsEvent.xsd:
OperationsEventClassType DONE
OperationsEventDefinitionType DONE
OperationsEventType DONE
-Use Existing element: <xsd:element name = "EffectiveTimeStamp"
-Use Existing element: <xsd:element name = "RecordTimeStamp"

ProcessSegment.xsd:
ProcessSegmentType DONE

OperationsDefinition.xsd:
OperationsDefinitionType DONE
OperationsSegmentType DONE
OperationsMaterialBillType DONE
OperationsMaterialBillItemType DONE

OperationsSchedule.xsd:
OperationsScheduleType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
OperationsRequestType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-PublishedDate: Not required since composite child object to OperationsScheduleType
OpSegmentRequirementType DONE
-Use Existing element: <xsd:element name = "EarliestStartTime"
-Use Existing element: <xsd:element name = "LatestEndTime"
-PublishedDate: Not required since composite child object to OperationsRequestType

OperationsPerformance.xsd:
OperationsPerformanceType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
OperationsResponseType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-PublishedDate: Not required since composite child object to OperationsPerformanceType.

OperationsPerformanceTypes.xsd:
OpSegmentResponseType DONE
-Use Existing element: <xsd: element name = "PostingDate"
-ADD element name = "PublishedDate" type = "DateTimeType"
-Use Existing element: <xsd:element name = "ActualStartTime"
-Use Existing element: <xsd:element name = "ActualEndTime"

OperationsCapability.xsd:
OperationsCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
OpProcessSegmentCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
OpOperationsSegmentCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"

WorkDefinition.xsd
WorkDefinitionType DONE
-CHANGE: "EffectiveFrom" TO: "EffectiveStartDate"
-CHANGE: "EffectiveTo" TO: "EffectiveEndDate"
-Use Existing element: PublishedDate

WorkflowSpecification.xsd:
WorkflowSpecificationType DONE
WorkflowSpecificationNodeTypeType DONE
WorkflowSpecificationConnectionTypeType DONE

ResourceRelationshipNetwork.xsd
ResourceRelationshipNetworkType DONE
-CHANGE: <xsd:element name = "EffectiveFrom" TO: "EffectiveStartDate
-CHANGE: <xsd:element name = "EffectiveTo" TO: "EffectiveEndDate
-ADD: <xsd:element name = "PublishedDate"
ResourceNetworkConnectionTypeType DONE
-CHANGE: "EffectiveFrom" TO: "EffectiveStartDate"
-CHANGE: "EffectiveTo" TO: "EffectiveEndDate"
-Use Existing element: PublishedDate

WorkSchedule..xsd
WorkScheduleType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
WorkRequestType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-PublishedDate: Not required since composite child object to WorkScheduleType.
JobOrderListType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
JobOrderType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate

WorkPerformance.xsd
WorkPerformanceType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
WorkResponseType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
JobResponseType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
JobResponseListType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"

WorkCapability.xsd
WorkCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
WorkMasterCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate

WorkAlert.xsd
WorkAlertDefinitionType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkAlertType DONE
-ADD element name = "Description" type = "DescriptionType" minOccurs = "0" maxOccurs = "unbounded"/>
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"

WorkCalendar.xsd
WorkCalendarDefinitionType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkCalendarDefinitionEntryType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-CHANGE: <xsd:element name = "StartRule" type = "CodeType" minOccurs = "0"/>
TO: element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkCalendarType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkCalendarEntryType DONE
-Use Existing element: <xsd:element name = "StartDateTime"
-Use Existing element: <xsd:element name = "FinishDateTime"
-ADD: <xsd:element name = "PublishedDate"

Common.xsd:
OperationsRecordSpecTemplateType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
OperationsRecordTemplateType DONE
-Use Existing element: <xsd:element name = "RecordTimestamp" for "PublishedDate"
-Use Existing element: <xsd:element name = "EffectiveTimestamp" for "EffectiveStartDate"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
OperationsRecordEntryTemplateType DONE
-Use Existing element: <xsd:element name = "RecordTimestamp" for "PublishedDate"
-Use Existing element: <xsd:element name = "EffectiveTimestamp" for "EffectiveStartDate"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
TestResultType
-ADD element name = "PublishedDate" type = "DateTimeType"
-Use Existing element: <xsd:element name = "EvaluationDate" for "EffectiveStartDate"
-Use Existing element: <xsd:element name = ""Expiration" for "EffectiveEndDate"

Change xxxTestSpecification element to TestSpecification in all Resource.xsds, their xxxInformationType, and entity types to align with updated 950002

This issue and solution are the complete explanation and solution across all types which include closed issues #13, #14, and #15.

Background
In B2MML, all instances of the XXXTestSpecificationID element should be changed to TestSpecificationID to align with updated 950002 Operations Test Model.
Also, general use of TestSpecificationID aligns with the existing OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinitionType.
MESA may not do this solution. ERDi should.

Impacted Types and Solutions

1. The following Impacted Types and Changed Elements in the resource schema changed to TestSpecification and TestSpecificationID element:
   Element in each Type:
   Material.xsd

• "MaterialInformationType": CHANGE "MaterialCapabilityTestSpecification" TO "TestSpecification"
• "MaterialClassType": CHANGE "MaterialTestSpecificationID" TO "TestSpecificationID"
• "MaterialDefinitionType": CHANGE "MaterialTestSpecificationID" TO "TestSpecificationID"
• "MaterialLotType": CHANGE "MaterialTestSpecificationID" TO "TestSpecificationID"
• "MaterialSublotType": ADD "TestSpecificationID"
  Equipment.xsd
• "EquipmentInformationType": CHANGE "EquipmentCapabilityTestSpecification" TO "TestSpecification"
• "EquipmentClassType": CHANGE "EquipmentCapabilityTestSpecification" TO "TestSpecificationID"
• "EquipmentType": CHANGE "EquipmentCapabilityTestSpecification" TO "TestSpecificationID"
  PhysicalAsset.xsd
• "PhysicalAssetInformationType": CHANGE "PhysicalAssetCapabilityTestSpecification" TO "TestSpecification"
• "PhysicalAssetClassType": CHANGE "PhysicalAssetCapabilityTestSpecification" TO "TestSpecificationID"
• "PhysicalAssetType": CHANGE "PhysicalAssetCapabilityTestSpecification" TO "TestSpecificationID"
  Personnel.xsd
• "PersonnelInformationType": CHANGE "Qualification TestSpecification" TO "TestSpecification"
• "PersonnelClassType": CHANGE "QualificationTestSpecification" TO "TestSpecificationID"
• "PersonType": CHANGE "QualificationTestSpecification" TO "TestSpecificationID"
  DONE: Above Edits complete

2. Extensions.xsd
   DELETE the following xsd:group name:

• MaterialCapabilityTestSpecification
• MaterialTestSpecification
• EquipmentCapabilityTestSpecification
• PhysicalAssetCapabilityTestSpecification
• QualificationTestSpecification

Supporting Documents
950002 JWG5 CDV01 version (2019 12)
Clause 5.4.2 Personnel class, Table 30 – Personnel class relationship roles
Clause 5.4.4 Person, Table 34 – Person relationship roles
Clause 5.5.2 Equipment class, Table 39 – Equipment class relationship roles
Clause 5.5.4 Equipment, Table 43 – Equipment relationship roles
Clause 5.6.2 Physical asset class, Table 49 – Physical asset class relationship roles
Clause 5.6.4 Physical asset, Table 53 – Physical asset relationship roles
Clause 5.7.2 Material class, Table 60 – Material class relationship roles
Clause 5.7.4 Material definition, Table 64 – Material definition relationship roles
Clause 5.7.6 Material lot, Table 68 – Material lot relationship roles
Clause 5.7.8 Material sublot, Table 72 – Material sublot relationship roles
Clause 5.7.8 Material sublot, Table 72 – Material sublot relationship roles
Clause 5.9.3 Testable object and testable object property, Table 100 Instances of testable object

Enumerate Type Definition

Simplify the current way to define enumerates type.

• Current Definition Sytle

<xsd:complexType name="AssemblyRelationship1Type">
        <xsd:simpleContent>
            <xsd:restriction base="CodeType">
                <xsd:enumeration value="Permanent"/>
                <xsd:enumeration value="Transient"/>
                <xsd:enumeration value="Other"/>
            </xsd:restriction>
        </xsd:simpleContent>
    </xsd:complexType>
	    <xsd:complexType name="AssemblyRelationshipType">
		<xsd:annotation> 
			<xsd:documentation>
Defines the type of the relationships. 
Defined types are
- Permanent: an assembly that is not intended to be split during the production process; 
- Transient: a temporary assembly using during production, such as a pallet of different materials or a batch kit. 
			</xsd:documentation>
		</xsd:annotation> 
         <xsd:simpleContent>
            <xsd:extension base="AssemblyRelationship1Type">
                <xsd:attribute name="OtherValue" type="xsd:string"/>
            </xsd:extension>
        </xsd:simpleContent>
    </xsd:complexType>

• Simplified Definition

<xsd:simpleType name="AssemblyRelationshipType">
        <xsd:restriction base="xsd:string">
              <xsd:enumeration value="Permanent"/>
                <xsd:enumeration value="Transient"/>
                <xsd:enumeration value="Other"/>
        </xsd:restriction>
</xsd:simpleType>

Add DispositionType definition to Common.xsd to align with updated 950002 and 950004

Raised to MESA

MESAInternational/B2MML-BatchML#35
Background and Solution
ERDi, MESA: Common.xsd
ADD <xsd:complexType name="DispositionType">, with defined values to align with updated 950002 Material Lot Object.

b2mmlv7beta/Schema/B2MML-Common.xsd

Lines 437 to 468 in c295c79

	<xsd:complexType name="Disposition1Type">
	<xsd:simpleContent>
	<xsd:restriction base="CodeType">
	<xsd:enumeration value="Planned"/>
	<xsd:enumeration value="In-Process"/>
	<xsd:enumeration value="Restricted"/>
	<xsd:enumeration value="UnRestricted"/>
	<xsd:enumeration value="Closed"/>
	<xsd:enumeration value="Other"/>
	</xsd:restriction>
	</xsd:simpleContent>
	</xsd:complexType>
	<!-- -->
	<xsd:complexType name="DispositionType">
	<xsd:annotation>
	<xsd:documentation>
	Defines Planning and logistics disposition of a material lot or assembly of material lots.
	Defined values for the disposition of a material lot are
	- Planned: a material lot that does not yet physically exist, is assigned to an operations request (segment requirement) or work request (Part 4 object) or job order (Part 4 object);
	- In process: the material lot is in the process of being worked on;
	- Restricted: a material lot is not permitted for normal use due to a restriction condition.
	EXAMPLE 5 A material lot can be awaiting a quality decision or a material lot can be physically inaccessible.
	- Unrestricted: material lot is permitted for normal use without restriction; and
	- Closed: material lot has been reconciled as completely consumed, sold or disposed of.
	</xsd:documentation>
	</xsd:annotation>
	<xsd:simpleContent>
	<xsd:extension base="DispositionType">
	<xsd:attribute name="OtherValue" type="xsd:string"/>
	</xsd:extension>
	</xsd:simpleContent>
	</xsd:complexType>

Impacted Types
B2MML - Common.xsd

Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.7.6 Material lot, Table 69 – Material lot attributes
Clause 5.7.8 Material sublot, Table 73 – Material sublot attributes

Related Issues
#22

Update BillOfMaterialsID, WorkDefinitionID (Change to WorkMasterID), and BillOfResourcesID elements to unbounded for OperationsDefinitionType and OperationsSegmentType

Background
OperationsDefinition.xsd

1. OperationsDefintionType and OperationsSegmentType use WorkDefinitionID, Per the updated 950002, the "corresponds to" association is from the Work Master object, not the Work Definition object. Align with updated 950002.

2. B2MML is using the an incorrect multiplicity for each relationship target names for OperationsDefinitionType and OperationsSegmentType. Align with updated 950002 Operations Definition Model.

Supporting Documents
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.1.2 Operations definition, Table 145 – Operations definition relationship roles
Clause 6.1.5 Operations segment, Table 151 – Operations segment relationship roles

Impacted Types and Solution
B2MML-OperationsDefinition.xsd

• OperationsDefinitionType
• OperationsSegmentType

1. complexType name = "OperationsDefinitionType"
   1.1. CHANGE: WorkDefinitionID
   TO: WorkMasterID.

1.2. For the following elements:"BillOfMaterialsID", "WorkMasterID", "BillOfResourcesID"
CHANGE: minOccurs = "0"/>min
TO: Occurs = "0" maxOccurs = "unbounded"/>

2. complexType name = "OperationsSegmentType"
   2.1. CHANGE: WorkDefinitionID
   TO: WorkMasterID.

2.2. For the following elements: "BillOfMaterialsID", "WorkMasterID", "BillOfResourcesID"
CHANGE: minOccurs = "0"/>min
TO: Occurs = "0" maxOccurs = "unbounded"/>

Add xxxClassPropertyID to xxxPropertyType for "Maps to" relationships throughout updated 950002 & 950004 models

THE BACKGROUND and COMMENT IS INCORRECT. SEE REWRITE COMMENT BELOW.

Background

There is 0..* map relationship from a certain object's Property to the object's ClassProperty. The mapping relationship is missing from the current B2MML schema.
For example, an EquipmentProperty can be mapped to multiple Equipment Class Properties.

Supporting Document

ISA-950002 JWG5 CDV01 version (2019 12)
Table 45 – Equipment property relationships
Table 66 – Material definition property relationship roles

Impacted types

B2MML-Equipment.xsd

• EquipmentPropertyType

B2MML-Material.xsd

• MaterialDefinitionPropertyType

Update SegmentDependencyType in Common.xsd to align with updated 950002

Background
Common.xsd
complexType name="SegmentDependencyType", Align with updated 950002 Operations Definition Model.

DELETE:

• element name ="TimingFactor" type = "ValueType" minOccurs="0" maxOccurs="unbounded"/>
  This element is not the same as the Dependency Factor attribute for Segment Dependency object which can be used for either timing factor, event or any conditional rules.
• element name = "UnitOfMeasure" type ="UnitOfMeasureType" nillable ="true" minOccurs="0"/> This element is a duplicate since also contained in the ValueType.

ADD:

• element name ="DependencyFactor" type = "ValueType" minOccurs="0"/>.
  This is the correct attribute for Segment Dependency object from the updated 950002.

Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.1.15 Segment dependency, Table 172 – Segment dependency attributes

Impacted Types
B2MML-Common.xsd

• SegmentDependencyType

Update WorkflowSpecificationConnectionTypeType to align with updated ISA-950004

Background
Align with updated 950004 Workflow Specification Model, Clause 6.16.10 Workflow specification connection type.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.10 Workflow specification connection type
Table 47 – Workflow specification connection type relationship roles
Table 48 – Workflow specification connection type attributes

Impacted Types and Solution
Related Issues #47, #50, #51
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationConnectionTypeType"

1. Global Element
   1.1. ADD <xsd:element name = "WorkflowSpecificationConnectionType" type = "WorkflowSpecificationConnectionTypeType" />

2. Transaction Elements
   2.1. ADD: All transaction elements for WorkflowSpecificationConnectionType

3. Simple & Complex Types
   complexType name = "WorkflowSpecificationConnectionTypeType"
   3.1. ADD: to incorporate new proposed elements

• #11 element name = "Version", type = "VersionType" minOccurs = "0"/>
• #9 element name = "EffectiveFrom", type = "DateTimeType" minOccurs = "0" />
• #9 element name = "EffectiveTo", type = "DateTimeType" minOccurs = "0" />

3.2. CHANGE: #51

• element name = "Property", type = "WorkflowSpecificationPropertyType"
  TO: "WorkflowSpecifictionConnectionTypeProperty", type = "WorkflowSpecificationConnectionTypePropertyType"

3.3. ADD: Align with updated 950004 Workflow Specification Model.

• element name = "HierarchyScope", type = "HierarchyScopeType" minOccurs = "0"/>
  Align with updated 950002 best practice to apply Hierarchy Scope to 1st class objects, this addition was added. Comment approved by ISA-95 Committee at October 28th meeting.
• element name = "FromWSNodeMultiplicity", type = "DescriptionType" minOccurs = "0"/>
• element name = "ToWSNodeMultiplicity", type = "DescriptionType" minOccurs = "0"/>
• element name = "Dependency" type="DependencyType"/>
• element name = "DependencyFactor" type="ValueType" minOccurs="0"/>

4. WorkflowSpecificationConnectionTypeType Transaction Types
   4.1. ADD All transaction types for WorkflowSpecificationConnectionTypeType

Change StorageLocation element from StorageHierarchyScopeType to ResourceLocationType in MaterialLotType and MaterialSubLotType

MESAInternational/B2MML-BatchML#30

Background and Solution

to align with updated 950002 Operational Location Model in Material Model, the following changes are required.

complexType name = "MaterialLotType", element name ="StorageLocation";
CHANGE: type = "StorageHierarchyScopeType" to "ResourceLocationType"

complexType name = "MaterialSubLotType", element name ="StorageLocation";
CHANGE: type = "StorageHierarchyScopeType" to "ResourceLocationType"

Impacted Types

Material.xsd

• MaterialLotType
• MaterialSubLotType

Supporting Document

950002 JWG5 CDV01 version (2019 12)
Clause 5.7.6 Material lot, Table 69 – Material lot attributes
Clause 5.7.8 Material sublot, Table 73 – Material sublot attributes

In Common.xsd, Change EquipmentElementLevelType, EquipmentElementLevel1Type, LocationType, and HierarchyScopeType to align with updated 950002

**Background **
MESA may not make this change. ERDi should.
Align BatchML-BatchInformation.xsd with B2MML-Common.xsd:

1. BatchInformation.xsd has the EquipmentElementLevel element to the EquipmentElementLevelType compared to Common.xsd which as the EquipmentLevel element to the EquipmentLevelType.
2. ISA-88 has the Equipment Element Level attribute compared to ISA-95's Equipment Level attribute. The two attributes represent same defined values and definitions; And so should use the same type in Common.xsd.
3. To support the ISA-88 and ISA-95 attributes as the same definition, the following change was made to align with BatchML to B2MML's Common.xsd.

Impacted Types and Solutions
To align with updated ISA950002 and ISA880002, Change the following,

1. Common.xsd, complexType name="HierarchyScopeType"_
   CHANGE: xsd:choice
   <xsd:element name="EquipmentElementLevel" type="EquipmentElementLevelType"/>
   <xsd:element name="EquipmentLevel" type="EquipmentElementLevelType"/>
   xsd:choice
   TO: xsd:choice
   <xsd:element name="EquipmentElementLevel" type="EquipmentLevelType"/>
   <xsd:element name="EquipmentLevel" type="EquipmentLevelType"/>
   xsd:choice
2. Common.xsd, complexType name="EquipmentElementLevelType"_
   CHANGE: complexType name="EquipmentElementLevelType
   TO: complexType name="EquipmentLevelType
   CHANGE: <xsd:extension base="EquipmentElementLevel1Type">
   TO: <xsd:extension base="EquipmentLevel1Type">
3. Common.xsd, name="EquipmentElementLevel1Type"_
   CHANGE: complexType name="EquipmentElementLevel1Type"
   TO: complexType name="EquipmentLevel1Type
4. Common.xsd, complexType name="LocationType"_
   CHANGE: element name="EquipmentElementLevel" type="EquipmentLevelType"
   TO: xsd:choice
   <xsd:element name="EquipmentElementLevel" type="EquipmentLevelType"/>
   <xsd:element name="EquipmentLevel" type="EquipmentLevelType"/>
   xsd:choice
5. BatchInformation.xsd, complexType name = "EquipmentElementType"
   CHANGE: element name = "EquipmentElementLevel" type = "EquipmentElementLevelType"
   TO: element name = "EquipmentElementLevel" type = "EquipmentLevelType"
6. BatchInformation.xsd, in the section: -- Commonly used elements --
   CHANGE: element name = "EquipmentElementLevel" type = "EquipmentElementLevelType"
   TO: element name = "EquipmentElementLevel" type = "EquipmentLevelType"

ERDi Design Rule for property attribute, Use IDs or embed full object schema

For an " XXXproperty" attribute/element in an object schema, what is the ERDI design rule? Make a property an exchange master data object or include property schema in object schema (including nested child properties?)

Change TestPropertyMeasurementType to PropertyMeasurementType in Common.xsd (if OperationsTest.xsd not used) to align with updated 950002 Operations Test

Background and Solution
ERDi, MESA: Related to #101
To align with updated 950002 Operations Test Model's relationships.
Align TestResult element with updated 950002, Operations Test Model where the Test Result object has an association relationships with the resource actual objects.
Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.

Solution
IF MESA does not except this change, the following change is recommended to Common.xsd.
CHANGE: "TestPropertyMeasurementType" with "PropertyMeasurementType"

Impacted Types
Common.xsd
TestPropertyMeasurementType

Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.9.9, Property measurement, Table 114 Property measurement attributes.

Change TestSpecificationEvaluatedPropertyType to EvaluatedPropertyType in TestSpecification.xsd (if OperationsTest.xsd not used) and add relationship role elements to align with updated 950002

Background

ERDI, MESA: Related to #101
TestSpecification.xsd
Background
Align TestResult element with updated 950002, Operations Test Model where the Test Result object has an association relationships with the resource actual objects.
Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.
Solution
IF MESA does not except OperationsTest.xsd change, the following change is recommended to TestSpecification.xsd.

CHANGE complexType name = "TestSpecificationEvaluatedPropertyType" to "EvaluatedPropertyType" to match explicit name of object to align with updated 950002 Operations Test Model's Test Specification object and EvaluatedProperty object.

ERDI, MESA: TestSpecification.xsd, complexType name = "EvaluatedPropertyType",
ADD "TestableObjectPropertyID" element to align with updated 950002 Operations Test Model's relationships for the Test Specification object and EvaluatedProperty object.

Impacted Types

B2MML-TestSpecification.xsd

• TestSpecificationEvaluatedPropertyType (existing)

Supporting Document

950002 JWG5 CDV01 version (2019 12)
Clause 5.9.7 Evaluated property, Table 109 – Evaluated property relationship roles

Add SegmentRequirement to OpSegmentResponseType in OperationsPerformanceTypes.xsd to align with updated 950002

Background
B2MML is missing the "corresponds to" relationship between Segment Response and Segment Requirement objects in the Operations Performance Model.
ADD a SegmentRequirementID reference element to OpSegmentResponseType to align to the updated 950002 Operations Performance Model.

Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.3.4 Segment response, Table 204 – Segment response relationship roles

Impacted Types and Solution
B2MML-OperationsPerformanceTypes.xsd

• complexType name = "OpSegmentResponseType"

ADD: <xsd:element name = "SegmentRequirementID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>

Add DefinitionType element to OperationsDefinitionType, OperationsSegmentType, OperationsRecordSpecificationTemplateType, WorkMasterType and WorkflowSpecificationType at align with updated 950002 and 950004

Background
B2MML currently has DefinitionType element on the following types:

• ProcessSegmentType

B2MML is missing the DefinitionType element for a new attribute on the following types:

• OperationsDefinitionType
• OperationsSegmentType
• OperationsRecordSpecificationTemplateType
• WorkMasterType
• WorkflowSpecificationType

The DefintionType attribute on process definition objects defines the object as either the Pattern object (target) or the (source) instance to support the "Defined by" exclusive Specialization relationship (0..1 for target element). The source object (instance or child pattern) is defined by a single Pattern object as a template for its objects and its properties._
The Pattern object lacks the details to be scheduled or executed where Instance object is able to be scheduled or executed. The Instance object is defined by Pattern object, This relationship applies to the sharing of the whole complex Pattern object with its composite objects and its properties in the Instance object (not to just properties of a single of object).

Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)

• Clause 5.8.1 Process segment model
  Figure 14 – Process segment model
  Table 74 – Process segment model relationships
• Clause 5.8.2 Process segment
  Table 75 - Process segment relationship roles
• Clause 5.10.1 Operations record model
  Figure 17 – Operations record model (abstract)
  Table 117 – Operations record model relationships
• Clause 5.10.2 Operations record specification template (abstract)
  Table 118 – Operations record specification template relationship roles
• Clause 6.1.1 Operations definition model,
  Figure 20 – Operations definition model
  Table 144 – Operations definition model relationships
• Clause 6.1.2 Operations definition
  Table 145 – Operations definition relationship roles
• Clause 6.1.5 Operations segment
  Table 151 – Operations segment relationship roles

ISA-950004 JWG5 CDV01 version (2019 12)

• Clause 6.1 Work Definition
  Figure 3 – Work definition model
  Table 22 – Work definition model relationships
• Clause 6.5 Work master relationship roles and attributes
  Table 26 – Work master relationship roles
• Clause 6.16.1 Workflow specification model
  Figure 5 – Workflow specification model
  Table 30 – Workflow specification model relationships
• Clause 6.16.2 Workflow specification
  Table 31 – Workflow specification relationship roles

Impacted Types and Solutions
950002
B2MML-Common.xsd

• OperationsRecordSpecificationTemplateType

B2MML-OperationsDefinition.xsd

• OperationsSegmentType
• OperationsDefinitionType

950004
B2MML-WorkDefinition.xsd

• WorkMasterType

B2MML-WorkflowSpecification.xsd

• WorkflowSpecificationType

ADD: To the above types
<xsd:element name = "DefinitionType" type = "DefinitionTypeType" minOccurs = "0"/>

Update WorkflowSpecificationNodeType to align with updated 950004

Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.3 Workflow specification node.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.4 Workflow specification node
Table 35 – Workflow specification node relationship roles
Table 36 – Workflow specification node attributes

Impacted Types and Solution
complexType name = "WorkflowSpecificationNodeType"

CHANGE: Align naming more closely with updated 950004 Workflow Specification Model to reduce confusion.

• element name = "NodeType" type = "IdentifierType" />
  TO: "WorkflowSpecificationNodeTypeID type = "IdentifierType" minOccurs = "0"/>
• element name = "Property", type = "WorkflowSpecificationPropertyType"
  TO: "WorkflowSpecifictionNodeProperty", type = "WorkflowSpecificationNodePropertyType"

ADD: Align with updated 950004 Workflow Specification Model.

• element name = "WorkMasterID", type = "IdentifierType" />, minOccurs = "0" maxOccurs = "unbounded"/>
• element name = "WorkDirectiveID",type ="IdentifierType" />, minOccurs = "0" maxOccurs = "unbounded"/>

Master Data Identification: Add new Version elements and Change all Version elements to IdentifierType to align with updated 950002 and 950004

Background
ERDi, MESA: Related #9
When the updated 950002 and 950004 first order objects are used to exchange the various forms of MOM Master Data, a version element in the B2MML Types shall be used for master data instances as required. In some use cases where there are multiple versions of a Master Data instance (ISA-95 1st order object) simultaneously used across a supply chain, the version attribute requires additional identification header information to differentiate each version as MD identification.
In the ISA95 October 2019 Meeting, one of the approved C. Gifford comments added

1. new text to the updated 950002 Clause 4.5.5. Object identification and
2. the Version attribute to 1st order objects.
   The updated text states that additional identification attributes/elements shall be used with Version attribute as required by the implementation. The recommended master data identification attribute set is ID, Version, Published Date, Effective Start Date and Effective End Date or similar. This attribute set is typical for Master Data of MOM process and resource definitions used by planning and job order execution. Versioned Master Data is time constrained in applications without changing the ID to maintain change history.

Solution
This issue and associated commits are to ADD the "Version" element to following Resource and Definition Types to support the updating of a master data instance as its properties and/or attributes are changed. Some B2MML types already have a version element.
Issue #9 and its associated commits are to ADD the PublishedDate, EffectiveStartDate, and EffectiveEndDate or use exisitng similar elements.
This issue for version element and master data dates (#9) are updated per approved comment at ISA-95 Meeting.

Additional Issue Addressed in This Solution
In Common.xsd, VersionType simply calls IdentiferType.
ETP recommend to MESA to simply the B2MML implementation by deleting Version Type and changing all Version elements to IdentifierType.
Current Common.xsd
<xsd:complexType name="VersionType">
xsd:simpleContent
<xsd:restriction base="IdentifierType"/>
</xsd:simpleContent>
</xsd:complexType>

EXAMPLE SOLUTION
complexType name = "MaterialClassType"
element name = "Version" type = "IdentifierType" minOccurs = "0"/>

Impacted Types:

WorkflowSpecification, WorkflowSpecificationNodeType, WorkflowSpecificationConnectionType

Equipment.xsd:
EquipmentClassType DONE
EquipmentType DONE

Material.xsd:
MaterialClassType DONE
MaterialDefinitionType DONE
MaterialLotType DONE
MaterialSublotType DONE

PhysicalAsset.xsd:
PhysicalAssetClassType DONE
PhysicalAssetType DONE

Personnel.xsd:
PersonnelClassType DONE
PersonType DONE

MasterDataProfile.xsd:
MasterDataProfileHeaderType DONE

OperationalLocation.xsd:
OperationalLocationClassType DONE
OperationalLocationType DONE

OperationsEvent.xsd:
OperationsEventClassType DONE
OperationsEventDefinitionType DONE
OperationsEventType DONE

ProcessSegment.xsd:
ProcessSegmentType DONE

OperationsDefinition.xsd:
OperationsDefinitionType DONE
OperationsSegmentType DONE
OperationsMaterialBillType DONE
OperationsMaterialBillItemType DONE

OperationsSchedule.xsd:
OperationsScheduleType DONE
OperationsRequestType DONE
OpSegmentRequirementType DONE

OperationsPerformance.xsd:
OperationsPerformanceType DONE
OperationsResponseType DONE

OperationsCapability.xsd:
OperationsCapabilityType DONE
OpProcessSegmentCapabilityType DONE
OpOperationsSegmentCapabilityType DONE

WorkDefinition.xsd
WorkDefinitionType DONE

WorkflowSpecification.xsd:
WorkflowSpecificationType DONE
WorkflowSpecificationNodeTypeType DONE
WorkflowSpecificationConnectionTypeType DONE

ResourceRelationshipNetwork.xsd
ResourceRelationshipNetworkType DONE
ResourceNetworkConnectionTypeType DONE

WorkSchedule..xsd
WorkScheduleType DONE
WorkRequestType DONE
JobListType DONE
JobOrderType DONE

WorkPerformance.xsd
WorkPerformanceType DONE
WorkResponseType DONE
JobResponse DONE
JobResponseListType DONE

WorkCapability.xsd
WorkCapabilityType DONE
WorkMasterCapabilityType DONE

WorkAlert.xsd
WorkAlertDefinitionType DONE
WorkAlertType DONE

WorkCalendar.xsd
WorkCalendarDefinitionType DONE
WorkCalendarDefinitionEntryType DONE
WorkCalendarType DONE

Common.xsd:
OperationsRecordSpecTemplateType DONE
OperationsRecordTemplateType DONE
OperationsRecordEntryTemplateType DONE
TestResultType DONE

BatchML-BatchInformation.xsd
ApprovalHistoryType DONE
ControlRecipeType DONE
ListHeaderType DONE
MasterRecipeType DONE
RecipeElementType DONE
-- Commonly used elements -- DONE

Update ProcessSegmentType to align with updated 950002

Background
Align complexType name = "ProcessSegmentType" in ProcessSegment.xsd with updated 950002 Process Segment Model.

Supporting Documents
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 5.8.2 Process segment,

• Table 75 – Process segment relationship roles
• Table 76 – Process segment attributes

Impacted Types and Solution
B2MML-ProcessSegment.xsd

• ProcessSegmentType

CHANGE: #12 element name = "ProcessSegment"
TO: element name = "ProcessSegmentChild"

ADD: element name = "DependentProcessSegmentID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: #32 element name = "ProcessSegmentPatternID" type = "IdentifierType" minOccurs = "0"/>

#2 Since updated 950002 relationship role naming convention only names the target element and not source element, the existing instances of source elements in B2MML shall not be deleted to align with the updated standard but shall change the element name to XXXSourceID to make the role explicit in the object and it B2MML type to be schematically correct, MESA B2MML implementation is inconsistent in it use of source elements across the schema.
CHANGE:

• element name = "CorrespondsToWorkMasterID"
  TO: "WorkMasterSourceID"
• element name = "CorrespondsToOperationsSegmentID",
  TO: "OperationsSegmentSourceID"
• element name = "CorrespondsToSegmentRequirementID"
  TO: "SegmentRequirementSourceID"

These elements are the source of the "Corresponds To" unidirectional relationship, not the target, element; The current element names are very confusing since process segment DOES NOT "correspond to" the source element.

ERDi design rule for creating a set of common types outside standard types.

B2MML creates common types for each element and subelement in the common schema; Many of the common types in the common schema simply reference common types like codeType, IdentifierType, string, etc. In the BHP JSON, we just used common types like string, array, object, etc. What is the ERDI design rule?

Update WorkDirectiveType in WorkDefinition.xsd to align with updated 950004

Background
Align complexType name = "WorkDirectiveType" in WorkDefinition.xsd with updated 950004 Work Definition Model.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.6 Work directive relationship roles and attributes,
Table 28 – Work directive relationship roles
Table 29 – Work directive attributes

Impacted Types and Solution
B2MML-WorkDefinition.xsd

• "WorkDirectiveType"

Align with updated 950004 Table 28 – Work directive relationship roles
CHANGE: #12 element name = "WorkDirective"
TO: "WorkDirectiveChild"

ADD: element name = "WorkDirectiveState"
This is a new attribute for Work Directive object to align with other state attributes for the Job Order State Model. Comment approved by 95 Committee at October 28th 2019 meeting.

CHANGE: #2 element name = "JobOrderID"
TO: JobOrderSourceID
Since updated 950002 relationship role naming convention only names the target element and not source element, the existing instances of source elements in B2MML shall not be deleted to align with the updated standard but shall change the element name to XXXSourceID to make the role explicit in the object and it B2MML type to be schematically correct, MESA B2MML implementation is inconsistent in it use of source elements across the schema.
In Table 28, the Job Order element is the source of the "Corresponds To" unidirectional relationship between Work Directive and Job Order objects; element is not the target, so Work Master and Work Directive objects do not "correspond to" the source element and the type should not reference the relationship source in this schema.

Duplicate: Update OpxxxActualPropertyType to align with updated ISA-950002

Closed: Duplicate of Issue #12 and #75

Background

ADD element name = "xxxActualPropertyChild";
ADD element name = "xxxClassPropertyID";
ADD element name = "xxxPropertyID"

Supporting document

Take Personnel Actual as an example,

ISA-950002
Section 6.3.7

Impacted Types

B2MML-OperationsPerformanceTypes.xsd
OpPersonnelActualPropertyType
OpEquipmentActualPropertyType
OpMaterialActualPropertyType
OpPhysicalAssetActualPropertyType

Extra Change

Below change is tracked by #53

DELETE element name = "RequiredByRequestedSegmentResponse"

Remove TestResult from xxxPropertyType

Related to ##16, #101

MESA

MESAInternational/B2MML-BatchML#44

Background

1. B2MML 7.0 still has the TestResult element in each instance resource property type per the old version of ISA-95 resource models and B2MML 6.0. The old resource model had an association relationship from each resource property to the Test Result object which did not allow Test Result object to be exchanged and queried as a 1st class object and did not allow Test Result object to be related to resource actuals.

2. The updated 950002 as part of the collaboration with OAGi changed Test Results to a 1st order object as part of the Operations Test Model.

3. ADDED new OperationsTest.xsd schema #101 with TestSpecificationType and TestResultType which allows 1st order transactions for both types. I do not believe that the 1st order transactions for both types were added to the updated 950005.

4. B2MML 7.0 beta only has B2MML-TestSpecification.xsd schema and has complex types of "TestResultType" and TestPropertyMeasurementType in the Common Schema.

5. In the new Operations Test Model in updated 950002, Test Result object is a 1st order object that is able to be exchanged/queried and has relationship to resource actual which is represented as a root element.

6. The MESA Committee may reject changing their implementation. If so, ERDi should create per updated standard.

Supporting Documents

1. Clause 5.9.1 Operations test model

2. Each of following resource models in updated 95002 do not have a Test Result object in their resource property objects. In the Operations Test Model, each of following resource models do have a Testable Object object that are target role in an association relationship from the Test Result object.
   Clause 5.4.1 Personnel model
   Clause 5.5.1 Role-based equipment model
   Clause 5.6.1 Physical asset model
   Clause 5.7.1 Material model

3. The following resource actual objects have a Test Result attributes per the Operations Test model
   Clause 6.3.6 Personnel actual, Table 208 – Personnel actual relationship roles
   Clause 6.3.8 Equipment actual, Table 212 – Equipment actual relationship roles
   Clause 6.3.10 Physical asset actual, Table 216 – Physical asset actual relationship roles
   Clause 6.3.12 Material actual, Table 220 – Material actual relationship roles

Impacted Types and Solutions
B2MML - Equipment.xsd, EquipmentPropertyType
B2MML - Material.xsd, MaterialLotPropertyType
B2MML - PhysicalAsset.xsd, PhysicalAssetPropertyType
B2MML - Personnel.xsd, PersonPropertyType

DELETE: TestResult element

Update WorkflowSpecificationType to align with updated 950004

Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.2 Workflow specification.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.2 Workflow specification
Table 31 – Workflow specification relationship roles
Table 32 – Workflow specification attributes

Impacted Types and Solution
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationType"

Align naming more closely with updated 950004 Workflow Specification Model to reduce user confusion.
CHANGE:

• element name = "Node" minOccurs = "0" maxOccurs = "unbounded"/>
  TO: "WorkflowSpecificationNode" minOccurs = "1" maxOccurs = "unbounded"/>
• element name = "Connection"
  TO: "WorkflowSpecificationConnection"
• element name = "WorkflowSpecificationProperty" type = "WorkflowPropertyType"
  TO: "WorkflowSpecificationProperty" type = "WorkflowSpecificationPropertyType"

Add Disposition element to MaterialLotType and MaterialSubLotType in Material.xsd to align with updated 950002

MESA Reference

MESAInternational/B2MML-BatchML#36

Background

Charlie's comment (modified to cover all changes)

ERDi, MESA: ADD element name = "Disposition", type = "DispositionType" to align with updated ISA-95 Part 2 Material Lot and Material SubLot Object. Add DispositionType to Common Schema.

Impacted Types

B2MML - Material.xsd

• MaterialLotType
• MaterialSubLotType

Supporting Document

950002 JWG5 CDV01 version (2019 12)
Clause 5.7.6 Material lot, Table 69 – Material lot attributes
Clause 5.7.8 Material sublot, Table 73 – Material sublot attributes

Related Issues

#19

Update EquipmentType and EquipmentClassType to align with updated 950002

MESA

MESAInternational/B2MML-BatchML#37

Background and Solution

Equipment.xsd
complexType name = "EquipmentType"

CHANGE: element name = "EquipmentLevel" type = "HierarchyScopeType" minOccurs = "0" />
TO: type = type = "EquipmentLevelType" minOccurs = "0" />
ADD element name ="PhysicalAssetID" type = "IdentifierType" minOccurs = "0"/>
ADD element name = "OperationalLocationType" type = "ResourceLocationTypeType"

complexType name = "EquipmentClassType">

CHANGE: element name = "EquipmentLevel" type = "HierarchyScopeType" minOccurs = "0" />
TO: type = "EquipmentLevelType" minOccurs = "0" />

Supporting Document

ISA-950002 JWG5 CDV01 version (2019 12)
Clause 5.5.2 Equipment class
Table 40 – Equipment class attributes
Clause 5.5.4 Equipment
Table 43 – Equipment relationship roles
Table 44 – Equipment attributes

Impacted Type

B2MML-Equipment.xsd

• EquipmentType
• EquipmentClassType

Delete WorkflowPropertyType used for WorkflowSpecificationProperty element in WorkflowSpecificationType to align with updated 950004

Background
ERDi, MESA:
The original B2MML complexType name = "WorkflowPropertyType" is incorrect and confusing since it does not align with updated 950004.

Impacted types
B2MML-WorkflowSpecification.xsd

• WorkflowSpecificationType
• WorkflowPropertyType
  -WorkflowSpecificationPropertyType

Solution

1. DELETE: complexType name = "WorkflowPropertyType"
2. complexType name = "WorkflowSpecificationType", WorkflowSpecificationProperty element,
   CHANGE: "WorkflowPropertyType"
   TO "WorkflowSpecificationPropertyType"

Other changes to updated "WorkflowSpecificationPropertyType" already covered by other issues,

Supporting document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.3 Workflow specification property

TestSpecificationID instead of xxxxTestSpecificationID should be included in testable object definition

Refer to #10 where this issue and solution are part of the complete explanation and solution across all types. Duplicate with closed #14 and #15.

Background
In the B2MML, all instances of the XXXTestSpecificationID element should be changed to TestSpecificationID to align with updated 950002 Operations Test Model.
Also general use of TestSpecificationID aligns with the existing OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinitionType.
MESA may not do this solution. ERDi should.

Impacted Types and Solution
ERDi, MESA: MaterialClassType:
CHANGE: MaterialTestSpecificationID element
TO: TestSpecificationID

The following Types shall be changed similiarly:

• MaterialDefinitionType/MaterialTestSpecificationID
• MaterialLot/MaterialTestSpecificationID
• EquipmentType/EquipmentCapabilityTestSpecificationID
• EquipmentClassType/EquipmentCapabilityTestSpecificationID

Change UsesPropertiesOfXXXXID to represent the two different specialization use cases in Updated 950002 and 950004

COMPLETE ISSUE EXPLANATION with all running comments incorporated. Related to #35
Background:
The required object and relationship updates for the proposed solutions were approved in comments to the ISA95 Committee October 2019 Meeting.
In analyzing the updated 950002 and 950004 "Includes properties of" specialization relationships and then researching on best practices of UML and XML, the current relationship and target role names are incorrect and not best practice for this type of relationship. Recommended Solutions below.
"IncludesPropertiesOf" relationship in the ISA-95 models actually address 2 very different specialization use cases in terms of UML and XML generalization and specialization best practice. Both explained below. The B2MML implementation uses only the "IncludesPropertiesOfXXXID" convention (or similar) for both uses which is semantically and logically incorrect.

Overlapping Specialization Use Case (member of a grouping, 0..*)

1. The specialization"IncludesPropertiesOf" relationship on the objects addressing the Overlapping Specialization Use Case shall not be renamed.

2. Overlapping Specialization (0..* for target element) where source element uses the properties of each identified group to define a specialization class of classes.

3. In updated 950002 and 950004, the original defined Target Role name of XXXParent for "IncludesPropertiesOf" relationships in models is not correct for the relationship semantics and logic; the Target Role is now approved as XXXBase for 0...* as list of member classes in a specialization group where the source object maps to the properties of the group members.

4. Supporting Documents. This change applies to following objects
   ISA-950002 JWG5 CDV01 version (2019 12)
   Clause

• 5.3.2 Operational location class, Table 21 – Operational location class relationship roles
• 5.4.2 Personnel class, Table 30 – Personnel class relationship roles
• 5.5.2 Equipment class, Table 39 – Equipment class relationship roles
• 5.6.2 Physical asset class, Table 49 – Physical asset class relationship roles
• 5.7.2 Material class, Table 60 – Material class relationship roles
• 5.11.2 Operations event class, Table 125 – Operations event class relationship roles (multiplicity is wrong, the approved ISA-95 change comment is for 0..1 to 0..*, relationship only for specialization group defined cumulative properties set)

ISA-950004 JWG5 CDV01 version (2019 12)
Clause

• 6.16.8 Workflow specification node type, Table 43 – Workflow specification node type relationship roles (Approved ISA-95 Comment to add new relationship to object)
• 6.16.10 Workflow specification connection type, Table 47 – Workflow specification connection type relationship roles (Approved ISA-95 Comment to add relationship to object)

SOLUTION:
Overlapping specialization (0..*) applies to figures and tables above.

1. CHANGE: Target Role name from XXXParentID to XXXBaseID in the relationship role tables for each Clause above and associated B2MML Type. This relationship for a specialization group is a cumulative properties set of base classes for the source where each member contributes to the specialized properties of the source.
   SAMPLE: <xsd:element name = "WorkflowSpecificationNodeTypeBaseID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>

2. OperationsEvent.xsd, OperationsEventClassType
   CHANGE: For OperationsEventClassBaseID element, change multiplicity from 0..1 to 0..* for “includes property of” association relationship; Like material class, Operations Event Class “includes properties of” relationship is a grouping (not an instance-to-pattern use case).

3. WorkflowSpecification.xsd, WorkflowSpecificationNodeType
   DELETE: WorkflowSpecificationNodeParentID for "Uses Properties Of" relationship from 950004 on the Workflow Specification Node object in:

• ISA-950004 JWG5 CDV01 version (2019 12) Clause 6.16.1 Workflow specification model, Figure 5 – Workflow specification model.
• ISA-950004 JWG5 CDV01 version (2019 12) Clause 6.16.3 Workflow specification node, Table 35 Workflow specification node relationship roles. This is a mistake since object is an instance and not a class, type, or definition.

4. WorkflowSpecification.xsd, WorkflowSpecificationNodeTypeType
   ADD: WorkflowSpecificationNodeTypeBaseID element for NEW "Includes Properties Of" relationship

• ISA-950004 JWG5 CDV01 version (2019 12) Clause 6.16.1 Workflow specification model, Figure 5 – Workflow specification model, Workflow Specification Node Type object
• ISA-950004 JWG5 CDV01 version (2019 12) Clause 6.16.7 Workflow specification node type, Table 43 – Workflow specification node type relationship roles

5. WorkflowSpecification.xsd, WorkflowSpecificationConnectionTypeType
   ADD: WorkflowSpecificationConnectionTypeBaseID element for NEW "Includes Properties Of" relationship

• ISA-950004 JWG5 CDV01 version (2019 12) Clause 6.16.1 Workflow specification model, Figure 5 – Workflow specification model, Workflow specification connection type object
• ISA-950004 JWG5 CDV01 version (2019 12) Clause 6.16.10 Workflow specification connection type, Table 47 – Workflow specification connection type relationship roles

Exclusive Specialization (0..1 for target element)

1. The specialization"IncludesPropertiesOf" relationship shall be renamed "Defined by" relationship for the Exclusive Specialization Use Case (0..1 for Pattern vs. Instance) shall be renamed from XXXParentID to XXXPatternID.

2. The Target Role object's naming convention of the Exclusive Specialization Use Case (0..1 for Pattern vs. Instance) shall be renamed from XXXParentID to XXXPatternID.

3. The source object (instance or child pattern) in the "Defined by" association relationship uses a one specific Pattern object as a template for its objects and its properties.
   This type of relationship is supported by the Definition Type attribute on process definition objects by identifying the Pattern ID (target) for the (source) instance. This is why the multiplicity is 0..1.

4. The Pattern object lacks the details to be scheduled or executed where Instance object is able to be scheduled or executed. The Instance object is defined by Pattern object.

5. This "Defined by" association relationship does not define a class of classes where only properties are shared across a specialized group as in the Overlapping Specialization. The relationship applies to the sharing of the whole complex Pattern object with its composite objects and its properties in the Instance object (not to just properties of a single of object).
   This relationship applies across the object's attributes, relationships and their properties, not to just properties. This specialization relationship is very different than the "includes properties of" relationship which has a multiplicity of 0..* which uses properties from any objects to define a single object.

6. Supporting Documents. The changes of the relationship and relationship name are applied in the following object figures and tables:
   ISA-950002 JWG5 CDV01 version (2019 12)

• Clause 5.8.1 Process segment model,
  • Figure 14 – Process segment model
  • Table 74 – Process segment model relationships
• Clause 5.8.2 Process segment
  • Table 75 – Process segment relationship roles
• Clause 5.10.1 Operations record model
  • Figure 17 – Operations record model (abstract)
  • Table 117 – Operations record model relationships
• Clause 5.10.2 Operations record specification template (abstract)
  • Table 118 – Operations record specification template relationship roles
• Clause 6.1.1 Operations definition model,
  • Figure 20 – Operations definition model
  • Table 144 – Operations definition model relationships
• Clause 6.1.2 Operations definition
  • Table 145 – Operations definition relationship roles
• Clause 6.1.5 Operations segment,
  • Table 151 – Operations segment relationship roles
    ISA-950004 JWG5 CDV01 version (2019 12)
• Clause 6.1 Work Definition
  • Figure 3 – Work definition model
  • Table 22 – Work definition model relationships
• Clause 6.5 Work master relationship roles and attributes
  • Table 26 – Work master relationship roles
• Clause 6.16.1 Workflow specification model
  • Figure 5 – Workflow specification model
  • Table 30 – Workflow specification model relationships
• Clause 6.16.2 Workflow specification
  • Table 31 – Workflow specification relationship roles

SOLUTION:
Exclusive Specialization (0..1), single Pattern object template for an Instance object, applies the below changes to the objects in the list of figures and tables above.

1. CHANGE: Target Role name from XXXParentID to XXXPatternID in the relationship role tables for each Clause above and associated B2MML Type so it semantically correct for this use case.
   SAMPLE: <xsd:element name = "WorkflowSpecificationPatternID" type = "IdentifierType" minOccurs = "0"/>

2. ADD: #35 Definition Type element under each Type to support the object definition as either an instance or pattern template object. This reduces user confusion since name is more explicit to Pattern/Instance semantic purpose.

Supporting Document
The Supporting Documents are listed above. But the below paragraphs from Clause 6.1.1. and above Solution changes apply to the 950002 and 950004 Clauses for process segment, operations definition operations segment, work master, and workflow specification

950002, Clause 6.1.1 Operations definition model, paragraphs 4 to 6.
“An operations definition instance may be a specialization of pattern operations definition object. An operations definition shall be defined as pattern or instance. A pattern operations definition defines a ‘template’, upon which other or instance operations definitions may be based. Unlike instance operations definitions, pattern operations definitions shall not be directly scheduled or tracked. Therefore, operations requests and operations responses shall not reference pattern operations definitions.
Pattern operations definitions shall provide a basis for standardization and reuse of pattern operations definitions across many instance operations definitions across and between plants. Where an operations definition references a work master defined in Part 4 of this standard, the definition type (pattern or instance) attribute of the referenced work master shall have the same value as that of the operations definition.
The operations material bill and bill of resources of an operations definition may map to those of any pattern operations definition upon which the operations definition is based.
EXAMPLE 1 A pattern operations definition can reference an operations material bill that contains items referencing material classes, while a instance operations definition based on this pattern operations definition can reference an operations material bill that contains items referencing material definitions belonging to those material classes.
EXAMPLE 2 A mining organization could define the following pattern and instance operations definitions:
• loading (pattern);
• train loading (pattern), specialization of loading (pattern);
• ship loading (pattern), specialization of loading (pattern);
• Site S1 train loading (instance), specialization of train loading (pattern);
• Site S2 ship loading (instance), specialization of ship loading (pattern)”

Update WorkMasterType in WorkDefinition.xsd to align with updated 950004

Background
Align complexType name = "WorkMasterType" in WorkDefinition.xsd with updated 950004 Work Definition Model.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.5 Work master relationship roles and attributes, Table 26 – Work master relationship roles

Impacted Types and Solution
B2MML-WorkDefinition.xsd

• "WorkMasterType"
  Align with updated 950004 Table 26 – Work master relationship roles

ADD: element name = "OperationsDefinitionID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: element name = "OperationsSegmentID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: element name = "ProcessSegmentID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: element name = "WorkflowSpecification" type = "WorkflowSpecificationType" minOccurs = "0"/> (0..1: CHANGE from minOccurs = "0" maxOccurs = "unbounded"/>)
ADD: #35 element name = "DefinitionType"
CHANGE: #12 element name = "WorkMaster" TO "WorkMasterChild" to align with Part 4 Work Master relationship table.
CHANGE: #32 element name = "IncludesPropertiesOf" TO "WorkMasterPatternID" type = "IdentifierType" minOccurs = "0"/> (0..1: CHANGE from minOccurs = "0" maxOccurs = "unbounded"/>) to align with Part 4 Work Master relationship table.

ERDi Design Rule: Using "ID" for both single element (0..1) and multiple (n) elements (0..n)?

Where B2MML Schema uses a “xxxID” to reference other master data objects. B2MML explicitly define the ID for both single element (0..1) and multiple (n) elements (0..n) as collection. In the BHP JSON schema, the design rule was to use the common best practice of xxxId and xxxIds to be explicit between single vs. collections, respectively. What is the ERDi design rule?

ADD TestResult element to OpXXXActualType in OperationsPerformanceTypes.xsd to align with updated 950002

Background
ERDi, MESA: Related to #7, #101

1. Align TestResult element with updated 950002, Operations Test Model where the Test Result object has an association relationships with the resource actual objects.
   Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.

2. B2MML 7.0 beta only created a B2MML-TestSpecification.xsd schema and created the complex types of "TestResultType" and TestPropertyMeasurementType in the Common Schema.

3. HOWEVER, B2MML 7.0 still has the TestResult element in each instance resource property per the old version of ISA-95 resource models and B2MML 6.0. The old resource model had a composite relationship from the each resource property of the resource master data objects which did not allow Test Result attribute to be exchanged and queried as a 1st class object. This design has the logic issue where a test result is related to testing of a resource actual to a master data resource's test specification. The old resource models had a composite relationship which did not allow Test Result to be exchanged and queried as a 1st class object.

Supporting Documents
Clause 6.3.6 Personnel actual, Table 208 – Personnel actual relationship roles
Clause 6.3.8 Equipment actual, Table 212 – Equipment actual relationship roles
Clause 6.3.10 Physical asset actual, Table 216 – Physical asset actual relationship roles
Clause 6.3.12 Material actual, Table 220 – Material actual relationship roles

Impacted Type and Solutions
_OperationsPerformanceTypes.xsd,

• OpPersonnelActualType"
• OpMaterialActualType"
• OpEquipmentActualType"
• OpPhysicalAssetActualType"_
  ADD: "TestResult" type = "TestResultType" to align with updated Part 2 Operations Test Model's relationships.

Update WorkflowSpecificationConnectionType to align with updated ISA-950004

Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.5 Workflow specification connection.

Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.6 Workflow specification connection
Table 39 – Workflow specification connection relationship roles
Table 40 – Workflow specification connection attributes

Impacted Types and Solution
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationConnectionType"

CHANGE: Align naming more closely with updated 950004 Workflow Specification Model to reduce confusion.

• element name = "ConnectionType" type = "IdentifierType"
  TO: "WorkflowSpecificationConnectionTypeID type = "IdentifierType" minOccurs = "0" maxOccurs = "1"
• element name = "FromNodeID"
  TO: "FromWSNodeID"
• element name = "ToNodeID"
  TO: "ToWSNodeID"
• #51 element name = "Property", type = "WorkflowSpecificationPropertyType"
  TO: "WorkflowSpecifictionConnectionProperty", type = "WorkflowSpecificationConnectionPropertyType"

ADD: Align with updated 950004 Workflow Specification Model.

• element name = "Dependency", type="DependencyType"/>
• element name="DependencyFactor", type="ValueType" minOccurs="0"/>