主持人 > 博客 > 管理 > XML 几乎总是被滥用

XML 几乎总是被滥用

XML 几乎总是被滥用
XML 语言于 1996 年发明。 它一出现，它的应用可能性就已经开始被误解，而对于他们试图适应它的目的来说，这并不是最好的选择。

毫不夸张地说，我见过的绝大多数 XML 模式都是对 XML 的不恰当或不正确的使用。 此外，这种对 XML 的使用表明了对 XML 含义的根本误解。

XML 是一种标记语言。 这不是一种数据格式。 大多数 XML 模式都明确忽略了这种区别，将 XML 与数据格式混淆，这最终导致选择 XML 的错误，因为它是实际需要的数据格式。

无需过多讨论，XML 最适合用结构和元数据注释文本块。 如果您的主要目标不是使用文本块，那么选择 XML 不太合理。

从这个角度来看，有一个简单的方法可以检查 XML 模式的制作情况。 让我们以预期架构中的文档为例，并从中删除所有标签和属性。 如果剩下的内容没有意义（或者如果剩下一个空行），那么要么您的架构未正确构建，要么您根本不应该使用 XML。

下面我将给出一些最常见的错误构造电路的示例。

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

这里我们看到一个毫无根据且奇怪的（尽管很常见）尝试用 XML 表达简单的键值字典的示例。 如果删除所有标签和属性，您将留下一个空行。 从本质上讲，无论听起来多么荒谬，这个文档都是空行的语义注释。

<root name="John" city="London" />

更糟糕的是，我们不仅仅将空字符串的语义注释作为表达字典的奢侈方式 - 这次“字典”直接编码为根元素的属性。 这使得元素上给定的属性名称集未定义且是动态的。 此外，它表明作者真正想要表达的只是简单的键值语法，但他却做出了应用 XML 的绝对奇怪的决定，强制使用单个空元素简单地作为使用属性语法的前缀。 我经常遇到这样的计划。

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

这是更好的东西，但现在由于某种原因键是元数据而值不是。 看字典的方式很奇怪。 如果删除所有标签和属性，一半的信息将丢失。

XML 中正确的字典表达式如下所示：

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

但是，如果人们做出了奇怪的决定，使用 XML 作为数据格式，然后用它来组织词汇表，那么他们应该明白他们所做的事情是不合适且不方便的。 设计人员错误地选择 XML 来创建应用程序也很常见。 但更常见的是，他们无意义地以上述形式之一使用 XML，从而使事情变得更糟，而忽略了 XML 根本不适合这种情况的事实。

最糟糕的 XML 模式？ 顺便说一句，奖品为 我见过的最糟糕的 XML 模式， 获取 Polycom IP 电话的自动配置配置文件格式。 此类文件需要通过 TFTP 下载 XML 请求文件，这...一般来说，以下是此类文件的摘录：

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

这不是某人的恶作剧。 这不是我的发明：

  • 元素只是用作附加属性的前缀，属性本身具有分层名称。
  • 如果要为特定类型记录的多个实例赋值，则必须使用属性名称来执行此操作。 有索引的.
  • 此外，属性以 softkey., 必须放置在元素上 <softkey/>, 属性开头 feature., 必须放置在元素上 <feature/> 等等，尽管事实上它看起来完全没有必要，乍一看毫无意义。
  • 最后，如果您希望属性名称的第一个组成部分始终与元素名称相同 - 没有那样的！ 例如，属性 up. 必须附于 <userpreferences/>。 将属性名称附加到元素的顺序是任意的，几乎完全是任意的。

文件或数据。 每隔一段时间，就会有人通过尝试比较 XML 和 JSON 来做出完全奇怪的事情，从而表明他们也不理解。 XML 是一种文档标记语言。 JSON 是一种结构化数据格式，因此将它们相互比较就像尝试比较暖与软。

概念之间的区别 文件和数据。 作为 XML 的类似物，我们可以有条件地获取机器可读的文档。 虽然它的目的是机器可读，但它隐喻地指的是文档，从这个角度来看，它实际上与 PDF 文档相当，后者通常不是机器可读的。

例如，在 XML 中，元素的顺序很重要。 但在 JSON 中，对象内键值对的顺序是没有意义且未定义的。 如果您想获取键值对的无序字典，则元素在该文件中出现的实际顺序并不重要。 但是您可以从这些数据中形成许多不同类型的数据。 文件，因为文档中有一定的顺序。 打个比方，它类似于纸质文档，但与打印输出或 PDF 文件不同，它没有物理尺寸。

我的正确 XML 字典表示形式的示例显示了字典中元素的顺序，而不是 JSON 表示形式。 我不能忽视这个顺序：这种线性是文档模型和 XML 格式所固有的。 有些人在解释此 XML 文档时可能会选择忽略顺序，但争论这一点是没有意义的，因为这个问题超出了格式本身的讨论范围。 此外，如果通过附加级联样式表使文档在浏览器中可见，您将看到字典元素以特定顺序出现，而不是其他顺序。

换句话说，字典（一段结构化数据）可以转换为 n 各种可能的文档（XML、PDF、纸质等），其中 n - 字典中元素可能组合的数量，我们还没有考虑到其他可能的变量。

然而，如果您只想传输数据，那么使用机器可读文档将不会有效。 它使用了一个模型，在这种情况下这是多余的；它只会造成阻碍。 此外，为了提取源数据，您需要编写一个程序。 对于在某些时候不会被格式化为文档的内容（例如，使用 CSS 或 XSLT，或两者），使用 XML 几乎没有任何意义，因为这是这样做的主要（如果不是唯一）原因。到文档模型。

此外，由于 XML 没有数字（或布尔表达式或其他数据类型）的概念，因此以这种格式表示的所有数字都被视为附加文本。 要提取数据，必须知道模式及其与所表达的相应数据的关系。 您还需要根据上下文了解特定文本元素何时表示数字并应转换为数字等。

因此，从 XML 文档中提取数据的过程与识别包含例如形成多页数字数据的表格的扫描文档的过程没有太大不同。 是的，原则上可以这样做，但这不是最好的方法，除非作为最后的手段，当绝对没有其他选择时。 一个合理的解决方案是简单地找到原始数据的数字副本，该副本未嵌入将数据与其特定文本表示相结合的文档模型中。

也就是说，XML 在商业中流行并不令我感到惊讶。 原因恰恰是文档格式（纸上）是业务可以理解和熟悉的，他们希望继续使用熟悉和可以理解的模型。 出于同样的原因，企业经常使用 PDF 文档而不是更机器可读的格式 - 因为它们仍然与具有特定物理尺寸的打印页面的概念相关联。 这甚至适用于不太可能打印的文档（例如 8000 页的 PDF 注册文档）。 从这一点来看，XML在业务中的使用本质上是拟物化的表现。 人们理解有限尺寸的打印页面的隐喻概念，并且理解如何基于打印文档创建业务流程。 如果这是您的指南，那么没有物理大小限制的机器可读文档（XML 文档）代表了创新，同时也是一种熟悉且舒适的文档对应物。 这并不能阻止它们仍然是一种不正确且过于拟物化的数据呈现方式。

迄今为止，据我所知，唯一可以真正调用该格式的有效使用的 XML 模式是 XHTML 和 DocBook。

来源： habr.com

添加评论