- Created by Paulette Reed , last modified on Mar 09, 2021
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 4 Next »
🔓 Public Page
CIECA 500 Westover Dr #11617; Sanford, NC 27330
Date
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
Participants
Mike Hastings
Dan Webster
Jeff Schroder
Andy Bober
Paul Barry
Chris Poulos,
Dan Webster
Cindy Chapman
Brad Broerman
Participants in the meetings are noted for your information. If you have questions on the committee’s activities, please contact a recent attendee. https://cieca.atlassian.net/wiki/spaces/ARCH
- No labels