Negative Coordinates forbidden in Diagram Interchange

[falko]

Describe the Bug

The Camunda Modeler allows negative coordinates in BPMN, CMMN and DMN diagram interchange.

All three specifications explicitly require positive coordinates only (see quotes at the and of the report). This breaks model interchange with several BPMN tools and is reported as a broken model by others.

In addition, this behaviour frequently causes usability problems for Camunda users with models being either hidden completely or only partially visible when opened in Camunda Modeler even though enough screen space would be available.

This has been uncovered during dry-runs for the next demo of the BPMN Model Interchange Working Group at the OMG.

Steps to Reproduce

Steps to reproduce the behavior:

1. Create a new BPMN, CMMN or DMN diagram
2. Move an element to the left or on top of the 0,0 point indicated by the grey cross in the upper left corner.

Expected Behavior

When BPMN XML is exported, all DI coordinates are positive.

Environment

• OS: Linux
• Camunda Modeler Version: 2.1.0-nightly of today

Specification Quotes

BPMN 2.0.2 page 371 (PDF 401):

BPMNPlane element is always owned by a BPMNDiagram and represents the root diagram element of that diagram. The plane represents a 2 dimensional surface with an origin at (0, 0) along the x and y axes with increasing coordinates to the right and bottom. Only positive coordinates are allowed for diagram elements that are nested in a BPMNPlane. This means that the union of all the nested elements’ bounds is deemed to be located at the plane’s origin point.

BPMN 2.0.2 page 372 (PDF 402):

The bounds of a BPMNShape are always relative to that plane’s origin point and are REQUIRED to be positive coordinates.

BPMN 2.0.2 page 375 (PDF 405):

The waypoints of BPMNEdge are always relative to that plane’s origin point and are REQUIRED to be positive coordinates.

CMMN 1.1 page 85 (PDF 103):

Only positive coordinates are allowed for diagram elements that are nested in a CMMNDiagram.

DMN 1.2 page 97 (PDF 97):

Only positive coordinates are allowed for diagram elements that are nested in a DMNDiagram.

[falko]

Would this be easy to do in a pull request or plugin?

[philippfromme]

The diagram-js Canvas currently is endless. We'd have to restrict the coordinates in bpmn-js which would include restricting navigation and element coordinates. This would probably be a seperate behavior and therefore a module that could be provided as a plugin. I wouldn't necessarily say it's easy, though.

[falko]

The UI does not have to change and the canvas can stay endless. The question is: can one add a normalization step at point when XML is generated/exported/saved?

[philippfromme]

Well, that would be as easy as moving all elements to the origin which is already possible.

[falko]

Great, then that should be invoked automatically before each XML export. Ideally only if elements have negative coordinates.

[volkergersabeck]

Having elements with negative coordinates breaks the import to Signavio in a way that the layout and labels are completely chaotic in Signavio in a way that it is impossible to recover from that. This was observed by @benhoffmann and myself during a PoC last week.

[nikku]

It makes sense to address this one along with https://github.com/camunda/camunda-modeler/issues/1096.

I've pulled in this issue into the scope of v3.0.0 accordingly. We'll investigate if this is an easy pick :crossed_fingers:.

[nikku]

Just to be sure that we all understand the consequences of automatic 0,0 alignment:

This has a high likelyhood to change all element coordinates with every save. That means the resulting BPMN 2.0 changes are becoming super hard to diff.

[benhoffmann]

The good news: diffing the DI is as far as I can think not that important in contrast to diffing the actual process. Also, the model should not change every time as long as I keep my elements somewhere close to positive coordinates, right?

[nikku]

Also, the model should not change every time as long as I keep my elements somewhere close to positive coordinates, right?

The general question is, what should trigger the alignment and my gut feeling is: We should trigger it whenever the diagram box is not at (0,0) (or some other chosen coordinate such as (50,50)).

Scenario 1

Scenario 2

Scenario 3

(The only scenario where no change would happen, as elements are already aligned to (50,50).)

[falko]

We must realign when coordinates become negative. Always realigning to a fixed point feels almost a little too much for me. But my observation is that most BPMN tools do realign to 0,0.

It is just our usability issue that we fly our palette over that high-frequented area instead of having it outside the canvas or in a less frequented area of the canvas. But that almost deserves a separate issue for further UX research. A possible solution there could also be to not render 0,0 on the upper left corner of the window but instead further to the right so that the palette flies over negative territory. This would also make the 'Move Elements to Origin' less problematic.

Graphical changes are not really mergeable anyway. So if the DI changes more frequently during graphical chances, it doesn't break anything now when we are using line based diff & merge with Git. However, it could make future MM-based diffs and merges harder.

[nikku]

Thanks for your feedback guys.

[nikku]

Will be available in the next nightly.

Try it out and give us feedback @falko @benhoffmann.

[falko]

In order to limit the effect of this, could we also update the default template for new files to place the start event at x="140" y="188". Why that position? The x coordinate allows a start event with a maximally wide label to be visible when a model is opened and the palette uses two columns. The y coordinate allows using a standard-size embedded sub-process behind the start event without triggering the behavior implemented for this issue.

In fact the x="140" should be the destination to move to, because otherwhise the two-column palette on small screens covers the start event or its label.

Furthermore, I think the 'Move to origin' should be aligned with this, because otherwise users that used 'Move to origin' will have a hard time moving their diagrams to a position where its start event is not hidden behind the palette when they open the file. Basically, their only chance would be to use the space tool or create new elements in negative areas, to trigger the behavior implemented for this issue.

[nikku]

Moved your proposed improvements to https://github.com/camunda/camunda-modeler/issues/1183.

Thanks for reporting.