-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Independent Serialization Policies for Primitive Data Types when converting XML to JSON #194
Comments
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. |
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. |
@twigglius What option does GSON provide that allows you to work around the problem? |
@mikesterlingw any movement on the pull request for this? |
Feel free to submit a pull request if you come up with an implementation that meets your requirements while not breaking existing applications. |
[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.
The text was updated successfully, but these errors were encountered: