Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include serialization format version in serialization #58

Closed
enikao opened this issue Jan 16, 2023 · 3 comments
Closed

Include serialization format version in serialization #58

enikao opened this issue Jan 16, 2023 · 3 comments

Comments

@enikao
Copy link
Contributor

enikao commented Jan 16, 2023

We might change the format of the serialization over time.
Does it make sense to store the format version in each serialization, or shall it be transported otherwise?

Example without version info:

[
  {
    "type": "LIonCore_M3_Metamodel",
    "id": "txjxNU9yRzEuyghtmgJK_l-nF93qWt7d1vErz5RbLow",
    ...
  },
  {
    "type": "LIonCore_M3_PrimitiveType",
    "id": "INhBvWyXvxwNsePuX0rdNGB_J9hi85cTb1Q0APXCyJ0",
    ...
  }
]

Example including version info:

{
  "format_version": "1",
  "nodes": [
    {
      "type": "LIonCore_M3_Metamodel",
      "id": "txjxNU9yRzEuyghtmgJK_l-nF93qWt7d1vErz5RbLow",
      ...
    },
    {
      "type": "LIonCore_M3_PrimitiveType",
      "id": "INhBvWyXvxwNsePuX0rdNGB_J9hi85cTb1Q0APXCyJ0",
      ...
    }
  ]
}

Questions

  • Can we require (as per JSON spec) the format version to always be the first entry?
    -> We can enforce by having only two entries on highest level
  • How is this usually done in web context?

Arguments

pro:

  • We know of any piece of serialized nodes how to interpret them, no matter whether we got it from a file, some protocol, web form, whatever.

con:

  • Might duplicate info transmitted somewhere else (e.g. some HTTP header or URL), and we need to deal with inconsistent info.

Decision

We include one version number in serialization format.
This version is a single integer, to be incremented with each new version.
A new version might be needed if the LIonCore M3, the serialization format, or both change.
The version must be the first entry in the top-level node serialization JSON object named serializationFormatVersion, as in:

{
  "serializationFormatVersion": 1,
  "nodes": [
    {
      "concept": "LIonCore_M3_Metamodel",
      "id": "txjxNU9yRzEuyghtmgJK_l-nF93qWt7d1vErz5RbLow",
      ...
    },
  ]
}

Rationale: Both the LIonCore M3 and the serialization format might change in the future. Most probably, they both change together (e.g. if we introduced a list of annotations for each node). If only the M3 changed and the serialization format stayed the same, it's acceptable to have two versions with the same serialization formats. Encoding M3 and serialization format number separately would introduce additional complexity through combinatorics of the two versions.

We want to be explicit about which version of both M3 and serialization format was used to write a serialization, such that the reader does not need to guess or detect it implicitly. The reader needs this information at the earliest possible time.

@enikao enikao added the repo label Jan 16, 2023
@enikao
Copy link
Contributor Author

enikao commented Jan 22, 2023

What's the name of the version field? version? format_version? lioncore_version? something else?

@dslmeinte
Copy link
Contributor

serializationFormatVersion, or versionOfSerializationFormat? (Preferably something camel-cased, not snake-cased.)

@enikao
Copy link
Contributor Author

enikao commented Jan 30, 2023

Decision via Slack vote: serializationFormatVersion

Rationale: Very specific, little room for interpretation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants