David vun Kannon曾任XBRL规范工作组第一任联合主席，参与编辑了各个版本的XBRL技术规范。目前，他是德勤会计师事务所技术和知识管理部总监。

Kurt Cagle日前在本博客上发表文章探讨呈现XBRL的其他方法。文中，他坦率地承认，他的观点关注于XML语言设计而非某一领域的专业知识。在回应对该文的一篇评论中，他这样写道：

XBRL就是XML，不是什么奇怪的变体；目前市面上已经出现了可以免费获取、功能强大、且比现有试图将XBRL转化为其自身元语言的繁琐的解决方案更好的工具。如果XBRL国际组织委员会能够承认上述这些显而易见的事实，那么许多令他们头痛的问题都可以迎刃而解。

Kurt曾表示，即使并不十分了解某项设计试图解决什么商业问题，也可以对其作出影响深远且富有洞察力的评论。从一开始，我就对他的这种观点感到惊讶。事实上，在XBRL的应用初期，该商业问题涉及的面就很广，其目标是开发出可以应用于信息供应链中每个环节的专门用于商业报告的语言。

XBRL对数据进行的区分意义重大。商业报告数据呈现双峰分布的特点。一部分数据是事实数据，由众多的报告者编写，每期都在变化。另一部分数据是与事实相关的元数据，主要由数据源（而非事实编写者）提供，变化较少。但事实编写者必须有能力编写并整合其自己的元数据，而多种元数据系统也必须能够被相互关联。简言之，这就是XBRL一直以来想要解决的商业问题。

事实本身确实包含上下文元数据，而XBRL为解决该问题所作的设计也一直在更改。随着维度XBRL的兴起，我渐渐相信，我们在上下文元数据上所做的工作并不完美。上下文能够在许多事实间实现分享，但设计差强人意。而维度XBRL实例文档可以实现一个事实与一个上下文的对应。

但Kurt表示：

……XBRL有一个上下文的概念，每一份特定报告中的所有数据项都拥有一个上下文属性，这种属性指向相应的数据结构，该数据结构将传达有关上下文的细节信息，如报告期、报告单位、报告编制者的详细信息等。每一位XML设计者都可能通过使用一个合适的标识符将有关上下文的所有关键信息融合为一个嵌套元素。而所有跨越上下文的元素都会将原始上下文视为一个IDREF。

坦白地说，我并不十分理解他的意思。目前，我们使用IDREF属性来参考上下文，而他的建议除了在操作方法上有所不同外，我实在看不出有什么过人之处。

对于XBRL在针对元数据上的设计来说，分类标准的设计是以XML Schema和XLink为基础的。我始终不愿意牺牲可以进行schema验证的即时价值去换取将来（十年后）可能获得的更高价值，即将来我们可能会使用RDF/OWL等语义技术。XML Schema、XLink和XML Namespaces都有其自身的缺陷，我很希望看到这些缺陷被解决。因为其中任何一个缺陷的解决都将为采用RDF/OWL的XBRL使用者提供更高的价值。

所以，“承认显而易见的事实”是什么意思？我所看到的事实是：XBRL是一种以XML语法编写的数据库传输格式。适合人们阅读并不是它的首要目的。在对这一点有所认识的应用领域里（如许多银行业系统），XBRL都取得了巨大的成功。而在一些大型安全监管机构里，XBRL并不容易被接受，应用进展缓慢，因为他们既需要进行数据传输又要求数据适合人们阅读。

作为非专家用户的经验积累，网络是否已经（或应该）为XBRL的设计和技术做出了选择还不明朗。这也是我在回应Tim Bray对XBRL和RSS的技术接受周期进行比较时所持的观点。我认为他们没有可比性，不仅仅因为他们都是XML。无论在设计、关注的问题，还是应用路线上，XBRL更接近RDBMS（关系型数据库管理系统），而非网络。

关键不在于数据库供应商对XBRL的设计做出了多大的贡献，而在于选择解决哪种商业问题。对于XBRL来说，取代CSV文件和Excel电子数据表成为符合企业文化要求的数据传输格式比选择另一种语法进行表达更重要。

在多种语法选择的问题上，区别替代性语法和多元化语法至关重要。企业文化需要在各方面超越现有状况，做到和现有状况一样好远远不够，它必须在各方面都超越现有状况，比它好得多，才能取代现有状况。而多元化语法容易令使用者产生混淆。语言设计的一个基本原则是，能够用一种方法解决的问题绝不考虑用第二方法。

的确，XML与其他一些格式只存在样式表上的不同。但数据交换格式过多会严重削弱每一种交换格式的应用价值。还会引发可执行代码（样式表）和数据交换方面的问题。

如果如Kurt所想XBRL就是XML，那么XBRL中就不会出现XLink。XML schema将成为一种特殊的与包容层次结构相匹配的包容结构，使上千份公司报告载入监管机构数据库的过程变得更加简单。那么我要问，这种包容层次结构是谁选择的？报告载入过程的简单化又是如何做到的？

哦，我忘了，这些都是显而易见，不言而喻的。