How to refer from one language to another?

[enikao]

In #80, we decided that references within one language use the id of the target, as the language elements are "just nodes".
We use key only if we cross M1 -> M2 boundaries (or M2 -> M3, respectively).

Example

In Repo alpha, we have:

Language Trees [id: 100, key: asdf]
  version: 1

concept Tree [id: 1, key: A]
  property height: integer [id: 2, key: B]

concept Pine extends Tree [id: 3, key: C]
  property needleLength: integer [id: 4, key: D]

"Pine extends Tree" is stored as:

{
  "reference": {
    "language": "LIonCore-M3",
    "version": "1",
    "key": "concept-extends"
  },
  "targets": [
    {
      "resolveInfo": "Tree",
      "reference": "1"
    }  
  ]
}

Now assume we have a second language:

Language Bonsais [id: 200, key: jkl]
  dependsOn: Trees@v1
  version: 1

concept Bonsai extends Tree [id: 8, key: A]
  property maxHeight: integer [id: 9, key: B]
  reference similarTo: 1..* Pine [id: 10, key: C]

"Bonsai extends Tree" is stored as:

{
  "reference": {
    "language": "LIonCore-M3",
    "version": "1",
    "key": "concept-extends"
  },
  "targets": [
    {
      "resolveInfo": "Tree",
      "reference": "1"
    }  
  ]
}

"reference similarTo: Pine" is stored as:

{
  "reference": {
    "language": "LIonCore-M3",
    "version": "1",
    "key": "link-type"
  },
  "targets": [
    {
      "resolveInfo": "Pine",
      "reference": "3"
    }  
  ]
}

Assume we exported Language Bonsais and Trees from repo alpha.

Now we import Trees into repo beta, which uses hash-based ids:

Language Trees [id: 599906, key: asdf]
  version: 1

concept Tree [id: e8b1b9, key: A]
  property height: integer [id: 3ea6ea, key: B]

concept Pine extends Tree [id: b6ab16, key: C]
  property needleLength: integer [id: 45aae5, key: D]

Now "Pine extends Tree" is stored as:

{
  "reference": {
    "language": "LIonCore-M3",
    "version": "1",
    "key": "concept-extends"
  },
  "targets": [
    {
      "resolveInfo": "Tree",
      "reference": "e8b1b9"
    }  
  ]
}

A bit later we want to import Bonsais into repo beta.
beta can find neither "Bonsai extends Tree" nor "reference similarTo: Pine" target, thus it stores

"Bonsai extends Tree" as:

{
  "reference": {
    "language": "LIonCore-M3",
    "version": "1",
    "key": "concept-extends"
  },
  "targets": [
    {
      "resolveInfo": "Tree",
      "reference": null
    }  
  ]
}

and "reference similarTo: Pine" as:

{
  "reference": {
    "language": "LIonCore-M3",
    "version": "1",
    "key": "link-type"
  },
  "targets": [
    {
      "resolveInfo": "Pine",
      "reference": null
    }  
  ]
}

Do we accept this?

[enikao]

Options

Option A: Whenever we point to metamodel elements, we use their key

Pro:

• Stable

Con:

• cannot treat a metamodel as "just a model"
  → Breaks “everything is a model” (Principle: "everything is a model" / "everything is a node" #144) principle of LIonWeb

Option B: Keep as is (model → metamodel uses key, metamodel → metamodel uses id)

Pro:

• Everything is a model

Con:

• Incremental language import might be broken

Option C: enforce id == key

Pro:

• Solves import case

Con:

• Cannot handle two copies of the same metamodel in same repo

Considerations

• The use case of incremental importing metamodels is not that uncommon. Example: A client lazily loads required languages. It needs to relate already loaded metamodels and their instances with newly loaded ones.
• We must be able to ship metamodels to client

Decision: Option B (keep as is)

Rationale: "Everything is a model" is a cornerstone of LIonWeb. We don't want to violate this principle at our core.

Consequence: Incremental language import needs to keep a mapping table around