XMLフォーマッター

正規表現の上に構築されたフォーマッター — 各`<`の前に改行を挿入し、開いたタグの継続的なカウントに応じてインデントする — は、シンプルな手書きXMLではまずまず動作しますが、実世界の文書では、それが破損したファイルを引き起こすまでは見落としやすい理由で失敗します。CDATAセクションは`<![CDATA[...]]>`と書かれ、まさにタグのように見える文字を含みうる任意テキストを含めるために特別に存在し、`<`を探す正規表現には、その中身を構造として扱うのではなく、それらのマーカーの間のすべてを無視すべきだと知る方法がありません。コメントも同じリスクを負い、属性値はさらに悪いです: `note="a > b"`のような属性は、ナイーブなスキャナーがタグの終わりと誤解しかねないリテラルの`>`文字を含み、間違った場所で黙ってタグを切り詰めてしまいます。

XMLを正しく整形するということは、スキャナーがタグのような構造を探す前に、これらの特殊な領域 — CDATAブロック、コメント、処理命令、DOCTYPE宣言、引用符で囲まれた属性値 — を認識しなければならないことを意味し、そうすることで内容がマークアップとして再解釈されるのではなく、バイト単位でそのまま引き継がれます。

このツールは各タグが正しく閉じられ、正しくネストされているか — 文書をXML的に「整形式」にする構造的ルール — をチェックし、そのチェックが失敗したとき、具体的なバランスの取れていない、あるいは閉じられていないタグを報告します。行わないのは、DTDまたはXML Schema（XSD）に対して文書を検証することです。これはさらに、要素、属性、そしてその特定の値が特定の文書型のルールに準拠しているか — 必須の属性が存在するか、要素が正しい文脈に現れるか、値が期待される型と一致するか — をチェックすることになります。それは本当に別個で手の込んだチェックであり、追加の入力としてスキーマ文書自体を必要とし、汎用のフォーマッターがXMLだけから推測できるものではありません。

厳格なXHTMLは有効なXMLであり、ここで正しく整形されますが、実世界の通常のHTMLはそうではありません。HTMLの仕様自体に組み込まれた理由からです: `<br>`や`<img>`のような空要素は決して閉じられず、終了タグを一切持ちません。いくつかのタグはブラウザが自動的に推論するオプションの終了タグを持ち、ブラウザは厳格なXML解析なら直接拒否するであろう不正なネストを許容します。厳格なXMLフォーマッターを典型的なHTMLに適用すると、完全に正常で整形式のあらゆるページでエラーが報告されます。これがまさに、HTMLがこれらのHTML固有のルールを理解する本物のHTMLパーサーを中心に構築された別のフォーマッターを持つ理由です。文書を厳格なXMLとして扱う代わりにです。

JSONは新しいWeb APIのデフォルトの選択肢としてXMLに取って代わりましたが、インフラの多くはその変化の前に構築され、今もその上で動作しています: SOAP Webサービス、RSSとAtomのフィード、SVG画像（それ自体がXMLです）、Officeの文書形式は内部的に、そしてJSONが普及する前からある企業システムと設定形式の長い列です。これらの古いあるいはより公式なシステムのどれかと統合する誰でも、今も整形式のXMLを読み、デバッグし、生成する必要があり、これがまさに、XMLが新しいAPIのデザインでは後退した今でも、専用のXMLフォーマッターが引き続き奉仕する対象です。