題干與適用場景
團隊希望用 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。