2022-08-09 Architecture Meeting Minutes

Public Page

Date: Aug 9, 2022

Agenda

• Antitrust

• Network/Welcome

• Review Previous Meeting Minutes(s)

• CONNEX/QA Face to Face

• Homework

  • Claims

    • deductibleBasedOnPercentageMethod we think we can remove for zero based ruling, but we will give a week to let everyone to review.

    • Inspection review to see if we want to bring it up.

  • Andy Build

• Review Part or quotedPart

• Review Jira Board

Meeting Minutes

• Antitrust accepted

• Meeting minutes reviewed/accepted

• CONNEX Reminder

  • September 15 we will be having a technical meeting and QA in person.

• Homework

  • No Examples were provided, but it was due to time constraints and not being able to work through the analysis. We will move this to the next meeting.

• Work with GitHub

  • A lot of work was done through the committee members to work on different objects and folder(s).

  • We want to make sure we have examples of all the codes in the code list and all the elements in the XML schemas.

  • Make sure we are testing

    • Test Instances are used for validation of our refactoring.

    • We need to make sure we have more invalid testing

      • With JSON Schema using additional properties, negative testing will be beneficial

      • Additional Properties should only be used at the object level but using negative testing will verify that.

      • Additional Properties defaults to true, which would allow implementations to add whatever property.

  • Mike updated schemas and tested them since the last meeting.

    • Schemas validated and was able to validate vehicle messages and some of the other ones.

    • Question was ask if the rest of the group making changes in gitHub validates

      • If we use the Tooling, it will validate

• Review of the Tools Andy is adding to GitHub

  • What we hope to accomplish here is to cover what exactly the script's going to do. You can see it's reporting it's running. It's the first version number and information. The concept is to have the three basic commands that were available in the XML version, so you can run a test, run a build and run a validate. And the idea here is that if you run a build, it would do whatever is needed in terms of bundling or anything else to verify that that we can create the final open API.

  • Json schema is going to be used in the open API. This is the purpose of this command to basically search through the schemas and for each one of the schemas bundle them and create the individual bundles and that will be based on its references back to the definitions.

  • Preparing the source code to create the bundles directory and the definitions directory, and then all the schemas. I have all these things that we were just talking about getting that all organized and the source code is going to create, and a folder called build.

  • How to do that and then as well as any validation errors will show like the actual validation error that is reported when we try and do a validation and a general log that is just the result. This type of thing will be in this file which would be in the output directory so.

  • First thing is to run a build by taking the schemas that we've got that all reference the definitions and it's going to generate these bundles and then when we generate either in JSON schema or in YAML.

    • Preference is JSON schema

    • YAML can be super hard to read

    • Either can be used a valid

  • Second is the validate command, which can use to validate like individual files.

    • If there is a particular instance, a JSON instance and you just want to say, hey, does this work, it would be able to validate it. That's

  • Third and final is the test command, which will validate the entire suite. The test is that it's going to go through this test instances and is going to recursively go through this directory. It will look for every subfolder and it's going to expect that every one of these has this model.

    • We expect to see invalid and valid test cases for Claims and this tool will go through and read any files that are for Claims and try to validate them.

    • The same thing with parties and vehicle.

  • GitHub will used to both build it and run the test suite to verify that everything is valid as is expected.

    • The validate is more of a tool for people to use outside of GitHub down on the local workstation

    • When making a change to a schema and you just want to validate the change or maybe several files and the wild card can be passed.

• Generating documentation from the Open API. Mike was kind enough to provide the CIECA vehicle VIN decoder, YAML and it was used to run the generator tool.

  • The targets in terms of this documentation generation.

  • The Uri shows the scopes and the various parameters, whether they're required or not.

  • Shows that it's going to use bearer token for security and then any return values responses, error numbers that are that were included in the file are all included here and then interestingly it also shows different ways to call this endpoint.

  • You'd be able to call it just this way with curl.

  • Rudimentary way of how to call that API in in Java.

  • Does a similar thing for Android, which is also Java as I understand it, but I know that they use Java.

  • Example of generating some static documentation of our app API and then this could just be dropped into the CIECA website and people could have it to peruse without having to look at the code, although they of course could just download the Open API specification themselves and look at it in whatever way they would prefer. But this is just a way to make it available.

  • It is automated to recognize when a change is made, it would be published out to the website right away.

  • The generator tool unfortunately does not support three dot 1.0. It only supports the prior one 3.0 and this is something that one of the we had a sika cast once and somebody asked us, you remember why we're using 3.1 and are we using anything specific about it? And I still think, Mike, that I really love the way you answered that because we want to be standards based.

    And the prior version, the version three dot O .3 which is the prior one. It didn't support true Json schema as you guys know, it was an extended subset and if you think about that and extended subset, so they cut out a bunch of it and have a subset of it and then they bolted on some extensions.

  • For this example, using CIECA of vehicle VIN decoder YAML, it is not actually using any of the new features of json schema so to get this to work a change from 3 dot 1.0 to 303.

    • The problem is this tool doesn't support the new 3.1 specification.

    • Basically, it shows that it's oversimplifying to say you could take a 3.1 O document, change it to 303, but these are the kind of problems and it's running into.

  • Stoplight also has documentation. Stoplight Studio is an Interactive OS renderer whereas the above demonstrated is a

    Batch creation.

    • Security scheme, so this documentation covers that.

      • First thing that it has to have is a name, and the name must correspond to one of these security schemes that are declared here.

      • CIECA could make the recommendation on what we think it should be and then the type instead of it being ACP. Depends on how far CIECA wants to go with the CAPIS, if we want to just stop at the schema, or we want to go right through and standardize the endpoints.

        • Recommend going past the schema and have the endpoints and the suggested security.

Action items

Decisions

Participants

• Paulette Reed

• Andy Bober

• Mike Hastings

• Paul Barry

• Dan Webster

• Phil Martinez

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