2023-04-25 Architecture Meeting Minutes

Dan Public Page

Date: Apr 25, 2023

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

• Finalize Contact

Meeting Minutes

• Antitrust Accepted

• Meeting Minutes Reviewed Accepted

• Thanks to Jeff for sharing his work with Contact

  • The BAD is just that, a Big Dictionary and we don’t care how big it is, we can define and let the integrations that need these elements select what they need to make the messages simple.

  • In 1A of the PDF shared, we are talking about how to encapsulate an object when it enumerates properties.

    • For the BMS IDNum, we had an ID qualifier and a number, the approach in the first CAPIS was to have a named property instead of the ID qualifier and then the property value for the ID.

    • Committee agreed that 1A idea of flattening away the ID qualifier ID NUM concept.

      • We should make an architecture rule that unless you have more than an identifier and a value, it will be a property instead of an object.

      • The BMS invites users to go in through back doors, an idea is that the ID Qualifier and ID NUM and we have examples of people making the ID qualifier some kind of name or indicator and then the ID Num is true or false and using custom properties for the same thing. Basically, in all cases to be able to make a revision to the schema or the rendering; this can be corrected by setting additional properties to be allowable.

      • A property in JASO is already a name value pair. It should be a warning sign if someone is trying to introduce something as a name value pair.

    • All in favor of 1A

  • 1B, parameters, attributes that that you know the combinations sort of starts growing exponential. Phone number, phone number, extension, phone number, type and preferred indicator. That's like I guess four different things. It just seems like, you know, there's enough complexity there to, you know, Warren, an object so that we don't have to enumerate all those combinations.

    • We need to articulate a rule about this because for actually right, as of this moment, I don't remember where we came down. But the I think we've got examples where we flatten something like license info and had a license plate, License or license number, license expiration, license state, License registration and somehow imagine that people would keep those straight because the there's a prefix associated with all those properties that we want together as opposed to this case where we say, well, it's got these properties, each of these phone numbers has a couple or three other properties associated with it, so it should be on an object and We should account for why, and again I may be out of date as to what we did with license number, but if we did it that way, we'd have to have some accounting for why we don't have home phone number and home phone extension and home phone preferred indicator.

    • With Phone number we have array or we have different values needed with different phone numbers, they are not always the same combination of fields.

    • When developing, do we want to go through all of the arrays to find the one we need? Do we need to read 24 combinations of phone number to find the preferred phone number, read 5 combinations of email to find the preferred, or do we just have a preferred phone number and preferred email?

    • Phone Number and Email we will look at some new examples and how applications transfer from the GUI to the message.

Great Discussion everyone

Up Next

• Network/Welcome

• Antitrust

• Review Meeting Minutes

Action items

Decisions

Reference

Open

Participants

• Paulette Reed

• Dan Webster

• Jeff Schroder

• Andy Bober

• 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