Page Comparison

Date

21 Sep 2021

Agenda

• Antitrust and Meeting minutes acceptance

• Review Options Code from Emerging Tech for 2020R2 Approval

• Phone Number format is US and more companies are needing International phone number for XML

• Continue to discuss Bundling after everyone can review.

• Get Vehicle proof of concept

Meeting Minutes

• Antitrust Accepted

• Meeting Minutes Accepted with a few Minor changes from Dan

• Options Code was reviewed, however the committee would like to have them sent to them Via email to review

  • For Codes that existed before but in a different category like APA, we could change the description and keep the code

• Reviewed Mikes changes to VIN Info

  • New Manufacturer Option Code (Open Code List)

  • New Valve Type (currently 3 values)

  • New Fuel Injection Type

  • New Transmission Type

  • New Cab Configuration (Trucks)

• Mike used the Bundling tool

• Need to Add descriptions

• Yamal file is smaller with around 1500 lines

• Model Year was changed to String

• Questions on the New Transmission Type and Transmission Speeds

  • We currently have a code list with over 60 values for Transmission

  • Mike got the proposed values of Transmission Type and Transmission Speed from Government site

• Proposal to look at how we want to handle Code List in Open API

  • the cryptic codes that were used in EMS were carried over to the BMS, however, open API use longer fields and descriptions instead of codes.

  • We can use the same Master Code List that we have today, but use the descriptions?

  • With Open API we should move away from the Short codes

  • Descriptions could cause duplicates

  • Proposal is to use Descriptions.

• Slimming of Current BMS Aggregates

  • In the past we followed an Architecture that if an aggregate was longer than 10, we would move it to its own Aggregate, this causes a complex Hierarchy

  • We removed the Hierarchy from Vehicle Info and other BMS Aggregates

  • We then removed some fields that we seen as no longer necessary

  • We need to remove more values based on things like towing and total loss values that we do not need for Vehicle Info

• VIN Decoder

  • We will send a VIN and get data back specific to that VIN

  • The Proof of Concept was removed from FNOL because it was more complex than originally thought and we could not get examples of the XML messages that were used today to determine what was required and what could be removed.

  • VIN Decoder was decided to used in replace of FNOL because the Architecture Team is Familiar with Vehicle.

  • The Concern that everyone already has a VIN Decoder and there are numerous versions, who is going to use a CIECA Standard VIN Decoder? They already have these services and trust them. In the past, CIECA only provided the schema for the data, are we writing services now?

  • CIECA is not providing Services but Providing Standards for Services. The CIECA Specifications for Services. A CIECA Member can download and implement the service how they desire.

  • There are many versions of VIN Decoder, which is a reason that we should do a VIN Decoder to help with the standards.

  • Request of Quote is another possibility for Proof of Concept, but there could be one or multiple calls.

  • The Business Community will see it as Decoder that they already have if we continue with the name Decoder.

  • We will rename the VIN Decoder to Get VIN, this will bring back Vehicle VIN information

    • We already have a VIN Info in the BMS

      • VIN Availability field

      • VIN Aggregate which has VIN Decode Source, VIN Format, VIN Number, VIN Decode Indicator, and VIN Decode Status.

• Should we still call it Get Vehicle?

  • We took common types, simple types and they would reference small groups but it showed all bundling package will build subset of what you need for Vehicle.

  • Vehicle Info is in Common Global and it needs to be broken out.

Good Discussion and Meeting. Next weeks meeting will be cancelled for CONNEX.

• Welcomed Tapas to the Architecture Committee

• A Doodle Poll was created to find the best time for QA, please fill that out ASAP.

• Reviewed Master Code List additions to Options Tab

  • All of the Codes that were not duplicates of older codes were approved.

  • All duplicates, such as APA, we will remove and leave the Code and description in the original category.

  • The question of do we need Blind Spot Monitor and Blind Spot Warning, will be taken back to the Emerging Technologies committee.

  • The question was brought up if we validated the codes being added did not duplicate existing codes.

    • Yes, Paulette did verify the new codes were unique.

    • It would be nice if the build process or QA process had a test to verify there were no duplicates. Andy accepted this challenge.

• Phone Number to be International

  • The proposal to make the BMS Phone Number international in format was proposed by Entegral.

  • The BMS format was reviewed and it was intended to be international format, however both EHI and Mitchell have experienced phone number validation errors with this format.

  • Newer developers would rather use Google to send numbers and it execute the formatting and validation.

  • Andy is going to review the errors for phone number that they have seen and come back with a proposal for the fix.

  • Also JSON phone number format will be international.

• Bundling

  • For a few weeks the committee has been discussing bundling concept.

  • Due to more member participation this week, Dan gave an overview of what work has been going on with the committee and the proposed approaches.

    • The Committee started with simple types and common aggregates for FNOL.

    • These aggerates were simplified by removing the hierarchy of elements to the upper level.

    • This still left the data aggregates very large and complex.

    • Fields were then removed that the committee did not see as being value added or needed with new implementations.

    • The JSON structuring for complex schema was still causing issues, therefore the bundling tool was looked at.

    • Bundling tool will go to the source schema in an external reference and pull back the fields needed and not the entire schema.

    • The two ways to pull in common data aggregates:

      • $id brings in the entire schema

      • The bundling tool will bring back only the necessary fields

    • At this time, Mike has been doing the bundler manually and would like a tool to automate this process.

    • Bundling Tool Documentation is at Structuring a complex schema — Understanding JSON Schema 2020-12 documentation (json-schema.org)

  • Team will review bundling and discuss more next week, but at this time, bundling is the process the Architecture Committee is recommending.

• Vehicle Info

  • Mike had some homework to add transmission back into Vehicle and we reviewed that.

  • We need to get Tapas access to Git/Stoplight and Slack

  • Do we go back to hierarchy in data aggregates, build subsets of data and reference them with the bundling tool or create different versions of common aggregates (VehicleInfo, VehicleLite)?

    • Committee wants one version of the truth, we do not want different Vehicle objects

    • We hope to not copy and only pull necessary data.

  • GraphQl will allow a model to be defined then quieris are done to get the data for the messages the customer/user wants.

    • Tapas will do a demo of GraphQl at the next meeting.

Great Meeting

Up Next

• Antitrust and Meeting minutes acceptance

• Review Options Code from Emerging Tech for 2020R2 Approval

• Phone Number format is US and more companies are needing International phone number for XML Continue to discuss Bundling after everyone can review.examples of errors and proposed fix

• GraphQL Demo