If I read the document correctly, there are 2 different ways to define XML attributes in the resulting JSON. Depending if there is a text node or not.
I would very much argue against this concept but add an object name for text objects.
I've thought about your question and reopened the solved remarks:since we only have one mixed element (i.e comment) it is probably easier to make a specific mapping rather than a complicated generic mapping.
The other 2 text only elements would also become simple arrays of string rather than nested arrays
As we are working on some projects where we use XJDF/JSON, I will show some examples on how the resulting JSON will look like.
I've also added a comparison table to the mapping page.
feel free to chime in
as the goal is now (as I understand it) to allow a programatically roundtrip between JSON and XML, we loose a lot of functionality of JSON.
Eg. as intents are still collections, I cannot write something like
Instead, I have to first the LayoutIntent item im the Intent collection to use this object. Or use frameworks like Jsonata to query the JSON.As of now, I still see the need to map the xJDF-JSON into a JSON representation in our applications. Hence I fail to see the advantage of a current JSON based xJDF version. My hope was to use the xJDF object model as good as possible with only the need to add additional private models where needed.What am I missing?
Discussing in Jira certainly makes sense and your proposal was discussed at the interop.
Here is a copy of my comment in JDF-716
You cal also create detailed issues and link them - see: JDF-839
I agree, and in the end it is the choice of swallowing a frog or a toad...We had discussed that solution using "#text" but there are multiple issues:1.) you cant really use any key that maps to an invalid code variable name because of automagic json - code mappers.2.) there is no way to actually know whether "text" is text body or @text.
obviously, these are not hard blockers, e.g. using "_text_" of some other certainly legal but improbable variable name.
In the end, it boils down to flipping a coin, which solution is preferrable.Luckily, we are talking about 3 elements (Comment, AdressLine and OrganizationalUnit)
Powered by a free Atlassian Confluence Open Source Project License granted to CIP4. Evaluate Confluence today.