第13回 論理構造と開始タグ、終了タグ、空要素タグ
XML 1.0は、1998年にW3Cから勧告として公開された。当然中身は英語で、しかもEBNFと呼ばれる式によって重要な部分が記述してある。この連載では、XML 1.0を深く理解するために、そのXML 1.0勧告の最新版「Extensible Markup Language (XML) 1.0 (Second Edition)」をだれでも分かるように、やさしく読み解きながら解説していくことを目指している。(編集局)
川俣 晶
株式会社ピーデー
2003/9/6
■論理構造(開始タグ、終了タグ、空要素タグ)を読む
今回の主な内容 論理構造(開始タグ、終了タグ、空要素タグ)を読む 要素の定義 要素のEBNF定義 整形式制約の定義 妥当性制約の定義 開始タグ、終了タグ、空要素タグ 開始タグ 整形式制約と妥当性制約 終了タグ contentの定義 空要素タグ |
前回は、XML1.0勧告の中で「2.10 White Space Handling」(2.10 空白の取扱い)、「2.11 End-of-Line Handling」(2.11 行末の取扱い)、「2.12 Language Identification」(2.12 言語識別)を読み切って、「2 Documents」(2 文書)は終わった。
いよいよ今回から、まったく新しい章に入り「3 Logical Structures」(3 論理構造)から「3.1 Start-Tags, End-Tags, and Empty-Element Tags」(3.1 開始タグ、終了タグおよび空要素タグ)までを読んでいく。
おそらく、ここからがXML仕様の一番分かりやすく、面白いところだろう。XMLを学ぶ者ならだれでも最初に出合う要素や属性についての直接的な説明がここにあるためだ。抽象的な概念や細かい文字の扱いなどに比べれば、とてもエキサイティングである。次回以降には、要素宣言など、DTDに関する機能についての説明も出てくる。DTDに含まれる概念の多くは、RELAX NGやXML Schemaといった新しいスキーマ言語でもそのまま役立つものである。構文は時代遅れになっても、概念は生き続けているので、これを学ぶことは大いに意義がある。
編集注:この連載では、XML 1.0勧告であるW3Cの「Extensible Markup Language (XML) 1.0 (Second Edition)」(英語)を参照し、その日本語訳として、日本工業規格 JIS X 4159:2002(リンク先は該当規格の原案ですが、最終版とほぼ同等の内容です)を参照しています。本文中のピンクの地の部分は、XML 1.0勧告の原文を示しています。 |
「3 Logical Structures」(3 論理構造)を読み始めよう。最初は要素についての定義から始まる。
[Definition: Each XML document contains one or more elements, the boundaries of which are either delimited by start-tags and end-tags, or, for empty elements, by an empty-element tag. Each element has a type, identified by name, sometimes called its "generic identifier" (GI), and may have a set of attribute specifications.] Each attribute specification has a name and a value. |
[定義:いかなるXML文書も、1つ以上の要素を含み、要素の境界は、開始タグおよび終了タグによって区切られ、要素が空要素のときは、空要素タグで区切られる。各要素は名前(共通識別子またはGIと呼ばれる)によって識別される型を持ち、いくつかの属性を持ってもよい。]属性は名前および値を持つ。 |
この段落は、最後の文を除き、element(要素)という言葉についての定義になっている。前半の文はいくつかの情報を含んでいる。
まず、要素は、1つのXML文書に1つ以上存在することが示されている。1つ以上ということは、要素がゼロということはあり得ない、ということを示す。最低1つ存在する要素が文書要素(ルート要素)である。次に、要素の境界の区切り方が2つ書かれている。1つは、開始タグと終了タグで前後を区切る方法。もう1つは、空要素タグを使う方法である。開始タグと終了タグで区切る方法は、その間の領域が要素の内容となる。空要素タグを使った場合は、要素の内容は存在しない。
これらの用語、開始タグ、終了タグ、空要素タグ、そして空要素はまだ出現していない言葉である。これはこれから解説される。あまり良い書き方ではないが、HTMLで書かれた仕様書はハイパーリンクが埋め込まれており、必要な説明を参照しながら読むことができるので、まあこれでもよいか、という気もする。
次の文も、複数の情報が詰め込まれているので分解して理解しよう。「要素には型がある」と書かれている。ここでいう型とは、プログラム言語でよくある整数型や実数型といったものではなく、XMLのID型やNMTOKEN型とも違う。要素の型は、この後の要素型という言葉で使われるもので、要素の名前によって識別される要素固有の型である。
もう1つ共通識別子、generic identifier、GIという言葉が出てくるが、これらの言葉はSGML時代の用語であって、XMLの世界ではあまり見掛けない。これらは要素型を示す名前の別名なので、特に深く突っ込んで理解しなくてもよいだろう。
最後の文は「各要素はいくつかの属性を持つことができる」とも書かれているが、これはXMLを知っている読者なら、問題なく理解できるだろう。
そして、要素の定義に含まれない最後の文では「属性は名前および値を持つ」としている。これは、ここで詳しく意味を考える必要のある文ではない。属性の名前と値については、後で詳しく出てくる。
さて、次は要素(element)のEBNF定義である(EBNFの詳細については、「第2回 XML勧告読解に必須のEBNF」を参照)。
Element
|
This specification does not constrain the semantics,
use, or (beyond syntax) names of the element types and attributes,
except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l') )
are reserved for standardization in this or future versions of this
specification. |
この版または今後の版のこの仕様で、標準化のために予約される正規表現(('X'|'x')('M'|'m')('L'|'l'))にマッチする文字列で始まる名前を除き、この仕様は、要素型および属性の意味、使用方法、または(構文に関することを除き)名前に制約を与えない。 |
これはそれほど難しいものではないだろう。要素(element)は、EmptyElemTagまたは、STag content ETagのいずれかということになる。EmptyElemTagは後で定義が出てくるが、ようするに空要素タグである。STagは開始タグ、contentは内容、ETagは終了タグである。ここで特に注意して読み取るべきところは、終了タグに省略を許容するようないかなる表記も付いていないことである。SGMLでは、条件によって終了タグが省略可能である場合があるのだが、XMLにはそのような規定は存在しない。どのような場合でも、終了タグは省略できない。
要素型や属性の意味、使い方、名前に制約を与えないというのが次のポイントである。例えば要素名は名詞を使い、先頭は大文字で書き始める、といったルールはこの仕様書内に存在しないのである。どのような名前を使って何を表現しても構わない。無責任のようにも思えるが、メタ言語つまり言語をつくる言語とは、そういうものである。要素や属性の名前や意味は、言語をつくる段階で考えるべき作業である。
さて、もう1つのポイントは、大文字小文字を問わず“XML”という文字列で始まる名前は使用できないと書かれている。しかし、これは、「2.3 Common Syntactic Constructs」(2.3 共通の構文構成子)で既に書かれていた規定の繰り返しである。これは、EBNF定義“Name”に対しての規定だが、要素名と属性名はNameを参照しているので、実際には同じ規定が適用されていることになる。
次は、整形式制約についての定義である。
Well-formedness constraint: Element Type Match The Name in an element's end-tag must match the element type in the start-tag. |
整形式制約:要素型のマッチ |
これは、Well-formedness constraint: Element Type Match(整形式制約:要素型のマッチ)について書かれたものである。要素型とは要素の名前であるから、開始タグの名前と終了タグの名前は一致しなければならない、という意図を読み取ることができる。
XMLを使っていれば当たり前のことだが、EBNFを忠実に読んでいくと、開始タグの名前と終了タグの名前が一致しなければならないという制限を読み取ることができない。これはEBNFに出てくる開始タグのNameと、終了タグのNameが同じでなければならない意図を表現する手段がないからである。そのため、EBNF外に制約として記述される必要がある。
次は、妥当性制約についての定義である。
Validity constraint: Element Valid An element is valid if there is a declaration matching elementdecl where the Name matches the element type, and one of the following holds:
|
妥当性制約:要素の妥当性
|
これは、Validity constraint: Attribute Value Type(妥当性制約:要素の妥当性)についての定義である。要素の妥当性という言葉から分かるとおり、まさに要素が妥当であるとはどういうことかを説明している。
冒頭の文から、4つの条件のどれか1つを満たせばよいことが分かる。条件は1〜4の数字で書かれているが、JIS版ではアルファベット小文字でa〜dが振られている。
条件1は空要素の場合を意味する。「宣言がEMPTYにマッチ」とは要素型宣言でEMPTYというキーワードを使って宣言している場合を意味する。これは後で詳しい話が出てくる。要素型宣言でEMPTYと宣言して、要素に内容がない場合は「要素の妥当性」が満たされるということである。ちなみに、この場合は要素の内容に、実体参照・コメント・PI・空白も持つことはできない。例えば、<a></a>はよいが、内容に半角空白を挿入して<a> </a>と書くと、もう妥当ではなくなってしまう。
条件2は、2つの文から構成されていて、少し長く分かりにくいので、ゆっくりと読み解いていこう。「宣言が生成規則childrenにマッチ」という言葉は仕様書の後の方で定義される生成規則childrenを参照しており、「内容モデル中の正規表現によって生成される言語」については、ある程度の基礎的素養とSGML系マーク付け言語の常識をもって挑まないと、把握しきれないだろう。
これはまず、その要素の要素型宣言が生成規則childrenにマッチしている場合の話である。そして、内容の子要素の並びがある条件を満たしている必要があり、その条件とは、要素型宣言で宣言された内容の定義(内容モデル)と一致していることである。ここではより厳密な言葉を使って、内容モデルに一致している、と書く代わりに「内容モデル中の正規表現によって生成される言語に属する」と書いている。ここでいう言語とは「XMLはメタ言語である」という場合の「言語」とはニュアンスが異なる。抽象的な意味での、ある種の構造を持つ構成要素の並びを「言語」と呼び、それが内容モデルを定義する正規表現としての構造を持つ文字列から生成されるとしている。ここでいう正規表現も、より抽象的な本来の意味での正規表現であり、検索ソフトのgrepが使う正規表現と呼ばれる構文と直接対応するものではない。
この文はもう1つのことも規定している。それは「開始タグおよび最初の子要素の間、子要素の間、または最後の子要素および終了タグの間に空白が許される」ということである。この条件を満たしている場合、<a><a/></a>
というXML文書に空白を挿入して、<a> <a/> </a>
と書いても構わない。これについては、もう1つ重要度が高くコメントしておくべきことがある。この文では、空白のみが許されるとしているが、実際には、空白だけでなく、コメント、PIも許される。これは生成規則Miscにマッチするものである。これは、XML
1.0 Second Edition Specification Errata(正誤表)に記述されていて、JIS版には反映されている。
次の文は、CDATAセクションはCDATAセクションであって、空白文字が記述されていても、空白文字扱いはされないといっている。この部分は、さらにErrataが出ており、JIS版には反映されている。追加された情報は、空白に展開される文字参照を置換テキストとして持つ実体への参照も同じように、非終端記号Sにマッチせずに、空白文字扱いされないということである。ただし「空白に展開される文字参照だけから構成されるリテラル値を持つ内部実体への参照は、文字参照の展開により置換テキストが空白になるので、非終端記号Sにマッチする」としている。
条件3の“Mixed”は混合内容だが、これは後で詳しく出てくる。Errataでは、文字データ、子要素のほかに、空白、PIが付け加えられている。これもJIS版では反映済みである。
条件4の“ANY”は、どのような要素を内容に記述してもよいとする万能のワイルドカード的な機能だが、妥当性の検証を放棄しているわけではない。ここに書かれているとおり、要素型が宣言されている要素に限って記述できる。逆にいえば、DTDの記述されていない要素が含まれるXML文書を妥当と見なすために、ANYの機能を使うことはできないといえる。
なお、Errataによって、2〜3には、すべて「実体参照を置換テキストで置き換えた後に(after replacing any entity references with their replacement text)」というテキストが追加されている。つまり、これらの妥当性の検証は、実体参照を置換テキストで置き換えた後に行われることになる。
さて、これで要素に関する説明は一段落である。次は、より具体的かつ深い内容に進んでいく。
次は「3.1 Start-Tags, End-Tags, and Empty-Element Tags」(3.1 開始タグ、終了タグおよび空要素タグ)である。特にHTMLの利用者を中心に、要素とタグの区別がついていない例が多く見られるが、ここまで読めば要素とタグの違いははっきり見えてくるだろう。タグとは要素を構成するための部品であって、部分と全体の関係である。ここまでは、全体となる要素について見てきたが、ここからは部分となるタグについての説明が始まる。
まずは、開始タグの定義からである。
[Definition: The beginning of every non-empty XML element is marked by a start-tag.] |
[定義:空でないすべてのXML要素の始まりは、開始タグによってマーク付けする。] |
ここでは、空要素は空要素タグを使うので別扱いだが、それ以外のすべての要素の始まりとして記述されるものが開始タグである、という定義である。
次は開始タグのEBNF定義である。
Start-tag
|
The Name in the start- and end-tags gives the element's type. [Definition: The Name-AttValue pairs are referred to as the attribute specifications of the element], [Definition: with the Name in each pair referred to as the attribute name] and [Definition: the content of the AttValue (the text between the ' or " delimiters) as the attribute value.]Note that the order of attribute specifications in a start-tag or empty-element tag is not significant. |
開始タグおよび終了タグ内のNameは、要素の型を表す。[定義:NameおよびAttValueの対を要素の属性指定といい]、[定義:個々の対におけるNameを属性名といい]、[定義:AttValueの内容(区切り子'または"の間のテキスト)を属性値という。]開始タグまたは空要素タグにおける属性指定の順序には意味がないことに注意すること。 |
このEBNF定義も難しいところはないだろう。STag ::= '<' Name (S Attribute)*
S? '>'
は、まず<記号があり、次にNameすなわち名前があり、その後に、属性と空白文字が並び、最後に>記号で終わる。属性は、属性を示す生成規則Attributeの手前に空白文字がある組み合わせを0回以上繰り返し、その後で省略可能な空白を記述する。このルールにより、すべての属性の手前には必ず空白文字が入り、最後の属性の後には空白文字を書いても書かなくてもよいことになる。タグの名前と属性の間には必ず空白が入ることも確認できるだろう。
Attribute ::= Name Eq AttValue
の方はもっと簡単である。属性は、名前(Name)、イコール記号(Eq)、属性値(AttValue)の3つが必ず並んだものである。ちなみに、Eqはイコール記号の前後に空白文字を入れることが許されているので、a="b"
だけでなく、a
= "b"
のような書き方も許される。
次に説明の文が続いている。「要素の型を表す」とは、つまり要素型のことである。すでに、要素型は名前によって表されることは読んだ。それが具体的に、開始タグおよび終了タグ内のNameによって表現されることが示されているわけである。
次は用語の定義となる。1つの文でattribute specifications(属性指定)、attribute name(属性名)、attribute
value(属性値)と3つの用語を定義しているが、それほど難しくないだろう。a="b"
のa
が属性名に当たり、b
が属性値に当たり、これ全体が属性指定ということになる。
さらに、もう1つの文が続く。これは定義ではない注意書きのようなものである。要素には順序性はあるが、属性にはない。要素を記述する順番を変えると致命的なトラブルを引き起こす場合もあるが、属性を記述する順番が変わっても一切結果に影響を与えることはない(ようにしなければならない)わけである。
次は個々の整形式制約と妥当性制約の内容が書かれている。
Well-formedness constraint: Unique Att Spec No attribute name may appear more than once in the same start-tag or empty-element tag. |
整形式制約:属性指定の一意性 |
これは、整形式制約Unique Att Spec(属性指定の一意性)の内容である。ある要素の内容に同じ名前の要素が複数出現することは許されているが、1つのタグ内に同じ名前の属性が2つ以上存在することは許されない。EBNFではこの意図を表現できていない。
Validity constraint: Attribute Value Type The attribute must have been declared; the value must be of the type declared for it. (For attribute types, see 3.3 Attribute-List Declarations.) |
妥当性制約:属性値の型 |
これは、妥当性制約Attribute Value Type(属性値の型)の内容である。カッコ内は補足説明で、例えば、その属性の型がNMTOKENなら、NMTOKENで許された文字の並びを満たす文字列が属性値として書き込まれていなくてはならない。属性の型については、補足説明のとおり、後で詳しく出てくるので、ここでは深く立ち入らずに先に進もう。
Well-formedness constraint: No External Entity
References Attribute values cannot contain direct or indirect entity references to external entities. |
整形式制約:外部実体への参照がないこと |
これは、整形式制約No External Entity References(外部実体への参照がないこと)の内容でが、外部実体の参照を含むことはできないということであって、外部実体を示す属性値を記述することができない、という意味ではない。実体参照とは、“&”記号で始まって“;”記号で終わる書式で書くものであるが、それだけが実体を扱う機能というわけではないのである。例えば、属性の型がENTITY型なら、属性値は実体の名前となるが、この場合、“&”記号や“;”記号は記述しないので実体参照の書式にならない。
Well-formedness constraint:
No < in
Attribute Values The replacement text of any entity referred to directly or indirectly in an attribute value must not contain a <. |
整形式制約:属性値に<を含まないこと |
これは、整形式制約No < in Attribute Values(属性値に<を含まないこと)の内容である。ただし属性値に“<”という文字を含めてはならない、ということではない。直接的に“<”という文字を書いてはならないことを示しているのである。つまり、“<”と書くことは問題ない。なぜこのような制約が必要とされているかはEBNFをたどると見えてくる。属性値の生成規則は、
|
という部分に当たるが、ここでは明確に“<”と“&”が有効な文字から除外されていることが分かる。しかし、ここで生成規則Referenceにマッチした場合は、この除外規定の対象外となる(除外規定のある定義と、Referenceのどちらか一方であるから)。では、この先はどうなるのかというと、実体の名前を記述するような規定で終わってしまう。実体が置換された場合のテキストの内容がどのようなものであるかは、これらの規則では何の制約も課せられない。では、具体的な置換テキストはどういう定義になっているかというと、
|
となっており、“<”が除外されていない。そのため、ここでは整形式制約として、“<”を含まないことを記述しているわけである。
次は、開始タグの例である。
An example of a start-tag:
|
ここでは、開始タグの例が示されている。termdefという名前(要素型)を持つ要素の開始タグである。2つの属性(id、term)を持っている。
次は、終了タグについての話に進む。
[Definition: The end of every element that begins with a start-tag must be marked by an end-tag containing a name that echoes the element's type as given in the start-tag:] |
[定義:開始タグで始まる要素の終わりは、対応する開始タグの要素型と同じ名前を持つ終了タグでマーク付けしなければならない。] |
これはend-tag(終了タグ)という用語に関する定義である。言葉は難しいが、意図するところは分かりやすいだろう。開始タグを書いたら、必ず終了タグを書かねばならず、終了タグの名前は、開始タグの名前に一致していなければならない、ということである。
次は終了タグのEBNF定義と例である。
End-tag
An example of an end-tag:
|
内容は難しくないので、あまり詳しく説明することはないだろう。ここで注目しておく点は2つある。1つは、“'</'”という記述である。“<”記号と“/”記号は連続していて、途中に空白文字などを入れることはできないことが分かる。もう1つは“S?”である。名前と>記号の間には空白文字を入れてもよく、入れなくてもよいことが分かる。しかし、名前の手前には“S?”のような記述はなく、ここに空白文字を入れることはできない。
次は、content(内容)という用語の定義である。
[Definition: The text between the start-tag and end-tag is called the element's content:] |
[定義:要素の開始タグと終了タグの間のテキストをその要素の内容(content)という。] |
ここで注意すべきことは、「内容」イコール「要素の開始タグと終了タグの間のテキスト」ではないということである。「要素の開始タグと終了タグの間のテキスト」は「内容」の1つであり、ほかにもいくつか「内容」と見なされるものがある。それは次の生成規則を見れば分かる。
External Subset
|
これはContent of Elements(要素の内容)についての生成規則である。CharDataは連載第6回の「2.4 Character Data and Markup」(2.4 文字データ及びマーク付け)ですでに解説済みなので繰り返さない。ようするにXML文書における通常の文字データで、省略可能な形で記述することが許されている。そのほかの生成規則だが、elementは今回取り上げたとおり要素を示す。Referenceは実体参照と文字参照、CDSectはCDATAセクション、PIは処理命令、Commentはコメントである。つまり、文字データを前後と中間に挟みながら、要素や実体参照などを繰り返し書くことができ、これがcontent(内容)となるわけである。
次は、話題が変わって、空要素タグについての話に進む。まず、empty(空)と、empty-element tag(空要素タグ)の用語の定義である。
[Definition: An element with no content is said to be empty.] The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag. [Definition: An empty-element tag takes a special form:] |
[定義:内容を持たない要素は空である。]空要素は、終了タグを直後に伴う開始タグによって表現されるか、または空要素タグによって表現される。[定義:空要素タグは、特別な形式を取る:] |
冒頭はempty(空)の定義である。次の文は用語定義ではない。空要素は内容をもたないが、その表現方法は2種類あると書かれている。1つは「開始タグ+終了タグ」であり、もう1つは「空要素タグ」である。開始タグ+終了タグの場合は、開始タグの直後に終了タグを入れねばならない、という意図も表現されている。次の文は、empty-element tag(空要素タグ)の用語定義である。ここでいう特別な形式とは、次に書かれた生成規則になるようだが、そこは用語定義の[......]の枠外になっている。
Tags for Empty Elements
|
このEBNF定義も難しいものではないだろう。注意すべき点は、“'/>'”という部分である。空要素タグを記述する際、最後の“/”記号と“>”記号の間には空白文字をはじめ、どんな文字も挿入できないことが分かる。また、この定義に付記されている整形式制約Unique Att Spec(属性指定の一意性)は、開始タグと同じものであり、ここにそれに関する記述はない。
次は、空要素タグに関するいくつかの規定である。
Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY. For interoperability, the empty-element tag should be used, and should only be used, for elements which are declared EMPTY. |
空要素タグは、内容を持たない任意の要素の表現に利用できる。空要素タグで表現する要素を、キーワードEMPTYを用いて宣言しなくてもよい。相互運用性のためには、空要素タグは、EMPTYとして宣言された要素に使用すべきであり、またこれ以外の要素に使用すべきではない。 |
ここでは、内容がなくても、ある場所に存在しているだけで意味を持つ情報もある、としている。例えばXHTMLにおけるbr要素などが、それに当たる。また、内容はなくても属性は持てることに注意が必要である。例えばXHTMLのimg要素は空要素だが、属性により扱うべきイメージを指定することで強力な機能を発揮する。
次の文は、要素型宣言で宣言する際に、EMPTYというキーワードを使うことができるが、それを使わなくてもよい、ということを示している。EMPTYというキーワードについては、要素型宣言について規定する個所で詳しく説明する。これは、要素型宣言でキーワードEMPTYを使っていなくても、たまたま内容が空の要素を出力する際に、空要素タグを使ってよいことを示している。実際、内容が空だと自動的に空要素タグを出力するようなクラスライブラリも存在する。
しかし、その次の文に、それが好ましくないという話も書かれている。相互運用性とはSGMLとの互換性のためという意味を持つとすでに説明したが、そのような運用を意識する場合は、EMPTYとして宣言されていない要素型の要素を記述するために空要素タグを記述すべきではない。
次は空要素の例である。
Examples of empty elements:
|
これは、特にコメントは不要だろう。XHTMLを意識した例だと思われるが、IMGはXHTMLを意識するならimgとするところである。XHTMLはXMLが生まれてからだいぶ時間がたって勧告されているので、XML仕様書の例が完全にXHTMLに従っていないのは、ある意味で当然である。
もう1つ、“<br></br>”と“<br/>”は等価であることにも注意を払おう。ただし、実際にHTML4.0対応のWebブラウザに読み込ませると、<br></br>は2つのbr要素として認識されてしまう可能性もあり得る。XMLの規定はXML外にまでは通用しないのである。
さて、今回はこれで終わりである。次回は、「3.2 Element Type Declarations」(3.2 要素型宣言)に入る。これは、DTDで要素型を宣言するための構文である。DTDはもう古くなっていまさら正確な定義を追いかける価値もない、と思うかもしれないが、DTDの概念の多くはXML SchemaやRELAX NGにも互換性を維持して継承されているものである。XMLという言語の原点を知るという意味でも、ぜひここも読破してみたい。
連載 やさしく読む「XML 1.0勧告」 |
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|