Public Page

2021-12-14 Architecture Meeting Minutes

Owned by Paulette Reed
Last updated: Dec 16, 2021
4 min read

Public Page

 

      
   CIECA 500 Westover Dr  #11617; Sanford,  NC  27330 

 

Date

Dec 14, 2021

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 and Meeting minutes acceptance

  • Vehicle Proof of Concept

Meeting Minutes

  • Antitrust Accepted

  • Meeting Accepted

  • Mike had a Point of Concept with BMS Chapter 9 Add Repair Facility, Create New Repair Facility | Repair Facility API (stoplight.io)

    • Repair Facility is not complete in this example, this example is to show how to use the JSON Verbs Get, Update, Create and Delete.

    • Shows how to use different endpoints

    • This is Point of Concept for the Verbs not the Schema

  • Clarification that CIECA is not coding APIs

    • The Verbs and APIs created are Examples or Test Instances that the Proof of Concepts in the Schemas work.

    • These are examples of how to use the CIECA Standards in API development

  • A Spreadsheet was created to help look at the Concept of Vehicle Lite, Vehicle Med and Vehicle Lg.

    • Concern of having different versions of Vehicle that may create confusion; analysis was done to look at the BMS Common Aggregates and how they were used with the other Chapters(s) of BMS with Messages and other aggregates.

    • The first tab in the document goes over all the Test Instances that we have today for the BMS that uses Vehicle Info and how the fields of VehicleInfo is used.

    • The Second Tab shows the Cross Reference of all the Common Aggrregates and how the other Messages and Aggregates use them.

      • There are Aggregates of VehicleInfo, such as VehicleDesc that is used in messages when the VehicleInfo is not used; this makes it seem like we should not combine VehicleDesc into VehicleInfo. M

      • Would it be better just to Flatten all the Common Data Aggregates and Aggregates and just use them as unnamed Objects?

      • There are only 4 Fields in VehicleInfo that is not an Aggregate, all the other fields is an optional aggregate. We remove the hierarchy by removing Vehicle Info instead of removing some fields that may need to be used in other areas.

    • The Remaining Tabs are the BMS Aggregates flattened without Aggregates to show the concept of using the Common Data Aggregates at their lowest Hierarchy.

  • We need to work on creating a Schema that will provide the best standards and how to document this?

    • We can use unnamed objects to pull in groups.

    • We can use unnamed objects only when we need an array, and all of the fields could be in one schema and everyone could use $Ref to pull in only the fields they would need.

    • With Documenation Would we just have one schema, how would people find all of the values they are needing?

      • Some people like Alphabetical names

      • Others like Group by Area.

        • If we group by Vehicle, then people could see all of the Vehicle fields and if something is not named as expected, they still may be able to find the field?

    • In an old project for Parts, the PartInfo was almost complete and then it was determined to move the object into Common Aggregates, this was brought up as an example of how working through things you will find scenarios that help you see something differently.

  • The original VINDecoder Proof of concept Flattened Vehicle Info and the fields were picked based off VehicleInfo that were included and dropped. This would be something for each Committee to review, but it is not easy to document the process for others to follow.

  • It is hard to know the properties that are not used and causing the BMS to have bulk data, but we do know having too many fields will cause the API to break.

  • The concept of Common Data Aggregates being moved to long list of Reference properties for JSON is next item for topic and how do we group these fields for the best documentation.

Great Meeting! We almost went over because we were so busy and productive! Have a Great Holiday!

Up Next

  • Antitrust and Meeting minutes acceptance

  • Andy presentation on Automation

  • Common Data Aggregates as List and how to group

Participants

  • Paulette Reed (Scribe)

  • Paul Barry

  • Pete Sheehan

  • Dan Webster

  • Brad B

  • Stacey Phillips

  • Chrisa Hickey

  • Mike Hastings

  • Phil Martinez

  • Tapas Sarangi

  • 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