Tim有一篇有趣的帖子，这篇帖子比较了JSON和XML。他的比较让我对其中的一些细节产生了兴趣。

就这篇帖子，我有一些具体的提问：

1、我没有找到为什么JSON比XML拥有不同的流特性的原因。我所编写的每个JSON分析器都在底层有一层用于流的输入输出，并且就像大多数时兴XML栈一样，拥有一个针对上一层的延迟缓存机制(和类型映射)。那为什么说XML天生就更适于流处理？

2、正如在注释中，Joe Gregorio针对Tim的贴子的阐述，我也偏好JSON只允许基于UTF格式编码的简化。

3、Tim阐述道当遇到处理数据顺序的情况时使用XML，但是JSON拥有一个完美的顺序排列器(数组)，可以被用于很多情况。

4、我也没有购买JSON，这不是什么题外话。没有什么东西可以阻止JSON价值的追捧者忽略没有意义的字段标签。当然，这需要通过使用惯例来避免名称空间冲突，但是我不信在同XML的名称名称生存了几乎10年之后，这种做法还是一件糟糕的事情。

5、至于在文本处理上，(相对于XML)我喜欢JSON。你可以巧妙地区分数字和看起来像数字的文本，并且更加重要的是，你可以在无需恢复到base64编码的情况下，表示含有控制符的字符串。当然，我还是没有拉下有意义的空白和无意义的空白之间的不明确性。对于JSON来说，那很明确，来自于数据本身。对于XML来说，你需要DTD或schema来确定。Tim肯定就是Text先生，所以我很肯定他一定会告诉我要想要这些东西是错误的想法。

6、至于产出能力，我没有看见这与{ “FirstName”: “Tim”, “LastName”: “Ewald” }XML的等同部分(我应该在这将它打出来，但是对于我这一生，我都不能让.TEXT正确的逃脱万物的束缚)相比有多差劲。当然，我能将XSLT应用于后者来产出HTML，但是如果我是一个Swing、AWT、User32或者是Avalon用户又会怎样呢。

简而言之，我想XML对于JSON最大的优势在于它的惯性。在XML这里，有一大堆处理它的工具和一大堆以XML为载体的数据。

要取代XML，JSON还要翻过一座大山。它的归宿是新的、不再拥有Javascript/Browser组件的应用程序(感谢Dare)

上面所述的立场中，有它的简单性和流行趋势因素在里面。