Docling 生态中 DOCLANG 核心规范的 ISO/PAS 提交修订清单：两阶段合规改造全解

本文围绕 tests/data/docx/groundtruth/docx_rich_tables_01.docx.md 这份文档展开：它是“Changes to the DOCLANG Core Spec”技术草稿的 Markdown 形态，列出了该规范以 PAS（Registered Standards-Track Work）形式经由 ISO/IEC JTC/1 提交 ISO 所需的全部编辑项。读完后你将掌握一份可直接落地的两阶段 ISO 合规改造清单（条款顺序重排、RFC 措辞转 ISO 措辞、微观排版修正等共 46 项具体规则），并了解该文档与 Docling 仓库的关联——它既是 DOCLANG 格式生态的一部分，又是 Docling DOCX 后端“块级 SDT 包裹表格正确提取”能力的真实回归测试数据。

文档定位：一份 ISO 合规编辑清单，也是 Docling 的测试基准

这份文档的标题为 Changes to the DOCLANG Core Spec（Last Updated: 2026-06-18），开宗明义：

This document identifies the edits needed for a PAS submission to ISO via ISO/IEC JTC/1.

它与当前仓库有两层实在的关联：

1. 格式生态关联：DOCLANG 是 Docling 官方支持的应用级 XML 格式。README 中列出了对“DocLang、USPTO、JATS、XBRL”等多种 XML schema 的支持；docs/usage/supported_formats.md 明确了 DocLang XML 的输入扩展名（.dclg、.dclg.xml 及以 <doclang> 为根节点的通用 .xml）与 DocLang 归档（.dclx，含页面图片的 zip 包），并给出对应的 CLI 输出格式 doclang 与 dclx。对应的实现入口分别是 docling/backend/xml/doclang_backend.py 与 docling/backend/xml/doclang_archive_backend.py。因此，“让 DOCLANG 核心规范通过 ISO 合规”对 Docling 生态的意义，就是让这套文档中间格式具备标准化的长期地位。
2. 测试数据关联：该 .md 文件位于 tests/data/docx/groundtruth/，由源文件 tests/data/docx/sources/docx_rich_tables_01.docx 转换而来。tests/test_backend_msword.py 中的 test_block_sdt_tables_are_extracted（约 L769-L802）正是以它为基准：断言文档中 2 张 24×3 的表格（即下文 Phase 1、Phase 2 两张修订清单表）能从块级 SDT（Structured Document Tag）内容控件包裹中被完整提取，表头为 Feature / Action Needed / Comment/Links，且两张表分别落在正文 “Phase 1” 与 “Phase 2” 标题之后。

总体改造方案：两阶段（Phase 1 / Phase 2）

文档将 ISO 合规改造拆成两个阶段：

• Phase 1（Macro-Level Structural Realignment，宏观结构重排）：修正文档主体布局。强制采用标准条款顺序；删除被禁止的公司名与作者署名；切除对竞品格式的批评性表述；把所有随意的需求措辞和大写关键词（RFC 2119 风格）统一改写为 ISO 标准的小写措辞形式（shall、should、may）。
• Phase 2（Micro-Level Editorial Optimization，微观编辑优化）：按 ISO House Style 清理细节。修复悬挂段落等排版缺陷、为大数字加空格分隔（如 65 535）、在纸质版中写出可打印的完整网络链接、使用规范的下标数学格式，并将全部排版限制在标准字体内，以通过最终出版系统校验。

下面完整继承原文档的逐条规则。所有条目的 “Comment/Links” 列均给出所依据的 ISO/IEC Directives, Part 2 条款号，可据此回溯具体规定。

Phase 1：宏观结构重排（23 项）

Feature	Action Needed	Comment/Links
Document Clause Ordering	重组为强制顺序：• Foreword（强制，不编号）• Introduction（可选，不编号）• 1 Scope（强制，第 1 条）• 2 Normative references（强制，第 2 条）• 3 Terms and definitions（强制，第 3 条）• 4 Symbols and abbreviated terms（强制，第 4 条）• 5 Conformance（强制，第 5 条）• 6 技术条款… • Annex A（规范性）• Annex B/C（资料性）• Bibliography（强制，绝对末尾）	当前草稿在标准排版条款确立之前混入了介绍性叙述、设计原则与示例。See ISO/IEC Directives, Part 2, Clause 6.
Author & Corporate Profiles	完全删除列有个人姓名与所属公司的表格。	ISO 正式出版物中禁止出现个人姓名、企业品牌、Logo 与隶属关系。See ISO/IEC Directives, Part 2, Clauses 4 and 12.5.2.
Foreword Boilerplate	用 ISO/IEC JTC 1 PAS 的强制前言文本替换原前言，仅保留一句中立语句指明发起该文件的工作坊。	ISO 前言遵循规定的措辞与结构。See ISO/IEC Directives, Part 2, Clause 12.
Market / Design Motivation	删除 Motivation 条款及所有批评 Markdown、HTML、LaTeX、PageXML、ALTO XML、hOCR 等类似技术的比较性内容。	ISO 标准应保持技术中立，避免比较性、竞争性声明。See ISO/IEC Directives, Part 2, Clause 4.
Evolutionary Versioning Prose	删除历史发展叙述、beta 版本讨论以及 Version 0.x 兼容性说明。	ISO 标准描述的是当前要求，而非产品发展史。See ISO/IEC Directives, Part 2, Clauses 11 and 12.
Clause Header Casing	将所有条款与子条款标题改为句首大写（sentence case）。	标题式大写（title case）不被 ISO 排版风格允许。See ISO/IEC Directives, Part 2, Clause 22.2.
Self-References	将 “this specification”“this standard”“this format” 全部替换为 “this document”。	ISO 出版物只能自称 “this document”。See ISO/IEC Directives, Part 2, Clause 10.6.
Scope Clause Compliance	重写第 1 条，只描述主题范围，删除规范性语句、实现义务与对一致性要求的引用。	Scope 条款应界定文档的适用范围，且不得包含要求。See ISO/IEC Directives, Part 2, Clause 14.
Normative References Clause	紧随 Scope 之后创建第 2 条。如无引用，插入：“There are no normative references in this document.”	第 2 条是强制的。See ISO/IEC Directives, Part 2, Clause 15.
External Dependency Classification	审查对 XML、XSD、Unicode、URI 规范及 RFC 的引用，逐项归类为规范性（第 2 条）或资料性（参考文献）。	凡实现本文件所必需的引用文件必须出现在第 2 条。See ISO/IEC Directives, Part 2, Clause 15.
Terms and Definitions Clause	将 “Terminology” 改为 “Terms and definitions”，并按 ISO 术语规范排版所有条目。	定义须遵循 ISO 规定的结构。See ISO/IEC Directives, Part 2, Clause 16.
Entry Notes in Definitions	将嵌入定义中的解释性备注转换为正式的 “Note X to entry:” 格式。	定义内嵌非正式备注不被允许。See ISO/IEC Directives, Part 2, Clause 16.5.9.
Terminological Source Attribution	为导入的定义添加正式的 [SOURCE: ...] 出处引用。	借用定义必须标注来源。See ISO/IEC Directives, Part 2, Clause 16.5.10.
Terminology Consistency Audit	为每个概念确立唯一优选术语，并全文清除同义词。	ISO 起草遵循“一概念一词”原则。See ISO/IEC Directives, Part 2, Clause 16.
Symbols and Abbreviated Terms Clause	创建第 4 条，或将缩写并入第 3 条。	OTSL、XML、VLM、RAG、PII、GDPR、XSD 等缩写需要集中处理。See ISO/IEC Directives, Part 2, Clause 17.
Conformance Definition	创建第 5 条 Conformance，界定有资格声明合规的实现类别。	若不能指明责任实现对象，要求便无法成立。See ISO/IEC Directives, Part 2, Clause 33.
Conformance Classes	视情况定义不同的一致性类别（如文档生成器、校验器、解析器、处理器、渲染器）。	不同实现类别可能承担不同义务与测试判据。See ISO/IEC Directives, Part 2, Clause 33.
Requirement Traceability	确保每条 “shall” 语句都能指明责任主体且可客观测试。	要求必须可度量、可验证。See ISO/IEC Directives, Part 2, Clause 33.
RFC Verbal Compliance	将 RFC 2119 大写关键词（MUST、SHOULD、MAY）替换为 ISO 措辞形式（shall、should、may）。	ISO 不承认 RFC 关键词惯例。See ISO/IEC Directives, Part 2, Clause 7.
Introduction Compliance	删除 Introduction 中的所有要求、许可、建议与实现规则。	Introduction 仅为资料性内容。See ISO/IEC Directives, Part 2, Clause 13.
Informative Annex Compliance	从所有资料性附录中删除规范性语言。	资料性附录不得包含要求。See ISO/IEC Directives, Part 2, Clause 20.2.
Annex Naming	将 Appendix A/B/C 改名为 Annex A（normative）、Annex B（informative）、Annex C（informative）。	ISO 不使用 “Appendix” 一词。See ISO/IEC Directives, Part 2, Clause 20.
Annex Reference Audit	确保正文中显式引用了 Annex A、B、C。	未被引用的附录常在编辑审查中被标记。See ISO/IEC Directives, Part 2, Clause 20.

从清单结构可以看出 Phase 1 的核心逻辑：先解决“文件骨架”（条款顺序、前言/范围/规范性引用/术语/一致性五大强制条款），再解决“措辞合法性”（RFC 2119 关键词、自指措辞、标题大小写），最后处理附录体系（命名、引用、规范性污染）。这也解释了为什么文档同时要求删除对 Markdown、HTML、LaTeX 等格式的批评——ISO 的技术中立性（Clause 4）对任何中间文档格式规范都是硬约束。

Phase 2：微观编辑优化（23 项）

Feature	Action Needed	Comment/Links
Cross-Reference Normalization	用 ISO 条款引用替换 Markdown 锚点与非正式引用。	引用应使用 “see 7.3.2”“see Annex A” 等形式。See ISO/IEC Directives, Part 2, Clause 10.
Hanging Paragraph Subclauses	在引出下级子条款之前，为各大条款先插入 “General” 子条款。	防止悬挂段落与歧义条款结构。See ISO/IEC Directives, Part 2, Clause 22.3.3.
Orphan Subclause Remediation	若某条款含 .1 子条款，则必须同时含 .2，或将细分内容合并回父条款。	ISO 编号规则禁止“单子节点”细分。See ISO/IEC Directives, Part 2, Clause 22.3.2.
XML Tag Typography	对元素名、属性、标记片段与语法符号施加一致的直体（literal）排版。	区分标识符与正文，减少歧义。See ISO/IEC Directives, Part 2, Clauses 9 and 24.
Formal Language Notation	引入专门条款描述规范性文法记法、schema 语言或语法约定。	形式化语言应使用公认记法，而非仅靠示例。See ISO/IEC Directives, Part 2, Clause 9.2.
Attribute Value Enumerations	将受控词表与属性取值整合为结构化表格或形式化规则。	提升可实现性、可校验性与一致性测试能力。See ISO/IEC Directives, Part 2, Clause 5.6 & Clause 29.
Number Formatting	千分位逗号分隔改为 ISO 空格约定（如 65 535）。	See ISO/IEC Directives, Part 2, Clause 9.1.
Printable URI / URL Strings	对外部引用资源展示显式 URI 字符串。	文档必须保持可打印可用性。See ISO/IEC Directives, Part 2, Clause 10.3.
Bi-directional Reference Auditing	核验所有规范性引用均按规范性方式被引用、所有参考文献条目均按资料性方式被引用。	不允许存在孤儿引用。See ISO/IEC Directives, Part 2, Clauses 10.1 and 15.1.
Font and Style Normalization	移除非标准格式、装饰性方框、自定义颜色与视觉样式。	ISO 出版系统会自动归一化字体与排版。See ISO/IEC Directives, Part 2, Clause 1.
Informative Code / Example Marking	将所有示例显式标注为 EXAMPLE。	示例必须与要求明确区分。See ISO/IEC Directives, Part 2, Clause 25.
Example Separation	审查示例周围解释性文字，确保示例不能被解读为规范性要求。	示例仅为资料性内容。See ISO/IEC Directives, Part 2, Clause 25.
Tabular Formats	将管道符分隔的文本表格转换为正式表格结构。	表格必须以结构化的方式定义。See ISO/IEC Directives, Part 2, Clause 29.
Non-Normative Implementation Narrative	将实现指导与编写过程评述移入 notes 或资料性附录。	标准定义技术结果，而非内部编写流程。See ISO/IEC Directives, Part 2, Clause 24.
Mermaid Diagram Transmutation	将 Mermaid 源码转换为静态图形。	基于文本的图源码完全不适用 ISO 出版系统。See ISO/IEC Directives, Part 2, Clause 28.6.4.
Graphic Text Normalization	统一图形内文字排版，去除图形中的品牌标识。	图形应保持中立、清晰、可读、达到出版就绪状态。See ISO/IEC Directives, Part 2, Clause 28.5.2.
Bibliography Construction	将所有资料性引用迁移至末尾不编号的 Bibliography。	See ISO/IEC Directives, Part 2, Clause 21.
Asset Caption Formatting	将题注改为 ISO 图/表题注风格并采用 sentence case。	See ISO/IEC Directives, Part 2, Clause 28.2 & Clause 29.2.
Commercial Tools Footnotes	为涉及商标产品或技术的引用添加“非认可”声明。	See ISO/IEC Directives, Part 2, Clause 31.
Mathematical Interval & Unit Formatting	改写区间记法，并强制数值与单位之间留空格。	See ISO/IEC Directives, Part 2, Clauses 9.1 and 9.4.1.
Percentage Symbol Clean-up	将正文中的 % 替换为 “per cent”。	% 符号仅允许用于表格矩阵与字面代码块。See ISO/IEC Directives, Part 2, Clause 9.4.1 & Annex B.
Schema Placeholder Optimization	从示例中移除占位值、省略号与起草残留物。	起草残留会被自动摄取系统标记为“未完成规范泄露”。See ISO/IEC Directives, Part 2, Clause 4.1.
Subscript Coordinate Notation	将 snake_case 数学变量转换为带下标的规范数学记法。	See ISO/IEC Directives, Part 2, Clause 9.3.1.

值得注意的工程细节：Phase 2 中 “Tabular Formats”“Printable URI”“Mermaid Diagram Transmutation” 三项，恰好对应本文档自身所处的形态——它就是一份由管道符表格构成的 Markdown，其中若含有 Mermaid 源码与锚点引用，都需要在转写为 ISO 文本时分别转为正式表格、可打印 URI 与静态图形。也就是说，这份清单对“自身”的转写过程同样成立。

该文档在 Docling 中的验证方式：块级 SDT 表格与富单元格

原文档中的两张修订清单表在 Word 源文件里被块级 SDT 内容控件（w:sdt，即 Word 的“构建性内容部件/内容控件”）包裹。这正是 Docling DOCX 后端需要处理的真实场景：DOCX 里常见的表格目录、表单域、Mendeley 引文等都是 SDT 容器。

源码层面，docling/backend/msword_backend.py 在两处显式处理 sdt 标签：约 L788-L798 的遍历逻辑会检测 sdt 容器（如目录），取出 w:sdtContent 子树并继续线性遍历（self._walk_linear(sdt_content, doc)），从而把包裹在内容控件里的正文/表格还原为普通文档流；约 L1530-L1541 则针对内联引用类 SDT，直接从 w:sdtContent//w:t 与 w:sdtContent//w:r 提取文本与 run。从源码结构看，这种“进入 sdtContent 继续线性化”的策略，正是块级 SDT 表格不被吞掉的直接原因。

测试层面，test_block_sdt_tables_are_extracted 的断言值得逐条对照：

• assert len(doc.tables) == 2——两张清单表都被识别为表格项；
• assert table.data.num_rows == 24 与 table.data.num_cols == 3——每张表均为 24 行（1 表头 + 1 分隔行 + 22 条规则，即原文档 Phase 1/Phase 2 的 23 行 Markdown 行减去表头后的规则集合）× 3 列；
• 前三个单元格文本恰为 "Feature"、"Action Needed"、"Comment/Links"；
• 通过遍历 doc.body.children 解析后的 body 项序列，验证第一张表位于 “Phase 1” 标题之后、第二张表位于 “Phase 2” 标题之后，即表格在正文中的位置关系被 SDT 包裹干扰后仍然保持正确。

与之配套的兄弟基准文件也展示了 Docling 对这份“富表格”文档的内部建模：

• tests/data/docx/groundtruth/docx_rich_tables_01.docx.json：DoclingDocument（schema version 1.10.0）JSON 序列化，body.children 以 $ref 指向 texts/groups/tables 三类节点；每个表格单元格被建模为名为 rich_cell_group_1_0_0、rich_cell_group_1_1_0 等的 group，富内容单元格（多段落/多 run）以独立组节点承载；
• tests/data/docx/groundtruth/docx_rich_tables_01.docx.itxt：逐项树状视图，可见 table with [24x3] 之下每个单元格都是 rich_cell_group_* 组节点包裹文本项，两个阶段说明列表则呈现为 list 组下含内联 group（Phase 1 / Phase 2 粗体片段与说明文字分离为独立 text 项）的 list_item 结构。

从源码与测试结构看，这条测试链同时验证了三件事：SDT 容器的透明穿透、富单元格（一个单元格内多个段落/样式片段）到 rich_cell_group 的建模保真度、以及 Markdown 导出时“标题—表格—标题—表格”的阅读顺序。

小结与使用建议

• 若你在为任何文档中间格式（DOCLANG 或其他）准备 ISO/PAS 提交，可直接按本文两张表执行：先 Phase 1 完成“结构 + 措辞”重排，再 Phase 2 完成排版与引用清理；每条规则都已标注 ISO/IEC Directives, Part 2 的对应条款号，可作为自查依据。
• 若想复现本文档的转换与验证流程：使用 Docling 转换 tests/data/docx/sources/docx_rich_tables_01.docx，对照 tests/data/docx/groundtruth/docx_rich_tables_01.docx.md、同目录 .json 与 .itxt 基准，并运行 tests/test_backend_msword.py 中的 test_block_sdt_tables_are_extracted 确认 SDT 包裹表格的提取结果。
• 若你关心的是 Docling 侧的 DOCLANG 能力：输入 .dclg / .dclg.xml / .dclx，输出 doclang / dclx，入口实现见 docling/backend/xml/doclang_backend.py 与 docling/backend/xml/doclang_archive_backend.py，格式矩阵见 docs/usage/supported_formats.md。