• R/O
  • HTTP
  • SSH
  • HTTPS

コミット

タグ
未設定

よく使われているワード(クリックで追加)

javac++androidlinuxc#windowsobjective-ccocoa誰得qtpythonphprubygameguibathyscaphec計画中(planning stage)翻訳omegatframeworktwitterdomtestvb.netdirectxゲームエンジンbtronarduinopreviewer

コミットメタ情報

リビジョンbaed5d311c9e9d7d3296e1fea36c04e0647a4642 (tree)
日時2011-04-01 16:31:15
作者akngw <akngw@user...>
コミッターakngw

ログメッセージ

いろいろ修正。

変更サマリ

差分

--- a/xmlgawk.texi
+++ b/xmlgawk.texi
@@ -39,7 +39,7 @@ software. Copies published by the Free Software Foundation raise
3939 funds for GNU development.''
4040 @end enumerate
4141
42-Copyright (C) 2008 KINUGAWA Akihito (japanese translation)
42+Copyright (C) 2008, 2011 KINUGAWA Akihito (japanese translation)
4343 @end copying
4444
4545 @ifinfo
@@ -65,22 +65,22 @@ This file documents the XML processing extension in GNU @command{awk}.
6565
6666 @dircategory Databases
6767 @direntry
68-* xgawk-pgsql: (xmlgawk)PostgreSQL API リファレンス. The xgawk PostgreSQL interface.
68+* xgawk-pgsql: (xmlgawk)PostgreSQL API Reference. The xgawk PostgreSQL interface.
6969 @end direntry
7070
7171 @dircategory Programming
7272 @direntry
73-* xgawk-time: (xmlgawk)Time Extension リファレンス. The xgawk time extension.
73+* xgawk-time: (xmlgawk)Time Extension Reference. The xgawk time extension.
7474 @end direntry
7575
7676 @dircategory Programming
7777 @direntry
78-* xgawk-gd: (xmlgawk)GD グラフィックス拡張リファレンス. The xgawk graphics extension.
78+* xgawk-gd: (xmlgawk)GD Graphics Extension Reference. The xgawk graphics extension.
7979 @end direntry
8080
8181 @dircategory Programming
8282 @direntry
83-* xgawk-mpfr: (xmlgawk)MPFR 拡張リファレンス. The xgawk MPFR extension.
83+* xgawk-mpfr: (xmlgawk)MPFR Extension Reference. The xgawk MPFR extension.
8484 @end direntry
8585
8686 @iftex
@@ -182,71 +182,80 @@ version 3.2 and later.
182182 @end ifnottex
183183
184184 @menu
185-* 序::
186-* AWK と XML の概念::
187-* POSIX AWK での XML データの読み込み::
188-* gawk の XML コア言語拡張::
189-* xmllib ライブラリの利点::
190-* xmltree ライブラリを使った DOM ライクアクセス::
191-* ニューズグループ comp.text.xml と comp.lang.awk からの問題::
192-* いくつかの高度なアプリケーション::
193-* XML 機能のリファレンス::
194-* 参考書籍とリンク::
195-* Extensible Gawk 言語拡張::
196-* PostgreSQL API リファレンス::
197-* Time Extension リファレンス::
198-* GD グラフィックス拡張リファレンス::
199-* MPFR 拡張リファレンス::
200-* xgawk のインストール::
201-* このマニュアルの著作権情報::
185+* Preface::
186+* AWK and XML Concepts::
187+* Reading XML Data with POSIX AWK::
188+* XML Core Language Extensions of gawk::
189+* Some Convenience with the xmllib library::
190+* DOM-like access with the xmltree library::
191+* Problems from the newsgroups comp.text.xml and comp.lang.awk::
192+* Some Advanced Applications::
193+* Reference of XML features::
194+* Reference of Books and Links::
195+* Extensible Gawk Language Extensions::
196+* PostgreSQL API Reference::
197+* Time Extension Reference::
198+* GD Graphics Extension Reference::
199+* MPFR Extension Reference::
200+* Installing xgawk::
201+* Copying This Manual::
202202 * Index::
203203 @end menu
204204
205-@c * XMark - XML ベンチマークプロジェクト::
205+@c * XMark — An XML Benchmark Project::
206+
206207
207208 @node Preface
208209 @unnumbered 序
209210
210-2003 年 6 月、私は XML フォーマットで書かれたある設定ファイルのテキストに直面して、私の好きなツール (@command{grep} と @command{awk}) が、こういったファイルから情報を抽出するのにまるで役立たずだったことに恐れをなしてしまいました。
211-AWK の行単位で処理をするやり方は、木のような構造をした XML データのノードをトラバースするやり方へと置き換えなければならないように見えました。
212-拡張した @command{gawk} の最初の実装では、XML ファイルの読み込みで私を助けるために、@command{expat} ライブラリを選択しました。
213-@pindex Expat、SAX ライクな API を持つ XML パーサ
214-
215-私は、Stefan Tramm に少し助けてもらいながら機能の選別を続け、2003 年のクリスマス休暇の間中、今 XMLgawk と呼ばれるものを実装していました。
216-2004 年 6 月、Manuel Collado が私達に合流し、この拡張に対する自分の意見や提案をまとめ始めました。
217-Manuel は XML ファイルを DOM ライクな構造へ読み込むためのライブラリをも書きました。
218-@cindex DOM、ドキュメントオブジェクトモデル
219-
220-2004 年 9 月、私は、この @value{DOCUMENT} の初版を書きました。
221-Andrew Schorr は、変更に対するパッチや提案で私のメールボックスを溢れさせました。
222-また、彼の後押しで SourceForge プロジェクトを始めました。
223-これは 2005 年 3 月のことで、以来ソフトウェアの変更は、SourceForge の CVS ソースツリーへ入力しています (このサービスを提供してくれていることに感謝します)。
224-Andrew の、ある生産システムへの急な必要から、2005 年初頭に開発が進みました。
211+2003年6月、私は、XMLフォーマットで書かれたある設定ファイルのテキストに直面して、こういったファイルから情報を抽出するのに、私の好きなツール(@command{grep}と@command{awk})がまるで役立たずだったことに恐れをなしてしまいました。
212+AWKの行単位で処理をするやり方は、木のような構造をしたXMLデータのノードをトラバースするやり方へと置き換えなければならないように思えました。
213+拡張した@command{gawk}の最初の実装では、XMLファイルの読み込みを行うのに、@command{expat}ライブラリを利用することを選択しました。
214+@pindex Expat, XML parser with SAX-like API
215+
216+私は、Stefan Trammに少し助けてもらいながら機能の選別を続け、2003年のクリスマス休暇の間中、XMLgawkと今呼ばれているものを実装していました。
217+2004年6月、Manuel Colladoが私達に合流し、この拡張に対する自分の意見や提案をまとめ始めました。
218+Manuelは、XMLファイルをDOMライクな構造へ読み込むためのライブラリも書きました。
219+@cindex DOM, Document Object Model
220+
221+2004年9月、私は、この@value{DOCUMENT}の初版を書きました。
222+Andrew Schorrは、修正パッチや修正提案で私のメールボックスを溢れさせました。
223+また、彼の後押しで、SourceForgeプロジェクトを始めました。
224+これは2005年3月のことです。
225+以来、ソフトウェアの変更は、SourceForgeのCVSソースツリーへ入力しています(このサービスを提供してくれていることに感謝します)。
226+ある生産システムでAndrewが急に必要としたことから、2005年初頭に開発が進みました。
225227 以下の重要な変更が行われました。
228+
226229 @enumerate
227230 @item
228231 構文解析の速度を倍にして、大きなデータベースの読み込みの際の効率を良くしました。
232+
229233 @item
230-@code{XMLEVENT} や @code{XMLNAME} のようなユーザに見えるパターンにおけるいくつかの単純化を Manuel が提案し、Andrew が実装しました。
234+@code{XMLEVENT}や@code{XMLNAME}のようなユーザに見えるパターンにおけるいくつかの単純化をManuelが提案し、Andrewが実装しました。
235+
231236 @item
232-Andrew が XMLgawk を、実行時にダイナミックライブラリとして読み込める @command{gawk} 拡張としてカプセル化しました。
233-これは XML 拡張無しで @command{gawk} を構築することも考慮したものでした。
234-そしてこれが @code{-l} オプションと @code{@@load} が導入されたきっかけです。
237+Andrewが、実行時にダイナミックライブラリとして読み込める@command{gawk}拡張としてXMLgawkをカプセル化しました。
238+これは、XML拡張無しで@command{gawk}を構築することも考慮したものでした。
239+そして、これが、@code{-l}オプションと@code{@@load}を導入したきっかけです。
240+
235241 @item
236-Andrew が autotool メカニズム (@code{Makefile.am} etc.) を仕上げ、Arnold の GNU Awk と同じディレクトリに衝突することなく簡単にインストールするためのインストールのメカニズムを見つけました。
237-また彼は、@code{-i} オプションを実装して、Arnold の @code{igawk} を obsolete にしました。
238-2005 年 4 月、@code{gawk-3.1.4} からのブランチとして @code{xgawk} のアルファリリースを見ました。
242+Andrewは、autotoolメカニズム(@code{Makefile.am}など)を仕上げました。
243+また、ArnoldのGNU Awkと同じディレクトリに衝突することなく簡単にインストールするためのインストールメカニズムを見つけました。
244+また、彼は、@code{-i}オプションを実装して、Arnoldの@code{igawk}をobsoleteにしました。
245+2005年4月、@code{gawk-3.1.4}からのブランチとして、@code{xgawk}のアルファリリースを見ました。
239246 @end enumerate
240247
241-2005 年 8 月、Hirofumi Saito が日本での @uref{http://ll.jus.or.jp/2005/files/lldn_awk_2005.pdf, @emph{Lightweight Language Day and Night}} でプレゼンテーションを行ないました。
242-彼は短いスライドショーの中で、モダンなプログラミング言語におけるマルチバイト文字の重要性についてデモンストレーションをしました。
243-また、Hirofumi Saito は私たちのソースコードの日本語に対するローカル化も行ないました。
244-Kimura Koichi はマルチバイト文字の取り扱いに関する問題のいくつかを報告し、修正しました。
245-また彼は、各種の Microsoft Windows 上でこれを全て動作させるやり方を見いだしました。
248+2005年8月、Hirofumi Saitoは、日本での@uref{http://ll.jus.or.jp/2005/files/lldn_awk_2005.pdf, @emph{Lightweight Language Day and Night}}でプレゼンテーションを行いました。
249+彼は、短いスライドショーの中で、モダンなプログラミング言語におけるマルチバイト文字の重要性についてデモンストレーションをしました。
250+また、Hirofumi Saitoは、ソースコードの日本語に対するローカル化も行いました。
251+Kimura Koichiは、マルチバイト文字の取り扱いに関する問題のいくつかを報告し、修正しました。
252+また、彼は、各種のMicrosoft Windows上でこれを全て動作させるやり方を見出しました。
246253 @cindex Microsoft Windows
247254
248-2005 年の夏頃 Arnold が @code{gawk-3.1.5} をリリースし、2005 年のクリスマス休暇一杯を使って私はその彼の 219 個のパッチを私たちの CVS ツリーへ適用しました。
249-さらに、Andrew が GNU メーリングリストのアーカイブから持ってきたいくつかのバグの修正を行ないましたので、@code{xgawk-3.1.5} の現在のベータリリースは Arnold の @code{gawk-3.1.5} よりも既にちょっとだけ先へ行っています。
255+2005年の夏頃、Arnoldは@code{gawk-3.1.5}をリリースしました。
256+私は、2005年のクリスマス休暇一杯を使って、その彼の219個のパッチをCVSツリーへ適用しました。
257+さらに、Andrewは、GNUメーリングリストのアーカイブから持ってきたいくつかのバグの修正を行いました。
258+このため、@code{xgawk-3.1.5}の現在のベータリリースは、Arnoldの@code{gawk-3.1.5}よりもちょっとだけ先へ既に行っています。
250259 @sp 1
251260 @noindent
252261 J@"urgen Kahrs @*
@@ -254,37 +263,37 @@ Bremen, Germany @*
254263 April, 2006
255264
256265 @page
257-2006 年 8 月、Arnold と彼をサポートしている人たちは、Arnold のソースツリーのミラーとして、@uref{http://savannah.gnu.org/projects/gawk, Savannah} に CVS リポジトリを用意しました。
258-これで今 Arnold のソースツリーの最新の変更を知ることは、私たちにとってかなり容易になっています。
259-私たちは、その変更を私たちのソースツリーへすぐに全てマージするよう努めています。
260-このマージプロセスは、1週間ごとの @code{cron} ジョブメカニズムでぶっちゃけ簡素化されています (Andrew が実装しました)。
261-Arnold のツリーでの変更状況を調査して私たちのメーリングリストへ email を送信するものです。
266+2006年8月、Arnoldと彼をサポートしている人たちは、Arnoldのソースツリーのミラーとして、@uref{http://savannah.gnu.org/projects/gawk, Savannah}にCVSリポジトリを用意しました。
267+これにより、Arnoldのソースツリーの最新の変更を知ることは、今、かなり容易になっています。
268+その変更は、ソースツリーへすぐに全てマージするよう努めています。
269+このマージプロセスは、1週間ごとの@code{cron}ジョブメカニズムでぶっちゃけ簡素化されています(Andrewが実装しました)。
270+Arnoldのツリーでの変更状況を調査して、メーリングリストへemailを送信するものです。
262271
263-日本の支援者たちが Arnold と私たちにマルチバイト文字の取り扱いに関するさらなる問題と修正を報告してくれました。
264-例えば、Hirofumi Saito とそのほかの人たちが、ShiftJIS ロケールにおける文字クラスの中の幅が半分のカタカナに対するパッチを送ってきました。
272+日本の支援者たちは、Arnoldと私たちにマルチバイト文字の取り扱いに関するさらなる問題と修正を報告してくれました。
273+例えば、Hirofumi Saitoとその他の人たちは、ShiftJISロケールにおける文字クラスの中の幅が半分のカタカナに対するパッチを送ってきました。
265274
266-2007 年 1 月から @code{Makefile} のトップレベルのターゲットに新しく @code{valgrind} が入っています。
267-この機能は、リグレッションのテストケースを実行中のインタプリタのメモリリークを検出するために実装されています。
268-この新しい機能で、私たちは @code{time} と @code{mpfr} 拡張の小さなメモリリークを即座に見つけました。
275+2007年1月から、@code{Makefile}のトップレベルのターゲットに@code{valgrind}が新しく入っています。
276+この機能は、回帰テストケースを実行中のインタプリタのメモリリークを検出するために実装されています。
277+この新しい機能で、@code{time}と@code{mpfr}拡張の小さなメモリリークを即座に見つけました。
269278
270-2007 年 3 月、多くの作業が行われました。
271-まず私たちは、GD ライブラリに対する Victor Paesa の新しい拡張を取り入れました。
272-それから、Arnold のソースツリーから Paul Eggert による @file{floatcomp.c} ファイル (浮動小数点/long の比較) をマージしました。
273-また、数値計算の振る舞い (無限と非数値) とそれらのフォーマティングの変更による、リグレッションテストケースとドキュメンテーションのマージも行いました。
279+2007年3月、多くの作業が行われました。
280+まず、GDライブラリに対するVictor Paesaの新しい拡張を取り入れました。
281+それから、Arnoldのソースツリーから、Paul Eggertによる@file{floatcomp.c}ファイル(浮動小数点/longの比較)をマージしました。
282+また、数値計算の振る舞い(無限と非数値)とそれらのフォーマティングの変更による、回帰テストケースとドキュメントのマージも行いました。
274283
275-Stefan Tramm が @uref{http://conferences.oreillynet.com/os2006, OSCON 06} で、5 分間の @uref{http://homepage.mac.com/stefan.tramm/iWiki/XmlGawkOsconLT.html, @emph{Lightning Talk on xgawk}} 行いました。
284+Stefan Trammは、@uref{http://conferences.oreillynet.com/os2006, OSCON 06}で、5分間の@uref{http://homepage.mac.com/stefan.tramm/iWiki/XmlGawkOsconLT.html, @emph{Lightning Talk on xgawk}}を行いました。
276285
277-Hirofumi Saito が @uref{http://ll.jus.or.jp/2006, @emph{Lightweight Language Conference 2006}} に参加しました。
278-Matt Rosin が @uref{http://telebody.net/wordpress/2006/09/05/lightweights-getting-physical, English} でのイベントの内容を要約しました。
286+Hirofumi Saitoは、@uref{http://ll.jus.or.jp/2006, @emph{Lightweight Language Conference 2006}}に参加しました。
287+Matt Rosinは、@uref{http://telebody.net/wordpress/2006/09/05/lightweights-getting-physical, English}でのイベントの内容を要約しました。
279288
280-新しく @ref{POSIX AWK での XML データの読み込み} に、テンプレートスクリプトの @code{getXMLEVENT.awk} について記述しています。
281-このスクリプトで XMLgawk API とほとんど互換のサブセットであるやり方でポータブルなスクリプトを書くことができます。
282-こういった方法で書かれたスクリプトは、@code{xgawk} ばかりでなく、POSIX 準拠のどんな AWK インタプリタでも実行させることができます。
289+別の節(@pxref{Reading XML Data with POSIX AWK})に、テンプレートスクリプトの@code{getXMLEVENT.awk}について記述しています。
290+このスクリプトを使うと、XMLgawk APIとほぼ互換のサブセットの方法で、ポータブルなスクリプトを書くことができます。
291+こういった方法で書かれたスクリプトは、@code{xgawk}ばかりでなく、POSIX準拠のどんなAWKインタプリタでも実行させることができます。
283292
284-新しく @ref{@file{xmlcopy.awk} ライブラリスクリプトを使ったコピーと修正} に、XML データを少し修正したコピーを作成するためのライブラリスクリプトについて記述しています。
293+別の節(@pxref{Copying and Modifying with the @file{xmlcopy.awk} library script})に、XMLデータを少し修正したコピーを作成するためのライブラリスクリプトについて記述しています。
285294
286-Arnold が彼の @code{gawk-stable} ツリーに適用したパッチをきちんと知らせてくれる Andrew の作った仕組みのおかげで、Andrew と 私は Arnold のソースツリーの最新の変更に追随しました。
287-その結果、現在@code{xgawk} は最新の @code{gawk-3.1.6} 公式リリースをベースにしています。
295+Arnoldが@code{gawk-stable}ツリーに適用したパッチをきちんと知らせてくれるAndrewの作った仕組みのおかげで、Andrewと私は、Arnoldのソースツリーの最新の変更に追随しました。
296+その結果、現在、@code{xgawk}は、最新の@code{gawk-3.1.6}公式リリースをベースにしています。
288297 @sp 1
289298 @noindent
290299 J@"urgen Kahrs @*
@@ -292,45 +301,48 @@ Bremen, Germany @*
292301 December, 2007
293302
294303 @page
295-@b{FIXME: このドキュメントは未完成です。
304+@b{FIXME:このドキュメントは未完成です。
296305 不完全な部分にはこのようなコメントでマークしています。}
297306
298-@b{FIXME: このドキュメントが対象とする範囲について決めなければなりません。
299-XMLgawk 拡張についてだけのドキュメントとするか、GNU Awk の全ての拡張についてのドキュメントにするか?
300-Andrew は PostgreSQL と time 拡張に関する記述を補遺部分に入れました。}
307+@b{FIXME:このドキュメントが対象とする範囲について決めなければなりません。
308+XMLgawk拡張についてだけのドキュメントとするか、GNU Awkの全ての拡張についてのドキュメントにするか。
309+Andrewは、PostgreSQLとtime拡張に関する記述を補遺部分に入れました。}
310+
301311
302312 @node AWK and XML Concepts
303-@chapter AWK と XML の概念
313+@chapter AWKとXMLの概念
304314
305315 @menu
306-* AWK の実行モデルに XML はどのようにフィットするか::
307-* gawk で木構造をトラバースする方法::
308-* XML ファイルを詳しく見る::
316+* How does XML fit into AWK's execution model ?::
317+* How to traverse the tree with gawk::
318+* Looking closer at the XML file::
309319 @end menu
310320
311-この @value{CHAPTER} では、XML の概念に関する (必然的に) 短い紹介を行います。
312-@command{gawk} で XML 処理をする多くのアプリケーションにはこれで十分だと思っていますが、さらに高度なタスクをこなすには、より深い背景を知る必要があるでしょうし、XSL プロセッサのような他のツールへ移ることも必要となるかもしれません。
321+この@value{CHAPTER}では、XMLの概念に関する(必然的に)短い紹介を行います。
322+@command{gawk}でXML処理をする多くのアプリケーションにはこれで十分だと思っていますが、さらに高度なタスクをこなすには、より深い背景を知る必要があるでしょうし、XSLプロセッサのような他のツールへ移ることも必要となるかもしれません。
313323 @cindex XSL
314324
325+
315326 @node How does XML fit into AWK's execution model ?, How to traverse the tree with gawk, AWK and XML Concepts, AWK and XML Concepts
316-@section AWK の実行モデルに XML はどのようにフィットするか
317-XML について見ていく前に、まず、AWK プログラムの実行がどのように働くか、そしてこのフレームワークの中での XML の処理に必要なものについて繰り返させてください。
318-@command{gawk} の man page には AWK の基本的な実行モデルについて次のようにまとめられています。
327+@section AWKの実行モデルにXMLはどのようにフィットするか
328+
329+XMLについて見ていく前に、まず、AWKプログラムの実行がどのように働くか、そして、このフレームワークの中でのXMLの処理に必要なものについて繰り返させてください。
330+@command{gawk}のman pageには、AWKの基本的な実行モデルについて次のようにまとめられています。
319331
320332 @quotation
321- AWK プログラムはパターン-アクションステートメントの並びとオプショナルな関数定義からなります。
333+ AWKプログラムは、パターン-アクションステートメントの並びとオプショナルな関数定義からなります。
322334 @* @emph{pattern @{ action statements @}}
323335 @* @emph{function name(parameter list) @{ statements @}}
324336 @*
325337 @dots{}
326- gawk は、入力されるそれぞれのレコードが AWK プログラム中のどのパターンにマッチするかを調べるためにテストします。
338+ gawkは、AWKプログラム中のどのパターンに各入力レコードがマッチするかを調べます。
327339 レコードにマッチした各パターンについて、そのパターンに関連付けられたアクションが実行されます。
328340 パターンはプログラムに現れる順番にテストされます。
329- 入力を全て使い切れば、最後に、もしあれば、END ブロックの中のコードを実行します (END ブロックが複数個ある場合もあります) 。
341+ 入力を全て使い切った後は、ENDブロックが存在すれば、ENDブロック中のコードを実行します(ENDブロックが複数ある場合もあります)。
330342 @end quotation
331343
332-短かくて簡単な例を見てもらうと、この抽象的な説明の効果が明らかになるでしょう。
333-次のスクリプトは、Unix ツールの @command{wc} を実装しています (うまく、ほとんど出来ていますが、完全なものではありません) 。
344+短い簡単な例を見てもらうと、この抽象的な説明の効果が明らかになるでしょう。
345+次のスクリプトは、Unixツールの@command{wc}を実装しています(ほとんど上手く出来ていますが、完全なものではありません)。
334346 @cindex Unix
335347 @cindex Cygwin
336348 @cindex Microsoft Windows
@@ -344,43 +356,43 @@ XML について見ていく前に、まず、AWK プログラムの実行がど
344356 END @{ print NR, words @}
345357 @end example
346358
347-処理するファイルを開く前にワードカウンターを 0 で初期化します。
348-次にファイルを開き、それぞれの行に対して、フィールドの数 (ワードの数と等しい数) をその時のワードカウンターに足していきます。
359+処理するファイルを開く前にワードカウンターを0で初期化します。
360+次に、ファイルを開き、各行ごとに、フィールドの数(ワードの数と等しい数)をその時のワードカウンターに足していきます。
349361 入力ファイルの全行を読み終われば、ワードカウンターの結果の値をファイルの行数とともに表示します。
350362
351-上記の行を @file{wc.awk} と名付けたファイルに格納して、それを次のように起動してください。
363+@file{wc.awk}と名付けたファイルに上記の内容を格納して、そのファイルを次のように起動してください。
352364 @example
353365 gawk -f wc.awk datafile.xml
354366 @end example
355-このような起動の仕方はすべてのプラットフォームで使えるでしょう。
356-Unix 環境 (あるいは Microsoft Windows 上の Cygwin Unix エミュレーション) では、上のスクリプトを実行ファイルにしてしまうのがもっと快適です。
357-そうするには、@file{wc.awk} という名前のファイルを書いて、そのファイルの最初の行が
367+このような起動方法は、全てのプラットフォームで使えるでしょう。
368+Unix環境(あるいは、Microsoft Windows上のCygwin Unixエミュレーション)では、上のスクリプトを実行ファイルにしてしまうとさらに快適になります。
369+@file{wc.awk}という名前のファイルを記述する際、最初の行が
358370 @example
359371 #!/usr/bin/gawk -f
360372 @end example
361373 となるようにし、前述のスクリプトの内容がそれに続くようにしてください。
362-次に、@file{wc.awk} ファイルを実行可能にするために次のようにしてください。
374+次に、以下のようにして、@file{wc.awk}ファイルを実行可能にしてください。
363375 @example
364376 chmod a+x wc.awk
365377 @end example
366-そして次のように起動してください。
378+そして、次のように起動してください。
367379 @example
368380 wc.awk datafile.xml
369381 @end example
370382
371-@ref{fig:awk_proc} を上から下へと見てもらうと、データファイルの各行がその図の横の列として表わされていることがわかると思います。
372-各横の列の左側に @command{NR} (現在行の番号) と、右側にパターン (実行の条件) とそのアクションがあるのが見えます。
373-最初と最後の列は、@command{BEGIN} (初期化) と @command{END} (終了処理) を表わしています。
383+fig:awk_proc(@pxref{fig:awk_proc})を上から下へと見てもらうと、データファイルの各行がその図の横の列として表わされていることが分かると思います。
384+各行の左側に@command{NR}(その時点の行番号)、右側にパターン(実行の条件)とそのアクションがあるのが分かります。
385+最初と最後の行は、@command{BEGIN}(初期化)と@command{END}(終了処理)を表わしています。
374386
375387 @float Figure,fig:awk_proc
376-@image{awk_proc,,,上から下へと進行する、ASCII データでの AWK プログラムの実行モデル,}
377-@caption{上から下へと進行する、ASCII データでの AWK プログラムの実行モデル}
388+@image{awk_proc,,,上から下へと進行する、ASCIIデータでのAWKプログラムの実行モデル,}
389+@caption{上から下へと進行する、ASCIIデータでのAWKプログラムの実行モデル}
378390 @end float
379391
380-このスクリプトを使えば、どのような XML ファイルも処理できるのでしょう。
392+このスクリプトを使えば、どのようなXMLファイルも処理できるでしょう。
381393 しかし、それによって得られる結果は私たちにとってあまり意味あるものではないでしょう。
382-XML ファイルを処理するのに、行数やワード数にはまったく興味はありません。
383-例えば次の XML ファイル、正確に言うと @uref{http://xml.web.cern.ch/XML/goossens/dbatcern/doc-structure.html#exa.dbgeneral, DocBook file} を見てください。
394+XMLファイルを処理する場合、行数やワード数にはまったく関心はありません。
395+例えば、次のXMLファイル、正確に言うと、@uref{http://xml.web.cern.ch/XML/goossens/dbatcern/doc-structure.html#exa.dbgeneral, DocBook file}を見てください。
384396 @cindex DocBook
385397
386398 @float Figure,fig:dbfile
@@ -416,37 +428,38 @@ XML ファイルを処理するのに、行数やワード数にはまったく
416428 </chapter>
417429 </book>
418430 @end example
419-@caption{ある XML データの例 (DocBook ファイル)}
431+@caption{あるXMLデータの例(DocBookファイル)}
420432 @end float
421433
422-この山括弧のジャングルを通して読めば、行という概念が、あなたが見ているものを説明するのに相応しい概念ではないということがわかるでしょう。
423-AWK の@emph{レコード} と @emph{フィールド} の考え方は、横の列と縦の列の中に収まったテキストデータの四角い世界でしか意味を成しません。
424-この概念では、@command{<title>}Introduction</title> のように前後を山括弧でそういうものとしてマークアップされたブロックで構造化されたテキストデータという XML の概念を理解することができません。
425-その上、XML のマークアップブロックは他のブロックを内に含むことがあります (@code{title} と @code{para} を含む @code{chapter} のようなものです)。
426-XML はテキストデータを、深くネストしたノード (マークアップブロック) でできた木構造としてとらえます。
427-木構造はダイナミックなデータ構造です。
428-木構造は他の木構造を含み、またその木構造がさらに他の木構造を含むこともあるので、木構造のことを@emph{リカーシブ} 構造と呼ぶ人もいます。
429-@cindex リカーシブ
430-このような下位の木構造というのは行や列のように番号が付けらているわけではありませんが、名前を持っています。
431-XML ファイルの構造について大まかに理解できたと思うので、その状況を描くのに十分な方法を選択することができます。
432-XML データは木構造を持っていますので、上の @ref{fig:dbfile} にあるファイル例を木構造 (@pxref{fig:docbook_chapter}) として描いてみましょう。
434+この山括弧のジャングルを通して読めば、行という概念が、あなたが見ているものを説明するのに相応しい概念ではないということが分かるでしょう。
435+AWKにおける@emph{レコード}と@emph{フィールド}の考え方は、行と列の中に収まったテキストデータの四角い世界でしか意味を成しません。
436+この概念では、@command{<title>}Introduction</title>のように、それ自体山括弧で前後をマークアップされたブロックで構造化されたテキストデータというXMLの概念を理解することができません。
437+その上、XMLのマークアップブロックは他のブロックを内に含むことがあります(@code{title}と@code{para}を含む@code{chapter}のなど)。
438+XMLでは、深くネストしたノード(マークアップブロック)でできた木構造としてテキストデータを捉えます。
439+木構造は、ダイナミックなデータ構造です。
440+木構造は、他の木構造を含み、また、その木構造が他の木構造をさらに含むこともあるので、木構造のことを@emph{リカーシブ}構造と呼ぶ人もいます。
441+@cindex recursion
442+このような下位の木構造というのは、行や列のように番号が付けられているわけではありませんが、名前を持っています。
443+XMLファイルの構造について大まかに理解できたと思うので、その状況を描くのに十分な方法を選択することができます。
444+XMLデータは木構造を持っていますので、上のfig:dbfile(@pxref{fig:dbfile})にあるファイル例を木構造(@pxref{fig:docbook_chapter})として描いてみましょう。
433445
434446 @float Figure,fig:docbook_chapter
435-@image{docbook_chapter,,,木構造として XML データ (DocBook ファイル),}
436-@caption{木構造として XML データ (DocBook ファイル)}
447+@image{docbook_chapter,,,木構造としてXMLデータ(DocBookファイル),}
448+@caption{木構造としてXMLデータ(DocBookファイル)}
437449 @end float
438450
439-それぞれのマークアップされたブロックがこの木構造の中でノードとして描かれているのがすぐにわかると思います。
440-木構造のエッジ (ノードとノードを結ぶ線) は、テキストで表現するよりももっとわかりやすく、マークアップされたブロックがネスティングしているということを明らかにしています。
451+マークアップされたブロックが、この木構造の中でノードとしてそれぞれ描かれているのがすぐに分かると思います。
452+木構造のエッジ(ノードとノードを結ぶ線)は、テキストで表現するよりももっと分かりやすく、マークアップされたブロックがネスティングしているということを明らかにしています。
441453 エッジはそれぞれ、矢印が向いている方向にあるマークアップされたブロックが矢印がやってきた元のマークアップブロックに含まれているということを示しています。
442-このようなエッジは @emph{"parent-child"} 関係を表わしています。
454+このようなエッジは@emph{"parent-child"}関係を表わしています。
455+
443456
444457 @node How to traverse the tree with gawk, Looking closer at the XML file, How does XML fit into AWK's execution model ?, AWK and XML Concepts
445-@section gawk で木構造をトラバースする方法
458+@section gawkで木構造をトラバースする方法
446459
447-さて、マークアップされたこういった木構造を扱う際、@command{wc} コマンドと同等なものとはどのようなものでしょうか。
460+さて、マークアップされたこういった木構造を扱う際、@command{wc}コマンドと同等なものとはどのようなものでしょうか。
448461 木構造のノードの数を数えることはできるでしょう。
449-前述のスクリプトで行ったのと同じように次のスクリプトをファイルに保存して起動してみてください。
462+前述のスクリプトで行ったのと同じように、次のスクリプトをファイルに保存して起動してみてください。
450463
451464 @pindex @file{node_count.awk}
452465 @cindex @code{XMLSTARTELEM}
@@ -456,47 +469,52 @@ XMLSTARTELEM @{ nodes ++ @}
456469 END @{ print nodes @}
457470 @end example
458471
459-このスクリプトを @ref{fig:dbfile} のデータファイルで起動すると、すぐにノードの数が表示されます。
472+fig:dbfile(@pxref{fig:dbfile})のデータファイルに対してこのスクリプトを起動すると、ノードの数がすぐ表示されます。
460473 @page
461474 @example
462475 gawk -l xml -f node_count.awk dbfile.xml
463476 12
464477 @end example
465478
466-この例のスクリプトと、ワードを数える元の @file{wc.awk} の似ている部分に注意してください。
479+この例におけるスクリプトと、ワードを数える元の@file{wc.awk}の似ている部分に注意してください。
467480 全行を舐めていく代わりに、このスクリプトはツリーをトラバースし、ノードが見つかるたびにノードカウンターをインクリメントします。
468-もう少しよく見ると、前のスクリプトとこのスクリプトの違いがいくつかわかってくるでしょう。
481+もう少しよく見ると、前のスクリプトとこのスクリプトの違いがいくつか分かってくるでしょう。
469482
470483 @enumerate
471484 @item
472-@command{gawk} のコマンドラインのところに、@code{-l xml} というパラメータが追加されています。
473-これは、@command{gawk} インタプリタに XML 拡張をロードするのに必要で、これにより、オープンするファイルが XML ファイルで、異なった扱いをしなければならないということを @command{gawk} インタプリタに知らせます。
485+@command{gawk}のコマンドラインのところに、@code{-l xml}というパラメータが追加されています。
486+これは、@command{gawk}インタプリタにXML拡張をロードするのに必要なものです。
487+これにより、オープンするファイルがXMLファイルであって、異なった扱いをしなければならないということを@command{gawk}インタプリタに知らせます。
488+
474489 @item
475490 パターンが関連付けられているアクションの中でノードカウンタがカウントされます。
476491 @emph{全ての}行でカウントしていた前のスクリプトと異なり、ノードを数えることにだけ関心があります。
477-ノードの出現 (マークアップされたブロックの始まり) は @code{XMLSTARTELEM} パターンで示されています。
492+ノードの出現(マークアップされたブロックの始まり)は@code{XMLSTARTELEM}パターンで示されています。
493+
478494 @item
479-ここではワードをカウントするのと同等のものはありません。
480-ノードをカウントすることだけです。
495+この場合、ワードをカウントするのと同等のものはありません。
496+ノードのカウントだけです。
497+
481498 @item
482499 トラバースされるツリーのノードの出現順というのは明確ではありません。
483-@code{bookinfo} ノードと @code{chapter} ノードはどちらも @code{book} の直下に位置していますが、どちらが先に数えられるでしょう?
484-木構造のテキスト表現に立ち戻ればその答えはわかります。
500+@code{bookinfo}ノードと@code{chapter}ノードは、どちらも、@code{book}の直下に位置しています。
501+どちらが先に数えられるでしょう。
502+木構造のテキスト表現に立ち戻れば、その答えは分かります。
485503 テキストでの順序がツリーをトラバースする順序に影響するのです。
486504 @end enumerate
487505
488-矢印の先の近くに数字が見えるでしょうか?
489-これらは、トラバースの順序を示しています。
490-番号の 1 番がありませんが、ルートノード (太枠) を最初に辿ることは明らかだからです。
491-コンピュータサイエンスの専門家は、この順番で辿ることを @uref{http://en.wikipedia.org/wiki/Depth-first, @dfn{depth-first}} と呼びます。
492-各ノードについて、同じレベルにあるノードへ行く前に、先にその子ノード (深いノード) を辿るからです。
493-他のトラバースの順序に (@uref{http://en.wikipedia.org/wiki/Breadth-first_search, @dfn{breadth-first}}) というのもありますが、@ref{fig:dbfile} のテキストの順序というのが @ref{fig:docbook_chapter} での数字が付けられた順序を強制します。
506+矢印の先の近くに数字が見えるでしょうか。
507+これは、トラバースの順序を示しています。
508+番号の1番がありませんが、ルートノード(太枠)を最初に辿ることは明らかだからです。
509+コンピュータサイエンスの専門家は、この順番で辿ることを@uref{http://en.wikipedia.org/wiki/Depth-first, @dfn{depth-first}}と呼びます。
510+各ノードについて、同じレベルにあるノードへ行く前に、その子ノード(深いノード)を先に辿るからです。
511+トラバースの順序には、他に、(@uref{http://en.wikipedia.org/wiki/Breadth-first_search, @dfn{breadth-first}})というのもありますが、fig:dbfile(@pxref{fig:dbfile})のテキストの順序というのがfig:docbook_chapter(@pxref{fig:docbook_chapter})での数字が付けられた順序を強制します。
494512
495-@ref{fig:docbook_chapter} のツリーは平衡ではありません。
496-一番最後のノードの部分が深くネストされていて、@ref{fig:docbook_chapter} のかなり右のマージンの部分に表示されています。
513+fig:docbook_chapter(@pxref{fig:docbook_chapter})のツリーは平衡ではありません。
514+一番最後のノードの部分が深くネストされていて、fig:docbook_chapter(@pxref{fig:docbook_chapter})のかなり右のマージン部分に表示されています。
497515 図の上の方の部分はそうではありません。
498-このようなツリーの最大の深さを知ると便利なことが時々あります。
499-次のスクリプトは全てのノードを辿り、そのノードの深さとそこまでの最大の深さを比較し、最も深い深さを見つけて記録するものです。
516+このようなツリーの最大の深さが分かると便利なことがあります。
517+次のスクリプトは、全てのノードを辿り、そのノードの深さとそこまでの最大の深さを比較し、最も深い所を見つけて記録するものです。
500518
501519 @pindex @file{max_depth.awk}
502520 @cindex @code{XMLENDELEM}
@@ -511,113 +529,132 @@ XMLSTARTELEM @{
511529 XMLENDELEM @{ depth-- @}
512530 END @{ print max_depth @}
513531 @end example
514-@caption{@file{max_depth.awk} スクリプトを使った XML ファイルのツリー表記の最大深さの探索}
532+@caption{@file{max_depth.awk}スクリプトを使ったXMLファイルのツリー表記の最大深さの探索}
515533 @end float
516534
517535 このスクリプトを前のものと比較すると、いくつかの微妙な違いにまた気が付くと思います。
518536
519537 @enumerate
520538 @item
521-@command{@@load xml} というのは、コマンドライン上の @code{-l xml} の代わりです。
522-スクリプトのテキストが実行ファイルに格納されているのであれば、全ての拡張をインタプリタにロードした状態でスクリプトを実行すべきです。
523-コマンドラインオプションの @code{-l xml} は、ワンラインのコマンドラインの作業をしているときにだけ略記法として使われるべきでしょう。
539+@command{@@load xml}というのは、コマンドライン上の@code{-l xml}の代わりです。
540+スクリプトのテキストが実行ファイルに格納されているのであれば、インタプリタに拡張を全てロードした状態でスクリプトを実行すべきです。
541+コマンドラインオプションの@code{-l xml}は、ワンラインのコマンドラインの作業をしている時にだけ略記法として使われるべきでしょう。
542+
524543 @item
525-変数の @command{depth} は初期化されていません。
526-@command{gawk} の変数は、前もって初期化しなくても、最初に使用されるときには 0 という値を持っていますので必要ないのです。
544+変数の@command{depth}は初期化されていません。
545+@command{gawk}の変数は、前もって初期化しなくても、最初に使用される時には0という値を持っていますので初期化は必要ありません。
546+
527547 @item
528-最も重要な違いは、@code{XMLENDELEM} という新しく出てきたパターンです。
529-これは @code{XMLSTARTELEM} と対になるパターンです。
530-片方はノードに入ったときに true となり、他方はノードから離れるときに true となります。
531-テキスト表現では、こららのパターンはマークアップされたブロックの最初と最後の部分を示しています。
532-スクリプトがマークアップされたブロックに差し掛かるたび @code{depth} カウンタが増やされ、マークアップされたブロックを離れるたび @code{depth} カウンタが減らされます。
548+最も重要な違いは、@code{XMLENDELEM}という新しく出てきたパターンです。
549+これは、@code{XMLSTARTELEM}と対になるパターンです。
550+一つは、ノードに入った時にtrueとなるもので、もう一つは、ノードから離れる時にtrueとなります。
551+テキスト表現において、これらのパターンは、マークアップされたブロックの最初と最後の部分を示しています。
552+マークアップされたブロックにスクリプトが差し掛かるたび、@code{depth}カウンタが増やされ、マークアップされたブロックを離れるたび@code{depth}カウンタが減らされます。
533553 @end enumerate
534554
535-@command{XMLDEPTH} という、その時点でのマークアップされたブロックのネストしている深さを保持している組み込み変数を使えば、このスクリプトはもっと短く書けるということを後で学びます。
536-この変数を使えば、@ref{fig:max_depth.awk} スクリプトは @command{gawk} での典型的な日常作業に使われるワンライナーの一つとなります。
555+@command{XMLDEPTH}という、マークアップされたブロックのその時点でのネストしている深さを保持している組み込み変数を使えば、このスクリプトはもっと短く書けるということを後で学びます。
556+この変数を使えば、fig:max_depth.awk(@pxref{fig:max_depth.awk})スクリプトは@command{gawk}での典型的な日常作業に使われるワンライナーの一つとなります。
557+
537558
538559 @node Looking closer at the XML file
539-@section XML ファイルを詳しく見る
560+@section XMLファイルを詳しく見る
540561
541-XML の基本的な用語について既にご存知であれば、この @value{SECTION} をスキップして、次の @value{CHAPTER} へと進んでも構いません。
542-そうでなければ、O'Reilly の本 @uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell} の学習をお勧めします。
543-この本はチュートリアルとリファレンスがうまく組み合わされています。
544-基本的な用語については第 2 章 (XML Fundamentals) に書かれています。
545-(フリーの) オンラインチュートリアルが良ければ、 @uref{http://www.w3schools.com/xml/default.asp, w3schools} を推薦します。
546-その他の価値ある資料は、@xref{インターネットへのリンク}。
562+XMLの基本的な用語について既にご存知であれば、この@value{SECTION}をスキップして、次の@value{CHAPTER}へと進んでも構いません。
563+そうでなければ、O'Reillyの本@uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell}の学習をお勧めします。
564+この本は、チュートリアルとリファレンスがうまく組み合わされています。
565+基本的な用語については第2章(XML Fundamentals)に書かれています。
566+(フリーの)オンラインチュートリアルが良ければ、@uref{http://www.w3schools.com/xml/default.asp, w3schools}を推薦します。
567+その他の価値ある資料は別の節を参照してください(@pxref{Links to the Internet})。
547568
548569 先を読み進める前に、次にあげる用語の意味が理解できるか確認したほうがよいでしょう。
549-あなたをこれらの用語の自習をさせたままにしないで、各用語の、厳密ではない、しかも不十分な説明をしていきたいと思います。
550-例としては @ref{fig:dbfile} を常に参照してください。
570+これらの用語の自習をさせたままにはしません。
571+厳密ではないですし、しかも、不十分ではありますが、各用語を説明していきたいと思います。
572+例としては、fig:dbfile(@pxref{fig:dbfile})を常に参照してください。
551573 そして、上のソースの中でその用語を探すことを考えてください。
552574
553575 @itemize
554576 @item タグ: ノードの名前
555-@cindex タグ
556-@item アトリビュート: 名前 (@code{lang}) と 値 (@code{en}) を持つ変数
557-@cindex アトリビュート
558-@item エレメント: サブツリー、たとえば、@code{title} を含んだ @code{bookinfo}
559-@cindex エレメント
560-@item 整形式: 正しくネストしたファイル; 引用符が付けられ、タグとして明快にアトリビュートが付けられた一つのツリー
561-@cindex 整形式
562-@item DTD: ファイルが含むエレメントとアトリビュートについて形式に従って記述したもの
577+@cindex Tag
578+
579+@item アトリビュート: 名前(@code{lang})と値(@code{en})を持つ変数
580+@cindex Attribute
581+
582+@item エレメント: サブツリー、例えば、@code{title}を含んだ@code{bookinfo}
583+@cindex Element
584+
585+@item 整形式: 正しくネストしたファイル;引用符が付けられ、タグとして明快にアトリビュートが付けられた一つのツリー
586+@cindex Well-Formed
587+
588+@item DTD: ファイルが含むエレメントとアトリビュートについての正式仕様
563589 @cindex DTD, Document Type Definition
564-@item スキーマ: DTD と同様に使うが、DTD よりも詳細で、DTD と違い、形式としてはそれ自身も XML である
565-@cindex スキーマ
566-@item 妥当: 通常 DTD やスキーマとして与えられる形式仕様に従っていること
567-@cindex 妥当
568-@item プロセッシングインストラクション: ねじ留めされた特別な目的のためのエレメント、"?" という名前を持つ、しばしば最初のデータ行である
569-@cindex プロセッシングインストラクション
590+
591+@item スキーマ: DTDと同様に使用するが、DTDよりも詳細で、DTDと違い、形式としてはそれ自身もXMLである
592+@cindex Schema
593+
594+@item 妥当: DTDやスキーマとして通常指定される形式仕様に従っていること
595+@cindex Valid
596+
597+@item プロセッシングインストラクション: ねじ留めされた特別な目的のためのエレメント、"?"という名前を持つ、しばしば最初のデータ行である
598+@cindex Processing Instruction
599+
570600 @example
571601 <?xml version="1.0" encoding="ISO-8859-1"?>
572602 @end example
603+
573604 @item キャラクタデータ: タグの間にあるエレメント内部のテキストデータ
574-@cindex キャラクタデータ
605+@cindex Character Data
606+
575607 @item Mixed Content: 内部にキャラクタデータを持つエレメント
576608 @cindex Mixed Content
577-@item エンコーディング: テキストのシンボルとバイト列の間のマッピングの名前 (ISO-8859-1)
578-@cindex 文字エンコーディング
579-@item UTF-8: XML のデフォルトのエンコーディング、利用可能な全てのテキストシンボルをカバーする、マルチバイトの場合も
609+
610+@item エンコーディング: テキストのシンボルとバイト列の間のマッピングの名前(ISO-8859-1)
611+@cindex character encoding
612+
613+@item UTF-8: XMLのデフォルトのエンコーディング、利用可能な全てのテキストシンボルをカバーする、マルチバイトの場合も
580614 @cindex @code{UTF-8}
581615 @end itemize
582616
583-まだ読んでますか?
584-これらの定義は厳密には正しくないことに注意。
585-それらはあなたがいい線を行くことができるように意図しています。
586-やる気のあるプロペラヘッドならばそれぞれ、これらの定義を喜んでけちょんけちょんにしてくれるでしょう。
587-もしあなたが XML のプロペラヘッドになるために真剣に努力しているのであれば、@uref{http://www.w3.org/TR/2004/REC-xml-20040204/, XML technology} に関するオリジナルの定義ドキュメントを読み忘れるべきではありません。
617+まだ読んでますか。
618+これらの定義は厳密には正しくないことに注意してください。
619+上手くあなたが軌道に乗れるように考えたものです。
620+やる気のあるプロペラヘッドならば、それぞれ、これらの定義を喜んでけちょんけちょんにしてくれるでしょう。
621+もし、XMLのプロペラヘッドになるためにあなたが真剣に努力しているのであれば、@uref{http://www.w3.org/TR/2004/REC-xml-20040204/, XML technology}に関するオリジナルの定義ドキュメントを読み忘れるべきではありません。
588622 @cindex XML technology
589-不安を持つ有志に相応わしいプレイグラウンドは、ニューズグループの @uref{news://comp.text.xml, comp.text.xml} です。
590-@cindex comp.text.xml, インターネット上のニューズグループ
591-そのようなプロペラヘッドたちが誰も @code{gawk} の @value{DOCUMENT} を読んでないならば私はうれしいです --- 彼らは私を殺すでしょう。
623+不安を持つ有志に相応わしいプレイグラウンドは、ニューズグループの@uref{news://comp.text.xml, comp.text.xml}です。
624+@cindex comp.text.xml, newsgroup on the Internet
625+そのようなプロペラヘッドたちが誰も@code{gawk}の@value{DOCUMENT}を読んでないならば私はうれしいです --- 彼らは私を殺すでしょう。
626+
592627
593628 @node Reading XML Data with POSIX AWK
594-@chapter POSIX AWK での XML データの読み込み
629+@chapter POSIX AWKでのXMLデータの読み込み
595630
596631 @menu
597-* Steve Coile の xmlparse.awk スクリプト::
598-* Jan Weber の getXML スクリプト::
599-* XMLgawk のポータブルサブセット::
632+* Steve Coile's xmlparse.awk script::
633+* Jan Weber's getXML script::
634+* A portable subset of XMLgawk::
600635 @end menu
601636
602-初めに述べた新しい言語機能を使うこと避けようとするユーザもいるでしょう。
603-そういった人たちはポータブルなスクリプトが書きたいのです。
604-彼らは標準化されている @uref{http://www.opengroup.org/onlinepubs/000095399/utilities/awk.html, POSIX AWK} に含まれない機能を使うのを我慢しなければなりません。
637+ここまでに述べた新しい言語機能を使うことを避けようとするユーザもいるでしょう。
638+そういった人たちは、可搬性のあるスクリプトが書きたいのです。
639+彼らは、標準化されている@uref{http://www.opengroup.org/onlinepubs/000095399/utilities/awk.html, POSIX AWK}に含まれない機能を使うのを我慢しなければなりません。
605640 @cindex POSIX
606-GNU Awk の XML 拡張は POSIX 標準に含まれていませんので、こういったユーザは XML データを読むのに別の方法を探さなければなりません。
641+GNU AwkのXML拡張はPOSIX標準に含まれていませんので、こういったユーザは、XMLデータを読むのに別の方法を探さなければなりません。
642+
607643
608644 @node Steve Coile's xmlparse.awk script
609-@section Steve Coile の xmlparse.awk スクリプト
610-POSIX AWK で完全な XML リーダを実装するということは、Unicode エンコーディングの微妙な細かい部分を取り扱わなければならないということを意味しています。
645+@section Steve Coileのxmlparse.awkスクリプト
646+
647+POSIX AWKで完全なXMLリーダを実装するということは、Unicodeエンコーディングの微妙な細かい部分を処理しなければならないということを意味しています。
611648 @cindex Unicode
612649 @pindex @file{xmlparse.awk}
613-AWK スクリプトでそのような細部に入って行くことは理にかなっていません。
614-しかし、2001 年、Steve Coile は、ASCII 文字で、シンプルなタグ付けされたブロックからなるXML データであれば十分処理できるパーサを書きました。
615-彼のスクリプトは @uref{ftp://ftp.freefriends.org/arnold/Awkstuff/xmlparser.awk, @code{xmlparse.awk}} としてインターネット上で利用できます。
616-@code{xmlparse.awk} のソースコードはドキュメントが十分で、インターネットにアクセスできる人ならすぐに使えます。
617-
618-@code{xmlparse.awk} をダウンロードして、その探検を開始しましょう。
619-このパーサで作業を始める前に、2007 年夏の時点で、ファイルに修正しなければならないタイポがあります。
620-342 行目のコメントの前にハッシュマーク文字 (@code{#}) を入れてください。
650+AWKスクリプトでそのような細部に入って行くことは理にかなっていません。
651+しかし、2001年、Steve Coileは、シンプルにタグ付けされたブロックからなるASCII文字のXMLデータであれば十分処理できるパーサを書きました。
652+彼のスクリプトは、@uref{ftp://ftp.freefriends.org/arnold/Awkstuff/xmlparser.awk, @code{xmlparse.awk}}としてインターネット上から取得可能です。
653+@code{xmlparse.awk}のソースコードでは説明が十分なされており、インターネットにアクセスできる人ならすぐに使えます。
654+
655+@code{xmlparse.awk}をダウンロードして、探検を開始しましょう。
656+このパーサで作業を始める前に、2007年夏の時点では、修正しなければならないタイポがファイルにあります。
657+342行目のコメントの前にハッシュマーク文字(@code{#})を入れてください。
621658 @example
622659 wget ftp://ftp.freefriends.org/arnold/Awkstuff/xmlparser.awk
623660 vi xmlparser.awk
@@ -627,22 +664,23 @@ AWK スクリプトでそのような細部に入って行くことは理にか
627664 :wq
628665 @end example
629666
630-パーサスクリプトを編集しながら、そのコメントを少し見てください。
631-これはドキュメントがよく書かれているスクリプトで、いくつかの使用事例に加えてその実装についても説明がされています。
632-例えば、そのヘッダにはユーザが知っておく必要があるであろう詳細についてほとんど全てまとめられています (@pxref{fig:ch2_xmlparser_header})。
633-そのヘッダにはささいな矛盾もあります。
634-ファイルが、ヘッダに書いてある @code{xmlparse.awk} では無く、実際には @code{xmlparser.awk} と名付けられていますね。
635-ユーザの視点から心に留めておくべき最も重要な制限は、この XML パーサが AWK の@emph{モダンな}バリアントを必要とすることです。
636-これは POSIX 準拠の AWK を意味します。
637-古い Solaris 実装の @code{oawk} は、この XML パーサスクリプトを意図した通りに実行することができないでしょう。
638-XML パーサを次のように初起動してください。
667+このパーサスクリプトを編集しながら、書かれているコメントを少し見てください。
668+これは、ドキュメントがよく書かれているスクリプトです。
669+使用事例に加えて、その実装についても説明がされています。
670+例えば、ヘッダには、ユーザが知っておく必要があるであろう詳細についてほとんど全てまとめられています(@pxref{fig:ch2_xmlparser_header})。
671+ヘッダには、取るに足らないことですが、間違ったことも書いてあります。
672+ファイルが、ヘッダに書いてある@code{xmlparse.awk}では無く、実際には、@code{xmlparser.awk}と名付けられていますね。
673+ユーザ視点から留意すべき最も重要な制限は、このXMLパーサがAWKの@emph{モダンな}バリアントを必要とすることです。
674+つまり、POSIX準拠のAWKを意味しています。
675+古いSolaris実装の@code{oawk}は、このXMLパーサスクリプトを意図した通りに実行することができないでしょう。
676+最初に、XMLパーサを次のように起動してください。
639677
640678 @example
641679 awk -f xmlparser.awk docbook_chapter.xml
642680 @end example
643681
644-出力されたものと、元のファイルの内容 (@pxref{fig:dbfile}) と木構造としての描写 (@pxref{fig:docbook_chapter}) を比較してください。
645-出力の最初のカラムには、順番にパースされた通りにアイテムの種類が常に出力されているのがわかるでしょう。
682+この出力を、元のファイルの内容(@pxref{fig:dbfile})、あるいは、木構造としての描写(@pxref{fig:docbook_chapter})と比較してください。
683+出力の最初のカラムには、順番にパースされた通りにアイテムの種類が常に出力されているのが分かるでしょう。
646684
647685 @example
648686 @b{pi} xml version="1.0" encoding="UTF-8"
@@ -663,35 +701,46 @@ awk -f xmlparser.awk docbook_chapter.xml
663701 @end example
664702
665703 これは、パーサスクリプトのヘッダで説明されている処理原則と一致します。
666-注意が必要ですが、@ref{fig:ch2_xmlparser_header} の説明は不完全です。
704+注意が必要ですが、fig:ch2_xmlparser_header(@pxref{fig:ch2_xmlparser_header})の説明は不完全です。
667705 詳細は以下に示します。
668706
669-このスクリプトは XML データをパースし、パースされたアイテムを二つの配列に格納します。
707+このスクリプトはXMLデータをパースし、パースされたアイテムを二つの配列に格納します。
708+
670709 @itemize
671-@item @code{type[3]} はパースされた 3 番目の XML データアイテムの種類を示しています。
672-これは次のうちのいずれかになります。
710+@item @code{type[3]}は、パースされた3番目のXMLデータアイテムの種類を示しています。
711+これは、次のうちのいずれかになります。
712+
673713 @itemize
674-@item @code{@b{"error"}}、不正なアイテムがパースされたかその他のエラーが発生したとき。 この場合、@code{item[3]} にはエラーメッセージのテキストが入っています。
675-@item @code{@b{"begin"}}、開始タグがパースされたとき。
676-@item @code{@b{"end"}}、終了タグがパースされたとき。
677-@code{type[3]} が @code{"begin"} か @code{"end"} の場合は @code{item[3]} にはタグの名前が入っています。
678-@item @code{@b{"attrib"}}、アトリビュートの名前がパースされたとき。
679-@item @code{@b{"value"}}、アトリビュートの値がパースされたとき。
680-@code{type[3]} が @code{"attrib"} か @code{"value"} の場合は @code{item[3]} にはアトリビュートの名前か値が入っています。
681-@item @code{@b{"data"}}、開始タグと終了タグの間のデータがパースされたとき。
682-@item @code{@b{"cdata"}}、 キャラクタデータがパースされたとき。
683-@item @code{@b{"comment"}}、 コメントがパースされたとき。
684-@item @code{@b{"pi"}}、プロセッシングインストラクションがパースされたとき。
714+@item @code{@b{"error"}}、不正なアイテムがパースされたか、その他のエラーが発生した時。この場合、@code{item[3]}にはエラーメッセージのテキストが入っています。
715+
716+@item @code{@b{"begin"}}、開始タグがパースされた時。
717+
718+@item @code{@b{"end"}}、終了タグがパースされた時。
719+@code{type[3]}が@code{"begin"}か@code{"end"}の場合は、@code{item[3]}にはタグの名前が入っています。
720+
721+@item @code{@b{"attrib"}}、アトリビュートの名前がパースされた時。
722+
723+@item @code{@b{"value"}}、アトリビュートの値がパースされた時。
724+@code{type[3]}が@code{"attrib"}か@code{"value"}の場合は、@code{item[3]}には、アトリビュートの名前か値が入っています。
725+
726+@item @code{@b{"data"}}、開始タグと終了タグの間のデータがパースされた時。
727+
728+@item @code{@b{"cdata"}}、 キャラクタデータがパースされた時。
729+
730+@item @code{@b{"comment"}}、 コメントがパースされた時。
731+
732+@item @code{@b{"pi"}}、プロセッシングインストラクションがパースされた時。
685733 @end itemize
686-@item @code{item[3]} は、上記のアイテムリストで区別されているように、@code{type[3]} に応じたデータが入っています。
734+
735+@item @code{item[3]}は、上記のアイテムリストで区別されているように、@code{type[3]}に応じたデータが入っています。
687736 @end itemize
688737
689-この @value{DOCUMENT} を読み進めていくうちに、この基本的な考え方が XMLgawk で行っていることと似ていることにあなたは気付くことでしょう。
690-特に、@ref{XMLgawk コア言語インターフェイスの要約} に @emph{Style B - すべてのイベントで共有される、限定された変数の組} のように記述しているアプローチはよく関連しているように見えます。
691-このスクリプトはそのままでは、モジュラービルディングブロックとなるようにデザインされていません。
692-どのようなアプリケーションも @code{xmlparser.awk} ファイルを単にインクルードする@emph{のではなく}、それをテキストとしてコピーし、そのコピーを修正します。
693-元のスクリプトをもう一度のぞいてみて、最後の @code{END} パターンのところをさらに詳しく見てください。
694-@code{END} パターンの中に、便利なアプリケーションに関する提案がいくつかあるのがわかるでしょう。
738+この@value{DOCUMENT}を読み進めていくうちに、基本的な考え方が、XMLgawkで行っていることと似ていること分かるでしょう。
739+特に、別の節(@pxref{XMLgawk Core Language Interface Summary})で@emph{Style B - すべてのイベントで共有される、限定された変数の組}として説明しているアプローチは、よく関連しているように見えます。
740+このスクリプトは、そのままでは、モジュラービルディングブロックとなるようにはデザインされていません。
741+どのようなアプリケーションでも、@code{xmlparser.awk}ファイルを単にインクルードする@emph{のではなく}、テキストとしてコピーし、そのコピーを修正して使います。
742+元のスクリプトをもう一度覗いてみて、最後の@code{END}パターンのところをさらに詳しく見てください。
743+@code{END}パターンの中に、便利なアプリケーションに関する提案がいくつかあるのが分かるでしょう。
695744
696745 @float Figure,fig:ch2_xmlparser_header
697746 @example
@@ -709,50 +758,51 @@ awk -f xmlparser.awk docbook_chapter.xml
709758 #
710759 # Description:
711760 #
712-# このスクリプトは AWK (のモダンなバリアント) のためのシンプルな
713-# XML パーサです。
714-# XML 形式で入力すると、二つの配列 "type" と "item" に保存します。
761+# このスクリプトは、AWK(のモダンなバリアント)のためのシンプルな
762+# XMLパーサです。
763+# XML形式で入力すると、二つの配列"type"と"item"に保存します。
715764 #
716-# ここで使う "item" という用語は、タグやアトリビュート名、
717-# アトリビュート値、データといった紛れもない XML エレメントを指します。
765+# ここで使う"item"という用語は、タグやアトリビュート名、
766+# アトリビュート値、データといった紛れもないXMLエレメントを指します。
718767 #
719768 # これらの配列のインデックスは、それぞれのアイテムに遭遇した順番に
720769 # なっています。
721-# 例えば、3 番目のアイテムの種類は type[3] と記述し、その値は、item[3]
770+# 例えば、3番目のアイテムの種類はtype[3]と記述し、その値は、item[3]
722771 # と記述します。
723772 #
724-# "type" 配列はそれぞれの順番で遭遇したアイテムの種類が入っています。
725-# 種類は一つのワードで表記されます: "error" (不正なアイテムもしくは
726-# その他のエラー)、"begin" (開始タグ)、"attrib" (アトリビュート名)、
727-# "value" (アトリビュート値)、"end" (終了タグ)、"data" (タグ間の
728-# データ)。
773+# "type"配列は、それぞれの順番で遭遇したアイテムの種類が入っています。
774+# 種類は、一つのワードで表記されます: "error"(不正なアイテムもしくは
775+# その他のエラー)、"begin"(開始タグ)、"attrib"(アトリビュート名)、
776+# "value"(アトリビュート値)、"end"(終了タグ)、"data"(タグ間の
777+# データ)。
729778 #
730-# "item" 配列はそれぞれの順番で遭遇したアイテムの値が入っています。
731-# "begin" あるいは "end" という種類では、アイテムの値はタグの名前です。
732-# "error" の場合、その値はエラーメッセージのテキストです。
733-# "attrib" ならば、値はアトリビュート名です。
734-# "value" ならば、値はアトリビュート値です。
735-# "data" の場合は、生のデータが値です。
779+# "item"配列は、それぞれの順番で遭遇したアイテムの値が入っています。
780+# "begin"、あるいは、"end"という種類では、アイテムの値はタグの名前です。
781+# "error"の場合、その値は、エラーメッセージのテキストです。
782+# "attrib"ならば、値は、アトリビュート名です。
783+# "value"ならば、値は、アトリビュート値です。
784+# "data"の場合は、生のデータが値です。
736785 #
737-# 警告: data やアトリビュート値の XML での引用形式の値 ("エンティティ")
786+# 警告: dataやアトリビュート値のXMLでの引用形式の値("エンティティ")
738787 # は、引用形式を元に戻していません。そのまま格納しています。
739788 #
740789 ###############################################################################
741790 @end example
742-@caption{@code{xmlparser.awk} のヘッダで説明されている使い方}
791+@caption{@code{xmlparser.awk}のヘッダで説明されている使い方}
743792 @end float
744793
745794 @page
746795 @enumerate
747-@item 次のようにエラーの発生を検査すれば、XML データが整形式であるかどうかをチェックするスクリプトがかなり簡単に実装できます。
796+@item エラーの発生を次のように検査すれば、XMLデータが整形式であるかどうかをチェックするスクリプトがかなり簡単に実装できます。
748797 @example
749798 if (type[idx] == "error") @{
750799 ...
751800 @}
752801 @end example
802+
753803 @item
754-シェルスクリプトでもっと簡単にパースできる@emph{シンプル}な XML を導入する試みがいくつか行なわれてきました。
755-XML の単純化と使いやすい行単位のフォーマットでの出力をするには、@code{END} パターンに次のコードフラグメントを入れることで実装することができます。
804+シェルスクリプトでもっと簡単にパースできる@emph{シンプル}なXMLを導入する試みがいくつか行われてきました。
805+XMLを単純化し、使いやすい行単位のフォーマットで出力をするには、@code{END}パターンに、次のコードフラグメントを入れることで実装することができます。
756806 これは、パースしたアイテムを順番に全て通りぬけて、それぞれの種類を適切に処理する方法を示しています。
757807 @example
758808 for ( n = 1; n <= idx; n += 1 ) @{
@@ -769,11 +819,12 @@ for ( n = 1; n <= idx; n += 1 ) @{
769819 @}
770820 @}
771821 @end example
822+
772823 @item
773-今述べたフレームワークを使ったアプリケーションの一つが、@ref{fig:ch2_outline.awk} のアプリケーションのようなアウトラインスクリプトです。
774-@ref{fig:ch2_dbfile} にあるようなアウトライン出力を生成するのは、@code{xmlparser.awk} スクリプトを修正すれば AWK では数行で書ける問題です。
775-これは、XML データが完全に読み込まれた後で行なわれるということに注意してください。
776-ですので、処理できるデータの大きさに何らかの制限があるものの、処理の時点では、XML の完全なデータが AWK のメモリにとにかく保存されています。
824+今述べたフレームワークを使ったアプリケーションの一つが、fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})のアプリケーションのようなアウトラインスクリプトです。
825+fig:ch2_dbfile(@pxref{fig:ch2_dbfile})にあるようなアウトライン出力を生成するのは、@code{xmlparser.awk}スクリプトを修正すればAWKでは数行で書ける問題です。
826+これは、XMLデータが完全に読み込まれた後で行われるということに注意してください。
827+ですから、処理できるデータの大きさに何らかの制限があるものの、処理の時点では、XMLの完全なデータがAWKのメモリにとにかく保存されています。
777828 @example
778829 XMLDEPTH=0
779830 for (n = 1; n <= idx; n += 1 ) @{
@@ -784,104 +835,111 @@ for ( n = 1; n <= idx; n += 1 ) @{
784835 @} else if (type[n] == "end" ) @{ XMLDEPTH -- @}
785836 @}
786837 @end example
787-このアプリケーションの出力と @ref{fig:ch2_dbfile} を比べると、違いが二つだけあることがわかると思います。
788-一つめは一番最初のタグの前にある改行文字です。
789-二つめはタグの名前です。
790-@code{xmlparser.awk} スクリプトは各タグの名前を大文字で保存します。
791-正確なタグ名は XML をパースする仕組みの内部を変更しないと取り戻すことはできません。@footnote{訳注: 原文の revovered は revivered の typo ?}
838+このアプリケーションの出力とfig:ch2_dbfile(@pxref{fig:ch2_dbfile})を比べると、違いが二つだけあることが分かると思います。
839+一つは、一番最初のタグの前にある改行文字です。
840+もう一つは、タグの名前です。
841+@code{xmlparser.awk}スクリプトは、各タグの名前を大文字で保存します。
842+正確なタグ名はXMLをパースする仕組みの内部を変更しないと取り戻すことはできません@footnote{訳注:原文のrevoveredはreviveredのtypoでしょうか。}。
792843 @end enumerate
793844
794845
795-
796846 @node Jan Weber's getXML script
797-@section Jan Weber の getXML スクリプト
798-2005 年、Jan Weber が類似の XML パーサを @uref{news://comp.lang.awk, comp.lang.awk} ニューズグループに投稿しました。
847+@section Jan WeberのgetXMLスクリプト
848+
849+2005年、Jan Weberが、類似のXMLパーサを@uref{news://comp.lang.awk, comp.lang.awk}ニューズグループに投稿しました。
799850 @pindex @file{getXML}
800851 @ignore
801852 Jan Weber 2005-07-10 comp.lang.awk
802853 @end ignore
803-@code{getXML} スクリプトを Google で検索して、そのコピーをファイルにすることができます。
804-残念なことですが、Jan はスクリプトを可能な限り短かくしようとしていて、複数のステートメントを 1 行に書くこともしばしばです。
805-このスクリプトの読み易さは極端に損なわれているので、スクリプトを解読するのであれば、理解するのに必要かもしれない編集をするつもりでいてください。
806-再びですが、このパーサスクリプトを編集しながら、そこに書かれているコメントを少し見てください。
807-Jan は、スクリプトの中心となる関数にユーザの視点から以下 (@pxref{fig:ch2_getXML_header}) のようにコメントを書いています。
808-基本的なアプローチは @code{xmlparser.awk} スクリプトから引き継いだものでした。
809-しかし、Jan が自分の XML パーサを書く上で満足させようとしたいくつかの条件がありました。
854+そのスクリプトである@code{getXML}スクリプトは、Googleで検索すれば、そのコピーをファイルにすることができます。
855+残念なことですが、Janは、スクリプトを出来るだけ短かくしようと、複数ステートメントを1行に書くことがよくあります。
856+このスクリプトは読み易さが極端に損なわれています。
857+そのため、このスクリプトを解読するのであれば、スクリプトを理解するのに編集が必要となるかもしれませんので、そのつもりでいてください。
858+もう一度、このパーサスクリプトを編集しながら、そこに書かれているコメントを少し見てください。
859+Janは、スクリプトの中心となる関数にユーザの視点から以下(@pxref{fig:ch2_getXML_header})のようなコメントを書いています。
860+基本的なアプローチは@code{xmlparser.awk}スクリプトから引き継いだものでした。
861+しかし、Janには、自分のXMLパーサを書く上で、満足させたい条件がいくつかありました。
810862
811863 @enumerate
812864 @item
813-@code{getXML} 関数は、並行して複数の XML を読み込むことを可能にします。
865+@code{getXML}関数は、複数のXMLを並行して読み込むことを可能にします。
866+
814867 @item
815-その結果、XML のイベントごとに @code{getXML} 関数からのリターンが起きます。
816-これは、AWK の @code{getline} の仕組みと似ています (@pxref{fig:ch2_getXML})。
817-その上、ユーザアプリケーションは @code{BEGIN} アクションでファイルを読み込みます。
818-@code{END} アクションの中ではありません。
868+その結果、XMLのイベントごとに@code{getXML}関数からのリターンが起きます。
869+これは、AWKの@code{getline}の仕組みと似ています(@pxref{fig:ch2_getXML})。
870+その上、ユーザアプリケーションは@code{BEGIN}アクションでファイルを読み込みます。
871+@code{END}アクションの中ではありません。
872+
819873 @item
820-タグとアトリビュートの正確な名前を保存します。
821-この XML パーサは大文字小文字を変更しません。
874+タグとアトリビュートの正確な名前を保存する。
875+このXMLパーサは大文字小文字を変更しません。
876+
822877 @item
823-パラメータの渡し方は、@ref{XMLgawk コア言語インターフェイスの要約} の中で、@emph{Style B - すべてのイベントで共有される、限定された変数の組} のように記述されているアプローチとずっとよく似ています。
878+パラメータの渡し方は、別の節(@pxref{XMLgawk Core Language Interface Summary})の中で@emph{Style B - すべてのイベントで共有される、限定された変数の組}のとして説明されているアプローチとずっとよく似ています。
824879 最も重要なことですが、アトリビュートの名前と値は、属しているタグと一緒に渡されます。
825-ですので、イベントの粒度はもっと粗くて、ユーザフレンドリなものとなっています。
880+ですから、イベントの粒度はもっと粗くて、ユーザフレンドリなものとなっています。
881+
826882 @item
827-@code{xmlparser.awk} スクリプトがパースする過程の間に二つの配列に完全な XML データを格納するのに対し、@code{getXML.awk} スクリプトは、一回に一つの XML イベントを呼び出したアプリケーションへ渡して戻します。
828-これはメモリの無駄遣いを避けるためです。
829-すなわち、巨大な XML ファイルのパースが可能になります (あまり意味があるわけではありませんが)。
883+@code{xmlparser.awk}スクリプトは、パースする過程の間に、二つの配列に完全なXMLデータを格納します。
884+それに対し、@code{getXML.awk}スクリプトは、一回に一つのXMLイベントを、呼び出したアプリケーションへ渡して戻します。
885+これは、メモリの無駄遣いを避けるためです。
886+すなわち、巨大なXMLファイルのパースが可能になります(あまり意味があるわけではありませんが)。
887+
830888 @item
831-この XML パーサは Solaris Operating System 上の AWK 言語実装である @code{nawk} とともに動きます。
832-それゆえ、この XML パーサはおそらく、この @value{DOCUMENT} に記載されているパーサの中で最もポータブルなものでしょう。
889+このXMLパーサは、Solaris Operating System上のAWK言語実装である@code{nawk}で動作します。
890+それゆえ、このXMLパーサはおそらく、この@value{DOCUMENT}に記載されているパーサの中で最も可搬性のあるものでしょう。
833891 @cindex Solaris
834892 @cindex @code{nawk}
835893 @end enumerate
836894
837-もう一度、@ref{fig:ch2_outline.awk} のようなアウトラインスクリプトを実装して、この XML パーサの使い方を示しましょう。
838-@file{getXML} ファイルを変更して、@ref{fig:ch2_getXML} にあるスクリプトで既存の @code{BEGIN} アクションを置き換えてください。
839-次のように新しいアウトラインパーサを初起動してください。
895+もう一度、fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})のようなアウトラインスクリプトを実装して、このXMLパーサの使い方を示しましょう。
896+@file{getXML}ファイルを変更して、fig:ch2_getXML(@pxref{fig:ch2_getXML})にあるスクリプトで既存の@code{BEGIN}アクションを置き換えてください。
897+まず最初に、次のように、新しいアウトラインパーサを起動してください。
840898
841899 @example
842900 awk -f getXML docbook_chapter.xml
843901 @end example
844902
845-元のファイルの内容 (@pxref{fig:dbfile})、木構造としての図 (@pxref{fig:docbook_chapter})、そして @command{expat} パーサに付いてくる元の @code{outline} ツールの出力 (@pxref{fig:ch2_dbfile}) と、このスクリプトの出力を比較してください。
846-@pindex Expat, SAX ライクな API を持つ XML パーサ
847-結果は、ささいな部分を除けば、@ref{fig:ch2_dbfile} とほとんど同じです。
903+このスクリプトの出力を、元のファイルの内容(@pxref{fig:dbfile})、および、木構造としての図(@pxref{fig:docbook_chapter})、@command{expat}パーサに付いてくる元の@code{outline}ツールの出力(@pxref{fig:ch2_dbfile})と比較してください。
904+@pindex Expat, XML parser with SAX-like API
905+結果は、ささいな部分を除けば、fig:ch2_dbfile(@pxref{fig:ch2_dbfile})とほとんど同じです。
848906 ささいな部分とは、一番最初の行がここでは空行となっていることです。
849907
850908 @float Figure,fig:ch2_getXML_header
851909 @example
852910 ##
853-# getXML( file, skipData ): # 次の XML データを XTYPE,XITEM,XATTR に読み込む
911+# getXML( file, skipData ): # 次のXMLデータをXTYPE,XITEM,XATTRに読み込む
854912 # パラメータ:
855-# file -- XML ファイルへのパス
856-# skipData -- フラグ: "DAT" (タグ間のデータ) セクションを読まない
913+# file -- XMLファイルへのパス
914+# skipData -- フラグ: "DAT"(タグ間のデータ)セクションを読まない
857915 # 外部変数:
858-# XTYPE -- 読み込んだアイテムの種類、e.g. "TAG"(タグ), "END"(終了タグ),
859-# "COM"(コメント), "DAT"(データ)
860-# XITEM -- アイテムの値、e.g. 種類が "TAG" か "END" であればタグ名
861-# XATTR -- アトリビュートのマップ、XTYPE=="TAG" のときだけセットされる
916+# XTYPE -- 読み込んだアイテムの種類、e.g. "TAG"(タグ), "END"(終了タグ),
917+# "COM"(コメント), "DAT"(データ)
918+# XITEM -- アイテムの値、e.g. 種類が"TAG"か"END"であればタグ名
919+# XATTR -- アトリビュートのマップ、XTYPE=="TAG"の時だけセットされる
862920 # XPATH -- 現在のタグまでのパス, e.g. /TopLevelTag/SubTag1/SubTag2
863921 # XLINE -- 入力ファイルのその時点での行番号
864-# XNODE -- XTYPE, XITEM, XATTR が一つの文字列に連結されている
922+# XNODE -- XTYPE, XITEM, XATTRが一つの文字列に連結されている
865923 # XERROR -- エラーテキスト、パースエラーで設定される
866924 # 戻り値:
867-# 1 成功裏に読めた: よって XTYPE, XITEM, XATTR がセットされる
868-# "" ファイルの終わり、またはパースエラー: XERROR がエラーでセット
925+# 1 成功裏に読めた: よってXTYPE, XITEM, XATTRがセットされる
926+# "" ファイルの終わり、または、パースエラー: XERRORがエラーでセット
869927 # される
870928 # プライベートデータ:
871-# _XMLIO -- ファイルを開いたときのバッファ、XLINE、XPATH
929+# _XMLIO -- ファイルを開いた時のバッファ、XLINE、XPATH
872930 ##
873931 @end example
874-@caption{Jan Weber の getXML パーサ関数の使い方}
932+@caption{Jan WeberのgetXMLパーサ関数の使い方}
875933 @end float
876934
877935 実装の詳細のいくつかの点は注目する価値があります。
878-ほら、アイテムの粒度が異なっていますね:
879-アトリビュートは全部タグのアイテムとともに返されます。
880-この結果は、設計の決定から来るものです:
881-@code{getXML} 関数は、呼び出し元へ、より大量のデータを返すのにいくつかの変数を使います。
936+ほら、アイテムの粒度が異なっていますね。
937+つまり、アトリビュートが、タグのアイテムとともに全て返されます。
938+この結果は、設計意図から来るものです:
939+@code{getXML}関数は、呼び出し元へ、より大量のデータを返すのにいくつかの変数を使います。
882940 最終的に、まだやってないこまかい事はこの例の中で明らかとなります。
883-@code{getXML} 関数の 2 番目のパラメータに注意してください (@code{skipData})。
884-Jan はタグ間にあるテキストデータ (mixed content) をスキップできるオプションを導入しました。
941+@code{getXML}関数の2番目のパラメータに注意してください(@code{skipData})。
942+Janは、タグ間にあるテキストデータ(mixed content)をスキップできるオプションを導入しました。
885943
886944
887945 @float Figure,fig:ch2_getXML
@@ -902,85 +960,95 @@ BEGIN @{
902960 @}
903961 @}
904962 @end example
905-@caption{Jan Weber の @code{getXML} パーサスクリプトを使った XML ファイルのアウトラインの取得}
963+@caption{Jan Weberの@code{getXML}パーサスクリプトを使った、XMLファイルのアウトラインの取得}
906964 @end float
907965
908966
909967 @page
910968 @node A portable subset of XMLgawk
911-@section XMLgawk のポータブルサブセット
969+@section XMLgawkのポータブルサブセット
912970 @pindex @file{getXMLEVENT.awk}
913971
914-前の @value{SECTION} にある Jan Webers のポータブルスクリプトは、Steve Coile のスクリプトから大きく先へ進んだものでした。
915-XML のイベント処理は、XMLgawk API で行うものに近い感じがします。
916-しかし、このスクリプトで何度か作業した後、このスクリプトと XMLgawk API の間の違いを覚えておくことが少しわずらわしくなりました。
917-その結果私たちは、Jan のスクリプトを取り上げ、新しいスクリプトファイルの @file{getXMLEVENT.awk} としてコピーし、その内部の動作を、XMLgawk API と最小の違いとなるように変更しました。
918-このスクリプトをあなた自身の作業のテンプレートとして使うつもりでしたら、以下の場所から @file{getXMLEVENT.awk} を探してください:
972+前の@value{SECTION}にあるJan Webersのポータブルスクリプトは、Steve Coileのスクリプトから大きく先へ進んだものでした。
973+XMLのイベント処理は、XMLgawk APIで行うものに近い感じがします。
974+しかし、このスクリプトで何度か作業した後、このスクリプトとXMLgawk APIの間の違いを覚えておくことが少し煩わしくなりました。
975+その結果、私たちは、Janのスクリプトを取り上げ、新しいスクリプトファイルの@file{getXMLEVENT.awk}としてコピーし、その内部の動作を、XMLgawk APIと最小の違いとなるように変更しました。
976+あなた自身の作業のテンプレートとしてこのスクリプトを使うつもりでしたら、以下の場所から@file{getXMLEVENT.awk}を探してください:
919977
920978 @itemize
921-@item @code{xgawk} ディストリビューションファイルの @file{awklib/xml} ディレクトリの中にコピーがあります。
922-@item ホストマシンに既に @code{xgawk} がインストールされていれば、共有ソースのディレクトリ (普通は GNU/Linux マシンの @code{/usr/share/awk} のような場所) にコピーがあるはずです。
979+@item @code{xgawk}の配布ファイルの@file{awklib/xml}ディレクトリの中にコピーがあります。
980+
981+@item ホストマシンに既に@code{xgawk}がインストールされていれば、共有ソースのディレクトリ(普通はGNU/Linuxマシンの@code{/usr/share/awk}のような場所)にコピーがあるはずです。
923982 @end itemize
924983
925-ゼロからスクリプトを書き始めたい場合は、@file{getXMLEVENT.awk} ファイルはそのままうまく利用できます。
926-スクリプトの @code{BEGIN} パターンには、既に@emph{イベントループ}が入っています。
927-その@emph{イベントループ} (@code{while} ループ) の本体のところだけを取って、XML のイベントストリームから入ってくるイベントに対する処理の部分を変更してください。
984+スクリプトをゼロから書き始めたい場合は、@file{getXMLEVENT.awk}ファイルはそのままうまく利用できます。
985+スクリプトの@code{BEGIN}パターンには、@emph{イベントループ}が既に入っています。
986+その@emph{イベントループ}(@code{while}ループ)の本体のところだけを取って来て、XMLのイベントストリームから入ってくるイベントに対する処理の部分を変更してください。
928987
929-しかし、この @value{SECTION} の残りの部分は、既にスクリプトが@emph{あって}、それを移植するということを仮定します。
930-最も役立つ方法でのアプローチの説明をするために、@file{getXMLEVENT.awk} テンプレートファイルの典型的な使用例を二つ通して見ていきます。
931-まず私たちは、XMLgawk 用に書かれた既存のスクリプトを取って、Solaris マシンで使うためにそのスクリプトをポータブルにするために必要なステップについて見ます (単にワーストケースシナリオと呼びます)。
932-次に、ぐるっと反対の方向へ行きます:
933-既存のポータブルなスクリプトを取って、XMLgawk 用のスクリプトへ変換するのに必要なステップを説明します。
988+しかし、この@value{SECTION}の残りの部分は、スクリプトが既に@emph{あって}、それを移植するということを仮定します。
989+最も役立つ方法でのアプローチの説明をするために、@file{getXMLEVENT.awk}テンプレートファイルの典型的な使用例を二つ通して見ていきます。
990+まず、XMLgawk用に書かれた既存のスクリプトを引用し、Solarisマシンで使えるよう、そのスクリプトをポータブルにするために必要なステップについて見ます(単に、ワーストケースシナリオと呼びます)。
991+次に、ぐるっと反対の方向へ行きます。
992+既存のポータブルなスクリプトを取って、XMLgawk用のスクリプトへ変換するのに必要なステップを説明します。
934993
935-@subsection XMLgawk 用のスクリプトのポータブルなサブセットへの変換
994+@subsection XMLgawk用のスクリプトのポータブルなサブセットへの変換
936995
937-XMLgawk の機能を使っているスクリプトをポータブルなスクリプトへと移植する一般的なアプローチは、いつも同じです。
938-オリジナルのアウトラインスクリプト (@pxref{fig:ch2_outline.awk}) を移植するか、あるいは DTD ジェネレータ (@pxref{サンプルファイルからの DTD の生成}) のような非凡なアプリケーションを取り上げるのかは、問題ではありません。
939-さあ、私たちは以下の一連のステップをずっと進んでいきますよ。
996+XMLgawkの機能を使っているスクリプトを、ポータブルなスクリプトへと移植する一般的なアプローチは、常に同じです。
997+オリジナルのアウトラインスクリプト(@pxref{fig:ch2_outline.awk})を移植するか、あるいは、DTDジェネレータ(@pxref{Generating a DTD from a sample file})のような非凡なアプリケーションを取り上げるのかは、問題ではありません。
998+さあ、以下の一連のステップをずっと進んでいきますよ。
940999
9411000 @enumerate
9421001 @item
943-私たちは、テンプレートファイルの @file{getXMLEVENT.awk} を新しいファイル (DTD ジェネレータの場合ならば @file{dtdgport.awk}) に先ずコピーすることから常にスタートします。
1002+テンプレートファイルの@file{getXMLEVENT.awk}を、新しいファイル(DTDジェネレータの場合ならば@file{dtdgport.awk})に先ずコピーすることから常にスタートします。
1003+
9441004 @item
945-新しいスクリプトファイルの先頭近くで、元のイベントループの本体を削除します。
1005+新しいスクリプトファイルの先頭近くにある元のイベントループの本体を削除します。
1006+
9461007 @item
947-元のイベントループをアプリケーションからのパターンアクションのペアに置き換えます。
948-DTD ジェネレータの場合であれば、ソースコード (@ref{fig:dtd_generator.awk}) の最初の部分を見て、イベントループの中に @code{XMLSTARTELEM} アクションを挿入します。
1008+元のイベントループを、アプリケーションからのパターンアクションのペアに置き換えます。
1009+DTDジェネレータの場合であれば、ソースコード(@pxref{fig:dtd_generator.awk})の最初の部分を見て、イベントループの中に@code{XMLSTARTELEM}アクションを挿入します。
1010+
9491011 @item
950-イベントループの後ろに、@ref{fig:dtd_generator.awk} の @code{END} パターンをそのまま追加します。
1012+イベントループの後ろに、fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})の@code{END}パターンをそのまま追加します。
1013+
9511014 @item
952-アプリケーションの 2 番目の部分 (@ref{fig:print_elem} の関数定義を含んでいる) をそのまま追加します。
1015+アプリケーションの2番目の部分(fig:print_elem(@pxref{fig:print_elem})の関数定義を含んでいる)をそのまま追加します。
1016+
9531017 @item
954-出来上がったアプリケーションのソースコードに対して、それが本当に期待通りに動作するか試します。
955-スクリプトの出力結果を @ref{fig:dbfile.dtd} と比較してください。
956-結果の出力 (DTD になっている) が全く正確に同じであることがわかるでしょう。
1018+出来上がったアプリケーションのソースコードに対して、期待通りにそれが本当に動作するか試します。
1019+スクリプトの出力結果をfig:dbfile.dtd(@pxref{fig:dbfile.dtd})と比較してください。
1020+結果の出力(DTDになっている)が、全く正確に同じであることが分かるでしょう。
1021+
9571022 @example
9581023 awk -f dtdgport.awk docbook_chapter.xml
9591024 @end example
9601025 @end enumerate
9611026
962-XMLgawk スクリプトをポータブルなスクリプトへ変換するということの簡単さとその効果は驚くべきものです。
963-結局のところやはり、ポータブルなスクリプトの制約について決して忘れるべきではありません。
964-このちっちゃな XML パーサは、完全な XML パーサとは程遠いものです。
965-最も重大なのは、マルチバイト文字や他の Unicode エンコーディングの細目を使ったファイルの読み込み能力が欠けていることです。
966-遅かれ早かれ、特殊な文字 (コピーライトマーク、タイポグラフィックダッシュ、ヨーロピアンアクセント文字、あるいは漢字とか) を含む顧客の XML ファイルに出くわしてしまうだろうことは私たちは経験的に知っています。
967-ですので、XML を完全にパースする機能が使える完全な XMLgawk 環境へスクリプトを移植しなおす必要が生じます。
968-あなたが結局このポイントまで来るときは、次のサブセクションを続けて読んでください。
969-そうすればスクリプトを XMLgawk に書き直すときのアドバイスが得られるでしょう。
970-
971-@subsection ポータブルなサブセットのスクリプトから XMLgawk への変換
972-ポータブルなサブセットから完全な XMLgawk へスクリプトを変換するのはさらに簡単です。
973-この簡単さは、@ref{XMLgawk コア言語インターフェイスの要約} の中で述べられているように、@emph{Style B - すべてのイベントで共有される、限定された変数の組} の API と、ポータブルなサブセットのイベントループが似ていることから来るものです。
974-移植の要点は、@code{getXMLEVENT} の起動を @code{getline} に置き換えることです。
975-以下の作業リストを順に進めば、XML データを細かい部分までサポートするアプリケーションへとすぐに到達できるでしょう。
1027+XMLgawkスクリプトをポータブルなスクリプトへ変換するということの簡単さとその効果は驚くべきものです。
1028+結局のところ、やはり、ポータブルなスクリプトの制約について決して忘れるべきではありません。
1029+このちっちゃなXMLパーサは、完全なXMLパーサには程遠いものです。
1030+最も重大なのは、マルチバイト文字や他のUnicodeエンコーディングの細目を使ったファイルの読み込み能力が欠けていることです。
1031+遅かれ早かれ、特殊な文字(コピーライトマーク、タイポグラフィックダッシュ、ヨーロピアンアクセント文字、漢字など)を含む顧客のXMLファイルに出くわしてしまうだろうことは私たちは経験的に知っています。
1032+ですから、XMLを完全にパースする機能が使える完全なXMLgawk環境へスクリプトを移植しなおす必要が生じます。
1033+この状況に結局なる時は、次のサブセクションを続けて読んでください。
1034+そうすればスクリプトをXMLgawkに書き直す時のアドバイスが得られるでしょう。
1035+
1036+@subsection ポータブルなサブセットのスクリプトからXMLgawkへの変換
1037+
1038+ポータブルなサブセットから完全なXMLgawkへスクリプトを変換するのはさらに簡単です。
1039+この簡単さは、別の節(@pxref{XMLgawk Core Language Interface Summary})の中で述べられているように、@emph{Style B - すべてのイベントで共有される、限定された変数の組}のAPIと、ポータブルなサブセットのイベントループが似ていることから来るものです。
1040+移植の要点は、@code{getXMLEVENT}の起動を@code{getline}に置き換えることです。
1041+以下の作業リストを順に進めば、XMLデータを細かい部分までサポートするアプリケーションへとすぐに到達できるでしょう。
9761042
9771043 @enumerate
9781044 @item
979-アプリケーションのコードが書かれたファイルを新しいソースコードファイルへコピーします。
1045+アプリケーションのコードが書かれたファイルを、新しいソースコードファイルへコピーします。
1046+
9801047 @item
981-新しいソースコードファイルのファイルの先頭へ @code{@@load xml} と挿入します。
1048+新しいソースコードファイルのファイルの先頭へ@code{@@load xml}と挿入します。
1049+
9821050 @item
983-@code{BEGIN} パターンの中で、イベントループの @code{while} ステートメントの条件を変換します。
1051+@code{BEGIN}パターンの中で、イベントループの@code{while}ステートメントの条件を変換します。
9841052 @example
9851053 while (getXMLEVENT(ARGV[1])) @{
9861054 @end example
@@ -989,10 +1057,13 @@ XMLgawk スクリプトをポータブルなスクリプトへ変換するとい
9891057 while (getline > 0) @{
9901058 @end example
9911059 に変更します。
1060+
9921061 @item
993-@code{BEGIN} パターンの残りの部分は、変更されていないイベントループの部分とともにそのままにしておきます。
1062+@code{BEGIN}パターンの残りの部分は、変更されていないイベントループの部分とともにそのままにしておきます。
1063+
9941064 @item
995-@code{getXMLEVENT}、@code{unescapeXML}、@code{closeXMLEVENT} の各関数を削除します。
1065+@code{getXMLEVENT}、@code{unescapeXML}、@code{closeXMLEVENT}の各関数を削除します。
1066+
9961067 @item
9971068 出来上がったアプリケーションソースファイルが、期待通りに本当に動作するかを試します。
9981069 出力結果を比較してください。
@@ -1000,26 +1071,28 @@ XMLgawk スクリプトをポータブルなスクリプトへ変換するとい
10001071
10011072
10021073 @node XML Core Language Extensions of gawk
1003-@chapter gawk の XML コア言語拡張
1074+@chapter gawkのXMLコア言語拡張
10041075
10051076 @menu
1006-* 整形式のチェック::
1007-* XML ファイルのアウトラインの表示::
1008-* XML ファイルからのデータの取り出し::
1009-* キャラクタデータと文字セットのエンコーディング::
1010-* DTD の取り扱い::
1011-* XML ファイルのデータ全種類の処理::
1077+* Checking for well-formedness::
1078+* Printing an outline of an XML file::
1079+* Pulling data out of an XML file::
1080+* Character data and encoding of character sets::
1081+* Dealing with DTDs::
1082+* Sorting out all kinds of data from an XML file::
10121083 @end menu
10131084
1014-@ref{gawk で木構造をトラバースする方法} の中で、@ref{fig:docbook_chapter} の XML ファイルの木構造に注目していました。
1015-木構造をトラバースする処理を追い掛けるのを助けてくれる @code{XMLSTARTELEM} と @code{XMLENDELM} という二つのパターンを知りました。
1016-この @value{CHAPTER} では、他の XML に特有のパターンがどういうものかを見ていきます。
1085+別の節(@pxref{How to traverse the tree with gawk})の中で、fig:docbook_chapter(@pxref{fig:docbook_chapter})のXMLファイルの木構造に注目していました。
1086+木構造をトラバースする処理を追い掛けるのを支援する@code{XMLSTARTELEM}と@code{XMLENDELM}という二つのパターンを知りました。
1087+この@value{CHAPTER}では、他のXMLに特有のパターンがどういうものかを見ていきます。
10171088 それらのパターンは全部例の中で使いますし、その意味を簡単に説明するつもりです。
10181089
1090+
10191091 @node Checking for well-formedness, , ,
10201092 @section 整形式のチェック
1021-XML フォーマットをデータの格納に使うことで有利になることの一つは、データの正しさをチェックする正式な手段があるということです。
1022-データが手作業で書かれたか、あるいは自動生成されたものかを問わず、新しいデータがあるルール (タグがミススペルしてないか?もうひとつが欠けてないか?3 番目のものが違う場所にないか?) に則っているかどうかを調べるツールがあるということは常に有利なことです。
1093+
1094+XMLフォーマットをデータの格納に使うことで有利になることの一つは、データの正しさをチェックする正式な手段があるということです。
1095+データが手作業で書かれたか、あるいは、自動生成されたものかを問わず、新しいデータが、あるルール(タグがミススペルしてないか。もうひとつが欠けてないか。3番目のものが違う場所にないか。)に則っているかどうかを調べるツールがあるということは常に有利なことです。
10231096
10241097 @cindex DTD, Document Type Definition
10251098 @cindex Schema
@@ -1027,26 +1100,27 @@ XML フォーマットをデータの格納に使うことで有利になるこ
10271100 @cindex validation
10281101 @pindex @file{xmllint}
10291102 @pindex @file{xsv}
1030-
10311103 正しいかどうかをチェックするこれらの仕組みは、さまざまな段階で適用されます。
10321104 最も低い段階は整形式かどうかです。
1033-正しいかどうかをチェックする次の上の段階は、DTD (@pxref{サンプルファイルからの DTD の生成}) と (より高度ですが、まだ標準では要求されない) スキーマの段階です。
1034-XML ファイルに DTD (あるいはスキーマ) による仕様書があるならば、それを@emph{バリデーション}ツールに渡して、仕様書を適用し、その仕様書に則しているかどうかをチェックし、結果を報告してもらうことができます。
1035-DTD に対する簡単なバリデーションツールには @uref{http://xmlsoft.org/xmllint.html, @command{xmllint}} があります。
1036-このツールは @code{libxml} の一部なので、たいていの GNU/Linux システムにはインストールされています。
1037-スキーマに対するバリデーションには、@command{xmllint} の新しいほうのバージョンか、あるいは、@uref{http://www.ltg.ed.ac.uk/~ht/xsv-status.html, @command{xsv}} を使うことができます。
1105+正しいかどうかをチェックする次の段階は、DTD(@pxref{Generating a DTD from a sample file})と(より高度ですが、まだ標準では要求されない)スキーマの段階です。
1106+DTD(あるいは、スキーマ)による仕様書がXMLファイルにあるならば、@emph{バリデーション}ツールにそれを渡して、仕様書を適用し、その仕様書に則しているかどうかをチェックし、結果を報告してもらうことができます。
1107+DTDに対する簡単なバリデーションツールには@uref{http://xmlsoft.org/xmllint.html, @command{xmllint}}があります。
1108+このツールは@code{libxml}の一部なので、たいていのGNU/Linuxシステムにはインストールされています。
1109+スキーマに対するバリデーションには、@command{xmllint}の新しいほうのバージョンか、あるいは、@uref{http://www.ltg.ed.ac.uk/~ht/xsv-status.html, @command{xsv}}を使うことができます。
1110+
1111+@code{gawk}インタプリタにバリデーションが現在含まれていないのには以下の二つ理由があります。
10381112
1039-@code{gawk} インタプリタにバリデーションが現在含まれていないのには二つ理由があります。
10401113 @enumerate
1041-@item バリデーションはささいな事というわけではありませんし、標準化やサポート、安定度が適切なレベルまで達しているのは DTD のバリデーションだけです。
1042-@item 私たちは整形式の XML ファイルを全て処理できるツールが欲しいのであって、きれいなデータを処理するツールだけが欲しいのではありません。
1114+@item バリデーションはささいな事というわけではありませんし、標準化やサポート、安定度が適切なレベルまで達しているのはDTDのバリデーションだけです。
1115+
1116+@item 整形式のXMLファイルを全て処理できるツールが欲しいのであって、きれいなデータを処理するツールだけが欲しいのではありません。
10431117 良いツールというのは、信頼できて、問題を解決するのに使えるツールです。
1044-道路がぬかるんでいるとか、お日様が照っていないという理由だけで外を走るのを拒む自動車があったとしたら、あなたはどう思いますか?
1118+道路がぬかるんでいるとか、お日様が照っていないという理由だけで外を走るのを拒む自動車があったとしたら、あなたはどう思うでしょうか。
10451119 @end enumerate
10461120
1047-ここに、XML データが整形式になっているかどうかをテストするスクリプトがあります。
1048-整形式を検査する実際の作業は、@code{gawk} に組込まれた XML パーサが行ないます。
1049-私たちはその結果と、エラー診断、エラーからの回復の詳細についてだけ関心があります。
1121+ここに、XMLデータが整形式になっているかどうかをテストするスクリプトがあります。
1122+整形式を検査する実際の作業は、@code{gawk}に組込まれたXMLパーサが行います。
1123+ここでは、その結果と、エラー診断、エラーからの回復の詳細についてだけ関心があります。
10501124
10511125 @pindex @file{well_formed.awk}
10521126 @example
@@ -1060,19 +1134,21 @@ END @{
10601134 @}
10611135 @end example
10621136
1063-毎度のことですが、このスクリプトは @code{gawk} を XML モードへ切り替えることで始まります。
1064-トラバースされるノードの中身については今は関心がありませんので、ノードを見つけたときに実行されるアクションはありません。
1065-その最後の部分 (XML ファイルは既に閉じられている時) で、成功と失敗を報告する変数をいくつか見ているだけです。
1066-もし @code{XMLERROR} 変数に 0 や 空文字列以外のものが入っていれば、エラーが発生していて、パーサが、そのエラーの起きた場所でツリーのトラバースを止めています。
1067-説明のメッセージが @code{XMLERROR} に入っています (内容は、そのプラットフォームで使われているその特定のパーサに依存します)。
1068-そのほかの、例で使われている変数には、その XML ファイルの形式が間違っている場所の行番号とカラム数が入っています。
1137+毎度のことですが、このスクリプトは、@code{gawk}をXMLモードへ切り替えることで始まります。
1138+トラバースされるノードの中身については今は関心がありませんので、ノードを見つけた時に実行されるアクションはありません。
1139+その最後の部分(XMLファイルは既に閉じられている時)で、成功と失敗を報告する変数をいくつか見ているだけです。
1140+もし、@code{XMLERROR}変数に0や空文字列以外のものが入っていれば、エラーが発生していて、パーサは、そのエラーの起きた場所で、ツリーのトラバースを止めています。
1141+説明のメッセージが@code{XMLERROR}に入っています(内容は、そのプラットフォームで使われているその特定のパーサに依存します)。
1142+例で使われているその他の変数には、そのXMLファイルの形式が間違っている場所の行番号とカラム数が入っています。
1143+
10691144
10701145 @node Printing an outline of an XML file
1071-@section XML ファイルのアウトラインの表示
1146+@section XMLファイルのアウトラインの表示
10721147 @pindex @file{outline.awk}
1073-XML を処理していると、XML ファイルの構造をある程度管理する必要があります。
1074-普通のエディタならば、@ref{fig:dbfile} にあるような表示や、@ref{fig:docbook_chapter} のような冴えないツリー表示を突き出してきます。
1075-ソフトウェア開発者たちは、@ref{fig:ch2_dbfile} にあるような適切にインデントされた状態でテキストファイルを読むことに慣れています。
1148+
1149+XMLを使って作業していると、XMLファイルの構造をある程度注意して見る必要があります。
1150+普通のエディタならば、fig:dbfile(@pxref{fig:dbfile})にあるような表示や、fig:docbook_chapter(@pxref{fig:docbook_chapter})のような冴えないツリー表示を突き出してきます。
1151+ソフトウェア開発者たちは、fig:ch2_dbfile(@pxref{fig:ch2_dbfile})にあるような適切にインデントされた状態でテキストファイルを読むことに慣れています。
10761152
10771153 @float Figure,fig:ch2_dbfile
10781154 @example
@@ -1089,17 +1165,17 @@ book lang='en' id='hello-world'
10891165 title
10901166 para
10911167 @end example
1092-@caption{適切にインデントされたツリーとしての XML データ (DocBook ファイル)}
1168+@caption{適切にインデントされたツリーとしてのXMLデータ(DocBookファイル)}
10931169 @end float
10941170
10951171 ここで、ノード間の階層的な依存関係を把握するのはわずかに難しくなっています。
1096-しかし、正しくインデントされていると、100 を超えるエレメントを持つファイルを管理することもできるようになります (そういった大きなファイルを純粋にグラフィカルな表示にしてしまうと耐えられないです)。
1097-@ref{fig:ch2_dbfile} は、XML パーサの @uref{http://expat.sourceforge.net, Expat}に付属する @code{outline} ツールに影響されたものです。
1098-@code{outline} ツールはそういったインデントされた出力を生成します。
1099-今からこの種の出力をまねたスクリプトを書きましょう。
1100-@pindex outline, Expat アプリケーション
1101-@pindex Expat, SAX ライクな API を持つ XML パーサ
1102-@cindex SAX, XML のシンプルな API
1172+しかし、正しくインデントされていると、100を超えるエレメントを持つファイルを管理することもできるようになります(そういった大きなファイルを純粋にグラフィカルな表示にしてしまうのは耐えられません)。
1173+fig:ch2_dbfile(@pxref{fig:ch2_dbfile})は、XMLパーサの@uref{http://expat.sourceforge.net, Expat}に付属する@code{outline}ツールに影響されたものです。
1174+この@code{outline}ツールはそういったインデントされた出力を生成します。
1175+ここで、この種の出力をまねたスクリプトを書きましょう。
1176+@pindex outline, Expat application
1177+@pindex Expat, XML parser with SAX-like API
1178+@cindex SAX, Simple API for XML
11031179 @cindex @code{XMLATTR}
11041180
11051181 @float Figure,fig:ch2_outline.awk
@@ -1112,74 +1188,84 @@ XMLSTARTELEM @{
11121188 print ""
11131189 @}
11141190 @end example
1115-@caption{XML データのツリーのようなアウトラインを生成する @file{outline.awk}}
1191+@caption{XMLデータのツリーのようなアウトラインを生成する@file{outline.awk}}
11161192 @end float
11171193
1118-@ref{fig:ch2_outline.awk} にある @file{outline.awk} ファイルは私たちがこれまで書いてきた他のスクリプトと非常によく似ているように見えます。
1119-特に、@file{max_depth.awk} に似ていますね。
1194+fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})にある@file{outline.awk}ファイルは、これまで書いてきた他のスクリプトと非常によく似ているように見えます。
1195+特に、@file{max_depth.awk}に似ていますね。
11201196 これもノードをトラバースして、トラバースしながらツリーの深さを記憶するものでした。
1121-最も大きな違いは、@code{print} ステートメントの書いてある行です。
1122-最初の時は、@code{XMLSTARTELEM} 変数にタグ名が入っているかどうかまったく調べませんでしたが、ここでは、@code{printf} フォーマットステートメントを使って正しくインデントしながらタグの名前も出力しています (インデントレベルごとに二つの空白を出力しています)。
1197+最も大きな違いは、@code{print}ステートメントの書いてある行です。
1198+最初の時は、@code{XMLSTARTELEM}変数にタグ名が入っているかどうかまったく調べませんでした。
1199+ここでは、@code{printf}フォーマットステートメントを使って、正しくインデントしながらタグの名前も出力しています(インデントレベルごとに二つの空白を出力しています)。
11231200
1124-@file{max_depth.awk} スクリプトの説明の最後で、既に @code{XMLDEPTH} 変数について言及しました。
1125-そこで使われていた @code{depth} 変数の代わりにここで使っています。
1126-その結果、@code{XMLENDELEM} の後ろのアクションで使われていた @code{depth} の記帳処理はもう必要ではありません。
1127-私たちのスクリプトは短くなって、読み易くなりました。
1201+@file{max_depth.awk}スクリプトの説明の最後で、@code{XMLDEPTH}変数について既に言及しました。
1202+そこで使われていた@code{depth}変数の代わりにここで使っています。
1203+その結果、@code{XMLENDELEM}の後ろのアクションで使われていた@code{depth}の記帳処理はもう必要ではありません。
1204+スクリプトが短くなって、読み易くなりました。
11281205
11291206 @cindex @code{XMLATTR}
1130-このスクリプトのもう一つの新しい事柄は、@code{XMLATTR} という連想配列です。
1131-マークアップされたブロックに入る場合 (そして、@code{XMLSTARTELEM} が空でないとき) はいつでも、@code{XMLATTR} 配列には対象となったタグのアトリビュートが全て入っています。
1207+このスクリプトのもう一つの新しい事柄は、@code{XMLATTR}という連想配列です。
1208+マークアップされたブロックに入る場合(そして、@code{XMLSTARTELEM}が空でない時)はいつでも、@code{XMLATTR}配列に、対象となったタグのアトリビュートが全て入っています。
11321209 配列のインデックスとしてアトリビュートの名前を指定して配列にアクセスすれば、そのアトリビュートの値を調べることができます。
1133-整形式の XML ファイルであれば、一つのタグに付けられているアトリビュートの名前は全て異なっていますので、各アトリビュートが配列の中にそれぞれの場所を確保していることは確実なはずです。
1134-やり残しているただ一つのことは、この配列のエントリを全てイタレートして、その名前と値をフォーマットして表示することです。
1135-このスクリプトの初期のバージョンでは、@command{for (i in XMLATTR)} ループを使ってこの連想配列を本当にイタレートしていました。
1136-そうするのは今でも選択肢の一つですが、今回は、元の XML データに出てくるのと全く同じ順序でアトリビュートを確実に表示したいと思いました。
1137-アトリビュートの正確な順序は、@code{$1 .. $NF} というフィールドで再生成できます。
1138-ですので、この @code{for} ループは @code{$1 .. $NF} というフィールドでアトリビュートの@emph{名前}をイタレートし、アトリビュートの@emph{値} @code{XMLATTR[$i]} を表示することができます。
1210+整形式のXMLファイルであれば、一つのタグに付けられているアトリビュートの名前は全て異なっています。
1211+そのため、各アトリビュートが、配列の中にそれぞれの場所を確保していることは確実なはずです。
1212+ただ一つやり残していることは、この配列のエントリを全てイタレートして、その名前と値をフォーマットして表示することです。
1213+このスクリプトの初期バージョンでは、@command{for (i in XMLATTR)}ループを使って、この連想配列を本当にイタレートしていました。
1214+そうするのは今でも選択肢としてありますが、今回は、元のXMLデータに出てくるのと全く同じ順序でアトリビュートを確実に表示したいと思いました。
1215+アトリビュートの正確な順序は、@code{$1 .. $NF}というフィールドで再生成できます。
1216+ですから、この@code{for}ループは、@code{$1 .. $NF}というフィールドでアトリビュートの@emph{名前}をイタレートし、アトリビュートの@emph{値}@code{XMLATTR[$i]}を表示することができます。
1217+
11391218
11401219 @node Pulling data out of an XML file
1141-@section XML ファイルからのデータの取り出し
1220+@section XMLファイルからのデータの取り出し
11421221 @pindex @file{outline_puller.awk}
1143-この @value{SECTION} で私たちが分析するスクリプトは、前の @value{SECTION} のスクリプトと全く同じ出力を生成します。
1144-では、二つ目のものが必要なほど何が違うのでしょうか。
1222+
1223+この@value{SECTION}で分析するスクリプトは、前の@value{SECTION}のスクリプトと全く同じ出力を生成します。
1224+それでは、二つ目のものが必要なほど何が違うのでしょうか。
11451225 それは、目前にあるこの問題を解くのに使われているプログラミングスタイルです。
1146-前のスクリプトは、@code{XMLSTARTELEM} パターンがその@emph{パターン}の内部に位置するように書かれていました。
1147-これは、AWK プログラミングの典型的なスタイルです。
1226+前のスクリプトは、@code{XMLSTARTELEM}パターンがその@emph{パターン}の内部に位置するように書かれていました。
1227+これは、AWKプログラミングの典型的なスタイルです。
11481228 しかし、それは他言語のユーザが育てられた方法ではありません。
1149-手続型の言語では、ソフトウェアの開発者は、プログラムの内部のコントロールフローを自分自身で決めたいと思っています。
1229+手続き型の言語では、ソフトウェアの開発者は、プログラムの内部のコントロールフローを自分自身で決めたいと思っています。
11501230 最初に何をするか、次にどうするか、またその次になどなど、というふうに書きます。
1151-AWK の@emph{パターンアクション}モデルの場合、まだ慣れていないソフトウェア開発者は、以下のような耐えがたい感覚をよく抱きます。
1231+AWKの@emph{パターンアクション}モデルの場合、まだ慣れていないソフトウェア開発者は、以下のような耐えがたい感覚をよく抱きます。
11521232 @itemize
1153-@item 自分が@emph{支配}していない
1154-@item イベントがどこからともなくパチパチと自分に降り掛かるようにみえる
1155-@item データフローが混沌として見え、不変なものが無い
1156-@item アサーションが不可能にみえる
1233+@item 自分が@emph{支配}していない。
1234+@item イベントがどこからともなくパチパチと自分に降り掛かるように見える。
1235+@item データフローが混沌として見え、不変なものが無い。
1236+@item アサーションが不可能に見える。
11571237 @end itemize
11581238
1159-この感覚は、プログラミング環境の種類丸ごとの特徴を示しています。
1160-ほとんどの人が、以下のプログラミング環境に何か共通するものがあるとは決して考えないでしょう。
1161-しかし共通点があります。
1162-それは、これらの環境を一つの屋根の下に結び付ける、静的コントロールフローの不在です。
1239+この感覚は、プログラミング環境の種類全体の特徴を示しています。
1240+ほとんどの人が、次のプログラミング環境に何か共通するものがあるとは決して考えないでしょう。
1241+しかし、共通点があります。
1242+これらの環境を一つ屋根の下に結び付ける静的コントロールフローの不在です。
11631243
11641244 @itemize
11651245 @item
1166-X Window System のような GUI フレームワークでは、メインプログラムは小さな@emph{イベントループ}です -- メインプログラムはイベントを待ってイベントハンドラを起動する以外は何もしません。
1246+X Window SystemのようなGUIフレームワークでは、メインプログラムは小さな@emph{イベントループ}です。
1247+イベントを待ってイベントハンドラを起動する以外はメインプログラムは何もしません。
1248+
11671249 @item
1168-Prolog プログラミング言語では、メインプログラムは@emph{問い合わせ}の式です -- そして Prolog インタプリタは適用するルールを決定して、その問い合わせを解決します。
1250+Prologプログラミング言語では、メインプログラムは@emph{問い合わせ}の式です。
1251+そして、Prologインタプリタは適用するルールを決定し、その問い合わせを解決します。
1252+
11691253 @item
1170-@code{lex} ツールと @code{yacc} ツールを使ってコンパイラを書く場合、メインプログラムは @code{yyparse()} 関数を起動するだけであって、正確なコントロールフローは、一定のルールの起動を制御する入力ソースに依存します。
1254+@code{lex}ツールと@code{yacc}ツールを使ってコンパイラを書く場合、メインプログラムは@code{yyparse()}関数を起動するだけであって、正確なコントロールフローは、特定ルールの起動を制御する入力ソースに依存します。
1255+
11711256 @item
1172-@pindex Expat, SAX ライクな API を持つ XML パーサ
1173-@uref{http://expat.sourceforge.net, Expat} XML パーサで XML パーサを書く場合、メインプログラムはコールバックハンドラ関数をいくつか登録し、XML ソースを Expat パーサへ渡します。
1174-コールバック関数の具体的な起動は XML ソースに依存します。
1257+@pindex Expat, XML parser with SAX-like API
1258+@uref{http://expat.sourceforge.net, Expat} XMLパーサでXMLパーサを書く場合、メインプログラムはコールバックハンドラ関数をいくつか登録し、XMLソースをExpatパーサへ渡します。
1259+コールバック関数の具体的な起動はXMLソースに依存します。
1260+
11751261 @item
1176-最後に、AWK の@emph{パターンアクション} はメインプログラムが全く無いスクリプトを書くことを奨励しています。
1262+最後に、AWKの@emph{パターンアクション}は、メインプログラムが全く無いスクリプトを書くことを奨励しています。
11771263 @end itemize
11781264
1179-XML のコンテキストの内部で、イベント駆動の@emph{プッシュ}スタイルと手続型の@emph{プル}スタイルを区別する用語が発明されました。
1180-前の @value{SECTION} のスクリプトは@emph{プッシュ}型のスクリプトの一例でした。
1181-開発者は普通、自分のプログラムのコントロールフローがあれこれ指図されるのを好まないので、ここで一つスクリプトをプレゼントします。
1182-このスクリプトは、XML ファイルから一つアイテムを取り出した後また一つ取り出して,
1265+XMLの脈絡の中で、イベント駆動の@emph{プッシュ}スタイルと手続き型の@emph{プル}スタイルを区別する用語が発明されました。
1266+前の@value{SECTION}のスクリプトは、@emph{プッシュ}型のスクリプトの一例でした。
1267+開発者は、普通、自分のプログラムのコントロールフローがあれこれ指図されるのを好まないので、ここで一つスクリプトをプレゼントします。
1268+このスクリプトは、XMLファイルから一つアイテムを取り出した後、また一つ取り出して,
11831269 次にすることをもっと明快に決定するものです。
11841270
11851271 @cindex @code{XMLATTR}
@@ -1200,34 +1286,35 @@ BEGIN @{
12001286 @end example
12011287
12021288 @cindex @code{XMLEVENT}
1203-@command{getline} コマンドで得たデータから、前のイベントの次の XML イベントが一つ引き出されます。
1289+@command{getline}コマンドで得たデータから、前のイベントの次のXMLイベントが一つ引き出されます。
12041290 指の間から砂粒がどんどんこぼれ落ちるような感じです。
1205-このスタイルの入力の読み方を好むユーザは、もう一つの目新しいものも価値があると思うでしょう。
1206-変数 @code{XMLEVENT} です。
1207-@ref{fig:ch2_outline.awk} の@emph{プッシュスタイル}のスクリプトがイベント特有の変数 @command{XMLSTARTELEM} を新しい (次の) XML エレメントの存在を検出するのに使うのに対し、この@emph{プルスタイル} のスクリプトはいつも同じ普遍的変数の @code{XMLEVENT} を見て、新しい XML エレメントを検出します。
1208-私たちは、@ref{fig:testxml2pgsql.awk.2} のもっと詳細な例を詳しく見ていきます。
1291+このスタイルの入力の読み方を好むユーザは、もう一つのノベルティにも価値があると思うでしょう。
1292+変数@code{XMLEVENT}です。
1293+fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})の@emph{プッシュスタイル}のスクリプトでは、イベント特有の変数@command{XMLSTARTELEM}を新しい(次の) XMLエレメントの存在を検出するのに使います。
1294+それに対し、この@emph{プルスタイル}のスクリプトは、いつも同じ普遍的変数の@code{XMLEVENT}を見て、新しいXMLエレメントを検出します。
1295+fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})にあるさらに詳細な例を見ていきます。
1296+
1297+形の上では、必ず起動されるアクションを伴った@code{BEGIN}パターン一つから構成されるスクリプトです。
1298+これは、その本質が見えなくなるほど広範に切り詰められた@emph{パターンアクション}モデルのコーナーケースです。
1299+(アイテム単位でファイルを読むために、)パターンの代わりに、@code{while}ループに埋めこまれた@command{switch}ステートメントのcaseがあるのが分かります。
1300+明かに、前に使った暗黙の条件の代わりに、条件文を今度は明示しています。
1301+@code{case}条件の中で起動されるアクションは@emph{プッシュ}のアプローチで見たものと同じです。
12091302
1210-形の上では、必ず起動されるアクションを伴った @code{BEGIN} パターン一つから構成されるスクリプトです。
1211-えっと、これはその本質が見えなくなるほど広い範囲で切り詰められた、@emph{パターンアクション}モデルのコーナーケースです。
1212-パターンの代わりに、(アイテム単位でファイルを読むために) @code{while} ループに埋めこまれた @command{switch} ステートメントの case があるのがわかります。
1213-明かに、前の私たちが使った暗黙のやり方の代わりに、今は条件文を明示的にしています。
1214-@code{case} 条件の中で起動されるアクションは@emph{プッシュ}のアプローチで見たものと同じです。
12151303
12161304 @node Character data and encoding of character sets
12171305 @section キャラクタデータと文字セットのエンコーディング
1218-@cindex キャラクタデータ
1219-@cindex 文字エンコーディング
1306+@cindex Character Data
1307+@cindex character encoding
12201308
1221-私たちがこれまで見てきた例示したスクリプトには全て共通することがあります。
1222-それらは、XML データの木構造にだけ着目していました。
1223-タグの間にあるワードを取り扱うものはその中にはありませんでした。
1224-@ref{fig:dbfile} にあるもののようなファイルで作業するとき、@ref{fig:docbook_chapter} のノードに埋め込まれたワードにもっと関心がある場合がときどきあります。
1225-XML の専門用語では、これらのワードのことを@dfn{キャラクタデータ}と呼びます。
1226-DocBook
12271309 @cindex DocBook
1228-ファイルの場合であれば、タグの間に点々と存在するこれらのワードのことをドキュメント全体の@emph{ペイロード}と呼ぶことができるでしょう。
1229-時々、山括弧で括られた役に立たないもの全てからこのペイロードを自由にして、ファイルからキャラクタデータを抜き出すことに関心があることがあります。
1230-ドキュメントの構造は失なわれるかもしれませんが、ASCII で書かれた生のテキスト内容が露になって、XML を解しないアプリケーションソフトウェアにそれをインポートする準備ができます。
1310+これまで見てきた例示スクリプト全てには共通することがあります。
1311+それらは、XMLデータの木構造にだけ着目していました。
1312+タグの間にあるワードを取り扱うものはその中にはありませんでした。
1313+fig:dbfile(@pxref{fig:dbfile})にあるようなファイルで作業する場合、fig:docbook_chapter(@pxref{fig:docbook_chapter})のノードに埋め込まれたワードの方に関心があることもあります。
1314+XMLの専門用語では、これらのワードのことを@dfn{キャラクタデータ}と呼びます。
1315+DocBookファイルの場合であれば、タグの間に点々と存在するこれらのワードのことをドキュメント全体の@emph{ペイロード}と呼ぶことができるでしょう。
1316+山括弧で括られた役に立たないもの全てからこのペイロードを自由にして、ファイルからキャラクタデータを抜き出すことに関心がある場合があります。
1317+ドキュメントの構造は失なわれるかもしれませんが、ASCIIで書かれた生のテキスト内容が露になって、XMLを解しないアプリケーションソフトウェアにそれをインポートする準備ができます。
12311318
12321319 @float Figure,fig:ch2_dbcharacters
12331320 @smallexample
@@ -1251,12 +1338,12 @@ Warning
12511338
12521339 This is still under construction.
12531340 @end smallexample
1254-@caption{DocBook ファイルから取り出したテキストデータの例}
1341+@caption{DocBookファイルから取り出したテキストデータの例}
12551342 @end float
12561343
12571344 テキストが書かれている行の間にある空行がどこから来たものなのか不思議に思うかもしれません。
1258-これらはその XML ファイルの一部です。
1259-XML の、タグの外にある各改行は (タグの閉じ山括弧の後のものですら) キャラクタデータです。
1345+これらの空行はXMLファイルの一部です。
1346+XMLにおいて、タグの外にある各改行は、タグの閉じ山括弧の後のものであっても、キャラクタデータです。
12601347 このような出力を生成するスクリプトは極めて簡単です。
12611348
12621349 @pindex @file{extract_characters.awk}
@@ -1266,149 +1353,160 @@ XML の、タグの外にある各改行は (タグの閉じ山括弧の後の
12661353 XMLCHARDATA @{ printf $0 @}
12671354 @end example
12681355 @cindex @code{XMLCHARSET}
1269-@caption{XML ファイルからテキストデータを抽出する @file{extract_characters.awk}}
1356+@caption{XMLファイルからテキストデータを抽出する@file{extract_characters.awk}}
12701357 @end float
12711358
1272-キャラクタデータがパースされる毎に、@code{XMLCHARDATA} パターンが 1 にセットされ、キャラクタデータそのものは変数 @code{$0} に格納されます。
1273-少し独特なのは、そのテキストは @code{$0} に格納されるのであって、@code{XMLCHARDATA} の中では無いということです。
1274-テキスト処理をするとき、インタプリタが XML モードでないときに AWK がするように、テキストをフィールドに分割する必要がしばしば出てきます。
1275-@code{$1} @dots{} @code{$NF} というフィールドに格納されているワードで、分割されたワードを再び参照する方法を今は知っています。
1276-上のスクリプトを拡張して、ワードを、@file{wc.awk} スクリプトでしたように数えるようにするのは簡単でしょう。
1359+キャラクタデータがパースされる毎に、@code{XMLCHARDATA}パターンが1にセットされ、キャラクタデータそのものは変数@code{$0}に格納されます。
1360+少し独特なのは、そのテキストは@code{$0}に格納されるのであって、@code{XMLCHARDATA}の中では無いということです。
1361+テキスト処理をする時、インタプリタがXMLモードでない時にAWKがするように、テキストをフィールドに分割する必要があることもあります。
1362+@code{$1} @dots{} @code{$NF}というフィールドに格納されているワードを使えば、分割されたワードを再び参照できることがここで分かりました。
1363+上のスクリプトを拡張して、@file{wc.awk}スクリプトで行ったようにワードを数えるようにするのは簡単でしょう。
12771364
1278-ほとんどのテキストが、@ref{fig:ch2_dbcharacters} ほど単純というわけではありません。
1279-コンピュータにおけるテキストデータというのは 26 文字に限られているわけでなく、さらに区切り記号もいくつかあります。
1280-あらゆるキーボードには様々な種類の括弧 (< とか [、@{) があって、また、ヨーロッパでは、合字 (@AE{}) やウムラウト (@"u) のようなものが数世紀に渡って使われてきました。
1281-記号が何千もあるということ自体は問題ではありませんが、ソフトウェアアプリケーションがこういった記号を異なったバイト (またはバイト列でも) で表現しはじめると問題となりました。
1282-今日、世界中の全ての記号をバイト列で表現するスタンダードがあります。
1283-@uref{http://www.unicode.org/versions/Unicode4.0.0, Unicode} です。
12841365 @cindex Unicode
1285-@cindex 文字セット
1286-残念なことに、この受け入れられたスタンダードはやって来るのが遅すぎました。
1287-早い段階の標準化の努力で、完全なシンボルセットのサブセットを表現する方法が複数作られました。
1288-それぞれのサブセットは 1 バイトで表現できる 256 個のシンボルを含んでいました。
1289-こういったサブセットには、現在も使われている名前が付けられました (ISO-8859-1 や IBM-852、ISO-2022-JP のように)。
1290-それから、1 文字 16 ビットの @code{char} データ型を持つプログラミング言語 Java が登場しました。
1291-しかし、16 ビットでも全ての記号を表現するのに十分ではないことがわかりました。
1292-16 ビットで固定された文字は失敗だとわかったので、標準化団体は最後に、現在の Unicode スタンダードを規定しました。
1293-現在の Unicode 文字セットは素晴しい記号のカタログを持っています -- 上述の本は、文字記号をすべて一覧するの 1000 ページ以上を要しています。
1294-
1295-さて、Unicode の不恰好なところです。
1366+@cindex character set
1367+ほとんどのテキストが、fig:ch2_dbcharacters(@pxref{fig:ch2_dbcharacters})ほど単純というわけではありません。
1368+コンピュータにおけるテキストデータというのは26文字に限られているわけでなく、さらに区切り記号もいくつかあります。
1369+どのキーボードにも様々な種類の括弧(<とか[、@{)があって、また、ヨーロッパでは、合字(@AE{})やウムラウト(@"u)のようなものが数世紀に渡って使われてきました。
1370+記号が何千もあるということ自体は問題ではありませんが、ソフトウェアアプリケーションがこういった記号を違うバイト(または、バイト列)で表現しはじめると問題となりました。
1371+今日、世界中の全ての記号をバイト列で表現するスタンダードがあります。
1372+@uref{http://www.unicode.org/versions/Unicode4.0.0, Unicode}です。
1373+残念ですが、この認められたスタンダードは登場するのが遅すぎました。
1374+それ以前の標準化の努力によって、完全なシンボルセットのサブセットを表現する方法が複数作られました。
1375+それぞれのサブセットは1バイトで表現できる256個のシンボルを含んでいました。
1376+こういったサブセットに付けられた名前は現在も使われています(ISO-8859-1やIBM-852、ISO-2022-JPのように)。
1377+それから、1文字16ビットの@code{char}データ型を持つプログラミング言語Javaが登場しました。
1378+しかし、16ビットでも全ての記号を表現するのに十分ではないことが分かりました。
1379+16ビットで固定された文字は失敗だと分かったので、標準化団体は、最後に、現在のUnicodeスタンダードを規定しました。
1380+現在のUnicode文字セットは素晴しい記号カタログを備えています。
1381+上述の本の場合、文字記号をすべて一覧するのに1000ページ以上を要しています。
1382+
1383+さて、以下は、Unicodeの不恰好なところです。
1384+
12961385 @itemize
12971386 @item
1298-8 ビットの文字セットの名前がまだ使われていて、XML パーサやその XML パーサを利用したソフトウェアでサポートしなければなりません。
1387+8ビットの文字セットの名前がまだ使われていて、XMLパーサやそのXMLパーサを利用したソフトウェアでサポートしなければなりません。
1388+
12991389 @item
1300-Unicode のカタログにある文字記号ははっきりした数値を持っていますが、その数値は、一文字当りのバイト数が変わる多くのやり方でエンコードされることがあります。
1390+Unicodeのカタログにある文字記号は明確な数値を持っています。
1391+しかし、その数値をエンコードする場合、多くの方法があって、一文字当りのバイト数が変わってしまうことがあります。
1392+
13011393 @item
1302-テキストを表示するとき、どのエンコーディングを使用するか決めないといけません。
1394+テキストを表示する時、どのエンコーディングを使用するか決めないといけません。
13031395 もしテキストに違うエンコードがなされていれば、夢にも思わない奇妙なシンボルを見ることになるでしょう。
13041396 @end itemize
1305-@cindex 文字セット
13061397
1307-注意が必要ですが、@emph{文字セット}と@emph{文字エンコーディング}はまったく異なる概念です。
1308-前者は数学的な概念で言う集合で、後者は、文字が持つ数値を可変長のバイト列へマッピングする方法です。
1398+@cindex character encoding
1399+注意が必要ですが、@emph{文字セット}と@emph{文字エンコーディング}は全く異なる概念です。
1400+前者は、数学的な概念で言う集合のことです。
1401+後者は、文字が持つ数値を、可変長のバイト列へマッピングする方法です。
13091402 悪いことに、これらの用語の使い方は首尾一貫していません。
1310-XML の仕様書でも紹介した文献でもこれらの用語は明確に区別されてはいません。
1311-たとえば、O'Reilly の素晴しい本 @uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell} の @uref{ http://safari.oreilly.com/0596002920/xmlnut2-CHP-5-SECT-2, chapter 5.2} を引用しますので見てください。
1312-
1403+XMLの仕様書でも、紹介した文献でも、これらの用語は明確に区別されてはいません。
1404+例えば、O'Reillyの素晴しい本@uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell}の@uref{ http://safari.oreilly.com/0596002920/xmlnut2-CHP-5-SECT-2, chapter 5.2}を以下に引用しますので見てください。
13131405
13141406 @quotation
13151407 5.2 エンコーディング宣言
13161408
1317-XML ドキュメントはすべて、XML 宣言の一部として、@emph{エンコーディング宣言}を持つべきです。
1409+XMLドキュメントは、XML宣言の一部として、@emph{エンコーディング宣言}を全て持つべきです。
13181410 エンコーディング宣言は、そのドキュメントがどの文字セットで書かれているかをパーサに知らせるものです。
13191411 そのファイル外部の他のメタデータが利用できない場合にだけ使われます。
1320-例えば、次の XML 宣言は、ドキュメントが US-ASCII 文字エンコーディングを使うということを言っています。
1412+例えば、次のXML宣言は、ドキュメントがUS-ASCII文字エンコーディングを使うということを言っています。
13211413
13221414 @code{<?xml version="1.0" encoding="US-ASCII" standalone="yes"?>}
13231415
1324-次のものは、ドキュメントが Latin-1 文字セットを使っていることを述べています。
1325-もっとも、より公式な名前の ISO-8859-1 を使っていますが。
1416+次のものは、ドキュメントがLatin-1文字セットを使っていることを述べています。
1417+もっとも、より公式な名前のISO-8859-1を使っていますが。
13261418
13271419 @code{<?xml version="1.0" encoding="ISO-8859-1"?>}
13281420
13291421 @cindex @code{UTF-8}
13301422 @cindex @code{UTF-16}
1331-メタデータが利用できなくても、ドキュメントが Unicode
13321423 @cindex Unicode
1333-の UTF-8 エンコーディングか UTF-16 エンコーディングで書かれていれば、エンコーディング宣言を省略することができます。
1334-UTF-8 というのは ASCII の厳密なスーパーセットですので、ASCII ファイルは、エンコーディング宣言が無くても規則に則った XML ドキュメントです。
1335-
1424+メタデータが利用できなくても、UnicodeのUTF-8エンコーディングか、UTF-16エンコーディングでドキュメントが書かれていれば、エンコーディング宣言を省略することができます。
1425+UTF-8というのはASCIIの厳密なスーパーセットですので、ASCIIファイルは、エンコーディング宣言が無くても、規則に則ったXMLドキュメントです。
13361426 @end quotation
13371427
1338-何度か、文字セットの名前がエンコーディング宣言に当てがわれています。
1339-この本がそのようにしていますし、XML のサンプルもそうしています。
1340-最後の段落だけ用語の使い方がきれいです。
1341-UTF-8 は、文字をバイト列へエンコーディングするデフォルトの方法です。
1428+何度か、文字セットの名前がエンコーディング宣言に割り当てられています。
1429+この本がそのようにしていますし、XMLのサンプルもそのようになっています。
1430+最後の段落だけ用語の使い方がきちんとしています。
1431+UTF-8は、文字をバイト列へエンコーディングするデフォルトの方法です。
13421432
1343-西洋社会におけるテキストデータの文化史へのこの不愉快な逸脱の後は、@code{gawk} へ戻って、エンコーディングと文字セットの概念がこの言語の中にどのように取り入れられているかを見てみましょう。
1433+西洋社会におけるテキストデータの文化史の話へと不愉快にも脱線してしまいました。
1434+@code{gawk}へ戻って、エンコーディングと文字セットの概念が、この言語の中にどのように取り入れられているかを見てみましょう。
13441435 @cindex @code{XMLATTR["ENCODING"]}
13451436 @cindex @code{XMLDECLARATION}
13461437 @cindex @code{XMLCHARSET}
1347-@cindex @code{LANG}, 環境変数
1348-知っておく必要があるのは三つの変数で全てですが、それらの変数はそれぞれ別々のコンテキストから来ています。
1349-XML ドキュメントと、@code{gawk} 内部のデータの扱いと、@emph{ロケール}を設定するシェル環境の影響、この三者の間の違いについての認識に注意してください。
1438+@cindex @code{LANG}, environment variable
1439+知っておく必要があるのは三つの変数で全てです。
1440+変数は、別々のコンテキストからそれぞれ来ています。
1441+XMLドキュメント、@code{gawk}内部のデータ処理、@emph{ロケール}を設定するシェル環境の影響、この三者の間の違いについての認識に注意するようにしてください。
13501442
13511443 @itemize
13521444 @item
1353-@code{XMLATTR["ENCODING"]} はパターン変数で、(空で無く、@code{XMLDECLARATION} がトリガーされているとき) その XML ファイルがエンコードされている元の文字エンコーディングの名前が入っています。
1354-この情報は、(通常の XML ヘッダがあれば) XML ファイルの最初の行から得られます。
1445+@code{XMLATTR["ENCODING"]}はパターン変数です。
1446+(空で無く、@code{XMLDECLARATION}がトリガーされている時、)XMLファイルがエンコードされている元の文字エンコーディングの名前が入っています。
1447+この情報は、通常のXMLヘッダがあれば、XMLファイルの最初の行から得られます。
13551448 この変数を上書きしても役に立ちません。
1356-この変数は、XML データに何が入っているのかを示すもので、@code{XMLATTR["ENCODING"]} を変更しても何も起きません。
1449+この変数は、XMLデータに何が入っているのかを示すもので、@code{XMLATTR["ENCODING"]}を変更しても何も起きません。
1450+
13571451 @item
1358-@code{XMLCHARSET} は、あなた自身が選んだ文字セットへ変換された XML データを見たい場合に変更する変数です。
1359-この変数をセットすると、@code{gawk} インタプリタが選択した文字コードを記憶します。
1360-しかし、こうして選択したものは次のファイルを開くときにだけ効果を持つでしょう。
1361-@code{XMLCHARSET} を変更しても、その前に読み込みのために既に開いていたファイルの XML データには影響しません。
1452+@code{XMLCHARSET}は、選択した文字セットへ変換されたXMLデータを見たい場合に変更する変数です。
1453+この変数をセットすると、@code{gawk}インタプリタが選択した文字コードを記憶します。
1454+しかし、こうして選択したものは、次のファイルを開く時にだけ効果を持ちます。
1455+@code{XMLCHARSET}を変更しても、その前に読み込みのために既に開いていたファイルのXMLデータには影響しません。
1456+
13621457 @item
1363-@code{LANG} は、オペレーティングシステムの環境変数です。
1364-ユーザスクリプトの中で何も指定していない場合、起動時の @code{XMLCHARSET} の値として @code{gawk} インタプリタに通知されるものです。
1365-@code{LANG} に対する設定が無い場合は、@code{US-ASCII} がデフォルトエンコーディングとして使用されます。
1366-ここまでずっと、処理されるデータのエンコーディングと文字セットについて話してきました。
1458+@code{LANG}は、オペレーティングシステムの環境変数です。
1459+ユーザスクリプトの中で何も指定していない場合、起動時の@code{XMLCHARSET}の値として@code{gawk}インタプリタに通知されるものです。
1460+@code{LANG}に対する設定が無い場合は、デフォルトエンコーディングとして@code{US-ASCII}が使用されます。
1461+ここまで、処理されるデータのエンコーディングと文字セットについてずっと話してきました。
13671462 ここで、プログラムのソースも何らかの文字セットで書かれるということを思い出してください。
1368-プログラムを書くのに使われるのは通常、@code{LANG} の文字セットです。
1369-あなたのネイティブキャラクタセットの文字を含んだプログラムがあった場合何が起きるかを想像してみてください。
1370-そのために、実行時に使うキャラクタセットにエンコーディングがありません。
1371-注意深い読者ならば、文字エンコーディングと文字セットを混同する Unicode
1463+通常、プログラムを書くのに使われるのは@code{LANG}の文字セットです。
1464+ユーザのネイティブ文字セットの文字を含んだプログラムがあった場合、何が起きるかを想像してみてください。
1465+そのために、実行時に使われる文字セットにはエンコーディングがありません。
13721466 @cindex Unicode
1373-の伝統に従って、@code{gawk} がどういう結果を生じさせるか気が付くでしょう。
1467+注意深い読者ならば、文字エンコーディングと文字セットを混同するUnicodeの伝統に従って、@code{gawk}がどういう結果を生じさせるか分かるでしょう。
13741468 @end itemize
13751469
1376-非常に多くの学者的な推理をしたあと、(まごまごしている初心者を除けば) 文字セットとエンコーディングが実生活ではほとんど役立たないというふうに考えるほうに気持ちが傾くかもしれません。
1377-次の例はあなたの持つ疑問を払拭するはずです。
1378-実生活では、良識的な推理を超越した状況によって、@ref{fig:ch2_dbcharacters} にあるテキストを Microsoft Windows のアプリケーションにインポートするよう強いられるかもしれません。
1470+非常に多くの学者的な推理をした後ならば、(まごまごしている初心者を除けば)文字セットとエンコーディングが実生活ではほとんど役立たないというふうに考えるほうに気持ちが傾くかもしれません。
1471+次の例は疑念を払拭するはずです。
1472+実生活では、良識的な推理を超越した状況によって、fig:ch2_dbcharacters(@pxref{fig:ch2_dbcharacters})のテキストを、Microsoft Windowsのアプリケーションにインポートするよう強いられるようなことがあるかもしれません。
13791473 @cindex Microsoft Windows
13801474 @cindex @code{UTF-16}
13811475 @cindex @code{US-ASCII}
1382-今の各種の Microsoft Windows は、@code{UTF-16} でテキストデータを格納するのを優先しています。
1383-ですので、テキストを @code{UTF-16} へ変換するスクリプトは、持っているとナイスなツールとなるでしょう。
1384-そして、既にあなたはそのようなツールを持っています。
1385-DocBook ファイルを読む際に、@code{UTF-16} エンコーディングを使うように @code{gawk} インタプリタに指示すれば、@ref{fig:extract_characters.awk} にある @file{extract_characters.awk} スクリプトがそのような仕事をします。
1386-この目標に達するのに取り得る手段が二つあります。
1476+現在の各Microsoft Windowsは、@code{UTF-16}でテキストデータを格納するのを優先しています。
1477+ですから、テキストを@code{UTF-16}へ変換するスクリプトは、持っているとナイスなツールとなるでしょう。
1478+そして、そのようなツールは既にあります。
1479+DocBookファイルを読む際に、@code{UTF-16}エンコーディングを使うように@code{gawk}インタプリタに指示すれば、fig:extract_characters.awk(@pxref{fig:extract_characters.awk})の@file{extract_characters.awk}スクリプトがそのような仕事をします。
1480+この目標を達成するには、取り得る手段が次のように二つあります。
1481+
13871482 @itemize
13881483 @item
1389-スクリプトを変更して、@code{XMLCHARSET} を @code{UTF-16} へセットする行を挿入します。
1390-起動後、@code{gawk} インタプリタは、 @ref{fig:ch2_dbcharacters} にあるのと同じデータではあるが、@code{UTF-16} に変換されたものを表示します。
1391-to @code{UTF-16}.
1484+スクリプトを変更して、@code{XMLCHARSET}を@code{UTF-16}へセットする行を挿入します。
1485+起動後、@code{gawk}インタプリタは、fig:ch2_dbcharacters(@pxref{fig:ch2_dbcharacters})にあるのと同じデータですれども、@code{UTF-16}に変換されたものを表示します。
1486+
13921487 @example
13931488 BEGIN @{ XMLCHARSET="utf-16" @}
13941489 @end example
1490+
13951491 @item
1396-スクリプトは変更せずに、@code{gawk} インタプリタを起動する前に、@code{LANG} 環境変数を @code{UTF-16} にセットします。
1492+スクリプトは変更せずに、@code{gawk}インタプリタを起動する前に、@code{LANG}環境変数を@code{UTF-16}にセットします。
13971493 @end itemize
1398-オペレーティングシステムがこれらの文字セットとエンコーディングをサポートしていれば、どちらの場合も結果は同じです。
1399-コマンドラインシェルのレベルでの変更が必要なので (しかも副作用の可能性もあるので)、実際には恐らく、これらのうち 2 番目のアプローチは避けるほうが良いです。
1494+
1495+オペレーティングシステムが、これらの文字セットとエンコーディングをサポートしていれば、どちらの場合も結果は同じです。
1496+コマンドラインシェルのレベルでの変更が必要なので(しかも、副作用の可能性もあるので)、実際には、恐らく、これらのうち2番目のアプローチは避けたほうが良いです。
1497+
14001498
14011499 @node Dealing with DTDs
1402-@section DTD の取り扱い
1500+@section DTDの取り扱い
14031501 @cindex DTD, Document Type Definition
14041502
1405-この @value{CHAPTER} の最初の方で、@code{gawk} は DTD に対して XML データの妥当性を検証しないということを見ました。
1406-XML ファイルのヘッダにあるドキュメントタイプの宣言は、データの中のあっても無くても良い部分で、強制的なものではありません。
1407-(@ref{fig:dbfile} にあるように) もしそのような宣言が存在している場合、その DTD への参照は解決されず、その内容はパースされないでしょう。
1408-しかしながら、宣言の存在は @code{gawk} によって報告されます。
1409-宣言が始まると、@code{XMLSTARTDOCT} 変数にルートエレメントのタグの名前が入ります。
1410-そしてその後、宣言が終了するとき、@code{XMLENDDOCT} 変数が 1 にセットされます。
1411-その間、@code{XMLATTR} 配列変数には、(もしあれば) DTD の public 識別子の値と、(もしあれば) DTD の SYSTEM の識別子の値が投入されます。
1503+この@value{CHAPTER}の最初の方で、@code{gawk}は、DTDに対してXMLデータの妥当性を検証しないということを見ました。
1504+XMLファイルのヘッダにあるドキュメントタイプの宣言は、データの中のあっても無くても良い部分であって、強制的なものではありません。
1505+fig:dbfile(@pxref{fig:dbfile})にあるように、そのような宣言が存在している場合、そのDTDへの参照は解決されず、その内容はパースされないでしょう。
1506+しかしながら、宣言の存在は@code{gawk}によって報告されます。
1507+宣言が始まると、@code{XMLSTARTDOCT}変数にルートエレメントのタグの名前が入ります。
1508+そして、その後、宣言が終了する時、@code{XMLENDDOCT}変数が1にセットされます。
1509+その間、@code{XMLATTR}配列変数には、(もしあれば)DTDのpublic識別子の値と(もしあれば)DTDのSYSTEMの識別子の値が入れられます。
14121510 @cindex @code{XMLATTR}
14131511 @cindex @code{XMLATTR["VERSION"]}
14141512 @cindex @code{XMLATTR["ENCODING"]}
@@ -1416,7 +1514,7 @@ XML ファイルのヘッダにあるドキュメントタイプの宣言は、
14161514 @cindex @code{XMLATTR["PUBLIC"]}
14171515 @cindex @code{XMLATTR["SYSTEM"]}
14181516 @cindex @code{XMLATTR["INTERNAL_SUBSET"]}
1419-宣言の他の部分 (エレメントやアトリビュート、実体) はレポートされません。
1517+宣言の他の部分(エレメント、アトリビュート、実体)はレポートされません。
14201518
14211519 @pindex @file{db_version.awk}
14221520 @float Figure,fig:db_version.awk
@@ -1447,25 +1545,26 @@ XMLENDDOCT @{
14471545 root = pub_id = sys_id = intsubset ""
14481546 @}
14491547 @end example
1450-@caption{XML ファイルの DTD に関する詳細を抽出する @file{db_version.awk}}
1548+@caption{XMLファイルのDTDに関する詳細を抽出する@file{db_version.awk}}
14511549 @end float
14521550
1453-データそのものに関心があるだけであれば、ほとんどのユーザはこれらの変数を安全に無視することができます。
1454-しかし、XML データの要求をチェックするためにこの変数を利用するユーザもいるかもしれません。
1455-出所がさまざまな何千もの XML ファイルでデータベースが構成されていた場合、それらのファイルの DTD の public 識別子が、処理しなければならないデータの種類を監視し、起こり得るバージョンの競合を監視する助けとなるでしょう。
1456-@ref{fig:db_version.awk} のスクリプトは、データファイルを解析するのを助けます。
1457-上で述べた変数を探して、その内容を評価するものです。
1458-DTD の最初で、ルートエレメントのタグ名を保存します。
1459-識別子もまた保存し、最後にそれらの値を、解析されたファイルの名前とともに表示します。
1460-DTD それぞれが終わるたび、次のファイルの DTD が表われるまで、記憶された値は空文字列へとセットされます。
1461-
1462-@ref{fig:ch2_DTD_details} には @ref{fig:db_version.awk} のスクリプトの出力例があります。
1463-出力の最初のエントリは、既に私たちが知っている @ref{fig:dbfile} のファイルです。
1464-もちろん、スイスの CERN にある DTD のローカルコピーに対して妥当性を検証しなければならない @code{book} エレメントを含む DocBook ファイル (English version 4.2) が最初のエントリです。
1551+データそのものに関心があるだけであれば、ほとんどのユーザは、これらの変数を安全に無視することができます。
1552+しかし、XMLデータの要求をチェックするためにこの変数を利用するユーザもいるかもしれません。
1553+出所がさまざまな何千ものXMLファイルでデータベースが構成されていた場合、それらのファイルのDTDのpublic識別子が、処理しなければならないデータの種類を監視し、起こり得るバージョンの競合を監視する助けとなるでしょう。
1554+fig:db_version.awk(@pxref{fig:db_version.awk})のスクリプトは、データファイルを解析するのを助けます。
1555+このスクリプトは、上で述べた変数を探して、その内容を評価するものです。
1556+DTDの最初で、ルートエレメントのタグ名を保存します。
1557+識別子もまた保存し、最後に、それらの値を、解析されたファイルの名前とともに表示します。
1558+DTDがそれぞれ終わるたび、次のファイルのDTDが現われるまで、記憶された値は空文字列へとセットされます。
1559+
1560+fig:ch2_DTD_details(@pxref{fig:ch2_DTD_details})には、fig:db_version.awk(@pxref{fig:db_version.awk})のスクリプトの出力例があります。
1561+出力の最初のエントリは、既知のfig:dbfile(@pxref{fig:dbfile})のファイルです。
14651562 @cindex DocBook
1466-2 番目のファイルは、インターネット上の DTD に対して妥当性を検証される、DocBook (English version 4.1.2) の @code{chapter} エレメントです。
1467-最後に、3 番目のエントリは、GanttProject アプリケーションのプロジェクトを説明するファイルです。
1468-ルートエレメントを指定するためのタグ名があるだけで、DTD が存在するようには見えません。
1563+もちろん、最初のエントリは@code{book}エレメントを含むDocBookファイル(English version 4.2)です。
1564+このエレメントは、スイスのCERNにあるDTDのローカルコピーに対して妥当性を検証しなければなりません。
1565+2番目のファイルは、DocBook(English version 4.1.2)の@code{chapter}エレメントで、インターネット上のDTDに対して妥当性を検証されます。
1566+最後に、3番目のエントリは、GanttProjectアプリケーションのプロジェクトを説明するファイルです。
1567+ルートエレメントを指定するためのタグ名があるだけで、DTDが存在するようには見えません。
14691568
14701569 @float Figure,fig:ch2_DTD_details
14711570 @smallexample
@@ -1496,51 +1595,59 @@ data/exampleGantt.gan
14961595 system id ''
14971596 intsubset ''
14981597 @end smallexample
1499-@caption{いくつかの XML における DTD に関する詳細}
1598+@caption{いくつかのXMLにおけるDTDに関する詳細}
15001599 @end float
15011600
1502-日々の作業で必要である場合、このスクリプトを変更したいと思うかもしれません。
1503-例えば、このスクリプトは現在、DTD の宣言を持たないファイルについて何も報告しません。
1504-@code{root} 変数、@code{pub_id} 変数、@code{sys_id} 変数が全て空である場合に報告する @code{END} ルールにアクションを追加すれば、変更は容易です。
1505-また、DTD というのは XML ファイルの常に先頭で、ルートエレメントの前にあるものなんですけれども、このスクリプトは、そのままであれば XML ファイル全体をパースします。
1506-ルートエレメントのパースは不要で、最初のエレメント (ルートエレメント) が出現したときにパースするのを止めるよう指示すれば、このスクリプトの速度をかなり改善することができます。
1601+日々の作業で必要であれば、このスクリプトを変更したいと思うでしょう。
1602+例えば、このスクリプトは、現在、DTDの宣言を持たないファイルについて何も報告しません。
1603+この変更は容易です。
1604+@code{root}変数、@code{pub_id}変数、@code{sys_id}変数が全て空の場合にそれを報告する@code{END}ルールに対し、アクションを追加するようにします。
1605+また、DTDというのは、XMLファイルの先頭で、ルートエレメントの前に常にあるものです。
1606+このスクリプトは、そのままであれば、XMLファイル全体をパースします。
1607+ルートエレメントのパースは不要です。
1608+最初のエレメント(ルートエレメント)が出現した時に、パースするのを止めるよう指示すれば、このスクリプトの速度をかなり改善することができます。
1609+
15071610 @example
15081611 @code{ XMLSTARTELEM @{ nextfile @} }
15091612 @end example
15101613
1614+
15111615 @page
15121616 @node Sorting out all kinds of data from an XML file
1513-@section XML ファイルのデータ全種類の処理
1514-
1515-あなたがここまでこの @value{DOCUMENT} を順に読んでこられたのでしたら、XML ファイルの読み方と木構造としての扱い方を理解しています。
1516-また、さまざまな文字エンコーディングと DTD 宣言の処理の仕方も知っています。
1517-この @value{SECTION} では、XML ファイルで作業するときのほかのパターンについて概要を示すことにしています。
1518-この概要は、出てくる全てのパターンの名前と使い方の例を示すという意味で完全なものにすることにしています。
1519-概念的には多くの新しい材料があるわけではないです。
1520-新しいものというのは、XML ファイルから情報を渡すためのいくつかの新しい変数に関するものだけです。
1617+@section XMLファイルのデータ全種類の処理
1618+
1619+この@value{DOCUMENT}をここまで順に読んでこられたのでしたら、XMLファイルの読み方と木構造としての扱い方を理解していることになります。
1620+また、さまざまな文字エンコーディングとDTD宣言の処理の仕方も分かっています。
1621+この@value{SECTION}では、XMLファイルを使って作業する時の他のパターンについて概要を示すことにします。
1622+この概要では、登場する全パターンの名前と、その使い方の例を示すという点で完全なものにするつもりです。
1623+概念的に新しい材料が沢山出てくるわけではありません。
1624+新しいのは、XMLファイルから情報を渡すためのいくつかの新しい変数に関するものだけです。
15211625 さて、その新しいパターンです。
15221626
15231627 @itemize
15241628 @item
15251629 @cindex @code{XMLPROCINST}
1526-XMLPROCINST にはプロセッシングインストラクションの名前が入っています。
1527-また、$0 にはその内容が入っています。
1630+XMLPROCINSTにはプロセッシングインストラクションの名前が入っています。
1631+また、$0にはその内容が入っています。
1632+
15281633 @item
15291634 @cindex @code{XMLCOMMENT}
1530-XMLCOMMENT は XML のコメントを示すものです。
1531-コメント自体は $0 の中にあります。
1635+XMLCOMMENTは、XMLのコメントを示すものです。
1636+コメント自体は$0の中にあります。
1637+
15321638 @item
15331639 @cindex @code{XMLDECLARATION}
15341640 @cindex @code{XMLATTR}
1535-XMLDECLARATION は、@code{XMLATTR["VERSION"]} から読み出せる、XML ファイルの最初の行からの XML のバージョン番号を表わします。
1641+XMLDECLARATIONは、@code{XMLATTR["VERSION"]}から読み出せる、XMLファイルの最初の行にあるXMLのバージョン番号を表わします。
1642+
15361643 @item
15371644 @cindex @code{XMLUNPARSED}
1538-XMLUNPARSED は他のカテゴリに当てはまらないかったテキストを表わします。
1539-その内容は $0 の中にあります。
1645+XMLUNPARSEDは、他のカテゴリに当てはまらなかったテキストを表わします。
1646+その内容は$0の中にあります。
15401647 @end itemize
15411648
1542-次のスクリプトは、全ての XML のパターンと変数をデモンストレーションするためのものです。
1543-このスクリプトで、XML ファイル中にある全てのものと、そしてそれが @code{gawk} でどのように読み込まれるかを表示することができますので、他のスクリプトをデバッグする際あなたを助けることができます。
1649+次のスクリプトは、全てのXMLのパターンと変数をデモンストレーションするためのものです。
1650+このスクリプトで、XMLファイル中にある全てのものと、そして、それが@code{gawk}でどのように読み込まれるかを示すことができますので、他のスクリプトをデバッグする際、便利に使えるでしょう。
15441651
15451652 @pindex @file{demo_pusher.awk}
15461653 @cindex @code{XMLMODE}
@@ -1576,8 +1683,8 @@ XMLUNPARSED は他のカテゴリに当てはまらないかったテキスト
15761683 @float Figure,fig:demo_pusher.awk
15771684 @example
15781685 @@load xml
1579-# コンプライアントな XML データを厳格に XML パーサで読み込むために
1580-# XMLMODE をセットする
1686+# 仕様に適合したXMLデータをXMLパーサで厳密に読み込むため
1687+# XMLMODEをセットする
15811688 BEGIN @{ XMLMODE=1 ; XMLCHARSET = "ISO-8859-1" @}
15821689 # ネストしたタグとアトリビュートのアウトラインを表示
15831690 XMLSTARTELEM @{
@@ -1586,18 +1693,18 @@ XMLSTARTELEM @{
15861693 printf(" %s='%s'", $i, XMLATTR[$i])
15871694 print ""
15881695 @}
1589-# タグを閉じる際、XMLPATH はタグ名を保持したまま。
1696+# タグを閉じる際、XMLPATHはタグ名を保持したまま。
15901697 XMLENDELEM @{ printf("%s %s\n", "XMLENDELEM", XMLPATH) @}
1591-# XMLEVENT は処理中のイベントの名前を保持。
1698+# XMLEVENTは処理中のイベントの名前を保持。
15921699 XMLEVENT @{ print "XMLEVENT", XMLEVENT, XMLNAME, $0 @}
15931700 # キャラクタデータは失なわれない。
15941701 XMLCHARDATA @{ print "XMLCHARDATA", $0 @}
15951702 # プロセッシングインストラクションとコメントが報告される。
15961703 XMLPROCINST @{ print "XMLPROCINST", XMLPROCINST, $0 @}
15971704 XMLCOMMENT @{ print "XMLCOMMENT", $0 @}
1598-# CDATA セクションは引用する字面そのままのテキストに利用される。
1705+# CDATAセクションは引用する字面そのままのテキストに利用される。
15991706 XMLSTARTCDATA @{ print "XMLSTARTCDATA" @}
1600-# CDATA ブロックは終了時に報告される。
1707+# CDATAブロックは終了時に報告される。
16011708 XMLENDCDATA @{ print "XMLENDCDATA" @}
16021709 # 一番最初のイベントはバージョン情報を保持する。
16031710 XMLDECLARATION @{
@@ -1605,19 +1712,19 @@ XMLDECLARATION @{
16051712 encoding = XMLATTR["ENCODING" ]
16061713 standalone = XMLATTR["STANDALONE"]
16071714 @}
1608-# 存在すれば、DTD 自体が表示される。
1715+# 存在すれば、DTD自体が表示される。
16091716 XMLSTARTDOCT @{
16101717 root = XMLSTARTDOCT
16111718 print "XMLATTR[PUBLIC]", XMLATTR["PUBLIC"]
16121719 print "XMLATTR[SYSTEM]", XMLATTR["SYSTEM"]
16131720 print "XMLATTR[INTERNAL_SUBSET]", XMLATTR["INTERNAL_SUBSET"]
16141721 @}
1615-# DTD の終了でも表示される。
1722+# DTDの終了でも表示される。
16161723 XMLENDDOCT @{ print "root", root @}
16171724 # 未パースのテキストがまれにある。
16181725 XMLUNPARSED @{ print "XMLUNPARSED", $0 @}
1619-# XMLENDDOCUMENT は、標準に厳密に従っていない XML データのときだけ
1620-# 起きる (ルートエレメントが複数ある)。
1726+# XMLENDDOCUMENTは、標準に厳密に従っていないXMLデータの時だけ
1727+# 起きる(ルートエレメントが複数ある)。
16211728 XMLENDDOCUMENT @{ print "XMLENDDOCUMENT" @}
16221729 # ファイルの終わりで、エラーが起きたかどうかチェックできる。
16231730 END @{ if (XMLERROR)
@@ -1625,79 +1732,87 @@ END @{ if (XMLERROR)
16251732 XMLERROR, XMLROW, XMLCOL, XMLLEN)
16261733 @}
16271734 @end example
1628-@caption{XMLgawk の全変数をデモンストレーションするスクリプト @file{demo_pusher.awk}}
1735+@caption{XMLgawkの全変数をデモンストレーションするスクリプト@file{demo_pusher.awk}}
16291736 @end float
16301737
1738+
16311739 @node Some Convenience with the xmllib library
1632-@chapter xmllib ライブラリの利点
1633-XML ファイルを読むために AWK 言語に追加された変数は、一度に一つのイベントを示します。
1634-いくつかのノードからデータを再度整理したいような場合、木構造のトラバースの間に必要なデータを集めねばなりません。
1635-こういう状況の一例が、@ref{いくつかの高度なアプリケーション}の例の中で何度か必要となる親ノードの名前です。
1740+@chapter xmllibライブラリの利点
1741+
1742+XMLファイルを読めるようにするためAWK言語に追加された変数は、一度に一つのイベントを示します。
1743+複数ノードから得たデータを再編したいような場合、木構造のトラバースの間に必要なデータを集めねばなりません。
1744+こういう状況の一例が、別の節(@pxref{Some Advanced Applications})の例の中で何度か必要とされる親ノードの名前です。
16361745
1637-Stefan Tramm は、コマンドラインでの @code{gawk} の使い方 (ワンライナー) を簡単にしたいがために、@file{xmllib} ライブラリを書きました。
1638-彼のライブラリは、AWK コードの普通のスクリプトとして書かれていて、@command{xmlgawk} の起動によって自動的にインクルードされます。
1746+Stefan Trammは、コマンドラインで@code{gawk}を簡単に使いたいために(ワンライナー)、@file{xmllib}ライブラリを書きました。
1747+このライブラリは、AWKコードの普通のスクリプトとして書かれていて、@command{xmlgawk}の起動によって自動的にインクルードされます。
16391748 キャラクタデータやタグのネストを簡単に扱うための変数が導入されています。
1640-Stefan は @command{xmlgawk} ラッパスクリプトと同じくこのライブラリも提供してくれました。
1749+Stefanは、@command{xmlgawk}ラッパスクリプトと同じく、このライブラリも提供してくれました。
16411750
16421751 @b{FIXME: This chapter has not been written yet}.
16431752
1753+
16441754 @node DOM-like access with the xmltree library
1645-@chapter xmltree ライブラリを使った DOM ライクアクセス
1755+@chapter xmltreeライブラリを使ったDOMライクアクセス
16461756 @cindex DOM, Document Object Model
1647-@file{xmllib} を使ってさえも、木構造の中のノードへランダムにアクセスすることはできません。
1648-親エレメントや子エレメントへアクセスして、ときどきツリーの中の離れた場所へもアクセスしなければならないアプリケーションは少しばかりあります。
1649-これが、Manuel Collado が @file{xmltree} ライブラリを書いた理由です。
1650-
1651-Manuel の @file{xmltree} は一度に XML ファイルを読み込んで、まるごと保持してしまいます。
1652-このアプローチのことを DOM アプローチと呼びます。
1653-XSL のような言語は本質的に、スクリプトを実行する際、DOM が存在していると仮定しています。
1654-これは、同時に、こういった言語の強さ (ランダムアクセス) でもあり、弱さ (メモリにファイルを丸ごと保持する事) でもあります。
1757+
1758+@file{xmllib}を使ってさえも、木構造の中のノードへ、ランダムにアクセスすることはできません。
1759+親エレメントや子エレメントへアクセスして、ツリーの中の離れた場所へもアクセスしなければならないアプリケーションが少しばかりあります。
1760+これが、Manuel Colladoが、@file{xmltree}ライブラリを書いた理由です。
1761+
1762+Manuelの@file{xmltree}は一度にXMLファイルを読み込み、丸ごと保持します。
1763+このアプローチのことをDOMアプローチと呼びます。
1764+XSLのような言語は、本質的に、スクリプトを実行する際、DOMが存在していると仮定しています。
1765+同時に、これは、こういった言語の強さ(ランダムアクセス)でもあり、弱さ(メモリにファイルを丸ごと保持する事)でもあります。
16551766 @cindex XSL
16561767
1657-Manuel は @file{xmltree} ライブラリを提供してくれました。
1768+Manuelは、@file{xmltree}ライブラリを提供してくれました。
16581769
16591770 @b{FIXME: This chapter has not been written yet}.
16601771
16611772
1662-
16631773 @node Problems from the newsgroups comp.text.xml and comp.lang.awk
1664-@chapter ニューズグループ comp.text.xml と comp.lang.awk からの問題
1665-@cindex comp.text.xml, インターネット上のニューズグループ
1666-@cindex comp.lang.awk, インターネット上のニューズグループ
1774+@chapter ニューズグループcomp.text.xmlとcomp.lang.awkからの問題
1775+@cindex comp.text.xml, newsgroup on the Internet
1776+@cindex comp.lang.awk, newsgroup on the Internet
16671777
16681778 @menu
1669-* i="Y" のエレメントの抽出::
1670-* XMLTV ファイルからタブ付き ASCII への変換::
1671-* 一組のデータの最小値の探索::
1672-* ドキュメントでの使われ方に適合する DTD のアップデート::
1673-* XML パスを使った操作::
1779+* Extract the elements where i="Y"::
1780+* Convert XMLTV file to tabbed ASCII::
1781+* Finding the minimum value of a set of data::
1782+* Updating DTD to agree with its use in doc's::
1783+* Working with XML paths::
16741784 @end menu
16751785
16761786
1677-この @value{CHAPTER} はインターネット上のニューズグループに投稿された XML に関係する問題を集めたものです。
1678-元の投稿を引用して問題の要点を短かく紹介したあと、それぞれの問題について XMLgawk での解決をしていきます。
1679-元の問題を正しく解決できるように注意しましたが、実際のところ、これらの問題のいずれの詳細にも関心はありません。
1680-関心が@emph{ある}ことは、この種の問題に取り掛かるための一般的な方法のデモンストレーションです。
1681-この @value{CHAPTER} の@emph{レゾンデートル}は多岐にわたります。
1787+この@value{CHAPTER}は、インターネット上のニューズグループに投稿されたXMLに関係する問題を集めたものです。
1788+元の投稿を引用して問題の要点を短かく紹介した後、それぞれの問題についてXMLgawkでの解決をしていきます。
1789+元の問題を正しく解決できるように注意しましたが、実際のところ、これらの問題のいずれについても、その細部には関心がありません。
1790+関心が@emph{ある}ことは、この種の問題に取り掛かるための一般的な方法をデモンストレーションすることです。
1791+この@value{CHAPTER}の@emph{レゾンデートル}は次のように多岐にわたります。
1792+
16821793 @itemize
16831794 @item
1684-ニューズグループに投稿される問題はしばしば、学校のテキストブックの例題というよりも、日常の作業というものをよく表わしています。
1795+ニューズグループに投稿される問題は、学校のテキストブックの例題というよりも、日常の作業というものをよく表わしていることがあります。
1796+
16851797 @item
16861798 オープンソースソフトウェアの開発は、実生活の中で起きる要求によって動かされています。
1687-ツールをユーザのニーズに適応させることは、観念的な基準に適応させることよりも得るところが大きいものです。
1799+ユーザのニーズにツールを適応させることは、観念的な基準に適応させることよりも得るところが大きいものです。
1800+
16881801 @item
16891802 こういった問題というのは、ツールの充実度を測るための歓迎すべき試験台です。
1690-私たちは、XMLgawk の輝いている面と同時にそれほど輝いていない面について学んでいきます。
1803+XMLgawkの輝いている面と同時に、それほど輝いていない面について学んでいきます。
1804+
16911805 @item
1692-問題を解決するツールのそれぞれは、ユーザがそれを使うための基本的なスキルとテクニックをいくらか会得したときにだけ、その実用性が証明されます。
1693-ついでに、こういったことのいくつかもデモンストレーションするつもりです。
1806+問題を解決するツールは、それぞれ、ユーザがそれを使うための基本的なスキルとテクニックをいくらか会得した時にだけ、実用性が証明されます。
1807+ついでに、こういったことについても、いくつかデモンストレーションするつもりです。
16941808 @end itemize
16951809
16961810
16971811 @node Extract the elements where i="Y"
1698-@section i="Y" のエレメントの抽出
1699-この問題の元の投稿者は、特定の種類 (@code{i="Y"}) のアトリビュートを持つタグを全て見つけだし、出力として別のアトリビュートの値を生成したいというものでした。
1700-彼はこの問題を、入出力の関係を使って次のように説明しました。
1812+@section i="Y"のエレメントの抽出
1813+
1814+この問題の元の投稿者は、特定の種類(@code{i="Y"})のアトリビュートを持つタグを全て見つけだし、出力として、別のアトリビュートの値を生成したいというものでした。
1815+彼は、この問題を、入出力の関係を使って次のように説明しました。
17011816
17021817 @example
17031818 次のものがあるとします。
@@ -1711,7 +1826,7 @@ Manuel は @file{xmltree} ライブラリを提供してくれました。
17111826 <g i="Y" j="ffff"/>
17121827 </a>
17131828
1714-そして以下のようなものを得られるように、i="Y" であるエレメントを抽出し
1829+そして、以下のようなものを得られるように、i="Y"であるエレメントを抽出し
17151830 たいのです。
17161831 <x>
17171832 <y>1. aaaa</y>
@@ -1723,11 +1838,11 @@ Manuel は @file{xmltree} ライブラリを提供してくれました。
17231838 うか。
17241839 @end example
17251840
1726-彼はおそらく、二つのフィールドを持つ入力フォームから XML データを得たのでしょう。
1727-最初のフィールドには選択肢 (Y/N) に対する答えが入っていて、2 番目のフィールドには何か説明が入っています。
1728-問題のゴールは、全てのポジティブな答え (@code{i="Y"}) に応じた説明の部分を抽出することでした。
1729-出力データはすべて、ネストされたタグ (@code{x} と @code{y}) の中に埋め込まなければなりませんでした。
1730-このタグのネスティングが、以下の解決方法の @code{BEGIN} パターンと @code{END} パターンの中の @code{print} コマンドの理由です。
1841+彼は、恐らく、二つのフィールドを持つ入力フォームからXMLデータを得たのでしょう。
1842+最初のフィールドには選択肢(Y/N)に対する答えが入っていて、2番目のフィールドには何か説明が入っています。
1843+問題のゴールは、ポジティブな答え(@code{i="Y"})に応じた説明の部分を全て抽出することでした。
1844+出力データは、ネストされたタグ(@code{x}と@code{y})の中に全て埋め込まなければなりませんでした。
1845+このタグのネスティングが、以下の解決方法の@code{BEGIN}パターンと@code{END}パターンの中にある@code{print}コマンドの理由です。
17311846
17321847 @cindex @code{XMLATTR}
17331848 @example
@@ -1740,35 +1855,36 @@ XMLSTARTELEM @{
17401855 END @{ print "</x>" @}
17411856 @end example
17421857
1743-@code{XMLSTARTELEM} パターンは、@code{y} の出力タグの表示をトリガーします。
1744-しかし、@code{i} アトリビュートが @code{Y} という値を持つときだけ出力が表示されます。
1745-出力自体は、@code{j} アトリビュートの値で構成され、@code{y} タグの間に埋めこまれます。
1858+@code{XMLSTARTELEM}パターンは、@code{y}の出力タグの表示をトリガーします。
1859+しかし、@code{i}アトリビュートが@code{Y}という値を持つ時だけ出力が表示されます。
1860+出力自体は、@code{j}アトリビュートの値で構成され、@code{y}タグの間に埋めこまれます。
17461861
1747-元の投稿者による入力データで、上のスクリプトを試してみると、前に示された期待される出力から少し違う出力が得られることがわかるでしょう。
1748-出力の 3 番目のアイテムが明らかにタイポです (@code{ffff} の代わりに @code{gggg})。
1862+元の投稿者による入力データで上のスクリプトを試してみると、期待される上述の出力から少し違う出力が得られることが分かるでしょう。
1863+出力の3番目のアイテムが明らかにタイポです(@code{ffff}の代わりに@code{gggg})。
17491864
17501865 @cindex XSL
1751-この種の問題 (入力データも出力データも XML) は通常 XSL 言語で解決されます。
1752-この例で、XMLgawk が (XML の) 入力データを読み込むのには十分なツールであることを学びました。
1753-しかし、出力データのタグ構造を (単に @code{print} コマンドで) 生成することが、それを好む人がいるというほど洗練されているわけではありません。
1866+この種の問題(入力データも、出力データもXML)は、通常、XSL言語で解決します。
1867+この例で、XMLgawkが(XMLの)入力データを読み込むのに十分なツールであることを学びました。
1868+しかし、出力データのタグ構造を(単に、@code{print}コマンドで)生成することが、それを好む人がいるというほど洗練されているわけではありません。
17541869
1870+
17551871 @node Convert XMLTV file to tabbed ASCII
1756-@section XMLTV ファイルからタブ付き ASCII への変換
1757-@cindex ASCII, タブ付き
1872+@section XMLTVファイルからタブ付きASCIIへの変換
1873+@cindex ASCII, tabbed
17581874 @cindex XMLTV
17591875
1760-この問題は、前の問題とは生成する出力データの種類の点で異なります。
1761-ここでは、XML の入力ファイルからタブ区切りの ASCII データの出力を生成します。
1762-この疑問の元の投稿者は、@uref{http://xml.coverpages.org/xmltv.html, XMLTV format} にある XML データを使いました。
1763-XMLTV というのは、いつ、どのチャンネルで、どの TV program (米語ではなく英語では TV program@emph{me}) が放送されるのかという情報を格納するためのフォーマットです。
1764-元の投稿者が例となるデータをいくつか示しています (非常に読み易い形式というわけではないということは確か)。
1876+この問題は、前の問題とは、生成する出力データの種類の点で異なります。
1877+ここでは、XMLの入力ファイルから、タブ区切りのASCIIデータの出力を生成します。
1878+この問題の元の投稿者は、@uref{http://xml.coverpages.org/xmltv.html, XMLTV format}にあるXMLデータを使いました。
1879+XMLTVというのは、いつ、どのチャンネルで、どのTV program(米語ではなく、英語の場合だとTV program@emph{me})が放送されるのかという情報を格納するためのフォーマットです。
1880+元の投稿者が、例となるデータをいくつか示しています(非常に読み易い形式というわけではないことは確かです)。
17651881
17661882 @example
1767-誰か以下を解決して、私が XMLGAWK を理解する手助けをしてもらえませんか?
1768-XMLTV のデータファイルがありまして、そこからあるデータを取り出して、タブ区切
1883+誰か以下を解決して、私がXMLGAWKを理解する手助けをしてもらえませんか。
1884+XMLTVのデータファイルがありまして、そこからあるデータを取り出して、タブ区切
17691885 りのフラットなファイルに書き出したいのです。
17701886
1771-当の XMLTV データは次のようなものです。
1887+当のXMLTVデータは次のようなものです。
17721888
17731889 <?xml version="1.0" encoding="UTF-8"?>
17741890 <tv><programme start="20041218204000 +1000" stop="20041218225000
@@ -1786,12 +1902,12 @@ worst enemies!</desc><rating
17861902 system="ABA"><value>C</value></rating><length
17871903 units="minutes">30</length><category>Children</category></programme></tv>
17881904
1789-フラットなファイルというのは次のようなものである必要があります。
1905+フラットなファイルというのは、次のようなものである必要があります。
17901906
17911907 channel<tab>programme
17921908 start<tab>length<tab>title<tab>description<tab>rating value
17931909
1794-で、最初のレコードは次のように読めるでしょう。
1910+最初のレコードは次のように読めるでしょう。
17951911
17961912 Network TEN Brisbane<tab>2004-12-18 hh:mm<tab>130<tab>The
17971913 Frighteners<tab>A psychic private detective, who consorts with
@@ -1799,8 +1915,8 @@ deceased souls, becomes engaged in a mystery as members of the town
17991915 community begin dying mysteriously.<tab>M
18001916 @end example
18011917
1802-で、彼は、@code{programme} という種類のノードそれぞれにつき、一つの ASCII 出力行を得たいようです。
1803-彼の例の入力の正しいアウトラインは以下のように見えます。
1918+彼は、@code{programme}という種類のノードそれぞれにつき、一つのASCII出力行を得たいようです。
1919+例にある入力の正しいアウトラインは次のような感じです。
18041920
18051921 @example
18061922 tv
@@ -1822,23 +1938,23 @@ tv
18221938 category
18231939 @end example
18241940
1825-期待する出力を表示するのは、前の @value{SECTION} ほど簡単ではありません。
1941+期待する出力を表示するのは、前の@value{SECTION}ほど簡単ではありません。
18261942 ここには、ノードのキャラクタデータとして格納されているたくさんのデータと、アトリビュートとして格納されている少しのデータがあります。
1827-XMLgawk では、キャラクタデータよりもアトリビュートに対して作業することのほうがかなり簡単です。
1828-このことは XMLgawk が XSL
1943+XMLgawkでは、キャラクタデータよりもアトリビュートに対して作業することの方がかなり簡単です。
18291944 @cindex XSL
1830-とは大きく違うところです。
1831-XSL は、どちらの種類のデータももっと統一的な方法で扱うことができます。
1832-
1833-@code{BEGIN} パターンの後ろのアクション部分では、タブ区切りの ASCII 出力を生成するのがいかに簡単かがわかります (すなわち、出力する各フィールドを @code{TAB} 文字で区切ります)。
1834-@code{OFS} 変数を @code{"\t"} に設定するだけです。
1835-もう一つ簡単な作業がありますが、それは、チャンネルに関する情報とテレビ番組の開始時刻に関する情報を集めることです。
1836-それらは、@code{programme} ノードのアトリビュートに格納されています。
1837-ですので、@code{programme} ノードに入ると、アトリビュートが読み出され、後の作業のためにその内容が保存されます。
1838-ノードに入ってすぐに出力行を表示できないのはなぜでしょうか?
1839-それは、それ以外のデータビット (length と title、description) が後からネストしたノードに入って現われるからです。
1840-この結果、データの収集は、@code{programme} ノードから離れるときにだけ完了します。
1841-ですので、タブ付きの出力表示は @code{XMLENDELEM == "programme"} パターンの後ろのアクション部分で行なわれます。
1945+このことは、XMLgawkがXSLとは大きく違うところです。
1946+XSLは、どちらの種類のデータももっと統一的な方法で扱うことができます。
1947+
1948+@code{BEGIN}パターンの後ろのアクション部分では、タブ区切りのASCII出力を生成するのがいかに簡単かが分かります(すなわち、出力する各フィールドを@code{TAB}文字で区切ります)。
1949+@code{OFS}変数を@code{"\t"}に設定するだけです。
1950+もう一つ簡単な作業があります。
1951+チャンネルに関する情報とテレビ番組の開始時刻に関する情報を集めることです。
1952+それらの情報は、@code{programme}ノードのアトリビュートに格納されています。
1953+ですから、@code{programme}ノードに入ると、アトリビュートを読み出し、後の作業のためにその内容を保存します。
1954+ノードに入って、出力行をすぐに表示できないのはなぜでしょうか。
1955+それ以外のデータビット(length、title、description)が、後からネストしたノードに入って現われるからです。
1956+この結果、データの収集は、@code{programme}ノードから離れる時にだけ完了します。
1957+ですから、タブ付きの出力表示は@code{XMLENDELEM == "programme"}パターンの後ろのアクション部分で行われます。
18421958
18431959 @cindex @code{XMLATTR}
18441960 @example
@@ -1862,35 +1978,36 @@ XMLENDELEM == "programme" @{
18621978 @end example
18631979
18641980 やり残していることはキャラクタデータを集めることです。
1865-キャラクタデータに遭遇するたびに、後でまた取り出すため、@code{data} 変数にそのキャラクタデータを保存します。
1866-この時点では、どのような種類のキャラクタデータなのかまだわかりません。
1867-後になって (@code{desc} や @code{length}、@code{title}、@code{value} ノードを離れるときに) ようやく、そのデータを正しい配置先へと割り当てることができます。
1868-この種の、キャラクタデータの遅延配置は、@emph{ストリーミング}アプローチに従う XML パーサにとって特徴的なことです。
1869-そういう XML パーサだと、一度に一つのデータアイテムしか見ず、後で必要になるデータビットを保存する処理をしなければなりません。
1870-XSL のような XML を変換する言語は、この欠点に煩わされることがありません。
1871-XSL では、XML データのあらゆる情報にランダムにアクセスします。
1872-目前の問題を、(XMLgawk のような) ストリーミングパーサで解決するべきか、あるいは、(XSL のような) @uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM parser} で解決するべきかの決定は、ユーザ次第です。
1873-XMLgawk を使いたくて、しかも、キャラクタデータを簡単に取り扱うことの快適さをさらに楽しみたいのであれば、別に説明している @code{xmllib} (@pxref{xmllib ライブラリの利点}) ライブラリか、@code{xmltree} (@pxref{xmltree ライブラリを使った DOM ライクアクセス}) ライブラリを使うべきです。
1981+キャラクタデータに遭遇するたびに、後でまた取り出すため、そのキャラクタデータを@code{data}変数に保存します。
1982+この時点では、どのような種類のキャラクタデータなのかまだ分かりません。
1983+後になって(@code{desc}や@code{length}、@code{title}、@code{value}ノードを離れる時に)、ようやく、正しい配置先へとそのデータを割り当てることができます。
1984+キャラクタデータのこの種の遅延配置は、@emph{ストリーミング}アプローチに従うXMLパーサにとって特徴的なことです。
1985+そういうXMLパーサだと、一度に一つのデータアイテムしか見ず、後で必要になるデータビットを保存する処理をしなければなりません。
1986+XSLのようなXMLを変換する言語は、この欠点に煩わされることがありません。
1987+XSLでは、XMLデータのあらゆる情報にランダムにアクセスします。
1988+目前の問題を、(XMLgawkのような)ストリーミングパーサで解決するべきか、あるいは、(XSLのような) @uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM parser}で解決するべきかの決定はユーザ次第です。
1989+XMLgawkを使いたくて、しかも、キャラクタデータを簡単に取り扱うことの快適さをさらに楽しみたいのであれば、別に説明している@code{xmllib}(@pxref{Some Convenience with the xmllib library})ライブラリか、@code{xmltree}(@pxref{DOM-like access with the xmltree library})ライブラリを使うべきです。
1990+
18741991
18751992 @node Finding the minimum value of a set of data
18761993 @section 一組のデータの最小値の探索
18771994
1878-これまで、XML の入力データの探索や再整形が主たる関心事の事例を見てきました。
1879-しかし、読み込みや表示というのがときどき十分ではありません。
1880-次の事例の元の投稿者は、全ての @code{month} タグの @code{value} アトリビュートの最も短かい値を必要としています。
1881-彼は、自分で試みた XSL による解決について、XSL テンプレートで起きた典型的な問題を述べながら、明確に言及しています。
1995+これまで、XMLの入力データの探索や再整形が主たる関心事の事例を見てきました。
1996+しかし、読み込みや表示というのが十分でないことがあります。
1997+次の事例の元の投稿者は、全ての@code{month}タグの中で、@code{value}アトリビュートの最短値を必要としています。
1998+彼は、自分で試みたXSLによる解決について、XSLテンプレートで起きた典型的な問題を述べながら、明確に言及しています。
18821999
18832000 @example
1884-私は、一連のデータ (後述) から最小値を見つけようと試みています。アトリ
2001+私は、一連のデータ(後述)から最小値を見つけようと試みています。アトリ
18852002 ビュートの値の長さを比較して、一番短いものを表示したいのです。
18862003
1887-変数へ値を割り当て直すことができれば、簡単なことでしょうけれども、私の
1888-推測では、そうすることはできないようです。ループを繰り返しているときに
1889-最小の値を保持しておくにはどうすればよいのでしょうか?私の XSL ドキュ
1890-メントは、各文字列の長さを調べ、それを (とりあえず) 表示するだけです。
1891-私は、再帰的なコールを行なうテンプレートを書くことはできますが、各ルー
1892-プを通り抜けている間、最小値をすぐ利用できるように保持しておくにはどう
1893-すれば良いかわかりません。
2004+変数へ値を割り当て直すことができれば簡単なことでしょうけれども、私の推測
2005+では、そうすることはできないようです。ループを繰り返している時に最小の値
2006+を保持しておくにはどうすればよいのでしょうか。私のXSLドキュメントは、各
2007+文字列の長さを調べ、それを(とりあえず)表示するだけです。私は、再帰的な
2008+コールを行うテンプレートを書くことはできますが、各ループを通り抜けてい
2009+る間、最小値をすぐ利用できるように保持しておくにはどうすれば良いか分かり
2010+ません。
18942011
18952012 どうぞよろしく。
18962013
@@ -1913,12 +2030,12 @@ XML Document
19132030 <month value="December"/>
19142031 </calendar>
19152032 @end example
1916-@cindex 再帰
2033+@cindex recursion
19172034
1918-彼が探している答えというのは、@code{May} という値です。
1919-私たちのような単純な思考だと、そこまでに見つかった最短の値を常に記憶しておいて、@code{month} タグのリストを上から下へ通り抜けます。
1920-そして、リストを終了するとその時記憶していた値が答えです。
1921-以下のスクリプトを見てもらえば、それが、私たちの単純思考のアプローチの経路を辿っていることがわかるでしょう。
2035+彼が探している答えというのは、@code{May}という値です。
2036+私たちのような単純な思考だと、そこまでに見つかった最短の値を常に記憶しておいて、@code{month}タグのリストを上から下へ通り抜けます。
2037+そして、リスト終了時、記憶していた値が答えです。
2038+以下のスクリプトを見てもらえば、スクリプトが、単純思考のアプローチの経路を辿っていることが分かるでしょう。
19222039
19232040 @cindex @code{XMLATTR}
19242041 @example
@@ -1935,75 +2052,81 @@ END @{ print shortest @}
19352052 @end example
19362053
19372054 @cindex XSL
1938-XSL での解決は、この場合ほど簡単というわけではありません。
1939-XSL は関数型言語の一つで、それ自体、@emph{変数}のようなプログラミング概念が普通はありません。
1940-また、普通は副作用が無いというのが関数型言語の強みの一つとなっていて、値を入れる大域変数というのは (概念的に言えば) 副作用です。
1941-ですので、XSL での解決では、いわゆる@emph{テンプレート}の、再帰的にお互いを呼び出し合う使い方を必要となります。
1942-
1943-このような事例は、XSL が他の言語と非常に違っていて、その結果、私たちのほとんどにとって学ぶのがさらに難しくなっているというのは何故なのかという疑問に光を当てるものです。
1944-この簡単な例を見てもわかるように、XSL において再帰の使用は避けられないものです。
1945-全てのタスクのうち最も簡単なものと考えてもです。っ
1946-実のところ、再帰的な思考というのは、大抵のソフトウェア開発者が日常的な仕事としてしたいと思うような方法ではありません。
2055+XSLでの解決は、この場合ほど簡単というわけではありません。
2056+XSLは、関数型言語の一つです。
2057+それ自体、@emph{変数}のようなプログラミング概念がほとんどありません。
2058+また、副作用がまず無いというのが関数型言語の強みの一つとなっています。
2059+値を入れる大域変数というのは(概念的に言えば)副作用です。
2060+ですから、XSLで解決するには、相互再帰的に呼び出しを行ういわゆる@emph{テンプレート}を使う必要があります。
2061+
2062+このような事例は、XSLが他の言語と非常に違っていて、その結果、ほとんどの人にとって学ぶのがさらに難しくなっているというのは何故なのかという疑問に光を当てるものです。
2063+この簡単な例を見ても分かるように、XSLにおいて再帰の使用は避けられないものです。
2064+全タスクの中で最も簡単なものを考えたとしてもです。
2065+実際のところ、再帰的な思考というのは、大抵のソフトウェア開発者が日常的な仕事としてしたいと思うような方法ではありません。
19472066 彼らに尋いてみてください。
1948-C や C++、あるいは AWK プログラムで、@emph{あなた}が最後に再帰を使ったのはいつですか?
2067+CやC++、あるいは、AWKプログラムで、@emph{あなた}が最後に再帰を使ったのはいつでしょうか。
2068+
19492069
19502070 @node Updating DTD to agree with its use in doc's
1951-@section ドキュメントでの使われ方に適合する DTD のアップデート
2071+@section ドキュメントでの使われ方に適合するDTDのアップデート
19522072 @cindex DTD, Document Type Definition
1953-私が @ref{サンプルファイルからの DTD の生成} を書いてから数ヶ月経って、誰かが @uref{news://comp.text.xml, comp.text.xml} ニューズグループに似たようなツールのリクエストを投稿しました。
2073+
2074+私が、別の節(@pxref{Generating a DTD from a sample file})を書いてから数ヶ月後、@uref{news://comp.text.xml, comp.text.xml}ニューズグループに、似たようなツールのリクエストを誰かが投稿しました。
19542075
19552076 @example
1956-数年前、提案されたドキュメントのクラスに対する DTD を私の所属部門が定
1957-義しました。合衆国憲法のように、この DTD には実際に使われないような項
1958-目が並んでいて、私はそれを整理したいのです。既存のドキュメントを見て、
1959-それらが使用している DTD と比較するようなツールが何かないでしょうか?
2077+数年前、提案されたドキュメントのクラスに対するDTDを、私の所属部門が
2078+定義しました。合衆国憲法のように、実際に使われないような項目がこのD
2079+TDには並んでいて、私は、それを整理したいのです。既存のドキュメントを
2080+見て、それらが使用しているDTDと比較するようなツールが何かないでしょ
2081+うか。
19602082
19612083 [私は、そのようなツールを何かで代用する他の可能性について考えることも
19622084 できますので、誰かがそういうものを発明しているかもしれないと考えました。
1963-私は XML Spy を持っていますが、こういうことをしてくれるような機能は見
2085+私はXML Spyを持っていますが、こういうことをしてくれるような機能は見
19642086 当たりません。]
19652087 @end example
19662088
1967-元の投稿者が必要としているものは、DTD を読み込んで、サンプルとなっているファイルが、その DTD の全ての部分を実際に使っているのかどうかを調べるツールです。
1968-これは @ref{サンプルファイルからの DTD の生成} にある DTD ジェネレータがやっていることでは必ずしもありません。
1969-しかし、DTD ジェネレータでサンプルファイルの DTD を生成し、その生成された DTD と元の DTD を比較することは実用的な解決法となるでしょう。
2089+元の投稿者が必要としているものは、DTDを読み込んで、サンプルとなっているファイルが、そのDTDの全ての部分を実際に使っているのかどうか調べるツールです。
2090+これは、別の節(@pxref{Generating a DTD from a sample file})にあるDTDジェネレータがやっていることでは必ずしもありません。
2091+しかし、DTDジェネレータでサンプルファイルのDTDを生成し、その生成されたDTDと元のDTDを比較することは実用的な解決法となるでしょう。
19702092
1971-誰かほかの人が、Unix ツールセットのいくつかのツールを寄せ集めて利用する、代わりの解決法を投稿しました。
2093+誰か他の人が、Unixツールセットのいくつかのツールを寄せ集めて利用する代わりの解決法を投稿しました。
19722094
19732095 @example
1974-私は、TEI SGML から XML への移行の一部としてこれを行ないました。要する
2096+私は、TEI SGMLからXMLへの移行の一部としてこれを行いました。要する
19752097 に次のようになります。
19762098
1977-a) nsgmls をドキュメント全部に実行し、ESIS を作る。
1978-b) awk を使ってエレメントの型の名前を抽出する。
1979-c) それを sort して uniq する。
1980-d) Perl::SGML を使って DTD を読み込み、エレメントの型の名前をリストに
2099+a) nsgmlsをドキュメント全部に実行し、ESISを作る。
2100+b) awkを使ってエレメントの型の名前を抽出する。
2101+c) それをsortしてuniqする。
2102+d) Perl::SGMLを使ってDTDを読み込み、エレメントの型の名前をリストに
19812103 する。
1982-e) それを sort する。
1983-f) 大文字小文字を区別せず二つのリストを -a 付きで join して、一致しな
2104+e) それをsortする。
2105+f) 大文字小文字を区別せず二つのリストを-a付きでjoinして、一致しな
19842106 いものを吐き出す。
19852107
1986-Unix ベースのシステムを使っていないのでしたら、Cygwin でこういったツー
2108+Unixベースのシステムを使っていないのでしたら、Cygwinでこういったツー
19872109 ルが使えると思います。
19882110 @cindex Cygwin
19892111 @end example
19902112
1991-あなたが望む解決法が何であっても、最も一般的なプラットフォームが利用できれば、これらのツールはユーザにとって十分役立ちます。
2113+選択する解決法が何であっても、最も一般的なプラットフォームが利用できれば、これらのツールはユーザにとって十分役立ちます。
2114+
19922115
19932116 @node Working with XML paths
1994-@section XML パスを使った操作
1995-
1996-現在のプログラミング言語のほとんどは、XML ファイルを読むための何らかのサポートを提供しています。
1997-しかし XMLgawk とは違い、その他の言語のほとんどは、XML ファイルを、メモリに常駐する、木構造をしたデータ構造へ写します。
1998-こうすることで、XML ファイルのあらゆるエレメントへ、望んだ順番で簡単にアクセスできるようになります。
1999-XMLgawk でするような、一度に一つ順番にアクセスするというだけではありません。
2000-@uref{news://comp.text.xml, comp.text.xml} ニューズグループの中で、そういった言語のユーザの一人がよくある問題を思い付き、その解決法を求めました。
2001-以下に示す XML データを読む際、構造的に似ているサブエレメントを運んでいる二つの @code{item} エレメントを報告してください。
2002-@code{item} にはそれぞれ、@code{PPrice} と @code{BCQuant} というサブエレメントがあって、@code{item} の価格と数量が入っています。
2117+@section XMLパスを使った操作
2118+
2119+現在のプログラミング言語の大部分は、XMLファイルを読むための何らかのサポートを提供しています。
2120+しかし、XMLgawkとは違って、他言語の大半では、木構造をしたデータ構造へXMLファイルを写し、メモリに常駐させます。
2121+こうすることで、XMLファイルのあらゆるエレメントに対し望んだ順番で簡単にアクセスできるようになります。
2122+XMLgawkで行うような一度に一つずつ単に順番にアクセスする方法ではありません。
2123+@uref{news://comp.text.xml, comp.text.xml}ニューズグループにおいて、そういった言語のユーザの一人が、よくある問題を思い付き、その解決法を求めました。
2124+以下に示すXMLデータを読む際、構造的に似ているサブエレメントを運んでいる二つの@code{item}エレメントを報告してください。
2125+各@code{item}には、@code{PPrice}と@code{BCQuant}というサブエレメントがあって、@code{item}の価格と数量が入っています。
20032126 そのユーザは次のように尋ねました。
20042127
20052128 @example
2006-次のような XML があります。
2129+次のようなXMLがあります。
20072130
20082131 <?xml version="1.0" encoding="UTF-8"?>
20092132 <invoice>
@@ -2037,22 +2160,24 @@ XMLgawk でするような、一度に一つ順番にアクセスするという
20372160 @end example
20382161
20392162 彼の最後のセンテンスが全てを要約しています。
2040-彼は、@code{PPrice} と @code{BCQuant} とを掛けたものの足し算を実行して、@code{item} 全部の合計の費用を知りたいのです。
2041-彼はかけ算をする変数を Unix ファイルシステムでのファイル名に似た@emph{パス}を使って識別しています。
2163+彼は、@code{PPrice}と@code{BCQuant}を掛けたものの足し算を実行して、@code{item}全部の合計の費用を知りたいのです。
2164+彼は、Unixファイルシステムでのファイル名のような@emph{パス}を使って掛け算を行う変数を識別しています。
2165+
20422166 @example
20432167 /invoice/billitems/item/BCQuant * /invoice/billitems/item/PPrice
20442168 @end example
2045-これは、XML ドキュメントにおける変数の位置を示す方法としてかなり便利な方法です。
2046-プログラミング言語の中には、変数の位置を示すためにこの表記を直接ユーザに利用させるものもあります。
2047-こういった言語のユーザにとっては、XMLgawk での問題を取り組む方法へ、彼らの習慣を合わせることはしばしば難しいことです。
2048-XMLgawk では、変数へ直接アクセスするためにそのようなパスを使うことは@emph{できません}。
2049-しかし、XML ドキュメントの中でのその時点での位置をマッチするのに AWK のパターンの中でそのようなパスを使うことはできます。
2050-以下に示す解決策を見れば、XMLgawk でパスをどのように使うかが理解できるでしょう。
2051-理解するための重要なポイントは、現在注視している場所へのパスを常に保持している @code{XMLPATH} 変数が予め定義してあるということです。
2052-この解決策の一番最初の行は、@code{PPrice} 変数と @code{BCQuant}変数へのアクセスの基礎です。
2053-このスクリプトは、何らかのキャラクタデータが読み込まれるたびに、その内容を連想配列の @code{data} に置きます。
2054-このとき、その変数の@emph{パス}名を配列のインデックスとして利用します。
2055-この結果、この連想配列 @code{data} は、変数名 (@code{/invoice/billitems/item/BCQuant}) をその値 (@code{15}) へマップするようになりますが、それは、XML エレメントの @code{item} が一つ読まれている間の短い間だけのことです。
2169+
2170+これは、XMLドキュメントにおける変数の位置を示す方法としてかなり便利な方法です。
2171+プログラミング言語の中には、変数の位置を示すのに、この表記をユーザに直接利用させるものもあります。
2172+こういった言語のユーザにとっては、XMLgawkにおける問題を取り組む方法へと習慣を合わせるのは大抵難しいことです。
2173+XMLgawkでは、変数へ直接アクセスするのに上記のようなパスを使うことは@emph{できません}。
2174+しかし、XMLドキュメントの中でのその時点での位置をマッチするのに、AWKのパターンの中でそのようなパスを使うことはできます。
2175+以下に示す解決策を見れば、XMLgawkでパスを利用する方法が理解できるでしょう。
2176+理解するための重要なポイントは、現在注視している場所へのパスを常に保持している@code{XMLPATH}変数が予め定義してあるということです。
2177+この解決策の一番最初の行は、@code{PPrice}変数と@code{BCQuant}変数へのアクセスの基礎です。
2178+このスクリプトは、何らかのキャラクタデータが読み込まれるたびに、その内容を連想配列の@code{data}に置きます。
2179+この時、その変数の@emph{パス}名を、配列のインデックスとして利用します。
2180+この結果、この連想配列@code{data}は、変数名(@code{/invoice/billitems/item/BCQuant})をその値(@code{15})へマップするようになりますが、それは、XMLエレメントの@code{item}が一つ読まれている間の短い間だけのことです。
20562181
20572182 @example
20582183 @@load xml
@@ -2064,64 +2189,70 @@ XMLENDELEM == "item" @{
20642189 END @{ printf "Sum = %.3f\n",sum @}
20652190 @end example
20662191
2067-足し算は、@code{item} エレメントが一つ完全に読み込まれたときに毎回行なわれます。
2068-すなわち、@code{XMLENDELEM == "item" のときです。
2069-この時点で、数量と価格は @code{data} 配列の中に確実に保存されています。
2070-XML ドキュメントが完了すれば合計処理は終了し、やり残したことはその結果の表示だけになります。
2192+足し算は、@code{item}エレメントが一つ完全に読み込まれた時に毎回行われます。
2193+すなわち、@code{XMLENDELEM == "item"の時です。
2194+この時点で、数量と価格は、@code{data}配列の中に確実に保存されています。
2195+XMLドキュメントが完了すれば、合計処理は終了し、やり残したことはその結果の表示だけになります。
20712196
20722197 @cindex DOM, Document Object Model
20732198 @cindex XSL
2074-この単純なテクニック (ある値へのパスを @code{data[XMLPATH] = $0} でマッピングすること) は、@emph{木構造のどこかほかの場所にある}データへ@emph{後で}アクセスするための鍵となります。
2075-丸ごとの XML ドキュメントを木構造 (@uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM}) の中に格納してしまう XSL のような言語と、XMLgawk との微妙な違いに注意してください。
2076-XMLgawk では、ツリーの、ランダムアクセスに本当に必要な部分だけが高価なメモリに読み込まれます。
2077-ユーザが自分でそういう部分を識別して、明示的にデータを格納しないといけないということだけがこれの不便な点です。
2078-他の言語では、そういうデータの格納を (なんらコードを書くことなく) 暗黙のうちにやりますが、ユーザは、データストレージの粒度を管理することを放棄しました。
2079-
2080-詳細に分析すれば、このシンプルなアプローチに重大な制限があることをわかってしまうかもしれません。
2081-マークアップされたブロックの内部に他のタグが無いとき、そのブロック内のキャラクタデータに対してだけ働きます。
2082-言いかえれば、XML ツリーのノードが終端のノード (@ref{fig:docbook_chapter} と @ref{fig:dbfile} における 3、5、6、8、9、11、12 番のようなリーフノード) ときだけ、期待通りに @code{XMLPATH} の中に格納されます。
2083-XML ツリーの (2、4、7、10 番のような) @emph{非終端}のノードのキャラクタデータへのアクセスにも関心があれば、もう少し洗練されたアプローチが必要となります。
2199+この単純なテクニック(ある値へのパスを@code{data[XMLPATH] = $0}でマッピングすること)は、@emph{木構造のどこか他の場所にある}データへ@emph{後で}アクセスするための鍵となります。
2200+丸ごとのXMLドキュメントを木構造(@uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM})の中に格納してしまうXSLのような言語とXMLgawkとの微妙な違いに注意してください。
2201+XMLgawkでは、そのツリーのうち、ランダムアクセスに本当に必要な部分だけが高価なメモリに読み込まれます。
2202+そういう部分をユーザが自分で識別して、明示的にデータを格納しないといけないということだけがこれの不便な点です。
2203+他の言語においては、そういうデータの格納を(何等コードを書くことなく)暗黙のうちにやりますが、ユーザは、データストレージの粒度を管理することを放棄することになりました。
2204+
2205+詳細に分析すれば、このシンプルなアプローチに重大な制限があることが分かってしまうかもしれません。
2206+このアプローチは、マークアップされたブロック内部に他のタグが無い場合のそのブロック内のキャラクタデータに対してだけ働きます。
2207+言いかえれば、XMLツリーのノードが終端ノード(fig:docbook_chapter(@pxref{fig:docbook_chapter})とfig:dbfile(@pxref{fig:dbfile})における3、5、6、8、9、11、12番のようなリーフノード)の時だけ、期待通りに@code{XMLPATH}の中に格納されます。
2208+XMLツリーの(2、4、7、10番のような)@emph{非終端}ノードのキャラクタデータへのアクセスにも関心があるならば、もう少し洗練されたアプローチが必要となります。
2209+
20842210 @example
20852211 @@load xml
20862212 XMLSTARTELEM @{ delete data[XMLPATH] @}
20872213 XMLCHARDATA @{ data[XMLPATH] = data[XMLPATH] $0 @}
20882214 @end example
2089-重要な違いは、XML ツリーを通り抜けていく間、各非終端のノードのキャラクタデータブロックを連続して蓄積する最後の行です。
2090-同じ種類の別のノード (同じタグ名、@emph{兄弟ノード}) を読み始めた後だけ、蓄積されたキャラクタデータがクリアされます。
2091-クリアすることは実際必要ですが、さもなければ、同じ種類で同じ深さのノード全部のキャラクタデータが蓄積されてしまうでしょう。
2215+
2216+重要な違いは、XMLツリーを通り抜けていく間、各非終端のノードのキャラクタデータブロックを連続して蓄積する最後の行です。
2217+同じ種類の別のノード(同じタグ名、@emph{兄弟ノード})を読み始めた後だけ、蓄積されたキャラクタデータがクリアされます。
2218+クリアは実際必要です。
2219+そうしなければ、同じ種類で同じ深さのノード全部のキャラクタデータが蓄積されてしまうでしょう。
20922220 このような蓄積は望ましくないです。
2093-なぜなら、一つの @code{data[XMLPATH]} のキャラクタデータの内容が、一つのノードのテキストだけであることを期待しているのであって、同じネストレベルの他のノードのテキストは要らないからです。
2221+なぜなら、一つの@code{data[XMLPATH]}のキャラクタデータの内容が、一つのノードのテキストだけであることを期待しているのであって、同じネストレベルの他のノードのテキストは要らないからです。
20942222 しかし、もちろん、必要に応じてこの振舞いを変更するのは自由です。
20952223
2224+
20962225 @node Some Advanced Applications
20972226 @chapter いくつかの高度なアプリケーション
20982227
20992228 @menu
2100-* @file{xmlcopy.awk} ライブラリスクリプトを使ったコピーと修正::
2101-* RSS ニュースフィードの読み込み::
2102-* SOAP を経由したサービスの利用::
2103-* PostgreSQL への XML データのロード::
2104-* XML データからツリー図への変換::
2105-* サンプルファイルからの DTD の生成::
2106-* サンプルファイルからの再帰下降パーサの生成::
2107-* Microsoft Excel の XML ファイルに対するパーサ::
2229+* Copying and Modifying with the @file{xmlcopy.awk} library script::
2230+* Reading an RSS news feed::
2231+* Using a service via SOAP::
2232+* Loading XML data into PostgreSQL::
2233+* Converting XML data into tree drawings::
2234+* Generating a DTD from a sample file::
2235+* Generating a recursive descent parser from a sample file::
2236+* A parser for Microsoft Excel's XML file format::
21082237 @end menu
21092238
2110-前の @value{CHAPTER} とは異なり、この @value{CHAPTER} では、小さくない仕事をする完全なアプリケーションプログラムを実際に提供します。
2111-これらのタスクの複雑になった性質にも関わらず、これらのアプリケーションのいくつかのソースコードは 1 ページにまだ収まります。
2112-しかし、そのソースコードの大半は、二つ三つの部分に分けねばなりませんでした。
2239+前の@value{CHAPTER}とは異なり、この@value{CHAPTER}では、小さくない仕事をする完全なアプリケーションプログラムを実際に提供します。
2240+これらのタスクが複雑な性質を持つにも関わらず、こういったアプリケーションのソースコードには1ページに収まるものがまだあります。
2241+しかし、ソースコードの大半は、二三の部分に分けねばなりませんでした。
2242+
21132243
21142244 @node Copying and Modifying with the @file{xmlcopy.awk} library script
2115-@section @file{xmlcopy.awk} ライブラリスクリプトを使ったコピーと修正
2116-
2117-XML データは、インターネットで使用される HTML データと良く似ているように見えますので、伝統的に、インターネットアプリケーションと結びつけて考えられます。
2118-しかし、10 年以上使われた後、XML データのフォーマットというのが、それぞれさまざまな要求があるもっと多くの領域で便利であるということがわかってきました。
2119-たとえば、離れた場所で定期的に計測されるデータは、今日では、よく XML データとしてエンコードされています。
2120-それは、XML データによる読み易さの改善 (プロプライエタリのバイナリフォーマットとは対照的) だけでなく、ユーザにとって非常に快いタグ付けされた XML データの木構造ということもあります。
2121-もし、フォーマットにもう一つ計測値のデータタイプを加えたいならば、計測装置では、単に、 XML アトリビュートかもう一つのタグを XML データのツリーに追加するだけです。
2122-このデータを読み込むアプリケーションソフトウェアは、追加されたデータタイプを安全に無視することができ、@emph{新しい}データフォーマットをなお読み込むことができます。
2245+@section @file{xmlcopy.awk}ライブラリスクリプトを使ったコピーと修正
2246+
2247+XMLデータは、インターネットで使用されるHTMLデータと良く似ているように見えます。そのため、伝統的に、インターネットアプリケーションと結びつけて考えられます。
2248+しかし、10年以上使われた結果、XMLデータのフォーマットというのがさらに多くの領域で有用であるということが分かってきました。
2249+そういった領域には様々なニーズがあります。
2250+例えば、離れた場所で定期的に計測されるデータは、今日では、よくXMLデータとしてエンコードされています。
2251+それは、XMLデータによる読み易さの改善(プロプライエタリのバイナリフォーマットとは対照的)だけでなく、ユーザにとって非常に快いタグ付けされたXMLデータの木構造ということもあります。
2252+もし、計測値のデータタイプをフォーマットにもう一つ加えたいならば、計測装置で、XMLアトリビュートか別のタグをXMLデータのツリーに追加するだけです。
2253+このデータを読み込むアプリケーションソフトウェアは、追加されたデータタイプを安全に無視できますし、それでもなお、@emph{新しい}データフォーマットを読み込むことができます。
21232254 ここまでは良いのです。
2124-しかし、時には、ある装置が @ref{fig:remote_data.xml} にあるようなデータを私たちに送信してきます。
2255+しかし、時には、ある装置がfig:remote_data.xml(@pxref{fig:remote_data.xml})にあるようなデータを私たちに送信してきます。
21252256
21262257 @float Figure,fig:remote_data.xml
21272258 @pindex @file{remote_data.xml}
@@ -2143,36 +2274,39 @@ XML データは、インターネットで使用される HTML データと良
21432274 </MONITORINGSTATION>
21442275 </MONITORINGSTATIONS>
21452276 @end example
2146-@caption{遠隔地で計測されたデータが入った @file{remote_data.xml} ファイル}
2277+@caption{遠隔地で計測されたデータが入った@file{remote_data.xml}ファイル}
21472278 @end float
21482279
2149-このデータをざっと読んでみれば、異常に見えるところが 3 箇所見つかるかもしれません。
2280+このデータをざっと読んでみれば、異常に見えるところが3箇所見つかるでしょう。
2281+
21502282 @itemize
2151-@item @b{NAME} タグの内部、CATALU@math{\tilde{N}}A の中のチルダが付いた大文字の N。
2152-@item @b{LON} タグの内部、浮動小数点数で小数点として使われるカンマ。
2153-@item @b{PARAMETER} タグの内部、@emph{&#xB5;} としてエンコードされている @math{\mu} シンボル。
2283+@item @b{NAME}タグの内部、CATALU@math{\tilde{N}}Aの中のチルダが付いた大文字のN。
2284+@item @b{LON}タグの内部、浮動小数点数で小数点として使われるカンマ。
2285+@item @b{PARAMETER}タグの内部、@emph{&#xB5;}としてエンコードされている@math{\mu}シンボル。
21542286 @end itemize
21552287
2156-私たちに必要なのは、木構造には触れないまま、この XML データのこういった奇抜な部分を修正するスクリプトです。
2288+私たちに必要なのは、木構造には触れないまま、このXMLデータのこういった奇抜な部分を修正するスクリプトです。
21572289 正確に言うと、次のようなスクリプトが必要です。
2290+
21582291 @itemize
21592292 @item ファニーな@emph{特殊文字}を全部、必要な文字エンコーディングへ変換する。
2160-@item @b{LON} タグの内側の数値だけ、カンマを小数点に置き換える。
2161-@item その他すべては、元の XML データにあった字面通りコピーする。
2293+@item @b{LON}タグの内側の数値だけ、カンマを小数点に置き換える。
2294+@item その他すべては、元のXMLデータにあった字面通りコピーする。
21622295 @end itemize
2163-@cindex 文字エンコーディング
2164-
2165-@ref{fig:modify.awk} に解決策の一つを見ることができます。
2166-それは、@file{xmlcopy.awk} という名前のライブラリスクリプトをインクルードする include ステートメントで始まります。
2167-2 行目では、データを読み始める前に望ましい文字エンコーディングを設定します。
2168-これは見てすぐわかります。
2169-しかし、なぜ、エンコーディング名 (@command{"ISO-8859-1"}) が @command{XMLATTR["ENCODING"]} 変数の中にコピーされるのでしょうか?
2170-@command{XMLATTR["ENCODING"]} が@emph{入力}データのエンコーディングを反映していることと、この読み取り専用の変数をオーバーライトしても無駄だということは、@ref{キャラクタデータと文字セットのエンコーディング}で学びませんでしたか?
2171-そのことは真実で、@command{xgawk} インタプリタは、@command{XMLATTR["ENCODING"]} の中に書き込んだものを単に無視します。
2172-しかし、すぐ、ライブラリスクリプト内部の関数がこの@emph{偽エンコーディング}の変数を評価することがわかるでしょう。
2173-スクリプトの 4 行目は、またもや見てすぐわかります。
2174-@b{LON} タグのキャラクタデータの内部で、カンマが小数点に置き換えられます。
2175-そして最後、一番下の行には @command{XmlCopy()} 関数の起動が書かれています。
2296+@cindex character encoding
2297+
2298+fig:modify.awk(@pxref{fig:modify.awk})に解決策の一つがあります。
2299+このスクリプトは、@file{xmlcopy.awk}という名前のライブラリスクリプトをインクルードするincludeステートメントで始まります。
2300+2行目では、データを読み始める前に、望ましい文字エンコーディングを設定します。
2301+これは見てすぐ分かります。
2302+しかし、なぜ、エンコーディング名(@command{"ISO-8859-1"})が@command{XMLATTR["ENCODING"]}変数の中にコピーされるのでしょうか。
2303+@command{XMLATTR["ENCODING"]}が@emph{入力}データのエンコーディングを反映していることと、この読み取り専用の変数をオーバーライトしても無駄だということは、別の節(@pxref{Character data and encoding of character sets})で学んだと思います。
2304+そのことは真実です。
2305+@command{xgawk}インタプリタは、@command{XMLATTR["ENCODING"]}の中に書き込んだものを単に無視します。
2306+しかし、すぐ、ライブラリスクリプト内部の関数が、この@emph{偽エンコーディング}の変数を評価することが分かるでしょう。
2307+スクリプトの4行目は、またもや見てすぐ分かります。
2308+@b{LON}タグのキャラクタデータの内部で、カンマが小数点に置き換えられます。
2309+そして、最後、一番下の行には@command{XmlCopy()}関数の起動が書かれています。
21762310
21772311 @float Figure,fig:modify.awk
21782312 @pindex @file{modify.awk}
@@ -2184,22 +2318,23 @@ XMLATTR["VERSION"] @{ XMLATTR["ENCODING"] = XMLCHARSET @}
21842318 XMLCHARDATA && XMLPATH ~ /\/LON$/ @{ gsub(",", ".") @}
21852319 @{ XmlCopy() @}
21862320 @end example
2187-@caption{XML データを少し修正する @file{modify.awk} スクリプト}
2321+@caption{XMLデータを少し修正する@file{modify.awk}スクリプト}
21882322 @end float
21892323
2190-偽エンコーディング名の評価し全部をコピーするというマジックは、全てライブラリスクリプトの内部で行なわれます。
2191-ちょうど@ref{XMLgawk のポータブルサブセット}で説明した @file{getXMLEVENT.awk} のように、このライブラリスクリプトは以下の場所のいずれかで見つけることができるでしょう。
2324+偽エンコーディング名の評価し全部をコピーするというマジックは、全てライブラリスクリプトの内部で行われます。
2325+ちょうど別の節(@pxref{A portable subset of XMLgawk})で説明した@file{getXMLEVENT.awk}のように、このライブラリスクリプトは以下の場所のいずれかで見つけることができるでしょう。
21922326
21932327 @itemize
2194-@item @code{xgawk} の配布ファイルの @file{awklib/xml} ディレクトリの中にコピーがあります。
2195-@item ホストマシンに @code{xgawk} が既にインストールされていれば、共有ソースのディレクトリの中にファイルのコピーがあるはずです (GNU/Linux マシンの @code{/usr/share/awk} のような場所に普通あります)。
2328+@item @code{xgawk}の配布ファイルの@file{awklib/xml}ディレクトリの中にコピーがあります。
2329+
2330+@item ホストマシンに@code{xgawk}が既にインストールされていれば、共有ソースのディレクトリの中にファイルのコピーがあるはずです(GNU/Linuxマシンの@code{/usr/share/awk}のような場所に普通あります)。
21962331 @end itemize
21972332
2198-@file{xmlcopy.awk} ライブラリスクリプトのコピーを少し見てみてください。
2199-このスクリプトは @command{XmlCopy()} 関数の宣言以外は何も入っていないことに注意してください。
2333+@file{xmlcopy.awk}ライブラリスクリプトのコピーを少し見てみてください。
2334+このスクリプトは、@command{XmlCopy()}関数の宣言以外は何も入っていないことに注意してください。
22002335 また、この関数は、データに対する全ての操作が終了したあとにだけ呼びだされることにも注意してください。
2201-実行が成功したときの結果は、@ref{fig:modify.xml} で見ることができます。
2202-入力ファイルがオープンされた直後、@code{DECLARATION} 型の @code{XMLEVENT} が起動しますが、入力データに宣言が含まれていないために @code{XMLATTR["ENCODING"]} 変数はセットされていません。
2336+実行が成功した時の結果は、fig:modify.xml(@pxref{fig:modify.xml})で見ることができます。
2337+入力ファイルがオープンされた直後、@code{DECLARATION}型の@code{XMLEVENT}が起動しますが、入力データに宣言が含まれていないために@code{XMLATTR["ENCODING"]}変数はセットされていません。
22032338 [未翻訳]
22042339 That's the place where our script in @ref{fig:modify.awk} comes in and sets
22052340 the declaration in the right moment. So, the @command{XmlCopy()} function
@@ -2229,48 +2364,51 @@ gawk -f modify.awk remote_data.xml
22292364 @caption{The output data of @file{modify.awk} is slightly modified}
22302365 @end float
22312366
2367+
22322368 @node Reading an RSS news feed
2233-@section RSS ニュースフィードの読み込み
2369+@section RSSニュースフィードの読み込み
2370+
22342371 インターネットはニュースデータの便利なソースです。
2235-ほとんど常に、私たちは、HTTP プロトコルで転送されてきた HTML ファイルを読むためにブラウザを使っています。
2236-しかし時々、手元にブラウザが無いことがあったり、すぐにニュースデータを見える状態にする必要が無かったりということがあります。
2372+HTTPプロトコルで転送されてきたHTMLファイルを読むため、ほとんど常に私たちはブラウザを使っています。
2373+しかし、手元にブラウザが無いことがあったり、ニュースデータを見える状態にすぐにする必要が無かったりということがあります。
22372374 非常に小さいウィンドウでニュース見出しを表示するニュースティッカーというのが一例です。
22382375 こういう場合のため、ニュース専用のフォーマットが作られました。
2239-@uref{http://www.rss-specifications.com, RSS format} です。
2240-このデータを転送するプロトコルは HTTP のままですが、その内容はもはや HTML ではありません。
2241-しかし、単純な構造の XML です (例 @pxref{fig:rss_inq})。
2242-この例のルートノードは、RSS 仕様書のバージョン 0.91 に従ったデータ構造であることを示しています。
2243-ノード番号の 2 は、このニュースのチャンネルを識別します。
2244-また、子ノードの 3、4、5 番で拡張されていて、その子ノードにはニュースソースのタイトル、リンク、説明が入っています。
2376+@uref{http://www.rss-specifications.com, RSS format}です。
2377+このデータを転送するためのプロトコルはHTTPのままですが、転送する内容はもはやHTMLではありません。
2378+しかし、単純な構造のXMLです(一例がfig:rss_inq(@pxref{fig:rss_inq})です)。
2379+この例におけるルートノードは、RSS仕様書のバージョン0.91に従ったデータ構造であることを示しています。
2380+ノード番号の2は、このニュースのチャンネルを識別します。
2381+また、子ノードの3、4、5番で拡張されていて、そのノードにはニュースソースのタイトル、リンク、説明が入っています。
22452382 しかし、私たちはこれらには関心が無くて、各ニュースアイテムのタイトルに関心があります。
2246-そして、そのタイトルは、ノード 6 のようなノードが並んだものの中に入っています (ここでは一つしか描かれていませんけれども)。
2383+そして、そのタイトルは、ノード6のようなノードが並んだものの中に入っています(ここでは一つしか描かれていませんけれども)。
22472384
22482385 @cindex HTTP
22492386 @cindex HTML
22502387 @cindex RSS, Really Simple Syndication or Rich Site Summary
22512388 テキストの出力として欲しいものは、ニュースタイトルの短かいリストです。
2252-すなわち、@ref{fig:table_inq} にあるように、それは番号付けがされ、タイトルがあって、リンクがあるものです。
2253-全ノードをトラバースしながら、それぞれのニュースアイテムのデータを収集するのはどうすればいいでしょうか?
2254-そして、一つのデータを拾い終わって、表示する準備ができるのはいつか、ということを知るにはどうすればいいでしょうか?
2255-考え方は、ノード 6 のようなアイテムが終るのを待つことです。
2256-ツリーは深さ優先でパースされるので、(@code{XMLENDELEM == "item"} というパターンが (アクションを) トリガーする時、ノード 6 の子ノードである ノード 7 と 8 は既にパースされてしまっていることに注意してください。
2257-ノード 7 と 8 の中の最新のデータは、表示すべきタイトルとリンクが入っています。
2258-@emph{もっと早い段階で既にトラバースされてしまったノードのデータにアクセスするにはどうするのか?}と尋ねられるかもしれません。
2259-その答えは、前もってテキストデータを保存しておくということです (XMLCHARDATA がトリガーする時にです)。
2260-その時、保存されているデータがタイトルなのかリンクなのかについてはまだわかりません。
2261-しかし、@code{XMLENDELEM == "title"} がトリガーすれば、そのときのそのデータがタイトルであることがわかりますので、それをそのように記憶することができます。
2262-これが複雑に感じられるということと、AWK あるいはイベントベースのプログラミングにおけるもっと重要な知識を、あなたが理解する必要が明らかにあるということを私はわかっています。
2263-
2264-これらの説明で混乱してしまっているのならば、今ぶつぶつ述べたことが全部、たった 4 行のコード (@code{while} ループの内側) の中に収まっているということを見れば愉快な気持になれるでしょう。
2265-この 4 行がツリーからニュースアイテムを全て選択して、しかもノード 3、4、5 を無視するのに十分だということに少し驚きます。
2266-ノード 3、4、5 番を無視することをどうやって実現しているのでしょうか?
2389+すなわち、fig:table_inq(@pxref{fig:table_inq})にあるように、番号付けがされ、タイトルがあって、リンクがあるものです。
2390+全ノードをトラバースしながら、それぞれのニュースアイテムのデータを収集するのはどうすればいいでしょうか。
2391+そして、一つのデータを拾い終わって、表示する準備ができるのはいつか、ということを知るにはどうすればいいでしょうか。
2392+考え方としては、ノード6のようなアイテムが終るのを待つことです。
2393+ツリーは深さ優先でパースされるので、(@code{XMLENDELEM == "item"}というパターンが(アクションを)トリガーする時、)ノード6の子ノードであるノード7とノード8は既にパースされてしまっていることに注意してください。
2394+ノード7とノード8の中の最新のデータは、表示すべきタイトルとリンクが入っています。
2395+@emph{それ以前の段階で既にトラバースされてしまったノードのデータにアクセスするにはどうするのか、}と思うかもしれません。
2396+その答えは、テキストデータを前もって保存しておくということです(XMLCHARDATAがトリガーする時にです)。
2397+その時、保存されているデータがタイトルなのかリンクなのかについてはまだ分かりません。
2398+しかし、@code{XMLENDELEM == "title"}がトリガーすれば、その時のそのデータがタイトルであることが分かりますので、そのように記憶することができます。
2399+これが複雑に感じられるということは分かります。
2400+また、理解するのに、AWK、あるいは、イベントベースのプログラミングにおける先行経験が確実に必要であるということも分かります。
2401+
2402+これらの説明で混乱してしまっているのならば、今ぶつぶつ述べたこと全部が、たった4行のコード(@code{while}ループの内側)の中に収まっているということを見れば、愉快な気持になれるでしょう。
2403+ツリーからニュースアイテムを全て選択して、しかもノード3、4、5を無視するのに、この4行で十分だということに少し驚きます。
2404+ノード3、4、5番を無視することをどうやって実現しているのでしょうか。
22672405 そうですね、実のところ無視しているわけではありません。
2268-@code{title} ノードと @code{link} ノードですが、その内容は @code{data} 変数へ保存されます。
2269-しかし、表示は @code{item} タイプのノードを離れるときにだけ発生しますので、ノード 3 と 4 の内容は決して表示されません。
2406+@code{title}ノードと@code{link}ノードですが、その内容は@code{data}変数へ保存されます。
2407+しかし、@code{item}タイプのノードを離れる時にだけ表示が発生しますので、ノード3と4の内容は決して表示されません。
22702408
22712409 @float Figure,fig:rss_inq
2272-@image{rss_inq,,,RSS ニューズフィードの XML データのノード構造の例,}
2273-@caption{RSS ニューズフィードの XML データのノード構造の例}
2410+@image{rss_inq,,,RSSニューズフィードのXMLデータのノード構造の例,}
2411+@caption{RSSニューズフィードのXMLデータのノード構造の例}
22742412 @end float
22752413
22762414 @float Figure,fig:table_inq
@@ -2282,17 +2420,18 @@ gawk -f modify.awk remote_data.xml
22822420 5. US to take over the entire Internet http://www.theinquirer.net/?article=18975
22832421 6. AMD 90 nano shipments 50% by year end http://www.theinquirer.net/?article=18974
22842422 @end smallexample
2285-@caption{RSS ニュースフィードのニュースタイトル}
2423+@caption{RSSニュースフィードのニュースタイトル}
22862424 @end float
22872425
2288-結局、この XML ファイルのトラバースが最も簡単な部分であるということがわかります。
2289-インターネットからこのファイルを取得することは、もう少し複雑です。
2290-インターネットから取得するニュースデータが、@uref{http://www.theinquirer.net/inquirer.rss, rumour mill} を離れて流れて来たホヤホヤの時点で XML データとして扱うことができたら素晴しかったでしょう。
2291-しかし残念ながら、この XML データにはヘッダが付いてきます。
2292-そのヘッダは XML の規則に従っていません -- つまり HTTP ヘッダです。
2293-ですので、まずその HTTP ヘッダを飲み込んでしまわないといけません。
2294-それから、ASCII の行としてそのニュースフィードから行を全て読み込んで、一時ファイルに保存しなければいけません。
2295-その一時ファイルをクローズした後は、そのファイルを XML ファイルとして再オープンして、前述したようにニュースのノードをトラバースすることができます。
2426+結局、XMLファイルのトラバースが最も簡単な部分であるということが分かります。
2427+インターネットからこのファイルを取得するのはもう少し複雑です。
2428+インターネットから取得するニュースデータが、@uref{http://www.theinquirer.net/inquirer.rss, rumour mill}を離れて流れて来たホヤホヤの時点でXMLデータとして扱うことができたら素晴しかったでしょう。
2429+しかし、残念ながら、このXMLデータにはヘッダが付いてきます。
2430+そのヘッダはXMLの規則に従っていません。
2431+つまり、HTTPヘッダです。
2432+ですから、まず、そのHTTPヘッダを飲み込んでしまわないといけません。
2433+それから、ニュースフィードからASCIIの行として行を全て読み込んで、一時ファイルに保存しなければいけません。
2434+その一時ファイルをクローズした後は、そのファイルをXMLファイルとして再オープンして、前述したように、ニュースのノードをトラバースすることができます。
22962435
22972436 @pindex @file{get_rss_feed.awk}
22982437 @example
@@ -2340,91 +2479,93 @@ BEGIN @{
23402479 @}
23412480 @end example
23422481
2343-RSS ニュースフィードからのデータについてもっと詳しい情報は、@uref{http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html, @emph{What is RSS}} という素晴しい記事がありますので、そこで読むことができます。
2344-詳細について深く掘り下げていくと、いずれも RSS と自らのことを呼ぶがその内容は異なっている似たような構造定義が多数存在することがわかるでしょう。
2345-上記の私たちのスクリプトは、このスクリプトが種々の RSS リソースを全て理解できるということが確実になるように書きましたが、これは細かい部分を無視するという犠牲を払ってやっと達成することができました。
2482+RSSニュースフィードのデータについてもっと詳しい情報は、@uref{http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html, @emph{What is RSS}}という素晴しい記事がありますので、そこで読むことができます。
2483+詳細について深く掘り下げていくと、いずれもRSSと自称するが、その内容が異なっている似たような構造定義が多数存在することが分かるでしょう。
2484+上記のスクリプトは、種々のRSSリソースを確実に全て解釈できるように書きましたが、これは、細かい部分を無視するという犠牲を払ってやっと達成することができました。
23462485
2347-RSS フィードにはもう一つ問題があります。
2486+RSSフィードにはもう一つ問題があります。
23482487 @cindex Yahoo
2349-たとえば、Yahoo も RSS のニュースフィードを提供しています。
2350-しかし、これを取得するために上記のスクリプトを使った場合、Yahoo は正しい XML データではなく HTML データを送信します。
2351-これは、RSS の標準が正しく定義されていなくて、Yahoo の HTTP サーバが RSS データに対するリクエストを理解していないために起こることです。
2488+例えば、Yahooも、RSSのニュースフィードを提供しています。
2489+しかし、これを取得するために上記のスクリプトを使った場合、Yahooは正しいXMLデータではなくHTMLデータを送信します。
2490+これは、RSSの標準が正しく定義されていなくて、YahooのHTTPサーバがRSSデータに対するリクエストを理解していないために起こることです。
2491+
23522492
23532493 @node Using a service via SOAP
2354-@section SOAP を経由したサービスの利用
2494+@section SOAPを経由したサービスの利用
23552495 @cindex SOAP, Simple Object Access Protocol
23562496 @cindex HTTP
23572497
2358-@ref{RSS ニュースフィードの読み込み}で、インターネット上のシンプルなサービスをどのように使うことができるかを見ました。
2359-そのサービスに対するリクエストは、サービスの名前をともなった一つの行でした。
2360-サーバからのレスポンスだけが XML データで出来ていました。
2361-リクエスト自体に、改行を含むテキストデータとか外国の文字記号を含んだりして、様々なタイプの複数のパラメータが入っているとしたらどうでしょうか?
2362-Yahoo の株式相場のような古典的なサービスの場合は、HTTP リクエストの @code{GET} 行にパラメータを追加することで多数のパラメータを渡す方法を見つけました。
2363-実践により、過度に長い @code{GET} 行は (容認できるような) @emph{awk} 風では無いだけでなく、オブジェクト指向サービスが必要とされた時には不十分であるということがわかっています。
2364-オブジェクト指向サービスのクリーンな実装の必要性は、@uref{http://www.w3.org/TR/soap, SOAP protocol} の考案の背後にある動機でした。
2365-一行の中にリクエストパラメータを押し込めてしまう代わりに、XML エンコードされたデータを、SOAP サービスへパラメータを渡す方法として利用します。
2366-SOAP でも、転送には HTTP を依然使いますが、そのパラメータは、HTTP の @code{POST} メソッドで転送されます (@code{POST} メソッドは、@code{GET} とは異なり、リクエストの本体部分を使ってデータを渡すことができます)。
2367-
2368-この @value{SECTION} では SOAP サービスのクライアントを書きます。
2369-インターネット上では、@uref{http://xmethods.net/ve2/ViewClient.po?clientid=261249, Barnes & Noble Price Quote service} の非常に短い正式な説明を見ることができます。
2498+前節(@pxref{Reading an RSS news feed})で、インターネット上のシンプルなサービスをどのように使うことができるかを見ました。
2499+そのサービスに対するリクエストは、サービスの名前を伴った一つの行でした。
2500+サーバからのレスポンスだけがXMLデータで出来ていました。
2501+リクエスト自体に、改行を含むテキストデータとか外国の文字記号を含んだりして、様々なタイプの複数のパラメータが入っているとしたらどうでしょうか。
2502+Yahooの株式相場のような古典的なサービスの場合は、HTTPリクエストの@code{GET}行にパラメータを追加することで多数のパラメータを渡す方法を見つけました。
2503+過度に長い@code{GET}行は(容認できるような)@emph{awk}風では無いだけでなく、オブジェクト指向サービスが必要とされた時には不十分であるということが実践により分かっています。
2504+オブジェクト指向サービスのクリーンな実装の必要性は、@uref{http://www.w3.org/TR/soap, SOAP protocol}の考案の背後にある動機でした。
2505+リクエストパラメータを一行に押し込めてしまう代わりに、XMLエンコードされたデータを、SOAPサービスへパラメータを渡す方法として利用します。
2506+SOAPでも転送にはHTTPを依然使いますが、そのパラメータは、HTTPの@code{POST}メソッドで転送されます(@code{POST}メソッドは、@code{GET}とは異なり、リクエストの本体部分を使ってデータを渡すことができます)。
2507+
2508+この@value{SECTION}ではSOAPサービスのクライアントを記述します。
2509+インターネット上では、@uref{http://xmethods.net/ve2/ViewClient.po?clientid=261249, Barnes & Noble Price Quote service}の非常に短い正式な説明を見ることができます。
23702510 @cindex Barnes & Noble Price Quote
2371-ユーザは、このサービスに対して書籍の ISBN コードを送信することができます。
2372-そして、サービスはその本の価格が記載された何らかの XML データを返します。
2373-この事例のサービスは、パラメータが一つだけ必要で、それゆえ、SOAP と XML 無しで実装すべきであるという主張をされるかもしれません。
2374-それはその通りなのですが、この SOAP の実装は、操作の基本的な原則を示すには十分良いのです。
2375-もしあなたが納得していなくて、リクエストとともに構造化したデータを渡すことができる SOAP の能力を乱用するサービスを選ぶというのであれば、インターネット上のリストを一つ見てみるとよいでしょう。
2376-そこには多くの @uref{http://xmethods.net, publicly available SOAP services} が存在しています。
2511+ユーザは、このサービスに対して書籍のISBNコードを送信することができます。
2512+そして、サービスは、その本の価格が記載された何らかのXMLデータを返します。
2513+この事例のサービスは、パラメータが一つだけ必要で、それゆえ、SOAPとXML無しで実装すべきであるという主張をされるかもしれません。
2514+それはその通りなのですが、このSOAPの実装は、操作の基本的な原則を示すには十分良いのです。
2515+もし、納得できなくて、リクエストとともに構造化したデータを渡すことができるSOAPの能力を乱用するサービスを選ぶというのであれば、インターネット上のリストを一つ見てみるとよいでしょう。
2516+そこには、多くの@uref{http://xmethods.net, publicly available SOAP services}が存在しています。
23772517 このページを訪問することをお勧めします。
2378-そこで見ることができるものには、本当に啓発されます。
2379-もっと複雑なサービスの内部動作に関心がある人は、リストにある実例のサービスの @emph{Try It} というリンクをクリックしてみるべきでしょう。
2380-@emph{Try It} リンクの向こうには、SOAP リクエストのためのある種のデバッガがあって、リクエストとレスポンスの内容が、疑似コードや生データ、ツリー、あるいは対話的な XML 表示で示されています。
2381-私はこの @emph{SOAPscope} で多くのことを学びました。
2518+そこで見ることができるものには、本当に教えられます。
2519+もっと複雑なサービスの内部動作に関心がある人は、リストにある実例サービスの@emph{Try It}というリンクをクリックしてみるべきでしょう。
2520+@emph{Try It}リンクの向こうには、SOAPリクエストのためのある種のデバッガがあって、リクエストとレスポンスの内容が、疑似コードや生データ、ツリー、あるいは、対話的なXML表示で示されています。
2521+私は、この@emph{SOAPscope}で多くのことを学びました。
23822522 @cindex SOAPscope.
23832523
2384-Barnes & Noble Price Quote サービスの作者 (Mustafa Basgun) は、この彼のサービスのクライアントも書きました。
2385-インターネット上のある素晴しい記事の中で、この作者は、@emph{Flash MX} を活用しながら、どのように @uref{http://www.devmx.com/articles.cfm?Mode=Article&c=6&a=8, GUI-based client interface} を実装したのかを説明しています。
2524+Barnes & Noble Price Quoteサービスの作者(Mustafa Basgun)は、このサービスのクライアントも書きました。
2525+インターネット上のある素晴しい記事の中で、この作者は、@emph{Flash MX}を活用しながら、どのように@uref{http://www.devmx.com/articles.cfm?Mode=Article&c=6&a=8, GUI-based client interface}を実装したのかを説明しています。
23862526 この記事から以下を引用します。
2387-これは、SOAP とは何であるかについて幾分か詳しく説明しています。
2527+これは、SOAPとは何であるかについて幾分か詳しく説明しています。
23882528
23892529 @quotation
2390-Simple Object Access Protocol (SOAP) は非集中分散環境での情報交換のための軽量プロトコルです。
2391-XML ベースのプロトコルで、三つの部分から構成されます。
2392-一つめは、メッセージの中にあるものは何なのか、そしてそれをどう処理するのかを記述するためのフレームワークを定義するエンベロープ。
2393-二つめは、アプリケーションが定義したデータタイプのインスタンスを表現するエンコーディングの規則のセット。
2530+Simple Object Access Protocol(SOAP)は、非集中分散環境での情報交換のための軽量プロトコルです。
2531+XMLベースのプロトコルで、三つの部分から構成されます。
2532+一つ目の部分は、メッセージの中にあるものは何なのか、そして、それをどう処理するのかを記述するためのフレームワークを定義するエンベロープです。
2533+二つ目の部分は、アプリケーションが定義したデータタイプのインスタンスを表現するエンコーディングの規則のセットです。
23942534 最後は、リモートプロシージャの呼び出しとレスポンスのための取り決めです。
23952535 @end quotation
23962536
23972537 @cindex Schema
2398-彼が述べている部分は全て @ref{fig:soap_request} にある例の中に見ることができます。
2399-この例は、XML フォーマットの SOAP リクエストを (縮退させたツリーとして) 図示したものを示しています。
2400-ルートノードが引用の中で述べられているエンベロープです。
2401-この XML データ (スキーマとエンコーディング) をどのように処理するかについての詳細は、ルートノードのアトリビュートに宣言されています。
2402-ノードの 4 番のキャラクタデータにある ISBN コードを持つ本の価格を取得するのに使うリモートプロシージャコールの @code{getPrice} がノードの 3 番に入っています。
2403-ノードの 4 番は、ISBN 自体が入っているだけでなく、リモートプロシージャの @code{getPrice} へ渡されるパラメータ (ISBN であるもの) のデータ型 @code{xs:string} も宣言しています。
2538+彼が述べている部分は、fig:soap_request(@pxref{fig:soap_request})にある例の中に全て見ることができます。
2539+この例は、XMLフォーマットのSOAPリクエストを(縮退させたツリーとして)図示したものを示しています。
2540+ルートノードが、引用の中で述べられているエンベロープです。
2541+このXMLデータ(スキーマとエンコーディング)をどのように処理するかについての詳細は、ルートノードのアトリビュートに宣言されています。
2542+ノードの4番のキャラクタデータにあるISBNコードを持つ本の価格を取得するのに使うリモートプロシージャコールの@code{getPrice}がノードの3番に入っています。
2543+ノードの4番は、ISBN自体が入っているだけでなく、リモートプロシージャの@code{getPrice}へ渡されるパラメータ(ISBNであるもの)のデータ型@code{xs:string}も宣言しています。
24042544
24052545 @float Figure,fig:soap_request
2406-@image{soap_request,,,SOAP フォーマットでの本の価格のリクエスト,}
2407-@caption{SOAP フォーマットでの本の価格のリクエスト}
2546+@image{soap_request,,,SOAPフォーマットでの本の価格のリクエスト,}
2547+@caption{SOAPフォーマットでの本の価格のリクエスト}
24082548 @end float
24092549
2410-SOAP クライアントのコーディングを始める前に、このリクエストに対するレスポンスがどのように見えるのかを調べなければなりません。
2411-@ref{fig:soap_reply} にあるツリーは、レスポンスとして来る XML データで、本の価格を探すときにトラバースしなければならないものです。
2412-正しいクライアントは完全にツリーを解析して、出てきたノードの型に対して注意を払うでしょう。
2413-@ref{fig:soap_reply} の構造は、リクエストが成功した時にだけ返されるでしょう。
2414-もしリクエストが失敗していたならば、失敗を示す違う種類のノードに直面することになるでしょう。
2415-レスポンスが静的な数字や文字列ではなく、内容が変化するツリーであるということは SOAP の利点の一つです。
2416-エラーメッセージは、わけのわからないやり方でただ番号付けされるのでは無く、特定のタグ名と、何が問題なのかを説明するキャラクタデータを含む XML エレメントとしてやってきます。
2417-しかし、私たちは今、ノードの 4 番 (@code{return} タグ) が @code{xsd:float} という型で、キャラクタデータとして本の価格が入っているという成功のケースだけに関心があります。
2550+SOAPクライアントのコーディングを始める前に、このリクエストに対するレスポンスがどのように見えるのかを調べなければなりません。
2551+fig:soap_reply(@pxref{fig:soap_reply})にあるツリーはレスポンスとして来るXMLデータです。
2552+本の価格を探す時にトラバースしなければならないものです。
2553+正しいクライアントならば、完全にツリーを解析して、出てきたノードの型に対して注意を払います。
2554+fig:soap_reply(@pxref{fig:soap_reply})の構造は、リクエストが成功した時にだけ返されます。
2555+もし、リクエストが失敗していたならば、失敗を示す違う種類のノードに直面することになるでしょう。
2556+レスポンスが静的な数字や文字列ではなく、内容が変化するツリーであるということはSOAPの利点の一つです。
2557+エラーメッセージは、訳の分からないやり方でただ番号付けされるのでは無く、特定のタグ名と、何が問題なのかを説明するキャラクタデータを含むXMLエレメントとしてやってきます。
2558+しかし、今は、ノードの4番(@code{return}タグ)が@code{xsd:float}という型で、キャラクタデータとして本の価格が入っているという成功のケースだけに関心があります。
24182559
24192560 @float Figure,fig:soap_reply
2420-@image{soap_reply,,,SOAP フォーマットでの本の価格のリクエストに対するレスポンス,}
2421-@caption{SOAP フォーマットでの本の価格のリクエストに対するレスポンス}
2561+@image{soap_reply,,,SOAPフォーマットでの本の価格のリクエストに対するレスポンス,}
2562+@caption{SOAPフォーマットでの本の価格のリクエストに対するレスポンス}
24222563 @end float
24232564
2424-@ref{fig:soap_book_price_quote.awk} にある SOAP クライアントの最初の部分は、先の RSS クライアントと非常によく似ています。
2425-@code{isbn} はコマンドラインからパラメータとして渡される一方、@code{host} 名とサービス識別子の @code{soap} は固定されています。
2426-@code{response} 変数を見れば、@ref{fig:soap_request} からのツリーがわかります。
2427-@code{isbn} だけ固定されていませんが、SOAP サーバへ後で送信される XML データの中に変数として挿入されます。
2565+fig:soap_book_price_quote.awk(@pxref{fig:soap_book_price_quote.awk})にあるSOAPクライアントの最初の部分は、先のRSSクライアントと非常によく似ています。
2566+@code{isbn}が、コマンドラインからパラメータとして渡される一方、@code{host}名とサービス識別子の@code{soap}は固定されています。
2567+@code{response}変数を見れば、fig:soap_request(@pxref{fig:soap_request})からのツリーが分かります。
2568+@code{isbn}だけ固定されていませんが、SOAPサーバへ後で送信されるXMLデータの中に変数として挿入されます。
24282569
24292570 @float Figure,fig:soap_book_price_quote.awk
24302571 @pindex @file{soap_book_price_quote.awk}
@@ -2459,22 +2600,25 @@ BEGIN @{
24592600 </soap:Body> \
24602601 </soap:Envelope>"
24612602 @end example
2462-@caption{SOAP リクエストを組み立てる @file{soap_book_price_quote.awk} の最初の部分}
2603+@caption{SOAPリクエストを組み立てる@file{soap_book_price_quote.awk}の最初の部分}
24632604 @end float
24642605
2465-SOAP クライアントの 2 番目と 3 番目の部分は、さらに RSS クライアントと似ています。
2606+SOAPクライアントの2番目と3番目の部分は、RSSクライアントとさらに似ています。
24662607 しかし、もっと念入りに比べてみれば、いくつか興味深い違いが見つかるでしょう。
24672608 次のようなものです。
2609+
24682610 @itemize
24692611 @item
2470-@code{ORS} 変数がもう使われていません。
2471-ここではヘッダ行を違うやり方で処理している。
2612+@code{ORS}変数がもう使われていません。
2613+ここでは、ヘッダ行を違うやり方で処理しています。
2614+
24722615 @item
2473-ヘッダそのものは今は HTTP の @code{POST} メソッドで始まっていて、@code{GET} メソッドではありません。
2616+ヘッダそのものは、今は、HTTPの@code{POST}メソッドで始まっていて、@code{GET}メソッドではありません。
2617+
24742618 @item
24752619 送信されるヘッダが多くなっています。
2476-たいていの SOAP サービスは、クライアントがコンテントタイプとコンテント長を指定するように求めています。
2477-そういったサービスをホスティングしている HTTP サーバが、この種の情報を受信し慣れているからです。
2620+たいていのSOAPサービスは、コンテントタイプとコンテント長をクライアントが指定するように求めています。
2621+そういったサービスをホスティングしているHTTPサーバはこの種の情報を受信し慣れているからです。
24782622 @end itemize
24792623
24802624 @float Figure,fig:soap_book_price_quote.awk.2
@@ -2492,13 +2636,13 @@ SOAP クライアントの 2 番目と 3 番目の部分は、さらに RSS ク
24922636 print "" |& HttpService
24932637 print request |& HttpService
24942638 @end example
2495-@caption{SOAP リクエストを送信する @file{soap_book_price_quote.awk} の 2 番目の部分}
2639+@caption{SOAPリクエストを送信する@file{soap_book_price_quote.awk}の2番目の部分}
24962640 @end float
24972641
2498-リクエストを送信すれば、やらなければならないのはレスポンスの受信とその XML ツリーのトラバースです。
2499-ちょうど例の RSS クライアントのように、この SOAP クライアントは一時ファイルに XML のレスポンスを保存し、このファイルを XML ファイルとしてオープンします。
2500-XML ツリーをトラバースしている間、このクライアントは非常に単純に振舞います。
2501-すなわち、キャラクタデータを記憶し、@code{return} というタグ名のノードが来るとすぐ表示します。
2642+リクエストを送信すれば、やらなければならないのはレスポンスの受信とそのXMLツリーのトラバースです。
2643+例示したRSSクライアントとちょうど同じように、このSOAPクライアントは一時ファイルにXMLのレスポンスを保存し、このファイルをXMLファイルとしてオープンします。
2644+XMLツリーをトラバースしている間、このクライアントは非常に単純に振舞います。
2645+すなわち、キャラクタデータを記憶し、@code{return}というタグ名のノードが来るとすぐ表示します。
25022646
25032647 @float Figure,fig:soap_book_price_quote.awk.3
25042648 @example
@@ -2522,7 +2666,7 @@ XML ツリーをトラバースしている間、このクライアントは非
25222666 @}
25232667 @}
25242668 @end example
2525-@caption{SOAP レスポンスを読み取る @file{soap_book_price_quote.awk} の最後の 3 番目の部分}
2669+@caption{SOAPレスポンスを読み取る@file{soap_book_price_quote.awk}の最後の3番目の部分}
25262670 @end float
25272671
25282672 @float Figure,fig:soap_error
@@ -2530,25 +2674,29 @@ XML ツリーをトラバースしている間、このクライアントは非
25302674 @caption{Response to a SOAP request in case of an error}
25312675 @end float
25322676
2533-エラーの場合は何が起きるでしょうか?
2534-以下に述べるそれぞれのケースは、正しく SOAP クライアントを書く場合にはもっと丁寧に処理しなければならないでしょう。
2677+エラーの場合は何が起きるでしょうか。
2678+以下に述べる各ケースは、正しくSOAPクライアントを書く場合にはもっと丁寧に処理しなければならないでしょう。
25352679
25362680 @itemize
25372681 @item
2538-サービスが、指定された ISBN を知らない時は、価格として @code{-1.0} を返します。
2539-これは私たちの SOAP クライアントにとっては問題とならないですが、ユーザは負の価格を検査することを忘れないようにしなければなりません。
2682+指定されたISBNをサービスが知らない時は、価格として@code{-1.0}を返します。
2683+私たちのSOAPクライアントにとってはこれは問題とならないですが、負の価格を検査するのをユーザは忘れないようにしなければなりません。
2684+
25402685 @item
2541-SOAP サービスへのネットワーク接続が確立できなかった時は、その時はクライアントがかなり長い時間@emph{ハング}するかもしれません。
2542-そして何も起きず、最終的にエラーで終了しますが、テキスト的な反応はありません。
2543-あるいは、例えばファイヤウォールがリクエストを拒絶したような場合には、クライアントはすぐに終了します。
2686+SOAPサービスへのネットワーク接続が確立できなかった時は、クライアントがかなり長い時間@emph{ハング}するかもしれません。
2687+そして、何も起きず、最終的にエラーで終了しますが、テキスト的な反応はありません。
2688+あるいは、例えば、ファイアウォールがリクエストを拒絶したような場合には、クライアントはすぐに終了します。
2689+
25442690 @item
2545-HTTP リクエストのヘッダに何か不足しているか、あるいは、リクエストの XML ツリーが不完全な時は、正しい SOAP レスポンスを受信することになるでしょう。
2546-しかし、そのレスポンスには @code{return} ノードは見つけられないでしょう (それゆえクライアントは何も表示しません)。
2547-代わりに、そのレスポンスには @code{SOAP-ENV:Fault}、@code{faultcode}、@code{faultstring}、@code{faultactor} という型のノードが入っています。
2548-この状況は @ref{fig:soap_error} に図示しています。
2691+HTTPリクエストのヘッダに何か不足しているか、あるいは、リクエストのXMLツリーが不完全な時は、正しいSOAPレスポンスを受信します。
2692+しかし、そのレスポンスには@code{return}ノードは見つけられないでしょう(それゆえクライアントは何も表示しません)。
2693+代わりに、そのレスポンスには@code{SOAP-ENV:Fault}、@code{faultcode}、@code{faultstring}、@code{faultactor}という型のノードが入っています。
2694+この状況はfig:soap_error(@pxref{fig:soap_error})に図示しています。
2695+
25492696 @item
2550-サービスが異常終了する時、正しい XML メッセージでレスポンスすることは不可能です。
2551-この場合、ホスティングしている HTTP サーバが、よく独特の言い回しでメッセージを入れます (たいてい HTML でのつぶやきです)。
2697+サービスが異常終了する時は、正しいXMLメッセージでレスポンスすることは不可能です。
2698+この場合、ホスティングしているHTTPサーバは、よく、独特の言い回しでメッセージを入れます(たいていHTMLでのつぶやきです)。
2699+
25522700 @example
25532701 <h1>Error: 400</h1>
25542702 Error unmarshalling envelope: SOAP-ENV:VersionMismatch:
@@ -2557,20 +2705,21 @@ Envelope element must be associated with the
25572705 @end example
25582706 @end itemize
25592707
2560-私は上記の各ケースを@emph{~の時は}という条件を付けて書きました。
2708+上記の各ケースを、@emph{~の時は}という条件を付けて書きました。
25612709 というのは、そのようなケースがいつか@emph{起きるのかどうか}という問題ではなく、@emph{いつ}起きるだろうかというだけの問題だからです。
2562-ソフトウェアを書く時、起こり得るケースを場合分けするということは常に重要なことです (例えば、リターンコードを評価したり、例外をキャッチしたりです)。
2710+ソフトウェアを書く時、起こり得るケースを場合分けするということは常に重要なことです(例えば、リターンコードを評価したり、例外を捕捉したりということです)。
25632711 しかし、ネットワークへ接続するソフトウェアを書いている時は、そのようにすることは不可避なことです。
25642712 そうでなければ、そのネットワーキングソフトウェアは信頼のおけないものになるでしょう。
2565-ですので、実世界のクライアントは普通、この @value{SECTION} で書いたクライアントよりももっと長いものとなります。
2566-しかし多くの場合、エラー条件を取り扱うことは実際には複雑ではありません。
2567-たとえば、@code{while} ループ本体の最後のところに以下の一行を入れると、正しいエラー処理への第一段階を行うことができます。
2713+ですから、実世界のクライアントは、普通、この@value{SECTION}で書いたクライアントよりももっと長いものとなります。
2714+しかし、多くの場合、エラー条件を取り扱うことは実際には複雑ではありません。
2715+例えば、@code{while}ループ本体の最後のところに以下の一行を入れると、正しいエラー処理への第一段階を行うことができます。
25682716
25692717 @example
25702718 if (XMLENDELEM ~ /^fault/) @{ print XMLENDELEM ":", price @}
25712719 @end example
25722720
2573-このクライアントが @ref{fig:soap_error} にあるようなレスポンスを受け取ることがあればいつでも、ノード 4、5、6 が入った検出メッセージが表示されるでしょう。
2721+fig:soap_error(@pxref{fig:soap_error})にあるようなレスポンスをこのクライアントが受け取ることがあれば、必ず、ノード4、5、6が入った検出メッセージが表示されます。
2722+
25742723 @example
25752724 faultcode: SOAP-ENV:Protocol
25762725 faultstring: Content length must be specified.
@@ -2579,30 +2728,32 @@ faultactor: /soap/servlet/rpcrouter
25792728
25802729
25812730 @node Loading XML data into PostgreSQL
2582-@section PostgreSQL への XML データのロード
2731+@section PostgreSQLへのXMLデータのロード
25832732 @pindex PostgreSQL
2584-@cindex データベース
2585-前の @value{SECTION} では、データベースの照会の間のデータ交換用フォーマットとしてどのように XML が利用できるかを見てきました。
2586-そのようなデータベースの検索における XML の利用は、今日ではかなりありふれたことです。
2587-しかし、背後にある巨大なデータベースの実際の格納フォーマットは、普通は XML ではありません。
2588-プロプライエタリのデータベースソリューションの多くは、この数十年の間に自分たちのニッチマーケットを確立してきました。
2589-XML のような妙な新しいフォーマットが突然登場したというだけで、それらのデータベースソリューションが姿を消すことは間違いなく無いでしょう。
2590-その結果、従来のデータベースと XML の間のデータ変換のニーズが、商用アプリケーションの内外で繰り返し生じてきます。
2591-幸運にも、問い合わせ言語の SQL が問い合わせを表現する標準として広く認められています。
2733+@cindex database
2734+
2735+前の@value{SECTION}では、データベースの照会の間のデータ交換用フォーマットとしてどのようにXMLが利用できるかを見てきました。
2736+そのようなデータベースの検索におけるXMLの利用は、今日ではかなりありふれたことです。
2737+しかし、背後にある巨大なデータベースの実際の格納フォーマットは、普通、XMLではありません。
2738+プロプライエタリのデータベースソリューションの多くは、この数十年の間に、自分たちのニッチマーケットを確立してきました。
2739+XMLのような妙な新しいフォーマットが突然登場したというだけで、それらのデータベースソリューションが姿を消すことはまず無いでしょう。
2740+その結果、従来のデータベースとXMLの間のデータ変換のニーズが、商用アプリケーションの内外で繰り返し生じてきます。
25922741 @pindex SQL
2593-しかし、残念ながら、リクエストと、問い合わせの受け渡し、その結果の受け渡しに関する実際のインターフェイス (転送のメカニズム) はまったく標準化されていません。
2594-この @value{SECTION} の残りの部分では、特定のデータベース PostgreSQL に対する GNU Awk 拡張を作成することによって、こういった問題をどのように解決するかを説明します。
2595-独自のアクセス機構はすべて拡張の中に隠蔽され、アプリケーションスクリプトはこの拡張を利用します。
2596-手近な問題は、小さな連絡用データベースファイル (XML、@ref{fig:sample.xml}) を読み込んで、GNU Awk の以下の二つの拡張を利用しながら PostgreSQL データベースへそのデータを書き込むことです。
2742+幸運にも、問い合わせ言語のSQLが、問い合わせを表現する標準として広く認められています。
2743+しかし、残念ながら、リクエストと問い合わせの受け渡し、その結果の受け渡しに関する実際のインターフェイス(転送のメカニズム)は全く標準化されていません。
2744+この@value{SECTION}の残りの部分では、特定のデータベースPostgreSQLに対するGNU Awk拡張を作成することによって、こういった問題をどのように解決するかを説明します。
2745+独自のアクセス機構は全て拡張の中に隠蔽され、アプリケーションスクリプトはこの拡張を利用します。
2746+目前に置く問題は、小さな連絡用データベースファイル(XML, @pxref{fig:sample.xml})を読み込んで、GNU Awkの以下の二つの拡張を利用しながら、PostgreSQLデータベースへそのデータを書き込むことです。
2747+
25972748 @table @samp
25982749 @item xml
2599-XML ファイルからデータを読み込む
2750+XMLファイルのデータを読み込むためのもの
26002751 @item pgsql
2601-PostgreSQL のデータベースインターフェイスに接続する
2752+PostgreSQLのデータベースインターフェイスに接続するためのもの
26022753 @end table
26032754
2604-それで、@ref{fig:testxml2pgsql.awk} のアプリケーションスクリプトがこの拡張を両方ロードすることで始まるのは驚くことではありません。
2605-@code{pgsql} のような GNU Awk 拡張は通常、基礎となっている @uref{http://www.postgresql.org/docs/8.0/interactive/libpq.html, C interface} をアプリケーションスクリプトの作者に使いやすくするために実装されています。
2755+fig:testxml2pgsql.awk(@pxref{fig:testxml2pgsql.awk})のアプリケーションスクリプトがこの拡張を両方ロードすることで始まるのは驚くことではありません。
2756+@code{pgsql}のようなGNU Awk拡張は、通常、基礎となっている@uref{http://www.postgresql.org/docs/8.0/interactive/libpq.html, C interface}を、アプリケーションスクリプトの作者が使いやすくなるように実装されています。
26062757
26072758 @float Figure,fig:testxml2pgsql.awk
26082759 @pindex @file{testxml2pgsql.awk}
@@ -2611,13 +2762,13 @@ PostgreSQL のデータベースインターフェイスに接続する
26112762 @@load pgsql
26122763
26132764 BEGIN @{
2614- # 注意: 以下のところで議論されているように、PQconnectdb オプションを含めて
2615- # pg_connect へ引数を渡すべき。
2765+ # 注意: 以下のところで議論されているように、PQconnectdbオプションを含めて
2766+ # pg_connectへ引数を渡すべき。
26162767 # http://www.postgresql.org/docs/8.0/interactive/libpq.html#LIBPQ-CONNECT
26172768 # でなければ、以下で議論されているように、環境によってパラメータが
26182769 # セットされ得る
26192770 # http://www.postgresql.org/docs/8.0/interactive/libpq-envars.html
2620- # たとえば、コールの典型は次のようになるでしょう。
2771+ # 例えば、コールの典型は次のようになるでしょう。
26212772 # pg_connect("host=pgsql_server dbname=my_database")
26222773 if ((dbconn = pg_connect()) == "") @{
26232774 printf "pg_connect failed: %s\n", ERRNO > "/dev/stderr"
@@ -2641,7 +2792,7 @@ BEGIN @{
26412792 exit 1
26422793 @}
26432794
2644- # insert ステートメントを前もって作成
2795+ # insertステートメントを前もって作成
26452796 sql = ("INSERT INTO tmp ("col[1])
26462797 for (i = 2; i <= ncols; i++)
26472798 sql = (sql", "col[i])
@@ -2655,20 +2806,20 @@ BEGIN @{
26552806 @}
26562807 @}
26572808 @end example
2658-@caption{PostgreSQL へ接続する @file{testxml2pgsql.awk} の最初の部分}
2809+@caption{PostgreSQLへ接続する@file{testxml2pgsql.awk}の最初の部分}
26592810 @end float
26602811
2661-たとえば、@code{pg_connect} 関数は、ほぼ同じ名前の C 関数のだたのラッパーです。
2812+例えば、@code{pg_connect}関数は、ほぼ同じ名前のC関数のだたのラッパーです。
26622813 この透過性は良い習慣ですが、強制的なものではありません。
2663-他の GNU Awk 拡張は、インターフェイスのデザインにおいて、不透明さの実装を選択することもできます。
2814+他のGNU Awk拡張は、インターフェイスのデザインにおいて、不透過な実装を選択することもできます。
26642815
26652816 接続の試みが失敗した場合は、終了の前に、アプリケーションスクリプトのユーザに対して報告されます。
2666-(@code{pg_connect} で) 接続が成功すれば、このデータベースの構造についてスクリプトが PostgreSQL に指示します。
2667-この構造はもちろん、@ref{fig:sample.xml} にある連絡用データベースのフォーマットに影響されています。
2668-データベースの各フィールド (name, email, work, cell, company address) は PostgresQL で実行される SQL ステートメントで宣言されています。
2669-このテーブルが作成されると、PostgreSQL は @code{OK} メッセージで応答することが期待されています。
2817+(@code{pg_connect}で)接続が成功すれば、このデータベースの構造についてスクリプトがPostgreSQLに指示します。
2818+この構造は、もちろん、fig:sample.xml(@pxref{fig:sample.xml})にある連絡用データベースのフォーマットに影響されています。
2819+データベースの各フィールド(name・email・work・cell・company address)は、PostgresQLで実行されるSQLステートメントで宣言されています。
2820+このテーブルが作成されると、PostgreSQLは、@code{OK}メッセージで応答することが期待されています。
26702821 そうでなければ、テーブルを作成する試みは中断して終了しなければなりません。
2671-最後に、前もって用意された insert ステートメントが PostgreSQL にデータベースの詳細 (fieldwidths) について指示します。
2822+最後に、前もって用意されたinsertステートメントが、PostgreSQLにデータベースの詳細(fieldwidths)について指示します。
26722823
26732824 @float Figure,fig:sample.xml
26742825 @pindex @file{sample.xml}
@@ -2703,11 +2854,11 @@ BEGIN @{
27032854
27042855 </contact_database>
27052856 @end example
2706-@caption{PostgreSQL に格納される連絡用データベース}
2857+@caption{PostgreSQLに格納される連絡用データベース}
27072858 @end float
27082859
2709-今や、PostgreSQL はデータベースの構造について知りましたので、実際のデータを読み込む準備ができました。
2710-@file{testxml2pgsql.awk} ファイルの中にスクリプトが格納されていて、XML データは @file{sample.xml} にあるとしますと、アプリケーションは次のように起動することができます。
2860+これで、PostgreSQLはデータベースの構造について知りましたので、実際のデータを読み込む準備ができました。
2861+@file{testxml2pgsql.awk}ファイルの中にスクリプトが格納されていて、XMLデータは@file{sample.xml}にあるとしますと、アプリケーションは次のように起動することができます。
27112862
27122863 @example
27132864 gawk -f testxml2pgsql.awk < sample.xml
@@ -2717,10 +2868,10 @@ Ellen Jones|ellen.jones@@widget.com|1-310-555-1212|<NULL>|Widget Inc.|137 Main S
27172868 Ralph Simpson|<NULL>|1-312-555-1212|1-773-555-1212|General Motors|13 Elm St., Chicago, IL
27182869 @end example
27192870
2720-このデータファイルはインタプリタにパラメータとして渡されず、インタプリタの標準入力にリダイレクトされている (@code{< sample.xml}) ことに注意してください。
2721-こういう起動の方法だと、アプリケーションにはファイルの名前が見えないようになりますが、このスクリプトは、@ref{fig:testxml2pgsql.awk.2} の波括弧内部で AWK の@emph{パターンアクション}モデルに従いながら、入力される XML データを都合良く処理することもできます。
2722-この XML ファイルの空であったフィールドがスクリプトの出力では @code{<NULL>} フィールドとして表われるということもわかります。
2723-明らかに、XML ファイルを読み込んでいる間、@ref{fig:testxml2pgsql.awk.2} のアプリケーションスクリプトは、データレコードの中のデータが入っているフィールドと空のフィールドに注意を向けています。
2871+このデータファイルはインタプリタにパラメータとして渡されず、インタプリタの標準入力にリダイレクトされている(@code{< sample.xml})ことに注意してください。
2872+こういう起動の方法だと、アプリケーションにはファイルの名前が見えないようになりますが、このスクリプトは、fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})の波括弧内部でAWKの@emph{パターンアクション}モデルに従いながら、入力されるXMLデータを都合良く処理することができます。
2873+このXMLファイルの空であったフィールドが、スクリプトの出力では@code{<NULL>}フィールドとして表われるということも分かります。
2874+当然、XMLファイルを読み込んでいる間、fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})のアプリケーションスクリプトは、データレコードの中のデータが入っているフィールドと空のフィールドに注意を向けています。
27242875
27252876 @cindex @code{XMLATTR}
27262877 @float Figure,fig:testxml2pgsql.awk.2
@@ -2758,20 +2909,20 @@ Ralph Simpson|<NULL>|1-312-555-1212|1-773-555-1212|General Motors|13 Elm St., Ch
27582909 @}
27592910 @}
27602911 @end example
2761-@caption{PostgreSQL へデータを送る @file{testxml2pgsql.awk} の 2 番目の部分}
2912+@caption{PostgreSQLへデータを送る@file{testxml2pgsql.awk}の2番目の部分}
27622913 @end float
27632914
27642915 @cindex @code{XMLEVENT}
2765-ここまで見てきたスクリプトの大半は、@ref{XMLgawk コア言語インターフェイスの要約} の中で @emph{Style A} として説明したやり方で AWK の@emph{パターンアクション}モデルに従っています。
2766-@ref{fig:testxml2pgsql.awk.2} のスクリプトは、@emph{Style B} を使っている点で異なっています。
2767-@emph{Style A} がアクションの前の @code{XMLSTARTELEM} パターンを求めているとしたら、@emph{Style B} は @code{XMLEVENT} の内容を見て、行なわれるべきアクションに対する @code{STARTELEM} case へ切り替えています。
2768-(データをアトリビュートの @code{type} やタグ名から集める) アクション自体は両方のスタイルで同じままです。
2769-@code{CHARDATA} の case は、末端の XML ノードからデータを集める考え方を説明している @ref{XML パスを使った操作}を見ていなければ、理解するのが難しいままでしょう。
2770-@ref{fig:sample.xml} にあるデータの大部分はキャラクタデータとして末端の XML ノードに格納されているということは覚えておいてください。
2771-@code{contact} ノードが終了すればいつでも、収集したデータを PostgreSQL へ保存する時です。
2772-そして、変数は次の @code{contact} のデータを収集するために空にされなければなりません。
2773-このデータの収集と保存は、XML イベントがこれ以上無くなってしまうまで繰り返されます。
2774-その時までには、PostgreSQL には完全なデータベースが入っているでしょう。
2916+ここまで見てきたスクリプトの大半は、別の節(@pxref{XMLgawk Core Language Interface Summary})の中で@emph{Style A}として説明したやり方でAWKの@emph{パターンアクション}モデルに従っています。
2917+fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})のスクリプトは、@emph{Style B}を使っている点で異なっています。
2918+@emph{Style A}が、アクションの前の@code{XMLSTARTELEM}パターンを求めているとしたら、@emph{Style B}では、@code{XMLEVENT}の内容を見て、行われるべきアクションに対する@code{STARTELEM} caseへ切り替えています。
2919+(アトリビュートの@code{type}やタグ名からデータを集める)アクション自体は両方のスタイルで同じままです。
2920+@code{CHARDATA}のcaseは、末端のXMLノードからデータを集める考え方を説明している節(@pxref{Working with XML paths})を見ていなければ、理解するのが難しいままでしょう。
2921+fig:sample.xml(@pxref{fig:sample.xml})にあるデータの大部分は、キャラクタデータとして末端のXMLノードに格納されているということは覚えておいてください。
2922+@code{contact}ノードが終了すれば、いつでも、収集したデータをPostgreSQLへ保存する時です。
2923+そして、変数は、次の@code{contact}のデータを収集するために空にされなければなりません。
2924+このデータの収集と保存は、XMLイベントがこれ以上無くなってしまうまで繰り返されます。
2925+その時までには、PostgreSQLには完全なデータベースが入っていることになります。
27752926
27762927 @float Figure,fig:testxml2pgsql.awk.3
27772928 @example
@@ -2804,49 +2955,51 @@ END @{
28042955 @}
28052956 @}
28062957 @end example
2807-@caption{PostgreSQL から再度データを読み出す @file{testxml2pgsql.awk} の最後の部分L}
2958+@caption{PostgreSQLから再度データを読み出す@file{testxml2pgsql.awk}の最後の部分L}
28082959 @end float
28092960
2810-私たちのアプリケーションスクリプトの最後の 3 番目の部分は @ref{fig:testxml2pgsql.awk.3} にありますが、全てのものが正しく保存されたか確かめるのを支援してくれます。
2811-それを行なうには、私たちのスクリプトから PostgreSQL データベースを読み出すにはどうすればよいかということも見ましょう。
2812-スクリプトに @code{END} パターンがあるときはいつも、全てのデータを読み終わったあとで、パターンに続くアクションが実行されます。
2813-それは、最初に実行された初期化が成功したかどうかは関係ありません。
2814-この状況は、比較的重要でないプログラミング言語の例外処理で使う @code{try (...) catch} シーケンスと似ています。
2961+このアプリケーションスクリプトの最後の3番目の部分はfig:testxml2pgsql.awk.3(@pxref{fig:testxml2pgsql.awk.3})にありますが、全てのものが正しく保存されたか確かめるのを支援してくれます。
2962+それを行うため、このスクリプトによってPostgreSQLデータベースを読み出すにはどうすればよいかということも見ていきます。
2963+スクリプトに@code{END}パターンがある時は、全てのデータを読み終わったあとで、このパターンに続くアクションが必ず実行されます。
2964+最初に実行された初期化が成功したかどうかは関係ありません。
2965+この状況は、比較的重要でないプログラミング言語の例外処理で使う@code{try (...) catch}シーケンスと似ています。
28152966 そういった「例外ハンドラ」では、当てになる変数の状態についてほとんどアサーションができません。
2816-なので、変数を使う前にそれが有効かどうか確認しなければなりません。
2817-それが、@ref{fig:testxml2pgsql.awk.3} で最初にやっていることです。
2818-データベースを読むのは、それが実際にオープンされた時にしか意味がありません。
2819-実際にオープン@emph{された}場合に PostgreSQL へ SQL ステートメントを送る意味があります。
2820-ステートメントを送るのが成功したあと (しかもその時だけ)、返された結果を各フィールドへ分割することができます。
2967+ですから、変数を使う前に、変数が有効かどうか確認しなければなりません。
2968+それが、fig:testxml2pgsql.awk.3(@pxref{fig:testxml2pgsql.awk.3})で最初にやっていることです。
2969+データベースを読むためには、データベースが実際にオープンされないことには始まりません。
2970+実際に@emph{オープンされた}場合には、PostgreSQLへSQLステートメントを送る意味が出て来ます。
2971+ステートメントを送るのに成功した後、(しかも、その時だけ、)返された結果を各フィールドへ分割することができます。
28212972 全行の全フィールドが表示されますが、空でないフィールドだけです。
28222973
2974+
28232975 @node Converting XML data into tree drawings
2824-@section XML データからツリー図への変換
2825-@ref{AWK と XML の概念} を読んでいる間、@ref{fig:dbfile} の DocBook ファイルを、@ref{fig:docbook_chapter} にあるツリーの図にどうやって変換しているのか不思議に思ったかもしれません。
2976+@section XMLデータからツリー図への変換
2977+
2978+別の節(@pxref{AWK and XML Concepts})を読んでいる間、fig:dbfile(@pxref{fig:dbfile})のDocBookファイルを、fig:docbook_chapter(@pxref{fig:docbook_chapter})にあるツリーの図にどうやって変換しているのか不思議に思ったかもしれません。
28262979 @cindex DocBook
2827-この図は手作業ではなく変換ツールを使って作りました。
2828-それは @code{gawk} スクリプトとして実装されています。
2829-画像の取り扱いに関する問題の良い解決策を見つけるこつは、必ず適切なツールを見つけるということです。
2830-AT&T Labs には、グラフを描くためのオープンソースソフトウェアパッケージの @uref{http://www.research.att.com/sw/tools/graphviz/, GraphViz} に関する作業をするプロジェクトグループがあります。
2831-グラフはツリーをもっと一般化したデータ構造ですので、ツリーは、グラフの特殊な場合としてそこに含まれます。
2832-それで、@uref{http://www.research.att.com/sw/tools/graphviz/dotguide.pdf, @code{dot} tool} で、@ref{fig:docbook_chapter} にあるようなナイスな図を生成することができます。
2833-@code{dot} のソースコードをダウンロードしに行く前に、あなたのオペレーティングシステムの配布メディアを見てください。
2834-@code{dot} はたいていの GNU/Linux ディストリビューションに無料で付いてきます。
2835-@cindex Graphviz, オープンソースのグラフ描画ソフトウェア
2980+この図は、手作業ではなく変換ツールを使って作りました。
2981+ツールは、@code{gawk}スクリプトとして実装されています。
2982+画像の取り扱いに関する問題の良い解決策を見つけるコツは、必ず、適切なツールを見つけるということです。
2983+AT&T Labsには、グラフを描くためのオープンソースソフトウェアパッケージの@uref{http://www.research.att.com/sw/tools/graphviz/, GraphViz}に関する作業をするプロジェクトグループがあります。
2984+ツリーをもっと一般化したデータ構造がグラフですので、ツリーは、グラフの特殊な場合としてそこに含まれます。
2985+それで、@uref{http://www.research.att.com/sw/tools/graphviz/dotguide.pdf, @code{dot} tool}で、fig:docbook_chapter(@pxref{fig:docbook_chapter})にあるようなナイスな図を生成することができます。
2986+@code{dot}のソースコードをダウンロードしに行く前に、オペレーティングシステムの配布メディアを見てください。
2987+@code{dot}は、たいていのGNU/Linuxディストリビューションに無料で付いてきます。
2988+@cindex Graphviz, open source graph drawing software
28362989 @pindex dot
28372990
2838-しかし、まだ疑問は残っています。
2839-どのように XML ファイルをグラフの画像に変換するのか?
2991+しかし、疑問はまだ残っています。
2992+どのようにXMLファイルをグラフの画像に変換するのでしょうか。
28402993 @cindex PostScript
2841-@code{dot} は、グラフの@uref{http://www.research.att.com/~erg/graphviz/info/lang.html, テキストによる記述}を読み込んで、Encapsulated PostScript のファイルを生成します。
2842-このテキストによる記述は @ref{fig:source_dot} のように見えます。
2843-@ref{fig:source_dot} には、@ref{fig:docbook_chapter} のツリーに対する @code{dot} ソースコードが記述されています。
2844-さて、そうすると、@ref{fig:dbfile} を @ref{fig:source_dot} に変換するのはどうするのかという疑問が改めて出てきます。
2845-少し比べてみれば、@ref{fig:source_dot} には基本的に、各ノード毎に一つの @code{struct} 行 (ノード名すなわちマークアップブロックのタグを含む) と、ツリーの各エッジ毎に一つの @code{struct} 行 (それが指し示すノードの番号を含む) があることに気付きます。
2846-一番最初の @code{struct1} は少し違います。
2847-@code{struct1} は XML ファイルのルートノードが入っています。
2848-このツリーの中で、このノードは番号を持っていませんが、太枠が付けられています。
2849-この @value{SECTION} の残りの部分では、@ref{fig:outline_dot.awk} にある @file{outline_dot.awk} スクリプトが XML ファイルを、@code{dot} ツールで読めるグラフ表現にどのように変換するのかということを明らかにします。
2994+@code{dot}は、グラフの@uref{http://www.research.att.com/~erg/graphviz/info/lang.html, テキスト表記}を読み込んで、Encapsulated PostScriptのファイルを生成します。
2995+このテキスト表記は、fig:source_dot(@pxref{fig:source_dot})のようなものです。
2996+fig:source_dot(@pxref{fig:source_dot})には、fig:docbook_chapter(@pxref{fig:docbook_chapter})のツリーに対する@code{dot}ソースコードが記述されています。
2997+さて、そうすると、fig:dbfile(@pxref{fig:dbfile})をfig:source_dot(@pxref{fig:source_dot})に変換するのはどうするのかという疑問が改めて出てきます。
2998+少し比べてみれば、fig:source_dot(@pxref{fig:source_dot})には、基本的に、各ノード毎に一つの@code{struct}行(ノード名すなわちマークアップブロックのタグを含む)と、ツリーの各エッジ毎に一つの@code{struct}行(それが指し示すノードの番号を含む)があることに気付きます。
2999+一番最初の@code{struct1}は少し違います。
3000+@code{struct1}は、XMLファイルのルートノードが入っています。
3001+このツリーの中でこのノードは番号を持っていませんが、太枠が付けられています。
3002+この@value{SECTION}の残りの部分では、fig:outline_dot.awk(@pxref{fig:outline_dot.awk})にある@file{outline_dot.awk}スクリプトが、XMLファイルを、@code{dot}ツールで読めるグラフ表現にどのように変換するのかということを明らかにします。
28503003
28513004 @float Figure,fig:source_dot
28523005 @example
@@ -2879,33 +3032,36 @@ digraph G @{
28793032 struct10 -> struct12:f0 [headlabel="12\n\n"]
28803033 @}
28813034 @end example
2882-@caption{@code{dot} ツールのためのツリー表現の例}
3035+@caption{@code{dot}ツールのためのツリー表現の例}
28833036 @end float
28843037
2885-@ref{fig:outline_dot.awk} の細かいところを追求する前に、少しの間だけ後ろへ下がってみて、この @code{gawk} スクリプトと @ref{fig:ch2_outline.awk} のスクリプトの間の構造の類似に注意してみてください。
2886-どちらもツリーのトラバースの間に各ノードの深さを測定しています。
2887-@ref{fig:outline_dot.awk} の @code{BEGIN} セクションには、三つの @code{print} 行が追加されただけです。
2888-その追加された行が @ref{fig:source_dot} の最初の 3 行を生成します。
2889-同じことが @ref{fig:outline_dot.awk} の @code{END} セクションにある一つの @code{print} 行にも言えます。
2890-これは @ref{fig:source_dot} の木構造のテキスト表記を終了させるだけのものです。
2891-その結果、@ref{fig:source_dot} の @code{struct} 行は全部、@ref{fig:outline_dot.awk} の @code{XMLSTARTELEM} セクションで木構造をトラバースする間に生成されます。
3038+fig:outline_dot.awk(@pxref{fig:outline_dot.awk})の細かいところを追求する前に、少しの間だけ元へ戻ってみて、この@code{gawk}スクリプトとfig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})のスクリプトの間の構造の類似に注意してみてください。
3039+どちらも、ツリーのトラバースの間に、各ノードの深さを測定しています。
3040+fig:outline_dot.awk(@pxref{fig:outline_dot.awk})の@code{BEGIN}セクションには、三つの@code{print}行が追加されただけです。
3041+その追加された行によって、fig:source_dot(@pxref{fig:source_dot})の最初の3行を生成します。
3042+同じことがfig:outline_dot.awk(@pxref{fig:outline_dot.awk})の@code{END}セクションにある一つの@code{print}行にも言えます。
3043+これは、fig:source_dot(@pxref{fig:source_dot})の木構造のテキスト表記を終了させるだけのものです。
3044+その結果、fig:source_dot(@pxref{fig:source_dot})の@code{struct}行は、fig:outline_dot.awk(@pxref{fig:outline_dot.awk})の@code{XMLSTARTELEM}セクションで木構造をトラバースする間に全部生成されます。
3045+
3046+ノードに会うたび、以下の二つのことを行わなければなりません。
28923047
2893-ノードにぶつかるたびに以下の二つのことを行なわなければなりません。
28943048 @enumerate
2895-@item 図にそのノードを入れる。
3049+@item 図に、そのノードを入れる。
28963050 @item 図に、そのノードの親からそのノード自身へ向かうエッジを入れる。
28973051 @end enumerate
28983052
2899-ノードの識別を簡単にするために、ノードカウンタ @code{n} がインクリメントされます。
2900-それから @code{n} は @code{struct} に追加され、各ノードを名前で識別できるようにします。
2901-タグ名というのは一つしかないというわけではありませんので、マークアップグロックのタグ名でノードを識別することはできません。
2902-この段階で、以下のような行を表示して図にノードを挿入する準備が整います。
3053+ノードの識別を簡単にするために、ノードカウンタ@code{n}がインクリメントされます。
3054+それから、@code{n}が、@code{struct}に追加され、各ノードを名前で識別できるようにします。
3055+タグ名というのは一つしかないというわけではありません。
3056+そのため、マークアップグロックのタグ名でノードを識別することはできません。
3057+この段階で、以下のような行を表示してノードを図に挿入する準備が整います。
3058+
29033059 @example
29043060 struct3[label="<f0>title "];
29053061 @end example
29063062
2907-ノードのラベルはマークアップブロックのタグ名を入れるのに適した場所です (@code{XMLSTARTELEM})。
2908-もしノードにアトリビュートがあれば、区切り文字を付けてラベルに追加されます。
3063+ノードのラベルは、マークアップブロックのタグ名を入れるのに適した場所です(@code{XMLSTARTELEM})。
3064+もし、ノードにアトリビュートがあれば、区切り文字を付けてラベルに追加されます。
29093065
29103066 @float Figure,fig:outline_dot.awk
29113067 @pindex @file{outline_dot.awk}
@@ -2932,67 +3088,76 @@ XMLSTARTELEM @{
29323088 @}
29333089 END @{ print "@}" @}
29343090 @end example
2935-@caption{XML ファイルを @code{dot} ツール用のツリー表現に変換する @file{outline_dot.awk}}
3091+@caption{XMLファイルを@code{dot}ツール用のツリー表現に変換する@file{outline_dot.awk}}
29363092 @end float
29373093
29383094 現時点でノードには名前が付いていますので、その親ノードからノード自身までエッジを描くことができます。
2939-@code{name} 配列には指定された深さにおいて最も最近トラバースされたノードの識別子が常に入っています。
3095+@code{name}配列には、指定された深さにおいて最も最近トラバースされたノードの識別子が常に入っています。
29403096 @emph{深さ優先}で木構造をトラバースしているため、一つ浅い深さで最も最近トラバースされたノードが親ノードであるということはいつも確実です。
29413097 このアサーションを考慮すれば、名前で簡単に親を特定し、親ノードからそのノードに線を表示することができます。
3098+
29423099 @example
29433100 struct2 -> struct3:f0 [headlabel="3\n\n"]
29443101 @end example
29453102
2946-ルートノード (@code{XMLDEPTH==1}) は処理がさらに簡単な特殊なケースです。
2947-ルートノードには親がありませんのでエッジを描く必要はありませんが、ルートノードは太枠で囲むことによって特別な認識をされています。
3103+ルートノード(@code{XMLDEPTH==1})は、処理がさらに簡単な特殊ケースです。
3104+ルートノードには親がありません。
3105+そのため、エッジを描く必要はありませんが、ルートノードは、太枠で囲むことによって特別な認識をされています。
29483106
29493107 さて、スクリプトをファイルへ保存して、起動してください。
2950-@code{gawk} の出力は @code{dot} へ直接パイプされます。
2951-@code{dot} は、@file{tree.eps} というファイルへ Encapsulated PostScript 出力を保存するよう指示されます。
2952-@code{dot} は、この出力の記述を、PostScript 形式の素晴しいグラフィカルな画像へと変換します。
3108+@code{gawk}の出力は@code{dot}へ直接パイプされます。
3109+@code{dot}は、@file{tree.eps}というファイルへ、Encapsulated PostScript出力を保存するよう指示されます。
3110+@code{dot}は、この出力の記述を、PostScript形式の素晴しいグラフィカルな画像へと変換します。
3111+
29533112 @example
29543113 gawk -f outline_dot.awk dbfile.xml | dot -Tps2 -o tree.eps
29553114 @end example
29563115
3116+
29573117 @page
29583118 @node Generating a DTD from a sample file
2959-@section サンプルファイルからの DTD の生成
3119+@section サンプルファイルからのDTDの生成
29603120 @cindex DTD, Document Type Definition
2961-@cindex 妥当性の検証
2962-@ref{整形式のチェック}の中で妥当性の検証についてすでにお話ししました。
2963-そこでは、@code{gawk} は DTD に対して XML ファイルの妥当性を検証することはしないというように学びました。
2964-じゃあ、このトピックは全く無視しなければならないということなんでしょうか?
2965-いいえ、DTD の利用は非常に広範囲なので、XML ファイルで作業している全員が少なくとも DTD を読む能力を持つべきでしょう。
2966-DTD をまじめに取り上げるべき良い理由が少くとも以下の二つあります。
3121+@cindex validation
3122+
3123+別の節(@pxref{Checking for well-formedness})の中で、妥当性の検証については既にお話ししました。
3124+そこでは、@code{gawk}は、DTDに対して、XMLファイルの妥当性を検証することはしないというように学びました。
3125+じゃあ、このトピックは全く無視しなければならないということなんでしょうか。
3126+否、DTDの利用は非常に広範囲に渡ります。
3127+XMLファイルで作業している人全てが、少なくとも、DTDを読む能力を持つべきでしょう。
3128+DTDを真面目に取り上げるべき良い理由が少くとも以下の二つあります。
3129+
29673130 @enumerate
29683131 @item
2969-オリジナルの DTD が与えられていた (そしてその DTD が上手く書けていた) 場合には、妥当な XML の見本ファイルをブラウジングすることからよりも、DTD を見ることからのほうがより多くのことを学ぶことができます。
3132+オリジナルのDTDが与えられていた(そして、そのDTDが上手く書けていた)場合、妥当なXMLの見本ファイルをブラウジングするよりも、DTDを見るほうが、より多くのことを学ぶことができます。
3133+
29703134 @item
2971-現実には、いつか DTD を作らなければならなくなる人は私たちの中にはほとんどいません。
2972-しかし、(@uref{http://lists.w3.org/Archives/Public/www-archive/2004Mar/0169.html, この投稿}に添付されているもののような) 巨大な XML ファイルと対峙して、DTD を@emph{持ってない}時、その XML ファイルの意味を理解するのは困難となるでしょう。
3135+現実には、今後、DTDを作らなければならなくなる人は私たちの中にはほとんどいません。
3136+しかし、(@uref{http://lists.w3.org/Archives/Public/www-archive/2004Mar/0169.html, この投稿}に添付されているもののような)巨大なXMLファイルと対峙していて、DTDを@emph{持ってない}場合、そのXMLファイルの意味を理解するのは難しいものとなるでしょう。
29733137 @end enumerate
29743138
2975-そういう場合、@uref{http://saxon.sourceforge.net/dtdgen.html, DTDGenerator -- A tool to generate XML DTDs} のようなツールがあったらよいのにと思うでしょう。
2976-このツールは、整形式の XML ファイルを取り、そこから DTD を生成します (ですので、もちろんその DTD に対して XML ファイルは妥当性を持ちます)。
2977-例として @ref{fig:dbfile} を見てみましょう。
2978-これは DocBook
3139+そういう場合、@uref{http://saxon.sourceforge.net/dtdgen.html, DTDGenerator -- A tool to generate XML DTDs}のようなツールがあったら良いのにと思うでしょう。
3140+このツールは、整形式のXMLファイルを受け取り、そこからDTDを生成します(ですから、もちろん、そのDTDに対してXMLファイルは妥当性を持ちます)。
3141+例として、fig:dbfile(@pxref{fig:dbfile})を見てみましょう。
29793142 @cindex DocBook
2980-ファイルで、そのヘッダで指定されている DTD はよく作られています。
2981-この DocBook ファイルがもっと長くて、このファイルを読んで処理することを要するアプリケーションがあったと想像してみてください。
2982-あなたは、完全な DocBook DTD を取りにいって、その DocBook DTD の細かい部分を全て処理するようにアプリケーションを仕立てますか?
2983-恐らくそうはしないでしょう。
2984-手元にあるファイルを記述するのには十分良い DTD のサブセットで始めるのはより現実的です。
2985-DTD ジェネレータはスタート地点としてはよく役立つ DTD を生成します。
2986-たとえば、@ref{fig:dbfile} の DocBook ファイルは @ref{fig:dbfile.dtd} の DTD で記述することができます。
2987-野生で見つけるであろう DTD の大部分とは違い、この DTD は 構造を強調するためにインデンテーションが使われています。
2988-アトリビュートは常にそのエレメント名の直後にリストされ、あるエレメントの中に表われるサブエレメントは、親エレメントの直下にインデントして続きます。
2989-
2990-少し時間を使って、@ref{fig:dbfile.dtd} にリストされているエレメントとアトリビュートの関係と、@ref{fig:dbfile} の例示ファイルを理解してみると良いでしょう。
2991-たとえば、 @ref{fig:dbfile.dtd} の最初の行は、@code{book} が一連のエレメントから構成され、その一連のエレメントとは @code{chapter} か @code{bookinfo} のどちらかであるということ示しています。
2992-@ref{fig:docbook_chapter} の図を見てこれを検証することができます。
2993-次の 2 行は、@code{book} が必須のアトリビュートを二つ、@code{lang} と @code{id} を持っているということを示しています。
2994-@ref{fig:dbfile.dtd} の残りの部分には同様にその他のエレメントとアトリビュート全てについてインデントしながら記述されています。
2995-他のエレメントをその中に持たないエレメントは中に @code{#PCDATA} があります。
3143+これはDocBookファイルです。
3144+ヘッダで指定されているDTDはよく作られています。
3145+このDocBookファイルがもっと長くて、このファイルを読んで処理することを要するアプリケーションがあると想像してみてください。
3146+完全なDocBook DTDを入手しにいって、そのDocBook DTDの細かい部分を全て処理するようにアプリケーションを作り上げるでしょうか。
3147+恐らく、そうはしないでしょう。
3148+手元のファイルを説明するのに足るDTDのサブセットがあれば、そのDTDを使って作業を始めるのが、より現実的です。
3149+DTDジェネレータは、スタート地点としては十分使えるDTDを生成します。
3150+例えば、fig:dbfile(@pxref{fig:dbfile})のDocBookファイルは、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})のDTDで記述することができます。
3151+野良で見つかるDTDの大部分とは違い、このDTDは、構造を強調するために字下げが行われています。
3152+アトリビュートはそのエレメント名の直後に常にリストされ、あるエレメントの中に表われるサブエレメントは、親エレメントの直下に字下げして続きます。
3153+
3154+少し時間を使って、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})にリストされているエレメントとアトリビュートの関係と、fig:dbfile(@pxref{fig:dbfile})の例示ファイルを理解してみると良いでしょう。
3155+例えば、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の最初の行は、一連のエレメントから@code{book}が構成され、その一連のエレメントとは、@code{chapter}か@code{bookinfo}のどちらかであるということ示しています。
3156+fig:docbook_chapter(@pxref{fig:docbook_chapter})の図を見れば、これを検証することができます。
3157+次の2行は、@code{book}が、必須のアトリビュートを二つ持っていることを示しています。
3158+@code{lang}と@code{id}です。
3159+fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の残りの部分には、その他のエレメントとアトリビュート全てについて、字下げしながら同様に記述されています。
3160+他のエレメントを中に持たないエレメントは、@code{#PCDATA}が中にあります。
29963161
29973162 @float Figure,fig:dbfile.dtd
29983163 @example
@@ -3007,24 +3172,27 @@ DTD ジェネレータはスタート地点としてはよく役立つ DTD を
30073172 <!ELEMENT title ( #PCDATA ) >
30083173 <!ELEMENT bookinfo ( title )* >
30093174 @end example
3010-@caption{ネスト構造を強調するようにアレンジされた DTD の例}
3175+@caption{ネスト構造を強調するようにアレンジされたDTDの例}
30113176 @end float
30123177
3013-この @value{SECTION} の残りの部分では、@ref{fig:dbfile.dtd} の DTD を生成するスクリプトの説明をします。
3014-このスクリプトの最初の部分は @ref{fig:outline_dot.awk} にかなり似ているように見えます。
3015-どちらのスクリプトも、XML ファイルのノードツリーをトラバースし、非常によく似たやり方で情報を集めていきます (たとえば @code{name} 配列と @code{XMLDEPTH} 変数)。
3016-@ref{fig:dtd_generator.awk} には配列変数が三つ追加され、後で DTD を生成するのに必要な情報を保持する役目を負っています。
3017-以下が追加された配列変数です。
3178+この@value{SECTION}の残りの部分では、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})のDTDを生成するスクリプトの説明をします。
3179+このスクリプトの最初の部分は、fig:outline_dot.awk(@pxref{fig:outline_dot.awk})にかなり似ているように見えます。
3180+どちらのスクリプトも、XMLファイルのノードツリーをトラバースし、非常によく似たやり方で情報を集めていきます(例えば、@code{name}配列と@code{XMLDEPTH}変数)。
3181+fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})には配列変数が三つ追加され、DTDを後で生成するのに必要な情報を保持する役目を負っています。
3182+以下は、追加された配列変数です。
3183+
30183184 @enumerate
30193185 @item
3020-@code{elem[e]} は全てのエレメントの名前を覚えて、各エレメントが現われた回数を数えます。
3021-これは、名前を確認して、あるエレメントがあるアトリビュートを必ず伴って現われるかどうかを決定するのに必要です。
3186+@code{elem[e]}は、全てのエレメントの名前を記憶し、各エレメントが現われた回数を数えます。
3187+これは、名前を確認して、あるエレメントが、あるアトリビュートを必ず伴って現われるかどうかを決定するのに必要です。
3188+
30223189 @item
3023-@code{child[ep,ec]} は、どのエレメントが他のエレメントの子であるかを覚えます。
3024-これは、@ref{fig:dbfile.dtd} の @code{<!ELEMENT @dots{}>} という行の細部を生成するのに必要です。
3190+@code{child[ep,ec]}は、どのエレメントが他のエレメントの子であるかを記憶します。
3191+これは、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の@code{<!ELEMENT @dots{}>}という行の細部を生成するのに必要です。
3192+
30253193 @item
3026-@code{attr[e,a]} はどのエレメントにどのアトリビュートがあるかを記憶します。
3027-これは、@ref{fig:dbfile.dtd} の @code{<!ATTLIST @dots{}>} の細部を生成するのに必要です。
3194+@code{attr[e,a]}は、どのエレメントに、どのアトリビュートがあるかを記憶します。
3195+これは、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の@code{<!ATTLIST @dots{}>}の細部を生成するのに必要です。
30283196 @end enumerate
30293197
30303198 @float Figure,fig:dtd_generator.awk
@@ -3049,17 +3217,17 @@ XMLSTARTELEM @{
30493217
30503218 END @{ print_elem(1, name[1]) @} # name[1] is the root
30513219 @end example
3052-@caption{@file{dtd_generator.awk} の最初の部分 --- 情報収集 }
3220+@caption{@file{dtd_generator.awk}の最初の部分 --- 情報収集}
30533221 @end float
30543222
3055-ツリーのトラバースを完了して、エレメントとアトリビュートの名前とそのネスティングの構造を全て把握すれば、あとは @code{END} パターンのアクションが関数を一つ起動するだけです。
3056-この関数は、エレメントとアトリビュートの関係の決定を開始して、正しい DTD の形式でそれを表示します。
3057-@code{name[1]} にはツリーのルートノードの名前が入っていることに注意してください。
3058-これは、DTD の記述が、@ref{fig:dbfile.dtd} の最初の行に見えるように、XML ファイルのトップレベルのエレメントから始まるということを示しています。
3223+ツリーのトラバースを完了して、エレメントとアトリビュートの名前とそのネスティングの構造を全て把握すれば、後は、@code{END}パターンのアクションが関数を一つ起動するだけです。
3224+この関数は、エレメントとアトリビュートの関係の解決を開始して、正しいDTDの形式でそれを表示します。
3225+@code{name[1]}には、ツリーのルートノードの名前が入っていることに注意してください。
3226+これは、DTDの記述が、(fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の最初の行にあるような)XMLファイルのトップレベルのエレメントから始まるという意味です。
30593227
30603228 @float Figure,fig:print_elem
30613229 @smallexample
3062-# エレメントを一つ (サブエレメントを含めて)、一度だけ表示する。
3230+# エレメントを一つ(サブエレメントを含めて)、一度だけ表示する。
30633231 function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{
30643232 if (already_printed[element]++)
30653233 return
@@ -3100,29 +3268,31 @@ function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{
31003268 @}
31013269 @}
31023270 @end smallexample
3103-@caption{@file{dtd_generator.awk} の 2 番目の部分 --- DTD の表示 }
3271+@caption{@file{dtd_generator.awk}の2番目の部分 --- DTDの表示}
31043272 @end float
31053273
3106-この関数が最初に行なう事は、エレメントが既に表示されたものかどうかを判断することです (もし既に表示されているなら二度目は表示されません)。
3107-正しいインデントは、何個かの空白 (インデントのレベル毎に二つの空白) で表示される行を始めることによって行ないます。
3108-次に現在のエレメントの子ノードを全部収集して @code{myChildren} という文字列に入れます。
3109-AWK の @code{split} 関数は、連想配列のインデックスを構成しているエレメントの組 (親と子) を分割するのに使われます。
3110-子ノードを全て見つければ、このエレメントに対する DTD の @code{<!ELEMENT @dots{} >} という行を表示する準備が整います。
3111-もしエレメントが子ノードを持たないのであれば、それはツリーの葉なので、DTD の中にそのように記述されます。
3112-そうでなく、子ノードを持つのであれば、見つけた子ノードが全てエレメントに属しているように表示されます。
3274+この関数が最初に行う事は、エレメントが既に表示されたものかどうかを判断することです(既に表示されているなら、二度目は表示されません)。
3275+何個かの空白(インデントレベル毎に二つの空白)を使って表示される行を開始することによって、正しいインデントが行われます。
3276+次に、現在のエレメントの子ノードを全部収集して、@code{myChildren}という文字列に入れます。
3277+AWKの@code{split}関数は、連想配列のインデックスを構成しているエレメントの組(親と子)を分割するのに使われます。
3278+子ノードを全て見つければ、このエレメントに対するDTDの@code{<!ELEMENT @dots{} >}という行を表示する準備が整います。
3279+もし、エレメントが子ノードを持たないのであれば、それはツリーの葉なので、DTDの中にそのように記述されます。
3280+そうでなく、子ノードを持つのであれば、見つけた子ノードがエレメントに全て属しているように表示されます。
31133281
3114-正しく @code{<!ATTLIST @dots{} >} の行を見つけ出すのには、似たようなやり方でコーディングされています。
3115-各アトリビュートは、そのエレメントの中で常に現われるかということがチェックされ、もしそうならばそれが表示されます。
3116-そのエレメントに対して常に現われるアトリビュートと、常にではなく時折現れるアトリビュートとの区別は、このジェネレータにおいて最初の段階の工夫です。
3117-しかし、生成された DTD を少し解析すれば、この DTD がかなり大雑把で気前の良い DTD であることに気付くでしょう。
3282+正しく@code{<!ATTLIST @dots{} >}の行を見つけ出すのは、似たような方法でコーディングされています。
3283+各アトリビュートは、そのエレメントの中で常に現われるかということがチェックされ、もし、そうならば、それが表示されます。
3284+そのエレメントに対して常に現われるアトリビュートと、常にではなく、時折現れるアトリビュートとの区別は、このジェネレータにおいて最初の段階の工夫です。
3285+しかし、生成されたDTDを少し解析すれば、このDTDが、かなり大雑把で気前の良いDTDであることに気付くでしょう。
31183286
31193287 @itemize
31203288 @item
3121-子エレメントがどういう順序で現われても良いというようにエレメントが宣言されている。
3289+子エレメントがどういう順序で現われても良いようにエレメントが宣言されている。
3290+
31223291 @item
3123-ツリーの葉であるエレメントがいつも @code{#PCDATA} であるように宣言されている。
3292+ツリーの葉であるエレメントが@code{#PCDATA}であるように常に宣言されている。
3293+
31243294 @item
3125-アトリビュートが常に @code{CDATA} であるように宣言されている。
3295+アトリビュートが@code{CDATA}であるように常に宣言されている。
31263296 @end itemize
31273297
31283298 @cindex Schema
@@ -3130,52 +3300,53 @@ Using the XSD Inference Utility
31303300 http://msdn2.microsoft.com/en-us/library/aa302302.aspx
31313301
31323302 ニーズに合わせてこのジェネレータを改良するのは自由にしてください。
3133-ひょっとしたら、Microsoft の @emph{XSD Inference Utility} の出力行の通りにスキーマファイルを生成することすらできます。
3134-@uref{http://msdn2.microsoft.com/en-us/library/aa302302.aspx, Using the XSD Inference Utility} を見てください。
3135-@code{print_elem()} 関数の残りの部分は、さらなる拡張に対して十分であるはずです。
3136-(最初の段階で集められた) エレメントの子ノードを取って、子ノードをそれぞれ表示するために、この関数を再帰的に使います。
3137-@cindex 再帰
3303+ひょっとしたら、Microsoftの@emph{XSD Inference Utility}の出力行の通りにスキーマファイルを生成することすらできます。
3304+@uref{http://msdn2.microsoft.com/en-us/library/aa302302.aspx, Using the XSD Inference Utility}を見てください。
3305+@code{print_elem()}関数の残りの部分は、さらなる拡張に対して十分であるはずです。
3306+@cindex recursion
3307+この関数は、(最初の段階で集められた)エレメントの子ノードを取って、子ノードをそれぞれ表示するために、再帰的に呼び出されます。
3308+
31383309
31393310 @node Generating a recursive descent parser from a sample file
31403311 @section サンプルファイルからの再帰下降パーサの生成
31413312 @cindex parser, recursive descent
31423313 @cindex recursion
31433314
3144-XML ファイルをタグ毎に読み取って、タグの前後関係や、その中に埋まっているキャラクタデータを非常に注意深く見ていくプログラムを書かなければならないことは、滅多に無いわけではなく時々あります。
3145-そういったプログラムはタグの並び、インデント、前後関係を検出して、アプリケーションに応じたやり方で、これを全て評価します。
3315+XMLファイルをタグ毎に読み取って、タグの前後関係や、その中に埋まっているキャラクタデータを非常に注意深く見ていくプログラムを書かなければならないことは、滅多に無いわけではなく、時々あります。
3316+そういったプログラムは、タグの並び・インデント・前後関係を検出して、アプリケーションに応じたやり方で、これを全て評価します。
31463317 コンパイラやインタプリタがやっていることとほとんど同じです。
31473318 こういったプログラムのことはパーサと呼びます。
3148-パーサの作成というのは簡単なことではなく、いつかパーサを書かなければならなくなった場合、見本のファイルからパーサの最初の段階を自動的に生成する方法がわかったならばあなたはありがたいと思うでしょう。
3149-極めて当然ですが、あなたのためにパーサを生成してくれそうな商用ツールがいくつかあります。
3150-たとえば、XMLBooster @uref{http://www.xmlbooster.com, XMLBooster} プロダクトは (C、C++、C#、COBOL、Delphi、Java、Ada のうちのいずれかの言語で書かれたあらゆる言語の) パーサを生成するだけでなく、構造化された便利なドキュメンテーションと、あなた独自の XML ファイルを編集する GUI も生成します。
3151-XMLBooster は既存の DTD ファイルやスキーマファイルを用いてそういったものを全て作り出します。
3152-XMLBooster とは異なり、私たちの場合、指定された XML データに DTD ファイルやスキーマファイルが存在しているとは仮定しません。
3153-私たちは、特定の XML データを入力し、そのようなデータのパーサを作り出すパーサジェネレータが欲しいと思っています。
3319+パーサの作成というのは簡単なことではなく、いつかパーサを書かなければならなくなった場合、見本のファイルからパーサの最初の段階を自動的に生成する方法が分かったならば、ありがたいと思うでしょう。
3320+極めて当然ですが、ユーザのためにパーサを生成してくれそうな商用ツールがいくつかあります。
3321+例えば、XMLBooster @uref{http://www.xmlbooster.com, XMLBooster}プロダクトは(C、C++、C#、COBOL、Delphi、Java、Adaのいずれかの言語で記述されたあらゆる言語の)パーサを生成するだけではありません。
3322+構造化された便利なドキュメントと、ユーザ独自のXMLファイルを編集するGUIも生成します。
3323+XMLBoosterは、既存のDTDファイルやスキーマファイルを用いて、そういったものを全て作り出します。
3324+XMLBoosterとは異なり、ここでは、指定されたXMLデータにDTDファイルやスキーマファイルが存在しているとは仮定しません。
3325+特定のXMLデータを入力し、そのようなデータのパーサを作り出すパーサジェネレータが欲しいのです。
31543326 @pindex XMLBooster
31553327
3156-前の @value{SECTION} の @ref{サンプルファイルからの DTD の生成} では、
3157-XML ファイルがどのように解析されて、さまざまな種類のタグの間の文法的な関係を記述した別のファイルをどのように作るかということを既に見ました。
3158-後で見るように、パーサというのはそれと非常によく似た方法で作ることができます。
3159-それでは、この @value{SECTION} では、前の @value{SECTION} のプログラムを変更してみましょう。
3160-その際、@code{print_elem()} 関数以外は何も変更せずにそのままにしておきます。
3328+前の@value{SECTION}(@pxref{Generating a DTD from a sample file})では、XMLファイルがどのように解析されて、さまざまな種類のタグの間の文法的な関係を記述した別のファイルをどのように作るかということを既に見ました。
3329+後で見るように、パーサというのは、それと非常によく似た方法で作ることができます。
3330+それでは、この@value{SECTION}では、前の@value{SECTION}のプログラムを変更してみましょう。
3331+その際、@code{print_elem()}関数以外は何も変更せずにそのままにしておきます。
31613332
3162-またしても、例として @ref{fig:dbfile} (DocBook ファイル) を使いましょう。
3163-この種の DocBook ファイルのパーサは、@ref{fig:parser_dbfile} にあるプログラムのように始めることができるでしょう。
3333+またしても、例としてfig:dbfile(@pxref{fig:dbfile})(DocBookファイル)を使いましょう。
3334+この種のDocBookファイルのパーサは、fig:parser_dbfile(@pxref{fig:parser_dbfile})にあるプログラムのように始めることができます。
31643335 @cindex DocBook
3165-このパーサの @code{BEGIN} 部分では、一番最初のタグが @code{NextElement()} 関数 (後述) によって読み込まれます。
3166-この一番最初のタグが @code{book} タグであれば、このタグにちなんで名付けられた関数へと実行が移されます。
3167-そうでなければ、パーサは XML ファイルのルートタグが期待されたものではないとみなし、エラーメッセージと共に終了します。
3168-@code{parse_book} 関数にはループがあって、@code{book} の閉じタグが読み込まれるまでタグを一つ一つ読んでいきます。
3169-その合間には、下位の各タグを存在が許されているタグの組と照合し、そのタグを処理する別の関数を起動します。
3336+このパーサの@code{BEGIN}部分では、一番最初のタグが@code{NextElement()}関数(後述)によって読み込まれます。
3337+この一番最初のタグが@code{book}タグであれば、このタグにちなんで名付けられた関数へと実行が移されます。
3338+そうでなければ、パーサは、XMLファイルのルートタグが期待されたものではないとみなし、エラーメッセージと共に終了します。
3339+@code{parse_book}関数にはループがあって、@code{book}の閉じタグが読み込まれるまでタグを一つ一つ読んでいきます。
3340+その合間には、下位の各タグを、存在が許されているタグの組と照合し、そのタグを処理する別の関数を起動します。
31703341 思わぬタグの名前が現われると警告メッセージが出されますが、パーサは終了しません。
31713342
31723343 このパーサにおける最も重要な原則は、@b{タグの名前毎に、その種のタグを解析する関数が一つ存在する}ということです。
3173-XML ファイルを解析している間、こういった関数が互いに起動されます (XML のマークアップブロックが再帰的に構成されていれば、恐らく再帰的に関数が呼び出されます)。
3174-これらの関数はそれぞれ、その中の冒頭にコメントが付いていて、この名前を持つタグに付けられるアトリビュートが宣言されています。
3175-さて、@code{parse_book} 関数を見てください。
3344+XMLファイルを解析している間、こういった関数が互いに起動されます(XMLのマークアップブロックが再帰的に構成されていれば、恐らく、再帰的に関数が呼び出されます)。
3345+これらの関数は、その中の冒頭にコメントがそれぞれ付いていて、この名前を持つタグに付けられるアトリビュートが宣言されています。
3346+さて、@code{parse_book}関数を見てください。
31763347 そして、このような関数を生成しなければならなかったらと想像してみてください。
3177-DTD ジェネレータを書いた際、各種のタグに関する情報をどのように保存したか思い出してください。
3178-タグに関して必要な情報は既に全て利用可能で、ここでは違う種類の出力を作らなければならないだけであることがわかるでしょう。
3348+DTDジェネレータを書いた際、各種のタグに関する情報をどのように保存したか思い出してください。
3349+タグに関して必要な情報は既に全て利用可能で、ここでは違う種類の出力を作らなければならないだけであることが分かるでしょう。
31793350
31803351 @float Figure,fig:parser_dbfile
31813352 @example
@@ -3203,41 +3374,43 @@ function parse_book() @{
32033374 @}
32043375 @}
32053376 @end example
3206-@caption{大変シンプルな DocBook ファイルのための生成されたパーサの冒頭}
3377+@caption{大変シンプルなDocBookファイルのための生成されたパーサの冒頭}
32073378 @end float
32083379
3209-さて、沿うべき原則 (下向き再帰) は明確ですので、細部に取り掛かることができます。
3210-パーサジェネレータを理解する上で最も難しい問題は、関係するテキストやデータの種類をかき混ぜてしまうことの危険性であることがわかります。
3211-何が起きているのかを理解しようとしてぐるぐる巡ってしまうときはいつでも、考えているデータの種類のことを思い出してください。
3380+さて、沿うべき原則(下向き再帰)は明確ですので、細部に取り掛かることができます。
3381+パーサジェネレータを理解する上で最も難しい問題は、関係するテキストやデータの種類をかき混ぜてしまうことの危険性であることが分かります。
3382+何が起きているのかを理解しようとして、ぐるぐる巡ってしまう時は、いつでも、考えているデータの種類のことを思い出してください。
3383+
32123384 @itemize
3213-@item @b{XML データ}、これは@emph{生成された}パーサでパースされるべきもの。
3214-@item @b{AWK のデータ構造}、これはタグの関係を保存するためもの。
3215-@item @b{パーサ}@emph{ジェネレータ}、今実際に書いているもの。
3385+@item @b{XMLデータ}、これは、@emph{生成された}パーサでパースされるべきもの。
3386+@item @b{AWKのデータ構造}、これは、タグの関係を保存するためもの。
3387+@item @b{パーサ}@emph{ジェネレータ}、実際に今書いているもの。
32163388 @item @b{パーサ}、ジェネレータで@emph{生成される}もの。
32173389 @end itemize
32183390
32193391 従来の言語パーサは入力テキストをトークン単位で読みます。
32203392 この仕事は、低レベルの文字リーダと高レベルの文法チェッカに振り分けられます。
3221-最も低レベルのところでは@emph{スキャナ}がトークンを取り出します。
3222-スキャナはこのトークンをパーサ自体にリターンします。
3223-@emph{生成された} XML データのパーサでは、私たちが使う XML リーダの中にスキャナが隠れていますので、独自のスキャナは必要ありません。
3224-生成しなければならないもののうちまだ残っているものは、呼び出す毎に次のトークンを読む関数です。
3225-@ref{fig:parser_generated_next_element} にあるトークン単位のリーダは、以前に見たことのある@emph{プルパーサ}スタイルで実装されています。
3226-このリーダを実装している @code{NextElement()} 関数は、生成された各パーサで同じもののままであることに注意してください。
3227-@code{getline} で XML ファイルを読んでいる間、このトークンリーダは、トークンストリームの以下のイベントを待ち受けています。
3393+最も低レベルのところでは、@emph{スキャナ}がトークンを取り出します。
3394+スキャナは、このトークンをパーサ自体にリターンします。
3395+@emph{生成された}XMLデータのパーサでは、使用するXMLリーダの中にスキャナが隠れていますので、独自のスキャナは必要ありません。
3396+生成しなければならないものの中でまだ残っているものは、呼び出すたびに次のトークンを読む関数です。
3397+fig:parser_generated_next_element(@pxref{fig:parser_generated_next_element})にあるトークン単位のリーダは、以前に見たことのある@emph{プルパーサ}スタイルで実装されています。
3398+このリーダを実装している@code{NextElement()}関数は、生成された各パーサで同じもののままであることに注意してください。
3399+@code{getline}でXMLファイルを読んでいる間、このトークンリーダは、トークンストリームの以下のイベントを待ち受けています。
3400+
32283401 @itemize
3229-@item @code{XMLSTARTELEM} はリターンする新しいタグ。
3230-@item @code{XMLENDELEM} はリターンするマークアップブロックの終わり。
3231-@item @code{XMLCHARDATA} はマークアップブロックに埋め込まれたテキスト。
3232-@item @code{XMLERROR} はエラーを表示するもので、終了処理が発生します。
3402+@item @code{XMLSTARTELEM}は、リターンされる新しいタグです。
3403+@item @code{XMLENDELEM}は、リターンされるマークアップブロックの終わりです。
3404+@item @code{XMLCHARDATA}は、マークアップブロックに埋め込まれたテキストです。
3405+@item @code{XMLERROR}は、エラーを表示するもので、終了処理を発生します。
32333406 @end itemize
32343407
3235-マークアップブロックに埋め込まれたテキストは関数の戻り値としては返されませんが、大域変数の @code{data} に格納されます。
3236-この関数はタグの名前を返すためのものです。
3408+マークアップブロックに埋め込まれたテキストは、関数の戻り値としては返されませんが、大域変数の@code{data}に格納されます。
3409+この関数は、タグの名前を返すためのものです。
32373410 マークアップブロックの開始でも終了でも問題ありません。
3238-呼び出し側がマークアップブロックの開始あるいは終了を区別したいような場合は、@code{XMLSTARTELEM} あるいは @code{XMLENDELEM} にセットされているかどうかを見ればそうすることが可能です。
3239-XML ファイルの終わりに到達したときだけ空文字列をリターンします。
3240-トークンストリームが終わりに達したときにそれを検出するかどうかは呼び出し側にまかされています。
3411+マークアップブロックの開始、あるいは、終了を、呼び出し側で区別したいような場合は、@code{XMLSTARTELEM}、あるいは、@code{XMLENDELEM}がセットされているかどうかを見れば可能です。
3412+XMLファイルの終わりに到達した時だけ空文字列をリターンします。
3413+トークンストリームが終わりに達した時にそれを検出するかどうかは呼び出し側にまかされています。
32413414
32423415 @float Figure,fig:parser_generated_next_element
32433416 @example
@@ -3255,18 +3428,19 @@ function NextElement() @{
32553428 @caption{プルスタイルトークンリーダ、生成されたパーサすべてで同一のもの}
32563429 @end float
32573430
3258-ここまでこの @value{SECTION} で見てきたコードは全て@emph{生成される}コードでした。
3259-あなた自身のプログラムにこのコードをコピーする意味はありません。
3260-今からが@emph{ジェネレータ}自体になります。
3261-前に述べたように、このジェネレータは、前の @value{SECTION} の @code{dtd_generator.awk} と同一のものです。
3262-あなたは、@code{print_elem()} 関数を、@ref{fig:parser_generator1} と @ref{fig:parser_generator2} にあるバージョンと置き換えることだけはしなくてはなりません。
3263-@code{print_elem()} 関数の冒頭は理解するのが簡単です。
3264-@code{NextElement()} 関数を生成しますが、この関数は @ref{fig:parser_generated_next_element} で見た関数です。
3265-@code{NextElement()} 関数は一度だけ生成する必要がありますので、ルートタグ (@code{depth == 1}) が処理された時にだけ生成します。
3266-@code{NextElement()} のように、@ref{fig:parser_dbfile} の @code{BEGIN} パターンも一度だけ必要ですので、@code{NextElement()} の直後に生成します。
3267-その次は、@ref{fig:parser_dbfile} で見たような XML アトリビュートに関するコメントの生成です。
3268-このコーディングスタイルは、@ref{fig:dtd_generator.awk} を学習したのであれば、初めて見るものではないはずです。
3269-ルートではない (@code{depth > 1}) タグに対する @code{print_elem()} の呼び出し毎に一つの関数が生成されることに注意してください (生成される関数はタグにちなんで名付けられます)。
3431+ここまで、この@value{SECTION}で見てきたコードは、全て、@emph{生成される}コードでした。
3432+ユーザ自身のプログラムにこのコードをコピーする意味はありません。
3433+今からは、@emph{ジェネレータ}自体になります。
3434+前に述べたように、このジェネレータは、前の@value{SECTION}の@code{dtd_generator.awk}と同一のものです。
3435+ユーザは、@code{print_elem()}関数を、fig:parser_generator1(@pxref{fig:parser_generator1})とfig:parser_generator2(@pxref{fig:parser_generator2})にあるバージョンと置き換えることだけはしなくてはなりません。
3436+@code{print_elem()}関数の冒頭部分は理解しやすいです。
3437+@code{NextElement()}関数を生成します。
3438+この関数はfig:parser_generated_next_element(@pxref{fig:parser_generated_next_element})で見た関数です。
3439+@code{NextElement()}関数は一度だけ生成する必要がありますので、ルートタグ(@code{depth == 1})が処理される時にだけ生成します。
3440+@code{NextElement()}と同様、fig:parser_dbfile(@pxref{fig:parser_dbfile})の@code{BEGIN}パターンも一度だけ必要ですので、@code{NextElement()}の直後に生成します。
3441+その次は、fig:parser_dbfile(@pxref{fig:parser_dbfile})で見たようなXMLアトリビュートに関するコメントの生成です。
3442+このコーディングスタイルは、fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})を学習したのであれば、初めて見るものではないはずです。
3443+ルートではない(@code{depth > 1})タグに対する@code{print_elem()}の呼び出し毎に一つの関数が生成されることに注意してください(生成される関数はタグにちなんで名付けられます)。
32703444
32713445 @float Figure,fig:parser_generator1
32723446 @example
@@ -3308,16 +3482,18 @@ function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{
33083482 @}
33093483 print ""
33103484 @end example
3311-@caption{@file{parser_generator.awk} にある @code{print_elem()} の最初の部分}
3485+@caption{@file{parser_generator.awk}にある@code{print_elem()}の最初の部分}
33123486 @end float
33133487
3314-これが @code{print_elem()} の最初の部分でした。
3315-@ref{fig:parser_generator2} にあるのが 2 番目の部分で、関数の本体を作りだすものです (生成された例として、@ref{fig:parser_dbfile} にある @code{parse_book()} を見てください)。
3316-新しく生成された関数の本体には @code{while} ループがあって、このループは、現在読んでいるマークアップブロックが閉じタグで終了するまでトークンを読み続けます。
3317-またその間、埋め込まれたマークアップブロックがそれぞれ検出され、他の関数で完全に読み取られます。
3318-埋め込まれたマークアップブロックのタグは、それがそこに存在することが可能なタグの中に入っている時だけ受け付けられます。
3319-この関数の残りの部分は初めてみるものではないはずで、埋め込まれているマークアップブロックのツリーをより深く再帰的に降りていって、そのタグの種類毎に一つの関数を生成します。
3320-@cindex 再帰
3488+これが、@code{print_elem()}の最初の部分でした。
3489+fig:parser_generator2(@pxref{fig:parser_generator2})にあるのが2番目の部分で、関数の本体を作りだすものです(生成された例としては、fig:parser_dbfile(@pxref{fig:parser_dbfile})にある@code{parse_book()}を見てください)。
3490+新しく生成された関数の本体には@code{while}ループがあります。
3491+このループは、現在読んでいるマークアップブロックが閉じタグで終了するまでトークンを読み続けます。
3492+また、その間、埋め込まれたマークアップブロックがそれぞれ検出され、他の関数で完全に読み取られます。
3493+埋め込まれたマークアップブロックのタグは、そのタグが、そこに存在することが可能なタグの中に入っている時だけ受け付けられます。
3494+この関数の残りの部分は初めてみるものではないはずです。
3495+埋め込まれているマークアップブロックのツリーを、より深く再帰的に降りていって、そのタグの種類毎に一つの関数を生成します。
3496+@cindex recursion
33213497
33223498 @float Figure,fig:parser_generator2
33233499 @example
@@ -3356,67 +3532,74 @@ function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{
33563532 @}
33573533 @}
33583534 @end example
3359-@caption{@file{parser_generator.awk} にある @code{print_elem()} の 2 番目の部分}
3535+@caption{@file{parser_generator.awk}にある@code{print_elem()}の2番目の部分}
33603536 @end float
33613537
3362-見本のファイルから完全なパーサが生成される時、さらなる改良のためのスタート地点としてよく役立つコメントが付けられたパーサをあなたは手にしています。
3363-最も重要な事ですが、XML アトリビュートを評価する部分と、結果を表示する部分にあなたはコードを追加するでしょう。
3364-これで、パーシングビジネスを簡単に始められるように見えるかもしれませんが、このアプローチにはいくらか制限があることに気付くはずです。
3538+見本ファイルから完全なパーサが生成された時点で、コメント付きのパーサを手にしていることになります。
3539+このパーサは、さらに改良するためのスタート地点として有用です。
3540+最も重要な事ですが、XMLアトリビュートを評価する部分と、結果を表示する部分にコードを追加することになるでしょう。
3541+これで、パーシングビジネスを簡単に始められるように思えるかもしれませんが、このアプローチにはいくらか制限があることに気付くはずです。
3542+
33653543 @itemize
3366-@item XML における@b{タグ名}は、有効な Unicode であればどんな名前でも構いません。
3544+@item XMLにおける@b{タグ名}は、有効なUnicodeであればどんな名前でも構いません。
33673545 @cindex Unicode
3368-この名前は、生成される AWK のソースコードの中で関数名として使われますので、たとえば、タグ名にウムラウトの文字を含んでいると問題が発生するでしょう。
3369-ウムラウトの文字は AWK の関数名としては許されていません。
3546+この名前は、生成されるAWKのソースコードの中で関数名として使われますので、例えば、タグ名にウムラウト文字を含んでいると問題が発生します。
3547+ウムラウト文字は、AWKの関数名としては許されていません。
33703548 生成されるコードの中でタグ名を使うのを止めて、元のタグ名から、列挙/生成された名前にマッピングする方法を代わりに使わなければなりません。
3549+
33713550 @item コード生成フレームワークにとって@b{ラウンドトリップエンジニアリング}というのは問題となります。
3372-パーサを生成したあと、別の見本ファイルで使われている新しいタグを追加したいと思った場合何が起きるでしょうか?
3551+パーサを生成したあと、別の見本ファイルで使われている新しいタグを追加したいと思った場合、何が起きるでしょうか。
33733552 これは難しい問題です。
3374-多分一番良い解決策は、生成されたパーサに対する手作業の修正を、生成されたパーサ自体でなく、その見本ファイルの PI (プロセッシングインストラクション) に挿入することによってコード生成処理を変更してしまうことです。
3375-パーサジェネレータはこの PI を取り上げて、その内容を生成したコードにコピーしなければなりません。
3553+多分一番良い解決策は、生成されたパーサに対する手作業の修正を、生成されたパーサ自体でなく、その見本ファイルのPI(プロセッシングインストラクション)に挿入することによってコード生成処理を変更してしまうことです。
3554+パーサジェネレータはこのPIを取得し、その内容を、生成したコードにコピーしなければなりません。
33763555 @cindex Schema
3377-@item XML データの意味上の制約はスキーマ言語でもっと簡単にコード化できます。
3378-パーサジェネレーションの問題に対するもっと高度なアプローチは、既存の Schema 仕様をパーサの中に編入してしまうことかもしれません。
3379-手元にある Schema 言語がそれ自身 XML で書かれている時、これは簡単な解決策のように見えるかもしれません。
3380-しかし、じっと見てみると、このアプローチは多くの落とし穴がある本当のコンパイラ構築作業です。
3556+
3557+@item XMLデータの意味上の制約は、スキーマ言語によってもっと簡単にコード化できます。
3558+パーサ生成の問題に対するもっと高度なアプローチは、既存のSchema仕様をパーサの中に編入してしまうことかもしれません。
3559+手元にあるSchema言語がそれ自身XMLで書かれている時、これは簡単な解決策のように見えるかもしれません。
3560+しかし、じっと見てみると、このアプローチは、多くの落とし穴がある本当のコンパイラ構築作業となります。
33813561 @end itemize
33823562
3563+
33833564 @node A parser for Microsoft Excel's XML file format
3384-@section Microsoft Excel の XML ファイルに対するパーサ
3565+@section Microsoft ExcelのXMLファイルに対するパーサ
33853566 @cindex Microsoft Excel
33863567
3387-見本の XML ファイルからテキストファイルを生成することについて書かれた前の二つの @value{SECTION} はかなり抽象的で、あなたを混乱させたかもしれませんでした。
3388-この @value{SECTION} は違います。
3389-ここでは、@file{parser_generator.awk} プログラムを動かして、それが何に役立つかを見ていきます。
3390-Microsoft の Excel アプリケーションが作る XML の出力形式のためのパーサを生成します。
3391-私たちの出発点はインターネットから取得した XML ファイルです。
3568+見本のXMLファイルからテキストファイルを生成することについて書かれた前の二つの@value{SECTION}はかなり抽象的で、混乱したかもしれません。
3569+この@value{SECTION}は違います。
3570+ここでは、@file{parser_generator.awk}プログラムを動かして、それが何に役立つかを見ていきます。
3571+MicrosoftのExcelアプリケーションが作るXMLの出力形式のためのパーサを生成します。
3572+出発点は、インターネットから取得したXMLファイルです。
33923573
33933574 このパーサジェネレータ動かす前に、もう一度繰り返しましょう。
3394-パーサジェネレータは @ref{fig:dtd_generator.awk} と @ref{fig:parser_generator1} と @ref{fig:parser_generator2} にあるソースコードで構成されています。
3395-この三つの断片を @file{parser_generator.awk} という名前の一つのファイルに入れてください。
3575+パーサジェネレータは、fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})とfig:parser_generator1(@pxref{fig:parser_generator1})とfig:parser_generator2(@pxref{fig:parser_generator2})にあるソースコードで構成されています。
3576+この三つの断片を、@file{parser_generator.awk}という名前の一つのファイルに入れてください。
33963577
3397-ジェネレータで使用する、Microsoft Excel で作った XML ファイルを探す時間です。
3578+ジェネレータで使用するMicrosoft Excelで作ったXMLファイルを探す時間です。
33983579 見本ファイルは、問題となる構造的なエレメントとアトリビュートを全て含んでいなければなりません。
33993580 これらのエレメントとアトリビュートは、生成されたパーサによって後で認識されるだけです。
34003581 インターネット上で、可能な限り多くの妥当なエレメントとアトリビュートを含む見本ファイルを探しました。
34013582 自由に利用できて、テンプレートとして十分役立つかもしれないファイルをいくつか見つけましたが、全ての種類のエレメントとアトリビュートを含むものはありませんでした。
3402-ほぼ完全なもののうちの二つは以下のものです。
3403-これらのコマンドを起動すれば、カレントディレクトリの中にこの二つのファイルを確認できるでしょう。
3583+ほぼ完全なものの二つが以下のものです。
3584+これらのコマンドを起動すれば、カレント作業ディレクトリの中に、この二つのファイルを確認できるでしょう。
34043585
34053586 @smallexample
34063587 wget http://csislabs.palomar.edu/Student/csis120/Matthews/StudentDataFiles/Excel/PastaMidwest.xml
34073588 wget http://csislabs.palomar.edu/Student/csis120/Matthews/StudentDataFiles/Excel/Oklahoma2004.xml
34083589 @end smallexample
34093590
3410-もしあなた自身の見本ファイルをいくつかお持ちならば、このように他のものと一緒にそのファイルの名前を渡してください。
3591+もし、独自の見本ファイルを持っていれば、次のように、他のものと一緒にそのファイルの名前を渡してください。
34113592
34123593 @smallexample
34133594 gawk -f parser_generator.awk PastaMidwest.xml Oklahoma2004.xml > ms_excel_parser.awk
34143595 @end smallexample
34153596
3416-今、カレントワーキングディレクトリに @file{ms_excel_parser.awk} という新しいファイルが見つかるでしょう。
3417-これは再帰下降パーサで、前述のテンプレートファイルに存在する全てのエレメントをパースして見分けるための用意がしてあります。
3418-@cindex parser、再帰下降
3419-この点を証明するために、新しいパーサをこのテンプレートファイルで動作させて、テンプレートファイルがルールに従っているかどうかを調べさせます。
3597+これで、カレント作業ディレクトリに、@file{ms_excel_parser.awk}という新しいファイルができます。
3598+これは、再帰下降パーサです。
3599+前述のテンプレートファイルに存在する全てのエレメントをパースして見分けるための用意がしてあるものです。
3600+@cindex parser, recursive descent
3601+この点を証明するために、新しいパーサを、このテンプレートファイルで動作させて、テンプレートファイルがルールに従っているかどうかを調べさせます。
3602+
34203603 @page
34213604 @example
34223605 gawk -f ms_excel_parser.awk PastaMidwest.xml
@@ -3425,10 +3608,10 @@ gawk -f ms_excel_parser.awk xmltv.xml
34253608 could not find root element 'Workbook'
34263609 @end example
34273610
3428-当然、@ref{XMLTV ファイルからタブ付き ASCII への変換}から持ってきた @file{xmltv.xml} ファイルはこのルールに従わなかった唯一のファイルでした。
3429-これは驚くことではありません。
3430-Microsoft Excel からエクスポートされた XML ファイルはそれぞれそのルートノードとして @file{Workbook} タイプのノードを持っています。
3431-これらの @file{Workbook} ノードは、@file{ms_excel_parser.awk} プログラムの以下に示す関数の冒頭で正しくパースされます。
3611+当然、別の節(@pxref{Convert XMLTV file to tabbed ASCII})から持ってきた@file{xmltv.xml}ファイルはこのルールに従わなかった唯一のファイルでした。
3612+これは、驚くことではありません。
3613+Microsoft ExcelからエクスポートされたXMLファイルはそれぞれそのルートノードとして@file{Workbook}という種類のノードを持っています。
3614+これらの@file{Workbook}ノードは、@file{ms_excel_parser.awk}プログラムの以下に示す関数の冒頭で正しくパースされます。
34323615
34333616 @float Figure,fig:ch6_ms_excel_parser
34343617 @example
@@ -3465,35 +3648,35 @@ function parse_Workbook() @{
34653648 @}
34663649 @}
34673650 @end example
3468-@caption{生成された @file{ms_excel_parser.awk} のコード片}
3651+@caption{生成された@file{ms_excel_parser.awk}のコード片}
34693652 @end float
34703653
34713654
3472-ルートノードが @file{Workbook} タイプのノードでは@emph{ない} (@file{xmltv.xml} ファイルを使った場合のような) 場合、その時はルートエレメントが無いことの報告が表示されます。
3473-すぐにわかるように、@file{Workbook} にはいくつか必須のアトリビュートがあります。
3474-生成されたパーサはこれらの存在についてチェックするようにも拡張できるでしょう。
3475-その上、@file{Workbook} は、@file{Styles}、@file{Worksheet}、@file{ExcelWorkbook}、@file{OfficeDocumentSettings}、@file{DocumentProperties} というタイプのノードの並びです。
3655+ルートノードが@file{Workbook}タイプのノードでは@emph{ない}(@file{xmltv.xml}ファイルを使った場合のような)場合、ルートエレメントが無いという報告が表示されます。
3656+すぐに分かるように、@file{Workbook}にはいくつか必須のアトリビュートがあります。
3657+生成されたパーサは、これらの存在についてチェックするようにも拡張できるでしょう。
3658+さらに、@file{Workbook}は、@file{Styles}、@file{Worksheet}、@file{ExcelWorkbook}、@file{OfficeDocumentSettings}、@file{DocumentProperties}というタイプのノードが並んだものです。
34763659
34773660
34783661 @ignore
34793662 @cindex Schema
34803663 @section Converting Schema files
3481-Schema ファイルは XML ファイルに対する制約の正式な表記です。
3482-Schema ファイル自体も XML ファイルで保存されます。
3664+Schemaファイルは、XMLファイルに対する制約の正式に記したものです。
3665+Schemaファイル自体もXMLファイルとして保存されます。
34833666 @end ignore
34843667
34853668 @ignore
34863669 @section Converting XSL programs
3487-XSL スクリプトは XML ファイルの変換するためのプログラムを目的として作られています。
3488-このスクリプト自体も xmlgawk で変換できる XML ファイルです。
3670+XSLスクリプトは、XMLファイルの変換するためのプログラムを目的として作られています。
3671+このスクリプト自体もxmlgawkで変換できるXMLファイルです。
34893672
3490-Sun は、入力されて Java XSL の入力を読み込んで Java の出力を生成するコンパイラをリリースしました。
3491-このコンパイラ (@uref{http://xml.coverpages.org/saxon42Ann.html, xsltc}) は Saxon ツールの一部としてフリーなライセンスの下に置かれました。
3673+Sunは、入力されてJava XSLの入力を読み込んでJavaの出力を生成するコンパイラをリリースしました。
3674+このコンパイラ(@uref{http://xml.coverpages.org/saxon42Ann.html, xsltc})はSaxonツールの一部としてフリーなライセンスの下に置かれました。
34923675
34933676 @section Compiling a GUI from a GLADE project file
3494-Glade は GUI を作るためのツールです。
3495-GUI を作成した結果は XML ファイルに収められます。
3496-libglade はそのような GUI の記述を ADA や Java、Python のコードにコンパイルすることができます。
3677+Gladeは、GUIを作るためのツールです。
3678+GUIを作成した結果はXMLファイルに収められます。
3679+libgladeは、そのようなGUIの記述をADAやJava、Pythonのコードにコンパイルすることができます。
34973680
34983681 http://www-106.ibm.com/developerworks/library/l-gnome-glade/
34993682
@@ -3502,16 +3685,18 @@ http://www-106.ibm.com/developerworks/library/l-gnome-glade/phonebook.glade.txt
35023685 http://users.bigpond.net.au/mlm/libglade/
35033686 @end ignore
35043687
3688+
35053689 @ignore
3506-@node XMark — An XML Benchmark Project
3690+@node XMark - An XML Benchmark Project
35073691 @chapter XMark - An XML Benchmark Project
3508-XMark プロジェクトの狙いは、ユーザや開発者に対して、彼らのリポジトリの特徴を見抜く能力を与えるベンチマークスイートを提供することです。
3692+
3693+XMarkプロジェクトの狙いは、ユーザや開発者に対して、リポジトリの特徴を見抜く能力を与えるベンチマークスイートを提供することです。
35093694
35103695 http://www.ins.cwi.nl/projects/xmark/Assets/xmlquery.txt
35113696
3512-このベンチマークの小さな問題は、xmlgawk の能力をそのテストへ向けるための好機です。
3513-これで、xmlgawk が何が得意なのか、その欠陥はどこなのかを見つけだすことができます。
3514-コアの xmlgawk と xmllib と xmltree を使ってよい時。
3697+このベンチマークの小さな問題は、xmlgawkの能力をそのテストへ向けるための好機です。
3698+これで、xmlgawkが何が得意なのか、その欠陥はどこなのかを見つけだすことができます。
3699+コアのxmlgawkとxmllibとxmltreeを使ってよい時。
35153700 @end ignore
35163701
35173702 @ignore
@@ -3770,32 +3955,33 @@ SORTBY (.)
37703955 @end ignore
37713956
37723957
3773-
37743958 @node Reference of XML features
3775-@chapter XML 機能のリファレンス
3959+@chapter XML機能のリファレンス
37763960
37773961 @menu
3778-* gawk インタプリタに組込まれた XML 機能::
3779-* XMLgawk コア言語インターフェイスの要約::
3962+* XML features built into the gawk interpreter::
3963+* XMLgawk Core Language Interface Summary::
37803964 * xmllib::
37813965 * xmltree::
37823966 @end menu
37833967
3784-この @value{CHAPTER} はリファレンスとして作られています。
3785-それは、正確で包括的な方法で、その使用を動機付けすることなく、機能をリストしています。
3786-まず最初は、XMLgawk の拡張で利用している組み込み変数と環境変数を全てリストしている @value{SECTION} です。
3787-その次は、これらの変数を使う二つの違うやり方を説明する @value{SECTION} です。
3788-そして最後は、XMLgawk 拡張の上に構築されたライブラリについて説明する二つの @value{SECTION} です。
3968+この@value{CHAPTER}は、リファレンスとして作られています。
3969+リファレンスは、機能の利用を動機付けすることなく、正確かつ包括的な方法で機能をリストしています。
3970+まず、最初は、XMLgawkの拡張で利用している組み込み変数と環境変数を全てリストしている@value{SECTION}です。
3971+その次は、これらの変数を使う二つの違うやり方を説明する@value{SECTION}です。
3972+そして、最後は、XMLgawk拡張の上に構築されたライブラリについて説明する二つの@value{SECTION}です。
3973+
37893974
37903975 @node XML features built into the gawk interpreter
3791-@section gawk インタプリタに組込まれた XML 機能
3792-この @value{SECTION} は GNU Awk の XML 拡張を構成する全ての変数と関数を紹介します。
3793-各変数毎に、例となる XML の断片一つを使って、どういう XML コードが、セットされるパターンの原因となるのかを説明します。
3794-このイベントが通過した後はその変数は空文字列を含んでいます。
3795-ですので、同じ種類のイベントが別の値をセットしたとき、値を保持している変数を後になるまで信頼@emph{できません}。
3796-私たちは行を読んでいるわけでは@emph{ありません} (XML イベントを見ている) ので、@code{$0} 変数は通常何かテキスト値がセットされているのではなく空文字列がセットされています。
3797-@code{$0} に値をセットすると XML モードで副作用が見られます。
3798-これはこのリファレンスでそのように説明します。
3976+@section gawkインタプリタに組込まれたXML機能
3977+
3978+この@value{SECTION}は、GNU AwkのXML拡張を構成する全ての変数と関数を紹介します。
3979+各変数毎に、例となるXMLの断片一つを使い、パターンが設定されるXMLコードがどういうものなのかを説明します。
3980+このイベントを通り過ぎた後は、その変数には空文字列が入っています。
3981+ですから、同じ種類のイベントが別の値をセットした時、値を保持している変数を後になるまで信頼@emph{できません}。
3982+行を読んでいるわけでは@emph{ありません}(XMLイベントを見ている)ので、@code{$0}変数は、通常、何かテキスト値がセットされているのではなく、空文字列がセットされています。
3983+@code{$0}に値をセットするとXMLモードでは副作用が現われます。
3984+これは、このリファレンスで説明します。
37993985
38003986 @subsection @code{XMLDECLARATION}: ドキュメントの開始を示す整数
38013987 @cindex @code{XMLDECLARATION}
@@ -3804,10 +3990,10 @@ SORTBY (.)
38043990 <?xml @b{version="1.0" encoding="UTF-8"}?>
38053991 @end example
38063992
3807-XML 文書に (XML 宣言を含む) ヘッダがある場合、そのヘッダはあらゆる他の種類のデータよりも前方に常に置かれます。
3993+XML文書に(XML宣言を含む)ヘッダがある場合、そのヘッダは、あらゆる他の種類のデータよりも前方に常に置かれます。
38083994 そのデータが、コメントやキャラクタデータ、プロセッシングインストラクションであってもです。
3809-それゆえ、@code{XMLDECLARATION} は (ともかく一つ存在すれば)、そのファイルから読まれる常に一番最初のイベントです。
3810-そのイベントが起きた時、@code{XMLATTR} 配列が、インデックスアイテムの @code{VERSION}、@code{ENCODING}、@code{STANDALONE} で定義されます。
3995+それゆえ、@code{XMLDECLARATION}がとにかく一つ存在すれば、そのファイルから読み込まれる常に一番最初のイベントとなります。
3996+そのイベントが起きた時、@code{XMLATTR}配列は、インデックスアイテムの@code{VERSION}、@code{ENCODING}、@code{STANDALONE}で定義されます。
38113997
38123998 @cindex @code{XMLATTR["VERSION"]}
38133999 @cindex @code{XMLATTR["ENCODING"]}
@@ -3820,37 +4006,40 @@ XMLDECLARATION @{
38204006 standalone = XMLATTR["STANDALONE"]
38214007 @}
38224008 @end example
3823-@code{XMLATTR} 配列の各エントリは、それぞれの値が XML データに存在する場合にだけ存在します。
38244009
3825-@subsection @code{XMLMODE}: XML 処理の切り替えのための整数
4010+@code{XMLATTR}配列の各エントリは、それぞれの値がXMLデータに存在する場合にだけ存在します。
4011+
4012+@subsection @code{XMLMODE}: XML処理の切り替えのための整数
38264013 @cindex @code{XMLMODE}
3827-この整数変数はインタプリタによって変更されません。
3828-初期値は 0 です。
3829-ユーザがこの変数を (0 以外の値に) セットすると、それ以後オープンされる各ファイルは XML ファイルとして読まれるということを示します。
3830-この変数を再び 0 に設定すると、インタプリタが、次からのファイルをまた通常のテキストファイルとして読むようになります。
4014+
4015+この整数変数は、インタプリタによって変更されません。
4016+初期値は0です。
4017+ユーザがこの変数を(0以外の値に)セットすると、それ以後オープンされる各ファイルはXMLファイルとして読まれるということを示します。
4018+この変数を再び0に設定すると、インタプリタが、次からのファイルを、また、通常のテキストファイルとして読むようになります。
38314019
38324020 @table @samp
38334021 @item XMLMODE
3834- = 0: 次にオープンされるファイルの XML パーシングを無効にする。
4022+ = 0: 次にオープンされるファイルのXMLパーシングを無効にする。
4023+
38354024 @item XMLMODE
3836- = 1: 次にオープンされるファイルの XML パーシングを有効にする。
4025+ = 1: 次にオープンされるファイルのXMLパーシングを有効にする。
4026+
38374027 @item XMLMODE
3838- = -1: XML パーシングを有効にして、連結した XML ドキュメントを有効にする。
4028+ = -1: XMLパーシングを有効にして、連結したXMLドキュメントを有効にする。
38394029 @end table
38404030
4031+いくつかはXMLファイルで、その他はテキストファイルというように、複数のファイルを同時にオープンすることが許されています。
4032+ファイルをあるモードでオープンした後、@code{XMLMODE}の値を変更して、別のモードで@emph{同じ}ファイルを読み続けるようなことはできません。
4033+複数のルートエレメントを持つXMLファイルを読む必要があるユーザはたくさんいます。
4034+そのようなXMLファイルは、(厳密に言うと)本当は整形式ではありません。
4035+整形式のXMLドキュメントはルートエレメントを一つだけ持ちます。
4036+@cindex Well-Formed
4037+@code{XMLMODE}を-1にセットすると、インタプリタは、一つ以上のルートエレメントを持つXMLドキュメントを受け付けるようになります。
38414038
3842-いくつかは XML ファイルでその他はテキストファイルというように、複数のファイルを同時にオープンすることは許されています。
3843-ファイルをあるモード、あるいはもう一つのモードでオープンした後は、@code{XMLMODE} の値を変更したりして、他方のモードで@emph{同じ}ファイルを読み続けるようなことはできません。
3844-複数のルートエレメントを持つ XML ファイルを読む必要があるユーザはたくさんいます。
3845-そのような XML ファイルは、(厳密に言うと) 本当は整形式ではありません。
3846-整形式の XML ドキュメントはルートエレメントを一つだけ持ちます。
3847-@cindex 整形式
3848-@code{XMLMODE} を -1 にセットすると、インタプリタは一つ以上のルートエレメントを持つ XML ドキュメントを受け付けるようになります。
3849-
3850-''@@load xml'' という行を使うと副作用として、XMLMODE が -1 にセットされます。
3851-コマンドラインオプションの ''-l xml'' も同様です。
3852-それで、たいていのユーザは @code{XMLMODE} を直接設定するのではなく、後の二つの方法を好みます。
3853-@code{xgawk} もしくは @code{xmlgawk} という名前で GNU Awk インタプリタを起動すると同じ副作用があります。
4039+「@@load xml」という行を使うと、副作用として、XMLMODEが-1にセットされます。
4040+コマンドラインオプションの「-l xml」も同様です。
4041+そのため、たいていのユーザは@code{XMLMODE}を直接設定するのではなく、後者の方法を好みます。
4042+@code{xgawk}、もしくは、@code{xmlgawk}という名前でGNU Awkインタプリタを起動すると同じ副作用があります。
38544043
38554044 @subsection @code{XMLSTARTELEM}: エレメントに入った時にタグを保持する文字列
38564045 @cindex @code{XMLSTARTELEM}
@@ -3860,12 +4049,13 @@ XMLDECLARATION @{
38604049 </book>
38614050 @end example
38624051
3863-マークアップグロックに入ると、XML パーサはタグ (例の中の @b{book}) を見つけて、その名前を @code{XMLSTARTELEM} 文字列変数へコピーします。
3864-この変数がセットされている時はいつでもその値を取り出して、他の変数へその値を保存することができますが、取り囲んでいる (あるいは、含まれている) マークアップブロックのタグの名前にはアクセスすることは@emph{できません}。
3865-副作用として、連想配列の @code{XMLATTR} と 変数 @code{$0} に値が入れられます。
3866-変数 @code{$0} は XML データに現われた順番でアトリビュートの名前が入っています。
3867-@code{$0} に入っているアトリビュートは空白で区切られています。
3868-@code{$1} から @code{$NF} までの変数には、同じ順番でアトリビュートの名前が入っています。
4052+マークアップブロックに入ると、XMLパーサはタグ(例の中の@b{book})を見つけて、その名前を、@code{XMLSTARTELEM}文字列変数へコピーします。
4053+この変数がセットされている時は、いつでも、その値を取り出して、他の変数へその値を保存することができます。
4054+しかし、取り囲んでいる(あるいは、含まれている)マークアップブロックのタグの名前にはアクセスすることが@emph{できません}。
4055+副作用として、連想配列の@code{XMLATTR}と変数@code{$0}に値が入れられます。
4056+変数@code{$0}は、XMLデータに現われた順番で、アトリビュートの名前が入っています。
4057+@code{$0}に入っているアトリビュートは空白で区切られています。
4058+@code{$1}から@code{$NF}までの変数には、同じ順番で、アトリビュートの名前が入っています。
38694059
38704060 @subsection @code{XMLATTR}: アトリビュートの名前と値を保持する配列
38714061 @cindex @code{XMLSTARTELEM}
@@ -3878,22 +4068,27 @@ XMLDECLARATION @{
38784068 @dots{}
38794069 </book>
38804070 @end example
3881-この連想配列は常に空ですが、@code{XMLSTARTELEM}、@code{XMLDECLARATION}、@code{XMLSTARTDOCT} が true の時は例外です。
3882-このケースの場合はすべて、@code{XMLATTR} は (広い意味で) 名前付きの複数のアトリビュートの値をユーザへ渡すために使われます。
4071+
4072+この連想配列は常に空ですが、@code{XMLSTARTELEM}、@code{XMLDECLARATION}、@code{XMLSTARTDOCT}がtrueの時は例外です。
4073+このケースの場合はすべて、@code{XMLATTR}は、(広い意味で)名前付きの複数のアトリビュートの値をユーザへ渡すために使われます。
4074+
38834075 @itemize
38844076 @item
3885-@code{XMLSTARTELEM} が設定されると、@code{XMLATTR} 配列には、現在パースされているエレメントのアトリビュートの名前が入れられます。
3886-各アトリビュートの名前はこの配列のインデックスとして入れられ、そのアトリビュートの値はインデックスに対応する値として入れられます。
3887-この配列は、@code{XMLENDELEM} がセットされている時でも空であることに注意してください。
4077+@code{XMLSTARTELEM}が設定されると、@code{XMLATTR}配列には、現在パースされているエレメントのアトリビュートの名前が入れられます。
4078+各アトリビュートの名前はこの配列のインデックスとして入れられ、そのアトリビュートの値は、インデックスに対応する値として入れられます。
4079+この配列は、@code{XMLENDELEM}がセットされている時でも空であることに注意してください。
4080+
38884081 @item
3889-@code{XMLDECLARATION} がセットされると、この配列には XML ヘッダのパラメータを反映した、@code{VERSION}、@code{ENCODING}、@code{STANDALONE} という名前の変数が入れられます。
4082+@code{XMLDECLARATION}がセットされると、この配列には、XMLヘッダのパラメータを反映した@code{VERSION}、@code{ENCODING}、@code{STANDALONE}という名前の変数が入れられます。
38904083 これらの各変数はオプショナルです。
4084+
38914085 @item
3892-@code{XMLSTARTDOCT} がセットされると、この配列には、@code{PUBLIC}、@code{SYSTEM}、@code{INTERNAL_SUBSET} と名付けられた、DTD の内部の同名のパラメータを反映した変数が入れられます。
4086+@code{XMLSTARTDOCT}がセットされると、この配列には、@code{PUBLIC}、@code{SYSTEM}、@code{INTERNAL_SUBSET}と名付けられたDTDの内部の同名のパラメータを反映した変数が入れられます。
38934087 これらの各変数はオプショナルです。
38944088 @end itemize
38954089
3896-例の場合だと、@code{XMLSTARTELEM} と @code{XMLATTR} はこのようにセットされます。
4090+例の場合だと、@code{XMLSTARTELEM}と@code{XMLATTR}は次のようにセットされます。
4091+
38974092 @example
38984093 # Print all attribute names and values.
38994094 XMLSTARTELEM = "book"
@@ -3905,10 +4100,11 @@ $2 = "lang"
39054100 NF = 2
39064101 @end example
39074102
3908-@cindex 文字エンコーディング
4103+@cindex character encoding
39094104
39104105 @subsection @code{XMLENDELEM}: エレメントから離れる時にタグを保持する文字列
39114106 @cindex @code{XMLENDELEM}
4107+
39124108 @example
39134109 <book id="hello-world" lang="en">
39144110 <bookinfo>
@@ -3917,15 +4113,18 @@ NF = 2
39174113 @dots{}
39184114 <@b{/book}>
39194115 @end example
3920-マークアップブロックを離れる時点で、XML パーサはタグを見つけ (例では @b{book})、その名前を @code{XMLENDELEM} 文字列変数にコピーします。
4116+
4117+マークアップブロックを離れる時点で、XMLパーサはタグを見つけ(例では@b{book})、その名前を、@code{XMLENDELEM}文字列変数にコピーします。
39214118 この変数は、ぱっと見た感じのように役に立たないというわけではありません。
3922-@code{XMLENDELEM} パターンでトリガーされたアクションは、普通、XML エレメント (ここでは @code{title}) の内部に詰め込まれたキャラクタデータ (ここでは @code{Hello, world}) を処理するのに適切な場所です。
3923-XML エレメントの @code{book} が、ネストした @code{bookinfo} のリストを含んでいれば、その時は、@code{XMLENDELEM == "book"} というパターンが、@code{bookinfo} データのリストを処理するアクションをトリガーするかもしれません。その @code{bookinfo} データのリストは @code{book} エレメントをパースする間に収集したものです。
3924-@code{XMLATTR} はこの瞬間には空です。
4119+@code{XMLENDELEM}パターンでトリガーされたアクションは、普通、XMLエレメント(ここでは@code{title})の内部に詰め込まれたキャラクタデータ(ここでは@code{Hello, world})を処理するのに適切な場所です。
4120+XMLエレメントの@code{book}が、ネストした@code{bookinfo}のリストを含んでいれば、その時は、@code{XMLENDELEM == "book"}というパターンが、@code{bookinfo}データのリストを処理するアクションをトリガーするかもしれません。
4121+その@code{bookinfo}データのリストは、@code{book}エレメントをパースする間に収集したものです。
4122+@code{XMLATTR}はこの瞬間には空です。
39254123
39264124 @subsection @code{XMLCHARDATA}: キャラクタデータを保持する文字列
39274125 @cindex @code{XMLCHARDATA}
39284126 @cindex @code{XMLENDELEM}
4127+
39294128 @example
39304129 <title>@b{Warning}</title>
39314130
@@ -3933,15 +4132,16 @@ XML エレメントの @code{book} が、ネストした @code{bookinfo} のリ
39334132 @end example
39344133
39354134 マークアップタグの間に点在するテキストデータは@emph{キャラクタデータ}と呼ばれます。
3936-キャラクタデータが現われるたびに @code{XMLCHARDATA} がセットされて知らされます。
3937-実際のデータは @code{$0} で渡され、現在使用されている文字エンコーディングでコード化されたテキストが入っているかもしれません。
3938-データに入っているのが @file{0} バイトという可能性もあります。
3939-データのバイト長は、@code{length($0)} で報告される文字の数とは異なるかもしれません。
3940-たとえば日本語のテキストの場合です。
3941-@code{$0} で報告されるキャラクタデータは、元の XML データとはバイト単位で同一であるとは限りません (もしかしたら異なるエンコーディングかもしれないからです)。
4135+キャラクタデータが現われるたびに@code{XMLCHARDATA}がセットされて知らされます。
4136+実際のデータは@code{$0}で渡され、現在使用されている文字エンコーディングでコード化されたテキストが入っているかもしれません。
4137+データに入っているのが@file{0}バイトという可能性もあります。
4138+データのバイト長は、@code{length($0)}で報告される文字の数とは異なるかもしれません。
4139+例えば、日本語のテキストの場合です。
4140+@code{$0}で報告されるキャラクタデータは、元のXMLデータとはバイト単位で同一であるとは限りません(もしかしたら異なるエンコーディングかもしれないからです)。
39424141 キャラクタデータには、上記の例の場合のように、改行がよく含まれています。
3943-XML ドキュメントにある連続するキャラクタデータは全て、1 度に @code{$0} で渡されます。
3944-ですので、改行が @code{$0} に含まれることがあるかもしれません。
4142+XMLドキュメントにある連続するキャラクタデータは全て、@code{$0}で一度に渡されます。
4143+ですから、改行が@code{$0}に含まれることがあるかもしれません。
4144+
39454145 @example
39464146 # キャラクタデータを集めて、タグ付けされたデータブロックの終わりで報告する。
39474147 XMLCHARDATA @{ data = $0 @}
@@ -3952,15 +4152,18 @@ XMLENDELEM == "item" @{ print "title", title, "contains", item, "and", link @}
39524152
39534153 @subsection @code{XMLPROCINST}: プロセッシングインストラクションターゲットを保持する文字列
39544154 @cindex @code{XMLPROCINST}
4155+
39554156 @example
39564157 <?@b{ echo ("this is the simplest, an SGML processing instruction\n");} ?>
39574158 @end example
3958-プロセッシングインストラクションは @code{<?} で始まり、@code{?>} で終わります。
3959-@code{<?} の直後の名前は@emph{ターゲット}です。
3960-@cindex ターゲット、プロセッシングインストラクションのもの
3961-@cindex プロセッシングインストラクチョン
4159+
4160+プロセッシングインストラクションは@code{<?}で始まり、@code{?>}で終わります。
4161+@code{<?}の直後の名前は@emph{ターゲット}です。
4162+@cindex target, of Processing Instruction
4163+@cindex Processing Instruction
39624164 プロセッシングインストラクションの残りの部分はアプリケーション特有のものです。
3963-ターゲットは @code{XMLPROCINST} でユーザに渡され、プロセッシングインストラクションの内容は @code{$0} で渡されます。
4165+@code{XMLPROCINST}でターゲットはユーザに渡され、プロセッシングインストラクションの内容は@code{$0}で渡されます。
4166+
39644167 @example
39654168 # これがどのようなプロセッシングインストラクションなのか調べる。
39664169 switch (XMLPROCINST) @{
@@ -3969,21 +4172,26 @@ switch (XMLPROCINST) @{
39694172 @}
39704173 @end example
39714174
4175+
39724176 @subsection @code{XMLCOMMENT}: コメントを保持する文字列
39734177 @cindex @code{XMLCOMMENT}
4178+
39744179 @example
39754180 <!-- @b{This is a comment} -->
39764181 @end example
3977-XML ドキュメントにおけるコメントは HTML でのものと同じように見えます。
3978-コメントが現われる時はいつも、XML パーサが @code{XMLCOMMENT} を @code{1} にセットし、コメントそのものを @code{$0} で渡します。
4182+
4183+XMLドキュメントにおけるコメントは、HTMLでのものと同じように見えます。
4184+コメントが現われる時は、XMLパーサが、@code{XMLCOMMENT}を@code{1}に必ずセットし、コメントそのものを@code{$0}で渡します。
4185+
39794186 @example
39804187 # コメントを報告する。
39814188 XMLCOMMENT @{ print "comment:", $0 @}
39824189 @end example
39834190
39844191
3985-@subsection @code{XMLSTARTCDATA}: CDATA の始まりを示す整数
4192+@subsection @code{XMLSTARTCDATA}: CDATAの始まりを示す整数
39864193 @cindex @code{XMLSTARTCDATA}
4194+
39874195 @example
39884196 <script type="text/javascript">
39894197 @b{<![CDATA[
@@ -3991,71 +4199,80 @@ XMLCOMMENT @{ print "comment:", $0 @}
39914199 ]]>}
39924200 </script>
39934201 @end example
3994-@cindex @code{CDATA}, エスケープされていないキャラクタデータ
3995-キャラクタデータには @code{<} という文字を入れることが許されていません。
3996-というのはこの文字がタグを示すという特殊な意味を持っているからです。
4202+
4203+@cindex @code{CDATA}, unescaped Character Data
4204+キャラクタデータには@code{<}という文字を入れることが許されていません。
4205+というのは、この文字がタグを示すという特殊な意味を持っているからです。
39974206 他の四つの文字についても同じことが成り立ちます。
3998-全部で五つの文字が、XML ドキュメントの中で使われる時にエスケープされなければなりません (@code{&lt;})。
3999-XML ドキュメントの @code{CDATA} セクションはエスケープが必要になるのを避ける方法です。
4000-@code{CDATA} セクションは @code{<![CDATA[} で始まり、@code{]]>} で終わります。
4001-CDATA セクションの内部にあるものはすべて XML パーサに無視されますが、その中身はユーザに渡されます。
4207+全部で五つの文字が、XMLドキュメントの中で使われる時にエスケープされなければなりません(@code{&lt;})。
4208+XMLドキュメントの@code{CDATA}セクションは、エスケープが必要になるのを避ける方法です。
4209+@code{CDATA}セクションは@code{<![CDATA[}で始まり、@code{]]>}で終わります。
4210+CDATAセクションの内部にあるものはXMLパーサに全て無視されますが、その中身はユーザに渡されます。
4211+
4212+@code{CDATA}セクションが現われると、@code{XMLSTARTCDATA}が@code{1}にセットされ、@code{$0}が、その@code{CDATA}セクションの内容を保持します。
4213+@code{CDATA}セクションには@code{]]>}という文字列を入れられません。
4214+そのため、@code{CDATA}のネストはできないということに注意してください。
40024215
4003-@code{CDATA} セクションが現われると、@code{XMLSTARTCDATA} が @code{1} にセットされ、@code{$0} がその @code{CDATA} セクションの内容を保持します。
4004-@code{CDATA} セクションには @code{]]>} という文字列を入れられませんので、そのため、@code{CDATA} のネストはできないということに注意してください。
40054216
4006-@subsection @code{XMLENDCDATA}: CDATA の終わりを示す整数
4217+@subsection @code{XMLENDCDATA}: CDATAの終わりを示す整数
40074218 @cindex @code{XMLENDCDATA}
40084219 @cindex @code{XMLSTARTCDATA}
4009-@code{XMLENDCDATA} がセットされる時はいつでも、@code{CDATA} セクションが終了して、XML パーサはデータを再び XML データとして解析しはじめます。
4010-@code{CDATA} セクションを閉じる @code{]]>} というのはユーザには渡されません。
4220+
4221+@code{XMLENDCDATA}がセットされる時は、いつでも、@code{CDATA}セクションが終了して、XMLパーサは、データを再びXMLデータとして解析しはじめます。
4222+@code{CDATA}セクションを閉じる@code{]]>}はユーザには渡されません。
4223+
40114224
40124225 @subsection @code{LANG}: デフォルトの文字エンコーディングを保持する環境変数
4013-@cindex @code{LANG}、環境変数
4014-@cindex 文字エンコーディング
4226+@cindex @code{LANG}, environment variable
4227+@cindex character encoding
40154228 @cindex @code{XMLCHARSET}
40164229
4017-GNU Awk インタプリタ実行時のオペレーティングシステムの環境は、@code{LANG} という環境変数を持っています。
4018-これはオペレーティングシステムのローカル機構の一部です。
4019-そしてその値は、インタプリタが使用する文字エンコーディングを決定します。
4020-この値は、@code{XMLCHARSET} 変数の初期値としてユーザが見ることができます。
4230+GNU Awkインタプリタ実行時のオペレーティングシステムの環境は、@code{LANG}という環境変数を持っています。
4231+これは、オペレーティングシステムのローカル機構の一部です。
4232+そして、その値は、インタプリタが使用する文字エンコーディングを決定します。
4233+この値は、@code{XMLCHARSET}変数の初期値としてユーザが見ることができます。
40214234
40224235 @example
40234236 # ユーザ環境の文字エンコーディングを表示する。
40244237 BEGIN @{ print "LANG =", XMLCHARSET @}
40254238 @end example
40264239
4027-シェルレベルの @code{LANG} 変数の値が @code{XMLCHARSET} にそのままコピーされないことが時々あります。
4240+シェルレベルの@code{LANG}変数の値が@code{XMLCHARSET}にそのままコピーされないことが時々あります。
40284241 つまり、オペレーティングシステムが別名を解決することを選ぶかもしれません。
40294242
40304243 @subsection @code{XMLCHARSET}: 現在の文字セットを保持する文字列
40314244 @cindex @code{XMLCHARSET}
4245+
40324246 @example
40334247 <?xml version="1.0" encoding="x-sjis-cp932"?>
40344248 @end example
40354249
4036-この文字列は、インタプリタの環境 (@code{nl_langinfo(CODESET)}) の現在の文字セットに最初はセットされています。
4037-最初はインタプリタがセットしますが、この文字列は、データを違う文字エンコーディングに変換する必要がある時にユーザがセットするためのものです。
4038-たとえば、上記の XML ヘッダは日本語のエンコーディングであることを述べていて、他のアプリケーションが読むにはデータを UTF-8 へ変換する必要があるかもしれません。
4250+この文字列は、インタプリタの環境(@code{nl_langinfo(CODESET)})の現在の文字セットに最初はセットされています。
4251+最初はインタプリタがセットしますが、この文字列は、違う文字エンコーディングにデータを変換する必要がある時にユーザがセットするためのものです。
4252+例えば、上記のXMLヘッダは、日本語のエンコーディングであることを述べています。
4253+他のアプリケーションが読む場合には、データをUTF-8へ変換する必要があるかもしれません。
40394254 @cindex @code{UTF-8}
40404255
40414256 @example
4042-# XML データを変換するために文字エンコーディングをセットする。
4257+# XMLデータを変換するために文字エンコーディングをセットする。
40434258 BEGIN @{ XMLCHARSET = "utf-8" @}
40444259 @end example
40454260
4046-その後、インタプリタが XML ファイルをオープンする時、XML データは全て、@code{XMLCHARSET} にユーザが設定した名前の文字セットへ変換されます。
4047-@code{XMLCHARSET} に対する変更はすぐ効果が現われるわけではなく、引き続いていずれかのファイルをオープンしたときに効果が現われることに注意してください。
4048-そういった変更は、変更された @code{XMLCHARSET} でオープンされたファイルにだけ作用します。
4049-@code{XMLCHARSET} の変更に先立ってオープンされたファイルには影響しません。
4261+その後、インタプリタがXMLファイルをオープンする時、XMLデータは全て、@code{XMLCHARSET}にユーザが設定した名前の文字セットへ変換されます。
4262+@code{XMLCHARSET}に対する変更はすぐ効果が現われるわけではありません。
4263+引き続いて、いずれかのファイルをオープンした時に効果が現われますので注意してください。
4264+この変数を変更した場合、変更された@code{XMLCHARSET}を使ってオープンしたファイルにだけ作用します。
4265+@code{XMLCHARSET}の変更に先立ってオープンされたファイルには影響しません。
40504266
40514267 @ignore
40524268 http://www.gnu.org/software/libiconv/documentation/libiconv/iconv_open.3.html
40534269 The empty encoding name "" is equivalent to "char": it denotes the locale dependent character encoding.
40544270 @end ignore
40554271
4056-@subsection @code{XMLSTARTDOCT}: DTD の始まりを示すルートタグ名
4272+@subsection @code{XMLSTARTDOCT}: DTDの始まりを示すルートタグ名
40574273 @cindex @code{XMLSTARTDOCT}
40584274 @cindex @code{XMLATTR}
4275+
40594276 @example
40604277 <?xml version="1.0" encoding="UTF-8" ?>
40614278 <!@b{DOCTYPE greeting} [ <!ELEMENT greeting (#PCDATA)> ]>
@@ -4063,10 +4280,10 @@ The empty encoding name "" is equivalent to "char": it denotes the locale depend
40634280 @end example
40644281
40654282 @cindex DTD, Document Type Definition
4066-妥当な XML データは、妥当性の検証の対象となるべき DTD への参照を含んでいます。
4067-@code{XMLSTARTDOCT} 変数は、DTD を参照するセクションの開始を示しています。
4068-そういった DTD は (上記の例のように) XML データの中に埋め込まれているか、あるいは、(下の例のように) DTD ファイルへの実際の参照であるかのどちらかです。
4069-両方の場合とも、XML データのルートタグの名前が @code{XMLSTARTDOCT} 変数へコピーされます。
4283+妥当なXMLデータは、妥当性の検証の対象となるべきDTDへの参照を含んでいます。
4284+@code{XMLSTARTDOCT}変数は、DTDを参照するセクションの開始を示しています。
4285+そういったDTDは、上記の例のように、XMLデータの中に埋め込まれているか、あるいは、下の例のように、DTDファイルへの実際の参照であるかのどちらかです。
4286+両方の場合とも、XMLデータのルートタグの名前が@code{XMLSTARTDOCT}変数へコピーされます。
40704287
40714288 @example
40724289 <?xml version='1.0'?>
@@ -4074,15 +4291,15 @@ The empty encoding name "" is equivalent to "char": it denotes the locale depend
40744291 <ListOfNames lang="English">
40754292 @end example
40764293
4077-両ケースは、@code{XMLATTR} 配列を見ることで区別できます。
4078-繰り返しですが、@code{XMLATTR} 配列は、(広い意味で) 名前の付いたアトリビュートいくつかの値をユーザへ渡すために使われます。
4079-この配列が @code{INTERNAL_SUBSET} というインデックスを持っている場合、DTD は XML データに埋め込まれています。
4080-そうでなければ、オプショナルなエントリである @code{PUBLIC} と @code{SYSTEM} が参照している DTD の SYSTEM 識別子か PUBLIC 識別子を報告します。
4294+両ケースは、@code{XMLATTR}配列を見ることで区別できます。
4295+繰り返しですが、@code{XMLATTR}配列は、(広い意味で)名前の付いたアトリビュートのいくつかの値をユーザへ渡すために使われます。
4296+この配列が@code{INTERNAL_SUBSET}というインデックスを持っている場合、DTDはXMLデータに埋め込まれています。
4297+そうでなければ、オプショナルなエントリである@code{PUBLIC}と@code{SYSTEM}が参照しているDTDのSYSTEM識別子かPUBLIC識別子を報告します。
40814298
40824299 @cindex @code{XMLATTR["PUBLIC"]}
40834300 @cindex @code{XMLATTR["SYSTEM"]}
40844301 @example
4085-# DTD 存在しているか、そしてそれが埋め込みか外部かを調べます。
4302+# DTD存在しているか、そしてそれが埋め込みか外部かを調べます。
40864303 XMLSTARTDOCT @{
40874304 root = XMLSTARTDOCT
40884305 if ("INTERNAL_SUBSET" in XMLATTR) @{
@@ -4093,82 +4310,104 @@ XMLSTARTDOCT @{
40934310 @}
40944311 @}
40954312 @end example
4096-どちらのケースでも、DTD 自体は XML パーサによってパースされることはありません。
4097-しかし埋め込まれた DTD テキストは @code{XMLUNPARSED} 変数で、@cite{unparsed data} として渡されます。
4313+
4314+どちらのケースでも、DTD自体は、XMLパーサによってパースされることはありません。
4315+しかし、埋め込まれたDTDテキストは、@code{XMLUNPARSED}変数で@cite{unparsed data}として渡されます。
40984316 @cindex @code{XMLUNPARSED}
40994317
4100-@subsection @code{XMLENDDOCT}: DTD の終わりを示す整数
4318+
4319+@subsection @code{XMLENDDOCT}: DTDの終わりを示す整数
41014320 @cindex @code{XMLENDDOCT}
4102-@code{XMLENDDOCT} 変数が設定されるたびに、DTD セクションが終了し、XML パーサはタグ付けされた XML データとして、再びデータをパースし続けます。
4103-DTD セクションの終了である @code{]>} はユーザに渡されません。
41044321
4105-@subsection @code{XMLUNPARSED}: unparsed characters を保持する文字列
4322+@code{XMLENDDOCT}変数が設定されるたびに、DTDセクションが終了し、XMLパーサはタグ付けされたXMLデータとして、再びデータをパースし続けます。
4323+DTDセクションの終了である@code{]>}はユーザに渡されません。
4324+
4325+
4326+@subsection @code{XMLUNPARSED}: unparsed charactersを保持する文字列
41064327 @cindex @code{XMLUNPARSED}
41074328 @cindex @code{XMLSTARTDOCT}
4108-XML データのうち、XML パーサにパースされないままなのはほんのわずかな部分しかありません。
4109-XML ドキュメントの埋め込まれた DTD は (@code{XMLSTARTDOCT} に設定することによって) そのまま検出され伝えられますが、DTD の内容自体は @code{XMLUNPARSED} で、パースされないデータとして報告されます。
4329+
4330+XMLデータのうち、XMLパーサにパースされないままなのは、ほんのわずかな部分しかありません。
4331+XMLドキュメントに埋め込まれたDTDは、@code{XMLSTARTDOCT}に設定することによって、そのまま検出され伝えられますが、DTDの内容自体は、@code{XMLUNPARSED}でパースされないデータとして報告されます。
4332+
41104333
41114334 @subsection @code{XMLERROR}: エラーの説明テキストを保持する文字列
41124335 @cindex @code{XMLERROR}
41134336 @cindex @code{XMLROW}
41144337 @cindex @code{XMLCOL}
4338+
41154339 この文字列は常に空です。
4116-XML パーサが XML データの中でエラーを見つけた時だけ設定されます。
4117-@code{XMLERROR} 文字列には、そのエラーのテキスト表現が入っています。
4118-このテキストの内容は略式のもので、全てのプラットフォームで同じものだとは保証されません。
4119-@code{XMLERROR} が空でない時はいつも、@code{XMLROW} 変数と @code{XMLCOL} 変数に XML データのそのエラーの場所が入っています。
4340+XMLパーサがXMLデータの中でエラーを見つけた時だけ設定されます。
4341+@code{XMLERROR}文字列には、そのエラーのテキスト表現が入っています。
4342+このテキストの内容は略式のものです。
4343+全てのプラットフォームで同じものだとは保証されません。
4344+@code{XMLERROR}が空でない時は、必ず、@code{XMLROW}変数と@code{XMLCOL}変数に、XMLデータのそのエラーの場所が入っています。
4345+
41204346
41214347 @subsection @code{XMLROW}: パースされているアイテムの現在行を保持する整数
41224348 @cindex @code{XMLROW}
4123-この整数には常に、現在パースされている行の番号が入っています。
4124-最初は 0 に設定されています。
4125-XML ファイルの最初の行が開かれると 1 にセットされ、XML データの各行でインクリメントされます。
4126-インクリメンタルしながら行を読むことは XML パーサが行ないます。
4127-ですので、ここでの行の概念は、AWK における@emph{レコード}の概念とは無関係です。
4128-XMLROW の内容は @code{RS} の設定に依存していません。
4349+
4350+この整数には、現在パースされている行番号が常に入っています。
4351+最初は0に設定されています。
4352+XMLファイルの最初の行が開かれると1にセットされ、XMLデータの各行でインクリメントされます。
4353+インクリメンタルしながら行を読むことはXMLパーサが行います。
4354+ですから、ここでの行の概念は、AWKにおける@emph{レコード}の概念とは無関係です。
4355+XMLROWの内容は、@code{RS}の設定に依存していません。
4356+
41294357
41304358 @subsection @code{XMLCOL}: パースされているアイテムの現在のカラムを保持する整数
41314359 @cindex @code{XMLCOL}
4132-この整数には常に現在パースされている現在行のカラムの番号が入っています。
4133-最初は 0 に設定されています。
4134-XML ファイルの最初の行がオープンされると、それは 1 にセットされ、XML データの各文字でインクリメントされます。
4135-各行の行頭で 1 にセットされます。
4136-インクリメントしながら行を読むことは XML パーサが行ないます。
4137-ですので、ここでの行の概念は、 AWK での@emph{レコード}の概念とは無関係です。
4138-XMLCOL の内容は @code{FS} の設定に依存していません。
4360+
4361+この整数には、現在パースされている現在行のカラムの番号が常に入っています。
4362+最初は0に設定されています。
4363+XMLファイルの最初の行がオープンされると、それは1にセットされ、XMLデータの各文字でインクリメントされます。
4364+各行の行頭で1にセットされます。
4365+インクリメントしながら行を読むことはXMLパーサが行います。
4366+ですから、ここでの行の概念は、AWKでの@emph{レコード}の概念とは無関係です。
4367+XMLCOLの内容は、@code{FS}の設定に依存していません。
4368+
41394369
41404370 @subsection @code{XMLLEN}: パースされているアイテムの長さを保持する整数
41414371 @cindex @code{XMLLEN}
41424372 @cindex @code{XMLCHARSET}
4143-この整数は常に、現在パースされているアイテムのバイト数が入っています。
4144-最初は 0 に設定されています。
4145-バイト数は、元のパースされた XML データのバイトを参照します。
4373+
4374+この整数は、現在パースされているアイテムのバイト数が常に入っています。
4375+最初は0に設定されています。
4376+バイト数は、元のパースされたXMLデータのバイトを参照します。
41464377 文字数と同じものではありません。
4147-@code{XMLCHARSET} で決定される文字エンコーディングへの変換 (オプショナル) の後、@code{XMLLEN} に入っている長さは、その XML データアイテムの変換後の長さとは異なっていることもあるかもしれません。
4378+@code{XMLCHARSET}で決定される文字エンコーディングへの変換(オプショナル)の後、@code{XMLLEN}に入っている長さは、そのXMLデータアイテムの変換後の長さとは異なっていることもあるかもしれません。
4379+
41484380
41494381 @subsection @code{XMLDEPTH}: エレメントのネスティングの深さを保持する整数
41504382 @cindex @code{XMLDEPTH}
4151-この整数は常に、現在パースされているエレメントのネスティングの深さが入っています。
4152-最初は、XML ファイルがオープンされた時、0 に設定されています。
4153-XML ファイルの最初のエレメントに入ると、1 にセットされ、(まだ完了していない) さらに先の各エレメントでインクリメントされます。
4383+
4384+この整数は、現在パースされているエレメントのネスティングの深さが常に入っています。
4385+XMLファイルがオープンされた時、最初は0に設定されています。
4386+XMLファイルの最初のエレメントに入ると、1にセットされ、(まだ完了していない)さらに先の各エレメントでインクリメントされます。
41544387 エレメントのパースが完了すると、この変数はデクリメントされます。
41554388
4389+
41564390 @subsection @code{XMLPATH}: パースされているエレメントのネストされているタグを保持する文字列
41574391 @cindex @code{XMLPATH}
4158-インタプリタをスタートして、XML ファイルをオープン時は、この文字列は空です。
4159-@code{XMLSTARTELEM} 毎に、新しいタグ名が、その前に @code{"/"} 文字を付けた状態で @code{XMLPATH} の後ろに追加されます。
4160-(XML ファイルの文字エンコーディングに従ってエンコードされている) @code{"/"} 文字は、両者の間のセパレータとして働きます。
4161-@code{XMLENDELEM} 毎に、古いタグ名 (と前置されている @code{"/"}) が @code{XMLPATH} から切り離されます。
4162-ユーザが @code{XMLPATH} を変更するかもしれませんが、@code{XMLPATH} に対するどのような変更も、次の XML データの読み込みで上書きされます。
41634392
4164-@subsection @code{XMLENDDOCUMENT}: XML データの終わりを示す整数
4393+インタプリタをスタートしてXMLファイルをオープンする時は、この文字列は空です。
4394+@code{XMLSTARTELEM}ごとに、新しいタグ名が、その前に@code{"/"}文字を付けた状態で、@code{XMLPATH}の後ろに追加されます。
4395+(XMLファイルの文字エンコーディングに従ってエンコードされている)@code{"/"}文字は、両者の間のセパレータとして働きます。
4396+@code{XMLENDELEM}ごとに、古いタグ名(および、前置されている@code{"/"})が@code{XMLPATH}から切り離されます。
4397+@code{XMLPATH}をユーザが変更するかもしれませんが、@code{XMLPATH}に対するどのような変更も、次のXMLデータの読み込みで上書きされます。
4398+
4399+
4400+@subsection @code{XMLENDDOCUMENT}: XMLデータの終わりを示す整数
41654401 @cindex @code{XMLENDDOCUMENT}
4166-この整数は常に 0 です。
4167-XML パーサが、XML データの終端を見つけた時にだけセットされます。
4402+
4403+この整数は常に0です。
4404+XMLパーサが、XMLデータの終端を見つけた時にだけセットされます。
4405+
41684406
41694407 @subsection @code{XMLEVENT}: イベント名を保持する文字列
41704408 @cindex @code{XMLEVENT}
4171-この文字列は常に、現在処理されているイベントの名前が入っています。
4409+
4410+この文字列は、現在処理されているイベントの名前が常に入っています。
41724411 有効な名前は
41734412 @code{DECLARATION}
41744413 @code{STARTDOCT}
@@ -4183,25 +4422,29 @@ XML パーサが、XML データの終端を見つけた時にだけセットさ
41834422 @code{UNPARSED}
41844423 @code{ENDDOCUMENT}
41854424 です。
4186-この名前は同名の変数と密に関係があります。
4187-同名の変数は @code{XML} というプリフィックスを持っています。
4188-このイベントについてくるいかなる名前も @code{XMLNAME}、@code{$0}、@code{XMLATTR} で渡されます。
4189-どの変数がどの情報を保持しているかの詳細は、@xref{fig:table_style_b}。
4425+この名前は、同名の変数と密に関係があります。
4426+同名の変数は、@code{XML}というプリフィックスが付いています。
4427+このイベントと共に来る名前も、全て、@code{XMLNAME}、@code{$0}、@code{XMLATTR}で渡されます。
4428+どの変数がどの情報を保持しているかについては別表を参照してください(@pxref{fig:table_style_b})。
4429+
41904430
4191-@subsection @code{XMLNAME}: XMLEVENT に割り当てられた名前を保持する文字列
4431+@subsection @code{XMLNAME}: XMLEVENTに割り当てられた名前を保持する文字列
41924432 @cindex @code{XMLNAME}
41934433 @cindex @code{XMLEVENT}
4194-@code{XMLNAME} 変数は、@code{XMLEVENT} 変数に特定のエベントが入っている時にデータを渡すために使われます。
4195-どの変数がどの情報を保持しているかの詳細は、@xref{fig:table_style_b}。
4434+
4435+@code{XMLNAME}変数は、@code{XMLEVENT}変数に特定のエベントが入っている時にデータを渡すために使われます。
4436+どの変数がどの情報を保持しているかのについては別表を参照してください(@pxref{fig:table_style_b})。
4437+
41964438
41974439 @node XMLgawk Core Language Interface Summary
4198-@section XMLgawk コア言語インターフェイスの要約
4199-前の @value{SECTION} の組み込み変数は、XML パーサ Expat の API に似た部分を引き受けるために選ばれました。
4200-@pindex Expat、SAX ライクな API を持つ XML パーサ
4201-ほとんどの組み込み変数は Expat の API の ''ハンドラ'' 関数を反映しています。
4202-Expat で作業したことがあるならば、XMLgawk を使えば家にいるような気分になるでしょう。
4203-あなたが持つであろう疑問は、@emph{どのようにパラメータを渡すか}ということだけです。
4204-この @value{SECTION} は、あなたの疑問に、変数名とパラメータ渡しの詳細による概要を表にして答えます。
4440+@section XMLgawkコア言語インターフェイスの要約
4441+
4442+前の@value{SECTION}の組み込み変数は、XMLパーサExpatのAPIに似た部分を引き受けるために選ばれました。
4443+@pindex Expat, XML parser with SAX-like API
4444+ほとんどの組み込み変数は、ExpatのAPIの「ハンドラ」関数を反映しています。
4445+Expatで作業したことがあるならば、XMLgawkを使えば家にいるような気分になるでしょう。
4446+疑問は、@emph{どのようにパラメータを渡すか}ということだけです。
4447+この@value{SECTION}では、この疑問に対して、変数名とパラメータ渡しの詳細による概要を表にして答えます。
42054448
42064449 @ignore
42074450 Each row of the table
@@ -4220,12 +4463,15 @@ the variable might be a future enhancement
42204463 @end table
42214464 @end ignore
42224465
4223-正確に言うと、この @value{CHAPTER} に実際には表が二つあります。
4466+正確に言うと、この@value{CHAPTER}に実際には表が二つあります。
4467+
42244468
4225-@subsection Style A - 各イベントクラス XML@emph{eventname} ごとに一つの予め定義された専用の変数
4226-最初の表では、プログラムの中でパターンとして単独で使える変数名を表わしていて、それぞれの種類のエベントを処理するアクションをトリガーします。
4227-表の最初の欄には変数名が入っていて、2 番目の欄にはトリガーされた時の変数の値が入っています。
4228-XML パーサから受け取ることのできるパラメータは全て、残りの欄に説明されています。
4469+@subsection Style A - 各イベントクラスXML@emph{eventname}ごとに一つの予め定義された専用の変数
4470+
4471+最初の表では、プログラムの中でパターンとして単独で使える変数名を表わしています。
4472+これらの変数は、それぞれの種類のイベントを処理するアクションをトリガーします。
4473+表の最初の欄には変数名が入っていて、2番目の欄にはトリガーされた時の変数の値が入っています。
4474+XMLパーサから受け取ることのできるパラメータは残りの欄に全て説明されています。
42294475
42304476 @float Figure,fig:table_style_a
42314477 @multitable { XMLNOTATIONDECL} {elemame} {list of attr nam} { INTERNAL_SUBSET} {encoding name}
@@ -4235,14 +4481,14 @@ XML パーサから受け取ることのできるパラメータは全て、残
42354481 @tab "1.0" encoding name "yes"/"no"
42364482 @item XMLSTARTDOCT @tab root element name @tab @tab PUBLIC@* SYSTEM @* INTERNAL_SUBSET @tab public Id@*system Id@*1
42374483 @item XMLENDDOCT @tab 1
4238-@item XMLPROCINST @tab PI name @tab PI content
4484+@item XMLPROCINST @tab PI name @tab PI content
42394485 @item XMLSTARTELEM @tab element name @tab Ordered list of attribute names @tab given name(s) @tab given value(s)
42404486 @item XMLENDELEM @tab element name
4241-@item XMLCHARDATA @tab 1 @tab text data
4487+@item XMLCHARDATA @tab 1 @tab text data
42424488 @item XMLSTARTCDATA @tab 1
42434489 @item XMLENDCDATA @tab 1
4244-@item XMLCOMMENT @tab 1 @tab comment text
4245-@item XMLUNPARSED @tab 1 @tab text data
4490+@item XMLCOMMENT @tab 1 @tab comment text
4491+@item XMLUNPARSED @tab 1 @tab text data
42464492 @item XMLENDDOCUMENT @tab 1
42474493 @ignore
42484494 Manuel suggested inclusion of the following.
@@ -4252,17 +4498,20 @@ Manuel suggested inclusion of the following.
42524498 @item * XMLNOTATIONDECL @tab ? @tab ? @tab ? @tab ?
42534499 @end ignore
42544500 @end multitable
4255-@caption{style A で XML データを渡す変数}
4501+@caption{style AでXMLデータを渡す変数}
42564502 @end float
42574503
4504+
42584505 @subsection Style B - すべてのイベントで共有される、限定された変数の組
4506+
42594507 さて、二つ目の変数の表です。
42604508 上記の表の中のいろいろな名前を全て覚えるのが好きではない人もいます。
4261-彼らは、変数名を最低二つ覚えるというほうを好みます。
4262-1 番目の変数 (@code{XMLEVENT}) には発生したイベント (たとえば @code{STARTELEM}) の種類が入っていて、2 番目の変数 (@code{XMLNAME}) は、(エレメントの名前のように) それについての詳細を渡します。
4263-全てのイベントとそのパラメータは、この方式で渡されます。
4264-しかし時々、たった一つだけでなくて、それ以上のパラメータが渡されることがあります。
4265-その時は、既に最初の表で説明したように、@code{$0} と @code{XMLATTR} に頼らなければなりません。
4509+そういった人は、変数名を最低二つ覚えるという方を好むでしょう。
4510+1番目の変数(@code{XMLEVENT})には、発生したイベント(例えば、@code{STARTELEM})の種類が入っています。
4511+2番目の変数(@code{XMLNAME})には、エレメントの名前のように、それについての詳細を渡します。
4512+全てのイベントとそのパラメータがこの方式で渡されます。
4513+しかし、たった一つだけではなく、それ以上のパラメータが渡されることもあります。
4514+その時は、最初の表で既に説明したような@code{$0}と@code{XMLATTR}に頼らなければなりません。
42664515
42674516 @float Figure,fig:table_style_b
42684517 @multitable {XMLNOTATION} {elemname} {list of attr nam} { INTERNAL_SUBSET} {encoding name}
@@ -4270,14 +4519,14 @@ Manuel suggested inclusion of the following.
42704519 @item DECLARATION @tab @tab @tab VERSION@* ENCODING@* STANDALONE @tab "1.0" @* encoding name @* "yes"/"no"
42714520 @item STARTDOCT @tab root element name @tab @tab PUBLIC@* SYSTEM@* INTERNAL_SUBSET @tab public Id@* system Id @* 1
42724521 @item ENDDOCT
4273-@item PROCINST @tab PI name @tab PI content
4522+@item PROCINST @tab PI name @tab PI content
42744523 @item STARTELEM @tab element name @tab Ordered list of attribute names @tab given name(s) @tab given value(s)
42754524 @item ENDELEM @tab element name
4276-@item CHARDATA @tab @tab text data
4525+@item CHARDATA @tab @tab text data
42774526 @item STARTCDATA
42784527 @item ENDCDATA
4279-@item COMMENT @tab @tab comment text
4280-@item UNPARSED @tab @tab text data
4528+@item COMMENT @tab @tab comment text
4529+@item UNPARSED @tab @tab text data
42814530 @item ENDDOCUMENT
42824531
42834532 @ignore
@@ -4288,7 +4537,7 @@ Manuel suggested inclusion of the following.
42884537 @end ignore
42894538
42904539 @end multitable
4291-@caption{style B で XML データを渡す変数}
4540+@caption{style BでXMLデータを渡す変数}
42924541 @end float
42934542
42944543 @ignore
@@ -4308,98 +4557,103 @@ Style A (one variable for each event) and style B (only two variables) interface
43084557 @end itemize
43094558 @end ignore
43104559
4560+
43114561 @node xmllib
43124562 @section xmllib
4563+
43134564 @b{FIXME: This section has not been written yet}.
43144565
4566+
43154567 @node xmltree
43164568 @section xmltree
4569+
43174570 @b{FIXME: This section has not been written yet}.
43184571
4572+
43194573 @node Reference of Books and Links
43204574 @chapter 参考書籍とリンク
43214575
43224576 @menu
4323-* 良書::
4324-* インターネットへのリンク::
4577+* Good Books::
4578+* Links to the Internet::
43254579 @end menu
43264580
4581+
43274582 @node Good Books
43284583 @section 良書
4329-ここでは XML と AWK についてもっと学びたい人のための本についてコメントしながらリストしていきます。
4584+
4585+ここでは、XMLとAWKについてもっと学びたい人のために、コメントしながら書籍を挙げていきたいと思います。
43304586
43314587 @itemize
43324588 @item
4333-AWK に関する一番最初の本は Aho, Kernighan, Weinberger による @cite{The AWK Programming Language} でした。
4334-この本が最初に登場してから 20 年以上、いまだに、情報とインスピレーションのソースとして高く評価されています。
4335-この本のことを @uref{http://cm.bell-labs.com/cm/cs/awkbook, @b{TAPL}} として参照する読者もいます。
4589+AWKに関する一番最初の本はAho、Kernighan、Weinbergerによる@cite{The AWK Programming Language}でした。
4590+この本が最初に登場してから20年以上経ちましたが、いまだに、情報とインスピレーションのソースとして高く評価されています。
4591+この本のことを、@uref{http://cm.bell-labs.com/cm/cs/awkbook, @b{TAPL}}と呼ぶ読者もいます。
43364592
43374593 @item
4338-@cite{TAPL} は高価な本で、AT&T の Unix に付いて来たオリジナルの AWK 実装と結び付けられていました。
4339-SunOS が一般的になったとき、AWK インタプリタ (@code{oawk} と @code{nawk})
4594+@cite{TAPL}は高価な本で、AT&TのUnixに付いて来たオリジナルのAWK実装と結び付けられていました。
43404595 @cindex @code{nawk}
4341-を実装した SunOS のやり方によって AWK の評判は傷付けられてしまいました。
4342-それで、オープンソースコードでの実装と開発者によるサポート、適切なドキュメンテーションの必要がありました。
4343-GNU Awk 実装は Arnold Robbins によって保守されています。
4344-彼は @b{EAP3}、@uref{http://www.oreilly.com/catalog/awkprog3/index.html, GNU Awk manual} の第 3 版の著者としても役割を果たしています。
4345-この高価でない本は O'Reilly によって出版されていますが、GNU Awk のソースディストリビューションと一緒に配布されてもいます。
4596+SunOSが一般的になった時、AWKインタプリタ(@code{oawk}と@code{nawk})を実装したSunOSのやり方によってAWKの評判は傷付けられてしまいました。
4597+そのため、オープンソースコードでの実装と開発者によるサポート、適切なドキュメントの必要がありました。
4598+GNU Awk実装は、Arnold Robbinsによって保守されています。
4599+彼は、@b{EAP3}、@uref{http://www.oreilly.com/catalog/awkprog3/index.html, GNU Awk manual}の第3版の著者としても役割を果たしています。
4600+この高価でない本はO'Reillyによって出版されていますが、GNU Awkのソースディストリビューションと一緒に配布されてもいます。
43464601 この最新の情報ソースと一緒にリファレンスカードが来ています。
4347-残念ながら、このリファレンスカードは O'Reilly の本の一部ではありません。
4348-POSIX スタンダードとオリジナルの AWK、そして GNU Awk の間の微妙な差異についてこれほど正確な発行物は他にありません。
4602+残念ながら、このリファレンスカードはO'Reilly本の一部ではありません。
43494603 @cindex POSIX
4604+POSIXスタンダードとオリジナルのAWK、そして、GNU Awkの間の微妙な差異について、これほど正確な発行物は他にありません。
43504605
43514606 @item
4352-AWK の成功を受けた中での他のスクリプト言語の成功と、初期の GNU/Linux の発展によって、AWK は他の言語に「置き換え」られつつあるという間違った認識が出てきました。
4353-スタイリッシュな新しいスクリプト言語が 5 年毎に現われては消えをしている一方、AWK は消えたり、「置き換え」られたりしないでしょう。
4354-@uref{http://en.wikipedia.org/wiki/Single_UNIX_Specification, Single UNIX Specification}
4607+AWKの成功を受けた中での他のスクリプト言語の成功と、初期のGNU/Linuxの発展によって、AWKは他の言語に「置き換え」られつつあるという間違った認識が出てきました。
4608+スタイリッシュな新しいスクリプト言語が5年毎に現われては消えをしている一方、AWKは消えたり、「置き換え」られたりしないでしょう。
43554609 @cindex Unix
43564610 @cindex POSIX
4357-の中で、AWK は、Unix オペレーティングシステムの必須ユーティリティの一つとして説明されています。
4358-AWK を除けば、スクリプト言語 Bourne Shell ただ一つだけが、「権威あるスクリプト言語」としての地位を保っています。
4359-実際に必要になる読者は少ないでしょうけれども、AWK の正確な仕様が知りたい場合は、@uref{http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html, @b{POSIX AWK}} という仕様書を読んでください。
4611+@uref{http://en.wikipedia.org/wiki/Single_UNIX_Specification, Single UNIX Specification}の中で、AWKは、Unixオペレーティングシステムの必須ユーティリティの一つとして説明されています。
4612+AWKを除けば、スクリプト言語Bourne Shellただ一つだけが、「権威あるスクリプト言語」としての地位を保っています。
4613+実際に必要になる読者は少ないでしょうけれども、AWKの正確な仕様が知りたい場合は、@uref{http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html, @b{POSIX AWK}}という仕様書を読んでください。
43604614
43614615 @item
4362-ポータブルなスクリプト言語として AWK ユーティリティを認識しはじめたばかりでしたならば、入門や総覧、そしてさらなる情報源へのディスパッチャとして @uref{http://en.wikipedia.org/wiki/Awk, @b{Wikipedia's AWK entry}} を読むべきでしょう。
4616+ポータブルなスクリプト言語としてAWKユーティリティを認識しはじめたばかりでしたならば、入門、総覧、そして、さらなる情報源へのディスパッチャとして@uref{http://en.wikipedia.org/wiki/Awk, @b{Wikipedia's AWK entry}}を読むべきでしょう。
43634617
43644618 @item
4365-XML は、ちょうど GNU Awk のように、1970 年代まで遡ることのできるスタンダードの成果です。
4366-お勧めの読み物については前にいくつかすでに触れました (@pxref{XML ファイルを詳しく見る})。
4367-単独の情報源としては、O'Reilly の本 @uref{http://www.oreilly.com/catalog/xmlnut3/, @b{XML in a Nutshell}} をよく勧めていました。
4368-さらに、@uref{http://en.wikipedia.org/wiki/Xml, Wikipedia's XML entry} が、手軽な概要と入門、そしてリンクと情報源を集めたものを提供しています。
4619+XMLは、ちょうどGNU Awkのように、1970年代まで遡ることのできるスタンダードの成果です。
4620+お勧めの読み物については前にいくつかすでに触れました(@pxref{Looking closer at the XML file})。
4621+単独の情報源としては、O'Reillyの@uref{http://www.oreilly.com/catalog/xmlnut3/, @b{XML in a Nutshell}}をよく勧めていました。
4622+さらに、@uref{http://en.wikipedia.org/wiki/Xml, Wikipedia's XML entry}が、手軽な概要、入門、そして、リンクと情報源を集めたものを提供しています。
4623+@end itemize
43694624
43704625
4371-@end itemize
43724626 @page
4373-
43744627 @node Links to the Internet
43754628 @section インターネットへのリンク
4376-このセクションは、この @value{DOCUMENT} を通してお話した様々な事柄に関する URL をリストしています。
4629+
4630+このセクションは、この@value{DOCUMENT}を通してお話した様々な事柄に関するURLをリストしています。
43774631
43784632 @itemize
43794633 @item
4380-XMLgawk は Arnold Robbins の @uref{http://www.gnu.org/software/gawk/gawk.html, @b{GNU Awk}} を基にしています。
4381-Arnold のディストリビューションは唯一の本物の GNU Awk です。
4382-GNU Awk は、標準に対して忠実で、非常に多くの Unix オペレーティングシステムで使われる、安定したディストリビューションであることを目的としています。
4634+XMLgawkは、Arnold Robbinsの@uref{http://www.gnu.org/software/gawk/gawk.html, @b{GNU Awk}}を基にしています。
4635+Arnoldのディストリビューションは唯一の本物のGNU Awkです。
4636+GNU Awkは標準に対して忠実です。
4637+非常に多くのUnixオペレーティングシステムで使われる安定したディストリビューションであることを目的としています。
43834638
43844639 @item
4385-XMLgawk は GNU Awk の機能拡張です。
4386-@uref{http://sourceforge.net/projects/xmlgawk/, @b{xgawk distribution}} の一部として配布されています。
4640+XMLgawkは、GNU Awkの機能拡張です。
4641+@uref{http://sourceforge.net/projects/xmlgawk/, @b{xgawk distribution}}の一部として配布されています。
43874642 @cite{xgawk}
4388-SourceForge
43894643 @cindex SourceForge
4390-のプロジェクトは @emph{xmlgawk} (小文字、SourceForge のプロジェクト名は小文字で構成されなければなりません) と名付けられています。
4391-これは、当初の計画が XML 拡張の実装だけを目指していたからです。
4392-後に、XML パーサよりも e@b{x}tension に重点があることを反映するために、このディストリビューションの名前が選ばれました。
4644+SourceForgeのプロジェクトは@emph{xmlgawk}(小文字、SourceForgeのプロジェクト名は小文字で構成されなければなりません)と名付けられています。
4645+これは、当初の計画がXML拡張の実装だけを目指していたからです。
4646+後に、XMLパーサよりもe@b{x}tensionに重点があることを反映するため、このディストリビューションの名前が選ばれました。
43934647
43944648 @item
4395-XMLgawk での XML データの処理の仕方が、SAX API を念頭にデザインされていることは @ref{XML ファイルのアウトラインの表示}の中で既に述べました。
4396-@cindex SAX, XML のシンプルな API
4397-他の言語でもこの API を実装したライブラリを持っています。
4398-ほとんどの開発者にとって Java の実装は SAX API の権威ある実装です。
4649+@cindex SAX, Simple API for XML
4650+XMLgawkでのXMLデータの処理の仕方が、SAX APIを念頭にデザインされていることは、別の節(@pxref{Printing an outline of an XML file})の中で既に述べました。
4651+他の言語でも、このAPIを実装したライブラリを持っています。
43994652 @cindex Java
4400-@cite{Core Web Programming} という本の @uref{http://www.corewebprogramming.com/PDF/ch23.pdf, @b{XML Processing with Java}} というチャプターを見てください。
4401-@ref{fig:ch2_outline.awk} で提供したスクリプト @file{outline.awk} の実装が見れます。
4653+ほとんどの開発者にとってJavaの実装はSAX APIの権威ある実装です。
4654+@cite{Core Web Programming}という本の@uref{http://www.corewebprogramming.com/PDF/ch23.pdf, @b{XML Processing with Java}}というチャプターを見てください。
44024655 @pindex @file{outline.awk}
4656+fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})で提供したスクリプト@file{outline.awk}の実装が見れます。
44034657 両方の実装を比較すれば、スクリプトによるソリューションとコンパイルによるソリューションの利点と欠点が明らかとなるでしょう。
44044658
44054659 @ignore
@@ -4409,159 +4663,162 @@ XMLgawk での XML データの処理の仕方が、SAX API を念頭にデザ
44094663 @end ignore
44104664
44114665 @item
4412-The @uref{http://www.w3.org/TR/2004/REC-xml-20040204/, @b{XML standard's exact specification}} は誰にでも開放されています。
4666+The @uref{http://www.w3.org/TR/2004/REC-xml-20040204/, @b{XML standard's exact specification}}は誰にでも開放されています。
44134667 しかし、ふと覗いてみたようなユーザには理解しにくいものです。
4414-消費して消化するのが少し簡単なものが、@uref{http://www.xml.com/axml/testaxml.htm, @cite{Introduction to the Annotated XML Specification}} です。
4415-ビギナーはよく、XML ファイルのオプショナルな部分、あるいは必須の部分について全ての概要を得ようと奮闘しています。
4416-そういう人たちは、@uref{http://www.mulberrytech.com/quickref/XMLquickref.pdf, @cite{XML Syntax Quick Reference}} をありがたく思うでしょう。
4417-この 2 ページのリファレンスカードは、素晴しいグラフィカルな形式でレイアウトされ、XML データにおける DTD の適切な場所を無視@emph{しない}概要を提供している点で注目すべきです。
4668+消費して消化するのがもう少し簡単なものが、@uref{http://www.xml.com/axml/testaxml.htm, @cite{Introduction to the Annotated XML Specification}}です。
4669+ビギナーはよく、XMLファイルのオプショナルな部分、あるいは、必須の部分について全ての概要を得ようと奮闘しています。
4670+そういう人たちは、@uref{http://www.mulberrytech.com/quickref/XMLquickref.pdf, @cite{XML Syntax Quick Reference}}をありがたく思うでしょう。
4671+この2ページのリファレンスカードは、素晴しいグラフィカルな形式でレイアウトされ、XMLデータにおけるDTDの適切な場所を無視@emph{しない}概要を提供している点で注目すべきです。
44184672 @cindex DTD, Document Type Definition
4419-
44204673 @end itemize
44214674
4675+
44224676 @node Extensible Gawk Language Extensions
4423-@appendix Extensible Gawk 言語拡張
4424-@command{xgawk} プログラムは、基本となる @command{gawk} の能力に、少しばかり機能を追加するものです。
4425-これは、手短かにまとめたものです。
4677+@appendix Extensible Gawk言語拡張
44264678
4427-@enumerate
4679+@command{xgawk}プログラムは、基本となる@command{gawk}の能力に、少しばかり機能を追加するものです。
4680+以下は、手短かにまとめたものです。
44284681
4682+@enumerate
44294683 @item
4430-共有ライブラリをリンクするための、@option{-l} (@option{--load}) というコマンドラインオプションを新しく追加。
4431-これにより、新しい @code{AWKLIBPATH} という環境変数を用いてライブラリを探します (環境に何もなければ、適切なデフォルト値が使われます)。
4684+共有ライブラリをリンクするための、@option{-l}(@option{--load})というコマンドラインオプションを新しく追加。
4685+これにより、@code{AWKLIBPATH}という新しい環境変数を用いてライブラリを探します(環境に何もなければ、適切なデフォルト値が使われます)。
44324686 また、ビルドされたプラットフォーム上の共有ライブラリに適したサフィックスを自動的に追加しようと試みます。
44334687
44344688 @item
4435-@command{gawk} のソースコードをインクルードするためのコマンドラインオプション @option{-i} (@option{--include}) を新しく追加。
4436-これにより、現在 @option{-f} の引数のために行なっているのと同様に、既存の AWKPATH 環境変数を用いて @command{gawk} コードを探します。
4437-また、デフォルトの @file{.awk} サフィックスを付けたり外したりして自動的にこのファイルを見つけようと試みます。
4689+@command{gawk}のソースコードをインクルードするためのコマンドラインオプション@option{-i}(@option{--include})を新しく追加。
4690+これにより、現在@option{-f}の引数のために行っているのと同様に、既存のAWKPATH環境変数を用いて@command{gawk}コードを探します。
4691+また、デフォルトの@file{.awk}サフィックスを付けたり外したりして、自動的にこのファイルを見つけようと試みます。
44384692
44394693 @item
4440-自動的な @file{.awk} サフィックスの付加も処理するように @option{-f} を強化。
4441-(@code{AWKPATH} にあるディレクトリそれぞれについて、まずサフィックス無しのファイルをオープンしようと試みて、次に @file{.awk} を追加して試みます。)
4694+@file{.awk}サフィックスの自動的付加も処理するように@option{-f}を強化。
4695+(@code{AWKPATH}にあるディレクトリそれぞれについて、まず、サフィックス無しのファイルをオープンしようと試みて、次に、@file{.awk}を追加して試みます。)
44424696
44434697 @item
4444-ソースコード中の @code{@@include} ディレクティブのサポートを追加。
4445-これは、現在の @command{igawk} スクリプトで提供されている機能と同じです。
4446-これは @command{igawk} で行なわれているものと同じように動作します (新しいコマンドラインオプションの @option{-i} でも同様)。
4447-ですので、@command{igawk} スクリプトを削除して、新しい @command{gawk} バイナリへのシンボリックリンクで置き換えることもできます。
4448-これで、@file{.awk} サフィックスを自動付加できるので、@command{igawk} の @code{@@include} よりも少しだけパワフルになります。
4698+ソースコード中の@code{@@include}ディレクティブのサポートを追加。
4699+現在の@command{igawk}スクリプトで提供されている機能と同じです。
4700+@command{igawk}で行われているものと同じように動作します(新しいコマンドラインオプションの@option{-i}でも同様)。
4701+ですから、@command{igawk}スクリプトを削除して、新しい@command{gawk}バイナリへのシンボリックリンクで置き換えることもできます。
4702+これで、@file{.awk}サフィックスを自動付加できるので、@command{igawk}の@code{@@include}よりも少しだけパワフルになります。
44494703
44504704 @item
4451-共有ライブラリをロードするために、ソースコード中の @code{@@load} ディレクティブのサポートを追加。
4452-これは、新しいコマンドラインオプションの @option{-l} と同様のことをします。
4705+共有ライブラリをロードするために、ソースコード中の@code{@@load}ディレクティブのサポートを追加。
4706+新しいコマンドラインオプションの@option{-l}と同様のことをします。
44534707
44544708 @item
4455-共有ライブラリをロードするためのより良いサポートを提供するために内部を強化しています。
4709+共有ライブラリをロードするより良いサポートを提供するために内部を強化しています。
44564710
44574711 @item
4458-本家 @command{gawk} にまだ取り込まれていないいくつかのバグ修正が含まれています。
4712+本家@command{gawk}にまだ取り込まれていないいくつかのバグ修正が含まれています。
44594713 特に、大きな整数の表示に関する問題が修正されました。
44604714
44614715 @item
4462-プラットフォーム特有のパッケージングツールを入れるために package サブディレクトリが一つ追加されました。
4463-現在 @acronym{RPM} の spec ファイル @file{xgawk.spec} だけが入っています。
4464-これは、tarball から簡単に @acronym{RPM} をビルドするのに使われます (あなたの設定に応じて、@command{rpmbuild -tb xgawk.tar.gz} と同じくらい可能な限り簡単に)。
4716+プラットフォーム特有のパッケージングツールを入れるため、packageサブディレクトリが一つ追加されました。
4717+現在、@acronym{RPM}のspecファイル@file{xgawk.spec}だけが入っています。
4718+これは、tarballから簡単に@acronym{RPM}をビルドするのに使われます(設定に応じて、@command{rpmbuild -tb xgawk.tar.gz}と同じくらい可能な限り簡単に)。
44654719 他のプラットフォームに対するパッケージングツールの提案を歓迎します。
4466-
44674720 @end enumerate
4468-Extensible GNU Awk のインストールのプロセスもいくつか新しいオプションを追加しました。
4469-@command{xgawk} のインストレーション処理は、決して @command{gawk} の前のインストレーションを損なったりしません。
4470-インストールされるファイルは全て、本家 @command{gawk} によってインストールされるファイルとは明確に別の名前を持っています。
4471-ですので、どちらのものもお互いの邪魔をすることなく共存できます。
4721+
4722+Extensible GNU Awkのインストールのロセスも、いくつか新しいオプションを追加しました。
4723+@command{xgawk}のインストール処理は、@command{gawk}の前のインストールを決して損なったりしません。
4724+インストールされるファイルは全て、本家@command{gawk}によってインストールされるファイルとは明確に別の名前を持っています。
4725+ですから、どちらのものもお互いの邪魔をすることなく共存できます。
44724726
44734727 @enumerate
44744728 @item
4475-本家 @command{gawk} の @option{--enable-switch} オプションはデフォルトで有効になっています。
4729+本家@command{gawk}の@option{--enable-switch}オプションはデフォルトで有効になっています。
4730+
44764731 @item
4477-@option{--enable-gawk} は新しいオプションで、そのデフォルトは @option{no} です。
4478-このオプションを有効にすると、@command{xgawk} に加えて、@command{gawk} と @command{awk}、そして @command{igawk} の実行ファイルへのリンクをインストールします。
4479-このオプションは、本家の @command{gawk} をインストールしたくない場合に役立ちます。
4480-しかし、@command{xgawk} の前に、本家 @command{gawk} が既にインストールされている場合は、これらのリンクはインストールされません。
4481-ですので、このオプションは効果を持ちません。
4732+@option{--enable-gawk}は新しいオプションです。
4733+デフォルトは@option{no}です。
4734+このオプションを有効にすると、@command{xgawk}に加えて、@command{gawk}と@command{awk}、そして、@command{igawk}の実行ファイルへのリンクをインストールします。
4735+本家の@command{gawk}をインストールしたくない場合に役立ちます。
4736+しかし、@command{xgawk}の前に、本家@command{gawk}が既にインストールされている場合は、これらのリンクはインストールされません。
4737+ですから、このオプションは効果を持ちません。
44824738
44834739 @item
44844740 @cindex Cygwin
4485-新しいオプション @option{--enable-static-extensions} (デフォルトで @option{no}) は、実行ファイルに静的にリンクされた拡張ライブラリを使うよう強制します。
4486-Cygwin のようなプラットフォームでは、このオプションは拡張ライブラリと一緒に動作させるための唯一の方法です。
4487-こういったプラットフォームは動的ライブラリの扱いに問題があります。
4741+新しいオプション@option{--enable-static-extensions}(デフォルトで@option{no})は、実行ファイルに静的にリンクされた拡張ライブラリを使うよう強制します。
4742+Cygwinのようなプラットフォームでは、このオプションは拡張ライブラリと一緒に動作させるための唯一の方法です。
4743+こういったプラットフォームは、動的ライブラリの扱いに問題があります。
44884744
44894745 @item
44904746 デフォルトでは、必要とされるライブラリがそのプラットフォーム上に存在するならば、全ての拡張ライブラリが構築されます。
4491-オプションの @option{--disable-xml}、@option{--disable-pgsql}、@option{--disable-mpfr}、@option{--disable-gd} が、特定の拡張を構築しないように切り替えるのに使うことができます。
4747+オプションの@option{--disable-xml}、@option{--disable-pgsql}、@option{--disable-mpfr}、@option{--disable-gd}は、特定の拡張を構築しないように切り替えるのに使うことができます。
44924748
44934749 @item
4494-オプションの @option{--with-expat=@emph{PATH}}、@option{--with-libpq=@emph{PATH}}、@option{--with-mpfr=@emph{PATH}}、@option{--with-gd=@emph{PATH}} は、ライブラリの使用法が特定のパスへインストールされるのを許可します。
4750+オプションの@option{--with-expat=@emph{PATH}}、@option{--with-libpq=@emph{PATH}}、@option{--with-mpfr=@emph{PATH}}、@option{--with-gd=@emph{PATH}}は、ライブラリの使用法が特定のパスへインストールされるのを許可します。
44954751 @end enumerate
44964752
4497-@node PostgreSQL API Reference
4498-@appendix PostgreSQL API リファレンス
44994753
4754+@node PostgreSQL API Reference
4755+@appendix PostgreSQL APIリファレンス
45004756 @pindex PostgreSQL
45014757 @cindex database
45024758 @cindex pgsql
45034759
4504-ここで説明する関数は、@uref{//http://www.postgresql.org/docs/8.0/interactive/libpq.html} で記されているように、libpq C API を明かにするためのものです。
4505-このドキュメンテーションは libpq ドキュメンテーションと合わせることで初めて理解できます。
4760+ここで説明する関数は、@uref{//http://www.postgresql.org/docs/8.0/interactive/libpq.html}で記されているように、libpq C APIを明らかにするためのものです。
4761+このドキュメントは、libpqドキュメントと合わせることで初めて理解できます。
45064762
4507-この API は、@option{-l pgsql} というコマンライン引数で @command{xgawk} を起動するか、スクリプトの中に @code{@@load pgsql} を挿入することで使うことができます。
4763+このAPIは、@option{-l pgsql}というコマンライン引数で@command{xgawk}を起動するか、スクリプトの中に@code{@@load pgsql}を挿入することで使うことができます。
45084764
4509-オプショナルなパラメータは角括弧@w{ ([ ])} で閉じています。
4765+オプショナルなパラメータは角括弧@w{([ ])}で閉じています。
45104766
45114767 @menu
4512-* データベース接続制御関数::
4513-* 接続ステータス関数::
4514-* コマンド実行関数::
4515-* 非同期コマンド処理::
4516-* コピーデータ送受信関数::
4517-* 問い合わせ結果情報の取得::
4518-* 配列を使った問い合わせ結果の取得のための高レベル関数::
4768+* Database Connection Control Functions::
4769+* Connection Status Functions::
4770+* Command Execution Functions::
4771+* Asynchronous Command Processing::
4772+* Functions for Sending and Receiving COPY Data::
4773+* Retrieving Query Result Information::
4774+* Higher-level Functions to Retrieve Query Results Using Arrays::
45194775 @end menu
45204776
4777+
45214778 @node Database Connection Control Functions
45224779 @appendixsec データベース接続制御関数
45234780
45244781 @table @code
4525-
45264782 @cindex @code{pg_connect} pgsql extension function
45274783 @cindex @code{PQconnectdb} libpq function
45284784 @item pg_connect(@r{[}@var{conninfo}@r{]})
4529-データベースの接続を始める。
4530-引数の文字列 @var{conninfo} は @code{PQconnectdb} 関数へ渡されます。
4531-成功すれば、ユニークでオペークな接続ハンドルが返されます。
4532-失敗すれば、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4785+データベースの接続を始めます。
4786+引数の文字列@var{conninfo}は@code{PQconnectdb}関数へ渡されます。
4787+成功すれば、ユニークでopaqueな接続ハンドルが返されます。
4788+失敗すれば、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
45334789
45344790 @cindex @code{pg_connectdb} pgsql extension function
45354791 @item pg_connectdb(@r{[}@var{conninfo}@r{]})
4536-この関数は単に @code{pg_connect} の別名です。
4792+この関数は単に@code{pg_connect}の別名です。
45374793
45384794 @cindex @code{pg_disconnect} pgsql extension function
45394795 @cindex @code{PQfinish} libpq function
45404796 @item pg_disconnect(@var{conn})
4541-@var{conn} で示されるハンドルで @code{PQfinish} 関数を呼び出します。
4542-@var{conn} ハンドルは、その前に @code{pg_connect} を呼び出したことによって戻されたものでなければなりません。
4543-このハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4544-成功すれば、0 が返され、@var{conn} と関連付けられた接続はもはや有効ではありません。
4797+@var{conn}で示されるハンドルを使って@code{PQfinish}関数を呼び出します。
4798+@var{conn}ハンドルは、その前に@code{pg_connect}を呼び出したことによって返されたものでなければなりません。
4799+このハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。
4800+成功すれば、0が返され、@var{conn}と関連付けられた接続はもはや有効ではありません。
45454801
45464802 @cindex @code{pg_finish} pgsql extension function
45474803 @item pg_finish(@var{conn})
4548-この関数は単に @code{pg_disconnect} の別名です。
4804+この関数は単に@code{pg_disconnect}の別名です。
45494805
45504806 @cindex @code{pg_reset} pgsql extension function
45514807 @cindex @code{PQreset} libpq function
45524808 @item pg_reset(@var{conn})
4553-@var{conn} で示されるハンドルで @code{PQreset} 関数を呼び出します。
4554-@var{conn} ハンドルは、その前に @code{pg_connect} を呼び出したことによって戻されたものでなければなりません。
4555-このハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4556-そうでなければ、@code{PQreset} が呼び出されます。
4557-もし @code{PQstatus} が返す次の値が @code{CONNECTION_OK} ならば、その時は 0 が返され、そうでなければ -1 返されて、@code{ERRNO} がセットされます。
4809+@var{conn}で示されるハンドルを使って、@code{PQreset}関数を呼び出します。
4810+@var{conn}ハンドルは、その前に@code{pg_connect}を呼び出したことによって戻されたものでなければなりません。
4811+このハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。
4812+そうでなければ、@code{PQreset}が呼び出されます。
4813+もし、@code{PQstatus}が返す次の値が@code{CONNECTION_OK}ならば、0が返されます。
4814+そうでなければ、-1返されて、@code{ERRNO}がセットされます。
45584815
45594816 @cindex @code{pg_reconnect} pgsql extension function
45604817 @item pg_reconnect(@var{conn})
4561-この関数は単に @code{pg_reset} の別名です。
4562-
4818+この関数は単に@code{pg_reset}の別名です。
45634819 @end table
45644820
4821+
45654822 @node Connection Status Functions
45664823 @appendixsec 接続ステータス関数
45674824
@@ -4570,137 +4827,138 @@ Cygwin のようなプラットフォームでは、このオプションは拡
45704827 @cindex @code{pg_errormessage} pgsql extension function
45714828 @cindex @code{PQerrorMessage} libpq function
45724829 @item pg_errormessage(@var{conn})
4573-この関数は指定された接続について @code{PQerrorMessage} を呼び出し、その結果を返します。
4574-接続が見つからないときは、戻り値はヌル文字列 (@code{""}) で、@code{ERRNO} がセットされます。
4830+この関数は指定された接続について@code{PQerrorMessage}を呼び出し、その結果を返します。
4831+接続が見つからない時は、戻り値はヌル文字列(@code{""})で、@code{ERRNO}がセットされます。
45754832
45764833 @end table
45774834
4835+
45784836 @node Command Execution Functions
45794837 @appendixsec コマンド実行関数
45804838
45814839 @table @code
4582-
45834840 @cindex @code{pg_getresult} pgsql extension function
45844841 @cindex @code{PQgetResult} libpq function
45854842 @item pg_getresult(@var{conn})
4586-接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4587-そうでなければ、@code{PQgetResult} が指定された接続について呼び出されます。
4588-それが NULL を返すならば、ヌル文字列 (@code{""}) を返します。
4589-返された @code{PGresult} が非 NULL ならば、戻り値は、@code{PQresultStatus(PQgetResult(@var{conn}))} の値に依存します。
4843+接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
4844+そうでなければ、@code{PQgetResult}が、指定された接続に対して呼び出されます。
4845+それがNULLを返すならば、ヌル文字列(@code{""})を返します。
4846+返された@code{PGresult}が非NULLならば、戻り値は、@code{PQresultStatus(PQgetResult(@var{conn}))}の値に依存します。
45904847 以下の通りです。
45914848
45924849 @table @code
4593-
45944850 @item PGRES_TUPLES_OK
4595-この関数は、SQL クエリによって返される行へアクセスするために使われる文字列ハンドルを返します。
4596-文字列ハンドルのフォーマットは @code{TUPLES <# of rows> <unique identifier>} です。
4597-返されるハンドル 2 番目のワードを取り出すか、@code{pg_ntuples} 関数を呼び出すことで行数を知ることができます。
4598-返された文字列ハンドルは、返されたデータをその後取り出すために使われる @code{PGresult} ポインタにマップされています。
4851+この関数は、SQLクエリによって返される行へアクセスするために使われる文字列ハンドルを返します。
4852+文字列ハンドルのフォーマットは、@code{TUPLES <# of rows> <unique identifier>}です。
4853+返されるハンドルの2番目のワードを取り出すか、@code{pg_ntuples}関数を呼び出すことで行数を知ることができます。
4854+返された文字列ハンドルは、返されたデータをその後取り出すために使われる@code{PGresult}ポインタにマップされています。
45994855
46004856 @item PGRES_COMMAND_OK
4601-まず、@code{PQcmdTulples} を呼び出し、次に @code{OK <result of PQcmdTuples>} という文字列を返します。
4602-返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。
4857+まず、@code{PQcmdTulples}を呼び出します。
4858+次に、@code{OK <result of PQcmdTuples>}という文字列を返します。
4859+返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。
46034860
46044861 @item PGRES_EMPTY_QUERY
4605-これは @code{PGRES_COMMAND_OK} と同じやり方で処理されます。
4862+これは、@code{PGRES_COMMAND_OK}と同じやり方で処理されます。
46064863
46074864 @item PGRES_COPY_IN
4608-返される文字列は @code{COPY_IN <PQnfields(res)> @{BINARY|TEXT@}} というフォーマットです。
4609-返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。
4610-ユーザのコードが続けて @code{pg_putcopydata} を呼び出して、サーバに大量のデータを送信するかもしれません (そして @code{pg_putcopyend} を使って転送を終了します)。
4865+返される文字列は、@code{COPY_IN <PQnfields(res)> @{BINARY|TEXT@}}というフォーマットです。
4866+返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。
4867+ユーザのコードが、続けて、@code{pg_putcopydata}を呼び出して、サーバに大量のデータを送信するかもしれません(そして、@code{pg_putcopyend}を使って転送を終了します)。
46114868
46124869 @item PGRES_COPY_OUT
4613-返される文字列は @code{COPY_OUT <PQnfields(res)> @{BINARY|TEXT@}} です。
4614-返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。
4615-ユーザのコードは、ヌル文字列 (@code{""}) を返すまで、@code{pg_getcopydata} を呼び出し続けるべきです。
4870+返される文字列は、@code{COPY_OUT <PQnfields(res)> @{BINARY|TEXT@}}です。
4871+返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。
4872+ユーザのコードは、ヌル文字列(@code{""})を返すまで、@code{pg_getcopydata}を呼び出し続けるべきです。
46164873
46174874 @item default (unhandled value)
4618-これは処理されていない戻り値ですので、標準化されたエラー文字列を @code{ERROR @r{[}BADCONN @r{]}<status>} というフォーマットで返します。
4619-ここで、@code{BADCONN} は、@code{PQstatus(conn)} が @code{CONNECTION_OK} と等しくない場合に含まれます。
4620-また、その次の文字列は @code{PQresStatus(PQresultStatus(res))} の呼び出しの結果です。
4621-そして、@code{ERRNO} を、 @code{PQresultErrorMessage(res)} によって返される文字列にセットします。
4622-返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。
4623-
4875+これは、処理されていない戻り値です。
4876+標準化されたエラー文字列を、@code{ERROR @r{[}BADCONN @r{]}<status>}というフォーマットで返します。
4877+ここで、@code{BADCONN}は、@code{PQstatus(conn)}が@code{CONNECTION_OK}と等しくない場合に含まれます。
4878+また、その次の文字列は@code{PQresStatus(PQresultStatus(res))}の呼び出しの結果です。
4879+そして、@code{PQresultErrorMessage(res)}によって返される文字列に@code{ERRNO}をセットします。
4880+返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。
46244881 @end table
46254882
46264883 @cindex @code{pg_clear} pgsql extension function
46274884 @cindex @code{PQclear} libpq function
46284885 @item pg_clear(@var{res})
4629-結果のハンドルが見付からなければ -1 が返され、@code{ERRNO} がセットされます。
4630-そうでなければ、@code{PQclear(res)} が呼び出され、0 が返されます。
4886+結果のハンドルが見付からなければ-1が返され、@code{ERRNO}がセットされます。
4887+そうでなければ、@code{PQclear(res)}が呼び出され、0が返されます。
46314888
46324889 @cindex @code{pg_exec} pgsql extension function
46334890 @cindex @code{PQexec} libpq function
46344891 @item pg_exec(@var{conn}, @var{command})
4635-接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4636-でなければ、@code{PQexec} が @var{command} 文字列で呼び出されます。
4637-@code{PQexec} が NULL を返す場合、戻り値は @code{"ERROR "} で始まります。
4638-@code{PQstatus} が @code{CONNECTION_OK} を返さない場合は、戻り値の次のワードが @code{"BADCONN"} となっています。
4639-それから、@code{PQresStatus(PQresultStatus(NULL))} の呼び出し結果がその文字列に追加されます。
4640-加えて、@code{ERRNO} が @code{PQerrorMessage} によって返される文字列にセットされます。
4641-一方、@code{PQexec} が NULL を返さない場合は、結果は @code{pg_getresult} によって返される標準フォーマットになります。
4892+接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
4893+でなければ、@code{PQexec}が、@var{command}文字列で呼び出されます。
4894+@code{PQexec}がNULLを返す場合、戻り値は@code{"ERROR "}で始まります。
4895+@code{PQstatus}が@code{CONNECTION_OK}を返さない場合は、戻り値の次のワードが@code{"BADCONN"}となっています。
4896+それから、@code{PQresStatus(PQresultStatus(NULL))}の呼び出し結果がその文字列に追加されます。
4897+加えて、@code{ERRNO}は、@code{PQerrorMessage}によって返される文字列にセットされます。
4898+一方、@code{PQexec}がNULLを返さない場合は、結果は、@code{pg_getresult}によって返される標準フォーマットになります。
46424899
46434900 @cindex @code{pg_execparams} pgsql extension function
46444901 @cindex @code{PQexecParams} libpq function
46454902 @item pg_execparams(@var{conn}, @var{command}, @var{nParams} @r{[}, @var{paramValues}@r{]})
4646-接続が見つからない場合、あるいは @var{nParams} が負の場合は、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4647-そうでなければ、@code{paramTypes}、@code{paramLengths}、そして@code{ParamFormats} の各引数が NULL にセットされ、それらの引数で @code{PQexecParams} が呼び出されます。
4648-@code{paramValues} 配列は、@code{$n} と一致する値を @code{paramValues[n]} として探すのに使われます。
4649-戻り値は @code{pg_exec} の場合と同じです。
4903+接続が見つからない場合、あるいは、@var{nParams}が負の場合は、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
4904+そうでなければ、@code{paramTypes}、@code{paramLengths}、@code{ParamFormats}の各引数がNULLにセットされ、それらの引数で@code{PQexecParams}が呼び出されます。
4905+@code{paramValues}配列は、@code{$n}と一致する値を、@code{paramValues[n]}として探すのに使われます。
4906+戻り値は、@code{pg_exec}の場合と同じです。
46504907
46514908 @cindex @code{pg_prepare} pgsql extension function
46524909 @cindex @code{PQprepare} libpq function
46534910 @item pg_prepare(@var{conn}, @var{command})
4654-接続が見つからない場合は、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4655-そうでなければ、@code{PQprepare} が @var{command} 文字列で呼び出されます。
4656-@code{PQprepare} が NULL を返す場合、あるいは @code{PQresultStatus(result) != PGRES_COMMAND_OK} の場合は、この関数はヌル文字列 @code{""} を返し、@code{ERRNO} をセットします。
4657-そうでない場合、成功すれば、@code{pg_execprepared} や @code{pg_sendqueryprepared} で使えるオペークなステートメントハンドルが返されます。
4911+接続が見つからない場合は、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
4912+そうでなければ、@code{PQprepare}が@var{command}文字列で呼び出されます。
4913+@code{PQprepare}がNULLを返す場合、あるいは、@code{PQresultStatus(result) != PGRES_COMMAND_OK}の場合は、この関数はヌル文字列@code{""}を返し、@code{ERRNO}をセットします。
4914+そうでない場合、成功すれば、@code{pg_execprepared}や@code{pg_sendqueryprepared}で使えるopaqueなステートメントハンドルが返されます。
46584915
46594916 @cindex @code{pg_execprepared} pgsql extension function
46604917 @cindex @code{PQexecParams} libpq function
46614918 @item pg_execprepared(@var{conn}, @var{stmtName}, @var{nParams} @r{[}, @var{paramValues}@r{]})
4662-この関数は、SQL コマンドの代わりに 2 番目の引数として、前もっと用意されているステートメントハンドルを必要とするということを除いて、@code{pg_execparams} と同様に動作します。
4663-
4919+この関数は、@code{pg_execparams}と同様に動作します。
4920+ただし、SQLコマンドの代わりに、2番目の引数として、予め用意されているステートメントハンドルを必要とします。
46644921 @end table
46654922
4923+
46664924 @node Asynchronous Command Processing
46674925 @appendixsec 非同期コマンド処理
46684926
46694927 @table @code
4670-
46714928 @cindex @code{pg_sendquery} pgsql extension function
46724929 @cindex @code{PQsendQuery} libpq function
46734930 @item pg_sendquery(@var{conn}, @var{command})
4674-接続が見つからなければ、0 が返され、@code{ERRNO} がセットされます。
4675-そうでない場合、指定された @var{command} で @code{PQsendQuery} が呼び出され、その結果が返されます (失敗の時は 0、成功の時は 1 のはずです)。
4676-戻り値が 0 の場合は、@code{ERRNO} がセットされます。
4677-結果を取得するには @code{pg_getresult} を呼び出してください。
4678-ヌル文字列 (@code{""}) を返すまで @code{pg_getresult} を呼び出し続けなければなりません。
4931+接続が見つからなければ、0が返され、@code{ERRNO}がセットされます。
4932+そうでない場合、指定された@var{command}で@code{PQsendQuery}が呼び出され、その結果が返されます(失敗の時は0、成功の時は1です)。
4933+戻り値が0の場合は、@code{ERRNO}がセットされます。
4934+結果を取得するには@code{pg_getresult}を呼び出してください。
4935+ヌル文字列(@code{""})を返すまで@code{pg_getresult}を呼び出し続けなければなりません。
46794936
46804937 @cindex @code{pg_sendqueryparams} pgsql extension function
46814938 @cindex @code{PQsendQueryParams} libpq function
46824939 @item pg_sendqueryparams(@var{conn}, @var{command}, @var{nParams} @r{[}, @var{paramValues}@r{]})
4683-接続が見つからなければ、あるいは @var{nParams} が負であれば、0 が返され、@code{ERRNO} がセットされます。
4684-そうでない場合、NULL にセットされた @code{paramTypes}、@code{paramLengths}、@code{paramFormats} 引数を付けて @code{PQsendQueryParams} が呼び出され、その結果が返されます。
4685-@code{pg_execparams} と同様に、@code{$n} に一致する値は @code{paramValues[n]} の中にあります。
4686-もし戻り値が 0 ならば、@code{ERRNO} がセットされます。
4940+接続が見つからなければ、あるいは、@var{nParams}が負であれば、0が返され、@code{ERRNO}がセットされます。
4941+そうでない場合、NULLにセットされた@code{paramTypes}、@code{paramLengths}、@code{paramFormats}引数を付けて@code{PQsendQueryParams}が呼び出され、その結果が返されます。
4942+@code{pg_execparams}と同様に、@code{$n}に一致する値は@code{paramValues[n]}の中にあります。
4943+もし、戻り値が0ならば、@code{ERRNO}がセットされます。
46874944
46884945 @cindex @code{pg_sendprepare} pgsql extension function
46894946 @cindex @code{PQsendPrepare} libpq function
46904947 @item pg_sendprepare(@var{conn}, @var{command})
4691-接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4692-そうでない場合、@var{command} 文字列で @code{PQsetPrepare} が呼び出されます。
4693-@code{PQsendPrepare} が 0 を返すならば、この関数はヌル文字列 @code{""} を返し、@code{ERRNO} をセットします。
4694-そうでなければ、@code{pg_sendqueryprepared} や @code{pg_execprepared} で利用できる opaque なステートメントハンドルが返されます。
4695-コマンドが成功して完了したかどうかを確かめるには @code{pg_getresult} を呼び出してください。
4948+接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
4949+そうでない場合、@var{command}文字列で@code{PQsetPrepare}が呼び出されます。
4950+@code{PQsendPrepare}が0を返すならば、この関数はヌル文字列@code{""}を返し、@code{ERRNO}をセットします。
4951+そうでなければ、@code{pg_sendqueryprepared}や@code{pg_execprepared}で利用できるopaqueなステートメントハンドルが返されます。
4952+コマンドが成功して完了したかどうかを確かめるには@code{pg_getresult}を呼び出してください。
46964953
46974954 @cindex @code{pg_sendqueryprepared} pgsql extension function
46984955 @cindex @code{PQsendQueryPrepared} libpq function
46994956 @item pg_sendqueryprepared(@var{conn}, @var{stmtName}, @var{nParams} @r{[}, @var{paramValues}@r{]})
4700-この関数は、SQL コマンドの代わりに 2 番目の引数として予め用意しておいたステートメントハンドルを必要とすることを除いて、@code{pg_sendqueryparams} と同じように動作します。
4701-
4957+この関数は、@code{pg_sendqueryparams}と同じように動作します。
4958+ただし、SQLコマンドの代わりに、2番目の引数として、予め用意しておいたステートメントハンドルを必要とします。
47024959 @end table
47034960
4961+
47044962 @node Functions for Sending and Receiving COPY Data
47054963 @appendixsec コピーデータ送受信関数
47064964
@@ -4709,28 +4967,29 @@ Cygwin のようなプラットフォームでは、このオプションは拡
47094967 @cindex @code{pg_putcopydata} pgsql extension function
47104968 @cindex @code{PQputCopyData} libpq function
47114969 @item pg_putcopydata(@var{conn}, @var{buffer})
4712-接続が見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4713-そうでない場合、@var{buffer} 引数で @code{PQputCopyData} が呼び出され、その値が返されます。
4714-もし、@code{PQputCopyData} が -1 を返すならば、@code{ERRNO} がセットされます。
4970+接続が見つからなければ、-1が返され、@code{ERRNO}がセットされます。
4971+そうでない場合、@var{buffer}引数で@code{PQputCopyData}が呼び出され、その値が返されます。
4972+もし、@code{PQputCopyData}が-1を返すならば、@code{ERRNO}がセットされます。
47154973
47164974 @cindex @code{pg_putcopyend} pgsql extension function
47174975 @cindex @code{PQputCopyEnd} libpq function
47184976 @item pg_putcopyend(@var{conn} @r{[}, @var{errormsg}@r{]})
4719-接続が見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4720-そうでない場合、もしあればオプショナルな @var{errormsg} 引数で @code{PQputCopyEnd} が呼び出され、その値が返されます。
4721-もし @code{PQputCopyEnd} が -1 を返すならば、@code{ERRNO} がセットされます。
4977+接続が見つからなければ、-1が返され、@code{ERRNO}がセットされます。
4978+そうでない場合、もしあれば、オプショナルな@var{errormsg}引数で@code{PQputCopyEnd}が呼び出され、その値が返されます。
4979+もし、@code{PQputCopyEnd}が-1を返すならば、@code{ERRNO}がセットされます。
47224980
47234981 @cindex @code{pg_getcopydata} pgsql extension function
47244982 @cindex @code{PQgetCopyData} libpq function
47254983 @item pg_getcopydata(@var{conn})
4726-接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4727-そうでない場合、@code{FALSE} にセットされた @var{async} 引数で @code{PQgetCopyData} が呼び出されます。
4728-もし @code{PQgetCopyData} が -1 を返すならば、そのコピーが行なわれ、ヌル文字列 (@code{""}) が返されます (@code{COPY} コマンドの最終的な結果のステータスを取得するために、ユーザは @code{pg_getresult} を呼び出さなければなりません)。
4729-戻り値が、エラーを示す -2 であれば、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4984+接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
4985+そうでない場合、@code{FALSE}にセットされた@var{async}引数で@code{PQgetCopyData}が呼び出されます。
4986+もし、@code{PQgetCopyData}が-1を返すならば、そのコピーが行われ、ヌル文字列(@code{""})が返されます(@code{COPY}コマンドの最終的な結果のステータスを取得するために、ユーザは、@code{pg_getresult}を呼び出さなければなりません)。
4987+戻り値が、エラーを示す-2であれば、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
47304988 そうでなければ、取得された行が返されます。
47314989
47324990 @end table
47334991
4992+
47344993 @node Retrieving Query Result Information
47354994 @appendixsec 問い合わせ結果情報の取得
47364995
@@ -4739,35 +4998,36 @@ Cygwin のようなプラットフォームでは、このオプションは拡
47394998 @cindex @code{pg_nfields} pgsql extension function
47404999 @cindex @code{PQnfields} libpq function
47415000 @item pg_nfields(@var{res})
4742-引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4743-そうでなければ、@code{PQnfields(res)} の値が返されます。
5001+引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。
5002+そうでなければ、@code{PQnfields(res)}の値が返されます。
47445003
47455004 @cindex @code{pg_ntuples} pgsql extension function
47465005 @cindex @code{PQntuples} libpq function
47475006 @item pg_ntuples(@var{res})
4748-引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4749-そうでなければ、@code{PQntuples(res)} の値が返されます。
5007+引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。
5008+そうでなければ、@code{PQntuples(res)}の値が返されます。
47505009
47515010 @cindex @code{pg_fname} pgsql extension function
47525011 @cindex @code{PQfname} libpq function
47535012 @item pg_fname(@var{res}, @var{column_number})
4754-引数 @var{res} の結果ハンドルが見つからない場合、あるいは、@var{column_number} が範囲外であった場合はヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4755-そうでなければ、@code{PQfname(res, column_number)} の値が返されます。
5013+引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{column_number}が範囲外であった場合、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
5014+そうでなければ、@code{PQfname(res, column_number)}の値が返されます。
47565015
47575016 @cindex @code{pg_getvalue} pgsql extension function
47585017 @cindex @code{PQgetvalue} libpq function
47595018 @item pg_getvalue(@var{res}, @var{row_number}, @var{column_number})
4760-引数 @var{res} の結果ハンドルが見つからない場合、あるいは、@var{row_number} か @var{column_number} が範囲外であった場合、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。
4761-そうでなければ、@code{PQgetvalue(res, row_number, column_number)} の値が返されます。
5019+引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{row_number}か@var{column_number}が範囲外であった場合、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。
5020+そうでなければ、@code{PQgetvalue(res, row_number, column_number)}の値が返されます。
47625021
47635022 @cindex @code{pg_getisnull} pgsql extension function
47645023 @cindex @code{PQgetisnull} libpq function
47655024 @item pg_getisnull(@var{res}, @var{row_number}, @var{column_number})
4766-引数 @var{res} の結果ハンドルが見つからなければ、あるいは、@var{row_number} か @var{column_number} が範囲外であったならば、-1 が返され、@code{ERRNO} がセットされます。
4767-そうでなければ、@code{PQgetisnull(res, row_number, column_number)} の値が返されます (データが NULL ならば 1、非 NULL ならば 0 です)。
5025+引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{row_number}か@var{column_number}が範囲外の場合、-1が返され、@code{ERRNO}がセットされます。
5026+そうでなければ、@code{PQgetisnull(res, row_number, column_number)}の値が返されます(データがNULLならば1、非NULLならば0です)。
47685027
47695028 @end table
47705029
5030+
47715031 @node Higher-level Functions to Retrieve Query Results Using Arrays
47725032 @appendixsec 配列を使った問い合わせ結果の取得のための高レベル関数
47735033
@@ -4775,142 +5035,149 @@ Cygwin のようなプラットフォームでは、このオプションは拡
47755035
47765036 @cindex @code{pg_fields} pgsql extension function
47775037 @item pg_fields(@var{res}, @var{field_names})
4778-引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4779-そうでなければ、結果のフィールド数 (すなわち @code{pg_nfields(res)}) が返され、配列 @code{field_names} がクリアされて、@code{PQfname(res, col)} によって返された値が @code{field_names[col]} に入るようにカラム名がそこに入れられます。
5038+引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。
5039+そうでなければ、結果のフィールド数(すなわち@code{pg_nfields(res)})が返されます。
5040+配列@code{field_names}はクリアされ、@code{PQfname(res, col)}によって返された値が@code{field_names[col]}に入るようにカラム名がそこに入れられます。
47805041
47815042 @cindex @code{pg_fieldsbyname} pgsql extension function
47825043 @item pg_fieldsbyname(@var{res}, @var{field_names})
4783-引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。
4784-そうでなければ、結果のフィールド数 (すなわち、@code{pg_nfields(res)}) が返され、配列 @var{field_names} がクリアされて、@code{fields_names[PQfname(res, col)]} が @code{col} を含むようになるようカラム名がそこに入れられます。
5044+引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。
5045+そうでなければ、結果のフィールド数(すなわち、@code{pg_nfields(res)})が返されます。
5046+配列@var{field_names}はクリアされ、@code{fields_names[PQfname(res, col)]}が@code{col}を含むようになるようカラム名がそこに入れられます。
47855047
47865048 @cindex @code{pg_getrow} pgsql extension function
47875049 @item pg_getrow(@var{res}, @var{row_number}, @var{field})
4788-引数 @var{res} の結果ハンドルが見つからければ、あるいは @var{row_number} が範囲外であったならば、-1 が返され、@code{ERRNO} がセットされます。
4789-そうでなければ、行の中の NULL でないフィールドの数が返され、配列 @var{field} がクリアされ、@code{field[col_number]} に、NULL でない全てのカラムについて @code{PQgetvalue(res, row_number, col_number)} 入るようにデータが入れられます。
5050+引数@var{res}の結果ハンドルが見つからなければ、あるいは、@var{row_number}が範囲外であったならば、-1が返され、@code{ERRNO}がセットされます。
5051+そうでなければ、行の中のNULLでないフィールドの数が返されます。
5052+配列@var{field}はクリアされ、NULLでない全てのカラムについて、@code{field[col_number]}が、@code{PQgetvalue(res, row_number, col_number)}となるようにデータが入れられます。
47905053
47915054 @cindex @code{pg_getrowbyname} pgsql extension function
47925055 @item pg_getrowbyname(@var{res}, @var{row_number}, @var{field})
4793-引数 @var{res} の結果ハンドルが見つからない場合、あるいは、@var{row_number} が範囲外である場合、-1 が返され、@code{ERRNO} がセットされます。
4794-そうでなければ、その行の NULL でないフィールドの数が返されます。
4795-そして、配列 @var{field} がクリアされ、NULL でない全てのカラムについて @code{field[PQfname(res, col_number)]} に @code{PQgetvalue(res, row_number, col_number)} が入るようにデータが入れられます。
4796-
5056+引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{row_number}が範囲外である場合、-1が返され、@code{ERRNO}がセットされます。
5057+そうでなければ、その行のNULLでないフィールドの数が返されます。
5058+配列@var{field}がクリアされ、NULLでない全てのカラムについて、@code{field[PQfname(res, col_number)]}が、@code{PQgetvalue(res, row_number, col_number)}となるようにデータが入れられます。
47975059 @end table
47985060
4799-@node Time Extension Reference
4800-@appendix Time Extension リファレンス
48015061
5062+@node Time Extension Reference
5063+@appendix Time Extensionリファレンス
48025064 @cindex time
48035065 @cindex sleep
48045066
4805-これらの関数は、@option{-l time} というコマンドライン引数を付けて @command{xgawk} を起動するか、スクリプトに @code{@@load time} を挿入するか、どちらかで使うことができます。
5067+これらの関数は、@option{-l time}というコマンドライン引数を付けて@command{xgawk}を起動するか、スクリプトに@code{@@load time}を挿入するか、どちらかで使うことができます。
48065068
48075069 @table @code
48085070
48095071 @cindex @code{gettimeofday} time extension function
48105072 @item gettimeofday()
4811-この関数は、1970-01-01 UTC から経過した時間を浮動小数点で返します。
4812-これは 1 秒以下の精度を持つべきですが、実際の精度はプラットフォームによって変わります。
4813-もし、このプラットフォームで時刻が利用できないのならば、-1 を返して、@code{ERRNO} をセットします。
4814-標準の @code{gettimeofday} 関数が利用可能ならば、単にその値を返します。
4815-そうでない場合、もし Windows 上であれば、@code{GetSystemTimeAsFileTime} を使うことを試みます。
5073+この関数は、1970-01-01 UTCから経過した時間を浮動小数点で返します。
5074+1秒以下の精度を持つはずですが、プラットフォームによって実際の精度は変わります。
5075+もし、プラットフォームで時刻が利用できないのならば、-1を返して、@code{ERRNO}をセットします。
5076+標準の@code{gettimeofday}関数が利用可能ならば、単にその値を返します。
5077+利用できない場合、Windows上であれば、@code{GetSystemTimeAsFileTime}を使うことを試みます。
48165078
48175079 @cindex @code{sleep} time extension function
48185080 @item sleep(@var{seconds})
4819-この関数は、@var{seconds} 秒間のスリープを試みます。
4820-@var{senconds} は浮動小数点の (不可欠須ではない) 値かもしれないことに注意してください。
4821-@var{seconds} が負であるか、あるいは、スリープする試みが失敗した場合、-1 が返され、@code{ERRNO} がセットされます。
4822-そうでなければ、この関数は、指示されただけの時間スリープした後 0 を返すはずです。
4823-実装の詳細としては、プラットフォームの利用可能性に応じて、@code{nanosleep} を使ったり、@code{select} を使ったりして遅延を実装しようと試みています。
4824-
5081+この関数は、@var{seconds}秒間のスリープを試みます。
5082+@var{senconds}は、浮動小数点数(不可欠ではない)かもしれないことに注意してください。
5083+@var{seconds}が負であるか、あるいは、スリープする試みが失敗した場合、-1が返され、@code{ERRNO}がセットされます。
5084+そうでなければ、この関数は、指示されただけの時間スリープした後、0を返します。
5085+実装の詳細としては、プラットフォームの利用可能性に応じて、@code{nanosleep}を使ったり、@code{select}を使ったりして遅延を実装しようと試みています。
48255086 @end table
48265087
4827-@node GD Graphics Extension Reference
4828-@appendix GD グラフィックス拡張リファレンス
48295088
5089+@node GD Graphics Extension Reference
5090+@appendix GDグラフィックス拡張リファレンス
48305091 @cindex GD
48315092
4832-@uref{http://www.boutell.com/gd/manual2.0.33.html} でドキュメントされているのと同じように、ここで説明されている関数は GD graphics API を明らかにするものです。
4833-このドキュメンテーションは GD ドキュメンテーションと合わせることで初めて理解することができます。
5093+@uref{http://www.boutell.com/gd/manual2.0.33.html}でドキュメントされているのと同じように、ここで説明されている関数はGD graphics APIを明らかにするものです。
5094+このドキュメントは、GDドキュメントと合わせることで初めて理解することができます。
48345095
4835-これらの関数は、@option{-l gd} というコマンドライン引数を付けて @command{xgawk} を起動するか、スクリプトに @code{@@load gd} を挿入することで使えるようになります。
5096+これらの関数は、@option{-l gd}というコマンドライン引数を付けて@command{xgawk}を起動するか、スクリプトに@code{@@load gd}を挿入することで使えるようになります。
48365097
48375098 @table @code
4838-
48395099 @cindex @code{gdImageCreateFromFile} GD graphics extension function
48405100 @item gdImageCreateFromFile(@var{img_dst}, @var{file_name})
4841-この関数を使って、オリジナルの @code{gdImageCreateFromJpeg()} や @code{gdImageCreateFromPng()}、@code{gdImageCreateFromGif()} の代わりに、PNG、JPG、GIF ファイルから画像をロードします。
5101+この関数を使って、オリジナルの@code{gdImageCreateFromJpeg()}、@code{gdImageCreateFromPng()}、@code{gdImageCreateFromGif()}の代わりに、PNG、JPG、GIFファイルから画像をロードします。
48425102 画像ハンドルを返します。
4843-失敗した場合は空文字列を返します。
5103+失敗した場合、空文字列を返します。
48445104
48455105 @cindex @code{gdImageCopyResampled} GD graphics extension function
48465106 @item gdImageCopyResampled(@var{img_dst}, @var{img_src}, @var{dstX}, @var{dstY}, @var{srcX}, @var{srcY}, @var{destW}, @var{destH}, @var{srcW}, @var{srcH})
4847-成功した場合は 0 を、失敗した場合は -1 を返します。
5107+成功した場合は、0を返します。
5108+失敗した場合は、-1を返します。
48485109
48495110 @cindex @code{gdImageCreateTrueColor} GD graphics extension function
48505111 @item gdImageCreateTrueColor(@var{width}, @var{height})
48515112 画像ハンドルを返します。
4852-失敗したら空文字列を返します。
5113+失敗した場合、空文字列を返します。
48535114
48545115 @cindex @code{gdImageDestroy} GD graphics extension function
48555116 @item gdImageDestroy(@var{img})
4856-成功した場合は 0 を、失敗した場合は -1 を返します。
5117+成功した場合は、0を返します。
5118+失敗した場合は、-1を返します。
48575119
48585120 @cindex @code{gdImagePngName} GD graphics extension function
48595121 @item gdImagePngName(@var{img}, @var{file_name})
4860-この関数を使って、オリジナルの @code{gdImagePng()} の代わりに、画像を PNG ファイルとして保存します。
4861-成功した場合は 0 を、失敗した場合は -1 を返します。
5122+この関数を使って、オリジナルの@code{gdImagePng()}の代わりに、画像をPNGファイルとして保存します。
5123+成功した場合は、0を返します。
5124+失敗した場合は、-1を返します。
48625125
48635126 @cindex @code{gdImageStringFT} GD graphics extension function
48645127 @item gdImageStringFT(@var{img}, @var{brect}, @var{fg}, @var{fontname}, @var{ptsize}, @var{angle}, @var{x}, @var{y}, @var{string})
48655128 テキストを描くのに使います。
4866-brect に 8 個の整数の配列を返すことに注意してください。
4867-img が空の AWK 文字列であることは、元の C 関数で img ポインタが NULL であるのと同じ意味です。
4868-GDFONTPATH 環境変数にフォントパスを設定し忘れないようにしてください。
4869-成功した場合は空文字列を返し、失敗した場合はエラーメッセージの文字列が返されます。
5129+brectに8個の整数の配列を返すことに注意してください。
5130+imgが空のAWK文字列であることは、元のC関数でimgポインタがNULLであるのと同じ意味です。
5131+GDFONTPATH環境変数にフォントパスを設定し忘れないようにしてください。
5132+成功した場合は、空文字列を返します。
5133+失敗した場合は、エラーメッセージの文字列が返されます。
48705134
48715135 @cindex @code{gdImageColorAllocate} GD graphics extension function
48725136 @item gdImageColorAllocate(@var{img}, @var{r}, @var{g}, @var{b})
4873-指定された r、g、b の値と一致する RGB カラーを返します。
4874-失敗した場合は -1 を返します。
5137+指定されたr、g、bの値と一致するRGBカラーを返します。
5138+失敗した場合は、-1を返します。
48755139
48765140 @cindex @code{gdImageFilledRectangle} GD graphics extension function
48775141 @item gdImageFilledRectangle(@var{img}, @var{x1}, @var{y1}, @var{x2}, @var{y2}, @var{color})
48785142 指定された色で長方形を塗りつぶします。
4879-成功すれば 0 を、失敗すれば -1 を返します。
5143+成功すれば、0を返します。
5144+失敗すれば、-1を返します。
48805145
48815146 @cindex @code{gdImageSetAntiAliasedDontBlend} GD graphics extension function
48825147 @item gdImageSetAntiAliasedDontBlend(@var{img}, @var{color}, @var{dont_blend})
48835148 アンチエイリアシングの際、この色をブレンドしません。
4884-成功すれば 0 を、失敗すれば -1 を返します。
5149+成功すれば、0を返します。
5150+失敗すれば、-1を返します。
48855151
48865152 @cindex @code{gdImageSetThickness} GD graphics extension function
48875153 @item gdImageSetThickness(@var{img}, @var{thickness})
48885154 線を描く時の太さをセットします。
4889-成功すれば 0 を、失敗すれば -1 を返します。
5155+成功すれば、0を返します。
5156+失敗すれば、-1を返します。
48905157
48915158 @cindex @code{gdImageSX} GD graphics extension function
48925159 @item gdImageSX(@var{img})
48935160 画像の幅を返します。
4894-失敗すれば -1 を返します。
5161+失敗すれば、-1を返します。
48955162
48965163 @cindex @code{gdImageSY} GD graphics extension function
48975164 @item gdImageSY(@var{img})
48985165 画像の高さを返します。
4899-失敗すれば -1 を返します。
5166+失敗すれば、-1を返します。
49005167
49015168 @cindex @code{gdImageCompare} GD graphics extension function
49025169 @item gdImageCompare(@var{img1}, @var{img2})
4903-画像が等しければ 0 を返します。
4904-違っていれば、GD のドキュメントに説明されている値を返します。
4905-また、img1 が無効の場合は 1<<14 を、img2 が無効の場合は 1<<15 を返します。
4906-
5170+画像が等しければ、0を返します。
5171+違っていれば、GDのドキュメントに説明されている値を返します。
5172+また、img1が無効の場合は1<<14を、img2が無効の場合は1<<15を返します。
49075173 @end table
49085174
5175+
49095176 @node MPFR Extension Reference
4910-@appendix MPFR 拡張リファレンス
5177+@appendix MPFR拡張リファレンス
49115178
49125179 @cindex MPFR
4913-@cindex 任意精度の計算
5180+@cindex Arbitrary Precision Arithmetic
49145181
49155182 @ignore
49165183
@@ -5030,27 +5297,28 @@ Arnold
50305297 @end ignore
50315298
50325299
5033-@uref{http://www.mpfr.org, MPFR} は、@uref{http://en.wikipedia.org/wiki/Floating-point, floating-point numbers} における @uref{http://en.wikipedia.org/wiki/Arbitrary_precision_arithmetic, arbitrary precision arithmetic} のためのポータブルなライブラリです。
5034-これはつまり、MPFR 拡張を使って、@uref{http://en.wikipedia.org/wiki/IEEE_754, IEEE 754-1985 standard} で定義されているような通常の浮動小数点数よりも、高い精度で (望めば低い精度でも) 数値計算を行なうことができるということです。
5300+@uref{http://www.mpfr.org, MPFR}は、@uref{http://en.wikipedia.org/wiki/Floating-point, floating-point numbers}における@uref{http://en.wikipedia.org/wiki/Arbitrary_precision_arithmetic, arbitrary precision arithmetic}のためのポータブルなライブラリです。
5301+これはつまり、MPFR拡張を使って、@uref{http://en.wikipedia.org/wiki/IEEE_754, IEEE 754-1985 standard}で定義されているような通常の浮動小数点数よりも、高い精度で(望めば低い精度でも)数値計算を行うことができるということです。
50355302
50365303 @menu
5037-* 誰が任意精度の計算を必要とするか?::
5038-* Nullary 関数::
5039-* Unary 関数::
5040-* Binary 関数::
5041-* Nullary 述語::
5042-* Unary 述語::
5043-* Binary 述語::
5044-* 数値の入出力::
5304+* Who Needs Arbitrary Precision Arithmetic ?::
5305+* Nullary Functions::
5306+* Unary Functions::
5307+* Binary Functions::
5308+* Nullary Predicates::
5309+* Unary Predicates::
5310+* Binary Predicates::
5311+* Input and Output of Numbers::
50455312 @end menu
50465313
5314+
50475315 @node Who Needs Arbitrary Precision Arithmetic ?
5048-@appendixsec 誰が任意精度の計算を必要とするか?
5049-多くのユーザにとって、そういった人たちが、この特殊な@emph{任意の精度}の数値を実際に必要としているのはなぜなのかということは明確ではありません。
5050-2 かける 2 は 4 となる。
5051-これ以上を必要としている人は誰でしょうか。
5052-実生活における計算の大半 (値段や距離の合計を計算するとか、VAT (付加価値税) 込みのガソリンの計算) においては、あなたのポケット計算機やコンピュータの精度は、実に十分良いものです。
5053-しかし、さらに少し先へ進めて、以下の多項式を計算する場合、あなたのソフトウェアの能力にいくらかの疑念が生じてきます (@uref{http://www.math.uni-wuppertal.de/org/WRST/literatur/PXSCENGL.ps.gz, PASCAL-XSC Language Reference with Examples}, page 188 から取った例)。
5316+@appendixsec 誰が任意精度の計算を必要とするか
5317+
5318+多くのユーザにとって、この特殊な@emph{任意の精度}の数値が実際に必要とされるのはなぜなのかということは明確ではありません。
5319+「2かける2は4」、これ以上を必要としている人は誰でしょうか。
5320+実生活における計算の大半(値段や距離の合計を計算するとか、VAT(付加価値税)込みのガソリンの計算)においては、ポケット計算機やコンピュータの精度は、実に十分良いものです。
5321+しかし、さらに少し先へ進めて、以下の多項式を計算するような場合、ソフトウェアの能力にいくらかの疑念が生じてきます(@uref{http://www.math.uni-wuppertal.de/org/WRST/literatur/PXSCENGL.ps.gz, PASCAL-XSC Language Reference with Examples}, page 188から取った例)。
50545322 @cindex PASCAL-XSC
50555323
50565324 @example
@@ -5059,16 +5327,17 @@ awk 'BEGIN @{x=665857; y=470832; print x^4 - 4 * y^4 - 4 * y^2 @}'
50595327 @end example
50605328
50615329 この結果の驚くところは、それが@emph{間違っている}というところです。
5062-ほんのちょっとだけというわけでなく、@code{1.0} という正確な結果と比べると、@emph{完全に}間違っています。
5063-さらに悪いことに、このソフトウェアはあなたに何の手掛かりも示しません。
5064-これは AWK が原因ではないので安心してください。
5065-AWK は、下にあるオペレーティングシステムの数値計算の実装を当てにしています (計算に使用しているプログラミング言語を問わず同じ結果になります)
5330+ほんのちょっとだけというわけでなく、@code{1.0}という正確な結果と比べると、@emph{完全に}間違っています。
5331+さらに悪いことに、このソフトウェアはユーザに何の手掛かりも示しません。
5332+これは、AWKが原因ではないので安心してください。
5333+AWKは、下にあるオペレーティングシステムの数値計算の実装を当てにしています(計算に使用しているプログラミング言語を問わず同じ結果になります)
50665334
5067-では、MPFR はこれについて何をより良く実行できるのでしょうか。
5335+では、MPFRは、これについて何をより良く実行できるのでしょうか。
50685336 まず、別の構文で問題を書き直さなければなりません。
5069-AWK の通常の計算オペレータを、等価な MPFR のオペレータへ置き換えなければなりません。
5070-これでプログラムが少し読み難くなります。
5071-以下の例は、同じ多項式を計算するためにMPFR 拡張を使ったものです。
5337+AWKの通常の計算オペレータを、等価なMPFRのオペレータへ置き換えなければなりません。
5338+これによって、プログラムが少し読み難くなります。
5339+以下の例は、同じ多項式を計算するためにMPFR拡張を使ったものです。
5340+
50725341 @example
50735342 gawk @b{-l mpfr} 'BEGIN @{x=665857; y=470832; \
50745343 print @b{mpfr_sub(mpfr_sub(mpfr_pow(x, 4), mpfr_mul(4, mpfr_pow(y, 4)))}, 4 * y^2)@}'
@@ -5076,12 +5345,12 @@ gawk @b{-l mpfr} 'BEGIN @{x=665857; y=470832; \
50765345 @end example
50775346
50785347 @cindex IEEE 754-1985
5079-デフォルトでは、MPFR 拡張は、オペレーティングシステムで実装されている通常の IEEE 754 互換のオペレータと同じ精度 (仮数部で 53 ビット) で計算をします。
5348+デフォルトでは、MPFR拡張は、オペレーティングシステムで実装されている通常のIEEE 754互換のオペレータと同じ精度(仮数部で53ビット)で計算をします。
50805349 ゆえに、その結果は上のものと同じになります。
5081-ここまでのところ有利な点はありません。
5082-では、どのようにすれば MPFR の@emph{任意の精度}の能力を最終的に活用することができるでしょうか。
5083-私たちは、その数値の仮数部にあともういくらかのビットを使うように MPFR に指示しなければなりません。
5084-この場合だと 80 ビットで十分です。
5350+ここまでのところ、有利な点はありません。
5351+では、どのようにすればMPFRの@emph{任意の精度}の能力を最終的に活用することができるでしょうか。
5352+その数値の仮数部に、さらにいくらかのビットを使うようにMPFRに指示しなければなりません。
5353+この場合だと80ビットで十分です。
50855354
50865355 @example
50875356 gawk -l mpfr 'BEGIN @{@b{MPFR_PRECISION = 80}; x=665857; y=470832; \
@@ -5089,62 +5358,67 @@ gawk -l mpfr 'BEGIN @{@b{MPFR_PRECISION = 80}; x=665857; y=470832; \
50895358 1.0000000000000000000000000
50905359 @end example
50915360
5092-仮数部を 80 ビットにして計算すると、計算全体の結果が正しい (@code{1.0}) ことがわかります。
5361+仮数部を80ビットにして計算すると、計算全体の結果が正しい(@code{1.0})ことが分かります。
50935362 さて、プログラムをもう一度見てください。
50945363 多項式の最後に注意してください。
5095-多項式の最後の項が MPFR のオペレータの項として書き直されていません。
5096-まだ通常のオペレータを使っています。
5097-この例は、通常の数値と、MPFR が返す長い数値を混ぜることができるということを示しています。
5098-通常の数値と長い数値を混ぜるとかなり便利で、プログラムの読み易さを改善します。
5099-しかし、(分析的な視点から) これは悪い例です。
5100-通常の数値は、もしかすると精度が低く、多項式にそのような項が一つあると、完全な計算を台無しにしてしまうかもしれません。
5101-上記のような多項式の計算の場合では、それは問題ではありません (その項が単に @code{y} の 2 次式であって、@code{x} と @code{y} の 2 次の項ほどの長さの仮数を必要としていないからです)。
5102-しかし、もっと一般的なケース (変数が実際に@emph{変化して}、定数ではないような場合) では、MPFR の関数の項で完全な計算をするべきでしょう。
5103-
5104-まとめますと、MPFR は、浮動小数点数における任意精度の計算をするためのポータブルなライブラリです。
5105-精度は、ビット単位で、各変数に対して有効ならばどのような値も厳密にセットできます。
5106-MPFR における計算の意味は以下のように規定されます。
5107-要求された計算操作を正確に (無限の正確さで) 計算し、その結果を、行き先の変数の精度に、指定された丸めモードで丸めます。
5108-MPFR の浮動小数点関数は、IEEE 754-1985 の計算をスムーズに拡張することを目的としています。
5109-
5110-数値の内部表現は MPFR 拡張のユーザには見えません。
5364+多項式の最後の項が、MPFRのオペレータの項として書き直されていません。
5365+通常のオペレータをまだ使っています。
5366+この例は、通常の数値とMPFRが返す長い数値を混在させることができるということを示しています。
5367+通常の数値と長い数値を混用するとかなり便利で、プログラムの読み易さを改善します。
5368+しかし、分析的な視点からは、これは悪い例です。
5369+通常の数値はもしかすると精度が低く、そのような項が多項式に一つあると、完全な計算を台無しにしてしまうかもしれません。
5370+上記のような多項式の計算の場合では、それは問題ではありません(その項が単に@code{y}の2次式であって、@code{x}と@code{y}の2次の項ほどの長さの仮数を必要としていないからです)。
5371+しかし、もっと一般的なケース(変数が実際に@emph{変化して}、定数ではないような場合)では、MPFRの関数の項で完全な計算をするべきでしょう。
5372+
5373+まとめますと、MPFRは、浮動小数点数における任意精度の計算をするためのポータブルなライブラリです。
5374+精度は、各変数に対して有効ならば、どのような値でもビット単位で厳密にセットできます。
5375+MPFRにおける計算の意味は以下のように規定されます。
5376+要求された計算操作を正確に(無限の正確さで)計算し、その結果を、行き先の変数の精度に指定された丸めモードで丸めます。
5377+MPFRの浮動小数点関数は、IEEE 754-1985の計算をスムーズに拡張することを目的としています。
5378+
5379+数値の内部表現は、MPFR拡張のユーザには見えません。
51115380 ユーザには、数値は、可変長の文字列として見えます。
5112-一般的なルールとして、MPFR 関数はすべて、数値を収めた文字列として数値計算をした結果を返します。
5113-それぞれの変数の初期化や計算は以下の大域変数で制御されています。
5381+一般的なルールとして、MPFR関数は、数値を収めた文字列として数値計算をした結果を全て返します。
5382+それぞれの変数の初期化や計算は、以下の大域変数で制御されています。
51145383
51155384 @itemize
51165385 @cindex MPFR_ROUND
5117-@item MPFR_ROUND (デフォルト GMP_RNDN) は、次の値を取ります。
5118-GMP_RNDN (最近接値へ丸める)、GMP_RNDZ (ゼロ方向へ丸める)、GMP_RNDU (正の無限大方向へ丸める)、GMP_RNDD (負の無限大方向へ丸める)。
5119-これらのシンボルの値は、IEEE 754-1985 標準の四つの丸めモードと一致します。
5386+@item MPFR_ROUND(デフォルトGMP_RNDN)は、GMP_RNDN(最近接値へ丸める)、GMP_RNDZ(ゼロ方向へ丸める)、GMP_RNDU(正の無限大方向へ丸める)、GMP_RNDD(負の無限大方向へ丸める)という値を取ります。
5387+これらのシンボルの値は、IEEE 754-1985標準の四つの丸めモードと一致します。
5388+
51205389 @cindex MPFR_PRECISION
5121-@item MPFR_PRECISION (デフォルト 53) は、各変数に対してどのような有効な値にでもセットすることのできる、ビット単位の精度です (非常に小さな精度も含みます)。
5122-特に、53 ビットの精度では、MPFR は、倍精度マシンの浮動小数点数 (C でいう double 型) での全ての計算を正確に再現できるはずです。
5390+@item MPFR_PRECISION(デフォルト53)は、各変数に対してどのような有効な値にでもセットすることのできるビット単位の精度です(非常に小さな精度も含みます)。
5391+特に、53ビットの精度では、MPFRは、倍精度マシンの浮動小数点数(Cでいうdouble型)での全ての計算を正確に再現できるはずです。
51235392 デフォルトの指数範囲を除きます。
51245393 この指数範囲は、より範囲が広く標準以下の数値で、実装されていませんが、エミュレートはできます。
5394+
51255395 @cindex MPFR_EXACT
5126-@item MPFR_EXACT (デフォルト 0)。
5127-いくつかの特別な関数は、正確な戻り値の時はゼロ、正確な結果よりも大きい戻り値の時は正の値、それら以外の時は負の値を返します。
5128-この変数は、最近起動された特別な関数からの戻り値を保持しています。
5396+@item MPFR_EXACT(デフォルト0)。
5397+いくつかの特別な関数は、正確な戻り値の時は、ゼロを返し、正確な結果よりも大きい戻り値の時は、正の値を返し、それら以外の時は、負の値を返します。
5398+この変数は、最後に呼び出された特別な関数からの戻り値を保持しています。
5399+
51295400 @cindex MPFR_BASE
5130-@item MPFR_BASE (デフォルトは 10 進数の 10) には、数字を表記するのに使われる基数が入っています。
5401+@item MPFR_BASE(デフォルトは10進数の10)には、数字を表記するのに使われる基数が入っています。
51315402 @end itemize
51325403
5133-この補遺の残りの部分は、MPFR 拡張で提供される全関数のリストです。
5134-ここにリストされている関数は実際に使うことができるものだけですので注意してください。
5135-古い MPFR バージョンの obsolete でレガシーな関数はサポートされていません。
5136-サポートしている関数は、@option{-l mpfr} というコマンドライン引数を付けて @command{xgawk} を起動するか、スクリプトに @code{@@load mpfr} を挿入して起動するかした後に使えるようになります。
5137-オプショナルなパラメータは角括弧@w{ ([ ]) }で閉じてあります。
5404+この補遺の残りの部分は、MPFR拡張で提供される全関数のリストです。
5405+ここにリストされている関数は、実際に使うことができるものだけですので注意してください。
5406+古いMPFRバージョンのobsoleteでレガシーな関数はサポートされていません。
5407+サポートしている関数は、@option{-l mpfr}というコマンドライン引数を付けて@command{xgawk}を起動するか、スクリプトに@code{@@load mpfr}を挿入して起動するかした後に使えるようになります。
5408+オプショナルなパラメータは角括弧@w{([ ])}で閉じてあります。
51385409 以下のセクションでは、関数をグループ毎に紹介しています。
5139-グループの分け方は、@uref{http://en.wikipedia.org/wiki/Arity, arity} に基づいています (arity は、関数のパラメータと戻り値のシグネチャ)。
5410+グループの分け方は、@uref{http://en.wikipedia.org/wiki/Arity, arity}に基づいています(arityは、関数のパラメータと戻り値のシグネチャ)。
5411+
51405412
51415413 @node Nullary Functions
5142-@appendixsec Nullary 関数
5143-nullary 関数は、引数を取りません (@emph{null}) が、役立つ数値を返します。
5144-これらの関数は、ある数値に対する、与えられた環境 (選択された精度、基数、丸め) の下で可能な限りの最良の近似値を提供するものです。
5414+@appendixsec Nullary関数
51455415
5146-次の関数は、それぞれ、e を底とする 2 の対数、Pi の値、オイラー定数 0.577... を返します。
5147-値は、その時セットされている方向 MPFR_ROUND で丸められます。
5416+nullary関数は引数を取りません(@emph{null}引数を取ります)。
5417+しかし、有用な数値を返します。
5418+これらの関数は、ある数値に対する、与えられた環境(選択された精度、基数、丸め)の下で可能な限り最良の近似値を提供するものです。
5419+
5420+次の関数は、それぞれ、eを底とする2の対数、Piの値、オイラー定数0.577...を返します。
5421+値は、その時セットされている方向MPFR_ROUNDで丸められます。
51485422
51495423 @itemize
51505424 @cindex @code{mpfr_const_pi} mpfr extension function
@@ -5155,36 +5429,39 @@ nullary 関数は、引数を取りません (@emph{null}) が、役立つ数値
51555429 @item mpfr_const_log2()
51565430 @end itemize
51575431
5158-次の例は、nullary 関数の使い方を示すだけでなく、算術オペレータのどのような実装にも付いて回る制限についてもはっきり示します。
5159-有名な定数の Pi を 2 進数で 1000 桁になるまで表示するのが簡単なことに、あなたは驚かないでしょう。
5432+次の例は、nullary関数の使い方を示すだけでなく、算術オペレータのどのような実装にも付いて回る制限についてもはっきり示します。
5433+よく知られる定数Piを、2進数で1000桁になるまで表示するのが簡単なことは驚くことではありません。
5434+
51605435 @example
51615436 gawk -l mpfr 'BEGIN @{MPFR_PRECISION=1000; print "pi = " mpfr_const_pi() @}'
51625437 pi = 3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127360
51635438 @end example
51645439
5165-この例を、2 進数で 100 万桁になるまで Pi を表示するように簡単に変更できるでしょう (この計算に数秒余計にかかるだけでしょう)。
5166-しかし、たった 4 ビットの精度での動作についてはどうでしょう。
5440+この例を、2進数で100万桁になるまでPiを表示するように変更するのは簡単です(この計算に数秒余計にかかるだけです)。
5441+しかし、たった4ビットの精度での動作についてはどうでしょう。
5442+
51675443 @example
51685444 gawk -l mpfr 'BEGIN @{MPFR_PRECISION=4; print "pi = " mpfr_const_pi() @}'
51695445 pi = 3.25
51705446 @end example
51715447
5172-結果の @code{3.25} というのが間違いなのはわかっていますが、その間違いは本当なのでしょうか。
5173-Pi の@emph{正しい}値というのは実際何@emph{である}のでしょうか。
5448+結果の@code{3.25}というのが間違いなのは分かっていますが、その間違いは本当なのでしょうか。
5449+Piの@emph{正しい}値というのは実際何@emph{である}のでしょうか。
51745450 前の例にある値でしょうか。
51755451 いいえ、それらの中に本当に@emph{正確な}ものはありません。
5176-他の多くの数値のように、Pi は無限に多い桁数を持っています。
5177-そのような数値の浮動小数点の数値はすべて近似値としてだけ表現できます (仮数部が 4 ビットだけで、最近接値に丸めた場合 3.25)。
5178-浮動小数点数でのいずれかの計算が、@emph{正確な}結果を返すならば、あなたは単に運が良かったのです。
5179-@emph{正確な}結果というのは例外で、一般的ではありません。
5452+他の多くの数値のように、Piは無限の桁数を持っています。
5453+そのような数値の浮動小数点の数値は、近似値としてだけ全て表現できます(仮数部が4ビットだけで最近接値に丸めた場合、3.25)。
5454+浮動小数点数でのいずれかの計算が@emph{正確な}結果を返すならば、単に運が良かったのです。
5455+@emph{正確な}結果というのは例外であって、普通のことではありません。
5456+
51805457
51815458 @node Unary Functions
5182-@appendixsec Unary 関数
5459+@appendixsec Unary関数
51835460
5184-unary 関数は、引数を一つ取って、便利な数値をいくつか返します。
5185-これらの関数は、特定の関数の、与えられた環境 (選択された精度、基数、丸め) の下で可能な限り最良の近似値を提供するものです。
5186-以下のリストの関数名が、何を意味しているのかを説明しているはずです。
5187-疑問がある場合は、@uref{http://www.mpfr.org/mpfr-current/mpfr.html, MPFR library} のドキュメンテーションを参照してください。
5461+unary関数は、引数を一つ取って、便利な数値をいくつか返します。
5462+これらの関数は、特定の関数の、与えられた環境(選択された精度、基数、丸め)の下で可能な限り最良の近似値を提供するものです。
5463+以下のリストの関数名が、何をするものなのかを説明しています。
5464+疑問がある場合は、@uref{http://www.mpfr.org/mpfr-current/mpfr.html, MPFR library}のドキュメントを参照してください。
51885465
51895466 @itemize
51905467 @cindex @code{mpfr_sqr} mpfr extension function
@@ -5246,14 +5523,16 @@ Only available since version 2.2 of MPFR.
52465523 @item mpfr_frac(op)
52475524 @end itemize
52485525
5526+
52495527 @node Binary Functions
5250-@appendixsec Binary 関数
5251-bina

差分はサイズ制限により省略されました。全ての差分を見るためにはローカルクライアントを利用してください。