Validation problem for extensions in version 2.3

Submitted by Joerg Freudenstein on Tuesday, 17 February, 2015 - 11:44
Issue ID
Bug report


Short form:
Messages with a Level-B extension will not validate against the original 2.3 model, if they extend an object that is already extended in 2.3 (for example Linaer, GenericPublication).

Not sure if this is also a methodology issue.

In DATEX II version 2.3, the A-Model is extended by default (for example with OpenLR). All instances created by extended clients should be able to be validated against the A model.
This is a problem now, when extending the same object twice (for example exending the Linear object with LinearByCoordinates). This second extension cannot be properly mapped to an 'any'-statement in the default Level A model. The reason is the usage of namespace ##other instead of ##any, which is forced by some other constrictions.

Jonas Jäderberg is working on this topic; there is no simple solution available so far.






Found Version
{"changeLogs":[{"date":1528368298072,"componentOLD":"- Select a value -","component":"Methodology","categoryOLD":"- Select a value -","category":"Bug report","priorityOLD":"- None -","priority":"Critical","assignedOLD":"","assigned":"Josef Kaltwasser (18)","statusOLD":"- None -","status":"Fixed"},{"date":1537268179704}]}

Posted by Josef Kaltwasser on April 25, 2023 Permalink

At a first glance this seems to be indeed a bug. Processing instances from a Level B extended model in a client that has been implemented against another Level B extension can cause problems if both extensions extend the same Level A class. This situation has been very rare in the past but will become frequent now with version 2.3 since this version includes a set of "approved Level B" extensions that already extend a couple of those classes that are popular to extend.

Posted by jaderberg on April 25, 2023 Permalink

Yes, this is not a bug in tool etc. It's real critical issue, I think. I have so for not found any solution. It wouldn't be an issue if 2.3 would include only Level A.
One approach would be to create two models. One 2.3 version with only level A and one 2.3 version including approved extensions. Then all extended level B models would validate against the 2.3 version with only level A.

Posted by Josef Kaltwasser on April 25, 2023 Permalink

Extracting the approved extensions would mitigate the problem on the 2.x branch since it would turn the problem back from likely to rare. For 3.0 we must consider to really solve the issue. One option could be extension specific sub-namepsaces. Then the "##other" would work.

Posted by Josef Kaltwasser on July 25, 2020 Permalink

The issue is resolved in v3.0 by introducing namespaces, with a separate namespace or extensions. The suggestion to mitigate the problem on the v2.x branch in #3 holds, so I close the issue.