XML namespace for JAXB not correctly set

[pieterbos]

Fixing this issue will open a whole can of worms.

Each package being mapped to XML should contain a package-info.java, which defines the XML namespace. That is currently not the case in archie.

that is not a huge problem, because XML is being parsed, regardless of set namespace, although the generated XML is potentially problematic.

However, if we want to set the namespace, we enter a place with tons of issues:

• RMQueryContext xpath expressions suddenly become namespaced!

• JAXB adds a namespace prefix when you set the elementFormDefault to Qualified, as it should be for OpenEHR

• when set to qualified, JAXB only does xmlns="" when a single namespace is used

• when set to unqualified, jaxb does not parse xmlns="http://schemas.openehr.org/v1"

• JAXB detects the namespace with URI "", for any Map it might encounter

• apparently we have some maps left in the AOM

  • ResourceDescriptionItem is accidentally used in XmlResourceDescription, in annotation
  • LanguageSection has a couple of maps and needs an adapter
  • archetype.otherMetaData
  • operationalTemplate.terminologyExtracts
  • operationalTemplate.componentTerminologies
  • probably more. To find: set a breakpoint in com.sun.xml.bind.v2.runtime.NameBuilder::createName, condition nsUri == null || nsUri.equalsIgnoreCase("")

• XML with a namespace will no longer parse

  • parsing without namespaces is very possible, using a XmlReader that is not namespace aware, but requires client code updating

Encountered because I wanted to use the regular XML parser for OPT default values - which did not work without elaborate tricks.

[pieterbos]

Note that this also means parsing both the new upcoming http://schemas.openehr.org/v2 and the old v1 to the same model will be really difficult

[pieterbos]

@J3173 I spoke with the people from EHRBase, and they say it's not a problem to change. They already remove namespace from XML documents, they can change it to apply http://schemas.openehr.org/v1 instead. In fact, such a filter + surrounding parsing utility class could be useful for archie, and would ease migration!

[subigre]

Hi @pieterbos, we have an issue reported in EHRbase repo regarding this topic and I am wondering if and when PR #344 will be merged?

[pieterbos]

Hi @subigre . I have separated the pull request in two parts:

• Xml aom fixes #371 solves the problems in the AOM XML serialization other than the namespace. It does not change the XML binding for the RM.
• https://github.com/openEHR/archie/pull/344/files contains the namespace

I hope to be able to merge the first one next Wednesday or soon after that, after a review from a coworker. We hope to do a new major release soon, with all the fixes and changes in the master branch.

The second one is what you ask for. That is a bit trickier - it has three things that need fixing:

• the XPATH-base path lookup implementation through the RM has issues
• the XML generated by Archie after this change cannot be parsed by old versions of Archie, and the other way around
• it binds to version v1 of the namespace rather than v2, and even though both will parse fine with the same model, the namespace will prevent compatibility.

The first issue will need to be fixed before merging
The second issue, we could decide not being important, I will check internally as wel
The third issue probably requires a preprocessor that replaces the v1 namespace with v2 before parsing XML, which could also solve the second issue

I do not have time to do this right away, we hope to have some time in a couple of weeks, but not certain. If you need this ASAP, perhaps you could apply the fix to a fork and work from there until we have time to fix the issue. Or alternatively, you could create a fix for these issues and make a pull request with it.