There are implicit rules in play when mapping from XML namespaces to Java packages. This can be set by a bindings-file. In some cases it is most cumbersome.
Apparently, a rule like "let us assume that if targetNamespace has a dot in the end then what comes after must be 'xsd' and hence harmless to remove!". I suspect this is a 10 year old JAXB-convention. The effect leads to trouble.
targetNamespace="urn:iso:std:iso:20022:tech:xsd:pain.001.001.02">
When run through xjc, this per default gets mapped to -
urn.iso.std.iso._20022.tech.xsd.pain_001_001
Here the last path-number "02" is gone: I would have liked the default mapping to be a strict conversion -
urn.iso.std.iso._20022.tech.xsd.pain_001_001_02
Mapping each individual file name for XSD to circumvent a generic mapping rule is really tough work. It also creates strong couplings in the overall setup and which have to be maintained -- instead of having the mappings applied and work "per construction".
How about changing this built-in default mapping? Like, say, only delete the rest if it contains letters and hence matches [.][a-zA-Z], something without numbers in it? This should be compatible with most uses.
In addition to changing the default rule, how about adding an xjc-option to express "please do not make any implicit mappings cutting information off"?
When I look at the reference implementation -- very briefly --, I find a number of occurrences of String#lastIndexOf('.') being applied in a blind manner somewhat like this:
HOW ABOUT considering a change of some of these code lines to a better approach and have the code actually look at what is behind the dots? --If, say, the last dot in a XML namespace is followed by digits and not only letters, then do not mutilate this name when mapping to Java package names -- and change the specification accordingly -- ?
How about a provider-interface in Java to control this? Does it exist already?
What is going on up until now begs for improvement and control. The current state significantly increases complexity.
