Kurt Cagle是XML Today的总编，也是O’Reilly传媒、DevX和TechNewsWorld新闻网的特约编辑。目前，他正与Diane Mueller一起为O’Reilly传媒编写《XBRL通用知识》一书，此书将于2010年年初出版。Cagle先生自己还经营了一家咨询公司，即Metaphorical Web。该公司主要从事未来技术问题、XML、分布式计算技术等业务。

最近，我一直在研究以XBRL技术报送的大量原始文件，这既是为编写此书而进行的研究工作，也是因为我对该技术的兴趣不仅来自于其作为会计格式的使用，更是由于它是一种XML格式。不管从哪方面考虑，我想这是一个不同寻常的观点。会计人员把XBRL“文档”看作为某公司的一组“事实”材料，而且基本上不关心该格式内在的表现形式，因为他们认为所有的东西都是一样的，这种表现形式只是一种“编码”。

从另一方面讲，XML程序员对XBRL文档的看法则稍有不同。大多数XML程序员并不是该领域的专家（他们只是在他们自己的工作领域中使用此编码）。对他们来说，XML是能够查询、改变、重构的语言，而且还具有不同的外部表征……也就是能够在网上发送并存储在专门的数据库中的特征。在大多数情况下，具体的要素名称一点都不重要。也正是XML结构广泛的特点使其变得越来越重要。

然而，XML研发者对XBRL的看法则十分严格。XBRL被故意设计为拥有尽可能少的结构，而其大多数结构是通过链表的形式加进去的。当然XBRL的结构的确是存在的，但是全部都是指示性的。例如，XBRL有语境的概念，在语境中的每个报告数据项目都有一个语境属性，即指向一个对应的数据结构，而该数据结构能够提供详细的语境信息：报告时期、报告机构以及报告准备者的详细信息等等。所有的XML编辑器都有可能利用一个适当的标记将所有相关语境的关键信息隐藏在其所载的要素中，之后所有横跨语境的要素都将注明主要语境（如引用文档中的ID属性）的来源。

同样，链接库（XBRL的一个重要特点）中混杂了大量的信息，这些信息需要进行处理，然后以一种更为有效的形式存储在内存中，尤其是涉及对三至四个等级链接的解析过程的信息。然而，在某些领域中，如标记领域（最有可能的情况是每个架构具有多个标记），一般来说能更好的解决定位问题的方法是拥有多个本地化文件，每个文件所使用的语言都不同，而且在架构名称及以该语言对其所有项目进行标记之间包含一对一的直接映射关系。当出现多种情况的时候，我们能够通过次级属性对XML做相应的修改，以辨明该信息。

两种情况下的想法都是一样的。如果允许多个潜在的可替换的XBRL展示方式存在，那么通过可接受的XSLT转换，每个XBRL展示方式在修正后都能够成为规范的格式，而不会造成任何一个展示方式的损失。从网络研发者的立场来说，这种可替换的展示方式可以极大地降低XBRL文档的大小和复杂性。某些情况下，在欧洲尤指涉及银行间的信息传输的情况，链接库的多面属性满足了超立方处理的十分现实的需求。在类似情况下，使用其他格式或许行不通。但是，大多数情况下（如SEC报送的数据），规范的XBRL技术所使用的多维性链接有点过度，而且在网络上的使用效果实际上并不是很理想。

这就需要其他的含义。目前十分复杂的功能最终将被更简单的格式所替代，尤其是如果您能够将它们与具体的展示方式（对于即将使用的格式可能是非常合适的）相联系的话。例如，一个XQuery的展示方式尤其适合存储在XML数据库中的XBRL技术。同样的方式，该方法可以用于创建带有脚本语言功能数据的JSON表示形式，这非常有助于引起Web 2.0用户对XBRL技术的兴趣。

XBRL语言有许多处理最复杂的案例应用的机制，但是，它必须能够在那些案例中同比缩减，并且无需进行复杂的处理。没有XBRL语言，其他潜在的标准（如美国国家信息交换模式，或简称为NIEM）可能很快就会过时。（在以后的博文中，我将讨论基于NIEM的XBRL技术。）

同许多标准一样，XBRL的技术及要求也是变化的，否则它就存在僵化的可能，从长远角度来说，这对任何一方都没有好处。