#!/usr/bin/perl

use strict;
use warnings;

use File::Find::Rule;
use XML::LibXML;

# get a list of target files
my $input_folder = 'input'; # whatever
my @files = File::Find::Rule->file->in( $input_folder );

# initiate XML parser
my $parser = XML::LibXML->new;
$parser->expand_entities( 0 ); # leave entities alone

# go through target files, collecting elements of interest
my @wanted;

foreach my $file ( @files ) {

    # parse XML
    my $dom = $parser->parse_file( $file ); # input

    # select and store all top level elements
    push @wanted, $dom->documentElement->findnodes( './*' ); 
}

# make a new document
my $new = XML::LibXML::Document->new( '1.0', 'UTF-8' );

# add root element
my $root = XML::LibXML::Element->new( 'xml' );
$new->addChild( $root );

# add the inner elements we've collected
$root->addChild( $_ ) for @wanted;

# output
print $new->toString; 
[download]

Thank you un-chomp, that looks exactly like what I was looking for.

---

Perl 6 in German

XML::LibXML::Document has a toString() method that converts the parsed DOM into a string, including all the child nodes. It has an optional format parameter, which, when set to zero "...the document is dumped as it was originally parsed".

Depending on how lazy / strict you're feeling you could either:

• just serialize each document into a string and use (anchored) regexes to strip off the document root
• use the documentElement() method to get the root of each document, then loop through its childNodes array, and individually toString() each of those

I'd be surprised if there isn't an XML::Twig equivalent to that - I'm just personally much more familiar XML::LibXML - hope that helps.

Thank you john_oshea. Probably there is such a method in XML::Twig, but knowing another module that does the job is fine for me as well.

---

Perl 6 in German

The method you are looking for is xml_string, which is also aliased as innerXML.

#!/usr/bin/perl

use strict;
use warnings;

use XML::Twig;

print "<foo>";
foreach my $file ( ' to_concat_1.xml', 'to_concat_2.xml')
  { print XML::Twig->new( keep_spaces =>1, comments => 'process')->par
+sefile( $file)->root->xml_string; }
print "</foo>\n";
[download]

Note that the comments => 'process' is used only because you have comments just before the end of the foo element in your example, it is probably not needed in your real code.

Also a more generic way would be to keep the first document, and then to add the other ones at the end, removing their root:

#!/usr/bin/perl

use strict;
use warnings;

use XML::Twig;

my $result_twig;

foreach my $file ( ' to_concat_1.xml', 'to_concat_2.xml')
  { my $current_twig= XML::Twig->new( comments => 'process')->parsefil
+e( $file);
    if( !$result_twig)
      { $result_twig= $current_twig; }
    else
      { $current_twig->root->move( last_child => $result_twig->root)
                           ->erase;
      }
  }

$result_twig->print;
[download]

Also a more generic way would be to keep the first document, and then to add the other ones at the end, removing their root: ...

I'm not sure how much more "generic" your second solution would be... It might not apply very well, I think, in cases where the quantity of xml data to be concatenated, multiplied by the additional memory consumed for DOM data structure storage in perl, could exceed available RAM.

It's more generic in the sense that it doesn't assume that the root tag of the first document is foo. As you did not mention any constraint on the size of the documents, then I did not assume any.

If there are contraints, for each individual file or for the resulting file, then you should mention it and the solution would be different. Depending on the constraints in terms of speed and potentialsize of the documents, the best solution could be regexp based (that could be made quite robust, provided your XML files do not include DTDs), XML::LibXML based (if individual files are not too big to be loaded in memory), XML::Parser based (rather easy if no DTD is used, a bit more complicated otherwise) or XML::Twig based (slower, but you could deal with arbitrary sized documents, and that would be quite easy to code, although a bit more complex than the examples I gave previously).

But all those potential constraints would be part of the requirements for your code, so you would have to express them if you want a response that really fits your problem.

And no, I am not trying to confuse you to cover up the fact that my answer wasn't that smart ;--)