2022-3-22 Architecture Meeting Minutes

Public Page

Date: Mar 22, 2022

Agenda

• Antitrust

• Committee Welcome

• Meeting Minutes Review

• CIECA Release and CIECAST

• Work through flattening and hierarchy

  • Review work by members

Meeting Minutes

• Antitrust Accepted

• Committee Welcome

  • As an effort to strengthen relationships between members, we will give everyone a few minutes to interact and share with each other. This is a great time to introduce new members.

  • Jeff Schroder introduced new technical team members that he invited. Brad Broerman, Aaron Daniele and Jeff Mueller are working on API initiatives and we think they will be a great resource to help us develop the API standards.

• Meeting Minutes Review/Accepted

  • In an effort to bring everyone up to date, we will review the meeting minutes highlights from the last meeting and any major decisions.

  • In review of the meeting notes it was mentioned that Modules should be models.

    • Corrections were made to the meeting minutes and accepted

  • Recommended to have an Agenda Posted prior to meeting to allow individuals to focus on the Homework task that they will be presenting. An Agenda being published before the meeting will allow everyone to prepare for the discussions, homework or not.

• CIECA Release and CIECAST

  • QA - April 5

  • Release - April 20

  • CIECAST - April 28

    • Stacey is working on a press release to get the information about the CIECAST shared to the industry. If you have not reviewed and provided feedback, please do so.

    • Stacey will send the latest updated document to Dan for Review.

• Flattening and Hierarchy

  • Mike shared a new Excel document that Jeff presented. The new columns represented how attributes of Vehicle are being used and how attributes are used differently in different messages.

    • For instance, if the part is a hood, then exterior color of the vehicle would be important. If the part is brake pad, the external color of the vehicle is not needed.

    • Another example was odometerInfo may need one field message1 but may need all 4 fields in message2.

  • The Excel document showed Object References that had 3 levels of hierarchy for Vehicle’s common aggregates.

  • The vehicle properties used for recycled part may be very few, where the estimate may use most. This is where the concept of VehilceLite, VehicleMed and VehicleMax came from. The Vehicle represented in the Excel document has 118 properties. Does Recycled parts have to use all 118 when they only want 2?

    • The Proof of Concept for referencing was to allow for VehicleInfo properties to be created in one schema and then any other needed version of VehicleInfo would reference the properties need from the Original.

      • The proof of concept Dan represented was a VehicleInfo with Object names that could be referenced and provide the properties to be listed together.

        • the use of "$ref": "vehicleCommonAggregatesSchema.json#/definitions/vinInfoType/properties/vinNum" would bring in only vinNum

        • the use of "$ref": "vehicleCommonAggregatesSchema.json#/definitions/licenseInfoType" would bring in all properties under the vehicleCommonAggregatesSchema LicenseInfoType

      • There was a concern that using $ref would mean the developers would have to develop mapping to handle this structure instead of using the Object structure.

    • The Excel document presented showed 7 categories common to part attribute and the concern was when they only need Odometer reading, would the 118 properties of VehiclInfo need to be brought in?

      • The idea of referencing would be “$ref”: “vehicleCommonAggregatesSchema.json#/definitions/odometerInfoType could be used to just get Odometer Info or $ref:” “vehicleCommonAggregatesSchema.json#/definitions/odometerInfoType/properties/odometerReading could be used to just receive the OdomterReading

      • The other proof of concept being proposed is to have Each aggregate its own object, so odometerReading would be an object and vehicleInfo would be an object.

  • Questions about the approaches

    • We need to look at the Pros and Cons of each approach

      • Data Mapping

      • How to use with endpoints

      • no duplication

Great Meeting Everyone!

Up Next

• Antitrust

• Committee Welcome

• Meeting Minutes Review

• Look at the Examples of the approaches proposed and work through the pros and cons and determine the best approach.

Action items

Decisions

1. The Next meeting will be extended to 2 hours so we have more time to discuss the approaches proposed.

Participants

• Paulette Reed

• Dan Webster

• Andy Bober

• Paul Barry

• Brad Broerman

• Mike Hastings

• Jeff Mueller

• Aaron Daniele

• Jeff Schroder

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. Architecture Committee