XML の将来 XML については理解できました。確かに構造が少し複雑で、DTD にはドキュメントに含めることができるものを定義するためのさまざまなオプションがあります。しかし、それだけではありません。
銀行など、データ交換が重要な業界を考えてみましょう。銀行は所有権システムを使用して内部取引を追跡しますが、Web 上で共通の XML 形式を使用する場合は、取引情報を別の機関またはアプリケーション (Quicken や MS Money など) に記述する必要があります。もちろん、Web ページ上のデータを表すこともできます。参考：このタグは存在しません。それはOFEX、オープン金融取引所と呼ばれています。
特定の状況下では、PC 上の IE 4 が
ここには、Andy Grove が 1970 年代に見た足し算機、タイプライター、鉛筆とは異なる 3 つの XML アプリケーションがあります。しかし、最終的に PC 上に登場したアプリケーションと同様に、XML の利点は一般的に次のように説明できます。「人間と機械が読み取り可能なタグを使用してデータを記述すると、良いことが起こります。
」 ?わからない。しかし、私の PC 上の次世代プログラムがどのようなものになるのかもわかりません。このようにデータにタグが付けられていれば、さまざまなアプリケーションを生成できます。
それがどこまで拡大するかについて考え始めていますか？
XML の実践的な応用例はたくさんありますので、近いうちに取り上げる予定です。私たちは皆インターネット ユーザーなので、将来は XSL (Extensible Style Language) になるでしょう。
拡張可能なスタイル言語)。
ちなみに、このレシピは確かに私の母のもので、絶品です。それを使用する場合は、すりおろしたココナッツをさらに半カップ加えます。
私がこれを書いているのは、あなたが私のことをどう思っているかが本当に気になるからです。私の懸念は、XML についての私の入門書を読んで、独自の XML ドキュメントを書き始める準備ができているかどうかです。そこで、情報を表すためにすでに確立されている DTD を探し始めます。以下に示すように、1 つが見つかります。
%attr.lang;
値 CDATA #FIXED "TEXT">
img.type CDATA #REQUIRED
img.data ENTITY #REQUIRED">
すぐにジェイは馬鹿に違いないと思うだろう。彼は ATTLIST と ENTITY が何であれ、それについては何も言いませんでした。
それでは、まずは少し辛抱してこれについて話しましょう。
上の行は見栄えが良くないかもしれませんが、実際には何もありません。これらは、DTD で XML ドキュメントの属性とエンティティを定義するために使用されます。 HTML を知っている人なら誰でもこれをよく知っているでしょう。属性は、タグをより正確に説明する HTML タグを含むエントリです。よく登場する 
には、高さと幅の 2 つの属性があります。後で説明するように、XML ドキュメントでの属性の使用は非常に似ています。
エンティティについても新しいことは何もありません。 & を使用したことがある場合は、基本をすでに知っています。 & とセミコロンで囲まれた文字列は、別の文字または文字のセットを表します。 (ISO エンティティの完全なリストはここで入手できます。)
もちろん、XML の属性とエンティティには他の機能もあります。これにより、それほど多くはありませんが、必然的に構文が導入されます。これを理解すれば、XML ドキュメントの操作は簡単になります。
簡略化されたレシピ
XML についての私の入門を読んだ方は、レシピ内の材料が
このアプローチには、データの管理が容易になるという実用的な利点があります。最初のアプローチでは、
次の構造を使用して同様の機能を実現できます。
<アイテム>小麦粉
<数量>2
<単位>カップ
これは処理できますが、2 つの問題があります。まず、item 要素にはテキストとその他のマークアップの混合コンテンツが含まれています。この構造は可能な限り避けるべきであることがすぐにわかりました。 2 つ目は、マーカーには独立した意味がほとんどないことです。ユニットだけがあって実際のコンポーネントがない状況を想像するのは困難です。これらの項目は簡単に説明できますが、私はプロパティとして考えることを好みます。
まず注意すべきことは、属性名、数量、および単位は、それらを翻訳できるアプリケーションによって処理される場合にのみ意味があるということです。
有効なドキュメントに含める前に、DTD に許可するように指示する必要があります。上記の成分要素の場合、DTD には次のコードのみが含まれています。
最初の行は見覚えのあるもので、DTD でよく見かける標準的な要素定義です。各 ATTLIST 行には、次の情報が順番に含まれます。
属性が付加される要素です。
ここで属性名を定義します。
ここで属性タイプを設定します。 CDATA は文字データの略です。つまり、プロセッサは属性内のテキストを取得できます。
最後の部分では、属性のデフォルト値を定義します。 3 などの実際の数値を使用できます。このようにすると、XML の空白の長さの属性値は 3 になります。入力した値はデフォルト値をオーバーライドします。
上の例では、特定の数量を設定しませんでしたが、XML キーワード #REQUIRED を使用しました。これは、セカンダリ属性に値が含まれている必要があることをプロセッサに伝えます。空白の場合、文書は処理されません。
デフォルト値には 2 つの追加キーワードがあります。 1 つ目は #FIXED - 属性値がドキュメント全体で同じ値のままである場合です。画像タグ属性を定義し、すべての画像が同じサイズ (100*50 ピクセルなど) であると仮定します。DTD では次のように属性を定義できます。
もう 1 つのキーワードは #IMPLIED で、プロパティに値を含めることも空にすることもできることを示します。
属性の種類を見てみましょう。
独自の DTD を作成する場合は、ATTLIST ステートメント内のすべての組み合わせの XML を説明した本が必要になる場合があります。ただし、DTD を借用する場合は、CDATA と他の 3 つの属性しか知らない可能性があります。
一つ目はIDです。属性の値が文書内で繰り返されないことが必要です。データベースを使用したことがある人なら、一意の識別子の必要性を知っています。 DTD ATTLIST ステートメントは次のようになります。
デフォルト値 #REQUIRED なしで ID 属性の型を想像するのは困難です。その場合、重複した ID または空の ID があると、プロセッサは強制的にエラーを返すことになります。 ID は文字またはアンダースコアで始まる必要があり、スペースを含めることはできません。
NMTOKEN タイプも上記の命名規則を使用します。ただし重複は認められます。これは、アプリケーションにデータを渡すための保証として使用されます。 Java や JavaScript を含むほとんどのプログラミング言語では、モジュール名にスペースを含めることはできません。ほとんどの場合、施設がそのルールに準拠していることを確認することが最善です。
最後に、特定のキーワードを必要としない列挙型があります。代わりに、「|」記号を使用して値を括弧で囲みます。例:
この方法は、使用可能な属性値の数が限られている場合に使用できます。
今日のコースが退屈だとは思わないので、読み続けてください。