search

ETPartners / b2mmlv7beta

b2mmlv7beta for review
2 stars 3 forks source link

Change 0..* multiplicity to 1..* for "is made up" composite relationship in OperationsSchedule.xsd, OperationsPerformance.xsd, WorkSchedule.xsd, and WorkPerformance.xsd to align with updated 950002. #79

Open CharlieG021163 opened 5 years ago

CharlieG021163 commented 5 years ago

Background B2MML has the following relationships as 0... In updated 950002, Operations Schedule model, the multiplicity for the "is madeup of" composite relationship between Operations Schedule and Operations Request and between Operations Request and Segment Requirement is 1...

Operations Performance model, the multiplicity for the "is madeup of" composite relationship between Operations Performance and Operations Response and between Operations Response and Segment Response is 1..*.

In updated 950004, Work Schedule model, the multiplicity for the "is madeup of" composite relationship between Work Schedule and Work Request and between Work Request and Job Order is 1..*.

Work Performance model, the multiplicity for the "is madeup of" composite relationship between Work Performance and Work Response and between Work Response and Job Response is 1..*.

Supporting Document ISA-950002 JWG5 CDV01 version (2019 12) Clause 6.2.1 Operations schedule model, Figure 21 – Operations schedule model Clause 6.2.2 Operations schedule, Table 174 – Operations schedule relationship roles Clause 6.2.3 Operations request, Table 176 – Operations request relationship roles Clause 6.3.1 Operations performance model, Figure 22 – Operations performance model Clause 6.3.2 Operations performance, Table 200 – Operations performance relationship roles Clause 6.3.3 Operations response, Table 202 – Operations response relationship roles

ISA-950002 JWG5 CDV01 version (2019 12) Clause 7.1 Work schedule model, Figure 8 – Work schedule model Clause 7.2 Work schedule, Table 52 – Work schedule relationship roles Clause 7.3 Work request, Table 54 – Work request relationship roles Clause 8.1 Work performance model, Figure 14 – Work performance model Clause 8.2 Work performance, Table 62 – Work performance relationship roles Clause 8.3 Work response, Table 64 – Work response relationship roles

Impacted Types and Solution OperationsSchedule.xsd complexType name = "OperationsScheduleType", element name = "OperationsRequest" type = "OperationsRequestType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

complexType name = "OperationsRequestType", element name = "SegmentRequirement" type = "OpSegmentRequirementType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

OperationsPerformance.xsd complexType name = "OperationsPerformanceType", element name = "OperationsResponse" type = "OperationsResponseType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

complexType name = "OperationsResponseType", element name = "SegmentResponse" type = "OpSegmentResponseType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

WorkSchedule.xsd complexType name = "WorkScheduleType", element name = "WorkRequest" type = "WorkRequestType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

complexType name = "WorkRequestType", element name = "JobOrder" type = "JobOrderType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

WorkPerformance.xsd complexType name = "WorkPerformanceType", element name = "WorkResponse" type = "WorkResponseType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

complexType name = "WorkResponseType", element name = "JobResponse" type = "JobResponseType" CHANGE: minOccurs = "0" maxOccurs = "unbounded"/> TO: minOccurs = "1" maxOccurs = "unbounded"/>

racheliurui commented 5 years ago

Agreed, Because if not, those parent types won't contain any useful information.

Dennis-Brandl commented 4 years ago

I disagree with this change. We purposefully made the relationships 0..n instead of 1..n in order to support the transactions of Part 5, so you could send a partial object and get the complete response.