Public Page

2022-04-26 Architecture Meeting Minutes

Owned by Paulette Reed
Last updated: May 03, 2022
4 min read

Public Page

Date: Apr 26, 2022

 

 

 

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

    • Pre Webinar meeting

  • Meeting Minutes Review

  • Review Mikes capisVinDecodeVehicleSchema.zip

  • Concept of CIECA being a list of Properties

Meeting Minutes

  • Antitrust Accepted

  • Welcome

    • Later Today we are going to have a pre webinar meeting to go over the presentation for the Technical CIECAST.

  • Meeting Minutes Review and Accepted

  • Meeting Minutes

    • New Topic from 4/12 Meeting that was brought up by Chris Poulous was for CAPIS be a list of properties and allow trading partners to use the fields as they want in their implementations.

      • With integrations today, New BMS Messages that are a subset of CIECA BMS use the same BMS Schema because they are familiar aggregates and elements.

      • In Open API the equivalent of a BMS message is in the future going to be an Open API endpoint.

      • The Committee decided that the properties, could be a schema with a data dictionary with all the properties in it, but it would be a mistake to not continue having structured messages.

        • The concept to have CAPIS be a list of properties, contrast with the principle of standardization that we want to provide the industry.

      • The Open API schema will allow for subsets of the messages and implementations, much like the BMS does today, but there will be a standard that is recommended.

      • The approach we are moving forward with is having a code list schema and common types schema and then building endpoint schemas that reference the common types schema.

      • Level one is using the common dictionary

      • Level two is creating the endpoints

      • The reason the BMS is not commonly used is due to the complexity of the nesting, the CAPIS project is removing the nesting and solving those problems by having these micro services and endpoints defined.

    • Referencing Discussion

      • The concept of referencing is to have definitions once. For example with vehicle we have LicenseInfo that is the parent of license plate state and license plate number. You could have messages that used license number and only license number and you could reference that element. This would allow for one definition.

      • Mike had mentioned in the past that the Referencing did not work as he expected. He shared his findings with XML Spy and bundling.

        • XML Spy has an issue with going more than one level deep for definitions

        • In deeper review, XML Spy worked for validation and using the $Ref in generating the XML Spy Schema view, but when you double click to drill down into it, XML Spy complains.

          • It seems to be a Tool issue and the Proof of Concept for using $Ref is valid.

      • The Schema files (Aggregates, Common Types) are common for CAPIS. These are really source code and they are not schemas because we are going to bundle them.

        • We can have different versions of the schema that includes different aggregates when using bundling.

        • Mike is going to do some homework to prove this Proof of Concept.

      • Mike presented the flattened versions of VehicleInfo and we worked through Proof of Concepts

      • Build our schema and have it in alphabetical order. This would help developers find the elements they were needing.

        • JSON does not care about the sequencing of aggregates/elements like the XML does.

    • Review of Car-Part.com Vehicle Info to discuss flattening and object levels

      • The review is to see what we need to flatten, such as VehicleDesc moved into VehicleInfo because it does not need to be used outside of VehicleInfo. However, there may be aggregates that are needed to be used outside of VehicleInfo that would need to stay an object.

        • License Plate Info is it used in other applications outside of Vehicle? Leaving the LicenceInfo structure but there are fields that may not be needed. It seems that flattening License plate info into vehicle makes sense.

        • Keys availability and Key location does not seem to be part of vehicle Info

          • These are used for Tow and First Notice of Loss

        • Odometer Information should remain an unnamed object

        • We ran out of time discussing the NICB Make and Model and will pick up here in review next week.

 

 

Action items

Decisions

  1. CAPIS can be used as a property list for anyone who has implementations that need it that way, but its’s also going to drive our endpoint schemas.
  2. We are going to use $Ref

Participants

  • Paulette Reed

  • Dan Webster

  • Paul Barry

  • Mike Hastings

  • 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. https://cieca.atlassian.net/wiki/spaces/ARCH