Public Page

2021-11-16 Architecture Meeting Minutes

Owned by Paulette Reed
Nov 23, 2021
6 min read

Public Page

 

      
   CIECA 500 Westover Dr  #11617; Sanford,  NC  27330 

 

Date

Nov 16, 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

Meeting Minutes

  • Antitrust Accepted

  • Meeting Accepted

  • Mike and Dan lead the meeting! Thank you both for helping out.

  • Reviewed Dan and Mike's capisFNOL Vehicle Simplification_With_VinDecoder_Changes Excel document to show the flattening process

    • Valuation Amount was keep but the other aggregates for adjustments to the value was removed for flattening.

    • File attachment was deleted

    • Custom Elements was keep

  • Mike used this flattened version of Vehicle from Excel to do a proof of concept on the VIN Decoder and realized there was still more data that could be removed.

    • Mike removed more data

    • Mike added a few more fields (21) VIN Decoder Vehicle Info Type like manufacturer and manufacterOptionCodes.

      • VehicleOptions is the only array left in Vehicle and it uses a object; which the others are all just properties.

      • configuration was changed to driveTrainConfiguration

      • The new properties were not dug into, the VDI Committee would need to approve these.

      • Ask that the examples of the type of data be added for the new fields being added so we know if they are valid. These can be added to the EXCEL and we also added the Stoplight.

  • Concerns of Proof of Concept is BMS 1200 properties, and following our JSON Style Guide and best practices gets it down to under a100 fields. So we fill that this was a good Proof of Concept.

    • 20 years ago we wanted to leave nothing out and had large Vehicle

    • Latest thinking is getting to use what you need.

    • The Committee felt as Vehicle would be a familiar object for everyone to be used as a proof of concept.

    • The first proof of concept that we can take a BMS object to a JSON object was completed with the VIN Decoder, as mentioned above, this is a proof of concept and would have to go through committee review for new fields and deleted fields.

  • Move on with examples with multiple end points and request. The VIN Decoder is pretty much done and now we will create another project that uses the verbs (GET, PUT, DELETE)

  • We started out using the BMS Schema structure that has 29 files or more, including simple types, common types per service, global common types. The open API structure should not be defined this way and only uses things that we use.

    • If you use objects that you do not use, the API will let you know you defined something you did not use.

    • npm service for schema bundling that read from resource files and wrote them to the open API, and this was another point that the proof of concept.

    • We have a very compact version of Vehicle now for an example, we don’t want Vehicle Lite, Vehicle Medium and Vehicle Large.

      • Will these 28 fields be in all Vehicle bundling info, but the current Vehicle Lite does not seem like the minimal?

        • There is only 4 required, the rest are optional

        • These are not the minimal, the exercise would be the same in going from 24 to 4.

        • As part example, 95% have a VIN, so VIN may not be a required field. The BMS has an XOR but JSON does not allow the XOR concept. So should they all be optional. Mike opened a help desk ticket with Spotlight because the schema could handle it but the Stoplight App could not.

        • VIN Decode it makes sense for VIN to be required, but for a Request of Quote you send Vehicle, Part and Claim buckets and 95% of time you have a VIN, the 5% have Year Make Model. So creating another example of Vehicle using for Part would help prove the concept of how we use different versions of vehicle in our standards.

        • We went through what tools we wanted to use and started with SwaggerHub, but it did not provide all the functions that we wanted and now that Stoplight does not meet the XOR requirement, we don’t want to keep starting over with the tools based on the limitations we run into with the tools.

          • Since Stoplight can not handle XOR, can we say VIN is not required and simply not have required fields?

          • The VIN Decode is great with Required, but if we for parts that has no VIN, will you send garbage or will we error?

          • We do not want to make a field required and then force people to send junk to pass the message. The XOR VIN or Make Model. There is a structure in JSON Schema that allows XOR, but its just not in Stoplight.

          • We need to do more work to get Stoplight to use the XOR concept or we would have to use them all optional and use an implementation guide to use best practices on the required fields.

  • Anonymous bundling Concept Review

    • Anonymous concepts means something specific in JSON schema, so we probably don’t want to call it that.

    • Back to the EXCEL document License aggregate brings in all the children.

      • To flatten, we removed the parent license and used all the children (plate Number, State) but what if we don’t want to use all the children?

      • For Vehicle, we want to use the children in some messages and others we do not. So we need an invisible container around these objects. So is there anything we can do to include these?

      • There is a way to use our bundling tool without bringing in a named object, and we think that is what we want to do.

        • We need examples that are smaller and bigger than the Vehicle that we have today so we can use that as a proof of concept

      • Instead of calling Aggregates they will be called Objects or Resources.

      • The 24 properties we have today in Vehicle Lite we can include all at once and then include the unnamed license and this is the next concept to prove.

      • We want to keep these coordinated in the standards.

      • Will we end up with a half a dozen vehicle objects?

        • We would have VIN Decode Vehicle, Parts Vehicle, Assignment Vehicle or have a structure where Vehicle and License will be your message.

  • Examples for VIN Decode, Parts, Estimate Vehicle Types to find our minimum Vehicle and then the items for bundling.

    • Mike to come up with Use case Management Systems Vehicle

    • Dan to come up with Use Case for Assignment or Estimate

  • Hypothetical Company used Vehicle ID Number but client started sending with no VIN and they received an error. The Client said we don’t have a VIN so change your schema. So we need to focus on things that work for the industry and remove the complexity.

Up Next

  • Antitrust and Meeting minutes acceptance

  • CIECA User Forum on cieca.com

  • Review Vehicle Concept for bundling (Invisible Container for Children) Use Cases

 

Participants

  • Paulette Reed (Scribe)

  • Paul Barry

  • Dan Webster

  • Mike Hastings

  • Brad Broerman

  • Jeff Schroder

  • Rochelle Schuette

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