當XSL轉換命名空間頁面脫機時該怎麼做？

的xmlns：XSL =「http://www.w3.org/1999/XSL/Transform」

並拋出一個錯誤，如果在鏈接命名空間並不完全正確。

今天，「http://www.w3.org/1999/XSL/Transform」處於脫機狀態。我無法運行任何轉換。當網絡請求超時時，轉換掛起，然後返回「意外的文件結尾」。如果將命名空間聲明中的URL更改爲隨機URL，則轉換將失敗，並顯示錯誤，告訴我「http://www.w3.org/1999/XSL/Transform」是必需的xsl命名空間。

那麼，如何解決W3的網站遭到了嗎？

來源

2011-11-14 Chris

這不是失敗，因爲「http://www.w3.org/1999/XSL/Transform」不可用。由於其他原因，這是失敗的。也許是因爲XHTML DTD正在被請求。 –

與其向我們提出一個基於錯誤假設的模糊和普遍的問題，提供一個完整的（最簡單的「失敗」轉化例子 - 那麼這裏的每個人都能夠確切地說出什麼是錯誤的將會更有成效。） –

，我們一直在等待12年的時間讓這個網頁成爲在線 - 還沒有 –

使用xmlns:something="..."聲明XML 命名空間。這樣的名稱空間僅僅是一個字符串，這將有助於將元素名稱的唯一含義賦予像template或href這樣的元素名稱，從而確保可以在單個文檔中使用多種基於XML的語言，而不會對其含義造成混淆。

其中一些命名空間預留給了W3C使用。 XSLT命名空間就是其中之一。一個合適的XSLT處理器將檢查樣式表是否聲明瞭正確的名稱空間，以確保不會有不正確的解釋。樣式表的根元素應該位於該XSLT名稱空間中。

對於實際命名空間值，你通常有一個URI（和最常見的是URL），因爲這通常是一個不錯的唯一標識符。但是，這個不應該用於在XML處理過程中實際解析任何在線資源。儘管HTTP URL通常以不區分大小寫的方式處理，並且可能使用字符的URL編碼（例如，空格變爲%20），但在XML名稱空間處理中不會檢查URL的這種解析或相等性。 XML中的命名空間不過是一個總是以確切形式，大小寫以及所有內容進行檢查的字符串。

所以，如果一個XSLT處理器抱怨說，在URL一些資源不能被發現，那麼無論它做什麼它不應該這樣做，或者問題無關命名空間的處理。

您使用的撒克遜人，其中大部分是絕對不會不理解命名空間的概念的處理器。它的父親是Michael Kay，他也負責XSLT 2.0規範。但是Saxon確實支持模式感知XSLT處理。如果一個文檔指定了一個模式位置，那麼使用這個進行驗證的處理器實際上會使用該位置來獲取模式。這與名稱空間有所不同。 DTD和XML Schema位置肯定會導致網絡活動。

所以我建議你檢查是否......

的XML使用外部定義，無論這些可用一個DTD;
XML指定模式位置以及是否可以到達該位置;
樣式表使用模式或其他外部資源以及是否可用。

一旦找到原因，請查看與處理器一起使用XML目錄。XML目錄將允許您使用本地資源，如果它們無法從其URI解析的話。

來源

2011-11-14 16:02:08

沒有真正回答這個問題「所以我建議你檢查一下...... XML是否指定了模式的位置以及是否「是的，這是問題。由於w3.org網站關閉，因此無法訪問定義的模式。如何解決此問題？ – Chris

」沒有真正回答問題「？我已經向你指出了這個問題的根源而不是命名空間，但架構位置，並且我已經告訴您查看可能解決該問題的XML目錄。我不是巫師，男人。 –

*「由於w3.org網站已關閉，因此無法訪問定義的模式。」* - 正如其他人試圖指出的那樣，這種假設是錯誤的。這不是你的樣式表失敗的原因。 –

簡單的回答：http://www.w3.org/1999/XSL/Transform不是一個URL，它只是一個字符串。如果W3C決定，沒有理由不能成爲'ThisIsAnXsltStylesheet'。按照慣例，它們通常與URL相似，但這不是必需的。

因此，這個URL中沒有任何內容與您的樣式表失敗原因無關，並且肯定不會是原因。從邏輯上講，如果是這種情況，那麼沒有互聯網連接的人就無法使用XSLT，而W3C的服務器將嚴重超負荷工作。

我建議將XSLT的前幾行添加到您的問題中;它可能會讓你發現問題的真相。

來源

2011-11-15 01:50:48 Flynn1179

當XSL轉換命名空間頁面脫機時該怎麼做？

回答

相關問題