Collapsing Complex Hierachies for Resource and JSON Object models

Topics: ACORD XML 2.x, JSON, Resources, REST
Jun 16, 2016 at 3:14 AM
Edited Jun 16, 2016 at 3:15 AM
Current resource aggregates have other grouped info for reuse-ability. However in a Resource model we group common resources into a higher level group.

Example: PersDriver and CommlDriver are now Driver. So we created the "Info" aggregate to put the common things like DriverInfo and separate things like PersDriverInfo and CommlDriverInfo.

Now that we have a higher level resource do we need the child "info" aggregates? The light weight message implementations (Restful XML and JSON) would say "No".

Big Question
Can we collapse grouping "Info" aggregates in the Resource to make the resource as flat as possible?

Other Comments/questions
Comment on the flattening of repeating aggregates like MiscParty. Part of this should be answered by the Party Resource Discussion. With that in mind if there is a need for a repeating Party like in Coverage, It should be fine to have that. Should the Party Aggregate have a Party aggregate inside it? Sure but with comments saying it is not intended to go more then one level.

Jun 16, 2016 at 8:47 PM
Joining the "party" late... (See what I did there? heheh) Sorry if I'm off topic.

It seems to me that we might want to start by defining a set of very high-level expectations and requirements. This is especially important because the two goals that I heard on today's call seem to be at odds with each other. I may be really off-base here, because I'm making inferences; but here's what I've "heard" so far.

1) We want re-usability between the aggregates currently used in 2.0 and the new Resources concept.
2) We want "flatter" resources.

These two goals are already at odds with each other! To flatten these things, even just "a little," you'll find that you have completely different aggregates and about the only re-use you'll achieve is around simple element names and code lists. In the end, you'll have two structures, two code bases, two message sets (RESTful vs. current), etc...

So, I think we need to start here. We need to start with our goals and define them more concretely. How "flat" is flat enough? How much re-usability do we expect? What are the advantages and trade-offs of these?

This doesn't need to be a huge exercise and certainly shouldn't be a long list of requirements. I'd expect there would surely be less than 10 requirements. The hardest part will be prioritizing them - which we should do as well.

My two cents (and worth nearly as much)!
Jun 18, 2016 at 2:04 AM

I am so glad that you are joining the party, I have heard nothing but positive things about your involvement in the last call. And I am excited that you can help bring what you have from the info model into the messages.

I sense from your comments that you are understanding the delema that plagues the standards community. The main goal is we need a robust standard to handle modern messages in the form of a Restful API that can be driven by either JSON or XML or... whatever. We need that and the fact that we don't have that many have gone out and created one. We are already behind.

What we in the industry have noticed is that we have a physical and psychological investment in the current technologies, AL3 and XML 1.x and we are not ready to just throw away those standards and infrastructure we have built. We as an industry have been hard to change what has and is currently working fine.

What 2.0 Brings to ACORD is to adapt Agile concepts into the current XML model , that is change. Because the best way to handle change is little by little. Or I should say always knowing that there is change and just adapting it into the process of building the product. 2.0 is going to help us get there because we have added extensibility, and some support for newer message styles. 2.0 will allow organizations who have an investment in 1.x to move that forward and transition into the Restful API that we want and need.

The story that comes to mind is the frog in a boiling pot. AML experienced this where we tried a new standard right away and didn't get the traction that we wanted and we didn't get adoption. With Restful API's as our current goal 2.0 is our avenue that allows organizations to get there and provides this transition path to adapt their messages into something more efficent.

That is why I don't think flattening and reusabiltiy in 2.0 are wrong. Both of those are going to give us those things we need to transition.

Now with that being said. I think we need to get to the Next step is best of breed insurance API as soon as possible. I need it in my organization and I think many organizations that are starting fresh new projects need it. And the lack of the industry having a standard API is causing us to individually invent our own API's. Every vendor is creating an API that I have to transform my data too.

So I am so glad that you have come to the Party and help us develop the something new in what I am coining the ACORD "Insurance" API. Let's get started.

Thanks again.