回头找你的问题变少
少有人再问这个错误是什么意思，答案本来就在结果里。
结构
在同一套本体之上，What、Why、How 一起给出。
多数校验器停在 What。它只说「有问题」，至于为什么、接下来怎么办，全留给收到消息的人。MirrorMere 三样一起给——之所以做得到，是因为这里把 XBRL 整个建成了一套本体。
- What — 哪里出了问题
- 直接点名文档里的哪个位置、哪个值出了问题，而不是丢个错误代码让你自己去找。
- Why — 为什么算错
- 是哪条规则抓到的，那条规则又实现了哪一款条文，一并给出。几个月后审计师来问，这就是答案。
- How — 那该怎么办
- 写的不是「哪里错了」，而是「该改什么」。这句话是写给手上拿着报送的人看的，不是给写引擎的人看的。
- 依据 — XBRL 本体
- XBRL 的概念、规则、错误及其条款都整理成了一套本体。上面三样，是在校验过程中于其上推理得出的。
本体与推理
之所以答得出「为什么」，是因为这里的 XBRL 本身就是一套本体。
只会吐错误代码的校验器答不出「为什么」。这里，概念、规则、错误及其依据条款都聚在同一套本体里，结论则是 SHACL 在其上推理出来的。推理过程本身就是理由。
ixbrlo:illegalMultipleUseOfId
a owl:Class ;
rdfs:subClassOf ixbrlo:ValidationError ;
rdfs:comment "id attribute reused across iXBRL elements that require uniqueness."@en ;
skos:note "Inline XBRL 1.1, Section 3 — ixe:illegalMultipleUseOfId"@en ;
skos:note "Inline XBRL 1.1, Section 4 — ixe:illegalMultipleUseOfId"@en ;
owl:equivalentClass <http://www.xbrl.org/2013/inlineXBRL/errors#illegalMultipleUseOfId> .词汇是 W3C 标准，最后一行指向 XBRL International 公布的错误标识。没有一个名字是我们自造的。
Why Path
看到的不是错误代码，而是哪一款条文。
错误代码只说哪里不对。Why Path 还会说清是哪个对象、依据哪条规则、卡在哪一款条文。经手报送的人可以当场修正，日后被追问也拿得出依据。
修正更快
哪个对象、哪一款条文都直接点名，不用再去翻找。
判定说得清
审计师或监管方问起缘由时，那条路径本身就是答案。
输入
被校验的文件。
规则
跑的是 XBRL 2.1 §3～§5 的检查。
条款
两处违规，都挂在 XBRL 2.1 §5.1.3.4 上。
该改什么
角色 http://xbrl.org/role/conformance 不能用在 link:label 上。
最后一行才是要点：它指的不是哪里错了，而是该改什么。
靠得住的结果
这台引擎说通过，就是通过。
校验结果最终会成为审计和报送的依据。所以要紧的是两件事：答案不能晃，「通过」得真的是通过。这里没有靠猜、靠概率作答的部分——同一份文档放进去一百次，出来一百次都一样。
没有依据就不指摘
每条指摘都带着它依据的条款。没有触犯任何条款，它就直说。这样团队就不必花时间去核实一条告警是真是假。
没查的不会算成通过
跑不了的检查会标为未执行，并与通过数分开计。没有东西悄悄溜过去，所以「无异常」这个结果可以照单全收。
升级不会改掉你的结果
标准测试每次构建都跑，弄坏哪怕一项的改动根本发布不了。换上新版本，不会推翻你上个月得出的结论。
- 产出结果的版本
- 任何结果都能追回到具体是哪次构建。
- 运行环境
- 帮你分清差异是出自文档还是出自环境。
- 读了哪些分类标准
- 一行就能对上：双方看的是不是同一套分类标准。
- 没找到的文件
- 这个数不是零，就说明有那么多没检查到——它会直说，而不是悄悄放行。
再跑一遍，答案照旧。
校验内核
一个规范一个模块。
每个规范都是独立模块。整台引擎一起用，或只挑您真正要处理的那几个，都可以。
| 规范 | 检查什么 |
|---|---|
| XBRL 2.1 Core | 数字、期间、单位与概念定义是否彼此对得上 |
| XBRL Dimensions 1.0 | 按分部、地区等拆分出来的值，是不是允许的组合 |
| XBRL Formula 1.0 | 是否符合公司或监管另行规定的计算与检查规则 |
| XBRL Table Linkbase 1.0 | 是否按监管规定的表格式样输出 |
| Inline XBRL 1.1 | 人看到的页面与机器读到的数据是不是一回事 |
| Open Information Model 1.0 | 同一份内容换成 XML、JSON、CSV 后含义是否不变 |
| Extensible Enumerations 1.0 / 2.0 | 本该从固定清单里选的项，填的是不是清单里的值 |
| Report Packages 1.0 | 提交的整包是不是按规范打好的 |
| Taxonomy Packages 1.0 | 分类标准的分发包打得对不对，能不能离线解析 |
| Units Registry 1.0 | 货币、股数、百分比这些单位有没有按标准登记簿来用 |
| Link Role Registry 1.0 | 用到的角色名是不是标准登记簿上公布的那些 |
| Transformation Rules Registry v3 / v4 / v5 | 页面上的「1,234」「2025 年 3 月」转成数据值时是否合规 |
Calculation 1.1 随核心一起提供。无论挑哪几个，回来的结果都是同一个样子。
纯 Java 与速度
整套标准测试约 20 秒跑完。
Pure Java，没有本地代码，也没有别的要装。却快到能把整套测试放进构建里跑——不是每次发布跑一遍，而是每改一次就跑一遍。
100%
通过 XBRL International 检验测试
~20s
跑完全套所需时间
0
另外要装的东西
耗时因机器而异，重要的是量级而非精确数字。测试是公开的，您可以在自己的机器上实测。
Java 17 及以上
只要那台机器跑得动 JVM，它就跑得动。不用另装什么，也没有随包的本地库。