Videos
Factsheet
Well, you can't. As you said, you can represent arrays and dictionaries. You have two choices.
Represent the set as an array. Advantage: Converting from set to array and back is usually easy. Disadvantage: An array has an implied order, which a set doesn't, so converting identical sets to JSON arrays can create arrays that would be considered different. There is no way to enforce that array elements are unique, so a JSON array might not contain a valid set (obviously you could just ignore the duplicates; that's what is likely to happen anyway).
Represent the set as a dictionary, with an arbitrary value per key, for example 0 or null. If you just ignore the values, this is a perfect match. On the other hand, you may have no library support for extracting the keys of a dictionary as a set, or for turning a set into a dictionary.
In my programming environment, conversion between set and array is easier (array to set will lose duplicate values, which either shouldn't be there, or would be considered correct), so for that reason I would go with arrays. But that is very much a matter of opinion.
BUT: There is a big fat elephant in the room that hasn't been mentioned. The keys in a JSON dictionary can only be strings. If your set isn't a set of strings, then you only have the choice of using an array.
Don't try to represent sets in JSON. Do it when parsing the data instead.
Your JSON data should have a schema which specifies which fields should be treated as a set, or you may have a metadata embedded in the JSON data itself that describes when a list should be treated as a set (e.g. {"houses": {"_type": "set", "value": [...]}}) or with a naming convention.
Note that according to JSON standard, a JSON object can have duplicate keys. ECMA-404 wordings:
Objects
[...] The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.
AFAICD, nothing in the spec forbids non unique names, and there are many JSON parser implementations that can parse non unique object names. RFC 7159 discourages non unique names for interoperability, but specifically don't forbid it either, and goes on to list how various parsers have been seen handling non unique object names.
And ECMA 404 also doesn't require that array ordering be preserved:
Arrays
The JSON syntax does not define any specific meaning to the ordering of the values. However, the JSON array structure is often used in situations where there is some semantics to the ordering.
This wording allows applications to use arrays to represent sets if they so choose.
No.
JSON is data-only. If you include a comment, then it must be data too.
You could have a designated data element called "_comment" (or something) that should be ignored by apps that use the JSON data.
You would probably be better having the comment in the processes that generates/receives the JSON, as they are supposed to know what the JSON data will be in advance, or at least the structure of it.
But if you decided to:
{
"_comment": "comment text goes here...",
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
No, comments of the form //… or /*…*/ are not allowed in JSON. This answer is based on:
- https://www.json.org
- RFC 4627:
The
application/jsonMedia Type for JavaScript Object Notation (JSON) - RFC 8259 The JavaScript Object Notation (JSON) Data Interchange Format (supercedes RFCs 4627, 7158, 7159)