stanford-oval/wikipedia huggingface dataset:
C Sharp
言語仕様 > C# 13.0からの仕様 > 新しいエスケープシーケンス

エスケープ文字を表すエスケープシーケンスとして\eが追加された。これに従って\x1bの使用は非推奨となった。
言語仕様 > C# 13.0からの仕様 > 暗黙的なインデックスアクセス

オブジェクト初期化子においても^演算子を用いたアクセスが可能となった。これにより、初期化子内でも配列やリストなどの末尾から値へアクセスできる。
言語仕様 > C# 13.0からの仕様 > params コレクション

コレクション式に対応している型であれば、引数にparams修飾子を付けられる様になった。
// 関数定義
void Print(string format, params IEnumerable<object> args)
{
    /* ... 任意の実装 ... */

    // 例えば
    Console.WriteLine(format, args.ToArray());
}

// 呼び出し
int a = 2, b = 3;
Print("{0} + {1} = {2}", a, b, a + b);
言語仕様 > C# 13.0からの仕様 > その他の仕様

メソッド グループでの自然型
部分プロパティ
ref 構造体のインターフェイス実装
OverloadResolutionPriority 属性（オーバーロードの解決優先度を変更できる）
Lock クラスに対する lock
イテレーター・非同期メソッド内の ref/unsafe
インターセプター
コレクション式の改善
実装

C#の言語仕様は標準化団体Ecma Internationalを通じて公開・標準化されており、第三者がマイクロソフトとは無関係にコンパイラや実行環境を実装することができる。
実装 > コンパイラの実装

現段階で、C#コンパイラの実装は次の5つが知られている。
マイクロソフト製
Visual Studio 2015 以降で使用されている、.NETコンパイラプラットフォーム (コードネーム Roslyn)。ApacheライセンスのオープンソースプロジェクトでGitHubで公開されている。Windows、macOS、Linuxで動作する。C#のコンパイラはC#、VB.NETのコンパイラはVB.NETで実装されている。以前のコンパイラと比べて、リファクタリングやIDE、スクリプティングなどへの利用が可能なAPIが公開されており、コンパイラ以外への様々な応用が可能。
Visual Studio 2013 まで使われていた、マイクロソフトによるVisual C# コンパイラ。
2006年のC# 2.0当時の、マイクロソフトによるShared Source Common Language Infrastructure。共通言語基盤 (CLI) とC#コンパイラがソースコードで公開されている。
Mono ProjectによるMono内の Mono Compiler Suite (mcs)。
2012年まで開発されていた、DotGNU ProjectによるPortable.NET内の the C-Sharp code compiler (cscc)。
実装 > 実行環境の実装

マイクロソフト
.NET Runtime
.NET Framework Runtime
Mono Project
Monoランタイム
カプコン
RE ENGINEに実装されている REVM
名称

ECMA-334 3rd/4th/5th edition によると、C# は「C Sharp」（シーシャープ）と発音し、LATIN CAPITAL LETTER C (U+0043) の後に NUMBER SIGN # (U+0023) と書く。MUSIC SHARP SIGN ♯ (U+266F) ではなく NUMBER SIGN # (U+0023) を採用したのは、フォントやブラウザなどの技術的な制約に加え、ASCIIコードおよび標準的キーボードには前者の記号が存在しないためである。
「#」を接尾辞とする名称は、他の .NET 言語にも使用されており、J#（Javaのマイクロソフトによる実装）、A#（英語版）（Adaから）、F#（System Fなどから）が含まれる。更には、Gtk#（GTK などの GNOME ライブラリの .NET ラッパ）、Cocoa#（英語版）（Cocoa (API) のラッパ）などのライブラリにも使用されている。そのほか、SharpDevelopなどの「Sharp」を冠する関連ソフトウェアも存在する。
C# という名称の解釈として、「（A-Gで表された）直前の音を半音上げる」という音楽記号の役割に着目し、「C言語を改良したもの」を意味したのではないか、というものがある[要出典]。これは、C++の名称が「C言語を1つ進めたもの」という意味でつけられたことにも似ている。アンダース・ヘルスバーグは、「C#」が「C++++」（すなわち「C++ をさらに進めたもの」）にみえるのが由来である、と語っている。
殉死と自殺の差は記事になるかならないか

「殉死と自殺の差は記事になるかならないか」（じゅんしとじさつのさはきじになるかならないか、原題: The Only Difference Between Martyrdom and Suicide Is Press Coverage）は、アメリカ合衆国のポップ・ロック・バンドであるパニック!アット・ザ・ディスコの楽曲。2005年9月27日にデビュー・シングルとしてスタジオ・アルバム『フィーバーは止まらない』と同時発売された。『ビルボード』誌のHot 100で最高位77位、Alternative Songsで最高位5位を記録した。
背景・曲の構成

楽曲のタイトルはパニック!アット・ザ・ディスコの楽曲の中で長いタイトルの1つとなっており、このタイトルは1999年に発表されたチャック・パラニュークの小説『サバイバー』から引用している。バンドのマネージャーであるスコット・アーデルベルクによれば、仮タイトルは「Applause」。
本作はアコースティック・ギターが先導するパーティーソングとなっており、曲の中盤には電子音を使用したダンス調のセクションが含まれている。曲のキーはF♯マイナーで、テンポは170BPM。
評価

『Gigwise』のジョナサン・ディーマーは、パニック!アット・ザ・ディスコが「約3分の日常を描くエモ・ポップの逸品を提供するためにじゅうぶんに団結している」ことを示す「完璧な例」として本作を挙げた。『CDJournal』は、本作をパニック！アット・ザ・ディスコこそが音楽シーンの新たな主役であることを宣言する、不敵かつエネルギッシュなロックンロール・ナンバーと紹介している。
『ビルボード』誌が発表した「（評論家が選んだ）史上最高のパニック!アット・ザ・ディスコの楽曲10選」では第4位にランクインした。
バージョン違い

トミー・サンシャインによってリミックスバージョンが制作されている。このリミックスバージョンは、2006年に公開された映画『スネーク・フライト』で使用され、同作のサウンドトラック・アルバムにも収録された。また、2006年5月22日にオーストラリアで発売されたCDシングル『アイ・ライト・シンズ・ノット・トラジェディーズ〜いつわりのウェディング』にも収録された。
2008年12月に発売されたライブ・アルバム『ライヴ・イン・シカゴ』には、『ホンダ・シヴィック・ツアー』のシカゴ公演でのライブ音源が収録された。2017年に開催された『ある独身男の死』ツアーでは、「『フィーバーは止まらない』メドレー」の1曲として演奏され、当時のライブ音源が同年12月に発売されたライブ・アルバム『All My Friends We're Glorious: Death of a Bachelor Tour Live』に収録された。
クレジット

※特記を除き、出典は『フィーバーは止まらない』のブックレット
ブレンドン・ユーリー – ボーカル、ギター、ベース、キーボード、ピアノ、アコーディオン、オルガン
ライアン・ロス – ギター、作詞、キーボード、ピアノ、アコーディオン、オルガン
スペンサー・スミス – ドラム、パーカッション
マット・スクワイア – プロデュース、エンジニア、ミキシング
パニック!アット・ザ・ディスコ – アディショナル・プロダクション
UEナスタシ – マスタリング
チャート成績

| チャート (2006年) | 最高位 |
| --- | --- |
US Billboard Hot 100: 77
US Alternative Songs (Billboard): 5
US Mainstream Top 40 (Billboard): 38
認定

| 国/地域 | 認定 | 認定/売上数 |
| --- | --- | --- |
| アメリカ合衆国 (RIAA) | Platinum | 1,000,000 |
  認定のみに基づく売上数と再生回数
ウィンクでさよなら

「ウィンクでさよなら」は、日本の歌手である沢田研二の16枚目のシングルである。
1976年5月1日にポリドール・レコードより発売された。
解説

作詞は「あの日にかえりたい」が大ヒットした直後の荒井由実、作曲は加瀬邦彦である。ちなみに荒井（のちの松任谷）は1978年2月28日、TV番組『ミュージックフェア』で共演した際「静かなまぼろし」を沢田に提供（作詞・作曲）したが、この楽曲が沢田によってレコーディングされ発売されたのは11年後の1989年のことであった（アルバム『彼は眠れない』に収録）。
収録曲

ウィンクでさよなら
作詞:荒井由実／作曲:加瀬邦彦／編曲:大野克夫
薔薇の真心
作詞:荒井由実／作曲:加瀬邦彦／編曲:東海林修
参加ミュージシャン

井上堯之バンド
井上堯之
速水清司　ギター
佐々木隆典　ベース
鈴木二朗
大野克夫
ケニー・ウッド・オーケストラ
ジュリアン・メリウェザー

| シカゴ・カブス #66 |
| --- | --- |
 トロント・ブルージェイズ時代 (2021年9月11日)
基本情報
国籍:   アメリカ合衆国
出身地:  カリフォルニア州アラメダ郡バークレー
生年月日:   (1991-10-14) 1991年10月14日（33歳）
身長 体重:  6' 4" ＝約193 cm 215 lb ＝約97.5 kg
選手情報
投球・打席:  右投右打
ポジション:  投手
プロ入り:  2014年 MLBドラフト5巡目
初出場:  2020年8月20日
経歴（括弧内はプロチーム在籍年度）
  フニペロ・セラ高等学校（英語版）  スカイライン・カレッジ（英語版）  オクラホマ・バプティスト大学  トロント・ブルージェイズ (2020 - 2022)  シカゴ・カブス (2023 - )
 この表について  この表はテンプレートを用いて表示しています。編集方法はTemplate:Infobox baseball playerを参照してください。 ■プロジェクト:野球選手  ■テンプレート  
ジュリアン・クリストファー・メリウェザー（Julian Christopher Merryweather, 1991年10月14日 - ）は、アメリカ合衆国カリフォルニア州アラメダ郡バークレー出身のプロ野球選手（投手）。右投右打。MLBのシカゴ・カブス所属。
経歴 > プロ入りとインディアンス傘下時代

2014年のMLBドラフト5巡目（全体158位）でクリーブランド・インディアンスから指名され、プロ入り。契約後、傘下のA-級マホーニングバレー・スクラッパーズでプロデビュー。13試合（先発12試合）に登板して1勝2敗、防御率3.66、35奪三振を記録した。
2015年はA級レイクカウンティ・キャプテンズでプレーし、21試合（先発4試合）に登板して2勝3敗1セーブ、防御率4.08、69奪三振を記録した。
2016年はA+級リンチバーグ・ヒルキャッツとAA級アクロン・ラバーダックスでプレーし、2球団合計で24試合に先発登板して13勝6敗、防御率2.60、114奪三振を記録した。
2017年はAA級アクロンとAAA級コロンバス・クリッパーズでプレーし、2球団合計で25試合に先発登板して7勝9敗、防御率5.32、128奪三振を記録した。オフの11月20日にはルール・ファイブ・ドラフトでの流出を防ぐために40人枠入りした。
2018年は3月にトミー・ジョン手術を受けたため、全休した。
経歴 > ブルージェイズ時代

2018年10月5日、8月31日に行われたジョシュ・ドナルドソンとのトレードの後日発表選手としてトロント・ブルージェイズへ移籍した。
2019年は傘下のルーキー級ガルフ・コーストリーグ・ブルージェイズとA+級ダニーデン・ブルージェイズでプレーし、2球団合計で2試合の登板にとどまった。オフにはアリゾナ・フォールリーグに参加し、メサ・ソーラーソックスに所属した。
2020年8月18日にMLBに初昇格を果たし、20日のフィラデルフィア・フィリーズ戦でMLB初出場を果たした。この年はMLBで8試合（先発3試合）に登板して防御率4.15、15奪三振を記録した。
2021年4月1日のニューヨーク・ヤンキースとの開幕戦1点リードの延長10回に抑えとして登板し、3者連続三振の快投を披露しMLB初セーブを記録した。5月5日に外腹斜筋の張りで60日間の故障者リストに入った。
2022年は26試合に登板し、0勝3敗で防御率6.75という成績であった。オフにブランドン・ベルトの加入に伴いDFAとなった。
経歴 > カブス時代

2023年1月17日にウェイバー公示を経てシカゴ・カブスへ移籍した。
投球スタイル

最速100.4mph（約161.6km/h）の速球にスライダーやチェンジアップを加える。
詳細情報 > 年度別投手成績

| 年  度 | 球団 | 登板 | 先発 | 完投 | 完封 | 無四球 | 勝利 | 敗戦 | セ丨ブ | ホ丨ルド | 勝率 | 打者 | 投球回 | 被安打 | 被本塁打 | 与四球 | 敬遠 | 与死球 | 奪三振 | 暴投 | ボ丨ク | 失点 | 自責点 | 防御率 | WHIP |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 2020 | TOR | 8 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | ---- | 55 | 13.0 | 11 | 0 | 6 | 0 | 0 | 15 | 0 | 0 | 6 | 6 | 4.15 | 1.31 |
| 2021 | TOR | 13 | 1 | 0 | 0 | 0 | 0 | 1 | 2 | 1 | .000 | 55 | 13.0 | 13 | 4 | 4 | 0 | 1 | 12 | 2 | 0 | 7 | 7 | 4.85 | 1.31 |
| 2022 | TOR | 26 | 1 | 0 | 0 | 0 | 0 | 3 | 0 | 1 | .000 | 119 | 26.2 | 31 | 4 | 7 | 1 | 2 | 23 | 1 | 0 | 20 | 20 | 6.75 | 1.43 |
| 2023 | CHC | 69 | 0 | 0 | 0 | 0 | 5 | 1 | 2 | 17 | .833 | 303 | 72.0 | 58 | 8 | 36 | 0 | 1 | 98 | 3 | 0 | 28 | 27 | 3.38 | 1.31 |
| 2024 | CHC | 15 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 2 | .500 | 74 | 15.0 | 18 | 0 | 9 | 0 | 3 | 14 | 2 | 0 | 11 | 11 | 6.60 | 1.80 |
| MLB：5年 | MLB：5年 | 131 | 5 | 0 | 0 | 0 | 6 | 6 | 4 | 22 | .500 | 606 | 139.2 | 131 | 16 | 62 | 1 | 7 | 162 | 8 | 0 | 72 | 71 | 4.58 | 1.38 |
2024年度シーズン終了時
詳細情報 > 年度別守備成績

| 年 度 | 球 団 | 投手（P）> 試  合 | 投手（P）> 刺殺 | 投手（P）> 補殺 | 投手（P）> 失策 | 投手（P）> 併殺 | 投手（P）> 守備率 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 2020 | TOR | 8 | 0 | 3 | 0 | 0 | 1.000 |
| 2021 | TOR | 13 | 0 | 1 | 0 | 0 | 1.000 |
| 2022 | TOR | 26 | 0 | 1 | 0 | 0 | 1.000 |
| 2023 | CHC | 69 | 3 | 2 | 0 | 0 | 1.000 |
| 2024 | CHC | 15 | 2 | 1 | 0 | 0 | 1.000 |
| MLB | MLB | 131 | 5 | 8 | 0 | 0 | 1.000 |
2024年度シーズン終了時
詳細情報 > 背番号

67（2020年 - 2022年）
66（2023年 - ）
Extensible Markup Language

| --- | --- |
: 「.xml」はこの項目へ転送されています。その他のファイル形式については「Category:XMLベースの技術」をご覧ください。
| --- | --- |

拡張子: .xml
MIMEタイプ: application/xml
UTI: public.xml
開発者: World Wide Web Consortium (W3C)
初版: 1998年 (27年前) (1998)
種別: マークアップ言語
派生元: Standard Generalized Markup Language (SGML)
拡張: XHTML、DocBook、RSS、ebXML、 ...
国際標準: 1.0 (Fifth Edition) 1.1 (Second Edition)
Extensible Markup Language（エクステンシブル マークアップ ランゲージ）は、基本的な構文規則を共通とすることで、任意の用途向けの言語に拡張することを容易としたことが特徴のマークアップ言語の総称である。一般的にXML（エックスエムエル）と略称で呼ばれる。JISによる訳語は「拡張可能なマーク付け言語」と定義している。XML文書のフォーマットをあらかじめ統一することで、異種プラットフォーム間での情報交換も可能となる。
SGMLからの移行を目的として開発された。文法はSGMLの構文解析器と互換性を保つようにSGMLのサブセットに定められシンプルになり、機能はSGMLに無いものが追加されている。
XML の仕様は、World Wide Web Consortium (W3C) により策定・勧告されている。1998年2月に XML 1.0 が勧告された。2010年4月現在、XML 1.0 と XML 1.1 の2つのバージョンが勧告されている（#バージョン）。
ちなみに、「eXtensible Markup Language の略である」と書かれることがあるが、これは間違いであり、XはExの発音を表している。
概要 > 基礎的概念と利用目的

XMLは、個別の目的に応じたマークアップ言語を定めるための汎用的言語であり、「タグの入れ子」式の構文が拡張性を容易にするとして「extensible」を謳っている。
データ構造としては木構造になるため、巡回があるようなネットワーク構造を直接扱うことはできない（XLinkなどの提案がある）。
XMLの最も重要な目的は、異なる情報システムの間で構造化された文書や構造化されたデータの共有を容易にすることである。
概要 > HTMLとXMLの違い

Webページを記述するマークアップ言語であるHTMLは、XMLと文法がよく似ている。これはどちらもSGMLが元になっているためである。
HTMLが特定目的のための言語であるのに対し、XMLはHTMLのような特定目的のための言語を新たに定めるための仕組みであり、タグを定義する事でXMLベースのマークアップ言語を定義することができる。実際、HTMLと同等の機能をXMLによって定義したXHTMLが開発されている。
概要 > 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文書を視覚的に表示する、#XML情報集合を参照）。
以下に挙げるものをはじめとして、現在も多くの関連技術の標準化作業が行われている。
プログラムからXML文書を処理する方法として、Document Object Model (DOM) や Simple API for XML (SAX) などのアプリケーションプログラミングインタフェース (API) が標準化されている。
XML文書のスタイルを指定する技術（スタイルシート）として Extensible Stylesheet Language (XSL) や Cascading Style Sheets (CSS) などがある。
XML文書を非テキスト形式（バイナリ）で効率的に表現する方法として、World Wide Web Consortium (W3C) は Efficient XML Interchange (EXI) フォーマットを定義した。
概要 > XMLの普及とXMLへの批評

XMLは現在、広く普及している技術であるが、その技術的な有用性などについて、肯定的に評価する人々が多い一方で、批判的に評価する人々も多い （#XMLに対する支持と批判を参照）。
整形式XML文書と妥当なXML文書

XML文書の正当性の水準には、整形式XML文書と妥当なXML文書の、2つの水準がある。なおXML文書に対して、整形式XML文書としての検査のみを行うXMLプロセサを非検証XMLプロセサといい、整形式XML文書としての検査に加えて妥当なXML文書としての検査を行うXMLプロセサを検証XMLプロセサという。
XMLの構文と整形式XML文書 > 多言語環境で使う

XML文書ではどのUnicodeの文字も （XMLで特別な意味をもつ、開き山括弧 "<" のような文字を除いて）、要素名として、属性名として、コメント内容として、文字データとして、処理命令 （後述） として、直接に使うことができる。このため、漢字とキリル文字を共に含む次の文書も、整形式XML文書である。
<?xml version="1.0" encoding="UTF-8"?>
<俄語>Данные</俄語>
XMLの構文と整形式XML文書 > 文書型宣言

XML文書 （あるいはSGML文書、HTMLウェブページを含む） において、文書型宣言 （DOCTYPE宣言、Document Type Declaration） は、その文書を特定の Document Type Definition(DTD、文書型定義) のスキーマと関連づけることを記述するものである。なお、Document Type Definition (DTD、文書型定義)は、XMLで使うことができるスキーマ言語の一つである。文書型宣言は、その文書が特定のスキーマに準拠していることを宣言する。
XML文書では文書型宣言を記述してもよいし、記述しなくてもよい。DTDをスキーマ言語として妥当性検証を行うことを想定しているのであれば、文書型宣言の記述は必須となるであろう。DTDで妥当性検証を行わない場合でも、後述する実体参照などを文書中で使うのであれば、文書型宣言において文書中で使う実体を宣言することができる。
文書型宣言は、その文書が特定のスキーマに準拠していること （妥当なXML文書であること） を、保証しているわけではない。文書型宣言に記されたスキーマに準拠しているかどうかを判断するには、検証XMLプロセサでその文書を検証する必要がある。
文書型宣言の一般的な構文は次のとおりである。
<!DOCTYPE ルート要素名 [SYSTEM もしくは PUBLIC 公開識別子] 外部サブセット参照 [
 <!-- 随意に内部サブセットを記述する -->
]>
ここで外部サブセットとは、そのXML文書のDTDを構成する （要素の型の宣言、後述する実体の宣言などの） 宣言群のうち、別ファイルに記述された宣言群のことである。また内部サブセットとは、そのXML文書のDTDを構成する宣言群のうち、文書型宣言内に直接記述された宣言群のことである。
XHTML 1.0 Strict に準拠したXML文書での文書型宣言は、次のとおりである。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XML文書においては、ルート要素がその文書の最初の要素である （例えば、XHTMLではルート要素は html である）。SYSTEM キーワードと PUBLIC キーワードは、その文書型 （文書の構造） の種類を指定する。一般に広く知られていないDTDを使う場合は、SYSTEM キーワードを使う。一般に広く知られているDTDを使う場合 （XHTMLなど） は、PUBLIC キーワードを使う。
SYSTEM キーワードを使う際は、その後に続けて、その文書が準拠するDTDのファイルのURIを、外部サブセット参照として記述する。
PUBLIC キーワードを使う際は、その後に続けて、その文書が準拠するDTDの公開識別子 (public identifier) を指定しなければならない （例えば XHTML 1.0 の公開識別子は、"-//W3C//DTD XHTML 1.0 Strict//EN" である）。公開識別子を記述した後に続けて、SYSTEM キーワードを使う場合と同様に、その文書が準拠するDTDのファイルのURIを、外部サブセット参照として記述する。
内部サブセットは必要に応じて記述する。
内部サブセットとして、DTDの一部分もしくはDTDの全体を記述することができる。
なお、内部サブセットとしてDTDの全体を記述する場合は、SYSTEMキーワード・PUBLICキーワード・外部サブセット参照は、いずれも記述しない。
XMLの構文と整形式XML文書 > 実体参照

実体参照 (entity reference) は、実体を表現するプレースホルダである。
XMLにおける実体 (entity) とは、SGMLにおける実体と同じように、名前の付けられたデータの本体である。具体的には、ファイルもしくは置換文字列のように、何らかの形でXML文書の一部となるデータを格納しているもののことである。置換文字列を使う事例としては、次のような場合がある。
キーボードから簡単には入力できない文字をXML文書中に表現したい場合。
決まった単語の並びがXML文書中に何度も出現する場合。
実体参照の構成は、まず最初にアンパサンド ("&") があり、その後に実体の名前が続き、セミコロン (";") で終わる。
XMLには、事前宣言された実体として次の表に示す5つの実体がある。
| 実体参照 | 実体 | 実体の説明 |
| --- | --- | --- |
| &amp; | & | アンパサンド (ampersand) |
| &lt; | < | 小なり (less than) |
| &gt; | > | 大なり (greater than) |
| &apos; | ' | アポストロフィ (apostrophe) |
| &quot; | " | クォーテーションマーク (quotation mark) |
「AT&T」の名前でアンパサンドを表現するために、事前宣言されたXMLの実体を使う例を示す。
<会社名称>AT&amp;T</会社名称>
事前宣言された実体以外の実体を宣言する必要がある場合、XML文書の Document Type Definition （DTD、文書型定義） の内部で宣言する。
XML文書の内部に定義されたDTDを使って、置換文字列としての実体を宣言して、実体参照を使う例を次に示す。宣言された実体は、一つの文字であっても良いし、テキストの断片であっても良いし、他の実体への参照を含むテキストであっても良い。
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE 例 [
    <!ENTITY copy "©">
    <!ENTITY copyright-notice "Copyright © 2007 平成新報社">
]>
<例>
    &copyright-notice;
</例>
XMLに準拠したブラウザを使うと、先のXML文書は次のように表示される。
Copyright © 2007 平成新報社
ファイルの実体を参照するXML文書の例を示す。
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE 文章 [
    <!ENTITY tsutsui-yasutaka SYSTEM "another-file.xml">
]>
<文章>
 <文>星新一はSF作家である。</文>
 <文>小松左京はSF作家である。</文>
 &tsutsui-yasutaka;
</文章>
なお、別ファイル another-file.xml には次の内容が記されていることとする。
<文>筒井康隆はSF作家である。</文>
XMLに準拠したブラウザでこのXML文書を表示すると、次のようになる。
星新一はSF作家である。小松左京はSF作家である。筒井康隆はSF作家である。
XMLの構文と整形式XML文書 > 文字参照

文字参照 (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</会社名称>
→「文字参照」も参照
XMLの構文と整形式XML文書 > 処理命令

処理命令 (processing instruction) は、XML文書の構成要素であり、XML文書を扱うソフトウェアに対する何らかの処理を行う命令を、記述する内容が、処理命令である。
次に処理命令の構文を示す。
<?処理命令ターゲット 処理内容?>
処理命令は ?> の文字列を除き任意の処理内容を記述することができる。処理命令には、処理内容として擬似属性 (pseudo attribute) を記述することがある。擬似属性は、記述のしかたが属性名と属性値のペアに似ている。しかしXMLプロセサは擬似属性を、属性として解釈せず、処理命令の処理内容として解釈する。
擬似属性を使った処理命令の例を次に示す。
これはXML文書にカスケーディングスタイルシート (CSS) と関連づけるという処理命令である。
<?xml-stylesheet type="text/css" href="monobook.css"?>
あるXML文書内に記述された特定の処理命令について、その処理命令をプログラマーが意図したとおりの処理を実行させるためには、そのXML文書を処理するアプリケーションソフトウェア側がその処理命令に対応する必要がある。
XMLの構文と整形式XML文書 > CDATAセクション

XML文書 （およびSGML文書） においてCDATAセクションとは、文字列データのみで構成されておりマークアップされたデータは含まれていないと、XMLプロセサが解釈するようマークされた、要素の内容を構成する文字列データの一部である。CDATAセクションは、文字列データを表現するための単なる代替構文である。
CDATAセクションとして宣言された文字列データと、"<" と "&" を "&lt;" と "&amp;" で表現する通常の構文で記述した文字列データとの間に、意味的な違いはない。
XMLの構文と整形式XML文書 > CDATAセクション > 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文書は、とりわけ、次に示す規則に適合しなければならない。
空要素ではない要素は開始タグと終了タグの両方によって境界が定められる。
空要素は空要素タグ （自分自身で開始タグと終了タグの2つの機能を兼ねるタグ） で記述することができる。例えば <私は空です/> のように記述することができる。この例は <私は空です></私は空です> と意味的に同等である。
属性値は全てシングルクォート (') かダブルクォート (") のいずれかで括る。シングルクォートで始められた属性値はシングルクォートで終わり、ダブルクォートで始められた属性値はダブルクォートで終わる。
タグは入れ子の構造をとることができる。ただしタグがオーバーラップしてはならない。ルート要素ではない要素のおのおのは、必ず別の要素に含まれる。
XML文書は宣言された文字符号化方式 （文字コード） にしたがって記述される。文字符号化方式は、XML文書がHTTPを介して転送される場合に "Content-Type" ヘッダをつけるように暗黙的にXML文書の外部で指定しても良いし、XML文書の内部で文書の先頭のXML宣言内で宣言しても良い。このような宣言がない場合、Unicodeの文字符号化方式が使われていると仮定される。XML文書の最初のバイトをみて、UTF-16のバイト順マークと合致すればUTF-16であると仮定する。合致しない場合はUTF-8であると仮定する。
要素の名前ではアルファベットの大文字と小文字とが区別される。例えば、次の例は整形式である。
<Abc> ... </Abc>
しかし次の例は整形式ではない。
<ABC> ... </abc>
XML文書のスキーマを設計する際に、XMLの要素の名前を注意深く選択すると、そのスキーマに準拠したXML文書のデータの意味を、第三者に伝えるために有効であろう。XMLの要素の名前を注意深く選択することにより、そのスキーマに準拠したXML文書は、人間にとって読みやすいものとなる。
XMLの要素と属性の名前を、体が名を表すように注意深く選択決定することで、人間がXML文書を読む際に、要素と属性の意味を、外部の説明文書を参照することなく、よりよく理解できるようになる利点が生まれる。ただしこのような作業を行うことは、XML文書の冗長性が増えることでもある。
人によっては、XML文書を書く際の労力が増えることを、好まない場合がある。またファイルサイズも大きくなることになる。ただし圧縮技術をXML文書に適用してファイルサイズを小さくすることは可能である。
整形式XML文書を正確に書くためには、ここまで述べたことよりずっと多くの規則にしたがう必要がある。例えば、XML名前空間を使うことや、XMLでの「名前」として使うことができる正確な文字集合を使って、XML文書を書くことなどである。とはいえ、ここまで述べた整形式文書に関する概略を理解しておけば、多くのXML文書を読み理解しあるいは多くのXML文書を書くために必要な基礎は、身についたといえる。
XMLの構文と整形式XML文書 > 自動的に検査する

XML文書の正当性を自動的に検査するための方法を説明する。
あるXML文書が、整形式XML文書としての条件のみを満たした文書であるか、それとも妥当なXML文書としての条件をも満たした文書であるかを、判別することは、比較的容易である。というのも、整形式XML文書であるための規則と、XMLの妥当性検証のしくみについては、XML文書を扱うツールの移植性を考慮して設計されているからである。つまりこの設計方針は、XML文書を扱うツールであれば、どのようなXML文書でも扱うことができるということである。
独立したツールを使い、XML文書の正当性を自動的に検査する例を示す。
XML文書を扱えるウェブブラウザで、例えば Mozilla Firefox や Internet Explorer などで、XML文書をロードする。
xmlwf のようなツールを使う （XMLプロセサの実装の一つである Expat（英語版） に通常は同梱されている）。
何らかのプログラミング言語を使って文書を構文解析する。例えばプログラミング言語Rubyでは次のようになる。
irb> require "rexml/document"
irb> include REXML
irb> doc = Document.new(File.new("test.xml")).root
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エディタでは、妥当な要素名や妥当な属性名を提示することなどができる。
XML文書の論理的構造と妥当なXML文書 > Document Type Definition (DTD、文書型定義)

→詳細は「Document Type Definition」を参照
XMLのための最も歴史の古いスキーマ言語は Document Type Definition (DTD、文書型定義) である。DTDは、XMLの前身であるSGMLから引き継がれた。DTDは XML 1.0 標準に含められているため、ほとんどあらゆるXMLプロセサがDTDを扱うことができる。しかし2007年現在ではDTDを使うことは限定的な範囲にとどまっているようである。その理由は次のとおりである。
DTDではXMLで新しく開発された機能を使うことができない。特にXML名前空間を扱えないことが厳しい。
DTDは表現力が乏しい。DTDではいくつかの形式的な視点からXML文書を扱うことができない。
DTDによるスキーマはXMLではない独自の構文で記述する。この構文は、XMLの前身であるSGMLから引き継いでいるという、経緯がある。XML 1.0 の制定当時はDTD以外のスキーマ言語は存在しなかった。
DTDは現在も多くの用途で使われている。その理由は、一定の人々にとってはDTDは他の新しいスキーマ言語よりも読みやすく書きやすいと考えられているからである。
XML文書の論理的構造と妥当なXML文書 > Document Type Definition (DTD、文書型定義) > XML Schema

→詳細は「XML Schema」を参照
XML Schema は、World Wide Web Consortium (W3C) により開発された、DTDの後継となる新しいスキーマ言語である。
非公式には、XSDと呼ばれることもある。XSDは、XML Schema のインスタンス (スキーマ) を意味する "XML Schema Definition" の頭字語である。
XML Schema は、豊富なデータ型を扱うことができるスキーマ言語である。XML文書の論理的構造について、DTDより詳細な制約を記述することができる。そしてDTDより詳細な妥当性検証の枠組みのもとで、妥当性検証が行われる。他にも、XMLによるマークアップ言語のスキーマの記述能力において、DTDと比べて非常に高いという長所も備えている。
また、XML Schema によるスキーマ自体を、XMLに準拠した形式を使って記述する。XML Schema のスキーマ自体がXMLに準拠することで、スキーマを編集したりスキーマに何らかの処理を行うために、普通のXMLツールを使うことができるようになる。
ただし、XML Schema の妥当性検証器を実装する作業には、単にXML文書を読むことができる能力よりも、非常に多くの知識と能力を必要とする。
XML Schema に対しては賛否両論がある。XML Schema に対する批判の一部を示す。
XML Schema の仕様は非常に膨大な分量がある。そのため XML Schema を理解することは難しい。またそのため XML Schema の妥当性検証器を実装することも難しい。
XML Schema でスキーマを記述する際、XMLに準拠した構文で記述する (記述しなければならない) のは、冗長である。このことが XML Schema のスキーマを理解することやスキーマを記述することを、DTDよりしんどい作業にしてしまっている。
XML文書の構文解析をした後に行う、XML Schema のスキーマによる妥当性検証は、費用が高くつく可能性がある。特にサイズの大きいXML文書の妥当性検証を行う際には、深刻な問題になる可能性がある。
XML Schema のデータモデリング能力は非常に限られている。属性の内容によってその要素の内容モデルを変更することはできない。
XML Schema における型派生モデルは、非常に限られた能力しかない。特に拡張による派生は、かなり使いにくい。
データベースと連携するためのデータ転送機能は、不可解な考え方によって実現されている。nillability (SQLデータベース用語でいうNULLに相当する状態をとることが可能であるという特性) は備えているが、出版業界の要件は満たしていない。
key/keyref/uniqueness の機構は、データ型を考慮していない。
スキーマ検証後情報集合 (PSVI、Post Schema Validation Infoset) の概念は、標準のXML表現やアプリケーションプログラミングインタフェース (API) をもたない。このため、妥当性の再検証を行わない場合、ベンダ非依存の考え方に反する (#情報集合への追加情報を参照)。
XML文書の論理的構造と妥当なXML文書 > Document Type Definition (DTD、文書型定義) > RELAX NG

→詳細は「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 では、データ型フレームワークプラグインを使うことにより可能となっている。