how to maintain namespace prefixes when using evaluate xpath assertion with add or remove XML element assertion

[Lepird]

Hi,

 

I was trying to concatenate 2 XMLs using the evaluate xpath assertion and add and remove element assertion but I was having an issue with name spaces not resolving. example below

 

lets say i get the below XML from the caller

 

<x:root xmlns:x="http://test.com/text">

     <x:child>

          <x:grandChild>

               000

          </x:grandChild>

     </x:child>

</x:root>

 

with the below XML saved server side

 

<y:root xmlns:y="http://test.com/text">

     <y:child1>

          111

     </y:child1>

</y:root>

 

and i need to produce the below XML before sending to back end.

 

<y:root xmlns:y="http://test.com/text">

     <y:child1>

       222

     </y:child1>

     <y:child>

          <y:grandChild>

               111

          </y:grandChild>

     </y:child>

</y:root>

 

the issue I'm facing is that the xPath is maintaining the same prefix even though it is referencing the same name space so the resulting XML is invalid as below

 

<y:root xmlns:y="http://test.com/text">

     <y:child1>

       222

     </y:child1>

     <x:child>

          <x:grandChild>

               111

          </x:grandChild>

     </x:child>

</y:root>

 

thanks in advance ( I have attached a sample policy for what I'm trying to do)

Attachment(s)

XML_Concat_test.xml.zip   1005 B 1 version

[Anon Anon]

The Apply XSL Transformation assertion would be a more appropriate tool for merging two documents. The Add or Remove XML Element assertion is essentially a glorified copy-and-paste solution and will not accomplish the required goal. There are a lot of examples of XSL transformation being used for document merging throughout the web. Some examples to look at might be:

 

https://stackoverflow.com/questions/15194718/how-to-merge-two-xml-files-with-xslt

https://stackoverflow.com/questions/19021205/merging-two-xml-files-using-xslt

[Lepird]

Hi Eric,

 

Thanks for the reply yes it seems that XSLT is the way to go though i have done some extra investigation and it seems the issue is with the apply xpath assertion specifically the .elements example below

 

using this XML

 

<x:root xmlns:x="http://test.com/text">

     <x:child>

          <x:grandChild>

               000

          </x:grandChild>

     </x:child>

</x:root>

 

with xpath "/x:root/x:child"

 

the .elements produces

<x:child>

       <x:grandChild>

            222

       </x:grandChild>

</x:child>

 

while the .element produces

 

<x:child xmlns:x="http://test.com/text">

       <x:grandChild>

            222

       </x:grandChild>

</x:child>

 

given this behavior this seems to me as a bug in the .elements out put of the xpath. Any thoughts ? 

[Anon Anon]

I think that it is a less of a defect and more of an undocumented behavior. There are certainly valid reasons why you'd want the ".element" variable to retain its namespace. Suppose you were trying to extract only a specific component of a message to transmit? If the XPath assertion does not capture and add the namespace then it has to be manually captured and readded (which is computationally expensive to re-perform). The assertion is just doing what it thinks makes the most sense: It is taking an element and all child elements out and treating it as a separate XML message which may require a namespace. I'll drop a comment on the documentation for this assertion to see if this can be cleared up in the documentation to explain the observed behavior.

[Lepird]

Hi Eric,

 

Thanks for the reply,I do agree that the expected behavior is to retain the name space but what seems as an issue is why the .elements does not behave the same forcing us to have an XSLT transformation. especially since in the documentation of the "add or remove XML element(s)" indicates that it is not compatible with the .element variable

[Anon Anon]

Let me see if I can cut to the meat of the issue: What can I do to help you with this request?

 

I cannot state one way or another as to why the decision was made to do that. I speculated in the above comment as to why they might be different but that is not a definitive answer. I do not believe that it is a defect and more that it is an undocumented difference in behavior between the two context variables. If you'd like the product to be changed to accommodate for this then you will need to open an Idea on the community for the product management team to review. I have posted a comment in the applicable documentation and asked documentation to clarify the difference between the two variables.