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 and Meeting minutes acceptance

  • STAR Collaboration with standards

  • Working on Proof of Concept

    • Dan Walkthrough

    • Work on the Architecture Guideline to help people understand the flattening

    • Work on Party and ClaimInfo

Meeting Minutes

  • Antitrust Accepted

  • Meeting Minutes Accepted

  • STAR and CIECA Standards Collaboration

    • CIECA Staff just meet with Paco with STAR, and we discussed ways that our organizations could collaborate. STAR has recently gone through moving XML to Standards to JSON Standards.

    • STAR is using Swagger Hub because they liked the function of Domains being off the local server, which is a feature Swagger Hub allows.

    • CIECA Staff thinks it would be good for the Architecture team to meet with STAR and discuss ways that our standards could work together to keep help our mutual customers with easier standard implementations.

      • Things we could standardize between us is use of camelCase, naming standards, common data

    • Mike said a few years ago in a CIECAST that we had a CIECA member that was familiar with STAR standards to a CIECAST and talked about how the STAR data was flat and did not have the hierarchy that the BMS did. He believes it was a middleware company.

  • Proof of Concept

    • Dan and Mike had shared some documentation after the meeting and Mike used this documentation to come up with a new vehicle lite.

    • Dan mentioned that we should all start using GitHub so we don’t lose the work we are doing, and we can all see the latest version.

    • Mike showed the Schemas in two different formats, one with no hierarchy and one with object hierarchy.

      • The code generated with no hierarchy in XML Spy puts the data elements by length of the element.

      • The code generated with Object hierarchy leaves all of the fields inside the object where it is easier to read.

    • We have three validators

      • XML Spy

      • JavasriptAJV

      • Stoplight

    • Dan had created white pages and there was discussion when these were created that Yamal was the preferred language. However, after several implementations with clients, he is not sure that is the case.

      • People are no longer clinging to XML

      • Documentation is not standard through the REST services

    • Like today, when a member needs a new version of data, for example the Vehicle lighter of Vehicle Lite, if they want it as part of the CIECA Schema, they will propose the change and it will come through the Committees and the Architecture Committee.

      • CIECA will have a repository of Schemas in GitHub

  • GitHub

    • Andy Volunteered to work on a Best Practices for GitHub

    • It was mentioned to create a new project because we had many versions and branches in the current CAPIS GitHub, however, CAPIS is the name of our project.

      • We will work offline to get the CAPIS directory cleaned up.

  • Items for Next Agenda

    • Style guide

      • Do we want to promote flat data, object Hierarchy or both?

        • The bundling tool has shown that we have flexibility, but we need to determine best practices to put in the Style Guide

      • Best Practice is to Define and Reference

      • Document Flattening Policy

      • Document Subset of Aggregate Policy

    • Test Instances

      • The XML Spy generated code will validate against the schema, it is best to have thorough test instances created.

    • Proof of Concept

      • We need to prove the use of Arrays and choice of Arrays. This is in reference to the BMS Required/Or, Optional/Or

      • Required fields

Great Meeting!

View file
nameInvalid file id - cb825680-c161-4b53-9752-12ecaf9b8927

Up Next

  • Antitrust and Meeting minutes acceptance

  • GitHub

  • 2022R2

  • Working on Proof of Concept

    • Style guide

      • Do we want to promote flat data, object Hierarchy or both?

        • The bundling tool has shown that we have flexibility, but we need to determine best practices to put in the Style Guide

      • Best Practice is to Define and Reference

      • Document Flattening Policy

      • Document Subset of Aggregate Policy

    • Proof of Concept

      • We need to prove the use of Arrays and choice of Arrays. This is in reference to the BMS Required/Or, Optional/Or

      • Required fields

      • ClaimInfo and Party

Participants

  • Paulette Reed (Scribe)

  • Chrisa Hickey

  • Andy Bober

  • Dan Webster

  • Mike Hastings

  • Jeff Schroder

  • Paul Barry

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