How to merge XML-Data of two variables of different namespace?

Question

Hi all,
I am facing a problem manipulating XML data in a BPEL process. As I didn't get any response on my question in the BPEL forum, I decided to post it again in this forum. I am not very familiar with using XML up to this moment, so please don't blame me if this turns out to be a stupid question.
I have to combine information coming from 2 different sources (1st delivered by BPEL-client input "FileInfo", 2nd delivered by a ftp-adapter "FileData") for passing it to another service.
So there are 3 XSDs (2 in, 1 out), each with a different namespace. As every structure is composed of several elements, I don't want to copy them one by one. But when copying a whole node including child elements, the target structure yields empty nodes, because the target child elements maintain the source namespace!
Using 2 XSLT's works well for each input, but in combination, the last transformation deletes the information of the first one.
So, the only way to merge the data I figured out by now, is to use a XSLT for each input, transforming it into 2 separate Variables belonging to the same namespace and then copying the complete nodes of the two variables into the target (which of course belongs to the common namespace as well).
Although there is an inconsistent indexing of the namespaces (see example), happily all data can be accessed.
  <CommonData>
    <CommonData xmlns="http://TargetNamespace.com/CommonData">
      <FileInfo xmlns="http://TargetNamespace.com/CommonData">
        <Name>testfile2.txt</Name>
        <Size/>
        <DateReceived>2009-02-10T17:15:46+01:00</DateReceived>
      </FileInfo>
      <FileData xmlns:ns0="http://TargetNamespace.com/CommonData">
        <ns0:KOPF>
          <ns0:Id>1</ns0:Id>
          <ns0:Value>1</ns0:Value>
          <ns0:Text>Hier könnten Ihre Daten stehen -</ns0:Text>
        </ns0:KOPF>
        <ns0:POSI>
          <ns0:Id>1</ns0:Id>
          <ns0:Position>1</ns0:Position>
          <ns0:Value>1</ns0:Value>
          <ns0:Text>eins ----</ns0:Text>
        </ns0:POSI>
        <ns0:POSI>
          <ns0:Id>2</ns0:Id>
          <ns0:Position>2</ns0:Position>
          <ns0:Value>2</ns0:Value>
          <ns0:Text>zwei ----</ns0:Text>
        </ns0:POSI>
      </FileData>
    </CommonData>
  </CommonData>Now for the question:
Is this really the only way to merge variables? As it took 4 operations to achieve this, it seems to be too complicated, and therefore too inperformant to me.
BTW: In real life there would be up to 9999 positions with much more payload (in total up to several MBs) to be processed!
Having full control of the namespaces in this case, I could think of using one namespace for all XSDs too. But would this be a better solution? Is there a golden rule on using namespaces relating to design issues?
Any comments appreciated,
cheers, Marco

Answer 1

Well, if you only want to change namespace (no other changes) I would use a single generic XSL that changes the namespace for any XML document into a given target namespace, keeping the rest. That will require two transformation calls, but only one XSL. I'm afraid I don't have an example available, but if you google perhaps you can find it, I have seen it somewhere.
Normally when you have different namespaces the contents differ as well, though, and what you really want is a merge function. There is a way to pass two documents into a single XSL and that is to use parameters. You pass one source document the normal way and assign the other converted to a string to a paramter. You must use an assign with processXSLT in BPEL, not a transform activity. The processXSLT really takes three arguments and the third contains the parameters. Now to the difficulty - in the transformation you need to change the string into a nodeset (an XML document). In the current XPath version used by the platform there is no nodeSet function, but it is possible to write one in Java. If you have it you can select from both documents while building the third. I don't have an example handy and yes it is a bit messy as well, but much of the work only has to be done once and can be reused in other processes.