Herramientas de desarrollo · Convertidores de sintaxis
XML de SGML: por qué tiene atributos, espacios de nombres y DTD Las rarezas de
· Antecedentes
xml formatos de datos seguridad
XML (atributos versus elementos, espacios de nombres, DTD, contenido mixto) tienen sentido una vez que sabes que fue diseñado como un SGML simplificado para documentos, no para datos. Esta publicación rastrea ese linaje y lo que significa cuando conviertes XML en JSON.
¿Por qué este formato de datos tiene atributos? — un desarrollador que convierte XML en JSON y cumple con una distinción JSON que nunca fue necesaria
JSON tiene un tipo de propiedad de objeto; XML distingue atributos, elementos secundarios y texto. ToolAcre asigna esa distinción con atributos `@` y claves secundarias ordinarias. La diferencia es visible cuando un elemento tiene `id="7"` y un hijo `<id>`: ambos sobreviven bajo propiedades separadas.
Esta convención explica la forma resultante sin afirmar que los atributos tengan una función semántica universal. XML autores los eligen según sus propios esquemas. El convertidor conserva la categoría de nodo que puede observar, no el motivo comercial por el que se eligió.
SGML y la tradición de los documentos: ISO 8879, marcado para publicación y la idea de etiquetar texto en lugar de codificar registros
El contenido mixto, los elementos secundarios ordenados, los atributos, los comentarios y las instrucciones de procesamiento son características orientadas a documentos presentes en la fuente XML. La implementación demuestra su manejo, pero no contiene evidencia de la cronología SGML, el historial de publicaciones ISO o las motivaciones de la industria editorial.
Por lo tanto, un artículo vinculado al código fuente comienza a partir de un comportamiento ejecutable. El texto alrededor de los elementos secundarios tiene pérdidas; se eliminan los comentarios y las instrucciones de procesamiento; CDATA permanece marcado. Esos hechos explican por qué un árbol de documentos no encaja perfectamente en un árbol de valores JSON.
Funciones XML orientadas a documentos visibles en la implementación, sin un reclamo de historial SGML
El analizador valida XML bien formado e informa la línea y columna. Ignora la declaración en el valor resultante y conserva las cinco entidades integradas y las referencias de caracteres numéricos como texto decodificado. No establece objetivos de grupo de trabajo ni una cuenta de diseño de diez principios.
Las afirmaciones históricas necesitan fuentes editoriales externas, que esta tarea no agrega. Omitirlos es más preciso que inventar el cumplimiento o la procedencia a partir del nombre de una dependencia.
El analizador maneja la sintaxis XML; la evidencia del repositorio no establece el historial de diseño 1998
Los atributos se convierten en claves con el prefijo `@`; Los elementos conservan sus nombres. El texto dentro de un elemento estructurado se mueve a `#text`, mientras que un elemento de solo texto se contrae en una cadena. Esto mantiene separadas las categorías estructurales en la medida en que lo permite un modelo de objetos.
Escribir XML invierte la convención: `@id` se convierte en un atributo. Los nombres de atributos o elementos no válidos se rechazan en lugar de desinfectarse. Esa decisión evita que un mapeo con formato incorrecto se vuelva plausible XML con nombres silenciosamente alterados.
Los atributos y elementos permanecen distintos según la convención @ de ToolAcre
Los prefijos de espacios de nombres se conservan palabra por palabra en los nombres de elementos y atributos, incluidas las declaraciones de espacios de nombres. No se resuelven, eliminan ni reescriben. Esto conserva la ortografía original pero no es una resolución de tipo que tenga en cuenta el espacio de nombres.
Cada DOCTYPE se rechaza antes de que fast-xml-parser reciba el documento. La máscara evita coincidencias falsas dentro de comentarios y CDATA. Esto evita solicitudes de entidades externas, lecturas de entidades de archivos locales y ataques de expansión de entidades, sin opción de evitar el rechazo.
Los prefijos de espacio de nombres se conservan literalmente y se rechaza cada DOCTYPE
En `<p>before<b>bold</b>after</p>`, la ubicación del texto es importante. ToolAcre detecta contenido mixto, une fragmentos bajo `#text` y advierte que sus posiciones relativas a los niños se pierden. Las propiedades del objeto JSON no pueden reproducir una secuencia ordenada de texto alternativo y nodos de elementos.
Los hijos repetidos con el mismo nombre se convierten en matrices, pero los hermanos con nombres diferentes siguen siendo propiedades. El código que requiere un orden exacto de los documentos debe utilizar una representación de nodo XML en lugar de tratar el objeto convertido como completo.
Lo que esto no cubre: XSLT, XPath y XQuery, los lenguajes de procesamiento que crecieron alrededor de XML
XSLT, XPath y XQuery no se importan ni se exponen. El panel tampoco valida XSD, procesa declaraciones DTD ni construye objetos de dominio tipificados. Es una proyección de datos con límites explícitos de seguridad y fidelidad.
Un lenguaje de consulta o transformación puede preservar y navegar por el orden de los nodos de maneras que esta conversión de valores simples no puede. Elija esas herramientas cuando las características del documento sean parte del trabajo en lugar de un embalaje incidental.
Conclusión: XML es un formato de documento que aprendió a transportar datos y cómo el panel de convertidores de sintaxis muestra lo que sobrevive a su traducción a JSON El modelo de datos observables de
XML incluye distinciones ausentes en JSON. ToolAcre marca atributos, CDATA y texto estructurado, conserva prefijos de espacios de nombres, elimina nodos que no son de datos y rechaza DOCTYPE. Cada elección es visible y probada.
Utilice el panel para saber qué sobrevive a una proyección, no como autoridad histórica o como procesador XML completo. Cuando el orden, los esquemas o la semántica del espacio de nombres son importantes, mantenga el árbol original y utilice herramientas XML especialmente diseñadas.
La seguridad y la fidelidad también se cruzan en el límite DOCTYPE. Rechazar la declaración impide el procesamiento de la entidad, pero eliminarla de un documento heredado arbitrario puede cambiar las referencias de la entidad o los supuestos de validación. Si es propietario de la fuente, reemplace las entidades requeridas con texto seguro explícito y valide el documento resultante. Si no es el propietario, utilice un flujo de trabajo XML aprobado en lugar de debilitar el rechazo o presentar una conversión parcial como contenido original.