Explicit extension namespaces

[nikku]

Context

This PR fixes a long standing issue that prevents general usability of moddle for advanced use-cases, i.e. UML parsing: We handle extension provided properties in a magic fashion, and polute the local namespace with them. All under the assuption that names declared across packages do not ever overlap (which can only hold true accidentally). In case of overlap we blow up (#36).

UML specifically defines two packages UML and UMLDI, and both declare a property ownedElement:

(Image from #36).

The Solution

This PR makes extension namespaces explicit, offering a more predicatable moddle behavior, and enabling use-cases such as #36 in the first place:

• Remove magic access to non-namespaced names for extension properties:

  // before, now disallowed
  const element = moddle.create('bpmn:ServiceTask', {
    topic: 'FOOBAR'
  });
  
  element.topic; // 'FOOBAR'
  
  // correct usage
  const element = moddle.create('bpmn:ServiceTask', {
    'camunda:topic': 'FOOBAR'
  });
  
  element['camunda:topic']; // 'FOOBAR'

• As a result you may define properties with name clashes in a safe manner:

  const diagramElement = moddle.create('umldi:DiagramElement', {
    ownedElement: [ ... ],
    'uml:ownedElement': [ ... ]
  });

Regarding the UML Case

For ease of use in moddle users must clearly separate local from extension properties. Inheritance must still be conflict free, meaning that the stock UML case ⬆️ is still not suppported out of the box. However you could argue that introducing such conflicts in the first place is bad language design. We have no urge to support such.

Given this PR you can however solve the situation through a virtual glue package (8a65475). That glue package does what UML should have done in the first place, clearly defining ownership (core domain - UMLDI) and extension (UML):

---

As indicated earlier this is a major breaking change: Where extension properties have been mapped via their local names in the past, they now must be mapped explicitly.

When considering the core bpmn.io domain this results in minor adjustments (f058e3a, bpmn-io/moddle-xml#68, bpmn-io/bpmn-moddle#97). When we considering the extension domain, this results in major changes (camunda/camunda-bpmn-moddle#122, camunda/zeebe-bpmn-moddle#40).

---

Migration

To aid migration migration to this new major version (and guide our users through stricter usage requirements) I suggest a strict mode and explicit logging of miss-use (#48).

[marstamm]

This issue is also preventing us to create a generic bpmn-linter that support both camunda: and zeebe: diagrams without configuration. Cf. camunda/camunda-modeler#3853 (comment) .

I verified this is the same issue with a test-case on https://github.com/bpmn-io/moddle/tree/test-allow-overlapping-types