I have a dmn model and want to query for inputData elements using the tools from camunda-dmn-model.
But instead of InputDataImpl instances I receive InputDataReferenceImp instances. After some debugging, I suspect the problem is InputDataReferenceImpl and InputDataImpl are registered on the same typeName and in that order. When I change the order in org.camunda.bpm.model.dmn.Dmn.doRegisterTypes(ModelBuilder) everything works fine.
I can easily create a pull request to fix this, but I’d like to have a deeper understanding of what is going on. Why are these elements both registered on the same typeName? What is a InputDataReference anyway? Did I just stumble on some previously unneeded code?
thank you for reaching this out. I can reproduce the issue. It’s a bug in the DMN model module (i.e. the underlying XML model module). The problem is that both elements are registered for the same name and the model API can’t handle this.
The solution is not to delete InputDataReference because it’s part of the specification (see the XSD). Instead, we should fix the model API so that it can handle duplicated names.
I took a look at this particular issue. I’ve submitted a pull request #6 to the camunda-xml-model repository, which contains a very simple optimization of skipping a lookup to the main map of types when querying elements by a type, as the type is already known and available when doing so. This in turn also has a side effect of fixing the specific issue outlined in this post as the correct ModelElementType is loaded from the start.
It however does not fix the underlying issue of handling elements which have the same name. I’ve submitted a separate pull request #7 to the camunda-xml-model repo that addresses this, as well as another pull request #5 to the camunda-dmn-model repo which implements the changes from the previous pull request.
The idea is that since the model XML is validated from the schema it’s type information is present when parsed. Since the name of the classes representing the elements are loosely related to it’s schema type (and it doesn’t happen often), we could use that to figure out which class to use. This would be needed when trying to query for elements with something else than it’s type. The pull request change is minimal, shouldn’t break anything and would only come into effect if used by any downstream projects (like dmn-model).
Please have a look if this would be a valid strategy.