2023-06-20 Architecture Meeting Minutes

Public Page

Date: Jun 20, 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

• Review work completed since last meeting

  • Comparison of Bundling Tools

Meeting Minutes

• Antitrust Accepted

• Meeting Minutes Reviewed Accepted

• Parser Bundling

  • We found that there was an issue with the bundling tool that we were using where it seemed to remember previous versions of the files. If you tell it to bundle 5 files, it remembers the first files in and reuses some of the information in future files. That may not be what the intent was, so there is actually two issues. The issue is hard to explain so Andy showed us how the person maintaining the JSON is open-source library. The JSON schema Ref Parser library has decided that they don’t want to maintain it anymore and it turn out that the folks at Stoplight have picked up the library. This was added to Stoplight release 19 days ago. To try and resolve the problem was instead of using the standard version of JSON schema ref parser, I updated to this most recent version that's being maintained by the folks at stoplight and it seems to have solved the problem.

  • New branch that used the @hyperjump bundling too with its draft/2020-12 reference by $id URIs instead of our previous method of using JSONPath expressions (which we use to traverse directory paths with “../”). That’s why json-schema-ref-parser builds don’t need to be told all the schema files (because our references specify the directory/file paths) but the @hyperjump bundler does need to be told all the schema file names (then it finds all the $id URIs inside the files). I think we concluded that switching to the @hyperjump bundler is not the answer for our CAPIS project, in large part because XMLSpy, jsonschema2pojo, and other tools that Mike uses to build code from the schemas don’t support the draft/2020-12 bundling method well (XMLSpy is super slow) or at all (jsonschema2pojo crashes, and I don’t know details about the others – Mike just said they don’t work).

  • We were hoping to touch base on that today at some point, but that's basically the update we met to go over this ref JSON schema ref parser and how it was doing the bundling and the and it was actually failing in the build process because of it.

    And what we found was that the schema that was being generated was an accurate and that's how we came to find that there was a problem with the actual library.

  • There are two tests that are being run, and when it says that there are that final result that you see there, that's the final result of the negative validation.

  • There's actually 22 sets of out output that are there, or if you're looking at the the files that are produced, there's a validation, there's negative validation and positive validation and those logs are separated that way.

  • The reports are much improved and I'm sure with just a couple minutes of review, I can figure it all out, but I didn't even get the build running till after this meeting had started.

• Changes in Code Reviewed

  • One of the changes I made was the change email into an array of emails and that was a pretty bad breaking change for all the instance docs.

    • Mike Changed the test instances, but did not do the invalid.

  • I made a hack in the BA schema to what's called preferred indicator umm to work around the bundling problem and we probably need to change the code back to remove the hack. - Create JIRA

• Mini QA of observations

  • Address Type is a com qualifier which is a COM Qualifier that goes to Communication Qualifier ENUM Type

  • The examples for the part parties and none of them had address type. This is residue or legacy from BMS XML where there was a single array.

  • Aggregate for each of those things, so you'd have one for work phone number, one for cell phone, one for IM1, for address, and the the two address types were, I think SA for street address and AL for a dress with no type, etcetera.

  • My understanding that we agreed in our somewhere along the way previously that our best practice was to have a separate set of enums instead of combining these, we would rather have, you know, 10 little ones than one big fat enum, right?

  • My understanding that we agreed in our somewhere along the way previously that our best practice was to have a separate set of enums instead of combining these, we would rather have, you know, 10 little ones than one big fat enum, right?

  • Think we should be able to actually get rid of communications qualifier enum, just make sure that it's all in phone number types and if we do need a separate type for email for address, it should be like an address enum.

    • Yes

  • The second thing is it's just a naming convention saying enum type that that's also another place that sort of type is used if we could just use enum there. If we could just say enums cut down one word and also it it does get rid of type.

    • We have, if we have something called uh email type, you know, we could just have email type enums that that like feels to me that it's simple.

  • Do we need to address type and so maybe you guys can, maybe you can help me, but maybe we can go back, Mike, to the address object and look at it and decide if we want to simply have an address type with two enumerations or if we just wanna flatten it and say you know, here's address.

    • It looks like the address type is not used. When I did a search, I see one instance, you know, maybe we can just delete that property.

      • We are deleting it.

    • COM qualifier is used by the phone number object, so we can't delete it.

  • In reviewing other code should we use a string of format email because that's the definition of according to the RFC of an XMPP IM address.

  • Naming convention with Num and NUMS saying its plural or array.

• Review Rules

  • Rule to call named object models to have object and the name and figure out if we've documented that before and if not, let's get on it. I think in in the case of phone NUM and you know, we have a property with the same name, right? So it makes sense to put object on the end.

    • We have three different names, this is a good example. It would be nice if we were consistent. We have the actual phone number itself and then we have the object that contains it and related properties and then we have the array which is sort of plural.

    • How about if it's just phone? Is the is the name of the object and the phone number. Phone NUM is still the name of the property and then.

    • Discourage us from trying to come to a resolution right now during this discussion. 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 gotta 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. But it's not.

  • BA schema needs to be alphabetized

• Review Code Part 2

  • The committee likes email type enums or something and would be a good naming pattern.

  • The communicate, this is like the phone enum, phone number, your number. I added TX for I call it text capable phone number yeah.

  • The branch basically after the new objects we've added to the schema. A new message schema parts and voice schema and I've also created instance documents for that. Demo of the code and test instances.

  • Demo of code for parts invoice folder and then there is a valid and invalid in the.

  • Andy Demo his code changes to the validator and bundled tools

    • So to keep in mind that you that you can't use like one specific file like you can in XML, you have to know which instances you're gonna be validating ahead of time and then you have to use the appropriate bundle for it. So if you're gonna be somehow, you have to be able to relate those things together. And if we want to focus on the names. Then whenever somebody adds a new folder, you know they're they're gonna have to be very careful to make sure that the naming is just so. Or, you know, this is really flexible to be able to just add another entry into the map and have things validated that way. I'm not married to either way.

    • How does it do bundling? So we look through index dot JS and we could see that the first thing it does is call main and after it gets done configuring itself and then we look at main, it dumps a banner, it dumps the environment and it runs this bundle all schemas and so bundle all schemas. Here you could see is it's got a list of file names and so So we're the schema directory turns out to be this one Jason schema, not the bundles.

• Comapnies may prefer to use the unbundled schemas, undeterred by the added size of the unused definitions in the capisCodeListsDefinitions.json  and capisPropertiesDictionaryDefinitions.json schemas (AKA the “Big-Ass Dictionary”, (BAD)) and perhaps CIECA should make sure we include all the files in our releases (we checked and we did put all the files in the 0.0.1 release), and then get out of the bundling business and only send the schemas and definitions folders and let member users of the schemas bundle them or not as they please.

• Members reiterated that our last release was numbered 0.0.1 and so obviously an alpha version, so can freely make breaking changes for our next release.

Great Work everyone

Up Next

• Network/Welcome

• Antitrust

• Review Meeting Minutes

• Review Work Changes

Action items

Decisions

Reference

Participants

• Paulette Reed

• Dan Webster

• Mike Hastings

• Andy Bober

• Jeff Schroder

• Pete Sheehan

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