Extensible Markup Language
基礎的概念と利用目的
XMLは、個別の目的に応じたマークアップ言語群を創るために汎用的に使える。マークアップ言語とは、コンピュータ言語の一種で（広義の「コンピュータ言語」であり、プログラミング言語ではないデータ記述言語などを含む意味）あるが、詳細は「マークアップ言語」の記事を参照のこと。XMLは、その「入子状にタグで囲まれたもの」という構文を共通としたことで、拡張が容易であるとして「extensible」と主張している。
上記の理由もあって、しばしば「あらゆる目的に使える」などと主張されるが、プログラム自体の構造としては入れ子構造（木構造）であって、より入り組んだネットワーク構造（グラフ構造）を直接扱うことは不可能である（XLinkなどの提案はあるが）。
XMLの最も重要な目的は、異なる情報システムの間で、特にインターネットを介して、構造化された文書や構造化されたデータの共有を、容易にすることである。XMLを使うと、文書を構造化して記述できるし、コンピュータのデータを直列化 （シリアライズ） できる。データを直列化する用途でXMLを使う際には、XMLは、JavaScript Object Notation (JSON) やYAMLなどの、テキストを基にした他の直列化言語と比較衡量できる。
XMLを基盤とするマークアップ言語とスキーマ言語
XMLで文書の論理的構造を規定する制約を追加することによって、XMLを適用したマークアップ言語を実装できる。XMLを適用したマークアップ言語は非常に多く存在している （#XMLの応用の節を参照）。例えば、Extensible HyperText Markup Language (XHTML)、DocBook、RSS、Mathematical Markup Language (MathML)、ebXML、Scalable Vector Graphics (SVG)、MusicXML などがある。さらにXMLは、そういった個別のXMLについての構文規則を示すためのスキーマ言語も用意している。スキーマ自体もXMLのXML Schemaの他、XMLではない記法でとても簡潔に大変わかりやすく書ける、Compact Syntaxも用意されているRELAX NGもある。
オープンな仕様
XMLは、同じく汎用的に使えるマークアップ言語である Standard Generalized Markup Language (SGML) の、簡素化されたサブセットとして、人間にとっても比較的判読しやすいように設計された （#歴史を参照）。XMLの仕様は、XMLワーキンググループなどにより設計が行われ、World Wide Web Consortium (W3C) により勧告 （策定） されている。XMLは無償で使えるオープン標準の技術である。XML仕様のW3C勧告ではXMLの文法とXMLプロセサ （XMLパーサ、XML文書の構文解析器） のための要件を定めている。1998年2月に XML 1.0 が勧告され、2004年2月に XML 1.1 が勧告された（#バージョン参照）。
正当性水準について
XML文書の正当性の水準には、整形式XML文書と妥当なXML文書の、2つの水準がある （#整形式XML文書と妥当なXML文書を参照）。XML文書のマークアップ規則に従って記述されていることだけが問題とされる文脈で、スキーマ言語を使わずに、XML文書のマークアップ規則に従って記述された文書を、「整形式XML文書」 (well-formed XML document) という （#XMLの構文と整形式XML文書を参照）。さらに、XML文書をより厳密に構造化した文書やデータとして扱いたい場合は、XML文書の構造をスキーマ言語によって定義することができ、XMLプロセサでそのXML文書（XMLインスタンス）に対してその文書構造に従っていることを検証する（妥当性検証を行う）というように、XML技術を使うこともできる （#XML文書の論理的構造と妥当なXML文書を参照）。
XML文書に対して妥当性検証を行うことにより、従来アプリケーションソフトウェアで行ってきた、XML文書の構造の検査や、XML文書に含まれるデータに対するデータ型のチェックや値の範囲のチェックが、可能となる。スキーマ言語としては Document Type Definition (DTD、文書型定義)、W3C XML Schema、RELAX NG （文書スキーマ定義言語: DSDL）などがある。XML文書の構造がスキーマ言語によって定義され、XML文書の妥当性を検証するソフトウェアによって妥当性が検証されたXML文書のことを「妥当なXML文書」 (valid XML document) という。整形式XML文書は、妥当なXML文書である場合と、妥当なXML文書ではない場合とがある。スキーマ言語を採用して妥当性検証を行う方法でXMLを使うこともできるし、スキーマ言語を採用せず妥当性検証を行わないで手軽にXMLを使うこともできる。
幅広い人間言語のサポート
XML勧告では、XMLプロセサがサポートすべき文字符号化方式（文字コード）としてUTF-8とUTF-16 (Unicode) を定めているため、英語以外の言語も扱いやすくなっている （#多言語環境で使うを参照）。また、UTF-8とUTF-16以外の文字コード（UCS-4、EUC-JP、Shift_JIS、EBCDICなど）を用いることも可能である。
XMLの普及とXMLへの批評
XMLは現在、広く普及している技術であるが、その技術的な有用性などについて、肯定的に評価する人々が多い一方で、批判的に評価する人々も多い （#XMLに対する支持と批判を参照）。
多言語環境で使う
XML文書ではどのUnicodeの文字も （XMLで特別な意味をもつ、開き山括弧 "<" のような文字を除いて）、要素名として、属性名として、コメント内容として、文字データとして、処理命令 （後述） として、直接に使うことができる。このため、漢字とキリル文字を共に含む次の文書も、整形式XML文書である。
<?xml version="1.0" encoding="UTF-8"?><俄語>Данные</俄語>
文字参照
文字参照 (character reference) は、文字をXML文書内でコード番号を指定して記述する記法である。文字参照は、実体参照と似ているが、実体参照では名前を使うのに対し、文字参照ではその部分で始めに "#" 文字を記述し続けて数字を記述する。
文字参照で使う数字は、符号化文字集合の国際規格である ISO/IEC 10646 (およびUnicode) のコード番号である。文字参照で使うことができる数字は、十進数であるか "x" を前につけた十六進数である。文字参照は、実体参照とは異なり、事前宣言されているわけでもなく、XML文書のDTD内部で宣言されているわけでもない。文字参照は、簡単には符号化できない文字を表現するために使われることが多い。例えば、欧州のコンピュータ上で作成するXML文書でアラビア語の文字を使う場合などである。「AT&T」の例の内のアンパサンドは、この場合に似ているともいえる。十進数の38と十六進数の26は、共に ISO/IEC 10646 の "&" 文字のコード番号である。つまり「AT&T」はXML文書では次のように記述することができる。
<会社名称>AT&#38;T</会社名称><会社名称>AT&#x26;T</会社名称>
処理命令
処理命令 (processing instruction) は、XML文書の構成要素であり、XML文書を扱うソフトウェアに対する何らかの処理を行う命令を、記述する内容が、処理命令である。
次に処理命令の構文を示す。
<?処理命令ターゲット 処理内容?>
処理命令は ?> の文字列を除き任意の処理内容を記述することができる。処理命令には、処理内容として擬似属性 (pseudo attribute) を記述することがある。擬似属性は、記述のしかたが属性名と属性値のペアに似ている。しかしXMLプロセサは擬似属性を、属性として解釈せず、処理命令の処理内容として解釈する。
擬似属性を使った処理命令の例を次に示す。
これはXML文書にカスケーディングスタイルシート (CSS) と関連づけるという処理命令である。
<?xml-stylesheet type="text/css" href="monobook.css"?>
あるXML文書内に記述された特定の処理命令について、その処理命令をプログラマーが意図したとおりの処理を実行させるためには、そのXML文書を処理するアプリケーションソフトウェア側がその処理命令に対応する必要がある。
CDATAセクション
XML文書 （およびSGML文書） においてCDATAセクションとは、文字列データのみで構成されておりマークアップされたデータは含まれていないと、XMLプロセサが解釈するようマークされた、要素の内容を構成する文字列データの一部である。CDATAセクションは、文字列データを表現するための単なる代替構文である。
CDATAセクションとして宣言された文字列データと、"<" と "&" を "&lt;" と "&amp;" で表現する通常の構文で記述した文字列データとの間に、意味的な違いはない。
CDATAセクションの構文と解釈
CDATAセクションは次の記述で始まる。
<![CDATA[
そしてCDATAセクションの内容が続き、次の記述が最初に出現したところでCDATAセクションは終わる。
]]>
CDATAセクションの内容の文字列は全て文字列データとして解釈され、マークアップや実体参照や文字参照として解釈されることはない。
次の例で「送信者」の開始タグと終了タグはマークアップとして解釈される。
<送信者>星新一</送信者>
しかし次のように記述した場合は、
<![CDATA[<送信者>星新一</送信者>]]>
次のように記述したものと同等に解釈される。
&lt;送信者&gt;星新一&lt;/送信者&gt;
すなわち、「送信者」タグは「星新一」の文字列と同列に位置づけられ、いずれも文字列データとして解釈される。
文字参照 &#x00F0; が要素の内容で出現した場合は、一つのUnicode文字 00F0 ("ð") として解釈される。しかしCDATAセクション内で出現した場合は、8つの文字からなる文字列として解釈される。
すなわち、アンパサンド、#マーク、文字x、数字0、数字0、文字F、数字0、セミコロンの8つの文字からなる文字列として解釈される。
XML文書の論理的構造と妥当なXML文書
妥当なXML文書について詳しく説明する。
XMLでは、要素に名前を付けることができ、階層構造をとることができ、スキーマ言語 (Document Type Definition など) により用途に沿うように定義されたスキーマを使うことで要素と属性の意味を公開し説明することができる。XMLのこうした特徴により、目的に応じたXMLに準拠したマークアップ言語を創るための、構文的な基礎が成り立っている。
スキーマは、制約の集合を記述することにより、XML文書の構文上の規則を単に補足するのみである。スキーマは、多くの場合、要素と属性の名前を限定し、各要素が内容とするものの階層構造を規定し、属性の内容を規定する。例えば、「誕生日」という名前の要素では、「月」という名前の一つの要素と「日」という名前の一つの要素をもつことができ、「月」要素と「日」要素のそれぞれは文字列データのみをもつことができる。
スキーマに定義された制約には、データ型の割り当てを含むことができる場合がある。
データ型を割り当てることにより、データ型が割り当てられた情報がどのように処理できるかを、規定することができる。
例えば、「月」要素の文字列データは、そのXML文書で採用したスキーマ言語の機能に準拠して、「1」から「12」までの数字のみが妥当であるという形で、定義することができる可能性がある。ここでスキーマ言語の (データ型に関する) 機能とは、おそらく特定の方法で形式にしたがって記述しなければならないということだけでなく、別のデータ型の値であるかのように処理されることを未然に防ぐことを、意味する。
何らかのスキーマに準拠したXML文書は、整形式であるということに加えて、妥当 (valid) であるということが成り立つ。
XMLのスキーマは、XMLの文書型 (文書の種類、文書の論理的構造) を記述したものである。
多くの場合スキーマは、その文書の構造と内容に関する制約という形で表現される。XMLのスキーマは、XML仕様で規定されている、整形式XML文書としての基本的な制約に加え、それ以上の制約をXML文書に課すことができる。XMLのスキーマ言語は、標準規格のものもプロプライエタリなものも含めて、こうしたスキーマを表現するという目的のもと、数多く存在している。いくつかのスキーマ言語では、スキーマ自身をXML文書として記述する。
スキーマ言語の記述能力はスキーマ言語ごとにさまざまである。例えばスキーマ言語の一つである Document Type Definition (DTD) では、XML文書がとるべき構造の主な規則として、そのDTDに準拠したXML文書で使うことができる要素の名前、要素の内容モデル、要素で指定できる属性の名前、属性の値のデータ型を、記述することができる。
なお、要素の内容モデルとは、要素の内容に出現可能な要素やデータとその順番、および要素の出現回数を規定したもののことをいう。
Standard Generalized Markup Language (SGML) やXMLなどの汎用的なデータ記述言語が世に出る前は、ソフトウェア設計者は、複数のプログラムの間でデータの受け渡しをするために、自分自身でファイルフォーマットを定義するか、ちょっとしたコンピュータ言語を定義しなければならなかった。このため受け渡しするデータの詳細な仕様やその他の文書を書かなければならなかったし、文書の書き手を別途に確保しなければならないこともあった。
XMLが一定の構造をもち厳密な構文解析の規則をもつことで、ソフトウェア設計者は構文解析の作業を標準的なソフトウェアツール (妥当性検証器、バリデータ) に任せることができる。そしてXMLには、用途に特有の言語を開発するための一般的な、データモデル指向の枠組みがある。
このためソフトウェア開発者は、比較的高水準の抽象度において、自分たちが扱うデータの規則の開発に専念するだけでよい。
XML文書をスキーマに照らして妥当性検証を行うための、十分にテストされたツールが、数多く存在している。XML文書をスキーマに照らして妥当性検証を行うためのツールを、妥当性検証器 (バリデータ) という。妥当性検証器は、スキーマに表現された制約にXML文書が準拠しているかについて、自動的に妥当性検証を行う。
妥当性検証器は、XMLプロセサ (XMLパーサ) に含まれていることもあれば、XMLプロセサとは別に提供されていることもある。
これまでに述べたスキーマの使い方とは別の使い方も存在する。
例えば、XMLエディタは、XML文書の編集を支援するためにスキーマを使うことができる。こうしたXMLエディタでは、妥当な要素名や妥当な属性名を提示することなどができる。
RELAX NG
RELAX NGは人気のあるもう一つの新しいスキーマ言語である。2001年12月にOASIS (構造化情報標準促進協会) で仕様が策定された。ISO (国際標準化機構) にて定められた国際標準でもある。ISOでは、文書スキーマ定義言語 (DSDL) の一部分を構成する仕様として位置づけられている。
RELAX NGのスキーマの記述方法は、2つの形式がある。XMLに準拠した構文 (XML構文、xml syntax) と、XMLに準拠しない短縮構文 (compact syntax) である。短縮構文は、読みやくすることとより書きやすくすることを目指している。ただし、短縮構文で記述されたスキーマをXML構文のスキーマに変換する方法と、その逆の変換を行う方法は、予め定義されているので、ジェームズ・クラークが開発した Trang conversion tool を使えば、標準のXMLツールを使う利便を享受することができる。
RELAX NGはXML Schemaよりも簡潔なスキーマ定義と簡潔な妥当性検証の枠組みを、備えている。そのためRELAX NGは、XML Schema と比べて、使いやすく、またRELAX NGの妥当性検証器を実装することも容易になっている。
RELAX NGもまた、データ型フレームワークプラグインを使う機能を備えている。
RELAX NG でスキーマを記述する人は、例えば、XML文書でXML Schemaのデータ型の定義に適合させたいと考えるかもしれない。
そして RELAX NG では、データ型フレームワークプラグインを使うことにより可能となっている。
ISO 文書スキーマ定義言語
ISO 文書スキーマ定義言語 (DSDL; Document Schema Description Languages) 標準は、小規模なスキーマ言語の広範なセットを共に提供する。DSDLを構成する複数の仕様のそれぞれが、特定の問題に対応するために特化されている。DSDLはRELAX NGのXML構文と短縮構文、スキマトロン、データ型ライブラリ言語、文字レパートリ記述言語、文書スキーマ再命名言語、名前空間に基づく検証委譲言語 (NVDL) を、含んでいる。DSDLスキーマ言語群はXML Schemasを支持するベンダの支援は2007年の時点ではまだ受けていない。DSDLは出版のための機能が欠如していることに対する、出版業界の一定の草の根の反応でもある。
XML文書を検証する過程でXML情報集合を変更することについて
いくつかのスキーマ言語では、特定のXML文書の構造を記述する能力に加えて、個々のXML文書をその特定のXML文書構造に適合するように変換する機能も、限定的ながら備えている。
DTDとXML Schemaはこの変換機能を備えている。
DTDと XML Schema では、XML文書に属性の既定値を与えることができる。RELAX NGとスキマトロンは、意図的にこの機能を外している。
例えば、XML情報集合を正確に扱うことが、RELAX NGとスキマトロンの仕様策定時に変換機能を外した理由の一つである。
XML文書を視覚的に表示する
XML文書を視覚的に表示するための方法を説明する。
XML文書は、その文書の内容をどのように視覚的に表示するかという情報を、一切含んでいない。
Cascading Style Sheets (CSS) や Extensible Stylesheet Language (XSL) のようなXMLのためのスタイルシート言語を使うのでなければ、ほとんどのウェブブラウザは普通のXML文書を生のXMLテキストとして描画する。いくつかのウェブブラウザは「ハンドル」をつけて表示する (例えば、余白に + と - の符号を表示する)。ハンドルを使うことにより、XML文書構造の部分木を、マウスクリックで展開したり折りたたんだりすることができる。
CSSを使ってウェブブラウザでXML文書を描画するためには、XML文書は次のような要領でスタイルシートへの参照を含めなければならない (XMLの処理命令を使ってスタイルシートを使って描画する旨を指定している)。
<?xml-stylesheet type="text/css" href="myStyleSheet.css"?>
この方法は、HTML文書におけるスタイルシート指定の方法とは異なる。HTML文書では <link/> 要素を使ってスタイルシートを指定する。
XML文書を視覚的に表示するために、Extensible Stylesheet Language（XSL、拡張可能なスタイルシート言語）を使うこともできる。XSLを使う場合は、XML文書をXHTML/HTML文書の構造に変換するか、もしくはウェブブラウザで視覚的に表示することができる他の文書の構造に変換する。
クライアント側でXSL Transformations (XSLT) のスタイルシートを指定するためには、XML文書に次のようにXSLTスタイルシートへの参照を含めることが、必要である（XMLの処理命令を使って実現している）。
<?xml-stylesheet type="text/xsl" href="myTransform.xslt"?>
クライアント側のXSLTスタイルシート処理機能は、現在では多くのウェブブラウザが備えている。
別の方法として、このような利用者が常用しているウェブブラウザの能力に依存する方法を採らずに、サーバ側でXSLを使ってXML文書を視覚化可能な形式に変換する方法も、行われている。利用者は、「舞台の裏側で」何が行われているかを、意識する必要はない。実際に目にするものは、よく整形され視覚化された文書だけである。
MIMEタイプ
XML文書はさまざまなMIMEタイプで配布することができる。RFC 3023 は、"application/xml" および "text/xml" のMIMEタイプを定義する。
"application/xml" と "text/xml" のMIMEタイプは、そのデータがXML文書の形式をとっているということのみを述べているだけであり、そのXML文書の論理的構造については何も述べていない。
"text/xml" を使うことに対しては、符号化に関する問題が生じる可能性があるとの批判があり、現在では非推奨とされている。RFC 3023 では、加えて、XML文書を "application/" で始まり、"+xml" で終わるMIMEタイプで配布することを勧めている。例えば、AtomのXMLデータに対しては、"application/atom+xml" のMIMEタイプで配布するのである。
XML名前空間
XML名前空間 (Namespaces in XML) は、一つXML文書内で、異なる複数のボキャブラリ（スキーマ）に由来する要素と属性を、名前の衝突を発生させることなく、含めることができるようにするための仕様である。World Wide Web Consortium (W3C) から、1999年1月14日に Namespaces in XML 1.0 が勧告された。XML文書に異なる複数のボキャブラリに由来する要素と属性を含める場合、ボキャブラリのそれぞれに名前空間をわりあてることにより、要素名の衝突と属性名の衝突の問題を、解決することができる。
一つの名前空間において定義された要素の名前は、一意でなければならない。
顧客への参照と注文された商品への参照を含む簡単なXML文書の例を考える。顧客要素と商品要素は、ともに「識別番号」という名前の子要素をもつことがあるだろう。識別番号要素への参照は、顧客要素の子要素の識別番号要素も商品要素の子要素の識別番号要素も同じ要素名をもつので、あいまいである。しかし2つのボキャブラリを区別する2つの名前空間のもとで識別番号要素を使う場合、顧客要素の子要素の識別番号要素と商品要素の子要素の識別番号要素は意味的に明確に異なる2種類の要素となる。
Simple API for XML (SAX)
Simple API for XML (SAX) は、字句解析を行いイベント駆動で処理を行う API である。SAXを使うとXML文書は文書の最初から順次読み込まれ、その内容はプログラマが実装したハンドラオブジェクトの様々なメソッドへのコールバックとして報告される。SAXを使ったXML文書処理は高速であり、少ないコンピュータ資源を効率的に使って非常にサイズの大きいXML文書を処理することが可能である。
SAXを使うことに伴う問題は、XML文書に対してランダムアクセスを行って情報を取り出すことが難しいことである。そのため、SAXを使うに際し、プログラマはXML文書のどの部分が現在処理対象となっているか把握する為の機構を実装しなければならない。
SAXは、処理対象となるXML文書中のある種類の情報がどの部分に出現するかに依らず、常に同じように処理されると保証できる場合に用いるのが望ましい。
Document Object Model (DOM)
Document Object Model (DOM) は、インタフェース指向のAPIであり、XML文書のおのおのの部分を表現する節オブジェクトの集まりからなる木構造であるかのように、XML文書全体に対してナビゲーションを行うことを想定している。DOMでは、XML文書に対してランダムアクセスを行って情報を取り出すことが、簡単にできる。
DOMにおけるXML文書全体に相当する Document オブジェクトは、XML文書をXMLプロセサが処理することにより生成することもできるし、プログラマがプログラミングすることによって生成することもできる。DOMにおける Node (節) のさまざまな型のデータ型は、DOM仕様においては抽象的にインタフェースとして定義されている。Node のデータ型の実装は、プログラミング言語に固有の言語バインディングを提供する。
DOMの実装は、サイズの大きいXML文書を扱う場合はたくさんのメモリを使う。なぜならDOMの実装は、一般的にはXML文書全体からオブジェクトの木構造を構築してメモリにロード（展開）し、その後にDOMを介した処理をできるようにしているからである。
Javaでは、標準ライブラリを構成するいくつかのパッケージでDOMが実装されており、Javaのプログラマは標準ライブラリのDOMを使うことができる。DOMの仕様は、World Wide Web Consortium (W3C) で策定されているため、DOMで中核をなす Node やDocument などのインタフェースや、直列化 (出力) などの機能を提供するためのインタフェースはパッケージ org.w3c.dom.* に収められている。
XMLに準拠したアプリケーションソフトウェアとエディタ
OpenOffice.org、AbiWord、およびアップルのiWorkなどのアプリケーションソフトウェアのネイティブファイルフォーマットは、XMLである。
従前、オフィススイートには各ソフトの特有のバイナリ形式としてデータが保存されていた。しかしながらこれでは互換性が低く、様々な情報をデータベースとして利用するオフィススイートでは不都合が生じていた。
そのため、データの標準化を進めて互換性を高めるため、各オフィススイートはXML形式でデータを出力する機能や、そもそも標準保存形式をXMLベースとするものが増えてきた。
OpenOffice.orgはXMLベースの保存形式を当初より標準としていた（英語版バージョン1.0は2002年5月1日リリース）。また、OpenOffice.orgに限らず、どのオフィススイートでも利用できるOpenDocument形式が国際標準化機構（ISO）によって標準規格として認定されている。
もう一つのオフィススイート用の保存形式である Office Open XML も、ISOにより標準規格として認定されている。
マイクロソフトの Microsoft Office では Microsoft Office XP のバージョンからXML形式への対応を始め、Microsoft Office 2003 で独自の定義の XML Schema がサポートされるに至った。
Microsoft Office 2007 ではデフォルトの保存方式がXMLとなった（Office Open XML）。Microsoft Office 2007 のいくつかの機能では、XMLファイルを利用者が指定したスキーマ (ただしDTDではない) に沿って編集することができるようになっている。
またマイクロソフトは、Microsoft Office 2003 のためのファイルフォーマット互換性キットを公開している。
この互換性キットを使うことにより、以前のバージョンの Microsoft Office で作成された文書をXMLに準拠した新しいフォーマットで保存することができる。
エディタについては現在、多くのXMLエディタが使えるようになっている。
情報集合への追加情報
情報集合への追加情報すなわち情報集合に対する改変は、スキーマによる妥当性検証を行う際に、情報集合を改変することをいう。
例えば、情報集合に属性の既定値 (デフォルト値) を追加することなどがある。情報を追加された情報集合は、スキーマ検証後情報集合あるいはPSVI (post-schema-validation infoset) と呼ばれる。
情報集合への追加情報については、賛否両論がある。
情報集合に情報を追加することに否定的な見解としては、情報集合への追加情報はモジュール性を侵害し相互運用性の面での問題を引き起こす危険があるとする。
なぜなら、同じXML文書を扱う複数のアプリケーションソフトウェアは、受け取る情報が妥当性検証を行うかどうかに依存してしまうからである。
アプリケーションソフトウェアが、妥当性検証を行う場合に受け取る情報と、妥当性検証を行わない場合に受け取る情報が、異なってしまうのである。
XML Schema は、XML情報集合への追加情報を扱うことができる。
RELAX NGは、情報集合への追加情報を扱わない。
RELAX NG では、情報集合への追加情報に否定的な立場をとっている。
特許の主張
2005年の10月に、Scientigoという小さな企業が、XMLの使用に対して同企業の2つの特許 U.S. Patent 5,842,213 と U.S. Patent 6,393,426 の対象になるという主張を、公的に表明した。
この2つの特許は、「特定の『階層構造ではない』統合されていない中立的な形式での、[データの]モデリングと格納と転送」を対象としている。
特許申請によると、この2つの特許は1997年と1999年に出願された。
Scientigoの最高経営責任者 (CEO) である Doyal Bryant は、この2つの特許を「金銭に換える」という願望を述べたが、同社は「世界を敵にするつもりはない」と言明した。
Bryant は、Scientigoは自社の2つの特許についていくつかの大企業と話し合っていると述べた。
XMLを使う人々や企業に在籍していない専門家たちは、Scientigoの主張に対して懐疑的で批判的な立場で反応した。
一定の人々は、Scientigoをパテント・トロールであると述べた。
ティム・ブレイは、この2つの特許がXMLを対象とするという主張は「ばかげている」と述べた。
XMLに関係する多くの先行技術がSGMLを含めて存在している。
XMLに対する支持と批判
多くの論者がXMLに対してさまざまな批判を行ってきた。
こうした批判は、XMLの長所と潜在的な欠点に対する言及を含んでいる。