题干与适用场景
团队希望用 YAML-LD 编写数据契约和知识图谱配置，同时继续向现有 JSON-LD 消费者供数。请说明如何验证语义等价、处理 YAML 特性限制、保障解析安全并设置采用闸门。
W3C YAML-LD 1.0 当前是 Working Draft。规范将 YAML-LD 定义为建立在 YAML 之上的约定，沿用 JSON-LD 的语法、语义和 API，并限制部分更丰富的 YAML 特性，使每个 YAML-LD 文档都能表示为 JSON-LD。题目考察数据格式迁移和互操作性，不要求假设草案已经成为最终标准。
面试官考察点
面试官会关注你是否区分 YAML 表面语法与 JSON-LD 图语义，能否建立规范化、差异比对、解析安全和版本治理流程。高质量回答还会指出 Working Draft 不等于稳定承诺，不能只用“看起来更易读”证明采用价值。
回答前需要澄清的问题
- 数据消费者是直接读取 YAML，还是只接受 JSON-LD RDF 图？
- 需要支持哪些 JSON-LD 关键字、上下文、远程文档和命名空间？
- 是否存在锚点、别名、自定义类型、时间戳等 YAML 特性？
- 解析环境、信任边界、资源上限和远程
@context策略是什么？ - 兼容窗口、版本协商、回滚和最终采用人是谁？
30 秒回答框架
“我会把 YAML-LD 当作 Working Draft 的输入格式，先固定支持子集和 JSON-LD 版本。每个样例同时经过安全 YAML 解析、YAML-LD 约束校验、转 JSON-LD、RDF 数据集规范化和语义差异比对；拒绝无法表达为等价 JSON-LD 的特性。远程上下文采用白名单和缓存，限制别名、深度、大小和别的资源访问。新格式先以只读双写或影子解析灰度，只有图语义、错误行为、性能和安全闸门都通过才扩大。”
分步骤深入解答
1. 明确输入输出契约
把 YAML-LD 文件、生成的 JSON-LD、RDF 数据集和消费者 API 版本写入契约。固定支持的 JSON-LD 关键字、上下文来源、字符编码和数值规则，禁止把任意 YAML 当作 YAML-LD。草案更新时记录规范版本和测试集版本，避免同一文件在不同解析器上产生隐式差异。
2. 先限制 YAML 特性
W3C 说明 YAML 比 JSON 表达力更强，因此 YAML-LD 只支持可映射到 JSON-LD 的约束子集。拒绝或显式禁止自定义标签、不可预测的时间戳类型、循环别名和实现特有类型；锚点与别名只有在展开后结构和 JSON 表示稳定时才允许。把限制编成机器可执行的 lint 规则，而不是依赖作者记忆。
3. 验证图语义而非文本相似
先安全解析 YAML-LD，再转换为 JSON-LD，展开上下文后生成 RDF 数据集，使用规范化算法比较三元组或四元组集合。属性顺序、YAML 缩进和 JSON 键顺序不应影响结论；节点标识、语言标签、类型和列表顺序必须被单独检查。出现语义差异时保留最小复现样例，禁止用字符串 diff 掩盖问题。
yaml = safe_parse(input, aliases=false, max_depth=32, max_bytes=1048576)
yaml_ld = validate_yaml_ld_subset(yaml)
json_ld = to_json_ld(yaml_ld)
left = normalize_rdf(json_ld)
right = normalize_rdf(reference_json_ld)
assert left == right4. 设计解析安全边界
禁止任意文件、网络和代码执行能力；远程 @context 只允许白名单 URL，使用固定版本缓存和大小上限。限制文档大小、嵌套深度、别名展开、解析时间和内存，记录解析器版本与上下文哈希。解析失败应返回结构化错误和定位信息，不把未验证数据写入知识图谱或下游仓库。
5. 兼容现有消费者
为每个 JSON-LD 消费者建立兼容矩阵，测试上下文解析、类型、语言标签、列表、空值和未知字段。接入初期保留 JSON-LD 作为规范输出，YAML-LD 只作为作者输入或影子路径；比较转化失败率、图差异、延迟、缓存命中和资源消耗。消费者不支持的特性要在 CI 中提前阻断，而不是线上静默降级。
6. 设置采用闸门和回滚
预先定义语义一致率、关键样例通过率、安全扫描、解析 p95、资源上限和消费者错误率。Working Draft 发生规范变化或测试集回归时暂停扩大，保留旧 JSON-LD 生成器、上下文缓存和输入版本。正式采用前需要重复测试、升级演练、审计记录和数据负责人批准，不能把草案状态写成标准稳定性承诺。
高质量示范回答
我会先把 YAML-LD 1.0 Working Draft 当作受控输入格式，固定支持的 JSON-LD 版本、关键字、上下文和 YAML 子集。流水线使用安全解析器限制大小、深度、别名和网络访问，校验后转换为 JSON-LD，再展开上下文并规范化 RDF 数据集，与现有 JSON-LD 基准比较图语义；键顺序和缩进差异不能导致失败，但节点标识、类型、语言标签和列表顺序必须一致。远程上下文使用白名单、固定版本缓存和哈希审计。接入初期保留 JSON-LD 规范输出，YAML-LD 走影子解析，按语义差异、解析错误、p95 延迟、内存和消费者错误率设置闸门。任何无法等价表示的 YAML 特性、安全扫描失败或草案升级回归都暂停，并回滚到旧生成器。最终批准要基于版本化测试集和数据负责人签字，不能把 Working Draft 当成最终标准。
常见错误
- 把 YAML 更短或更易读当作互操作性证明 → 可读性不等于图语义等价 → 比较规范化 RDF 数据集。
- 直接使用通用 YAML 反序列化器 → 可能接受超出 YAML-LD 子集的类型或别名 → 启用安全模式和约束 lint。
- 只做文本 diff → 键顺序和缩进会制造假差异 → 比较节点、类型、语言标签、列表和四元组。
- 允许远程上下文任意访问 → 供应链、可用性和版本漂移不可控 → 白名单、缓存、哈希和资源上限。
- 把 Working Draft 当稳定标准 → 草案可能继续变化 → 版本化测试集、灰度和可回滚输出。
追问及应对
为什么不能把所有 YAML 特性都保留？
规范目标是让 YAML-LD 文档可表示为 JSON-LD；无法稳定映射的类型、标签或循环结构会破坏互操作性，应拒绝或等待扩展 Profile。
如何判断两个文档语义相同？
转换并展开上下文后生成规范化 RDF 数据集，比较节点标识、谓词、对象、类型、语言标签和列表顺序，而不是比较原始文本。
远程 @context 为什么要缓存和白名单？
它会影响解析结果并引入网络、供应链和版本漂移风险；固定来源、版本、哈希和超时才能复现和回滚。
什么时候可以让 YAML-LD 成为写入主路径？
约束验证、语义差异、安全扫描、性能、消费者兼容和回滚演练连续通过，并且草案版本、测试集和变更负责人都已锁定后再决定。
如果规范更新导致少量图差异怎么办？
暂停扩大，保存最小复现、规范版本和上下文哈希，评估是否属于预期语义变化；在兼容策略和数据负责人批准前继续输出旧 JSON-LD。