XML 源自 SGML：为什么它有属性、命名空间和 DTD

为什么这种数据格式有属性？ — 开发人员将 XML 转换为 JSON 并满足从未需要的区别 JSON

JSON 有一种对象属性； XML 区分属性、子元素和文本。 ToolAcre 将这种区别映射到 `@` 属性和普通子键。当元素同时具有 `id="7"` 和 `<id>` 子元素时，差异是可见的：两者都在不同的属性下生存。

这一约定解释了结果形状，但没有声明属性具有一个通用语义角色。 XML 作者根据自己的模式选择它们。转换器保留它可以观察的节点类别，而不是选择它的业务原因。

SGML 和文档传统 — ISO 8879、发布标记以及标记文本而不是编码记录的想法

混合内容、有序子项、属性、注释和处理指令是 XML 源中存在的面向文档的功能。该实现展示了它们的处理方式，但不包含 SGML 年表、ISO 出版历史或出版业动机的证据。

因此，受源代码限制的文章从可执行行为开始。子元素周围的文本是有损的；评论和处理指令被删除； CDATA 保持标记。这些事实解释了为什么文档树不能完全适合 JSON 值树。

面向文档的 XML 功能在实现中可见，没有 SGML 历史声明

解析器验证格式正确的 XML 并报告行和列。它忽略结果值中的声明，并将五个内置实体和数字字符引用保留为解码文本。它没有建立工作组目标或十原则设计账户。

历史主张需要外部编辑来源，此任务不会添加这些来源。省略它们比从依赖项名称发明合规性或出处更准确。

解析器处理 XML 语法；存储库证据未建立 1998 设计历史

属性成为前缀为 `@` 的键；元素保留其名称。结构化元素内的文本移动到 `#text`，而纯文本元素则折叠为字符串。这使得结构类别在对象模型允许的范围内保持分离。

写入 XML 会颠倒约定：`@id` 成为属性。无效的属性或元素名称将被拒绝而不是被清理。这一决定可以防止格式错误的映射变成带有悄悄更改名称的看似合理的 XML 。

在 ToolAcre 的 @ 约定下，属性和元素保持不同

命名空间前缀在元素和属性名称中逐字保留，包括命名空间声明。它们没有被解决、删除或重写。这保留了源拼写，但不是命名空间感知的类型解析。

在 fast-xml-parser 接收文档之前，每个 DOCTYPE 都会被拒绝。该掩码可避免注释和 CDATA 内的错误匹配。这可以防止外部实体请求、本地文件实体读取和实体扩展攻击，并且无法绕过拒绝。

命名空间前缀按字面保留，每个 DOCTYPE 都被拒绝

在 `<p>before<b>bold</b>after</p>` 中，文本放置很重要。 ToolAcre 检测混合内容，将片段连接到 `#text` 下，并警告它们相对于子项的位置丢失。 JSON 对象属性无法重现交替文本和元素节点的有序序列。

重复的同名子级成为数组，但不同名称的兄弟级仍然是属性。需要精确文档顺序的代码应使用 XML 节点表示形式，而不是将转换后的对象视为完整的。

这不包括什么 — XSLT、XPath 和 XQuery，这些围绕 XML 发展的处理语言

XSLT、XPath 和 XQuery 不会导入或公开。该面板也不验证 XSD、处理 DTD 声明或构造类型化域对象。它是具有明确安全性和保真度边界的数据投影。

查询或转换语言可以以这种纯值转换所不能的方式保留和导航节点顺序。当文档功能是工作的一部分而不是附带的打包时，请选择该工具。

要点：XML 是一种学会携带数据的文档格式，以及语法转换器面板如何显示翻译成 JSON 后仍保留的内容

XML 的可观察数据模型包括 JSON 所没有的区别。 ToolAcre 标记属性、CDATA 和结构化文本，保留命名空间前缀，删除非数据节点并拒绝 DOCTYPE。每个选择都是可见且经过测试的。

使用面板来了解投影后的内容，而不是作为历史权威或完整的 XML 处理器。当排序、架构或命名空间语义很重要时，请保留原始树并使用专用的 XML 工具。

安全性和保真度也在 DOCTYPE 边界处交叉。拒绝声明会阻止实体处理，但从任意遗留文档中删除它可能会更改实体引用或验证假设。如果您拥有源代码，请使用显式安全文本替换所需的实体并验证生成的文档。如果您不拥有它，请使用已批准的 XML 工作流程，而不是削弱拒绝或将部分转换呈现为原始内容。