S1000D Issue 4 与 Issue 5 有什么区别？迁移对照与选型
S1000D Issue 4 与 Issue 5 都以数据模块、DMC、CSDB 和结构化出版为核心，但 Issue 不是一个可以只改数字的文件头。真正的差异要结合对应的 Schema、数据字典、代码表、业务规则、工具链和交付环境核对。Issue 5 项目应先建立版本基线，再决定新建、兼容或迁移策略。
S1000D Issue 4 与 Issue 5 的核心区别是什么？
Issue 4 和 Issue 5 属于同一规范体系的不同版本基线，共同使用数据模块（DM，Data Module）、数据模块代码（DMC，Data Module Code）、公共源数据库（CSDB，Common Source Database）和出版物模块（PM，Publication Module）等概念。区别不应只看一个元素名称，而应比较与该 Issue 配套的 Schema、Data Dictionary、代码表、业务规则、工具和交付要求。公开资料可以帮助理解方向，项目是否兼容仍必须以批准的版本包和样例验证。
因此，“Issue 5 一定完全兼容 Issue 4”或“Issue 5 一定必须重做全部内容”都不是通用结论。不同组织、项目和工具可能采用不同的受控词汇、扩展规则、转换方式和验收范围，应先建立差异清单，再确定迁移边界。
两者有哪些共通的实施思路？
| 共通思路 | 项目中的作用 | 实施时仍需确认 |
|---|---|---|
| 数据模块 | 把技术信息拆成可管理、可复用和可组合的内容单元。 | 模块类型、结构、状态、内容粒度和项目 Schema。 |
| DMC 与 SNS | 用身份编码和系统层级帮助定位模块、组件和信息类型。 | 编码字段、代码表、SNS 分解和与型号配置的映射。 |
| CSDB | 管理模块、媒体、引用、版本、状态、审核和发布关系。 | 工具实现、权限、基线、重用策略和交付包组织。 |
| PM 与适用性 | 按目录、交付范围和产品配置组织可阅读的出版物。 | 条件逻辑、DMRef、筛选结果、阅读器和输出格式。 |
| 规则校验 | 通过 Schema、BREX、代码表和引用检查控制质量。 | 规则版本、错误级别、豁免流程和验收证据。 |
Issue 4 与 Issue 5 项目上应该对照哪些内容？
下面是迁移或选型时的核对框架。表中“需要确认”表示不能脱离项目版本包下结论，不代表某个字段在所有 Issue 中必然发生同样变化。
| 对象 | 需要对照的问题 | 为什么影响项目 | 建议证据 |
|---|---|---|---|
| Schema 与命名空间 | 根元素、命名空间、元素顺序、属性、数据类型和必填项是否一致？ | 直接影响解析、编辑、校验和转换；“能打开”不等于通过目标 Schema。 | 采用 Issue 的 Schema 包、校验报告、批准样例。 |
| Data Dictionary 与代码表 | 元素定义、允许值、状态、代码含义和生效范围如何变化？ | 相同文本值可能在不同规则包中含义不同，影响内容、检索和上下游接口。 | 数据字典版本、代码表差异、映射和审批记录。 |
| DMC、SNS 与身份 | 字段组合、长度、允许值、项目扩展和文件名映射是否保持兼容？ | 身份变化会影响引用、DMRL、CSDB、PM、适用性和历史追溯。 | DMC/SNS 规则、代表性编码、引用扫描结果。 |
| 适用性与 PM | ACT/PCT/CCT 或项目适用性表达、DMRef 和筛选结果是否一致？ | 迁移后可能出现内容多发、少发或目标构型筛选错误。 | 条件矩阵、PM 预览、边界构型回归记录。 |
| BREX 与业务规则 | 必填项、命名、警告、安全信息、媒体和项目限制是否变更？ | Schema 通过但业务规则失败时，模块仍不能作为项目交付物。 | BREX 版本、规则差异、失败/豁免和复核记录。 |
| 工具与交付环境 | 编辑器、CSDB、转换器、渲染器、阅读器和目标设备支持哪组基线？ | 工具兼容性、性能、字体、媒体和离线交付可能与源端不同。 | 供应方支持矩阵、工具配置、目标环境抽检。 |
一个版本对照矩阵示例
下表使用虚构的“项目 A”展示如何记录差异。版本号、Schema 名称和结果是示意值，不是 S1000D 官方发布清单，也不能作为实际项目配置直接复制。
| 对象 | 项目 A 当前基线 | 项目 A 目标基线 | 迁移验证 |
|---|---|---|---|
| Issue | Issue 4（合同批准版本，待补完整发布信息） | Issue 5（变更申请拟定版本） | 确认合同、客户、标准包和生效日期。 |
| Schema | schema-4-project-a（虚构名称） | schema-5-project-a（虚构名称） | 对描述、程序、零件和故障隔离样例分别校验。 |
| DMC / SNS | 保留现有身份与系统分解 | 先做兼容映射，再决定是否调整代码 | 扫描 DMRef、PM、文件名和历史交付包中的引用。 |
| 适用性 | 型号 A、构型 1 和 2 | 增加构型 3 的条件组合 | 检查真值组合、边界条件和空结果。 |
| 输出 | PDF 与离线 IETP | PDF、离线 IETP 和目标阅读器包 | 在目标设备检查目录、检索、媒体、警告和离线运行。 |
矩阵要把“当前”和“目标”分开写，并给每一项绑定规则、工具、样例和验收证据。若目标版本、Schema 或客户基线尚未确认，应标记“待确认”，不要把猜测写成已批准事实。
从 Issue 4 迁移到 Issue 5 怎么做？
- 冻结当前基线：保存 Issue、Schema、Data Dictionary、代码表、BREX、工具配置、DMC/SNS 规则、模块、媒体、PM 和交付包清单。
- 确认迁移目标：写清合同依据、目标 Issue、目标 Schema、目标工具和必须保持兼容的交付物；没有批准依据的目标不进入批量转换。
- 做差异分析：从结构、编码、规则、适用性、引用、媒体、渲染、接口和安全信息逐项比较，形成影响矩阵。
- 选择代表性样例：至少覆盖描述、程序、零件、故障隔离、带适用性模块、图形/3D 媒体和复杂引用，避免只测最简单文件。
- 小批量试迁移：保留原始只读快照，记录转换日志、失败项、人工修订和映射规则，确认可以回退。
- 双轨回归：比较新旧基线的 Schema/BREX 结果、引用、筛选、目录、检索、媒体、PDF 和 IETP 输出。
- 目标环境验收：在客户指定的阅读器、设备、浏览器或离线环境打开候选交付物，记录问题和复测结果。
- 批准并维护：关闭异常，更新版本矩阵、发布说明和维护策略，再切换正式基线；旧版包和回退步骤按项目要求归档。
如何选择 Issue 4 或 Issue 5？
选择版本时先问“项目需要交付什么、由谁验收、工具能稳定支持什么”，再比较版本差异。正在维护的大型 Issue 4 资产不一定要为了版本新旧立即迁移；新项目也不应只因为工具宣传“支持 Issue 5”就跳过 Schema、BREX、代码表和交付验证。
| 情况 | 优先做法 |
|---|---|
| 客户合同已明确 Issue 和配套规范包 | 以合同和批准基线为准，先验证工具和交付链路，再安排编制或迁移。 |
| 现有 Issue 4 数据量大、交付稳定 | 先评估迁移收益、兼容风险和维护窗口，用小样例验证后再决定是否批量迁移。 |
| 新项目尚未冻结版本 | 同时核对客户接受的版本、工具支持、团队能力、长期维护和下游接口，形成书面决策。 |
| 供应方只给出“支持 S1000D” | 要求提供具体 Issue、Schema、BREX、数据字典、导入导出边界和目标环境测试范围。 |
常见问题
Issue 5 是 Issue 4 的简单升级版吗？
不能简单这样理解。两者都采用数据模块和公共源数据库等核心思路，但项目实际使用的是一组相互匹配的规范、Schema、数据字典、代码表和业务规则。迁移前必须以批准的版本包做差异分析。
Issue 4 数据能直接用 Issue 5 工具打开吗？
不能默认可以。工具能打开文件只说明解析层面可用，还需要检查结构校验、BREX、代码表、适用性、引用、媒体、渲染和目标交付环境。
Issue 4 与 Issue 5 的 DMC 会完全不同吗？
DMC 作为数据模块身份的作用仍然存在，但字段、允许值、Schema 约束和项目映射必须按采用的 Issue 与规则核对，不能把一个版本的样例直接当成另一个版本的模板。
选择 Issue 4 还是 Issue 5 应该看什么？
应综合合同和客户基线、交付时间、现有数据、目标阅读器、工具支持、团队经验、迁移成本和后续维护计划决定，不能只按版本号的新旧做选择。
迁移到 Issue 5 只修改 XML 命名空间可以吗？
不可以。命名空间或文件头变化不能替代 Schema、数据字典、业务规则、代码表、引用、适用性和发布结果的验证。