Meeting minutes Aachen 2022-09-27

[enikao]

LiOnWeb

Present: @markusvoelter @ftomassetti @nkoester @enikao

Risks

• Too ambitious: Run out of steam before getting somewhere
• One member dominating because of available work effort
  • But: Not everybody needs to contribute equally

Approach

• do one milestone approx. Mid-January
• one party can provide max. one contribution per milestone
• bi-weekly meetings to get things going (!)

Contributions to milestone 1

• List of use cases @TBD
• Meta-meta model: Strumenta @ftomassetti
  • APIs:
    • rather conservative: Java (JVM)
    • Typescript
• Repository API: itemis @markusvoelter + @slisson
  • bulk API
  • open questions to discuss
    • authentication?
    • authorization?
    • version control?
    • bonus: collaboration
• Service API: @sergej-koscejev?
  • might not be suitable for editors (it might though)
  • describe changes

Organization

• Need general secretary
  • See if person emerges

Use cases

TBD
TODO: Define at least 3 use cases

Misc

• To think about: Scientific involvement (don't do things that are known not to work in scientific community)
• @enikao will have a look into SysML2 repository server (mentioned in Aachen)

[enikao]

SysML2 Repo Server API is described in https://raw.githubusercontent.com/Systems-Modeling/SysML-v2-Release/master/doc/3-Systems_Modeling_API_and_Services.pdf
Nothing unexpected, worth a look for completeness

[enikao]

One interesting idea there: They define explicit APIs for converting between textual and model representation.

[dslmeinte]

Interesting! I think we have to consider why you'd want a textual representation of an AST-first model. I'm guessing that that (perceived) need often comes from needing to integrate with text-centric tools, e.g. for diffing and versioning. Can we then also add to the use cases/architectural components/whatever-we-want-to-call-it the capability to diff two (versions of) models?

[dslmeinte]

Sorry I couldn't attend this meeting Tuesday evening: I had to go back for private matters.

Good minutes! I'm not certain what kind of use cases (scope, generality, size, etc.) we're aiming for.

Did you already plan the next bi-weekly meeting?

[enikao]

I'm not certain what kind of use cases (scope, generality, size, etc.) we're aiming for.

To my understanding, we want to have a few concrete use cases to guide the idea.
Adapting IEEE's approach "Rough consensus and running code", I'd think we're looking into use cases that are small enough to be feasible, but real in the sense that we either work on them^1 or could implement them as demos.

^1 "work on them" could mean non-public commercial project; then the use case would abstract from the specifics, but benefit from real-world experience.

Did you already plan the next bi-weekly meeting?

Not yet.

[dslmeinte]

Ha, I bought that article, and found out that it can be summarized in a couple of sentences ;) Luckily, it's a company expense.

So, for “use cases” we read: “descriptions of MVPs we could build in a proverbial rainy Sunday afternoon”?

[ftomassetti]

From my point of view, it would be useful to have a ~3 lines description of 2-4 use cases.

For example, when writing the draft of the Meta-Metamodel proposal, I am considering that we may want to use it to support:

1. Projectional editors running on the web (similar to the ones presented in your book or ProjectIt). These would be written in Typescript
2. Parsers for textual languages such as Java or RPG. These would be written in Kotlin

My first concern is to miss some use cases and end up not supporting them. My second concern is that we may have different ideas about the use cases we want to support and therefore make different assumptions in the different parts of the system.

From my point of view, I think we can do with fairly short descriptions of use cases, as far as we are all familiar with that kind of use case.

[dslmeinte]

In my experience, you go from use case to requirements. Your (@ftomassetti) list looks like they are already requirements, right?

[ftomassetti]

I tend to confuse the two, but I guess that we may look at this from two different points of view: the one of the final user and the one of the language engineering consultant tasked to implement a certain kind of solution.

In this case, I was putting myself in the shoes of the language engineering consultant who knows already he has to implement a specific component, not determining which kind of components it needs to be built, as this was already decided either by the client or during some analysis phase.

[dslmeinte]

Ah, OK, now I'm starting to understand you, I think.

Maybe we can think of “required architectural components” rather than “use cases”?