No JSON array for I048/030 and I062/510 if only one extent is present in the data item

[tmartincevic]

This issue is related to the recent fix for #104 and #156. If there is more than one extent in I048/030 or I062/510, a JSON array is produced as expected, for example:

"I510":[{
                "SDPSUID":115,
                "STN":500,
                "FX":1},{
                "SDPSUID":115,
                "STN":1019,
                "FX":0}]

But, if there is only one extent in the data item, a simple JSON object is produced:

        "I510":{
                "SDPSUID":115,
                "STN":1019,
                "FX":0}

In this case I would still expect an array with a single element inside:

        "I510":[{
                "SDPSUID":115,
                "STN":1019,
                "FX":0}]

Capture file:
048-030-and-062-510.zip

[dsalantic]

That was intentional. I wanted to avoid too many changes in decoder behavior.
If we implement a list non repeating variable items (even for one element) , then many Variable items will change in all categories and will affect everyone who use the decoder.
That's just my opinion that's it better to keep it as it is to keep backward compatibility, but maybe I change my mind in some later upgrade (maybe some later major release where backward compatibility is changed).

[tmartincevic]

I see. I agree - you wouldn't want to turn every variable item into a list. The issue for me as a parser user is that standard JSON unmarshallers generally expect either an object or a list but can't handle both at the same time. The workaround for me would be to implement a custom unmarshaller with some internal logic to handle objects/lists just for these two items. But it would be so convenient if these two data items would always produce a list.
Would it be possible to introduce an attribute or something in XML config that would indicate that these items are "variable length but produce a list"? That way all other variable items would still produce single objects and I048/030 and I062/510 would always produce a list even with a single element. I wish the protocol designers made these two items repetitive instead of variable - it would have been much cleaner and more consistent with the rest of the protocol.

[dsalantic]

What do you think about following proposal:

if Variable item definition contains 1 Fixed subitem and Variable is not part of Compound presence definition
show elements in list
else if Variable item definition contains more than 1 fixed subitem
show elements in dictionary

This will solve I048/030 and I062/510 as they will always be shown as list, and not many other Variable definitions will be affected because most contain more then one Fixed definition.

[tmartincevic]

I'm not clear about the last part where you talk about "other Variable definitions that will be affected". Those would be Variable items with 1 Fixed subitem that are part of Compound definition? And they would be affected because now they would be enclosed in a list? Can you give a concrete example of one of these affected items? I scanned the messages that I'm using and the only one that fits these criteria (I think) would be CAT048 RE, M4E (CAT048 Appendix A Ed. 1.7), but I'm only working with a subset of 6 messages.

[dsalantic]

Here is the list of category/items that would be affected with my proposal. Those will be presented as list even if they have only one element:

001/030
001/130
001/210
002/050
002/060
002/080
008/100
008/110
019/553
020/030
021/110
023/110
025/100
048/030
062/510
252/240

[tmartincevic]

Ok, I see it now. It's really based on the number of subitems and Compound vs. Non-Compound does not matter since most of them are not Compound but I021/110 is. And actually some of them (I001/030, I002/080, I019/553, I020/030) currently have the exact same problem as I048/030 and I062/510 so putting them in a list would be beneficial. So yes, I think your proposal looks reasonable and would resolve the issue.

[dsalantic]

Thank you for you comments and test samples.
I changed it now in this way and published a new version.