we should not use "data" to be the key of json

[kunlinyu]

https://github.com/opengeospatial/IndoorGML-SWG/blob/27d50895a4365b5bfd8f7f5c5315bbb187fc19ff/IndoorGML2/IndoorGML2-v.0.3/Part%20II/JSON/indoorjson2_dummy.json#L12C18-L12C18

There are some json keys "C1", "C2", "R1", "E1" in it.
I guess it is kind of "id", which is "data", but not "keys".

Think about it, in the parsing programing, we should do something like:
indoorFeatures["layers"][0]["primalSpace"]["cellSpaceMember"][3];

but this is not good:
indoorFeatures["layers"]["TopographicLayer"]["primalSpace"]["cellSpaceMember"]["C1"];
Because different encoder or parser may use different id genaration. Which should nothing to do with standard.

we should never put data in the [ ], but we should put keys in [ ];
And put data in [ ] will make the schema file wired. It is hard to describe it.

[TaehoonK]

@kunlinyu I'm sorry, but I don't fully understand this explanation.

"I guess it is kind of "id", which is "data", but not "keys"."

Q1. What is the difference between "data" and "key" you are describing here?

"Because different encoder or parser may use different id generation. Which should nothing to do with standard."

Q2. Why does it say ID generation? Isn't it just parsing the incoming data?

Q3. Also, you gave 2 examples, are you saying that the first approach (using the indexes of the array) is better?
I don't see why it's better from a parsing perspective.

I would be grateful if you could answer.

[kunlinyu]

A1: for example

{
"name": "Adam",
"age": 23,
"height": 1.70
}

"Adam" is data, 23 is data, 1.70 is data also.
"name" is key, "age" is key, "height" is key also.
Key is not data. key is schema.
The json schema should always describe key.
If you put data on the key, then the schema and encoder will be wired.

this is a bad example:

"Adam" : {
  "age": 23,
  "height": 1.70
}

this example use "Adam" as key, but "Adam" is data. We should not put data on key.

A2:

I guess "C1", "C2", "R1", "E1" is kind of ID.
of cause the coder can write a encoder or decoder for them but it is not good.
because it is data which should not be a key of json.
I think a better way is:

           {
            "id": "C1";
            "type": "CellSpace",
            "duality": "R1",
            "poi": false,
            "name": "001",
            "level": "1",
            "cellSpaceGeom": {
              "type": "Solid",
              "boundaries": [
                [ [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[1, 2, 6, 5]], [[2, 3, 7, 6]], [[3, 0, 4, 7]] ]
              ]
            }

then use an array to wrap them.

A3:
Use index is better, because index is not data and can be a key.
And if we use index, then the *Member field is array.
All *Member field is array in IndoorGML standard and XSD.

And, at last, ID can be generated automatically without any declaration for high level coding language.