为什么XML有结构？

Question

我有一个已发布给用户的XML架构。它有一个相当复杂的结构，但它也有一些通用元素，允许我们添加其他数据而不破坏已发布的结构。

示例：

<record>
    <song>
        <name>thriller</name>
        <artist>Mike</artist>
        <genericData key="year">1980</genericData>
        <genericData key="duration">03:35</genericData>
    </song>
</record>

所以这里我添加了两个genericData元素的年份和持续时间。

我们被要求向我们的结构添加更多数据，并且可能使用这些genericData元素来满足这些需求，但这样做的缺点是什么？我知道它没有为数据保留关系模型（这很糟糕），但还有什么东西会卷土重来咬我们吗？它给我带来难闻的气味。我更愿意为新数据添加特定元素，但是要求改变我们的架构。

Answer 1

“genericData”设计模式经常在XML中出现，但在我看来，它很少是最佳解决方案。我认为人们使用它的一个原因是当他们使用数据绑定工具（如JAXB）时：这些工具使用Java等语言将XML映射到数据结构，而像Java这样的语言无法处理与XML相同的灵活性。没有数据绑定的约束（即如果你使用为作业设计的工具处理XML，比如XSLT和XQuery），我会利用XML的内置灵活性（无需架构，或在架构中使用通配符），也许用命名空间来添加一个规范控制级别：所以

<record>
    <song>
        <name>thriller</name>
        <artist>Mike</artist>
        <m:year xmlns:m="http://me.com/ns">1980</m:year>
        <m:duration xmlns:m="http://me.com/ns">03:35</m:duration>
    </song>
</record>

Answer 2

我想说，在JSON或YAML等相当轻的格式上使用XML的唯一令人信服的理由是XML的模式定义和实例验证功能。虽然有一些例外，例如Play Framework的JSON功能，但您通常无法在这些较轻的格式上强制执行架构。事实上，根据用例，这可以很容易地看作是一个加分。这是＆＃34;无架构＆＃34;的卖点之一。 NoSQL数据库。

如果您放松XML太多以至于架构几乎是偶然的，那么根据您的用例可能完全合法。但如果是这样的话，你就失去了使用XML的唯一令人信服的理由。

我建议你确保你的＆＃34;特殊＆＃34;通用数据的案例确实很少见。放松你必须抵制的规则将有一种自然的倾向。但是如果仔细考虑后你觉得架构限制太多，那么我建议完全放弃XML。只要知道你将把负担转移到你的团队来处理XML中开箱即用的逻辑。