S1000D技术出版物结构化：数据模块、DMC编码与IETP实战

第一次接触 S1000D 的人十有八九是被一串像DMC-DEMOPUMP-AAA-D1012-00-00A-040A-A_001-00_zh-CN.XML这样的文件名劝退的。我第一次做 S1000D 项目的时候对着一份几十页的编码规则表看了整整两天才反应过来这套规范真正想干的事其实很朴素把一本几百页、改一次就要重印一版的设备手册拆成几百块能被机器识别、被系统组装、被反复复用的内容积木然后用一套严格的编码和规则把每块积木钉在它该在的位置上。这套规范最早来自欧洲航空工业的标准化组织现在由 ASD 持续维护已经从 SGML 时代迭代到了以 XML 为核心的 Issue 4.x、5.0。它被大量用在航空、船舶、轨道交通、能源装备、大型工业设备的全寿命周期技术出版物场景里。如果你正在做技术文档结构化、IETP交互式电子技术出版物、备件图册或者你所在团队要把几十年的老手册迁到新平台S1000D 大概率会出现在你的选型清单上。下面这些内容是我自己踩过坑之后整理出来的导读路线先讲它到底解决什么问题、为什么这么设计再拆核心概念和数据模型然后给一条能跑通的最小实操路径最后把我遇到过的报错和项目推进中的坑摊开讲。适合完全没接触过的技术写作新人也适合已经上手但被 BREX、适用性、IETP 这些名词绕晕的老手。1. S1000D 到底在解决什么问题1.1 从一本几百页的手册说起传统技术出版物的三个死结只要做过设备手册你一定遇到过这三个死结。第一个是重复。同一段液压泵工作原理的说明可能要出现在操作手册里、维护手册里、培训教材里、备件目录里改一次就得同步改四处漏一处就是事故隐患。第二个是无法组装。客户买的是 A 型号的配置但手册是按全配置印的客户拿到手翻到一半发现本章适用于 B 型号剩下三分之二都是废纸。第三个是不可计算。手册里的拧紧到 45 N·m、更换密封圈这类内容在系统眼里只是一堆字符它不知道这是一条步骤也不知道这条步骤依赖哪个零件、适用于哪个批次。这三个死结不是靠排版工具解决的靠的是把内容的结构和内容本身分开。这就是 S1000D 的第一个设计出发点内容一旦结构化就可以被筛选、被引用、被重新组合、被程序校验。我在一个项目里做过统计同一个设备的描述类内容在三个不同的手册里被复用了十七次如果还是老办法维护这十七个副本就是十七个定时炸弹而结构化之后它们只有一个源其余全是引用。理解了这一点后面所有的规范细节都能串起来为什么要有 DMC 编码、为什么要有适用性机制、为什么要有 CSDB本质都是为了让机器能找得到、选得对、拼得起。1.2 数据模块化把手册拆成可组装的积木S1000D 的核心单位叫数据模块英文 Data Module简称 DM一个 DM 就是一个独立的内容文件只讲一件事。比如液压泵概述是一个 DM液压泵拆卸程序是另一个 DM液压泵常见故障隔离又是另一个。每个 DM 都有一个唯一的身份证也就是 DMCData Module Code系统靠这个码来定位它、引用它、判断它属于哪台设备的哪个部位。拆到什么粒度算合适这是新手最容易纠结的地方。我的经验是看变更频率和适用性边界两个内容如果总是同时改、适用条件也完全一样就该放在同一个 DM 里如果一个改了一个不用改或者适用条件不同就必须拆开。拆得太碎会导致引用关系爆炸一个程序里挂几十个引用维护起来痛苦拆得太粗就丧失了结构化的意义。按照常见实践一个 DM 一般对应 1 到 5 页的内容量程序类 DM 通常是一套完整的动作序列描述类 DM 通常是一个部件或一个功能的说明。这个粒度不是规范强制的但你必须在项目内部统一否则不同作者写出来的东西拼在一起就是灾难。我们当时定的规矩是描述类不超过 800 字程序类不超过 25 个步骤超过就考虑拆然后把这条写进了项目的业务规则文件里。1.3 为什么是 XML CSDB而不是数据库或者 DITA经常有人问我为什么不直接用一个内容管理系统加数据库非要用 XML 文件加文件夹这个问题的答案在交换和寿命上。设备的技术出版物生命周期动辄三四十年中间会换好几家供应商、好几套软件。如果内容躺在某个厂商的数据库里换供应商那天你就要面对数据迁移的地狱而 XML 是纯文本任何一家工具都能读甚至十年后拿记事本都能打开。S1000D 把内容定义为 XML 文件、把存储位置定义为 CSDB公共源数据库Common Source Data Base实际上是把数据格式和管理系统解耦了。那为什么不选 DITA两者经常被拿来对比我做过一个简单的对照你可以按自己项目的性质来选维度S1000DDITA传统 Word 手册交换单位数据模块 DM主题 topic整本文档元数据强度极强DMC、SNS、适用性、密级、来源全都有中等几乎没有约束方式XSD schema 加项目级 BREX 规则DTD 或 schema 加风格约定无典型场景装备全寿命周期技术出版物、备件图册、IETP产品文档、帮助中心、通用内容小范围、一次性交付上手成本高概念多中低一句话概括S1000D 是给复杂装备的长寿文档设计的它牺牲了灵活性换取严密性。如果你的内容需要精确到这个步骤适用于序列号 1001 到 2000 的 A 配置设备、并且在寒冷气候条件下要换成另一套扭矩值那 DITA 会觉得别扭S1000D 会觉得很自然。2. 规范家族全景核心构件逐个拆2.1 DMC 编码S1000D 世界的身份证DMC 不只是一串编号它是 S1000D 的信息坐标系。一个完整的 DMC 由 11 个字段组成可以拆成 XML 里的 11 个属性也可以拼成文件名里的字符串。下面用我虚构的一个演示泵项目举例说明每一段的含义字段名作用示例值modelIdentCode型号识别码区分是哪个产品DEMOPUMPsystemDiffCode型号差异码同一型号的不同构型AAAsystemCode系统码通常沿用行业通行的章节体系D10subSystemCode分系统码1subSubSystemCode分分系统码2assyCode装配件码定位到具体组件00disassyCode拆分件码定位到更细的零件层级00disassyCodeVariant拆分件变体处理同层级的不同实现AinfoCode信息码说明这块内容是什么类型040infoCodeVariant信息码变体同类型内容的细分AitemLocationCode位置码区分同一物品的不同安装位置A这 11 段里前 8 段基本回答讲的是哪台设备的哪个部位第 9 到第 10 段回答讲的是什么事最后一段回答在哪儿。系统拿到一个 DMC不用打开文件就知道它属于哪个系统的哪个部件、是描述还是程序、适用于哪个位置这就是结构化的威力。有几个细节新手很容易翻车。第一位数的校验是死的某些字段只能是 2 位或者 3 位少一位多一位 schema 直接报错。第二systemCode 那一段不是随便编的绝大多数项目直接沿用行业里通用的章节编号体系因为你的客户和上游供应商都用同一套你另起炉灶当天就会被要求返工。第三itemLocationCode 的 A 一般表示针对物品整体或者不需要区分位置其余字母用来区分同一物品在不同安装位置上的内容这个字母用错了客户在看 IETP 的时候会看到一堆重复的步骤。提示把 DMC 的 11 个字段做成一张 Excel 或者一个校验脚本让作者先填表再生成文件名能省掉后期至少一半的返工。手工拼 DMC 是错误率最高的环节。2.2 信息码与 DM 类型内容怎么分类信息码infoCode是三位数字回答这个数据模块讲的是哪一类内容。规范附表里定义了几百个信息码而且按首位数字做了大类划分描述类、程序类、故障类、图解零件类大致落在不同的号段里。实际项目里没人会去背这几百个码通常的做法是从规范附表里挑出本项目真正需要的二十到三十个写进业务规则其余的禁用。这是我强烈建议的做法理由很简单信息码种类越多作者选错的空间就越大审核成本就越高。数据模块还按内容性质分成几种类型对应的校验规则和 XML 骨架都不一样。不同 Issue 版本的叫法略有差别但大致是这么几类描述类讲原理、讲构成、讲功能常见信息码是 040 这一类。程序类拆卸、安装、测试、调整、清洁步骤必须带编号动作和结果要能一一对应。故障类故障隔离流程、故障现象、可能原因、排查动作这个类型要求特别严密因为现场人员是按它排故的。图解零件类备件图册图片加零件号加位置号和适用性强绑定。操作人员类面向操作者的简化版本语言更口语化安全提示更前置。我在项目里最常说的一句话是先定类型再写内容。作者上来就问这段写哪儿其实就是类型没定清楚。类型定了XML 骨架就定了能填什么元素、步骤怎么写、图片怎么挂全都有答案。2.3 CSDB、版本与状态流内容是怎么被管住的CSDB公共源数据库不是一个软件它是一组规则和目录结构。你完全可以用文件夹加 Git 来搭一个最小可用的 CSDB也可以买商业套件。关键在于它必须满足几件事唯一标识一个 DMC 加一个版本号只能对应一个文件、状态可追溯草稿、待审、已校验、已发布每一步要留痕、引用可解析A 引用 B系统要能判断 B 是否存在、是否已发布。版本控制的核心是两个属性。一个是issueNumber三位数字正式发布的版本号每次发布加一。另一个是inWork两位数字规定里00表示这是一份正式发布的版本非零值表示这是工作过程中的临时版本。这个设计挺聪明的它允许你把半成品交给合作方做早期接口验证同时又能一眼看出哪些内容还没定稿不会误用。状态流我一般会设计成这样起草 → 内部评审 → 技术校验schema 加 BREX→ 业务验证现场核对→ 发布。每个状态对应 DM 头部的一个状态标记谁在什么时间改的、依据是什么都要能查。我见过最惨的一次事故是某个批次的手册漏了适用性筛选客户拿到的是整本结果现场人员按另一个构型的扭矩值去操作直接把螺栓拧坏了。从那以后我在任何项目里都会坚持一件事内容可以晚一点发布但状态和适用性绝对不能含糊。注意CSDB 目录里数据模块文件的扩展名规范里约定用大写的.XML。在 Windows 上无所谓一放到 Linux 或者容器环境里.xml和.XML就是两个文件工具链会直接找不到东西。这个坑我踩过两次。2.4 BREX 与业务规则为什么每个项目都要自己再定一套规矩schema 只能管住结构对不对管不住内容合不合规。比如 schema 允许你在一个程序里写 200 个步骤但你的行业惯例是超过 25 步就拆schema 允许你把密级标成任意值但你的项目只有三个密级可选。这些项目级的规矩就靠BREXBusiness Rules Exchange业务规则交换来承载。BREX 本身也是一个数据模块它的内容是规则条目每条规则说明管哪个元素、允许怎么用、违反了算什么级别的错误。工具读取 BREX 之后就能在编辑和校验阶段实时提示作者。我一般会在项目启动的第一周就把 BREX 的第一版搭起来哪怕只有十几条规则因为它能立刻解决三个问题作者不用猜、审核有依据、交付时客户知道你的规则在哪儿。具体规则怎么写大致是这么个结构子要素以你所用 Issue 版本的 schema 为准brex identAndStatusSection !-- 头部DMC、版本、密级、来源等 -- /identAndStatusSection content structureObjectRule objectPath//step/objectPath objectUse1/objectUse brDecision允许使用但单个程序内步骤数不超过 25/brDecision /structureObjectRule /content /brex要注意的是BREX 的规则不是写得越多越好。我见过一个项目写了四百多条规则结果作者每写一句话就被弹十个提示最后大家集体把校验关掉了。比较实用的节奏是第一版只写会出人命和天天要用的规则跑三个月再根据实际返工数据往上加每加一条都要说清楚它挡住了什么具体的错误。2.5 发布物与 IETP数据模块怎么变成一本手册数据模块是原料客户拿到手的是成品。成品有两种形态一种是发布模块PM它本身也是一个 XML 文件内容就是一棵引用树按章节顺序把各个 DM 串起来形成一本手册的目录和结构另一种是数据模块清单DML用来交付一批 DM 的清单常见于数据交换场景。交付给客户的时候通常还会带上一份数据分发说明告诉对方这批内容包含什么、版本是什么、引用哪些外部内容。再往上就是IETP交互式电子技术出版物。它把 DM 和发布模块渲染成可交互的界面支持按配置筛选、按故障线索跳转、点图查件。IETP 一般按集成深度分成几个等级从最基础的翻页式电子书到能与诊断系统联动的深度集成等级越高对数据质量的要求越苛刻。我在实际项目中最大的体会是IETP 做得好不好八成取决于数据阶段的适用性和引用关系干不干净工具只占两成。数据里有一处适用性标错界面上就会出现这条步骤不知道该不该显示的尴尬。3. 从零跑通一个最小 S1000D 项目3.1 工具链选型从商业套件到命令行工具选型这事我建议按团队规模分两档来看。人数多、要交付给外部客户、还要做 IETP 的直接上成熟的商业套件省下来的是集成和培训时间人数少、想先验证方法的完全可以先用开源命令行工具跑通流程等流程稳定了再换。我自己的最小工具链是这样的编辑器支持 XML schema 校验的编辑器就行关键是要能挂上 S1000D 的 XSD边写边报错。校验xmllint做 schema 校验s1kd-tools这类社区命令行工具集做批量处理和 BREX 检查。转换Saxon 加 S1000D 官方提供的 XSLT 样式表把 DM 转成 HTML用来做走查和预览。版本控制Git。CSDB 用文件夹加 Git 完全能跑而且对比差异、回滚、分支管理都很顺手。流水线一个脚本串起校验 → 转 HTML → 生成发布包放进 CI 里每次提交自动跑。这套组合不花一分钱授权费缺点是没有图形化的 CSDB 管理界面、没有审批流。但对于摸清 S1000D 的数据模型来说这反而是优点因为每一步都是你自己拼出来的哪里不懂就得去翻规范。3.2 目录结构与文件命名目录结构没有唯一标准但我用下来最顺手的是按数据模块类型 系统码两级分csdb/ ├── dm/ │ ├── descript/ # 描述类数据模块 │ │ └── d10/ # 按系统码分目录 │ ├── proced/ # 程序类 │ ├── fault/ # 故障类 │ └── ipd/ # 图解零件类 ├── brex/ # 业务规则模块 ├── icn/ # 插图及其元数据 │ ├── images/ │ └── meta/ ├── pm/ # 发布模块 ├── dml/ # 数据模块清单 └── schema/ # 本地 schema 副本文件名严格按规范拼接形态大致是DMC-型号-差异码-系统分系统-装配件-拆分件变体-信息码变体-位置码_版本-在制标识_语言.xml比如DMC-DEMOPUMP-AAA-D1012-00-00A-040A-A_001-00_zh-CN.XML。这里有个细节文件名里的语言标签要用规范约定的写法别自己改成cn或者zh_CN否则你在做多语言合并的时候会被工具打回。手工拼名字一定会错我习惯写个小脚本从一张 CSV 里读字段生成文件名和 XML 头让机器去拼# build_dmc.py 根据字段表生成规范格式的 DMC 字符串 FIELDS [ modelIdentCode, systemDiffCode, systemCode, subSystemCode, subSubSystemCode, assyCode, disassyCode, disassyCodeVariant, infoCode, infoCodeVariant, itemLocationCode, ] def build_dmc(parts: dict) - str: missing [f for f in FIELDS if not parts.get(f)] if missing: raise ValueError(f缺少字段: {missing}) # 系统码分系统码分分系统码 在前缀里是拼在一起的 sysblock f{parts[systemCode]}{parts[subSystemCode]}{parts[subSubSystemCode]} disassy f{parts[disassyCode]}{parts[disassyCodeVariant]} info f{parts[infoCode]}{parts[infoCodeVariant]} return ( fDMC-{parts[modelIdentCode]}-{parts[systemDiffCode]} f-{sysblock}-{parts[assyCode]}-{disassy}-{info} f-{parts[itemLocationCode]} ) if __name__ __main__: demo { modelIdentCode: DEMOPUMP, systemDiffCode: AAA, systemCode: D10, subSystemCode: 1, subSubSystemCode: 2, assyCode: 00, disassyCode: 00, disassyCodeVariant: A, infoCode: 040, infoCodeVariant: A, itemLocationCode: A, } code build_dmc(demo) print(code) # DMC-DEMOPUMP-AAA-D1012-00-00A-040A-A print(f{code}_001-00_zh-CN.XML)这段代码看着简单但它帮我挡住了一类最烦的错误作者漏填某个字段或者位数不对。拼接口径和位数限制在规范的不同 Issue 版本里有细微差别落地前一定要对着项目实际使用的版本核一遍。3.3 手写第一个数据模块XML 骨架逐段拆解第一次写 DM别看完整 schema会晕。就盯着三块看头部标识、状态与适用性、内容体。下面是我用演示泵项目写的一个描述类 DM 的骨架删掉了大部分可选要素?xml version1.0 encodingUTF-8? dmodule xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:noNamespaceSchemaLocationschema/descript.xsd identAndStatusSection dmAddress dmIdent dmCode modelIdentCodeDEMOPUMP systemDiffCodeAAA systemCodeD10 subSystemCode1 subSubSystemCode2 assyCode00 disassyCode00 disassyCodeVariantA infoCode040 infoCodeVariantA itemLocationCodeA/ language languageIsoCodezh countryIsoCodeCN/ issueInfo issueNumber001 inWork00 date2024-05-06/ /dmIdent dmAddressItems issueDate year2024 month05 day06/ dmTitle techName液压泵/techName infoName概述与工作原理/infoName /dmTitle /dmAddressItems /dmAddress dmStatus issueTypenew security securityClassification01/ responsiblePartnerCompany enterpriseName示例企业/enterpriseName /responsiblePartnerCompany originator enterpriseName示例企业/enterpriseName /originator applic assert applicPropertyIdentvariant applicPropertyTypeprodattr applicPropertyValuesA/ /applic brexDmRef dmRef dmRefIdent dmCode modelIdentCodeDEMOPUMP systemDiffCodeAAA systemCodeD10 subSystemCode1 subSubSystemCode2 assyCode00 disassyCode00 disassyCodeVariantA infoCode022 infoCodeVariantA itemLocationCodeA/ /dmRefIdent /dmRef /brexDmRef /dmStatus /identAndStatusSection content description para液压泵安装在动力单元右侧支架上为整个液压回路提供压力油源。/para para泵体由壳体、齿轮组、驱动轴和密封组件构成工作时由驱动轴带动齿轮组旋转……/para /description /content /dmodule几个必须说的点。第一元素顺序是 schema 硬约束的。dmStatus下面那一串子元素的先后顺序不能乱我第一次写的时候把applic放到了brexDmRef后面schema 直接报错排查了半小时。所以上面这段骨架你在正式用之前一定拿你们的 schema 验一遍不同 Issue 版本顺序有差异。第二brexDmRef是必填的在大多数项目的业务规则里都是它指向本项目的业务规则模块。这个引用一旦挂上后续所有校验都以那份规则为准所以 BREX 的版本管理要和 DM 的版本管理一样严格。第三applic是适用性的核心。上面这条断言的意思是本模块适用于构型 A 的产品。真实项目里适用性断言的属性来自产品属性表可能有构型、批次、序列号区间、软件版本好几个维度多个断言之间还有与或关系。这一块是 S1000D 里最容易出错的部分我后面会专门讲。第四语言标签是双字段的语言码加区域码两者都要写对否则多语言交付时会错配。3.4 校验、组装与转 HTML 的完整流水线写完一个 DM第一件事不是给人看是让机器看。我用得最多的校验命令是# 逐文件做 schema 校验离线 schema 优先避免网络问题 for f in csdb/dm/**/*.XML; do xmllint --noout --schema csdb/schema/descript.xsd $f \ || echo FAIL: $f done这个循环看着土但加上 CI 之后非常有效。它至少能挡住三类错误元素顺序错、必填要素缺失、属性取值越界。我建议把校验分成两层跑schema 校验放在每次提交时跑BREX 校验放在每晚构建时跑前者快后者要加载规则引擎、耗时长。转 HTML 我用 Saxon 加官方的 XSLTjava -jar tools/saxon9he.jar \ -s:csdb/dm/descript/d10/DMC-DEMOPUMP-AAA-D1012-00-00A-040A-A_001-00_zh-CN.XML \ -xsl:tools/s1000d-to-html.xsl \ -o:build/pump-description.html做完这两步一个最小的 S1000D 流程就算跑通了写 DM → schema 校验 → BREX 校验 → 转 HTML 预览 → 组装进发布模块 → 打包交付。等到这一步跑顺了再考虑上商业工具、做 IETP、搞多语言合并路会清楚很多。反过来先买工具再学规范大概率是把工具的坑和规范的坑一起吃下去。4. 常见问题与排查技巧实录4.1 校验报错速查表下面这张表是我这几年真正遇到过的、出现频率最高的几类问题直接拿去当排查清单用现象大概率原因处理办法schema 校验报元素顺序错误dmStatus下子要素顺序不符合当前 Issue 版本的 sequence对照本项目 schema 里的定义顺序调整别照抄网上的例子工具报找不到引用的数据模块dmRef里的 DMC 与被引用文件名不一致或引用的版本还没发布用脚本批量比对 DMC 与文件名检查引用目标的状态标记IETP 里出现重复步骤itemLocationCode用错同一物品不同位置的内容都被选中逐条核对位置码确认每条内容的位置归属多语言合并时内容错配语言标签写法不统一或issueNumber不一致统一语言标签写法合并前强制校验版本号一致文件在服务器上消失扩展名大小写不一致.xml与.XML混用统一用大写扩展名加一条流水线规则兜底内容明明适用却不显示适用性断言属性值拼写与产品属性表不一致属性值必须从产品属性表里取禁止手工输入这张表里我最想强调最后一条。适用性断言里的属性值看起来就是个字符串实际上它是和产品属性表严格对应的键。手输一次拼错一个字母内容就凭空消失而且不报错等到客户投诉才发现。解决办法只有一个属性值做成下拉选择或者从属性表里查绝不给人手输的机会。4.2 版本迁移与项目落地的两个大坑第一个坑是版本迁移。从 Issue 4.x 的一个小版本升到另一个或者从 4.x 升到 5.0schema 会有差异元素增删、属性改名、校验规则变严都是常事。我见过一个团队直接拿新版 schema 去校验旧项目的数据结果一次跑出两千多个错误团队直接崩溃。正确的做法是分三步走先做差异分析把新旧 schema 的变更点列出来再做影响面扫描用脚本统计哪些 DM 用到了受影响的元素最后做分批迁移先迁一个系统跑通校验和渲染再推广。整个过程最好预留三个月以上别信两周搞定的说法。第二个坑是组织层面的比技术坑更疼。S1000D 项目里写内容的作者往往不懂 XML懂 XML 的工程师往往不懂设备。我见过最典型的失败模式是技术部门买了一堆工具培训了两天然后发现没人知道该怎么拆数据模块最后写出来的东西是一个 DM 装一整章结构化的收益几乎为零。我总结的落地顺序是这样的先定 SNS系统编号体系→ 再定信息码清单和数据模块类型 → 再定 BREX 第一版 → 再培训作者 → 最后才谈工具和 IETP。工具永远放在最后因为它是最容易被替换的一环而体系一旦定错返工的就是全部内容。另外一定要设一个SNS 管理员的角色专门管编码体系和信息码清单谁都不许自己发明编码。这个角色在我参与的项目里是投入产出比最高的一个岗位。4.3 我踩过之后总结的几条实操心得先说图片。S1000D 里插图不是一个文件那么简单它要配一份元数据文件说明图的编号、尺寸、适用性、版权等。图片格式上矢量图是首选位图只作为补充因为 IETP 会放大缩小位图放大了就糊。我吃过一次亏几百张位图插图在交付时才发现分辨率不够被迫重新出图工期直接拖了两周。建议在项目早期就把插图规范和出图工具链定下来并且要求插图编号和 DMC 结构对齐否则后期挂图会变成纯体力活。再说引用管理。DM 之间会互相引用引用一多就会出现引用了一个已被删除的模块这种问题。我的做法是写一个定时任务扫全库把引用关系画出来找出孤立节点和断链。这张引用图还有一个额外好处当某个模块要改版本时你能立刻知道有哪些下游内容需要同步验证。还有一个很实用的小技巧给每个 DM 加一份变更影响记录。不是为了交付是为了自己。内容改了什么、为什么改、影响哪些引用、谁验证的记在一个独立文件里和 DM 一起进版本库。等到三年后有人问你这个扭矩值为什么从 45 改成 50你能三分钟内给出答案。这种能力在长周期项目里价值比任何工具都高。提醒别指望一次把 BREX 和适用性体系做完美。先做能挡住 80% 常见错误的那 20% 规则剩下的靠实际返工数据迭代。规范是死的项目是活的。最后分享一个我自己的体会S1000D 最难的部分从来不是 XML而是内容边界的划分和适用性的判断。这两件事都需要对设备本身有理解光看规范文档是学不会的。我当时最快的进步方式是拿一台自己熟悉的设备从零拆出三十个数据模块然后拿 schema 和自己定的规则一遍遍校验被报错折磨一个星期基本就通了。