Require empty members in serialization

[ftomassetti]

We should not include keys with empty values, as specified in LionWeb-io/specification#59

[joswarmer]

In #59 in the decision text at the end it states that:
Sub members (e.g. property LIonCore_M3_Concept_abstract or child LIonCore_M3_FeaturesContainer_features) can be present with a value of null (for properties) or empty list [] for links. Not being present and being present with null/[] value mean exactly the same and are interchangable. Any LIonWeb implmementation must be able to read both variants.

So it seems that there we allow both options.

[enikao]

I agree -- we actually chose another option -- I think "A*"? We should adjust the text.

[dslmeinte]

Ah OK, I really was on the B bandwagon in the meanwhile, at least for validation. (The TS implementations actually don't emit empty values, and accept either.)

[joswarmer]

It is confusing, it states we have chose decision B, but the description actually seems to be A.
Your implementation is ok for A as well :-).

[enikao]

I changed #59 to state "A'". Is this according to everybody's understanding?

[dslmeinte]

I think there's still a “thing” (not wanting to call it a “problem”) with undefined vs. null. In JSON/JavaScript there is a difference, even if there might not be in Java. We even say explicitly that [null] is semantically different from [].

[enikao]

I think undefined is not valid JSON: https://stackoverflow.com/questions/13796751/json-undefined-value-type

[dslmeinte]

To be precise: JSON doesn't have a literal undefined in its syntax, but the value of a “missing” value would be undefined when explicitly queried - at least in {Java|Type}Script, and in many JSON libraries for other languages. So: “value missing” != null. null could be used, but we'd have to explicitly state its semantics.

[enikao]

I don't really get it. Let's look at an example:

{
  "a": "hello",
  "b": null,
  "c": [],
  "d": {},
  "e": null,
  "f": undefined,
  "g": 
}

To my understanding, a, b, c, d, e are all valid JSON.
f, g, (and h: the non-existent entry) are NOT valid JSON, so we don't have to care for them.

[ftomassetti]

For now I will then leave code as-is, as it consider absence of keys and empty values as being equivalent. The implementation serialize the empty keys at the moment

[dslmeinte]

@enikao Correct, but the problem is what code does with the JSON. If null is supposed to mean something different than undefined, but you happen to use a JSON library that erases the difference (post-parse) then you can't be compliant.

[joswarmer]

@dslmeinte Isn't it about the semantics of the value in the JSON: do we regard undefined different from null?

I cannot imagine that we would want to make a difference between null and undefined for property values of LionWeb models. That might just be a lack of my imagination, so enlighten me if I am missing something.

Whether that is easy to reflect in a programming language is not in scope for the Data Interchange meta-model. In practice, however, we should think about the consequences in the popular languages, at least the ones we are using ourselves. Making this difference in Java is hard, as Java does not support it out of the box, while this is easy to do support JS/TS. Making no difference means that we might get different values in JS/TS objects if we use the nativee JSON reader/parser, sop that might be more difficult from that side.

[dslmeinte]

True: null and undefined should be regarded as the same value.

Whether some-GPL-with-some-JSON-lib was going you to tell the difference in the first place, is then also not relevant - which is a good design choice IMO.

[enikao]

I still don't get it: undefined cannot appear in JSON. Whatever any programming language does if we ask "please get me the value of key 'x'" -- with 'x' being not present in the transmitted data -- is out of scope of the data format.
(In case of JavaScript: it returns undefined.)

Anyhow, we actually defined that cases e and h above have to be treated the same (for properties). For links, cases c and h have to be treated the same.
This leaves properties with case c (empty array) and links with case e (null). I'd say that's an invalid format.