Bug in version 20160212?

[sunmingtao]

XML.toJSONObject("<code>29.</code>");returns {"code": 29}, rather than {"code": "29."}

Earlier versions seem fine.

[stleary]

Will investigate why the behavior has changed, but this looks correct. If a value can be converted to numeric, the conversion should be performed.

[johnjaylward]

@stleary, it changed back in a commit I made for the number parsing. I deprecated the XML.stringToValue method and had it call JSONObject.stringToValue instead for consistency. PR #188 was the one.

@sunmingtao, there are a lot of complaints with how we handle the XML to JSON conversions. I doubt this will get fixed short of modifying the XML reader to always use string values, but I'm sure someone will complain about that as well.

[stleary]

@johnjaylward Thanks for clarifying. So now we know why it changed, and it seems to be the right thing to do.

We know that JSON/XML conversions will always be broken to some degree, because of the nature of the format: data vs document. With that in mind, it may be worth considering allowing some degree of tuning by the developer. For example, the default would be the code as currently implemented, but a dev may choose to emit values as strings, instead of conversion to numeric or other representations. Other settings could be considered as well. Please post here if you have any thoughts or suggestions.

[johnjaylward]

@stleary there was a simliar PR for the JSONML class, #70 & #97. The implementation looks decent enough there and may be applicable to handling this scenario

[stleary]

I think this issue is resolved.