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.
Description:
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.
-->
#1
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.
#2
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.
#3
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.
#4
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.