El espacio de nombres es una característica heredada del XML. Y consiste en la posibilidad de establecer categorias diferenciadas donde el significado de los tags es distinto en cada categoría (aunque se llamen igual los tags).

Un cliente que procese un XML ignorará todo contenido definido en un espacio de nombres que no entienda (por no haber sido programado para entenderlo). Así si un fichero XML contiene una imagen, un texto y una voz grabada, en función de que el programa soporte sonido y gráficos este mostrará el máximo de información que pueda.

Además este mecanismo protege los errores de interpretación del XML. Si dentro del espacio de nombres "sonido" hay un tag llamado <contenido> y en el espacio de nombres "imagen" hay otro tag de igual nombre, no ocurrirá que un cliente intente reproducir sonido del contenido de la imagen (si el cliente no entiende de imagenes).

Y ahora Jabber

Jabber incorpora estos mecanismos lo que permite que cada cliente Jabber pueda incorporar libremente todas aquellas funcionalidades que estime oportunas sin necesidad de tener que comunicarlo a todos los desarrolladores de clientes Jabber (sería imposible) ni a un organismo central que todos mirasen (obligaría a modificar todos los clientes cada vez que uno modifica algo).

Hay que guardar cierto orden para establecer nuestros espacios de nombres. Si hay acuerdo previo se utilizará el nombre especificado, en caso de modificaciones experimentales, se luele usar el nombre del cliente que lo implementa seguido de la función que implementa. Por ejemplo, los mensajes para jugar al ajedrez con Tkabber van todos dentro de un espacio de nombres llamado "games:board" y la pizarra de Tkabber va en "tkabber:whiteboard". Se ve, por el nombre usado, que el segundo nombre indica una función más experimental que el primero y han usado un nombre para que no coincida con ninguna pizarra de otro cliente.

Implementar funcionalidades usando el espacio de nombres se hace por 3 motivos:

• Experimentación. Experimentar cosas nuevas que aún no está en el estándar. Así no se molesta a los demás desarrolladores de clientes y en cambio se puede demostrar la utilidad de dicha funcionalidad.
• Especifidad. Se implementa una funcionalidad tan específica para un número tan reducido de clientes que no es necesario complicar el protocolo para incluir dicha funcionalidad.
• Modularidad. El protocolo no hace imposiciones sobre los tipos de clientes/servidores a usar (por ejemplo no obliga a la existencia de una pantalla). De forma que todas las funcionalidades avanzadas (como puede ser una transferencia de ficheros) se clasifican con nombres de espacio distintos para permitir a los clientes ignorarlos si les conviene.

Normalmente, en el primer caso se intenta promover las funcionalidades experimentales a estándar. En el tercero se entiende que ya está en el estándar y en el segundo caso no tendría sentido.

Por último, puede plantearse la duda de que la posibilidad de añadir funcionalidades sin control por parte de los clientes perjudiquen el protocolo hasta tal punto de hacer clientes incompatibles entre sí. La única respuesta posible es filosófica (no técnica). El nacimiento de jabber se efectúa como la necesidad de implementar un protocolo libre de mensajería. Y los desarrolladores de clientes jabber crean los clientes para poder acceder a ese protocolo libre. La mayoria de los clientes son además libres, lo que significa la posibilidad de copiar rápidamente las funcionalidades añadidas e incorporarlas al estándar (aunque el creador inicial no quisiese). Luego en esta epoca de desarrollo de Jabber no tiene sentido hablar de un cliente que abuse de extensiones no estándares.

El problema es cuando más adelante, si se asienta y florecen clientes Jabber no libres. ¿Que impediría establecer funcionalidades avanzadas para exclusivamente los usuarios de estos clientes?