Public Page
2023-05-23 Architecture Meeting Minutes
Public Page
Date: May 23, 2023
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
Network/Welcome
Antitrust Statement
This meeting is subject to the terms of our anti-trust statement shown here. In addition, this meeting may be recorded.
Review Meeting Minutes
Review work completed
Work Meeting
Builds and Stoplight
Meeting Minutes
Antitrust Accepted
Meeting Minutes Reviewed Accepted
Review Work since last meeting
We found an issue with the bundling tool, where if you told it to bundle 5 files, it remembers the first files in and reuses some of the information in the future files that may not be what the intent.
There was another issue that is complex due to the person maintaining the JSON is open-source library. The JSON Schema Ref Parser Library decided that they don’t want to maintain it anymore and turns out that the folks at stoplight have picked up the library.
Stoplight put out a new release 19 days ago that resolves the problem.
Andy updated the JSON Schema ref parser to the most recent version that is being maintained by Stoplight and the issues have been resolved.
Mike Added three objects into the Schema
User Company in the updated contact objects
Merged branches into GitHub
Validated the test instances.
There are two different test that gets ran. We run test over the invalid and valid test instances.
Changing the email to array was a breaking change that impacted several validations.
There was a Hack to the BADD schema for preferred indicator to work and we need to remove the hack.
Guidelines
We would like to have separate set of enums instead of combining aggregate
So instead of having communication Type we will have phone nums and email and address
We have objects named the object name and object name + type and have enums, we should simply call email; email
email address should be a string of format email because that's the definition of according to the RFC of an XMPP IM address.
Naming Standards
This is how you the the pejorative design by committee description came from, but it's clear that if we put on the agenda for next week, we got a or that we should look at how we've defined phone nums and all of the like named properties and we got to fix it somehow and we come up with ideas.
But the one thing I think is usually the naming pattern is the array would be something like phone nums and we have a rule that says array names should be plural and anyone would expect if they're raised called phone nums the things inside it would be phone NUM.
I think it is umm type and this is type of email and even this to someone getting their first assignment to implement something in capus might be unsatisfied by this and have to actually go to the reference to see that well and they would be very disappointed to see that the only email type is OEM.
But if this were phone type that would be home work, cell text or whatever.
So that's one use of the word type, and then other places we at least I think we do the naming convention we just talked about where we append object to something we sometimes use type in exactly that way.
Review Mikes work and reviewed bundling
Great Discussion everyone
Up Next
Network/Welcome
Antitrust
Review Meeting Minutes
Action items
Decisions
Reference
Participants
Paulette Reed
Dan Webster
Andy Bober
Pete Sheehan
Jeff Shroder
Paul Barry
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