題干與適用場景
請設計一個根據 RDF 資料圖與 SHACL 形狀圖自動產生編輯表單的渲染器。你會如何確定焦點節點與根形狀、聚合屬性約束、選擇控制項、處理多語言標籤，並確保驗證結果可解釋？
題目對應 W3C 於 2026 年 5 月 26 日發布的 SHACL 1.2 User Interfaces 首個公開工作草案。它把 SHACL 形狀與約束用於產生 RDF 資源的檢視、編輯介面，並定義元件、標籤解析、版面提示與控制項評分等處理模型。草案仍可能變更，面試中應把規範邊界與產品實作邊界分開。
面試官考察點
面試官會看你能否把形狀圖、資料圖、焦點節點與節點形狀建立清楚資料流，能否處理同一路徑上的多條屬性形狀，能否讓控制項選擇可擴充且具確定性。也要說明語言回退、失敗可解釋性、快取失效、權限與提交交易邊界。高品質答案會指出規範沒有定義視覺樣式、提交協定、完整驗證流程或無障礙要求，這些要由應用補足。
回答前需要澄清的問題
- 輸入只有資料圖與形狀圖，還是呼叫方也會傳入焦點節點與根節點形狀？
- 這是檢視、編輯還是查詢模式？是否允許一個焦點節點符合多個形狀？
- 控制項目錄由誰維護，評分圖是否可由租戶擴充？
- 標籤的偏好語言、回退語言與無標籤時的本地名稱規則是什麼？
- 儲存是否需要原子交易、並行控制、權限檢查與獨立 SHACL 驗證？
30 秒回答框架
「我會把系統分成輸入解析、形狀索引、元件產生、控制項選擇、標籤解析、驗證展示與提交適配層。渲染器至少接收資料圖、形狀圖、焦點節點與節點形狀；若缺少後兩者，由應用層執行自動選擇並明確標示不確定性。屬性元件按焦點節點與屬性路徑聚合約束，再用明確控制項、接受匹配器與評分函式決定控制項。所有選擇記錄規則與分數，標籤按使用者語言回退。規範只負責渲染處理，儲存、授權、交易與視覺樣式由應用定義。」
分步驟深入解答
1. 固定輸入與執行模式
將資料圖、形狀圖、焦點節點與節點形狀作為明確輸入。四者齊全時是手動模式，缺少焦點節點或節點形狀時才進入自動模式，並把自動選擇結果寫入診斷資訊。檢視與編輯可共用形狀解析，但編輯器還需要髒狀態、復原與並行策略。
2. 建立形狀與路徑索引
預處理節點形狀、屬性形狀、目標宣告、屬性路徑與約束元件，索引鍵至少包括形狀 IRI、焦點節點與路徑。對同一焦點節點、同一屬性路徑的多個屬性形狀做約束聚合，保留來源與嚴重程度，避免一條約束靜默覆蓋另一條。
3. 產生節點與屬性元件
節點元件代表一個焦點節點，屬性元件代表該節點某條路徑的合併約束。先按形狀確定欄位集合，再套用分組、排序、角色與條件形狀。複雜路徑必須保留可編輯語意；若路徑無法安全映射到單一欄位，應降級為唯讀檢視器或要求產品明確提供編輯策略。
4. 選擇控制項並保證確定性
優先檢查形狀上明確指定的控制項及其接受匹配器；匹配失敗後呼叫評分函式，從評分圖取得候選控制項，再按穩定的分數、優先級與 IRI 順序決勝。評分函式輸入包括焦點節點、資料圖、形狀圖、屬性形狀與評分圖。缺少必要輸入或評分實例格式錯誤時，應回傳結構化錯誤，而不是渲染猜測控制項。
explicit widget -> accept matcher -> score candidates -> stable tie-break
-> label resolution -> component tree -> validation messages5. 處理語言與標籤回退
標籤解析同時查看形狀圖、資料圖、應用環境與使用者偏好。先選擇偏好語言，再按設定的回退順序尋找語言值；沒有合適標籤時用 IRI 的本地名稱或產品定義的安全佔位符。欄位標籤、列舉值與驗證訊息應使用同一套語言上下文，並記錄最終選取來源，方便排查跨語言不一致。
6. 把驗證與儲存放在正確邊界
SHACL UI 草案描述控制項產生與處理，不定義提交協定、儲存交易、完整錯誤處理或權限模型。應用應在提交前後呼叫獨立驗證器，展示 focus node、路徑、約束元件與訊息來源。儲存採用版本號或條件寫入避免覆蓋並行修改；失敗時保留使用者編輯狀態與可重試的結構化結果。
7. 觀測、快取與安全
形狀圖變更會使元件與控制項快取失效，快取鍵應包含形狀版本、資料圖版本、語言與權限上下文。限制遠端 IRI、HTML 富文字與自動完成來源，避免把不受信任 RDF 直接變成腳本或連結。記錄形狀選擇、控制項決策、驗證耗時與降級原因，但不要把完整敏感圖資料寫入日誌。
高品質示範回答
我會先約定渲染器的四個輸入：資料圖、形狀圖、焦點節點與節點形狀；若缺少後兩者，由上層執行自動選擇並回傳可解釋的選擇結果。預處理階段建立節點形狀、屬性形狀與路徑索引，對同一焦點節點與路徑的約束做可追溯聚合。元件樹產生後，控制項選擇先看明確控制項與接受匹配器，再執行評分函式，並用穩定的分數、優先級與 IRI 順序解決平分。標籤解析按使用者偏好語言與回退語言從形狀圖、資料圖及環境中選值，沒有值時使用安全的本地名稱。每個決定都記錄規則來源，驗證結果關聯焦點節點、路徑與約束。儲存、權限、並行與交易放在應用層，規範沒有定義的視覺樣式、提交協定與無障礙要求也由產品明確補足。這樣既能跨實作產生一致表單，也能在規範草案變更時替換適配層。
常見錯誤
- 把 SHACL UI 當成完整低程式碼平台 → 忽略規範範圍 → 明確區分渲染、驗證、儲存與權限邊界。
- 只取第一條屬性形狀 → 多約束被靜默遺失 → 按焦點節點與路徑聚合並保留來源。
- 控制項選擇隨機或依賴遍歷順序 → 同一輸入產生不同介面 → 定義評分、優先級與穩定決勝。
- 標籤只讀
rdfs:label→ 多語言與回退失效 → 實作語言解析並記錄選取來源。 - 把 RDF 文字直接當 HTML → 產生腳本注入風險 → 對不受信任值轉義並限制檢視器能力。
- 提交成功就關閉表單 → 並行或驗證失敗遺失編輯 → 使用版本條件寫入並保留失敗狀態。
追問及應對
如果焦點節點符合多個根形狀怎麼辦？
讓應用提供明確選擇器或業務優先級；渲染器只在規則足夠確定時自動選擇，並把候選與原因回傳給呼叫方，不把遍歷順序當成業務規則。
評分相同的兩個控制項如何決勝？
先比較明確接受規則與產品優先級，再用穩定的控制項 IRI 或註冊順序決勝；把決勝規則版本化，避免部署後介面漂移。
為什麼不在渲染器內部儲存 RDF？
渲染器可以管理編輯狀態，但提交協定、交易、權限與衝突解決屬於應用資料層。分離後可重用渲染器，也能讓伺服器再次驗證不受信任輸入。
複雜屬性路徑無法映射到輸入框怎麼辦？
先展示唯讀路徑與值，指出缺少編輯策略；只有產品提供安全的讀寫轉換與衝突處理後才開放編輯，避免做出看似可寫卻無法持久化的欄位。
如何測試跨實作的一致性？
固定資料圖、形狀圖、語言偏好與評分圖，斷言元件樹、標籤來源、控制項 IRI、排序與錯誤分類；再用規範測試套件與屬性級回歸樣例覆蓋降級路徑。