我們目前正在設計一個RESTful應用程序。我們已經決定將XML作爲我們的基本代表。 我有關於在XML中設計/建模應用程序數據的以下問題。XML設計 - 如何？
注意：我已經看過一個相關的問題在stackoverflow（What are best practices for designing XML schemas?），但似乎並沒有解決上述問題。
如果您還沒有XML並且不知道需求，那麼將很難首先設計架構。如果您已經有了必須處理XML的代碼，那麼將對象樹作爲第一個XML樹的示例可能是最好的辦法。它們沒有什麼不同，除了XML總是隻是一棵樹而不是你的對象。
從此，您穩定了XML並收集了需求模型的使用案例。如果你有這兩個，你有一個完美的開始做架構。這將鞏固你的格式。
尋找標準模式總是一個好主意，但幾乎總是令人沮喪。推遲這個，直到你知道你的xml是什麼樣的。也許你會意識到已經有一些標準化的東西就像你的格式一樣。
你應該小心命名空間。這是XML中較重的主題，因爲您可能犯這麼多錯誤。如果您不確定是否需要它們，請跳過。這就是世界其他地方正在做的事情。如果你認爲你會需要他們從第一次使用它們開始。混合沒有名稱空間感知代碼和名稱空間感知代碼是一種痛苦。
我強烈反對刪除命名空間 - 這會阻止你可能不關心的事情，但是你的庫（或者客戶，或者未來的維護者，或者集成工程師）可能想要做哪些事情，比如將文檔嵌入到更大的文檔中以不同的格式，或者在*你的文檔中嵌入不同類型的信息，期待第三方工具對你的文檔格式一無所知，以做正確的事情。因此使用名稱空間是未來防護的更安全選擇。 –
那麼這只是另一個「個人決定」。你在談論框架，第三方軟件。我不認爲他談論這件事的可能性很高。世界其他地方都有簡單的問題。是的，儘管名稱空間是正確的路線，但它可以使您的工作非常繁瑣。因此，如果用例不關心這個跳過命名空間正在節省 –
離開命名空間適用於無關緊要的應用程序。因果關係，反之亦然？ –
服務設計需要注意的一點是，它與設計類/對象不同，而且您必須更多地考慮交換文檔。這有時被稱爲course-grained。在面向對象的世界中，您將在同行之間交換一系列方法調用，但在SOA中，您將避免惹人討厭，並嘗試將大部分所需信息填充到文檔中，有點像提交納稅表格。
我同意你應該先設計你的應用程序，然後決定你需要交換什麼信息。
正如你這樣做，你可能會發現你正在交換的一些信息來自標準模式。您也可能會發現客戶使用的標準架構已經描述了您想要交換的信息。
如果這些事情都沒有發生，那麼忘掉「標準模式」。除此之外，我不認爲你會找到一個完整的列表 - 有太多。
從一開始就更好地思考名稱空間設計方法。如果你打算設計的XML文件在概念上是相關的，你可以選擇同名的命名空間設計方法。
異質名稱空間設計方法允許共享和重用。當您想要直觀地識別特定於域的文件時，可以使用它。
異構設計方法是推薦的方法。請參閱http://technologyandleadership.com/three-schema-design-approaches/瞭解如何爲您的項目實施此設計方法
如果您已經想要開始使用XML，那麼爲什麼還要開發ReST API？爲什麼不從一開始就使用SOAP/WS（DL）？不要誤解我。我是ReST的大力支持者，但是如果您希望將XML與自己的模式一起使用，您還應該研究API的整個XML工具鏈。 – Boldewyn