Page Comparison

🔓 Public Page

Agenda

• Antitrust

• Committee Welcome

• Meeting Minutes Review

• Review Dan’s proposal to share with CIECA Members working on open APIs before Architecture has completed the Standards.

• Review Dan and Mike’s work on Options with examples

Meeting Minutes

• Antitrust Accepted

• Welcome

  • Andy and Paul are unable to make the meeting today.

• Meeting Minutes Review

  • Add the Decision to the last meeting that Vehicle Options was agreed to be ciecaVehicleOptions that would be the options as is today; then we would have a detailedVehicleOptions that would have vehicle options from other sources including the manufacturer.

    • Those examples will be reviewed today.

• It was mentioned that it seems to be hard to get things accomplished when only meeting once a week for an hour. And we are at a good point in time that a face-to-face meeting would benefit the Architecture Committee working on CAPIS.

  • We will take this proposal to Paul and see what we need to do.

• We had a member reach out requesting information on how to stay compliant with CIECA Standards when they are developing open APIs before CIECA is completed. Dan proposed a message we could share and we reviewed in the meeting.

  • Below are the steps for working through JSON interfaces based on BMS XML messages that follow the outlines of the process we’re undertaking as an architecture committee. This only gets you partway there, through the “science” part of art vs. science dynamic when we can’t guess the outcome of many weeks of committee discussions and compromises still ahead. It’s my draft response to inquiries from CIECA members about “how can we get going on ‘CIECA’ JSON/REST interfaces before CIECA itself finalizes its JSON/REST standards?”. Old timers may recognize the similarity to the process of building “EMS XML” interfaces decades ago while members were waiting for BMS XML to be released.

     The process:                

    • gather the tag names from your BMS messages

    • convert the tag names to camelCase per CIECA JSON Style Guide guidelines        

    • structure repeating elements (XML style) to arrays with plural names (JSON style)

    • build JSON instances with examples of your current messages

    • optionally build json-schemas to describe your JSON instances

                      

    CIECA's CAPIS (CIECA Application Programming Interface Standard) JSON (JavaScript Object Notation) is envisioned together with REST (Representational State Transfer) and OpenAPI to have some fundamental differences that also need to be factored in:

    • BMS's Request-Response structure which exchanges Rq and Rs messages will be implemented in CAPIS as an unnamed payload (suitable for Create/Read/Update operations) with responses typically exchanged as HTTP response codes. Therefore messages names (e.g. DispositionAddRq/Rs, DispositionChgRq/Rs, DispositionStsRq/Rs) aren't expected to be part of the CAPIS standards

    • Rules/principles like the above are regular things we learn and document in our ongoing committee development process

  • Everyone in the meeting liked the message, wanted to add a little information about flattening

  • Paul is out of office this week, so we will need to wait for his review

  • Paulette will forward the email to members that are in attendance to review.

• Reviewing Real life examples with vehicleOptions and detailedVehicleOptions

  • vehicleOptions will be the CIECA vehicle options that are in the BMS today

  • detailedVehilceOptions will be the different source data for vehicle options including fields (detailedOptionSource, detailedOptionId, detailedOptionCategory, detaledOptionSelectedOrder, detailedOptionDesc)

  • Option Codes will have Option Codes minus the Engine and Transmission codes and then a new Engine Code and a new Transmission code.

  • engineOptions is new for CIECA code list for Engine and detailedEngineOptions follow the same as detailedVehicleOptions

  • transmissionOptions is new for CIECA code list for Transmission and detailedTransmissionOptions.

  • The aggregates under options are optional so they do not have to be populated.

  • String normally has a minLength and maxLength in the capisVehicleCommonAggregatesSchema.json

    • we can do it, but its not done now

• Agile and incremental schema concept to propose

  • We would have simple types, code list and objects as we create them

  • We could offer a different version, so this can be version 0.1 to share

• Review AdminInfo from BMS and Party

  • AdminInfo is a layer that is not needed and seen as extraneous hierarchy

  • Parties under AdminInfo has been promoted up

    • Other Parties is plural

  • BMS had 6 different types of Party. Insurance Company may have party plus an ID, a Claimant may have party and Claim number.

  • BMS you were an Organization or a person

  • In this proposal, the properties are optional, but all the fields are available.

  • We don’t need custome elements

  • OrgInfo and PersonInfo layer has been removed

  • IdInfo is still there but we can determine if we need it. Think this can be simplified

💻 Thanks everyone for all the work, Great Meeting!

Action items

•  Car-Part will come up with an example with the new detailedVehilceOptions to validate
•  Paulette will create a meeting with our committee members that work with vehicle to review.
•  Committee will share Party and ClaimInfo and/or PartInfo
•  Paulette will take examples of Party, ClaimInfo or PartInfo and place in an Excel document to show the BMS and proposed.
•  Work on Face to Face Meeting Proposal

Decisions

• We have a consensus on Vehicle and ready to share with the committee’s