Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29500-3 — Office Open XML 文件格式 — 第3部分：标记兼容性与可扩展性
MC 可扩展引擎：替代内容、可忽略命名空间与向前兼容的文档设计
ISO/IEC 29500-3 解决了一个在任何大型、不断演进的文档标准中都会遇到的基本挑战：实现不同规范版本的应用如何在没有数据丢失的情况下互操作？答案是标记兼容性（MC）机制——在 http://schemas.openxmlformats.org/markup-compatibility/2006 命名空间中定义的一组 XML 构造，它实现了向前兼容的文档处理。应用程序可以使用新元素和属性扩展 OOXML，同时确保旧处理器优雅地跳过它们无法理解的内容，保持文档的其余部分完好无损。
MC 机制最好被理解为 OOXML 版的”忽略未知标签”行为——但通过 Ignorable 命名空间声明具有显式的选择加入契约。与 HTML 不同，OOXML 处理器被明确告知哪些命名空间允许忽略，从而消除了猜测并降低了数据丢失风险。
1. 标记兼容性命名空间
MC 命名空间定义了五个 XML 属性和两个元素，它们共同构成了可扩展性框架。这些构造在 XML 实例级别（而不是模式级别）应用，这意味着它们作用于实际文档内容而不是类型定义。
| MC 构造 | 类型 | 用途 |
|---|---|---|
| mc:Ignorable | 属性（命名空间前缀列表） | 声明如果未被识别，文档作者期望处理器跳过的命名空间前缀的元素/属性 |
| mc:ProcessContent | 属性（带命名空间前缀的元素名列表） | 指示处理器即使元素本身被跳过，也要处理来自可忽略命名空间的元素的文本内容 |
| mc:PreserveElements | 属性（QName 列表） | 指示处理器在往返过程中保留来自可忽略命名空间的某些元素 |
| mc:PreserveAttributes | 属性（QName 列表） | 类似地保留来自可忽略命名空间的属性的保证 |
| mc:MustUnderstand | 属性（命名空间前缀列表） | 标记处理器必须理解的命名空间——与 Ignorable 相反 |
| mc:AlternateContent | 元素（容器） | 包含一个或多个 mc:Choice 和最多一个 mc:Fallback 子元素 |
| mc:Choice | 元素（带 Requires 属性） | 声明需要处理器支持某些命名空间的内容变体 |
| mc:Fallback | 元素（无属性） | 声明当没有 mc:Choice 适用时的默认内容变体 |
一个关键实现细节：mc:Ignorable 应用于其出现的元素及其所有后代元素。这意味着在文档元素上声明 mc:Ignorable 使整个文档对未知命名空间具有容忍性。但是，mc:MustUnderstand 具有优先权——如果一个命名空间同时出现在 Ignorable 和 MustUnderstand 中，MustUnderstand 获胜。文档作者必须确保这些列表不会意外重叠。
2. 替代内容：Choice 与 Fallback 处理
mc:AlternateContent 元素是向前兼容文档设计的基石。它包装了多个内容变体——每个 mc:Choice 有一个 Requires 属性，列出处理器必须支持的命名空间。处理器按文档顺序评估每个 mc:Choice，并选择第一个其完全支持的命名空间。如果没有 mc:Choice 匹配，则使用 mc:Fallback 内容。
这种机制在概念上类似于 HTML5 的 <picture> 元素的 <source>/<img> 回退模式，但在 XML 元素级别而不是资源选择级别操作。在 OOXML 中，替代内容被广泛用于：
- 图表可扩展性：新图表类型（例如漏斗图、直方图）包装在带有较新命名空间的 mc:Choice 中；旧处理器渲染静态回退图像
- SmartArt 和图表功能：跨 Office 版本演进的布局算法和渲染提示
- 自定义扩展场景：在基础 OOXML 之上分层的行业特定扩展（例如法律编号、医疗编码）
生成针对多个应用程序版本的 OOXML 文档时，采用”优雅降级”模式：将功能最丰富的内容放在第一个 mc:Choice 中，将等效但更简单的表示放在 mc:Fallback 中。这确保最新应用程序获得完整体验，而旧版应用程序保持完全可编辑性而不会丢失数据。
3. 可忽略命名空间与 ProcessContent 语义
当处理器遇到声明为 mc:Ignorable 的命名空间时，它必须跳过来自该命名空间它未识别的元素和属性。但是，mc:ProcessContent 属性可以针对特定元素覆盖此行为：即使元素本身来自可忽略命名空间，其文本内容（字符数据）也被保留并处理，就像该元素被识别一样。
这种区别对于文档保真度至关重要。例如，自定义扩展可能添加包含用户评论的 <ext:annotation> 元素，使用可忽略命名空间。使用 mc:ProcessContent="ext:annotation"，旧版本将剥离 XML 标记但保留评论文本，从而保持至少部分内容保真度。
| 场景 | MC 声明 | 处理器行为 |
|---|---|---|
| 新图表类型——期望完全支持 | mc:AlternateContent 带有 Requires 中的新命名空间 | 新版：渲染图表；旧版：渲染回退图像 |
| 自定义元数据——可忽略 | 根元素上 mc:Ignorable=”ext” | 旧版：静默剥离所有 ext:* 元素和属性 |
| 自定义元数据——保留文本 | mc:Ignorable=”ext” + mc:ProcessContent=”ext:comment” | 旧版：剥离 ext:comment 元素但保留文本内容 |
| 关键渲染提示——必须理解 | mc:MustUnderstand=”render” | 旧版：必须支持或失败（不能静默忽略） |
过度使用 mc:MustUnderstand 是 OOXML 文档中的设计不良迹象。每个 MustUnderstand 命名空间都会创建一个硬依赖，可能阻止旧处理器打开文档。仅将 MustUnderstand 保留给那些缺失会导致静默数据损坏的命名空间扩展（例如加密元数据、数字签名配置）。对于所有其他扩展，使用 Ignorable + Alternate Content 以保持广泛的兼容性。
4. 向前兼容文档生成的工程策略
对于构建 OOXML 文档生成器的工程团队，MC 机制实现了一种版本感知的输出策略。现代最佳实践是始终在根文档元素上发出 mc:Ignorable 属性，并列出文档中使用的任何扩展命名空间。这带来了三个好处：(1) 旧处理器可以安全地打开文档，(2) 文档验证工具正确区分未知内容和无效内容，(3) 文档在旧版应用程序中保持可编辑性。
该标准还定义了 MC 如何与 MCE（标记兼容性可扩展性）处理器在模式验证、XPath 查询和 DOM 操作中交互。当重新序列化经过 MC 处理的文档时，通过 mc:PreserveElements 或 mc:PreserveAttributes 保留的可忽略命名空间的元素必须被原样写回，确保往返保真度。
问：mc:Ignorable 可以应用于 OOXML 文档中的任何 XML 元素吗？
答：可以——mc:Ignorable 可以出现在任何元素上。然而，惯例和实用性决定了它通常应用于部件根元素（例如 w:document、x:workbook、p:presentation），以便整个部件受益于该声明。
问：MC 如何与模式验证交互？
答：来自可忽略命名空间的元素和属性被排除在模式验证之外——它们通过而不经验证。这是关键的架构洞见：MC 允许在不更改模式的情况下进行扩展。只有非可忽略内容才进行模式验证。实现必须正确处理这种分叉的验证逻辑。
问：如果文档使用了 mc:MustUnderstand 但处理器部分支持该命名空间，会发生什么？
答：部分支持被视为”不理解”。处理器必须像完全不支持该命名空间一样回退。对于 mc:AlternateContent，这意味着具有 Requires 的 mc:Choice 被跳过，选择下一个选项或 mc:Fallback。
问：MC 是否支持嵌套的 AlternateContent？
答：支持——mc:AlternateContent 元素可以嵌套在 mc:Choice 或 mc:Fallback 内部。这对于多版本目标定位很有用，其中一个功能版本的回退包含其自身的子功能替代内容。
