介設計XML的目的是創建基於自描述標記的語言。這些語言的必然演變稱為版本管理。版本管理意味著添加、刪除或修改語言的一些部分。使版本管理實際可用是計算中最困難的問題之一，長時間內嘗試多次均失敗了。Web 興起和流行的一個可能原因，是因為演變和版本控制被內建到HTML和HTTP報頭中，這兩者都為理解實現其分散的擴展和版本管理的擴展提供了明確的擴展點和規則。 XML Namespaces為識別語言的各種版本提供了一個理想的機制，而所有的XML schema語言（如W3C XML Schema）規定了受控的擴展性。本文描述了在系統間實現更有效的松散耦合的多種技術，這些技術提高了當相關系統演變時向後兼容和向前兼容變更發生的可能性。這些技術針對具有或不具有schema傳播的可兼容變更而設計。許多規則被描述用於XML詞匯的版本管理，利用XML Namespaces和XML Schema結構。它包括與提供擴展容器模型的語言協同工作的規則，特別是SOAP。該規則集被稱為擴展性的“必須忽略（Must Ignore）”模式。奇怪的是，用於HTML標記和HTTP 報頭的“必須忽略”模式明顯地促進了它們的采用，但還沒有被XML從業者廣泛采用。本文的目標是為當前的Schema驗證環境糾正這種情況。後面的材料將討論創新的不嚴格的schema驗證環境。定義兼容性 FOLDOC [1]提供了向後和向前兼容性的定義。本文將重復這些定義，並重點討論消息的動作，特別是發送方和接收方，而不是客戶端和服務器。向後兼容性意思是可以推出一個新版本的接收方，不會中斷現有的發送方。這意味著發送方能夠向理解新版本消息的接收方發送老版本的消息，而接收方仍能夠成功地處理該消息。向前兼容性意思是老版本的接收方能夠處理新消息而不中斷。當然老版本將不會實現任何新的行為，但發送方能夠發送新版本的消息，並且仍能夠成功處理它。換句話說，向後兼容性意味著現有的發送方能夠使用已經更新的服務，向前兼容性意味著較新的發送方能夠繼續使用現有服務。向前兼容變更典型情況下涉及添加可選的元素和/或屬性。與引入非向前或向向後兼容的變更相關的成本經常很高，典型情況下需要所部署的軟件進行更新來適應新的版本。下面描述的規則優化了進行向前和向後兼容變更的情況。本文認為這意味著不變更命名空間名稱或變更元素名稱。兼容性是針對單個消息的發送方和接收方來定義的。然而，大多數web服務規范提供輸入和輸出的定義。在兼容性的這些定義中，一個更新了其輸出schema的web服務被認為是一個新發送方。當將兼容性定義應用到輸出消息時，它簡單地反轉輸入消息的發送方/接收方術語。如果一個接收方更新了輸出消息的schema，那麼它正在“發送”一個新版本的消息，因此它被認為是一個“發送方”。識別和擴展語言典型情況下，在語言中設計擴展性會導致一個更加松散耦合的系統。擴展性允許發送方變更實例而無需通過集中授權。這樣，第一個與擴展性相關的規則是： 1. 允許擴展性規則：語言應設計為具有擴展性。對擴展性的一種基本要求是能夠確定元素和屬性的語言。XML Namespaces[14]提供了一種將URI和XML元素或屬性名稱相關聯的機制，以此指定名稱的語言。這也能夠防止名稱沖突。 W3C XML Schema[15]提供了一個稱為通配符（（）的機制，用於控制來自某些命名空間的元素允許的位置。通配符指出指定命名空間中的元素被允許存在於通配符出現的實例文檔中。這考慮到了以後schema以嚴格定義的方式進行擴展。擴展文檔的接收方能夠識別它們不理解的擴展並根據擴展的處理模型將其安全地忽略。 使用namespace屬性來控制擴展元素能夠來自於什麼命名空間。該屬性的主要值包括：##any，這意味著可以使用來自任何可能的命名空間的元素來擴展schema；##other，它只允許來自除當前命名空間之外的命名空間的擴展元素；##targetnamespace，它只允許來自當前命名空間的擴展元素。 使用processContents屬性來控制XML parser如何驗證擴展元素。允許的方法包括："lax"，允許驗證發生；"strict"，需要驗證；"skip"，跳過驗證。本文使用"lax"驗證，因為它最靈活，而且是web服務規范的典型選擇。擴展性的"Must Ignore"模式的主要目標是允許對文檔的向後和向前兼容變更。最少情況下，這意味著既不修改也不添加命名空間名稱，也不變更元素名稱。在目標命名空間中添加元素名稱只能使用##any命名空間或一個##other命名空間和詞匯的目標命名空間的組合來完成。許多例子說明了這些規則的應用。想象一下一個定購單從一個機器發送到另一個機器。定購單的處理會生成一個“裝運”的消息。但這個消息在接收到定購單一段時間後才發送。發送軟件必須為響應（同步消息）而等待一些時間，這很不方便。更好的模型是接收方能夠自己控制發送“裝運”消息，不需要等待。接收方“回調”最初的發送方，因此得出術語“回調”。發送方在回調地址中向接收方提供一個地址。這表示接收方向發送方發送任何後續消息應該使用的地址。在web服務中，這個Callback典型情況下會作為一個SOAP 報頭塊來發送。我們的優先選擇是使用一個##any的可擴展樣式。使用該模型的回調類型如下： 示例 1 – 一個使用##any實現擴展性的schema 然而，W3C XML Schema的決定約束（後面會更詳細介紹）會阻止該模型工作。當回調的後續版本添加一個可選元素時，問題就出現了。超時就是一個很好的例子。回調的超時對於接收方是一段內容豐富的信息。如果接收方不理解超時，那麼它們能夠繼續處理。下面的schema大約是使用通配符所期望的，但是由於決定約束，它是非法的： 示例 2 – 一個非法的schema 由於該模式無法工作，為了達到最初目標，我們需要創建一個大致等效的設計模式。為了在同一個命名空間中允許新擴展，作者必須創建一個在同一個命名空間中允許擴展的擴展類型。擴展類型應當只被用於同一個命名空間中的未來兼容擴展。我們需要兩個或更多規則來允許XML語言定義的適當版本管理。首先是命名空間的規則： 2. 任意命名空間規則：擴展點應該考慮任意命名空間中的擴展。對於XML Schema應用程序，擴展點應當是一個考慮了目標命名空間中的擴展的元素，一個考慮了任何其它命名空間中的擴展的通配符。允許擴展性的規則： 3. 完整擴展性規則：所有XML元素都應該考慮元素定義後的元素擴展性，並且允許任意屬性。一個遵守這些規則的回調類型的例子： 示例 3 – 一個具有擴展性的回調類型因為目標命名空間中的每個擴展都在擴展元素中，所以每個後續目標命名空間將增加被另一層的嵌套。盡管每個擴展的嵌套層不是所期望的，它是今天在應用嚴格W3C XML Schema驗證時能夠完成的。如果能夠為一種語言完成多種可兼容的修改版本，那麼擁有多個嵌套元素看來也是值得的。這種技術允許在保持目標命名空間本身驗證的同時，在目標命名空間中進行擴展的驗證。總的來說，一個擴展可以由一個新規范定義，該規范對以前的規范進行標准參考，然後定義新元素。制作這樣一個擴展不需要來自規范編撰者的允許。實際上，XML命名空間的主要設計點是允許分散擴展。推論是對於在同一個命名空間中的擴展，許可是必需的。命名空間有一個擁有者，修改某事物含義的非擁有者可能是有害的。理解擴展發送方理想情況下應該能夠用新元素擴展現有的XML文檔，而不需要接收方修改現有的實現。擴展是邁向這一目標的一個步驟，但達到兼容性也需要一個用於擴展的處理模型。軟件在遇到擴展時的行為應該清楚。這樣，我們引入下一個規則： 4. 提供處理模型規則：語言應該指定一個處理模型來用於處理擴展。使兼容修改成為可能的最簡單的處理模型是忽略不理解的內容。這個規則是： 5. 必須忽略規則：文檔接收方必須忽略有效XML文檔中它們無法識別的XML屬性和元素。該規則不要求以物理方式刪除元素，只是為處理目的忽略它們。有許多“必須忽略”規則的著名用法。HTML 1.1、2.0和3.2遵守必須忽略規則；它們指定在分段化（tokenization）過程中將任何未知的開始標簽或結束標簽映射為無。HTTP 1.1[6]指定接收方應該忽略任何它不理解的報頭：“無法識別的報頭字段應該被接收方忽略，並且必須被透明代理轉發。”XML的必須忽略規則在1997年由WebDAV工作組首次引入[19]，在WebDAV規范RFC 2518 [5] section 14中標准化，後來作為Flexible XML Processing Profile單獨發布[2]。有兩種與處理擴展相關的主要詞匯表類型。這些類型是面向數據的，是演示（或文檔）應用程序。對於面向數據的應用程序，例如web服務，規則是： 6. 必須全部忽略規則：三必須忽略規則應用於無法識別的元素和它們的後代元素。例如，如果一個在SOAP 報頭塊中具有無法識別元素的消息被接收到，它們必須被忽略，除非被標記為“mustUnderstand”（參閱下面的規則10），但期望將無法識別的元素寫到日志文件中是合理的。面向文檔的詞匯表可能需要一個不同的規則，因為該應用程序通常需要表示未知元素的內容。針對面向文檔的應用程序的規則是： 7. 必須忽略容器規則：必須忽略規則只應用於無法識別的元素它保留元素的後代元素，例如用於顯示目的的元素。一種語言可能為處理擴展提供一種不同的模型，而不是忽略無法識別的組件。一個模型是，如果接收方發現一個無法理解的組件，它將產生一個故障。例如接收方必須理解任何擴展的一個安全規范。這需要忍受顯著的缺點：它不允許在語言中發生兼容修改；修改不能被忽略。另一個模型是一個備用模型，如果接收方部理解擴展，替代元素將被提供。XSLT 2.0提供了這樣一個模型。版本管理當需要一個新版本的語言，並且它與舊語言向後兼容時，那麼作者必須為新語言中的名稱決定命名空間名稱。有兩個選擇：創建一個新命名空間或重用現有的命名空間名稱。我們認為重用更加有效，我們將在“新命名空間”部分探究選項#1的問題。重用命名空間規則是： 8. 重用命名空間名稱規則：如果對規格進行了向後兼容變更，那麼舊的命名空間名稱應該與XML的擴展性模型一起使用。一個重要的結論是，新命名空間名稱只在進行不兼容變更時才需要。 9. 新命名空間中斷規則：在不允許向後兼容時使用一個新命名空間名稱，如果軟件不理解新語言組件，它必須中斷。非向後兼容修改典型情況下以兩種方式發生：添加一個所需信息項；或變更一個現有信息項的語義。重用命名空間規則要求遵守前面的“必須忽略”和“任意命名空間”規則。如果不遵守這些規則，那麼將阻止語言設計者進行兼容變更和重用命名空間。我們已經強調為可兼容擴展重用命名空間名稱是很好的做法。相反的情況是命名空間擁有者能夠通過提供允許其他命名空間的擴展點（）來為兼容變更使用新命名空間。該技術有一個問題：在不同命名空間中的擴展意味著組合schema不能被完全驗證。特別是，沒有方法創建一個約束通配符的新schema。例如，想象ns1包含foo和bar，是不可能采用SOAP schema（一個使用通配符的schema示例）並要求ns1:foo元素必須是報頭元素的子元素，ns1:bar必須不是只使用W3C XML構件的報頭元素的子元素。確實，對於該功能的需求產生了一些WSDL功能。新命名空間名稱方法導致不適當分解的規格和命名空間，因為相關的結構將位於分開的命名空間中。進一步講，重用相同命名空間具有較好的工具支持。許多應用程序使用單一schema來創建等價的編程結構。這些工具經常與對“所生成”結構的單一命名空間支持一起工作得最好。命名空間名稱的重用至少允許命名空間作者對命名空間進行變更，並執行對擴展的驗證。默認處理模型重寫假定采用了必須忽略規則，常有的情況是：擴展的創建者要求重寫必須忽略規則而使接收方能理解擴展。 10. 提供mustUnderstand規則：容器語言應該提供一個“mustUnderstand”模型，用於處理重寫默認必須忽略規則的擴展的可選性。該規則和必須忽略規則一起工作來為擴展提供穩定的、靈活的處理模型。最簡單和最靈活的重寫技術一個指示項目是否必須被理解的mustUnderstand 標志。指定理解的SOAP[7]、WSDL[8]和WS-Policy[10]屬性以及值分別是： soap:mustUnderstand="1"，wsdl:required="1"，wsp:Usage="wsp:Required"。 SOAP可能是提供mustUnderstand模式的容器的最常見情況。默認值是0，是必須忽略規則。一個mustUnderstand標志允許發送方將擴展插入到容器中，並使用mustUnderstand屬性來重寫必須忽略規則。這允許發送方在不改變擴展元素的父元素的命名空間的情況下擴展消息，保持向後兼容性。顯然，接收方必須被擴展以處理新擴展，但當前在語言處理模型和擴展的處理模型之間有一個松散耦合。有其他可能的技術，如提供一個元素來指示哪些擴展命名空間必須被理解。在有些情況下，一種語言不提供mustUnderstand機制。在缺少mustUnderstand模型時，如果接收方不理解擴展命名空間，沒有方法迫使接收方拒絕一個消息。確定性 XML DTDs和W3C XML Schema擁有一個規則，要求schema具有確定性的內容模型。下面的例子來自XML 1.0規范。例如，內容模型 ((b, c) | (b, d))是非確定性的，因為給出了一個初始b，XML處理器在不向前查看哪一個元素緊跟b的情況下，不知道模型中的哪一個b是匹配的。 ##any的使用意味著存在一些我們可能希望表達的schema，但不被允許。 · 使用##any的通配符（這裡minOccurs不等於maxOccurs），在元素聲明之前不允許。該元素的一個實例將對於##any或該元素有效。可以使用##other。 · 在使用##any的通配符之前的元素必需有maxOccurs的基數，它等於其minOccurs。如果不一樣，譬如minOccurs="1"和maxOccurs="2"，那麼可選的事件會與該元素定義或##any相匹配。作為該規則的結果，minOccurs必須大於0。 · 必須避免使用在使用##any的通配符後添加元素定義的導出類型。導出類型可能在通配符後添加元素定義，然後所添加元素定義的實例可能與通配符或導出元素定義相匹配。 11. 確定性規則：通配符的使用必須是確定性的。通配符的位置、通配符擴展的命名空間、minOccurs和maxOccurs的值是受約束的，類型限制是受控的。如前面所示，通用設計模式將提供一個擴展性點——而不是一個元素——以允許類型末端的任何命名空間。典型情況下，這可以通過來做到。在許多情況下確定性使此無法作為一個完整解決方案工作。首先，擴展點只能出現在原有schema中的所需元素後，將擴展性的范圍限制在原有schema中。其次，向下兼容變更要求所添加的元素是可選的，這意味著minOccurs="0"。確定性防止我們將一個minOccurs="0"放置在##any的擴展點前。這樣，當在一個擴展點添加一個元素時，作者能夠使該元素可選，喪失擴展點，或者作者使該元素成為必需的，並喪失向後兼容性。這為什麼困難？我們已經說明了，通過完全利用但不需要新schema定義的兼容變更，使用XML和W3C XML Schema來達到松散耦合是困難的。遵守這些擴展性規則導致W3C XML Schema文檔更加笨重，同時也更缺少表現力。W3C XML Schema的擴展性處理所引入的結構限制是W3C XML Schema設計的結果，而不是基於schema的結構的固有限制。對於W3C XML Schema來講，如果它能夠向任意位置（如其他元素前）添加元素的話，將會很有用。但是確定性約束限制了它。一個較少限制的確定性模型類型可以被使用，例如URI規范[4]中定義的“greedy”算法。這將允許在通配符前放置可選元素，而無需引入擴展類型。它仍然不允許元素前的通配符，因為通配符將匹配元素。進一步說，它不允許通配符和類型的類型擴展共存。一個“priority”通配符模型（一個元素能夠被一個通配符匹配，或者可能的話一個元素能夠用另一個元素匹配）將允許通配符位於元素聲明前或後。另外，只允許尚未定義元素的通配符——其他命名空間有效地加上任何在目標命名空間未定義的東西——是另一個有用的模型。這些修改將也允許繼承和通配符較干淨地混合。但那仍然意味著作者必須在它們的類型中使用通配符。需要一個與前面提到的通配符變更結合的類型級any元素。一個可能的解決方法是序列聲明有一個指定任何位置都允許擴展的屬性，然後有一個指定命名空間、元素和驗證規則的相當屬性。上個方法的問題是：使用特定schema，有時候必須在系統的不同部分以嚴格或不嚴格的方式應用相同的schema。對於Internet一個長期存在的規則是健壯性原理，在Internet Protocol[3]中有詳細說明：“通常，一個實現必須在其發送行為上保守，在接收行為上自由。”在schema驗證術語中，發送方能夠以嚴格的方式應用一個schema，接收方以寬松的方式應用schema。在這種情況下，嚴格的程度不是schema的屬性，而是如何使用的屬性。一個看來能解決這些問題的方案是定義一種形式的schema驗證，允許一種開放的內容模型，該模型在對schema進行版本管理時被使用。我們稱這種模型驗證為“by projection”，其忽略而不是拒絕出現在消息中而沒有被schema明確定義的組件。我們計劃在將來探討這個寬松的驗證模型。關於W3C XML Schema擴展性的最後評價是：對於在保持擴展性的同時來定義用來驗證已知擴展的schema方面仍然有未滿足的需求。一個作者將希望創建一個基於一個擴展schema的schema，但在保持通配符擴展性的同時在特定通配符中混入了其他已知的schema。我們在一些領域（像描述SOAP 報頭塊）遇到了這種困難。從多個schema組合schema的主題比較困難，但也很迫切。離開通配符擴展性的主題，如果接收方不理解擴展類型，就像在xsi:basetype=""中，那麼如果實例文檔能夠表明一個基礎類型，在Web上使用擴展類型可能會更加令人愉快。如果接收方不理解基礎類型的擴展，那麼接收方能夠後退來使用基礎類型。另一個對於架構的改進的領域是XML（或者甚至是W3C XML Schema）可能已經提供了一個mustUnderstand模型。在目前情況下，每個提供mustUnderstand模型的詞匯表重新改造了mU wheel。XML可以提供一個每種語言都能使用的xml:mustUnderstand屬性和模型。2000年2月[18]，Tim Berners-Lee在他的關於強制擴展的設計筆記上詳細描述了XML中對其的需要，但是XML 1.0和1.1都沒有包括該模型。最後，在對於W3C XML Schema實現的符合性測試方面存在不明確性。W3C XML Schema測試集[16]不測試一些已經在這裡排除的、比較通用的情況。例如，重寫不同風格的通配符測試，它是一個復雜類型中的xs:any。它們不包括一些非確定性情況，這些情況典型地可以通過組合minOccurs/maxOccurs變化和##any、或者組合繼承與##any來獲得。這樣，一些實現無法正確地對非確定性進行測試，這可能產生無法互操作的文檔。人們共同關注的問題是對這些功能和組合的實現支持。這些示例已經在許多不同的schema分析器和工具包上進行過試用，如XML Beans、SQC和JAX-RPC。盡管不可能知道是否所有的實現都支持這些規則，但好像那些已經測試過的實現支持很好。作者一定對了解不支持這些規則的工具包感興趣。結束語 W3C TAG決定版本控制和擴展性主題對於web架構足夠重要，因此在一個發現上付出工作[20]，並且將材料包含進Web Architecture文檔[21]中。盡管本文為TAG材料提供了一個起始點，但該材料將包含更廣泛的范圍，並且比一篇文章在交互和重復的方式方面更加進了一步。對於正在進行的擴展性和版本控制領域的處理，讀者可以遵循TAG材料。本文描述了一些在語言構造和擴展中使用XML、W3C XML Schema和ML Namespaces的規則。這套規則的主要目標是允許語言設計者能夠為了獲得系統間的松散耦合而對其語言進行向後和向前兼容的變更。一定程度上，這裡介紹的技術將##any和##other設計和周知的規則組合起來，以生成一個可實現兼容擴展性和使用W3C XML Schema的驗證的版本控制目標的設計。命名空間名稱的擁有者能夠向擴展元素中添加向後和向前兼容變更，同時保持驗證所有組件的能力，其他作者能夠在##other通配符位置添加他們的修改。參考 · Free Online Dictionary of Computing · Flexible XML Processing Profile · IETF RFC 791 · IETF RFC 2396 · IETF RFC 2518 · IETF RFC 2616 · SOAP 1.1 · WSDL 1.1 · WS-Callback · WS-Policy Framework · Xfront@#s Schema Best Practices · W3C Note, Web Architecture: Extensible Languages · W3C XML 1.0 · W3C XML Namespaces · W3C XML Schema Part 1 · W3C XML Schema Working Group@#s Test collection for Any · XML.com: W3C XML Schema design Patterns，作者：Dare Obasanjo · Tim Berners-Lee關於演化、可擴展性和Must Understand的文章： o http://www.w3.org/DesignIssues/Mandatory.html o http://www.w3.org/DesignIssues/Extensible.html o http://www.w3.org/DesignIssues/Evolution.html · http://lists.w3.org/Archives/Public/w3c-dist-auth/1997AprJun/0190.Html · W3C TAG Finding on extensibility and versioning · W3C TAG Web Architecture document section on extensibility and versioning 致謝作者感謝許多對本文做出貢獻的評論者，特別是David Bau、William Cox、Edd Dumbill、Chris Ferris、Yaron Goland、Hal Lockhart、Mark Nottingham、Jeffrey Schlimmer、Cliff Schmidt和Norman Walsh。征得作者的允許，本文借用了WS-Calback中的例子和一些文本[9]。