1

I tried to convert the JSON data

{
  "a": {
    "b": null
  }
}

to XML using an online converter. The response was

<a>
  <b />
</a>

Converting this back to JSON using the same converter gave me

{
  "a": {

  }
}

This made me wonder – if you're explicitly given a null value, are you required to preserve it when dealing with JSON? I'm fairly sure that the XML <a><b /></a> is not equivalent to <a></a>, and especially not <a /> (which happens to be what I get when I continue with the same exercise).

In other words, if I'm handed JSON of unknown origin and am supposed to hand it over to an unknown recepient, am I required to preserve the nulls or can I safely remove them? Conversely, can I rely on my nulls to end up in the same way I outputted them when delivered by third-party software?

Here's a similar question: Should JSON include null values – However, the question there is whether the code should output nulls if you define the format yourself, not what you should do if you don't know anything about the original format.

EDIT – Clarification: The way I asked the question was bad and apparently caused confusion. To rephrase it: I do understand that XML and JSON are different formats and are able to carry different kinds of (meta)data. I do know that null is a valid value, as defined by RFC4627. I do understand that there are different ways to convert between XML and JSON since the formats don't have a 1-to-1 relationship. I do understand that the converter I found might be buggy. However, the fact that the same converter didn't provide the same conversion in both directions (no information was lost when converting from "b": null to <b /> and a similar translation in the opposite direction would have been possible) made me wonder something that I couldn't find an answer to despite attempts:

  • Is it legal, according to the JSON standard, to treat {"a":{"b":null}} and {"a":{}} as one and the same object when transferring them on behalf of other software?

Note that I'm here assuming that it's legal to add or remove whitespace as I see fit (e.g. pretty-printing, which is okay according to RFC4627), and even to rearrange the name/value pairs in a collection (again according to RFC4627). I simply don't know if a null must be preserved in the same way as significant data, or can be dropped in the same way as insignificant whitespace.

Community
  • 1
  • 1
Anders Sjöqvist
  • 3,372
  • 4
  • 21
  • 22
  • JSON is an exchange format and doesn't define what you have to do with what you receive. Tee choice of the converter you link to is to preserve the fact that you defined `b` instead of simply not sending it. I see no problem. – Denys Séguret Jun 18 '12 at 11:13
  • @dystroy: I didn't mean to ask what to do with JSON that someone is sending to me. I want to figure out how I'm supposed to treat JSON that is meant for someone else in a legal way. Also, you're focusing on what happened when the JSON was translated to XML. What I wanted to know is how a JSON object relates to other JSON objects. – Anders Sjöqvist Jun 18 '12 at 15:58
  • I've noticed that there have been votes to close this question. I've read the FAQ carefully and I don't see the problem. I'd appreciate if you could give me an explanation of what's wrong. Please, at least give me a chance to learn. – Anders Sjöqvist Jun 18 '12 at 16:18

2 Answers2

0

Yes, null is a separate value in JSON, and is distinct from not having an attribute, obviously. Also, you can see this question about nulls in XML. The thing to conclude here isn't that there is something wrong with JSON or XML, but simply that the tools you use aren't coded to handle these cases.

Community
  • 1
  • 1
Amadan
  • 191,408
  • 23
  • 240
  • 301
  • You might be correct, but I'm not sure your arguments are valid. As I understand it, you're saying that since XML works in a certain way, JSON must as well. However, in JSON [an object is an unordered set of name/value pairs](http://json.org/), and nothing can therefore be assumed about the order in a certain representation. This is certainly not the case with XML. In other words, child nodes can't be arbitrarily reordered simply because they have different names. Hence, it's incorrect to refer to what's correct in XML to prove what's correct in JSON. – Anders Sjöqvist Jun 18 '12 at 15:16
  • @AndersSjöqvist: You misunderstand me. Those were two separate arguments, claiming that both XML and JSON have a way to represent a `null` in a standard way. I was not inferring correctness of one from the other. Going on the premise that data loss is bad unless intentional, I conclude that the tools messed up: they turned a null value of JSON into an empty string in XML, and then when going back to JSON, dropped the empty string as non-existent attribute. Neither is a behaviour I would expect. – Amadan Jun 18 '12 at 16:27
0

One of the problems in converting JSON to XML is that if you try and make the conversion lossless, you end up with somewhat "unnatural" XML, whereas if you try to create the most natural XML representation, it ends up losing information. That's why there are lots of different converters that all do it in slightly different ways. Choose the one that meets your requirements.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • Thanks Michael. Your answer is helpful and highlights the fact that conversion is tricky, but what I'd really want to find out is how *I'm* supposed to treat JSON without violating any rules, not find a tool that performs a certain operation for me. – Anders Sjöqvist Jun 18 '12 at 16:12
  • You can handle JSON any way you like: only you know what it means. If null means zero in your particular input, then treat it as zero. As with SQL, the meaning of null is entirely a matter for agreement between sender and recipient. – Michael Kay Jun 20 '12 at 14:24