Public Page

2021-03-2 Architecture Meeting Minutes

Public Page

 

      
   CIECA 500 Westover Dr  #11617; Sanford,  NC  27330 

 

Date

Mar 2, 2021

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

  • Meeting Invite change

  • Review Mike’s work on API Data Types

  • Swagger /Git Hub

  • FNOL

    • Look at ADMIN INFO and break it into the Data Types and Aggregates that we need.

Meeting Minutes

  • Antitrust Accepted

  • Meeting Minutes approved after revision was made by Dan Webster

  • Meeting Invite Change

    • The meeting invite was changed to have the Architecture Committee Confluence page link so you can access the meeting notes and Committee information.

    • The Confluence page was changed to have Affiliation and Industry segment and removed everyone’s email.

      • This was done for Member privacy since these are public pages we didn’t want to have everyone's emails available

      • The recommendation for affiliation and industry segment was requested for another committee and agreed to use on all committee pages to keep them standard.

    • Dropbox has the Work Documents for the Committee

  • Review Mikes Document for Open API Data Types

  • Out of Sync https://cieca.atlassian.net/browse/R121-157

    • Mike noted that the BMS Data Types are missing in chapter 2 of the BMS but are in the Schema

      • Percentage

      • Time

  • Data Type(s)

    • The team reviewed the Data Types in Mike’s documentation and noted that the Data Types has changed from the 3.0 to 3.1 version.

    • Agreed that Narrow Character Data Type, that was created in Accord standards and not used, should be removed.

    • Indicator may be used for more that Y,N,U?

      • Chris is going to look into what other values may be used in indicator.

    • Year and Date data need more analysis to determine if we can use JSON date and a format to control the needs of our messages.

    • Duration Data Type is recommended for removal

    • Data Types such as Phone and email should be able to use JSON String with a format

    • Decimal and Currency is not used in Open API, instead JSON has Float and double.

    • Enum/Closed Enum/Open Enum is used in XML for our Code List values

      • make character based that you can restrict

      • remove Open and Closed Enum and just use Enum.

    • We should not need the data type identifier

    • UUID, URI, and URL are all valid Data Types

      • URN is not in current schema so we should remove it.

    • HexBin nobody knows if this is used

      • Andy will generate a script to identify how many times a data type is used in the current XML.

    • Email is a good data type

    • Percentage, do we need this or is it just a number?

    • In Current XML we define the length of Char values and Range of numeric values.

      • Discussion on If we need to do this or leave it open?

        • If we do not put the values in schemas, then all the applications that use the APIs will have to validate the length and see if they are valid, where now the Schema will kick it out for being invalid.

        • Another thought is if we don’t add here, CIECA would need a document to show the recommended lengths and use of fields.

        • These lengths help create the database(s)

        • In an effort to move to simpler messages, we should remove unnecessary properties and not remove content of properties used.

  • Swagger/GITHUB

    • New Repository was created in GitHub

    • Swagger we initialized and we are currently in the 10 day trial version

    • Swagger is still functioning off the 3.0 standards

      • Current version of 3.1 gets away from the extended subset of data types.

      • We need to determine when Swagger will move to 3.1 and determine if Swagger is the correct tool.

      • At this time, a quick Google Search didn’t turn up any Swagger competitors using 3.1.

  • Mike’s research on Person/Contacts/Organization

    • Facebook did not have much information.

    • Google has a huge API and best practices that we should be able to use

      • If you have Gmail contacts it works with people.

  • Dan reviewed JSON Style Guide that he is working on and hopes to make sure CIECA follows the same guide.

  • Dan reviewed a document where he broke down the Current XML and the JSON version of AdminInfo that he will share with the team.

  • Google API Uses Property of communication type so Phone has Business, Home, etc instead of using a Communication qualifier.

  • Privacy Issues with Name VS Company

    • topic that we will add to the agenda for next week

Wow we got a lot of work done and identified a lot more to do, Have a great week everyone!

Up Next

  • Antitrust and Meeting minutes acceptance

  • Privacy Issues with Name and Company

  • Review Action Items

    • Swagger Hub

    • Indicator

    • Data Type Usage

  • FNOL

    • Look at ADMIN INFO and break it into the Data Types and Aggregates that we need.

Action Items

Paulette and Paul will check with Swagger Hub on when they plan to implement 3.1
Chris is looking into values used for Indicator
Andy is creating a script to see how often a data type is used.
Dan is sending the documentation he reviewed to Paulette to share with the team.

Decisions