2021-11-9 Architecture Meeting Minutes

   CIECA 500 Westover Dr  #11617; Sanford,  NC  27330 

Date

Nov 9, 2021

Agenda

• Antitrust and Meeting minutes acceptance

• Phone number review and propose a solution

  • BMS Phone Number Review of 2017 changes to ITU E.164

• Concerns of Proof of Concept

• Review Documentation proposals and discuss which works best

• Decide what’s next, Dan worked on a number of Data aggregates, think we should finish them.

Meeting Minutes

• Antitrust Accepted

• Meeting Accepted

• In reviewing phone numbers it was noticed that the BMS had two sections for Phone Number and they were numbered the same. It was determined to delete the first paragraph and keep the second. A Jira was created to do this work in 2022R1. After the meeting it was determined that the duel phone numbers were in place since 2017.

  • The BMS is working as expected, and no changes to the BMS and Schema for XML is planned at this time, it seems that the trading partner needs to be informed of the standards and the phone number pattern.

  • The API phone number format will be tabled until a later meeting. At some time JSON had a phone number pattern, but they deleted the attempt and there is no longer a standard JSON phone number pattern or simple type.

  • The original attempt to move BMS to JSON identified problems with the phone number pattern in JSON. The BMS phone number pattern caused the JSON messages not to validate.

• Concerns of Proof of Concept

  • The VIN decoding seemed to be a problem because of the VIN Decoder; it was recommended in a previous meeting that we change the name to not include Decoder. There is a new version of Vehicle/VIN Decoder that changed the name. It is believed that VIN Decoder is okay and can be used, that VIN Decoder was used to show a lite version of Vehicle.

  • The FNOL was thought to be a simple message and it was determined it was complex and a simple messages was looked at to achieve the proof of concept. The most simple in the collision was VIN Decoder, it is a valid message and this vehicle light can be used in many areas of the collision.

  • The Architecture Committee is trying to prove that we can take a BMS aggregate and slim it down into a JSON aggregate that is simpler and does not use the nesting and complexity of the BMS. The Vehicle light seems to do this.

  • The concept we are trying to prove is to have an object in JSON schema that we can use in API development. The Vehicle object for VIN Decoder does this.

• Steps taken for the Proof of Concept

  • First step was to create JSON from the BMS (This was prior to CAPIS)

  • Then we looked at the naming standards that needed to be followed

  • Created Simple Types that would be needed in JSON

  • Flattened BMS Common Global Types; Vehicle

    • Flattened means we first removed all nested aggregates and moved in to the top level

    • Second the data was looked at and some elements that were optional was removed

    • Third if new data elements were identified, we could add elements that are not in the BMS

  • Used Bundling Concept so we could have properties be smaller because all the data would not be required for every message

• Look back at Vehicle

  • The FNOL Vehicle had the elements that still remain in Vehicle Lite, but it also had Admin Info to identify the people related to the FNOL, it had information for seatbelt usage, and information for assignment. Those are all things that are not needed if you just want vehicle information.

• Questions on Vehicle versions.

  • We know that each message may need different data of Vehicle, so how do we go about having different levels of vehicle and not having to duplicate Vehicle (Vehicle Lite, Vehicle Medium, Vehicle Large, Vehicle XL). Different versions of Vehicle would make standards hard to follow and updates even more difficult.

  • The Simple Types and Code list will be reused, but how do we get the Common Data Aggregates from the BMS to be reused? As mentioned above, for some messages the Vehicle will need License, which has State and dates and then Odometer which has odometer reading information. This is the complexity and the next level of what the Architecture Committee needs to work on to help take the proof of concept to the next level.

  • Is Odometer a Simple Type or Anonymous object that can be referenced in vehicle? The Anonymous object instead of a named object brings in children without parents, so no nested or complex hierarchy.

  • Also before Proof of concept can be completed, we need to work with more JSON verbs, PUT and POST, so show the full circle.

• VIN Decoder completed the Proof of concept that it needed to, now we need more APIS.

• New Project with Vehicle

  • VIN decoder was proof of concept that the steps will provide a valid schema. The work product is to

    • define flattening and how we remove the hierarchy

    • how we renamed the BMS objects to fit the JSON Style guide

  • Side by Side comparison to see the criteria to be included and excluded so we know how to show the flattening to other committees for them to duplicate.

• Action Items

  • Dan is going to look at the Flattening Excel format for the Vehicle Lite

  • Dan will work on the Anonymous concept for bundling objects to have the committee review in next meeting.

Up Next

• Antitrust and Meeting minutes acceptance

• CIECA User Forum on cieca.com

• Review Vehicle Lite document to show flattening

• Review Anonymous Concept for bundling

Participants

• Paulette Reed (Scribe)

• Paul Barry

• Dan Webster

• Mike Hastings

• Brad B

• Jeff Schroder

• Andy Bober

• Tapas Sarangi

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. https://cieca.atlassian.net/wiki/spaces/ARCH