tpolaske opened a new issue, #3594:
URL: https://github.com/apache/incubator-kie-tools/issues/3594
## Summary
`@kie-tools/dmn-editor-standalone` strips the **text content** of unknown
vendor extension elements during its parse/serialize round-trip. Today there is
no public API for consumers to register custom extensions so the editor
preserves them. We'd like an equivalent of bpmn-js's `moddleExtensions`
mechanism on the standalone DMN editor.
## Reproduction
Given a DMN file containing a custom vendor extension under
`<dmn:extensionElements>`:
**Before opening + saving in the editor:**
```xml
<dmn:extensionElements>
<x-vendor:visibility
xmlns:x-vendor="https://example.com/vendor/1.0";>PROTECTED</x-vendor:visibility>
</dmn:extensionElements>
```
**After a no-op open + Save round-trip:**
```xml
<dmn:extensionElements>
<x-vendor:visibility xmlns:x-vendor="https://example.com/vendor/1.0"; />
</dmn:extensionElements>
```
The element itself survives. The **text content is silently dropped.**
Tested against `@kie-tools/[email protected]`.
## Why it matters
We use the standalone DMN editor in a product where a custom extension
element carries access-control state for a decision model. Silent loss of that
value on every Save is a security-relevant data loss. We're forced to wrap the
editor with a host-side re-injection layer that pulls the original element
bytes from the previously saved DMN and patches them back into the editor's
output before persisting. This works, but it's fragile, scoped per extension,
and not something every consumer of the editor should have to re-invent.
## Why we can't fix it in our app
- The DMN spec ([DMN11-155](https://issues.omg.org/issues/DMN11-155),
ยง6.3.14) *permits* implementations to drop unknown vendor extension text on
round-trip โ so we accept this is spec-conformant, not a defect.
- The standalone editor's public API has no hook to register custom
moddle/extension descriptors. We can't import internals (and shouldn't have to).
- Patching the bundled editor is not viable as a long-term strategy.
## Proposed solution
Add a public option on the standalone editor (and the underlying `DmnEditor`
boxed-context) for consumers to register custom vendor namespaces / extension
descriptors, analogous to bpmn-js's `moddleExtensions`:
```js
DmnEditor.open({
container,
initialContent,
moddleExtensions: {
'x-vendor': {
name: 'Vendor',
uri: 'https://example.com/vendor/1.0',
prefix: 'x-vendor',
types: [
{ name: 'Visibility', superClass: ['Element'], properties: [...] }
]
}
}
});
```
When a registered descriptor matches an element in the input DMN, the editor
would preserve its full content (attributes + text + child nodes) across the
parse โ render โ serialize cycle.
If a more lightweight passthrough mechanism is preferable (e.g. a "preserve
unknown extensions verbatim" boolean), that would also meet the need.
## Workaround we're using today
Host-side wrapper around the editor's `getDmnContent` API that diffs the
editor's output against the original DMN bytes and re-injects any stripped text
content of registered extension elements before persisting. Functional but
fragile across editor upgrades.
## Related
- bpmn-js prior art:
https://github.com/bpmn-io/bpmn-js/tree/master/docs/#extension-points
(`moddleExtensions`)
- OMG DMN spec: https://issues.omg.org/issues/DMN11-155
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
