2021-05-11 Architecture Meeting Minutes

   CIECA 500 Westover Dr  #11617; Sanford,  NC  27330 

Date

May 11, 2021

Agenda

• Antitrust and Meeting minutes acceptance

• Demo new CIECA.com layout

• Finalize and vote on SimpleTypes; we would like everyone to attend to make verify the guidelines being established

• Review and vote on Style Guide

• Versioning of CIECA API

Meeting Minutes

• Antitrust Accepted

• Meeting Minutes Accepted

• Review Of new CIECA Website

  • A quick demo of the preview of CIECA Standards was displayed to the team.

    • The Committee liked the approach that was being taken with the new web design to share information with the industry and showing the distinction between the General Vs Membership views.

  • Questions from the Demo

    • Under the Schemas not all of the schemas used was listed, for example BMSSimpleTypes. This page is a draft website that was coming from the new concepts put in place for the Disposition Inquiry message in the last release for Confluence. It is not complete, but good catch.

    • GitHub, today we only have 5 license, will all members get access? We are looking into getting new licensing for Service account, not all members could change, but could access for View Only.

• SimpleTypes

  • Mike did some work in GitHub to reflect the changes that we discussed in the last meeting. He has ran into some tool issues.

    • Mike normally uses XMLSpy, however it has limitations with JSON, therefore, he has used AJV validator and OPIS.com as a validator and a good source for information on the new version of JSON.

  • In review of Mike’s capisSimpleTypesSchema.json in GitHub, we noted all of the Char_# values. In past meetings we discussed removing the Char_ and Range values with the Min and Max to Simplify the JSON Schemas. A spreadsheet view of the Char_# that were in production schemas was reviewed to point out that some of these simpleTypes were only used 1 or 2 times in the BMS Schemas.

1. It was decided that Char_# and Decimal_Range_, and Integer_Range_ values would not be used in OpenAPI development, that we would use the JSON values String, Decimal and Integer.

•  

  • Committee did discuss the use of Common types like Postal Code, State, Name, and address being Property definitions.

    • State is already defined in ENUM, and can be controlled with that existing Type.

    • Other values are seen as beneficial to define since they can be used through our OpenAPI. We reviewed Mike’s capisCommonPropertyTypesSchema.json that reflects this design concept.

    • We want to make sure to stay away from creating a massive property guide as the BMS Common Global Types.

• JSON Style Guide Review.

  • We walked through the document JSON Style Guide and everyone thought the document was good, but there were a few questions to be resolved:

    • Additional Properties is a setting to allow or not allow in OpenAPI development. We need to decide if we are wanting to turn this feature on or off.

      • Pro If the Additional Properties is set to TRUE: the trading partners can add new values without breaking the schemas.

      • Con if the Additional Properties is set to TRUE: trading partners can modify and make implementations outside of CIECA standards.

      • Additional Properties is one of the new concepts being driven with OpenAPI development and most REST services will handle this switch for True/False.

      • Maybe CIECA should implement a strict and unstrict Version?

      • GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

      • When Testing it is always good to have Additional Properties set to false so you can check spelling and verify that you are meeting the requirements of the test.

  • Property Value Guidelines may be out of sync with the newer version of JSON Standards that we have decided to use, such areas as nullable values. Would like to revisit this section to make sure we are in sync with the new version.

Great Meeting everyone! Please review the JSON Style guide that is in confluence with this meetings notes and send any recommendations to Paulette this week. Paulette will work on getting the requested recommendations documented and we can go over them in the next meeting.

Up Next

• Antitrust and Meeting minutes acceptance

• Review Style Guide Recommendations

  • Do we use Additional Properties set to True/False/Both?

  • Make sure the Property Value Guidelines are in Sync with the new version of JSON

• Review and work on the capisCommonPropertyTypesSchema.json to identify the property types we want to define.

• Versioning CIECA API

Participants

• Paulette Reed (Scribe)

• Chrisa Hickey

• Andy Bober

• Dan Webster

• Paul Barry

• Aaron Daniele

• Brad Broerman

• Mike Hastings

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. Architecture Committee