4. Taxonomy架构设计
Taxonomy（分类标准）是XBRL工程的“数据宪法”。实例报文只是对Taxonomy的一次具体取值，如果Taxonomy结构混乱，后续所有实例、公式、校验和报表都会陷入返工。本节从架构视角出发，梳理分类标准的结构组织、元素定义方式、类型选择、替换组机制，以及抽象元素与具体元素的设计原则，帮助你在动手写Schema之前先想清楚“骨架”。
一、核心原理：Taxonomy的三层结构
一个可交付的XBRL Taxonomy通常由三层构成：Schema层负责元素与类型的声明，Linkbase层负责元素之间的关系（列报、计算、定义、标签、引用），扩展层负责在监管基础分类之上做行业或企业级细化。三者通过schemaRef和linkbaseRef相互引用，形成一张有向图。
Schema层是唯一“定义事实”的地方：元素名、命名空间、类型、替换组、抽象属性都在这里确定。Linkbase层不产生新元素，只描述已有元素如何被组织、计算和展示。理解这一点，就能避免把“展示顺序”写进Schema、把“计算关系”硬编码进实例这类常见错误。
二、方法流程：从业务概念到元素定义
设计Taxonomy不是“先写XML再想业务”，而应遵循一条可复用的流程：
- 概念建模：从报表、披露要求和监管规则中抽取业务概念，区分“事实型概念”（如营业收入）与“组织型概念”（如资产负债表）。
- 命名与命名空间规划：为每个概念分配唯一名称，确定targetNamespace，避免与基础分类冲突。
- 类型选择：根据数据性质选择itemType，如金额用monetaryItemType，日期用dateItemType，枚举用stringItemType配合枚举linkbase。
- 替换组分配：事实型元素归入item替换组，容器型元素归入tuple替换组，超立方体相关元素归入hypercubeItem或dimensionItem。
- 抽象属性判定：仅用于组织层级、不承载具体值的元素设为abstract="true"。
- Linkbase编排：在presentation中定义展示层级，在calculation中定义加减关系，在definition中定义维度关系。
三、案例场景：一个“营业收入”元素的完整定义
假设我们要为某制造业企业定义“营业收入”元素。它属于事实型概念，金额型，需要参与利润表计算，并在资产负债表中作为组织节点下的子项。其Schema片段如下：
<xs:element name="OperatingRevenue"
id="mfg_OperatingRevenue"
type="xbrli:monetaryItemType"
substitutionGroup="xbrli:item"
abstract="false"
nillable="true"
xbrli:periodType="duration"
xbrli:balance="credit">
<xs:annotation>
<xs:documentation>营业收入，利润表主科目</xs:documentation>
</xs:annotation>
</xs:element>对应的presentation linkbase中，它被挂到“利润表”抽象节点下；calculation linkbase中，它作为“营业利润”计算加项之一。注意：periodType和balance是事实型元素的关键属性，前者决定实例中必须提供期间还是时点上下文，后者决定计算关系中的正负方向。
再看一个抽象元素的例子：
<xs:element name="IncomeStatementAbstract"
id="mfg_IncomeStatementAbstract"
type="xbrli:stringItemType"
substitutionGroup="xbrli:item"
abstract="true"
nillable="true"
xbrli:periodType="duration"/>该元素只用于在展示层级中充当“利润表”标题节点，实例报文中不会出现它的值。若误将其设为abstract="false"，实例中就可能出现空事实，导致校验失败。
四、误区与复盘：常见设计陷阱
| 误区 | 表现 | 后果 | 修正原则 |
|---|---|---|---|
| 抽象元素误设为具体 | 组织节点abstract="false" | 实例出现空事实，校验报错 | 仅组织用途一律abstract="true" |
| 替换组混用 | 事实元素用tuple替换组 | 无法作为事实被实例引用 | 事实用item，容器用tuple |
| 类型选择过宽 | 金额用stringItemType | 失去货币单位与计算能力 | 按数据性质选择monetary/date等 |
| 命名空间冲突 | 扩展元素与基础分类同名 | 解析歧义，合并报表失败 | 扩展命名空间独立且语义清晰 |
| 计算关系硬编码 | 在Schema中写加减逻辑 | Linkbase无法复用 | 计算关系放calculation linkbase |
Taxonomy架构设计不是一次性工作，而是随着监管规则和业务披露需求持续演进的工程。把Schema当作“数据契约”，把Linkbase当作“关系契约”，把扩展层当作“差异契约”，三者边界清晰，后续的实例报文工程才能稳定推进。