2022-3-1 Architecture Meeting Minutes

Date

22 Feb 2022

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

    • Javasript

    • 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 SML 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

      • Stop Light could not handle the Required/Or

Great Meeting!

Up Next

• Antitrust and Meeting minutes acceptance

• Working on Proof of Concept

  • Mike walkthrough of VINDecoder/VehicleInfoLite with Reference and Bundling

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

  • Work on Party and ClaimInfo