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
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.
CIECA Architecture Committee-20220426_121403-Meeting Recording.mp4
Action items
Decisions
- CAPIS can be used as a property list for anyone who has implementations that need it that way, but is’s its’s also going to drive our endpoint schemas.
- We are going to use $Ref
Participants
Paulette Reed
Dan Webster
Paul Barry
Mike Hastings
Jeff Schroder