XML优于S-expressions（-ish）表示法的优点是什么？

我想问一个关于XML和S-expressions（-ish）表示法的问题。S表达式很老。他们也很简单。我们可以考虑两种含义相同但语法不同的形式：

（来自波兰维基百科的 xml代码）

<?xml version="1.0" encoding="UTF-8"?>
<ksiazka-telefoniczna kategoria="bohaterowie książek">
 <!-- komentarz -->
  <osoba charakter="dobry">
    <imie>Ambroży</imie>
    <nazwisko>Kleks</nazwisko>
    <telefon>123-456-789</telefon>
  </osoba>
  <osoba charakter="zły">
    <imie>Alojzy</imie>
    <nazwisko>Bąbel</nazwisko>
    <telefon/>
  </osoba>
</ksiazka-telefoniczna>

S-Expression（-ish）版本：

(:version "1.0" :encoding "utf-8")
(ksiazka-telefoniczna :category "bohaterowie książek"
  ; komentarz(a comment)
  (osoba :charakter "dobry"
    (imie Ambroży)
    (nazwisko Kleks)
    (telefon 123-456-789))
  (osoba :charakter "zły"
    (imie Alojzy)
    (nazwisko Bąbel)
    (telefon)))

S-Expression版本更为简洁。我们通过使用简单的列表符号来避免冗余，但是我们仍然可以定义语法以包括我们想要拥有的东西（例如属性）。当然，这只是一个例子，实际的标准可能更好或更简单。但是，它更短且更容易解析。XML为什么赢了？

我们知道XML的设计人员熟悉S表达式，因为XML基于SGML，并且SGML具有样式表语言DSSSL，该语言使用S表达式语法（以及作为嵌入式脚本语言的方案）。

但是，由于XML的用例，他们选择了与S表达式不同的语法。XML最初被设计为既支持机器生成的结构化数据，又支持诸如HTML之类的标记语言，它们是手动编写的，并且包含混合内容（文本与带有元数据的元素混合在一起）。

冗余

标记文本文档通常比屏蔽文本文档更长。如果看到a )并且看不到结构的开始，那么您很迷失；您不知道是结束的章节还是侧边栏。像XML那样在末端标签中重复标记名的冗余性</sidebar>使人工编写者容易得多。它还使它更加健壮：如果不小心删除了结束标签，则通常可以推断出缺少哪个结束标签。

SGML（XML的前身）使您可以选择将结束标签缩短为单个字符，但是为简单起见，此功能未包含在XML中。

简而言之，XML在设计上更加冗长，因为它旨在支持人类可编辑的文档。如今，XML被用于各种各样的目的，也用于不需要这种冗余的纯机器对机器通信。

混合内容

您建议的语法不能很好地支持混合内容。以HTML为例：

<p>Hi! <a href="example.com">Click here</a>!</p>

您将如何用语法表达这一点？您将需要某种其他定界符来区分属性和文本内容。突然，它不再那么简洁了。

特殊字符

在普通文本中，尖括号比括号和冒号少得多。

兼容性

在设计XML时，HTML已经取得了巨大的成功，因此选择类似的语法很有意义。

XML为什么赢了？

S表达式绝不能替代XML。XML规范不仅仅是尖括号。它定义了元素和属性以及混合内容，转义，字符编码，DTD语法和验证等的语法。s表达式没有类似的东西。当然，您可以按照此处的建议定义类似的标准，但是当时还没有人这样做。XML受到W3C的祝福，因此被主要参与者采用，并成为事实上的数据交换标准。

就个人而言，我认为关于XML的最好部分是定义良好的模式功能，而不是其语法。模式机制允许用户发布其文档格式以共享他们认为有效的文档。也有自动验证器。另外，一个用户创建的类型和架构可以被其他用户扩展。

据我所知，除了LISP语言本身（OP问题中的示例未使用）之外，没有人为标准化用于s表达式的通用模式机制做出任何努力。

我选择XML代替“ S-expression-ish”有两个原因：

定义明确的句法和语义模型

XML不仅是节点树，而且是具有不同句法表示和不同行为的分类节点树。例如，具有给定名称的属性对于给定节点可能只出现一次，而子节点可能出现多次。

您可以在通用S表达式之上定义这样的模型。您的示例显示了一种用于对属性和子元素进行分类的方案。添加用于文本，注释和处理指令的语义，您将获得与XML同构的东西。

工装

通过标准的句法和语义模型，您可以构建工具-很多人都拥有。您可以为每种常见的语言/平台找到某种形式的XML解析器/序列化器，XPath和XSLT处理器。而且您知道它们在每个平台上的行为都相同。

还有其他一些要考虑的事项：

在宏伟的方案中，XML不是那么冗长

在您的示例中，您实际上消除了什么？在我阅读时，您已经：

• 消除了每个表达式的结束标记。
• 消除了>通常会将开始标签与其子标签分开的。
• 将=分隔属性名称和值的替换为，:以指示子级是属性；没有积蓄。

我认为认识到XML的内部和外部表示形式非常不同也很重要。在内部，XML树非常紧凑。并且由于各种元素已经分类，因此操作非常有效。是的，从外部看，您会获得所有这些结束标签，但它们的压缩效果很好。

“冗长”是真正的问题吗？

我认为真正的问题不是XML是否“冗长”，而是XML是否比给定目的所需的表达能力更强。一些例子：

• 元素保留属性的能力，这些属性在语义上与子元素不同。对于元素内容的带外信息（例如描述本机数据类型）很有用。但是也许您不需要这样做，因为您的外部规范定义了内容。
• 混合内容，其中元素可以同时包含子元素和文本（以及注释和处理指令）。对于标记很有用，但对于简单的数据表示可能没有用。