Resumen

  • El espacio de nombres predeterminado alcanza a los elementos sin prefijo, pero no a sus atributos sin prefijo; confundirlos puede asignar significado o autoridad al campo equivocado.
  • XML bien formado, vocabulario reconocido, validación, firma y autorización son comprobaciones separadas y deben conservar recibos separados.

El elemento llevaba el vocabulario esperado. Dentro había un atributo sin prefijo. A simple vista parecía parte de la misma declaración; para XML no lo era.

Los espacios de nombres predeterminados se aplican a los elementos sin prefijo, no a los atributos sin prefijo. Si una implementación atribuye a ambos el mismo origen, puede leer una instrucción local como si perteneciera al vocabulario protocolario. El documento sigue siendo XML perfectamente bien formado.

El RFC 3470, publicado en enero de 2003 como Best Current Practice 70, fue escrito para protocolos que ya habían elegido XML. No intenta decidir que XML sea la mejor representación. Explica qué decisiones no puede tomar el analizador por ellos.

La gramática abre la puerta, no identifica al visitante

La comprobación de buena formación establece reglas básicas: caracteres admitidos, etiquetas equilibradas, atributos construidos correctamente y una estructura que un procesador XML puede leer. Un documento mal formado no debe interpretarse parcialmente. El protocolo puede pedir retransmisión o terminar la operación, pero no seleccionar los fragmentos cómodos.

El éxito produce un XML Information Set, una vista abstracta. Para llegar allí, el procesador ha tratado la codificación, finales de línea, entidades, espacios de nombres y normalizaciones. El infoset no es la copia exacta de los octetos recibidos.

Por eso el primer recibo conserva bytes, hash, transporte, tipo de medio, fecha y codificación. El segundo identifica analizador, versión, configuración y resultado de buena formación. Una luz verde que diga «XML válido» no aclara cuál de esas pruebas se realizó.

La declaración XML debe aceptarse y, cuando el protocolo permita codificaciones distintas de UTF-8 o UTF-16, pasa a ser necesaria. La codificación no es decoración: determina qué caracteres entraron en la gramática antes de que existiera el árbol.

El URI del espacio de nombres no firma nada

Los espacios de nombres permiten combinar vocabularios sin confundir nombres iguales. Sus identificadores tienen forma de URI, pero no son una orden automática de descarga ni una credencial institucional.

Que un nombre incluya un dominio conocido no demuestra que el emisor tenga permiso para actuar en nombre de esa organización. El protocolo debe asociar vocabulario, significado y autoridad mediante reglas propias y comprobaciones autenticadas.

La diferencia entre elementos y atributos sin prefijo obliga a revisar cada nombre expandido, no solo la apariencia del texto. También obliga a decidir qué se hace con una extensión desconocida. Puede ignorarse, conservarse, reenviarse, rechazarse o declararse obligatoria de entender. XML no elige una opción.

Las instrucciones de procesamiento y los comentarios tampoco deben alojar extensiones normativas escondidas. El RFC 3470 recomienda que el procesamiento normal pueda ignorarlos.

Una extensión válida puede bloquear la interoperabilidad

Supongamos que dos pares reconocen el elemento principal. Uno encuentra un hijo de otro espacio de nombres y lo conserva; el otro lo descarta; un tercero lo interpreta como obligatorio. Ninguno tiene un error de sintaxis. La incompatibilidad está en la política de extensiones.

El contrato debe indicar dónde se permiten extensiones, cómo se marca la obligación de entenderlas, qué datos se conservan al reenviar y qué error se devuelve. De lo contrario, cada biblioteca convierte una decisión accidental en comportamiento de protocolo.

Este límite importa más con intermediarios. Un gateway puede validar el documento, eliminar lo que no comprende y volver a serializarlo. El receptor final recibe XML válido pero ya no la misma instrucción. Para auditar el caso hacen falta los octetos de cada salto y el registro de transformación.

La especificación mínima común debe cubrir estos puntos de interoperabilidad. No necesita imponer una biblioteca ni una arquitectura interna; sí debe impedir que el silencio produzca nueve políticas incompatibles.

El esquema no corrige la autoridad del nombre

Una DTD o XML Schema puede exigir elementos, tipos y relaciones estructurales. Los formalismos no expresan todas las reglas semánticas. Un campo puede cumplir su tipo y seguir siendo falso, caduco o prohibido en el estado actual.

Además, una validación necesita coordenadas: perfil, versión, origen y configuración. Los valores predeterminados pueden aparecer en el árbol aunque no estuvieran en el paquete. Un visor de tráfico y un validador pueden mostrar mensajes diferentes sin alterar los bytes.

El RFC desaconseja esa dependencia en protocolos porque complica firmas, trazas y procesadores que no conocen el esquema. La evidencia debe conservar tanto la entrada como el infoset entregado a la aplicación.

La semántica permanece en la especificación y en el código. Ningún esquema decide que una identidad autenticada está autorizada para ejecutar la operación.

Las referencias externas cambian el perímetro

Entidades externas, esquemas remotos y referencias relativas pueden introducir datos no incluidos en el mensaje. También pueden hacer que el analizador abra una conexión desde una red con privilegios distintos a los del emisor.

El RFC 3470 recomienda evitar declaraciones de entidades en protocolos e impedir accesos arbitrarios al procesar XML no confiable. Las cinco entidades predefinidas y las referencias numéricas no requieren una consulta remota; deben seguir admitiéndose.

xml:base añade una disputa potencial entre la base del documento, la del contenedor y la del transporte. La precedencia debe quedar escrita. Para reproducir una decisión hay que registrar cada URI resuelto, los bytes obtenidos o la prueba de que la red estaba desactivada.

Una repetición que vuelve a consultar Internet no reproduce el incidente: ejecuta otro experimento.

Firmar un nodo no autoriza todos los nodos

Canonical XML, en el RFC 3076, genera una serialización reproducible de un conjunto de nodos. XML Signature, en el RFC 3275, aplica referencias y transformaciones. La verificación solo cubre el objeto seleccionado por esas reglas.

El recibo criptográfico debe mostrar referencias, transformaciones, algoritmo de canonización, clave e identidad. Si la aplicación toma la orden de un nodo firmado pero el destino de un atributo no firmado, la firma no avala la combinación.

La identidad verificada tampoco concede autorización. Una petición puede ser auténtica y violar el estado, el plazo o la política. La transición confirmada y el resultado para el usuario llegan después.

Tampoco debe sustituirse XML por un subconjunto privado para simplificar la firma. Las restricciones improvisadas crean productores y consumidores incompatibles. Cuando hace falta una representación común, debe especificarse una canonización compartida.

El espacio visible puede tener significado

XML entrega información de caracteres. Si el protocolo no define otra cosa, la sangría y los saltos pueden formar parte del contenido. Un formateador que «solo ordena» el archivo puede modificar la operación.

En cambio, el orden de atributos no tiene significado XML y algunos valores se normalizan. Basar una firma o una regla de negocio en ese orden convierte una coincidencia del serializador en contrato oculto.

Las reglas de espacios, contenido mixto, orden de elementos y atributos deben ser explícitas. La apariencia en una consola no es evidencia suficiente.

El analizador también necesita límites

XML no aporta confidencialidad, integridad, autenticación ni autorización incorporadas. El código del analizador procesa estructura controlada por terceros y puede sufrir expansiones, consumo excesivo o errores de memoria.

Hay que registrar límites de tamaño, profundidad, tiempo, memoria, expansión y acceso externo, además del comportamiento ante fallos. Un documento puede ser gramaticalmente correcto y operacionalmente inaceptable.

El RFC 8996 actualizó el contexto de RFC 3470 al retirar TLS 1.0 y 1.1. Un canal moderno protege su transporte según la configuración, pero no decide el significado del atributo ni la autorización de la operación.

La cadena que evita otorgar autoridad por apariencia

Conserve octetos y codificación. Identifique el analizador y su política. Registre buena formación y rechazo completo. Capture entidades, base y recursos externos, y después el infoset.

Nombre el esquema y la validación. Registre los nombres expandidos, la política de extensiones y cualquier transformación. Fije canonización, referencias de firma e identidad verificada.

Después vienen semántica, autorización y estado anterior. El commit y el resultado autenticado son recibos propios. Para afirmar interoperabilidad, repita con acceso externo desactivado y otra implementación conforme.

Límite de la evidencia

Este artículo no atribuye un fallo a un producto ni afirma que todo XML use recursos externos. Tampoco sostiene que validar o firmar carezca de valor. Acota lo que cada control demuestra.

No repite el artículo existente de BTW sobre YANG/XML, cuyo objeto es el árbol YANG efectivo, los valores por defecto, las revisiones, el montaje, el datastore y el efecto de red. Aquí se estudia la autoridad genérica entre nombres XML y una acción de aplicación.

La especificación inicial mínima y la primacía del código en funcionamiento de Heng Lu son lentes editoriales declaradas. Favorecen reglas comunes solo donde la interoperabilidad lo exige y recibos del sistema ejecutado. No son datos de despliegue.

La conclusión es concreta: un espacio de nombres organiza vocabulario. Solo el protocolo, la autenticación y la autorización pueden convertirlo en permiso.

Sources