Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
🔓 Public Page
Date:
Info |
---|
ANTITRUST STATEMENT As participants in this meeting, we need to be mindful of the constraints of antitrust laws. There shall be no discussions of agreements or concerted actions that may restrain competition. This prohibition includes the exchange of information concerning individual prices, rates, coverages, market practices, claims settlement practices, or any other competitive aspect of an individual company’s operation. Each participant is obligated to speak up immediately for the purpose of preventing any discussion falling outside these bounds. |
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 vinNumthe 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
- Mike Hastings to provide the Excel Document to Paulette to get into the Architecture Committee Work Documents
- Dan Webster to provide the documents he for POC using references and get them into GitHub
- CarPart.com team to provide some examples of schemas using objects
Decisions
- 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