Requirements on metamodel keys

[enikao]

Both NamespacedElement.key and Metamodel.key MUST adhere to LIonWeb id format (#31).

NamespacedElement.key MUST be unique within its metamodel.

Metamodel.key SHOULD be globally unique, and MUST be unique within an id-space (#31).
For approximate global uniqueness, we SHOULD adopt Java's package naming scheme, based on domain names.
As we don't allow dots (.) in ids, we SHOULD use dashes (-) instead.
Dashes are preferable to underscores (_) because of better Java compatibility: In Java package names, underscores are allowed, but dashes are not. The same applies to most other programming languages, as they need to separate names from subtract expressions. Thus, we can easily establish similar names for metamodels and packages by substituting dashes with dots.

Example: Given domain subdomain.example.com, metamodel keys might be com-example-subdomain-myDepartment-group123-entity_model (with package name com.example.subdomain.mydepartment.group123.entity_model) and com-example-subdomain-great_ultimate_universal_unified_dataModel (with package name com.example.subdomain.great_ultimate_universal_unified_datamodel).

[enikao]

Does the dashes-policy as described above makes sense?
If yes, shall we change our M3 ids? E.g. LIonCore_M3_Language_dependsOn --> LIonCore-M3-Language-dependsOn?

cc @ftomassetti @dslmeinte

[dslmeinte]

For the actual keys in the M3, I was thinking more along the lines of dependsOn, etc. - at We don't really need to qualify the keys, because the M3 is pretty small.

But I don't get why dashes instead of underscores. A key with underscores is likely immediately Java-friendly, right?

[enikao]

My line of thought for Java-based names:

1. Java has a working approach to (mostly) globally unique names: DNS-based package names
2. Java separates subpackages (and other names) by dot
3. Java does allow underscores in names, but does not allow dashes in names ^1
4. LIonWeb does allow underscores in ids, but does not allow dots
5. We can establish an unambiguous, bidirectional, one-to-one mapping between Java names and LIonWeb ids by swapping Java dots with LIonWeb dashes

If we swapped Java dots with LIonWeb underscores, the mapping becomes ambiguous: Java package name com.example.sub_package --> LIonWeb id com_example_sub_package --> mapping back to Java package name com.example.sub.package

^1: Dashes in (package) names would be ambiguous with subtract operation if using full qualified names: com.example.MyClass.CONST1-com.example.OtherClass.CONST2

[dslmeinte]

OK, so dashes are in addition to underscores, with the explicit purpose to have an effective equivalence Java FQ-names ⇆ keys? That sounds good.

[enikao]

So the M3 ids would be like

M3 element	Concept	Key
LIonCore	Language	LIonCore-M3
Language	Concept	Language
Language.dependsOn	Reference	Language-dependsOn
Concept	Concept	Concept
Concept.abstract	Property	Concept-abstract
Link.type	Reference	Link-type
Property.type	Reference	Property-type

I'd prefer Language-dependsOn over dependsOn. The latter would still be unique within LIonCore, but for type we'd include the owning concept -- and then I would keep it consistent for all elements.

[enikao]

Agreed in meeting on 2023-06-09

[enikao]

For reference: The agreed ids and keys are listed in metamodel docs