Page Comparison

🔓 Public Page

Agenda

• Network/Welcome

• Antitrust

• Meeting minutes review

• What’s next for ArchitectureReview Meeting Minutes

• CAPIS Like Proposal feedback

• Feedback of Restful services

• Work on moving the rest of BMS Data Dictionary to JSON Schema Data Dictionary

• Work on Parts and Procurement Services.

Meeting Minutes

• Antitrust Accepted

• Meeting minutes review accepted

• Approach to data dictionary

  • Is CIECA okay with publishing the Data Dictionary and having CIECA Like API services?

    • This is how the BMS is set up, the BMS is optional and allow the user to pick the data they want to interface with, we have examples of best-case scenarios and implementation guides, but they are optional.

• Next 6 Months

  • Complete conversion of BMS Data Dictionary to new Data Dictionary based on the style guide.

  • Work on Parts with Mike

• CIECA Executive Committee Proposal for Next Virtual Board Meeting

  • Invite Dan to the meeting to discuss exposing data dictionary as part of the release that is separate from schemas that allows you to implement elements into CIECA like services.

    • Stand Alone Document

    • Report of SAB of direction of CIECA

    • BMS Data Dictionary was in WORD in table structure

      • The Common Data Aggregates were used in all messages

    • CAPIS Data Dictionary is a JSON Schema

      • The architecture is to use references and bunding

Up Next

• Network/Welcome

• Antitrust

• Review Meeting Minutes

• CAPIS Like Proposal feedback

• Feedback of Restful services

• Work on moving the rest of BMS Data Dictionary to JSON Schema Data Dictionary

• Work on Parts and Procurement Services.reviewed from old version because confluence version was lost

• CIECA Membership

  • The Board meeting at SEMA was to discuss the access of CIECA Standards with the different membership types and Non members

    • What does a CIECA membership get a company? If you are not a member and never been a member, you have no right to the CIECA Standards. A member company may share a small subset of the data dictionary, for example, to illustrate the benefits of a CIECA membership to a potential customer.

    • A lot of time was spent reviewing the types of members CIECA has today and the rights to the standards that they have.

    • It was agreed that the Data Dictionary would be part of the CIECA Standard.

      • This would allow members to have CIECA Like Services as they do in the BMS and API services in the future. If they build the services using the CIECA Data Dictionary, they are CIECA like. The services are flexible and always has been with the BMS and will continue to be with CAPIS.

        • This would mean that we should convert the BMS Data Dictionary to a CAPIS Jason Schema.

          • This would be to continue with the zero-based budgeting concept and flattening of all BMS aggregates.

      • The constraint is you have to be a member to use the CIECA Data Dictionary and you use the information, and it is perpetual that you can use it forever.

  • The Membership and how to use the CIECA intellectual property is being moved back to the Board and Executive committees, as Architecture does not need to focus on all the details, just needs to know the plan of use so we can build the standards with that in mind.

• CIECA License in an API

  • Do we need a License for CIECA so when the API ask what license we are using, it can be entered?

    • The License is only needed if it open sourced, CIECA is private source and does not need a license.

    • Instead of a license, the use of the word Private should be able to be used.

• Feedback on Restful Services

  • The use of ID for claim number, would typically be provided by the client and when you are using a post, the server is going to create the ID. In CIECA post statement today, the server is not creating the ID, so we should be using it in the put.

  • Mike to provide Dan with some examples for Microsoft references to show how to use the post and the put.

  • 201 status is a response that we should probably add.

  • The concept to make it more restful, is sending a message that has multiple objects in int and typically or multiple resources to be restful.

    • An example is to send the claim and then send the party in a restful api.

    • The BMS would contain all 60 objects in a message, but with restful api we would have claim and then party and then the other objects used.

    • It is great to have individual objects available

      • but ultimately you have to have a transaction where you are tying these objects together.

      • we still need feedback from the industry that are doing Api development

    • We reviewed services that are being built today by members of the architecture Committee.

  • Do we have a standard if we allow then to use put claim number api, put party api and put vehicle api and then allow others to put claimsservice api that has all 3 objects?

    • CIECAs focus is more the interchange of data and not the API itself. CIECA provides examples of how to exchange the data with services, but that is not the standard.

  • Standards will be the Data Dictionary,

    • We wanted to find out how folks structure their Jason schemas, how they name their properties, and then when it came down to things that are truly standard or should be, we went looking for things that have already been defined. How do you render a day? How do you render a phone number?

    • data standards is probably more usable and readily accepted.

    • Reusing the data structures and their own web services. It's been happening for years and years and I think I personally think it's a great opportunity to kind of get our arms around that and adopt it, be open to it.

• Architecture will focus on converting the BMS Data Dictionary to CAPIS Data Dictionary

  • We halted conversations on items before to get the release in on time, now we can resume conversations on things like Arrays.

  • We can review the JIRAS in the next meeting.

Up Next

• Network/Welcome

• Antitrust

• Review Meeting Minutes

Action items

Decisions