Reputation: 11
I'm required to produce a schema that will generate XML outputs that has 3 different namespaces, but there should not be any prefixes used to reference the elements or namespace. More specifically, it's ISO20022 SWIFT message to be used with SWIFT Alliance Access (SAA). Below is an example. How can I achieve this output?
<Data xmlns="namespace1">
--elements--
<Body>
<Header xmlns="namespace2">
--elements--
</Header>
<Doc xmlns="namespace3">
--elements--
</Doc>
</Body>
</Data>
I have tried creating the schema through xs:import
where Header
and Doc
are separate XSDs. The closest I managed to get to was the output below, where the elements under Doc
includes n0
prefixes. Note that I'm using the schema with an application called Mapforce and the n0
prefix was automatically assigned.
<Data xmlns="namespace1">
--elements--
<Body>
<Header xmlns="namespace2">
--elements--
</Header>
<Doc xmlns="namespace3">
<n0:--elements-->
</Doc>
</Body>
</Data>
Upvotes: 1
Views: 107
Reputation: 111491
<Data xmlns="namespace1">
--elements--
<Body>
<Header xmlns="namespace2">
--elements--
</Header>
<Doc xmlns="namespace3">
--elements--
</Doc>
</Body>
</Data>
<ns1:Data xmlns:ns1="namespace1">
--elements--
<ns1:Body>
<ns2:Header xmlns:ns2="namespace2">
--elements--
</ns2:Header>
<ns3:Doc xmlns:ns3="namespace3">
--elements--
</ns3:Doc>
</Body>
</Data>
XML 1 vs XML 2 cannot be controlled at the XSD level.
XML 1 and XML 2 are fully equivalent. No conformant XML application will treat them any differently. If you have an application that requires one over the other, then it's broken. Fix it. Do not perpetuate the problem by catering to it.
If you say it's out of your control, then curse the responsible party and prepare to battle application-specific serialization configuration at best or revert to text-level (not XML-level) tools at worst to achieve your ill-guided goal.
Upvotes: 2