XML::LibXML

libxml2 implementa internamente clientes ftp y http, por lo que podemos utilizar de manera transparente URIs de estos protocolos, tanto al indicarle al procesador que se desea tratar un archivo, como a la hora de colocar en el texto referencias a entidades externas o enlaces Xinclude.

En ambos casos el procesador XML::LibXML los trata como si de archivos locales se tratara. En consonancia con su uso transparente, el módulo ha previsto sólamente un diálogo simple con el servidor, por ejemplo el uso de ftp anónimo, sin implementar una capa compleja que lidie con el protocolo, por ejemplo ante el uso de proxies o de autentificación.

Si este uso simple no fuera suficiente, si deseáramos cambiar las URIs existentes en los documentos por otras, o habilitar el acceso a URIs de protocolos diferentes, tenemos la posibilidad de hacerlo, aunque en este caso nos queda a nosotros el implementar el diálogo con el servidor.

En este caso disponemos de métodos adicionales para dar instrucciones concretas al procesador para unas URIs determinadas.

El método match_callback nos permite indicar qué patrón debe buscarse en la URI. Nos remite a una función (una referencia a ella en realidad), que hará la tarea:

$parser->match_callback($subref);

Si la rutina indicada devuelve 1, es decir se cumple ese patrón, el procesador ejecutará las funciones que hemos indicado para él. La búsqueda tiene prioridad ante otros patrones internos de libxml2, por lo que si se activa no buscará en otros tipos de URIs; en caso de que no se siga el patrón, el procesador seguirá su curso normal.

Podemos crear funciones específicas para tres acciones que toma el procesador al tratar la URI: open_callback , al abrirla, read_callback, al leer datos del archivo referido por la URI, y close_callback, al cerrarlo.

En este ejemplo implementaremos unas funcionas básicas para gestionar URIs del protocolo tftp:

#!/usr/bin/perl -w
use XML::LibXML;
use Net::TFTP;

my $parser = XML::LibXML->new();
$parser->match_callback( \&match_uri );
$parser->read_callback( \&read_uri );
$parser->open_callback( \&open_uri );
$parser->close_callback( \&close_uri );

$doc=$parser->parse_file('tftp://localhost/sidebar.xml');
print $doc->toString();

sub match_uri {
    my $uri = shift;
    return $uri =~ /^tftp:\/\// ? 1 : 0; 
}
sub open_uri {
	my $uri = shift;
	$uri =~ /^tftp:\/\/([^\/]*)\/(.*)/;
	my $server=$1;
	my $file=$2;
	my $tftp = Net::TFTP->new($server, BlockSize => 1024);
	$tftp->binary;
	$tftp->get($file, "$file"); # /tmp/$file
	my $handler = new IO::File "$file"; # /tmp/$file
	return $handler;
}
sub read_uri {
    my $handler = shift;
    my $length  = shift;
    my $buffer = undef;
    if ( $handler ) {
        $handler->read( $buffer, $length );
    }
    return $buffer;
}
sub close_uri {
    my $handler = shift;
    if ( $handler ) {
        $handler->close();
    }
    return 1;
}

En nuestro ejemplo, la URI del archivo a procesar por el método parse_file es tftp://localhost/sidebar.xml.

La función match_uri sevuelve 1 si la URI comienza por la cadena "tftp://", e inicia el procesado alternativo.

El grueso del trabajo lo realizará la función open_uri. Ésta debe devolver un manejador de archivo, y tenemos varios métodos de implementar esto. Aquí utilizamos el más sencillo, guardar el archivo remoto en un directorio temporal, tras traerlo con Net::TFTP, y abrirlo entonces mediante IO::File, que nos proporciona el manejador necesario.

XML::LibXML permite utilizar archivos locales comprimidos con gzip. Esta funcionalidad no está disponible con la gestión de URIs http o ftp, aunque lógicamente se podría implementar una similar mediante médodos de gestión propios para determinadas URIs, como hemos visto.

Simplemente se ha de utilizar un método de procesamiento de archivos, por ejemplo parse_file:

my $doc = $parser->parse_file('sidebar.xml.gz');

En el proceso contrario, si se vuelca un objeto XML::LibXML::Document a un archivo, com el método toFile es posible obtener una salida comprimida con zlib ( gzip). Ello dependerá obviamente de que libxml2 esté compilada con la opción de utilizar zlib.

Esta funcionalidad se controla mediante una variable interna, que podemos consultar con el método compression, o modificar mediante el método setCompression de un objeto XML::LibXML::Document.

En ausencia de compresión, la variable toma el valor -1, y si es positivo, es decir, está habilitada la compresión, guarda la ratio de compresión, que para gzip puede ser de 1 a 9.

Así, para volcar el árbol DOM del documento completo a un archivo, con la máxima compresión:

$doc->setCompression(9);
print my $state=$doc->toFile("/tmp/sidebar.xml.gz");

El primer método que podemos usar para una recepción a ráfagas está basado en el tratamiento de un flujo de datos. La llamada al procesador parse_fh nos permite utilizar para el flujo cualquier manejador de entrada (handler) que pueda gestionarse desde Perl. En este caso se le indica al procesador una referencia al manejador o un objeto IO::Handle.

Así podemos modificar el código incial para que obtenga el texto XML de la entrada estándard:

#!/usr/bin/perl -w
use XML::LibXML;
my $parser = XML::LibXML->new();
$ioref     = *STDIN{IO};
$doc = $parser->parse_fh( $ioref );
print $doc->toString();

Y ya podemos usarla en una tubería:

cat prueba.xml | prueba.pl;

En este método el procesado continúa hasta que se detecta el fin de la entrada, por ejemplo en un archivo hasta que llega al final del mismo.

El método parse_fh admite también un segundo parámetro, para indicar la URI base, que se usa igual que lo hacíamos con parse_string:

$doc = $parser->parse_fh( $ioref, $baseuri);

Otro método, parse_chunk, nos permite utilizar las ráfagas en cadenas de texto.

use XML::LibXML;
  my $parser = XML::LibXML->new;
  for my $string ( "<", "hola a todos", "/>") {
       $parser->parse_chunk( $string );
  }
  my $doc = $parser->parse_chunk("", 1); # terminate the parsing
print $doc->toString;

En este caso el procesador no sabe cuándo ha llegado la última cadena, y hemos de indicársela expresamente, con un segundo parámetro que activa el flag de fin de la entrada.

Aquí no dispondremos de la posibilidad de indicar una URI base para textos que incluyan rutas relativas.

Si los métodos anteriores no son suficientes para nuestro entorno, por ejemplo, porque la fuente de datos produce errores, aún podemos utilizar el procesador push a bajo nivel. En este caso, obviamente, armar el proceso es más parecido al trabajo real de los datos con libxml2, no como en el caso anterior en que LibXML::XML hacía todo el trabajo por nosotros. Debemos inicializar la matriz de cadenas con el método start_push, llenarla con push y declararla con el método finish_push.

A cambio, aquí es posible utilizar las facilidades de recuperación de errores del procesador, como hacemos con del método recover del modo pull; en caso de error en el procesado de una de las secuencias aún es posible continuar. Para activarlas enviamos un 1 como parámetro al método finish_push.

use XML::LibXML;
my $parser = XML::LibXML->new;
eval {
	for my $string ( "<hola>", "a" , "<todos/>") {
       		$parser->push( $string);
  	}
	$doc = $parser->finish_push(1);
};
print $doc->toString();

En esta variante de los ejemplos anteriores el elemento hola está roto, y el procesador lo advierte, pero aún así continúa procesando el texto e intenta reparar el error:

Entity: line 1: parser error : Extra content at the end of the document
<hola>a<todos/>
               ^
<?xml version="1.0"?>
<hola>a<todos/></hola>

XML::LibXML::SAX provee un procesador PerlSAX. Su uso más simple, como es habitual en SAX, encadena un procesador a un manejador, al que pasa los eventos.

Así, en este ejemplo, utilizamos el manejador XML::Handler::PrintEvents, que imprime un informe de cada evento que recibe:

#!/usr/bin/perl -w
use XML::LibXML::SAX;
use XML::Handler::PrintEvents;
my $p = XML::LibXML::SAX->new(Handler => XML::Handler::PrintEvents->new);
$p->parse_uri("sidebar.xml");

Este procesador es puro SAX, no construye el árbo DOM de los datos con que va trabajando; en su lugar va generando los eventos.

A los métodos de SAX2 se le añade uno nuevo, parse_chunk, que permite utilizar las facilidades del libxml2 con textos incompletos, aqunque balanceados, como hace el método parse_balanced_chunk del procesador DOM.

$p->parse_chunk($cadena');

XML::LibXML::SAX::Parser provee de un generador PerlSAX a partir de un árbol DOM. No es un procesador de flujo, simplemente produce una lista de eventos que se pueden utilizar en la tubería SAX:

#!/usr/bin/perl -w
use XML::LibXML::SAX::Parser;
use XML::Handler::PrintEvents;
my $p = XML::LibXML::SAX::Parser->new(Handler => XML::Handler::PrintEvents->new);
$p->parse_uri("sidebar.xml");

Estos procediemtos se aplican a los objetos del tipo XML::LibXML::Document, es decir al árbol DOM completo obtenido tras el procesamiento con alguno de los métodos adecuados DOM, por ejemplo parse_file.

El procedimiento de validación de un documento contra un esquema RelaxNG difiere en algo de la validación contra DTDs, que son el procesamiento por defecto en XML::LibXML, y que son los definidos en el estandard.

El paso inicial del procesamiento del documento XML es igual que en caso anterior. El procesamiento del esquema RelaxNG lo lleva a cabo el módulo XML::LibXML::RelaxNG, y el método validate que lleva a cabo la acción final de validación en esta ocasión lo provee este últmo módulo.

use XML::LibXML;
my $parser = XML::LibXML-> new();
my $validator = XML::LibXML::RelaxNG->new(location => "prueba.rng");
my $doc = $parser-> parse_file("prueba.xml");
eval { $validator-> validate($doc); };

Podemos probar este código con los ejemplos que nos ofrece el tutorial de RelaxNG que nos proporcionan sus desarrolladores.

El método new el validador recibe como parámetro un par clave-valor que indica el tipo de datos en que se guarda el esquema RelaxNG y dónde ha de irlo a buscar el programa. Las opciones posibles en los tipos de datos son:

Así, la creación de la instancia del validador con string podría ser:

my $validator = XML::LibXML::RelaxNG->new(string =>
<<'FIN');
<element name="addressBook" xmlns="http://relaxng.org/ns/structure/1.0">
  <zeroOrMore>
    <element name="card">
      <element name="name">
        <text/>
      </element>
      <element name="email">
        <text/>
      </element>
    </element>
  </zeroOrMore>
</element>
FIN;

Y con DOM debemos procesar previamente el esquema RelaxNG, que es después de todo un documento XML:

my $rng=$parser-> parse_file("prueba.rng");
my $validator = XML::LibXML::RelaxNG->new(DOM => $rng);;

El tratamiento para esquemas XML es similar al de RelaxNG, haciendo uso de un validador de la clase XML::LibXML::Schema. Esta vez sólo disponemos de dos opciones para entregar el código del esquema, la de un archivo y un escalar:

use XML::LibXML;
my $parser = XML::LibXML-> new();
my $validator = XML::LibXML::Schema->new(location => "library1.xsd");
my $doc = $parser-> parse_file("library1.xml");
eval { $validator-> validate($doc); };

Podemos comprobar este código con los ejemplos de un tutorial de xml.com.

Si se tratara de un escalar, el comportamiento es igual al que vimos más arriba:

my $validator = XML::LibXML::Schema->new(string =>$myXMLschema);

Node es el interfaz base del Core de DOM. DOM modela los documentos XML como un conjunto de nodos. Veamos la corespondencia entre el interfaz y su implementación con XML::LibXML::Node.

Para su uso típico en escritura de documentos, LibXML::XML provee de un método de escritura para el atributo NodeName del estándard DOM, que no contempla este caso, setNodeName. Tengamos en cuenta que DOM sigue caminos diferentes en la creación de documentos XML.

Otra diferencia con el estándard es el atributo baseURI, que DOM modela dentro de Node. Hemos visto que es un parámetro global en XML::LibXML, pasado al procesador, por lo que ni siquiera está a la altura del nodo raíz del documento XML, sino afectado a todos los documentos pasados al procesador.

El interfaz Node del estandard DOM provee de una propiedad de sólo lectura, ownerDocument, que indica el nodo de tipo Document que ocupa el lugar más alto de la estructura arbórea XML. Tal valor será nulo cuando se crea un nodo por primera vez. LibXML::XML, por contra, provee de dos métodos para esta propiedad, uno de lectura, ownerDocument, y otro de escritura, setOwnerDocument, lo que de hecho nos permite sacar un nodo de un documento e incluirlo en otro.

Esta operación ya la permite DOM 3, pero efectuada desde el nodo superior, Document, mediante la operación adoptNode. Lo que hace LibXML::XML es permitir también la operación desde el nodo inferior. Las dos últimas líneas del siguiente código son similares:

my $doc = XML::LibXML::Document->new;
my $xnode = XML::LibXML::Element->new("test");

my $node = $doc->adoptNode( $xnode );
$xnode->setOwnerDocument( $doc );

Adicionalmente, LibXML::XML permite adscribir nodos no sólo a documentos, sino también a fragmentos -nodos DocumentFragment-. De ahí que provee de un método para averiguar directamente el nodo superior, getOwner, sin hacer referencia explícita al nodo XML::LibXML::Document. Su efecto no obstante es similar al método ownerDocument si efectivametne el nodo está adscrito a un documento.

XML::LibXML extiende las operaciones del estándard DOM en la manipulación de nodos con métodos de adición (addChild, addNewChild, addSibling, insertAfter), substracción (removeChildNodes) o sustitución (replaceNode).

En lo que se refiere a los enlaces directos de los nodos, LibXML::XML provee de un método, unbindNode, que desliga el nodo de sus superiores y hermanos; la adscripción al nodo documento sin embargo no se pierde, y deberemos acudir a setOwnerDocument si deseamos cambiarlo de documento. Los nodos desligados son implícitamente hijos de un nodo XML::LibXML::DocumentFragment.

Otra extensión a DOM es el método getNamespaces, que devuelve los espacios de nombres declarados explícitamente en ese nodo (no los heredados desde los nodos superiores). Este método devuelve un arreglo de objetos XML::LibXML::Namespace.

XML::LibXML::Node ofrece métodos adicionales para búsquedas XPath y salida, a los que nos referiremos más tarde.

DOM define el interfaz Nodelist como una simple lista ordenada de nodos, sin entrar a detallar su implementación. Tan sólo indica dos propiedades que describen el número de items (length) y los nodos componentes (item).

XML::LibXML permite utilizar las lista de nodos como arreglos de Perl, con cualquiera de sus procedimientos habituales. El siguiente ejemplo nos devolverá por este camino el número de elementos de la lista, que presentaremos seguidamente como cadenas de texto:

use XML::LibXML;

my $string = "<A><A><B/></A><A><B/></A></A>";
my $parser = XML::LibXML->new();
my $document = $parser->parse_string($string);
my @array = $document->getElementsByTagName("A");
print scalar( @array ), "\n";
foreach $node (@array) {
	print $node->toString, "\n";
}

Lo que devolverá el número de elementos, y cada uno de los nodos, como texto:

3
<A><A><B/></A><A><B/></A></A>
<A><B/></A>
<A><B/></A>

XML::LibXML provee también de una implementación específica del interfaz Nodelist, XML::LibXML::Nodelist. Esta clase funciona de manera bastante similar a un arreglo Perl, con métodos para crear un objeto (new), introducir elementos en él (push como en una pila, unshift como en colas), extraerlos (pop como en pilas, shift como en colas) y para conocer el número de elementos (size, equivalente a la propiedad lenght del interfaz).

Si utilizamos la clase XML::LibXML::Nodelist::Iterator, externa a la distribución, dispondremos de un método adicional, iterator, que nos permite crear subconjuntos de XML::LibXML::Nodelist que cumplan determinada condición XPath y tratarlos como una lista, con movimientos lineales hacia arriba y hacia abajo.

Los métodos de la clase XML::LibXML::Document que devuelven listas de nodos si se utilizan en contexto de arreglos, como en el ejemplo anterior, devuelven arreglos Perl, pero si se utilizan en contexto escalar devuelven un objeto XML::LibXML::Nodelist.

Podemos modificar ligeramente el ejemplo anterior, para conocer desde un objeto XML::LibXML::Nodelist su número de elementos, y que nos devuelva el último:

use XML::LibXML;

my $string = "<A><A><B/></A><A><B/></A></A>";
my $parser = XML::LibXML->new();
my $document = $parser->parse_string($string);
my $nodelist = $document->getElementsByTagName("A");
print $nodelist->size, "\n";
my $node=$nodelist->pop;
print $node->toString;

Obtendremos:

3
<A><B/></A>

Los métodos prepend y append nos permiten añadir un objeto XML::LibXML::Nodelist a otro ya existente, colocándolo al principio o al final respectivamente.

Modificamos nuestro ejemplo para que añada un nuevo Nodelist al que hemos creado inicialmente, al final del conjunto existente:

my $nodelist2 = $document->getElementsByTagName("B");
$nodelist->append($nodelist2);

y el resultado mostrará los cambios introducidos tras la adición del nuevo objeto XML::LibXML::Nodelist:

5
<B/>

El método get_nodelist devuelve un arreglo Perl, con lo que podremos revertir al modelo de gestión de listas de nodos que veíamos arriba.

Añadiendo estas lineas al ejemplo anterior:

my @array=$nodelist->get_nodelist;
print scalar( @array ), "\n";

nos devolverá el número de elementos del arreglo que hemos creado con los nodos que contiene el objeto XML::LibXML::Nodelist.

La interfaz NamedNodeMap permite acceder a colecciones de nodos, pero a diferencia de Nodelist los nodos están agrupados por su nombre, y no están ordenados.

El método attributes de XML::LibXML::Node devuelve en contexto escalar un nodo XML::LibXML::NamedNodeMap (en contexto de arreglo devuelve un arreglo Perl de objetos XML::LibXML::Attr):

use XML::LibXML;
my $string = '<a n="1" b="c"><b/></a>';
my $parser = XML::LibXML->new();
my $doc= $parser->parse_string($string);

my $nnm=$doc->firstChild->attributes;
print $nnm->length;

El método length devuelve el número de nodos que componen la colección. El método new que introduce XML::LibXML::NamedNodeMap permite crear un objeto nuevo, a partir de un arreglo de nodos:

use XML::LibXML;
my $string = '<a><b/><c/><d/></a>';
my $parser = XML::LibXML->new();
my $doc= $parser->parse_string($string);
my @array=($doc->firstChild->firstChild, $doc->firstChild->lastChild);
my $nnm=XML::LibXML::NamedNodeMap->new(@array);
print $nnm->getNamedItem("d")->toString;

El uso habitual de esta colección de nodos es a través de su nombre. En este ejemplo, el método getNamedItem nos devuelve el nodo correspondiente a un nombre que conocemos previamente.

El método nodes, también extensión de XML::LibXML::NamedNodeMap a DOM, permite realizar la operación contraria a new, o sea obtener un arreglo de nodos a partir de un objeto XML::LibXML::NamedNodeMap. nodes en realidad devuelve una referencia a un arreglo. Así, si el objeto XML::LibXML::NamedNodeMap anterior se convierte en una colección ordenada, podemos acceder a ella secuencialmente:

my $new_array= $nnm->nodes;
foreach $node ( @{$new_array} ) {   
    print $node->toString , "\n";
}

Document y DocumentFragment son los nodos más altos en la jerarquía que establece el modelo DOM para representar los textos XML. Todos los demás nodos serán hijos de estos nodos. En consecuencia, el procesador DOM de LibXML::XML devuelve objetos de estos tipos tras tratar un texto de entrada.

Si no hemos utilizado el procesador, y deseamos crear un objeto XML::LibXML::Document nuevo, debemos partir del método createDocument o su alias new.

XML::LibXML añade dos extensiones adicionales a las operaciones que permiten obtener listas de nodos desde el nodo documento: getElementsById y getElementsByLocalName.

XML::LibXML permite compresión, y por ello añade los métodos compression y setCompression a los nodos Document; se trata de la manipulación de una propiedad, y obviamente no afecta al árbol DOM, sino a las operaciones de escritura que se se realicen posteriormente con él.

DOM establece una única propiedad, doctype, de sólo lectura, para indicar el tipo de documento (interfaz DocType). LibXML::XML en cambio utiliza la clase XML::LibXML::Dtd para representar el tipo de documento.

libxml2 distingue entre nodos Dtd internos y externos: los internos son procesados como paso previo a su utilización; de ahí que los métodos de adscripción genéricos de Document (adoptNode, importNode), no son suficientes para este tipo de nodos. En su lugar se ofrece un grupo extenso de métodos para actuar sobre este tipo de nodos desde el nivel superior del árbol (XML::LibXML::Document), además de los que provee la clase XML::LibXML::Dtd en el nivel inferior. Se proveen para crear (createDTD, createExternalSubset, createInternalSubset), indicar cuál se aplica (setExternalSubset, setInternalSubset) o simplemente leer el valor (externalSubset, internalSubset).

El siguiente ejemplo establece el tipo de un documento:

use XML::LibXML;
my $doc = XML::LibXML::Document->new;
my $dtd = $doc->createExternalSubset( "html",
                                          "-//W3C//DTD XHTML 1.0 Transitional//EN",
                                          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
                                        );
print $dtd->toString;

El resultado:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

El método createDTD crea un nodo XML::LibXML::Dtd sin prejuzgar si es interno o externo. El uso posterior de uno de los métodos setExternalSubset o setInternalSubset nos permite precisarlo posteriormente, sustituyendo a adoptNode o importNode:

my $dtd = $doc->createDTD( "html",
                                "-//W3C//DTD XHTML 1.0 Transitional//EN",
                                "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
                              );
$doc->setInternalSubset( $dtd);

Al método insertProcessingInstruction, alternativa a createProcessingInstruction nos referiremos al tratar las instrucciones de procesamiento

Los nodos Element son contenedores de otros nodos. En el modelo DOM son los encargados de crear las ramas del árbol como posición intermedia entre los nodos raíz (Document o DocumentFragment) y los nodos con información final.

DOM incluye en el interfaz la propiedad tagName, que no está implementada en XML::LibXML::Element. En su lugar acudiremos a los métodos nodeName, setNodeName o localname que heredamos de la clase padre, XML::LibXML::Node.

XML::LibXML incluye extensiones al estandard para añadir nodos hijo a un objeto Element. El método appendWellBalancedChunk -o su alias appendChild- permite incluir un fragmento balanceado, es decir una sucesión cualquiera de nodos hijo, sin encuadrarse en un elemento. Puesto que el procesador puede tratar también textos balanceados, podemos obtener esos fragmentos directamente, y añadirlos a un nodo Element, de esta manera:

my $element = XML::LibXML::Element->new( $name )
my $fragment = $parser->parse_xml_chunk( $chunk );
$element->appendChild( $fragment );

El método appendText - o su alias appendTextNode - añade un nodo texto a un elemento, que puede contener otros nodos hijos. El método appendTextChild en cambio crea un elemento con un único hijo, un nodo texto.

Otros métodos extienden la posibilidad de buscar conjuntos de nodos dentro del elemento, que en DOM queda reducida a la búsqueda de nodos con un determinado nombre, ya sea simple (getElementsByTagName) o con espacio de nombres (getElementsByTagNameNS). El método getElementsByLocalName permite buscar elementos que contengan un determinado nombre local, no sólo el conjunto nombre local + espacio de nombres que permite getElementsByTagNameNS. Por último, los métodos getChildrenByTagName y getChildrenByTagNameNS listan los nodos hijo con igual nombre de etiqueta.

El método setNameSpace permite añadir espacios de nombres al nodo Element. Según los parámetros recibidos, se instalará un espacio de nombres adicional, a añadir a la lista de los ya existentes, o será el espacio de nombres por defecto del elemento.

DOM prevee la creación de nodos Element desde Document. LibXML::XML en cambio nos permite crear nodos LibXML::XML::Element independientes, gracias al método new. Estos nodos están desligados mientras no los insertemos en un árbol, y por defecto quedan adscritos a un nodo LibXML::XML::DocumentFragment implícito.

DOM modela los interfaces de texto desde un interfaz común, CharacterData, del que heredan los interfaces Text y Comment. A su vez el interfaz Text sirve de base para CDATASection.

XML::LibXML prescinde del interfaz CharacterData y concentra todos los métodos en LibXML::XML::Text. Las clases LibXML::XML::Comment y LibXML::XML::CDATASection heredan los métodos de LibXML::XML::Text y no poseen métodos propios.

Por lo demás, LibXML::XML::Text implementa prácticamente todo el interfaz CharacterData. Pero como las operaciones de subcadenas son limitadas en DOM, añade extensiones para ellas.

Las operaciones DOM replaceData y deleteData (y sus correspondientes métodos XML::LibXML::Text) cambian o borran subcadenas, indicando la posición de inicio y la longitud. Los métodos replaceDataString y deleteDataString parten de subcadenas conocidas, sustituyéndolas o eliminándolas.

$text->deleteDataString($remstring, $flag);
$text->replaceDataString($old, $new, $flag);

El parámetro final es un indicador de si la operación se realizará una sólo vez (con valor 0) o en todas las ocurrencias (con valor 1).

Por último, el método replaceDataRegEx permite la sustitución de una cadena mediante un patrón de expresiones regulares.

Como en otros nodos intermedios o finales, LibXML::XML permite extender las posibilidades de DOM creando nodos LibXML::XML::Text invocando la clase directamente con el método new, sin necesidad de hacerlo desde LibXML::XML::Document.

DOM define este interfaz para instrucciones de procesamiento con dos únicas propiedades, para indicar la marca o identificador de enlace (la primera palabra) y un texto que le sigue.

El texto puede ser escrito mediante el método setData, mientras que para la lectura utilizaremos el método getData que provee la clase superior, XML::LibXML::Node. La marca es accesible mediante los métodos nodeName y setNodeName de XML::LibXML::Node o al tiempo de creación del nodo.

La creación de una instrucción de procesamiento, siguiendo los métodos DOM, implica tres pasos: Crearla, escribir el texto que contiene y añadirla al árbol:

my $pi = $dom->createProcessingInstruction("abc");
$pi->setData(foo=>'bar', foobar=>'foobar');
$dom->appendChild( $pi );

XML::LibXML::Document nos provee del método alternativo insertProcessingInstruction para hacerlo todo en un paso:

$dom->insertProcessingInstruction("abc",'foo="bar" foobar="foobar"');

que dará el mismo resultado que el código de arriba:

<?abc foo="bar" foobar="foobar"?>

XML::LibXML::Attr implementa el interfaz Attribute de DOM.

En esta clase tampoco hay una implementación de la propiedad Name de DOM, y acudiremos a los métodos nodeName, setNodeName o localname que heredamos de XML::LibXML::Node.

El método setNameSpace extiende el interfaz DOM para permitir colocar el atributo en un espacio de nombres.

La clase XML::LibXML::Dtd incluye un procesador para documentos DTD, como la clase LibXML::XML ofrece un procesador para documentos XML. El procesamiento con esta clase devuelve un objeto especial, de esta clase.

Los nodos Dtd se corresponden -más bien sustituyen- al interfaz DOM DocumentType, que es hijo (en una sola ocurrencia) de un nodo Document. XML::LibXML::Dtd no obstante no implementa los métodos de DocumentType. Tan sólo posee los métodos que hereda de XML::LibXML::Node, aunque dada la naturaleza de los DTDs no todos los métodos están disponibles.

Puesto que los DTDs no soportan espacios de nombres, los métodos de XML::LibXML::No