List with several identical user extension elements in XML: correct conversion into JSON/JSON-LD?

[RalphTro]

Dear @sboeckelmann and colleagues,

I just came across the following observation while using your (great) tool which I want to discuss with you:

Let us assume we have the following user extension element in XML:

    <example:userListElement>
          <entry>1</entry>
      <entry>2</entry>
          <entry>3</entry>
        </example:userListElement>

Right now, the tool converts it into the following JSON structure:

 "example:userListElement": {
          "entry": [
            "1",
            "2",
            "3"
          ]
        }, 

Are you sure that this is really the correct/desired output? I am especially struggling with how "entry" becomes a list name.

My expectation was that the tool would convert it into sth. like this:

(a)

   {"example:userListElement": [
          {"entry": "1"},
          {"entry": "2"},
          {"entry": "3"}
          ]
}

or (b)

       {"example:userListElement": [
          "1",
          "2",
          "3"
          ]
}

What is your opinion on this matter?

FYC, I enclosed the input XML file which I was using.

XMLWithRepeatableUserExtensionElements.xml.zip

Many thanks in advance for sharing your thoughts.

Kind regards, Ralph

[sboeckelmann]

Dear @RalphTro, the example you provided represents an edge case. (b)

       {"example:userListElement": [
          "1",
          "2",
          "3"
          ]
}

would be my preferred JSON representation.

Actually, in my opinion, this is would be the ideal JSON for such a custom extension:

       {"example:userList": [
          "1",
          "2",
          "3"
          ]
}

It's impossible to come up with a generic way of converting custom extension into into nice looking XML and JSON, without providing an SPI (Service Provider Interface) to the converter, that is responsible for taking care of the tiny details when converting user defined extension.

And that's reason why you ended up geting something between a) and b) 😄

[RalphTro]

Many thanks for your quick feedback, Sven!

Yes, I think the implication/summary of this matter is: whenever an EPCIS implementation requires to support both syntaxes and has user extensions, the respective solution provider should generate the messages in both XML and JSON/JSON-LD and may provide, if applicable, an SPI to ensure a desired conversion behaviour.

Closing this ticket as this cannot be addressed through the tool.

[sboeckelmann]

Dear @RalphTro I had to re-open this issue because I realized, apart from what we may expect or not expect, or whatever personal preference may exist: The most important requirement would be, that the conversion is working in such a way, that the event hash generator will always create the same hash for JSON and XML, even it has been converted by the document converter tool.

But that also means if users are actually applying some beautification logic, like I mentioned in my previous comment, this may become a huge issue when creating event hashes.

[RalphTro]

Dear @sboeckelmann , Good point. I agree that this subject may be worth discussing further.

Before we continue though, I think it would be helpful for the SMG to understand the use case. In which situations would this be important to have from your POV?

As soon as we identified a compelling Use Case: I am not sure whether all use/edge cases can be tackled technically (see your earlier comment), so how do you like the idea of at least defining a small set of conventions/rules for the most common user extension structures so that independent implementations translate a given JSON-/JSON-LD structure into XML in a consistent manner? Or do you have sth. different in mind?