Page Comparison

Date

06 Apr 2021

Agenda

• Antitrust and Meeting minutes acceptance

• Review Dan and Mikes Style Guide and messages and implement the Google Revisions and other revisions

• Specify Simple Types that will be used in JSON

  • Andy to provide more information for the Team to review.

• Version of CIECA API

Meeting Minutes

• Antitrust Accepted

• Meeting Minutes Accepted

• Not able to review the Style Guide that Dan and Mike was working on due to technical difficulties

• GitHub Structure

  • Add folders to GitHub for JSON-Schema, and JSON Test Instances like we did in the BMS Schema

    • Make sure that we have a folder for negative test instances.

• Simple Types discussion to simplify strings to one value and numeric to one value or continue with specific validations

  • Should we validate string and numeric values or let that go?

  • Validating is not as useful in JSON as XML; is one thought.

  • These Constraints exist since BMS was created.

  • BMS proposals are universal approved for length to be longer.

  • Anything that is longer than CIECA approved length can be truncated.

  • Open API examples do not seem to have max length.

  • The Max length option was not available until JSON version 3.1; so examples may not have them because this is a new version. It does appear that this feature was requested and examples will start to have this validation.

  • The API examples that we have looked at is limited to a few areas, maybe we should look at larger more complex examples.

  • Strict Schemas VS No Schemas Vs a middle version?

    • middle version of schema may have fields and required values but not have strict rules

  • CIECA has 100s of codes that we validate to help our standards throughout the industry; removing these seem to let people move away from standards.

  • What happens if we do not force the date and time validation in a message such as appointment?

• If we decide that we are not having a schema that validates values, the Data Dictionary will be very important to keep up to date so the rules and lengths can be found and CIECA members can build the validations.

• If we provide the schemas, the developer will not have to build these validations and possibly interpret or change the standards. No validations in our schemas means developers have to manually build them into the interface.

• JSON schema errors are more difficult to read and not user friendly.

• Simplification eliminate details you don’t need but keep the details you do need.

  • The XML schemas are very complex; we do not need All the data and ALL the rules; however, those that are needed should be in the JSON Schemas.

  • The JSON for assignment has been simplified and removed data to make it smaller.

    • When it was dropped into Swagger Hub it was still to big.

  • Part of simplification is to remove types that do not add benefit. If we only have one field that needs a type; we can make that description on one field instead of making it a type.

• Decision that we will have a validating schema; we will not worry about speed; but we want to make presentable for ease of implementations.

  • Required fields are important and must be validated.

  • Structure is important.

  • CIECA can validated length if it is critical to the message

  • CIECA will validate Code List Values

• Version of CIECA API

  • Policy Version has 3 parts 1.0.0

  • CIECAs rule now is no one part can go above 10; so we do not have a reason besides its going to 11 to change the previous number (1.9.0 will force next version to be 2.0.0)

  • We need new rule to be standard with industry

    • New Version that breaks an existing code would increase the first number

    • The middle number would increase if change didn’t break existing code

    • the third would be a patch

    • Schema Draft JSON version is what Swagger uses.

🤓 Great Meeting Everyone!

Up Next

• Antitrust and Meeting minutes acceptance

• Versioning of CIECA API

Action Items

Decisions