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