Hi Vaibhav,
The XML to JSON policy outputs the JSON using the Badgerfish convention. This was done as the policy is general purpose and has to handle XML with namespaces and attributes. The Badgerfish artifacts would not be needed if the XML document did not utilize namespaces and attributes. I would suggest you submit a request for enhancement using https://www.ibm.com/developerworks/rfe/?PROD_ID=1517 to request an option on this policy to output "plain" JSON, ie, throwing away any namespace or attributes in the XML to produce a JSON with name:value pairs at leaf properties, or even a "relaxed" JSON, ie, only producing the Badgerfish artifacts when those input XML elements have namespaces and attributes, otherwise producing the "plain" JSON for those elements.
In the meantime, customers can use the XML to JSON policy and then follow it with a GatewayScript policy that "de-badgerfishes" the JSON. The example GatewayScript code I have attached will throw away any namespace or attributes nodes from the XML in the resulting JSON, producing the "plain" JSON that you're wanting.
As for the map policy and "complex transformations where merging or transforming arrays is required", I'll note that many issues seen in this space were caused by the map policy UI not effectively creating the map actions in the swagger for these use cases. Significant enhancements to the UI for array mappings were made in the 5.0.8.8 time frame (fall of 2019), but you also have the option in some cases to simply map from one input object/array to the output array directly instead of using the individual properties, and then write the complex mapping GatewayScript by clicking on the green circle at the output property to bring up the Configure Map dialog. This approach would allow you to map the easier parts of the schema as always but add special handling for these complex arrays, all in one map policy. I'm working on a developerWorks article that will provide some examples of these use cases that will hopefully be published in the near future.
Best Regards,
Steve