處理複雜的XML

我需要處理很多可能相當複雜的傳入XML。典型情況如下：處理複雜的XML

<SomeNode> 
    <Request> 
    <Id>1</Id> 
    <!-- Request specific stuff --> 
    </Request> 
    <Request> 
    <Id>2</Id> 
    <!-- Request specific stuff --> 
    </Request> 
    <Response> 
    <Id>1</Id> 
    <!-- Feedback on request no. 1 --> 
    </Response> 
    <Response> 
    <Id>2</Id> 
    <!-- Feedback on request no. 2 --> 
    </Response> 
</SomeNode>

請注意，SomeNode不一定是頂級節點。我必須將這些請求與已存儲在我的數據庫中的請求進行匹配，即如果傳入XML中的請求與db中的記錄不匹配，則需要採取措施。通常我會要求用戶手動匹配未識別的XML部分，並根據這些手動規則重新處理XML。任何「錯誤」（包括失敗和成功）都應該相應地記錄下來，最好具有某種程度的細節。

最後，值得指出的是，有很多不同類型的XML進入我的系統 - 硬編碼處理邏輯可能不是我想要的。爲了處理新的消息而重新編譯和發佈新的可執行文件太麻煩了。當然，時間就是金錢。實現新類型的XML應儘可能快速和可靠。

目前，我對技術比對特定實現更感興趣。 XQuery是一個很好的開始嗎？或者這可能是矯枉過正？ XPath 1.0能夠讓我們一路領先嗎？還是我們必須使用2.0？也許我們根本不需要任何複雜的處理，這樣基本的XML解析就足夠了？你們有什麼感想？

對於這篇長文章，我很抱歉，但我們都知道GIGO的原則嗎？ :)

來源

2009-10-14 conciliator

您使用哪種語言？也許LibXMLParser可以爲你完成這項工作。 – junmats 2009-10-14 07:14:36

我們的店每天都使用德爾福。我已經使用MSXML DOM API進行了模式驗證，但是，在這一點上什麼都沒有解決。我們正在考慮不同的腳本替代方案，只是爲了使XML邏輯易於維護，並與可執行文件分開。 – conciliator 2009-10-14 07:33:45

我看到三個部分，您的問題：

你必須先找到一個方法來快速，輕鬆地從XML
的「識別」的信息，那麼你必須能夠檢查數據庫
，如果它不存在，你需要「處理」您的XML莫名其妙

現在，第一塊，你可能只需要一個聰明的XPath表達式 - 像//SomeNode/Response/Id在你的例子中 - 定義如何讀取「ID」 - 無論這可能是什麼。因此，將此XPath表達式存儲在一個配置中 - 您可以更改「即時」。

第二部分是檢查是否存在 - 取步驟編號檢索到的值。 1並檢查你的數據庫 - 你在這裏沒有提供任何細節，這不是與XML相關的，所以我猜這應該相當簡單。

第三步是處理XML，再次，你不清楚涉及什麼。您很可能需要另一個XPath來選擇要從原始XML中處理的節點，然後盡一切可能「處理」該XML。

在這種情況下你可以做的是創建一個包含這個邏輯的抽象基類 - 只是要調用的方法的存根 - 從而定義步驟和所有的順序。

對於您需要處理的每個XML，創建一個具體的後代類，然後實際爲您要解決的具體問題實現這三個步驟。

通過這種方式，您可以捕獲基類中的常見問題和常見任務，並在您的後代類中處理特定於問題的邏輯。

Marc

來源

2009-10-14 06:51:57

謝謝marc_s！當涉及到數據庫的一面時，我非常自信，這就是爲什麼我沒有提出它。而且我不想詳細討論處理XML的原因，因爲人們往往會陷入這些例子中。我一直在思考這些相同的路線;抽象類完成所有常規工作，實際的實現需要處理類型特定的細節。出於好奇：XPath 1.0能走多遠？我必須考慮2.0嗎？ – conciliator 2009-10-14 07:27:34

處理複雜的XML

回答

相關問題