嗯，我承认我学东西比较慢。

FINREP分类标准引发了我对一些事情的思考。有人问过我这样一个问题：“有没有一个可以帮助商业用户浏览分类标准的展示链接库？”我一开始感到非常震惊。竟然会有人发布一个没有展示关系的分类标准？没有展示关系，你怎么可能阅读分类标准？

自动生成定义链接库

我 开始进一步思考这个问题，我想：“难道我们不能只通过所提供的定义链接库就生成一套有用的展示关系吗？”我之所以有这种想法是因为当我们创建美国通用会计 准则分类标准的时候（我是创建这个分类标准的小组的组员之一），我们就是通过展示链接库自动生成定义链接库的，而不是两个都手动创建。

如果你看一下美国通用会计准则分类标准展示链接库（这里有一个），你就可以看见标签里的元数据。比如附加在标签末端的“[表]”、“ [轴]”和“ [行项]”这些东西。同时，关系的组织方式也解释了有关信息模型的事情。美国通用会计准则分类标准架构解释了附加在标签末端的这些东西，并且解释了这些关系是如何组织起来的（见第4.5部分）。之所以开发出这种“记录”关系（在美国通用会计准则分类标准中称为“类型”）的方法就是为了让人们把这些关系看得更加清楚。

因此从本质上说，展示链接库中细心组织起来的东西和验证功能能够确保你是正确的，能够让你通过展示链接库自动生成定义链接库。美国通用会计准则分类标准绝对保证，展示链接库和定义链接库之间是100%一致的。因为展示必须正确，才能正确的生成定义链接库。

看法180度转变

当我真正开始思考这个问题的时候，我意识到定义链接库的元数据非常严谨，并且由XBRL强制执行。当你在展示链接库（像美国通用会计准则分类标准）表达关系信息的时候，你必须建立验证来强制执行这些关系。然后我想到了计算链接库。这里也有元数据。在XBRL公式链接库中同样有关于计算关系的元数据，这就意味着前滚中（运动分析）的计算关系是必须的。

这时我才恍然大悟！首先，人们可以通过定义链接库、计算链接库和XBRL公 式信息（用于表达不能在计算结果关系中表达的计算关系）中所包含的元数据生成一个像美国通用会计准则分类标准那样的展示链接库。你不仅可以自动生成一个像 美国通用会计准则这种类型的展示关系，你还可以生成任何你想要的展示“方案”。所有的展示关系都在一个真正的“信息模型”中。展示关系自身并不是信息模 型，元数据才是信息模型。从本质上说，我所犯的错误是把展示关系当成了信息模型。

可以“实质上”创建展示

分 类标准并不需要一个“展示链接库”。它们所需要的是一种能够让商业用户浏览分类标准的方法。对于我来说，这似乎就是把分类标准中的元数据组织成某种有用的 形式。我可以阅读这些“树视图”解释。现在的软件都是这样子，所以我必须学习怎么看树视图。但一般的商业用户永远都不会和这些树视图扯上关系，而且也没有 这个必要。比如可以想一下，大部分分类标准工具所展示的由上往下的计算关系是怎么样的？甚至是XBRL计算验证报告所展示的又是怎么样的？为什么不能像现在的会计师一样，在报告的底部用双下划线表示总计，单下划线表示小计呢？

恩，它是可以的。

“编辑展示链接库”、“编辑计算链接库”和“编辑定义链接库”这些想法全都是被误导的。这是因为我们过多的从XBRL的角度进行考虑，而从商业报告角度进行的考虑并不足够。这是错误的。

一 个信息模型重要吗？当然！这就像一个数据库方案是重要的，一个好的数据模型是重要的一样。你的确需要了解这些数据和遵守良好的数据建模惯例。但一些被设计 出来的展示并不重要。你可以设计出无数不同的，用于浏览这些信息模型的方式，树视图却只有一个。展示链接库也可以表示为树视图。但是信息模型和查看信息模 型的方法是两码事。

商业用户需要软件销售商提供更有创造性的界面。为此，我们需要一致性更强，结构更好的分类标准。

其他可能存在的问题

我可以找出一大堆潜在的问题。计算中的比重看起来不会是什么问题，但却可能成为一个问题。对于我来说，它更像是一个展示问题，而不是能否正确解释分类标准元数据的问题。虽然对定义链接库的层次没有什么限制，但它有可能会是一个问题。为前滚创建XBRL公式可能是一个问题，但我觉得不是。在一个软件界面中真正要表达的是这么一个事实：两个概念之间存在着前滚关系。同样，XBRL公式也是可以自动生成的。

关键

商业用户，你会关心这些。这一切都是为了更易于理解和使用XBRL。这不是很好吗？问一下软件销售商，为什么他们强迫你掌握XBRL语法？