Implement Independent Serialization Policies for Primitive Data Types when converting XML to JSON

[twigglius]

[This is an enhancement request, not a true issue]

When converting XML to JSON the code does its best to determine proper serialization/deserialization but it is sometimes incorrect. I should have the ability to tell the program to treat primitive data types according to my requirements.

For example I have an XML message I want to convert to JSON, but I want every field to written as a String. I have an element in my XML with a value of '5237E8' after conversion, the JSON shows the value as 5.237E11. It assumed it was a double and converted it.

Another example is I have elements with leading 0's that need to be maintained in the conversion to json, but those 0's are removed in the serialization/deserialization.

This is standard functionality in other similar libraries such as GSON.

[johnjaylward]

This project does not support schema validation. While this feature is often requested for the XML processing, it would be a lot of work to fit it in.

Also, looking at the JSON number spec, your example matches a number. If you can control the XML generation at all, I would suggest modifying the output of 5237E8 to have quotes around it, or other non-numeric characters.

For the leading 0 problem, I agree that the JSON spec does not allow for them (except for leading a decimal like 0.5), so those values should be treated as string data. If you want, you can open a issue for that case specifically.

[mikesterlingw]

I'm working on a pull request to address this. I think what @twigglius is trying to get at is not schema validation but a way to treat all numbers as strings.

[stleary]

@twigglius What option does GSON provide that allows you to work around the problem?

[johnjaylward]

@mikesterlingw any movement on the pull request for this?

[stleary]

Feel free to submit a pull request if you come up with an implementation that meets your requirements while not breaking existing applications.