Allow additional info in serialization

[enikao]

We should allow to pass additional info in serialization format at some well-defined place.

Example:

{
    "serializationFormatVersion": "1",
    "additionalBla": "Blubb", // additional info here
    "nodes": [
      {
        "type": "Library",
        "id": "idBobLib",
        "properties": {
          "LibraryName": "Bob's library"
        },
        "children": {
          "LibraryBooks": [
            "idExplorer"
          ]
        },
        "parent": null
      }
  ]
}

[dslmeinte]

Why the "should"? I agree with the "well-defined place"-part, but I'm not entirely sure about the rest. What use case is facilitated with this? Can't the same not be done through additional, separate info (i.e., in a separate JSON) that references the serialization (AKA a "marking model").

[enikao]

This is a reminder of some discussion in some project context, so not well fleshed out.

I actually think this kind of info should be outside the serialization format, e.g.

{
  "responseCode": 200,
  "additionalBla": "Blubb",
  "serialization": {
    "serializationFormatVersion": "1",
    "nodes": [
       {
         ...
       }
    ]
  }
}

Rationale: Serialization format can also be just a file, and I'd prefer as little ambiguity as possible there (i.e. no "hidden channels").

[enikao]

Decision on 2023-10-13: Don't allow additional fields (for now)

Rationale:

• Additional info can be outside the LW serialization structure (see comment above)
• Even if a LW parser would ignore additional fields, it would not keep them around / send them back (or, if we required that, would pose a lot of additional effort on LW implementations).
• If we allowed additional fields in the future, we could still be backwards-compatible.

We might revise this decision in the future if we find a good use case.

[joswarmer]

Should close this