Should serialization contain a list of used languages?

[enikao]

Both MPS and EMF store the list of used languages in their storage files. We could do the same:

{
  "serializationFormatVersion": "1",
  "languages": [
    {
      "key ": "idOfLibraryMetamodel",
      "version": "1"
    },
    {
      "key": "idOfMapMetamodel",
      "version": "1"
    },
    {
      "key": "namedStuffMetamodel",
      "version": "1"
    },
  ],
  "nodes": [
    {
      "id": "aaa",
      "language": ,
      "concept": {
        "language": "idOfLibraryMetamodel",
        "version": "1",
        "key": "libraryTravelBook"
      },
      "properties": [
        {
          "property": {
            "language": "namedStuffMetamodel",
            "version": "1",
            "key": "namedStuffName"
          },
          "value": "Discover Rome"
        }
      ],
      "children": [],
      "references": [
        {
          "reference": {
            "language": "idOfLibraryMetamodel",
            "version": "1",
            "key": "bookMaps"
          },
          "targets": [
            {
              "resolveInfo": "Rome",
              "reference": "bbb"
            }
          ]
        }
      ]
    },
    {
      "id": "bbb",
      "concept": {
        "language": "idOfMapMetamodel",
        "version": "1",
        "key": "cityMap"
      },
      "properties": [
        {
          "property": {
            "language": "namedStuffMetamodel",
            "version": "1",
            "key": "namedStuffName"
          },
          "value": "Roma"
        }
      ],
      "children": [
        {
          "containment": {
            "language": "idOfMapMetamodel",
            "version": "1",
            "key": "sizeId"
          },
          "children": [
            "ccc"
          ]
        }
      ],
      "references": []
    },
    {
      "id": "ccc",
      "concept": {
        "language": "idOfMapMetamodel",
        "version": "1",
        "key": "GroundArea"
      },
      "properties": [
        {
          "property": {
            "language": "idOfMapMetamodel",
            "version": "1",
            "key": "squareKilometers"
          },
          "value": "1285"
        }
      ],
      "children": [],
      "references": []
    }
  ]
}

• idOfLibraryMetamodel is required for libraryTravelBook and bookMaps
• idOfMapMetamodel is required for cityMap, sizeId, GroundArea, and squareKilometers
• namedStuffMetamodel is required for namedStuffName

Pros:

• Easy to determine for a client whether they can work with the metamodel

Cons:

• Redundant information, thus another way to screw up the format

[enikao]

This is not the same as Metamodel.dependsOn (as discussed in #50): Metamodel.dependsOn describes relations between metamodels. Here, we discuss relations between instances and their metamodel.

[ftomassetti]

It seems a good idea. In this way we could quickly determine if the model consumer is able to process the model, without going through the whole file

[enikao]

Relates to #7

[enikao]

Based on discussion on 2023-03-03 (#7, #89, #90), we add a field metamodels to our serialization format:

{
  "serializationFormatVersion": "1",
  "metamodels": [
    {
      "key": "idOfLibraryMetamodel",
      "version": "1"
    },
    {
      "key": "idOfMapMetamodel",
      "version": "1"
    },
    {
      "key": "idOfLibraryMetamodel",
      "version": "2"
    },
  ],
  "nodes": [ ... ]
}

[enikao]

Do we want to enforce only one version of any given metamodel being used in one (bulk) serialization?
That would imply the client can tell which version it wants for each metamodel.

Pro:

• A client doesn’t want to deal with metamodel versioning
• A client might use different java classes for different versions of a metamodel (e.g. my.client.metamodel.v1.Concept vs. my.client.metamodel.v2.Concept)

Con:

• More complicated API (need to include version per metamodel)
• Assume a client requests a subtree. The subtree mostly contains nodes from metamodel version 3, but a few interspersed nodes from metamodel version 2. Would the server filter them out? If so, the client would probably write back the subtree with missing nodes, or do some other inconsistent processing.

==> Decision: We always contain all nodes, independent of the metamodel version. The metamodels header lists all metamodels, so the client can easily make an informed decision whether it can handle the model chunk.

[joswarmer]

Sounds like a good idea to have this list of used meta-models+version in the JSON for the very reasons that Federico has given. I would suggest that there should be one version per meta-model in one JSON.

The only potential use case I can see for having nodes of multiple versions of one meta-model in a JSON might be in a migration context. But in general it is unlikely that many tools can deal with multiple met-modelo versions in one model.

[enikao]

I think Jos' argument is sound: multiple versions of the same metamodel within the same model chunk is a migration issue.

What about:

• By default, each metamodel can be present only once in a model chunk (for all APIs).
• This also means that meta-pointers (Establish term meta-pointer #89) are pairs, not triplets: We can omit the metamodel version.
• If a chunk would contain more than one version of a metamodel, the whole query fails with appropriate error.
• There is a special migration API to handle mixed metamodel versions.

[markusvoelter]

I don't see Jos' comments as a new argument. We had discussed this in the meeting. The migration issue is still there, right? Sure, you can query twice, once for the old model, once for the new model (and then each reply has one meta model version in it), but the client still has to deal with two. I don't quite see what it is so important that the JSON only contains one version. But I won't die on that hill, I am fine with deciding for one.

Regarding the meta-pointer: in general, a meta-pointer is still a triplet. Eg in the (not yet defined) notification or delta APIs.

 meta = {"com.my.language", "2", "PlusExpression"}

But there's an abbreviated version if we have a header:

header : {
  my : {"com.my.language", "2"}
  ...
} 

...

 meta : {"my", "PlusExpression"}

[dslmeinte]

Having only 1 version per metamodel in the serialization prevents the protocol being usable to have anything outside the repository itself do the migration (so neither a client, nor a processor). The downside is that a client might have to decide e.g. that “I can't load this model because my runtime only supports one set of types at any time [or whatever], so I'm going to set in motion that this model gets migrated properly”.

As for the abbreviating triplets: I think we decided that “we don't care about [no stinkin'] payload size”, so in the interest of keeping things simple (but possibly redundant), we should stick to triplets.