Open jonnio opened 4 years ago
Is your suggestion to avoid arrays completely in the JSON? There are a number of things in EDI that are naturally repeated, without any visible identifier for each repetition. For example, transactions within a functional group, or functional groups within an interchange. Or repetitions of a segment loop. Representing these as JSON arrays seems to me the obvious and simplest choice. Using your example, if there were multiple N1-1000A loops (I realize that this particular loop is not repeated but some loops are) how would that work? the keys need to be unique.
I'm attempting to create a schema for this json format for a specific X12 transaction type and version, and running into challenges that I think are directly related to your point about the anonymous arrays. I am experimenting with specific alternative formats, looking to choose one that is is more convenient for the type of navigation you have in mind, well-suited for transaction-specific schemas, and yet is reasonably readable by humans.
Would you be willing to give feedback/comments on the various alternatives I am considering? I am envisioning a major new release that continues to support the original "light" format as well as a new format; it would be important to get some trial use first. If you are interested, please contact me separately. Thanks.
Yes! In the ideal state, we should be able to take a json document and convert it into a javascript object model that is simple to navigate. I could write you a test case that demonstrates it and let you provide the implementation that makes it work.
When generating the JSON, the output does not include names for the arrays. When converting to an object, the arrays are anonymous and makes navigating the objects very difficult.
for example
should be something like this which has the actual object name vs. array.