Skip to content

How to represent annotations in serialization #150

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

Closed
enikao opened this issue Jul 27, 2023 · 0 comments
Closed

How to represent annotations in serialization #150

enikao opened this issue Jul 27, 2023 · 0 comments

Comments

@enikao
Copy link
Contributor

enikao commented Jul 27, 2023

Assuming we include annotations (#13), how to represent them in serialization format (#37)?

Aspects:

Alternative A: Regular containment

Change built-in uber-Concept Node to have a containment annotations: IAnnotation [0..*] that's inherited by every concept.

Same as MPS' BaseConcept.smodelAttribute

Pro:

  • No special constructs needed
  • Parent is inherently clear

Con:

  • Need to treat this containment special in some contexts

Alternative B: Special list

In serialization, a Node currently has these lists:

  • properties
  • containments
  • references

We could add another list annotations.

Pro:

  • Clear separation of regular model contents and annotations

Con:

  • The parent of an annotation would still be the annotated node. But then parent is not always the inverse of containment any more.

Alternative C: Adjacent model

(Discussed in #13, alternative G)

Decision: Alternative B: Special list

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

1 participant