XML 幾乎總是被濫用

XML 語言於 1996 年發明。它一出現，它的應用可能性就已經開始被誤解，而對於他們試圖適應它的目的來說，這並不是最好的選擇。

毫不誇張地說，我所見過的絕大多數 XML 模式都是對 XML 的不恰當或不正確的使用。此外，這種對 XML 的使用表明了對 XML 含義的根本誤解。

XML 是一種標記語言。 這不是一種資料格式。大多數 XML 模式都明確忽略了這種區別，將 XML 與資料格式混淆，這最終導致選擇 XML 的錯誤，因為它是實際需要的資料格式。

無需過多討論，XML 最適合用結構和元資料註解文字區塊。如果您的主要目標不是使用文字區塊，那麼選擇 XML 就不太合理。

從這個角度來看，有一個簡單的方法可以檢查 XML 模式的製作情況。讓我們以預期架構中的文件為例，並從中刪除所有標籤和屬性。如果剩下的內容沒有意義（或者如果剩下一個空行），那麼要么您的架構未正確構建，要么您根本不應該使用 XML。

下面我將給出一些最常見的錯誤構造電路的範例。

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

這裡我們看到一個毫無根據且奇怪的（儘管很常見）嘗試用 XML 表達簡單的鍵值字典的範例。如果刪除所有標籤和屬性，您將留下一個空白行。從本質上講，無論聽起來多麼荒謬，這個文件都是空行的語義註釋。

<root name="John" city="London" />

更糟的是，我們不僅僅將空字串的語義註釋作為表達字典的奢侈方式 - 這次“字典”直接編碼為根元素的屬性。這使得元素上給定的屬性名稱集未定義且是動態的。此外，它表明作者真正想要表達的只是簡單的鍵值語法，但他做出了應用 XML 的絕對奇怪的決定，強制使用單個空元素簡單地作為使用屬性語法的前綴。我常常遇到這樣的計劃。

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

這是更好的東西，但現在由於某種原因鍵是元數據而值不是。看字典的方式很奇怪。如果刪除所有標籤和屬性，一半的資訊將會遺失。

XML 中正確的字典表達式如下所示：

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

但是，如果人們做出了奇怪的決定，使用 XML 作為資料格式，然後用它來組織詞彙表，那麼他們應該明白他們所做的事情是不合適且不方便的。設計人員錯誤地選擇 XML 來建立應用程式也很常見。但更常見的是，他們無意義地以上述形式之一使用 XML，從而使事情變得更糟，而忽略了 XML 根本不適合這種情況的事實。

最糟糕的 XML 模式？ 順便說一句，獎品為 我見過的最糟糕的 XML 模式， 取得 Polycom IP 電話的自動設定檔格式。此類文件需要透過 TFTP 下載 XML 請求文件，這...一般來說，以下是此類文件的摘錄：

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

這不是某人的惡作劇。這不是我的發明：

• 元素只是用作附加屬性的前綴，屬性本身俱有分層名稱。
• 如果要為特定類型記錄的多個實例賦值，則必須使用屬性名稱來執行此操作。 有索引的.
• 此外，屬性以 softkey., 必須放置在元素上 <softkey/>, 屬性開頭 feature., 必須放置在元素上 <feature/> 等等，儘管事實上它看起來完全沒有必要，乍看之下毫無意義。
• 最後，如果您希望屬性名稱的第一個組成部分始終與元素名稱相同 - 沒有那樣的！例如，屬性 up. 必須附於 <userpreferences/>。將屬性名稱附加到元素的順序是任意的，幾乎完全是任意的。

文件或數據。每隔一段時間，就會有人透過嘗試比較 XML 和 JSON 來做出完全奇怪的事情，從而表明他們也不理解。 XML 是一種文檔標記語言。 JSON 是一種結構化資料格式，因此將它們相互比較就像嘗試比較暖和軟。

概念之間的區別 文件和數據。作為 XML 的類似物，我們可以有條件地取得機器可讀的文件。雖然它的目的是機器可讀，但它隱喻地指的是文檔，從這個角度來看，它實際上與 PDF 文檔相當，後者通常不是機器可讀的。

例如，在 XML 中，元素的順序很重要。但在 JSON 中，物件內鍵值對的順序是沒有意義且未定義的。如果您想要取得鍵值對的無序字典，則元素在該檔案中出現的實際順序並不重要。但是您可以從這些資料中形成許多不同類型的資料。 文件，因為文檔中有一定的順序。打個比方，它類似於紙質文檔，但與列印輸出或 PDF 文件不同，它沒有物理尺寸。

我的正確 XML 字典表示形式的範例顯示了字典中元素的順序，而不是 JSON 表示形式。我不能忽視這個順序：這種線性是文檔模型和 XML 格式所固有的。有些人在解釋此 XML 文件時可能會選擇忽略順序，但爭論這一點是沒有意義的，因為這個問題超出了格式本身的討論範圍。此外，如果透過附加級聯樣式表使文件在瀏覽器中可見，您將看到字典元素以特定順序出現，而不是其他順序。

換句話說，字典（一段結構化資料）可以轉換為 n 各種可能的文件（XML、PDF、紙本等），其中 n - 字典中元素可能組合的數量，我們還沒有考慮到其他可能的變數。

然而，如果您只想傳輸數據，那麼使用機器可讀文件將不會有效。它使用了一個模型，在這種情況下這是多餘的；它只會造成阻礙。此外，為了提取來源數據，您需要編寫一個程式。對於在某些時候不會被格式化為文檔的內容（例如，使用 CSS 或 XSLT，或兩者），使用 XML 幾乎沒有任何意義，因為這是這樣做的主要（如果不是唯一）原因。到文檔模型。

此外，由於 XML 沒有數字（或布林表達式或其他資料類型）的概念，因此以這種格式表示的所有數字都被視為附加文字。要擷取數據，必須知道模式及其與所表達的相應數據的關係。您還需要根據上下文了解特定文字元素何時表示數字並應轉換為數字等。

因此，從 XML 文件中提取資料的過程與識別包含例如形成多頁數位資料的表格的掃描文件的過程沒有太大不同。是的，原則上可以這樣做，但這不是最好的方法，除非作為最後的手段，當絕對沒有其他選擇時。一個合理的解決方案是簡單地找到原始資料的數位副本，該副本未嵌入將資料與其特定文字表示相結合的文件模型中。

也就是說，XML 在商業中流行並不令我感到驚訝。原因恰恰是文件格式（紙上）是業務可以理解和熟悉的，他們希望繼續使用熟悉和可以理解的模型。出於同樣的原因，企業經常使用 PDF 文件而不是更機器可讀的格式 - 因為它們仍然與具有特定實體尺寸的列印頁面的概念相關聯。這甚至適用於不太可能列印的文件（例如 8000 頁的 PDF 註冊文件）。從這一點來看，XML在業務中的使用本質上是擬物化的表現。人們理解有限尺寸的列印頁面的隱喻概念，並且理解如何基於列印文件創建業務流程。如果這是您的指南，那麼沒有實體大小限制的機器可讀文件（XML 文件）代表了創新，同時也是一種熟悉且舒適的文檔對應物。這並不能阻止它們仍然是一種不正確且過於擬物化的資料呈現方式。

到目前為止，據我所知，唯一可以真正呼叫該格式的有效使用的 XML 模式是 XHTML 和 DocBook。

來源： www.habr.com