背景的
我正在研究当代Web应用程序中消息传递的效率，研究XML替代品的使用。这是一个大学项目，其结果将公开发布 - 社区的参与度越大，所得到的结果的价值就越大。
我需要尽可能多的实际使用XML示例，以便：
问题
你如何在Web应用程序世界中使用XML？
当主机B通过HTTP将XML结构化数据返回给主机A时，会出现什么情况？这可能是在AJAX环境中返回数据的服务器，也可能是从一个或多个其他服务器整理数据的服务器。
理想的答案包括：
我更喜欢来自您已经>制作，开发或工作的应用程序/服务的示例，但欢迎任何示例。从5行XML文档到10,000行怪物的任何东西都会很棒。
你自己对你的例子中使用XML的看法也很棒（例如我们实现了XML结构化的响应，因为要求X / Person Y，尽管我认为JSON会更好，因为...;或者，我们使用XML来做到这一点是因为[非常好的理由]而且它只是这项工作的最佳选择。
更新
我非常感谢关于XML主题的所有答案，但我真正想要的是包含XML 的HTTP响应主体的现实例子。
我目前非常了解XML的历史，可能存在哪些常见替代方案，以及它们如何在功能和适用性方面与特定方案进行比较。
如果目前在HTTP主机之间的数据交换中使用XML当前是如何使用XML的，那么无论当前使用情况是正确还是合适，都会给人留下深刻印象。 XML被误用的情况的示例与正确应用XML的情况一样有价值。
答案 0 :(得分：3)
我尽量不要使用它。它绝对是一个架构中的传输协议，客户端和服务器彼此不了解并且是独立实现的 - 或者是独立于任何客户端开发的API。它在持久性中也有一个适用相同推理的地方，而且我在该领域的反对意见远远不够。
但是，如果客户端和服务器是由同一个团队实现的，那么以人类可读的形式在两者之间来回翻译几乎没有意义，并且几乎总是有更快，更便宜（在处理方面）的替代方案即使客户端和服务器技术不同。
集中我对传输协议的评论，在XML到达“糟糕”的旧客户端/服务器之前，当带宽和处理能力很宝贵时，建筑师的工作就是设计一个协议（通常是二进制的）在数据包大小最小化的情况下，效率和速度的唯一工作。明显的限制是握手是非常具体的，除非它被公布，否则二进制方言是难以理解的。从好的方面来说，它非常高效，可以针对手头的应用进行高度优化。通常发布二进制格式（您是否看过旧的Excel BIFF规范 - 不是协议，而是发布二进制格式的示例）。
HTTP中的XML，即SOAP，打破了这一点。基本原理非常合理，有一个普遍理解的握手协议，一种计算机Esperanto，因此您可以将您的客户端和服务器架构分开，并完全分开决定它们的开发速度和内部结构。更重要的是，通过承诺切换客户只是实施新客户的要求，您可以面对未来的客户需求。更重要的是，允许任何带有XML解析器的Joe使用您的API。所有伟大的东西，并导致了非常好的标记架构 - 这完全是好的。
因此，在很大程度上，这个命题的力量已经显现出来并且显然有优势，但是我认为a）这个要求经常被夸大了; b）XML协议通常非常荒谬，并且很少考虑到他们暗示的加工成本。最初理智的推理已经让位于极端主义宗教的情况（我打赌我被拒绝了），我看到代码在同一个类中的函数调用之间传递XML，完全使用未来的证据理由和功能分离的论点，显然是疯狂的。
所以我的口头禅是使沟通高效和有效。如果这意味着为任意和未知的消费者提供通用的API和协议，那么XML是一个非常好的选择。如果它意味着制作闪电般的，可扩展的客户端/服务器（即Web）架构，那么我尝试使用二进制协议，经常自己滚动。
JSON的出现证明了这样一个事实，即XML的潮流层次太多了。 JSON试图缩短结构元素，同时保持通用性，从而获得较小数据包的好处。像Adobe AMF这样的协议通常很多更紧凑，几乎完全是二进制的。
这就是我认为未来可能存在的地方。我确信可以保留XML代表的所有上端用于接口的发布，但是能够显着地减少它并减少处理器和带宽 - 至少这是我作为开发人员和架构师的使命。
想象一下，如果您的平均客户端/服务器请求是大小的十分之一，并且两端都没有文本解析，但您保留了接口的通用性。我不知道任何开发人员不会接受这一点。
答案 1 :(得分：2)
可能不是你想要的答案，但我从不使用XML，它太复杂了（不管怎样我的简单需求），但即使我的需求很复杂，XML也太复杂了，它让我害怕在一个复杂的问题。
答案 2 :(得分：2)
我的建议是跳过XML并查看更简单的JSON。 XML只提供两件事：
1）序列化复杂数据的“标准化”方式 2）验证（通过DTD）上述序列化的正确性的方法
注意“标准化”是引号。唯一标准化的是格式化标签的方式。标签的含义根本不是标准。最后，XML给你的唯一东西是一个很好的解析器，你不必自己编写。
如果您传递的数据可以表示为简单的字符串，数组或关联数组（或哈希），那么XML就太过分了。
答案 3 :(得分：1)
我建议您也学习JSON，它是XML的替代品，并且因其紧凑性而被广泛使用。
答案 4 :(得分：1)
不幸的是，出于商业/法律原因，我无法向您提供任何实际数据。
根据我的经验，xml一直是我近年来在90％以上的后端，服务器到服务器通信的标准格式，纯粹是因为使用它的工具的流行，以及大多数开发人员都有一些经验。
谷歌的协议缓冲区之类的东西对于许多任务来说可能更有效，但是大多数具有“企业”经验的程序员已经知道如何使用的格式的便利性和安全性很难做出商业案例。
如果您向外界销售服务，如果您提供基于xml的界面，CIO会更容易销售，CIO会读取“基于xml的网络服务”，CIO说“很好，我的团队知道......” / p>
Xml并不总是（有些人认为永远不会）这项工作的最佳工具，但它的无处不在，以及使用它的现有代码库和技能组（好的，坏的和平庸的）的数量，往往把它推到头上候选队列。
答案 5 :(得分：1)
我不认为XML是一种字节有效的语言，但这不是它的用途。 XML提供的是可以构建协议的良好基础结构。对于我所使用的产品，我们使用SOAP来发送和接收业务数据到我们无法控制的外部系统，但接受SOAP是一种健全的通用消息传递协议。同样，我们使用SAML断言在系统之间交换授权数据。
答案 6 :(得分：1)
我已多次在Web应用程序中使用XML。它一直通过SOAP Web服务。这是因为我在Visual Studio中编程，它对SOAP Web服务有很好的内置支持。它自动生成OOP包装器，允许从AJAX（客户端）和.NET（服务器端到服务器到服务器通信）轻松使用它。
我不认为我可以发布任何例子，但我认为它不会发生太大变化。
答案 7 :(得分：1)
我将给出两个使用XML满足的需求示例：
我们需要传达从许多UNIX服务器收集的有关文件分配的数据，并将详细信息发送到Windows服务器进行分析。详细信息和摘要都通过Web应用程序以图形方式显示。
我们需要在单个存储库中存储多种格式的表单响应，以便以后搜索和“回放”。表单在Web应用程序中生成，存储，搜索和播放。
在这两种情况下，我们都需要能够以自定义格式传达松散结构的数据。在这两种情况下，我们都发明了一种通用的XML结构，它易于发送过程生成，接收过程很容易存储（基本上是一个长字符串），搜索和解码，并且很容易被人类阅读和理解，现在都是在我们早已离去之后。我们本可以发明一种除XML以外的语法，但当时没有人能想到更好的东西，而且它对我们起到了很好的作用。我不能分享具体的例子，因为数据被认为是专有的。
答案 8 :(得分：0)
Eucaris是一个用于检索汽车注册数据的Web应用程序。后端使用XSD类型的XML数据来处理请求和响应消息。
答案 9 :(得分：0)
与许多其他人一样，我曾经尝试过使用SOAP和XMLRPC，但发现浏览器支持非常弱，以至于当MSXML在输入上进行清理时，我需要“回退”在ad-hoc解析器上。早期版本的my netMail application过去常常使用XML，而MSIE对XML解析的速度还不够快。如果你真的有兴趣看到它，我仍然有XML实现。
两个真实世界的例子让人想起 ，就像过去几个月我不得不面对的那样：
在处理Ingram-Micro的XML排序界面时，消息依赖于所有元素的顺序，并且对编码问题非常敏感。根本没有办法使用标准的XML处理工具与之交互。特别的解决方案会更好，因为毫无疑问，元素的顺序是什么。交换是通过推拉方法执行的。我们的服务器将数据发布到IM-XML的端点，并将其服务器POST回数据。
MRIS的XML Feed包含类似＆lt; Data Separator =“〜”＆gt;的行。然后是一堆~ - 分隔数据。这些源很多兆字节，只需采用面向行的读取+拆分而不是“XML”的方法，可以在更少的内存和更快的速度下完成工作。 “XML”数据定期通过HTTP GET下载。
我再也不会使用XML了;总是ad-hoc解析器。我认为XML是一个设计决策，是一个令人难以置信的短视，以及最好天真的的证据，以及其他时间的彻头彻尾的愚蠢。
大多数情况下，我发现在涉及浏览器时使用原始javascript表达式（通常称为JSON）（仅仅因为eval“尽可能快”）和S表达式。
对不起，我无法帮助您处理网络上的任何优秀XML示例;我根本就认为没有。