So-net無料ブログ作成
検索選択

古典テキスト入力のためのXMLツール [XML]

古典テキスト、と言えば、僕の場合チベット語のテキストだが、これの校訂テキストを作成するのに便利なツールを作るにはどうしたらいいか、ということを随分前に書いた。その後、他の先生と話をして、希望などを聞いてみたところ、少し方針を変更するにした。まだ、具体的にどう作るかの見通しはないので、ここで少し考えてみたい。

 最終的なツールの見え方としては、HTMLによるWebページにする。処理のためには、PHPとXML、XSLTを使用する。データはXMLで保存しておく。XSLTで処理できる部分はXSLTで処理し、それではできないところはPHPを使用する、という組み合わせで作る。この点は以前と変わらない。

 問題は、XMLのデータ構造である。これは前にも色々と揺れていた。今度、他の先生と話をして、大きく方針を変えた。前は、校注を本文テキストの中にタグを付けて、混在させていて、表示するときだけ、見やすく分離することを考えていた。しかし、これでは、見せるにはいいが、編集支援という部分が弱くなる。少なくとも、画面表示では、テキスト本文と注記の部分は、フィールド分けて表示をした方がいいということになった。

 それでは、データ、すなわちXMLをどのような形式にしておいたらいいだろうか。

 以前とは異なり、オリジナルのテキスト一ページごとに、データも一つのファイルにするか、あるいは少なくとも、XMLの一つの単位を一ページに設定し、その中に注記も含めておくようにする。ただし、テキスト本文に入れるのではなく、本文の後ろに付けるようにする。あるいは、本文の中に入れる形式と、本文の後に付ける形式は、XSLTで変換できるようにする。

<p no="123a">
 abcd efgh ijkl mnt opq rstu vwx yz / 
 zyxw vuts rqpo tnm lkjiP: lkji, D:LKJI. hgfe cdba / 
 mntP: mnt; D: mno. rtst efht vwxy ijkl abcd opq / 
</p>

これをXHTMLに変換する。ページ番号などのデータはXHTMLの要素ではなく、直接テキストに書き込む。

<div class="p">
[123a1] abcd efgh ijkl mnt opq rstu vwx yz /
[123a2] zyxw vuts rqpo tnm lkji [*1] hgfe cdba /
[123a3]  mnt[*2] rtst efht vwxy ijkl abcd opq /
</div>

<div class="nt">
<ol>
<li> P: lkji, D:LKJI.</li>
<li>P: mnt; D: mno.</li>
</ol>
</div>

XMLからXHTMLへの変換はXSLTを使えば可能なように思う。しかし、その逆はPHPなどのスクリプトの席表現を使わなければならないだろう。正規表現を使えば十分可能な範囲だと思う。

 本当はもう少しよく考えて、より簡潔な表記を可能にできるかもしれない。それはまた後日考え直すことにしよう。


TeX2HTMLよりはXML [XML]

昨年度の卒論で、LaTeXのソースをHTML文書に変換するツールをPythonで作る、というテーマのものがあった。その開発には、基本方針というか、基本的なアルゴリズムを僕が提供し、学生がそれを個々のコマンドや環境に適応して実装したものだった。実際には、様々な制約をつけ、しかもマクロなどを定義していないデフォルトのpLaTeXでの処理が前提だった。それでもテーブルなどは、必ずしも実用的なものとは行かなかった。

 コンセプトとしては、できるだけシンプルなHTMLに変換し、またCSSを十分に使って、標準のHTMLでは表現できないものは、CSSのクラス名を挿入するというものだ。もちろん、CSSファイルは別に用意したが、ユーザーはこれを自由に書き換えたり、書き足したりして、簡単に変換のカスタマイズをできるようにした。

 今年の卒論では、もう少し別のアプローチを考えた。すでに僕のブログのカテゴリーの「XML」のところで何度か書いたように、最初に文系の論文に適したXMLを定義しておき、それをXSLTでTeXとHTMLに書き直す、というものだった。類似のツールは他にもあることは知っているが、文系の論文・レポートにターゲットを絞り、使いやすい、あるいは覚えやすいルールのものを作りたかった。既存のものは複雑だし、インストールも大変だし、使いづらかったからである。

 まず最初にやってもらったことは、TeXのコマンドに対応するようなXMLの要素を考え、それをXSLTでTeXのソースに変換するものだった。これが意外と簡単にできた。完全というわけではないし、まだまだ検証は必要だし、そもそもXML自身がTeXのコマンドにほぼ一対一で対応しているので、簡単に変換できるのは当たり前だが、それにしても、若干の試行錯誤で原理的にはうまくいった。

 同じXMLをXHTMLに変換するXSLTを書くことも、そんなに難しくないように思われる。大体、普通使われるコマンドは、ほとんどそのままHTMLに書き換えられる。

 どうして、TeXからHTMLに変換すると、うまく行かない、ないしは非常に難しいのに、XMLからTeXやHTMLに変換すると、それほど複雑にならないのだろうか。XSLTが、XMLの変換に適していて、それをPythonなりPerlなりのスクリプトで書くより簡単に変換できるからなのだろうか。

 ただし、現在のものは単なる試作品にすぎない。そもそものXMLの設計は、もっとよく考え、出来る限り多様な論文形態に対応できるようにしなければならないし、その定義もDTDで書くようにしなければならない。また、卒論としては、今疑問に思った点、つまり、どうしてスクリプトで変換するよりも簡単にできるのかについての考察も必要だろう。しかし、このXMLおよびXSLTという単純な規則が、非常に柔軟で効果の大きいものであることを再確認できたように思う。

 完成が楽しみだ。


データは一つのXMLに [XML]

 古典テキストのXML化の続きを考える。

 長いテキストの場合、HTMLを複数ページに分割して表示する必要がある。長いテキストと言っても、どうだろう、タグなどを除く純粋なテキストデータだけで、500Kとかが限界のような気がする。テキスト自体はもっと長いものもあるが、それは初めから分割してデータ化しておいた方がいい。とはいえ、そのサイズを一ページで表示するのは、実用的ではない。

 そこで、分割して表示することにするのだが、どこで分割したらいいのだろうか。前に<page>要素を一つの単位に分割するということを考えたが、そのようなpage要素は、表示するときのページ分割のためのものであり、構造とデザインを分離するという原則に反した、デザインに引きずられた要素だろう。そこで、この案は却下。

 それでは、見出し毎に切るというのはどうだろうか。これはUnix系のマニュアルでinfoファイルからHTML化したようなものにしばしば見られる。あれは見出しごとに一ページずつになっていることが多く、したがって、ページによっては非常に短いところも出てくる。また個々のページが小さいので、膨大な数のファイルが生成される。これはその後からファイルを手作業で修正しようとしてもできない位のものである。従って、規則的に処理できるようにデータを作っておかなければならない。

 また、見出しからは自動的に目次が作られ、リンクも貼られる。

 問題は、この大量のHTMLの生成が、データの修正がある毎に全部作り直すとすると、かなりの手間がかかるということだ。XMLのデータは個々に分かれる前の全体を含むもので、編集はその一部、多分、段落毎(もっと正確にはブロック要素毎)に編集をし、更新をするときは、その編集したブロックを、全体のXMLに書き戻す必要がある。そのとき同時にHTML化もしてしまうとすると、かなりのオーバーヘッドになる。

 そこで、データの修正は親のXMLデータを更新するとして、HTML化の方は、修正したブロックのみでよく、そのブロックを含むHTMLテキストのみを更新すればよい。それ以外のHTMLファイルの方は、そのまま手を着けずに置いておく。


XSLTとCGIの使い分け [XML]

古典テキストをオンラインで編集するためのシステムを考え中。

 最初、できるだけXSLTで処理しようと思っていたが、実際に考え出すと、ユーザーへの様々な便宜を提供するためには、CGIなりPHPなりで処理を書いた方が楽だと思うようになった。要するに、XMLのデータをXHTMLとして表示する部分のみをXSLTに受け持たせ、それ以外のシステム全体のロジックはCGIまたはPHPで構築した方がよさそうだ。

 たとえば、ユーザーが、テキストのある部分(それをどのような単位で提供するかは、また後で考えることにする。)を編集したいと思ったとき、そのテキスト部分の直ぐ上に[編集]というリンクを作っておき、そこをクリックしたら、別のウィンドウに、そのテキスト部分のXMLのソースが、編集できるような形で表示されるようにする。ちょうど、このブログで、今読んでいる記事を編集しようとする場合、タイトルの横に現れている[編集]というリンクをクリックすると、編集用のフォームが開き、その記事がテキスト・エリアに読み込まれているようなものだ。

 これを実現するには、その[編集]というリンクがCGIを呼び出すリンクになっていて、テキストのその部分を特定するアドレスを含んでいるようにする。そして、それを手縢りにCGIまたはPHPが、元のXMLのデータからその部分のみを取り出して、別ウィンドウに表示する。その編集が終わったら、フォームの送信ボタンで、ふたたびCGIまはたPHPを呼び出し、編集済みデータを渡す。CGIスクリプトは、そのデータで元のXMLのデータの対応部分を更新する。その後、元のXMLの表示を再読込して更新する。

 XSLTによるXMLのXHTMLへの変換は、表示するときにではなく、予めXMLのデータが更新されたときにXHTMLを生成してしまうようにすれば、パフォーマンスが改善するので、部分テキストの更新の場合も、XMLのデータの更新の直後にそれをXSLTでXHTMLへと変換してしまっておく。変換そのものは、だから、CGIスクリプトあるいはPHPスクリプトから変換コマンドを呼び出して行うようにする。場合によっては、複数のXSLTを用いて、複数のタイプのXHTMLを生成することも考えられる。

 XSLTはXMLをXHTMLへ変換すめためのもので、その表示デザインそのものはCSSを用いる。つまり、XSLTはXMLをXHTMLに変換するとき、CSSでXHTMLを表示するように変換する。だから、同時にCSSも設計して用意しておく必要がある。

 こうなると、一番神経を使い、細かい管理をしなければいけないのは、XSLTの部分ではなく、CGIスクリプトあるいはPHPスクリプトの部分だということが分かる。

 次は、このあたりの具体的な仕組みを考えことになる。


古典テキストのXML化─ブロック要素とインライン要素 [XML]

まずは、古典のテキストをどのようにXML化するかを考えてみる。

 昨日の記事では、HTMLを複数ページに分けるために<page>タグを入れると書いたが、これは、表示に関する単位をデータの中に入れることになるので、却下。別のやり方を考えなければならない。

 とりあえず、要素はブロック要素とインライン要素に分けられる。と言っても、HTMLと違い、ブロック要素とインライン要素の区別は、厳密なものではない。DTDでもその違いは表現できない(と思う)。従って、ブロック要素の下にブロック要素が来てもいい。

 注記やページ番号などはインライン要素だ。段落内改行もインライン要素だ。他にも何かあるかもしれないが、それは後で思いついた時に追加することにする。

 それに対してブロック要素として、今思いつくのは、見出しや段落、引用、詩の四つだ。これも他に何か思いついたら、追加する。

 このうち、段落は例えば<para>、たるいは一番頻繁に使うことを考えて、簡潔に<p>タグでよいだろう。引用はTeXでは二種類用意しているが、HTMLでは一種類なので、ここでも取り敢えず<quote>要素のみにする。詩は、古典的テキストに頻繁に用いられる。表示は引用と同じようにすることもできるが、引用と作者自身が書いた詩では、意味が異なっているので別の要素にする。タグは<verse>でいいだろう。

 それでは、引用の中に詩があったらどうするか。これは、引用要素の子要素として詩要素を書けることにすればよい。一方、段落要素の下位に詩要素は書けない。段落を終了してから詩を書き、詩を終了してから、段落を再開すればよい。

 見出しもブロック要素だが、これには何段階かの階層を考える。HTMLでは<h>要素は6段階だが、これでは管理が大変になる。せいぜい3階層か4階層くらいが妥当だ。そこで、<chap>、<sec>、<subsec>、<subsubsec>に分け、<chap>は無くてもいいことにする(という規則が可能かどうかは分からないが)。

 この見出しは、それぞれ下位のものを包含し、さらに最終的な見出しが段落要素や詩要素、引用要素を包含することになる。これらの見出しは同時に目次を作ることになる。

 編集作業は、このうちの見出し部、あるいは段落、詩、引用要素単位で行う。この、編集をどうするか、という処理についてはまた後日考えることにする。


オンラインで校訂テキストを編集する [XML]

 複数の人が、共同で古典のテキストを校訂したり、編集したり、注記を付けたり、といった作業をできるようにするためのツールを考える。古典のテキストだけではなく、その和訳も同じように処理できるだろう。中身は異なっても形式的には同じだと思われるので、とりあえず、テキストの方だけを考えることにする。

 もちろん、それを実現するにはいろいろなやり方が考えられる。しかし、たとえば、編集をするためのエディタまで作っていたのでは、大変だ。ということで、ここでは、XMLの勉強も兼ねて、XMLおよびXSLTとXHTMLや、せいぜいJavascriptやPHPを使う程度で実現できることを考えよう。

 まず、見通しとして二つの方向を考えておきたい。一つは、テキストに注記やページ番号などを挿入する仕方である。

 注記は、単純な注であるのか、それとも校注であるのかは、今は区別する必要はない。要は、本文のある箇所に注記の記号が表示され、注記自体は別のところに表示される。あるいはそれはリンク先に別ウィンドウで表記してもかまわない。だから、本文には注本文に対するリンクのみを挿入しておく。

 ページ番号は、直接本文に表示されていて構わない。XMLとしては、空要素、つまり<location src="ABC" page="34" line="4" />というような感じで、底本にしている本の略号、ページ番号、必要とあれば行番号を属性にする。たいてい、複数の底本を校合するので、srcで、それぞれの底本を区別する。これは、本文を表示するときに、より簡潔な仕方で表示するようにしてもいいし、場合によっては、一つの底本のみを表示したり、全てを非表示にも切り替えられるようにする。

 二つの方向のうちのもう一つは、更新履歴を残すようにすることである。僕はMS Wordは嫌いだし、あのような不便なものを研究者がメインに使うなどというのは、全く信じがたいことと思っているが、しかし、複数の人が編集した作業履歴が残されており、表示、非表示が切り替えられたり、編集以前のものに戻せたりする、というアイデアだけは、研究作業でも、それなりに意味のあることと思う。

 MS Wordのやり方が分かりやすいかどうかは疑問の余地があるが、何かそれをもっとシンプルにし、どうしても必要な履歴のみを残していけるような方法を考えられたらいいと思う。現在のところ、これといった方策が思い浮かぶわけではないので、これは今後また考えを詰めていく必要がある。

 テキストは全体を一つのWebページに表示するのではなく、いくつかのページに分けて表示できた方がいい。さらに見出しを中に挿入できて、その見出しで目次のページができ、またその見出しのあるレヴェルのところでページが分かれるようにできればいいと思う。

 そのページの分かれ目を自動的に処理するよりは、最初から入力する人がページの切れ目を指定しておいた方がいい。それために、大まかにXMLのツリー構造を書くと


 
  
abcde .... xyz 1234 ... 7890
.....
....

といった感じになるだろう。DTDはまた、別の機会に書いてみることにしたい。

 この<page>タグで、Webのページが区切られるようにする。またそれは編集の単位でもあるし、注記は、原則的にそのページの最後に表示されるようにすればよい。

 まだ、具体的には今日考え始めたことなので、できるかどうか、使いやすいかどうかは、分からない。雲を掴むような状態から、少しずつ、方向性を固めていく段階にあるのだ。

 


文系のレポート・論文を書くためのXML [XML]

 以前「XMLで文系論文作成を支援する。」で簡単に書いたことの続き。

 昨年度の卒論で、TeXで書いた文系のレポートや論文を、HTMLに変換するツールを作成した学生が二人いた。標準のTeXを使っている限りにおいては、それはよく機能した。ただ、パッケージを読み込んだり、独自のマクロを定義したりしたら、対応できなかった。

 そこで、少し戦略を変えて、ソースを生のLaTeXで用意するのではなく、文系の論文・レポート用に必要にして十分な構造を備えたXMLを設計し、そこからXSLTを使ってpLaTeXのソースとHTMLとに変換するようにしたらいいのではないかと考えた。

 最初から、論文・レポートを書くための構造を定義しておけば、それに対応した変換のみをサポートすればいいので、例外的なことやユーザーの様々な環境や意図を考える必要がないのだ。しかし、もちろん、そのXMLの設計は、通常の要求には必要にして十分なだけの要素を提供しておかなければならない。この設計こそが、このプロジェクトの成否の大部分を決定する。あるいはこのプロジェクトの本質は、変換のためのプログラムをすることではなく、このXMLの設計にある。

 ではどのような手順で考えたらいいだろうか。

 これは二つの方面から同時に詰めていかなければならない。

  1. pLaTeXとXHTML+CSSで、対応するデザイン・構造要素をリストアップする。基本的には両者に対応するものがあるものが第一候補だが、一方にしかなくても、他方でおかしくない程度の書き換えができるのであれば、それもリストアップする。これは第二候補である。
  2. 文系の論文やレポートの構造で必要なものは何か、を調べる。たとえば、章分けとか、箇条書きとか、注とか、もちろん、相互参照や文献表、目次、柱、引用、など。この段階では、デザインではなく、意味的な構造を抽出するようにする。

 昨年度も同じようなステップを踏んだが、徹底したものではなかった。特に第二の点は、既存の印刷された論文を見ていては、よく分からない。実際にTeXなどで書かれだ論文・レポートを見る必要があるが、余りたくさん種類がない。したがって、ここでは、取り敢えず1の方から始め、取り敢えず動くものを設計し、そこでそれを使って、具体的な論文やレポートを作成して拡張の可能性を探る、という手順で進めるのがいいだろう。

 現段階で感じをつかむために、LaTeXで書かれた文書をXMLで書き直すようなことをしてみた。ちょっとやっただけでも、様々な設計の可能性があることが分かる。特に要素にするのか属性にするのか、という点は大きい。そういう具体例・試作品をいくつも作って、そこからXMLの設計を抽象していくようにすればいい。

 昨年度の卒論は、Web上で参照できるので、それを出発点にするのは、「卒論の継承」の項で書いた。

 XMLによるドキュメント作成については、既にDocBook、SmartDocなどがあるので、特に後者の機能も参考にしなければならない。


校訂テキストを作るためのXML [XML]

 文献研究を支援するために、単純なテキスト入力ではなく、校訂テキストを作成することを支援するようなツールがあると便利だ。

 最低限必要となるのは、本文と校注と行ページ番号と章節番号や見出しなどの校訂者が入力するテキスト部分の区別、そしてテキスト全体としては、文献の書誌情報、凡例、などの区別である。

 これらをそれぞれXMLの要素にする。表示はブラウザーを使用するが、単に表示だけではなく、入力もできるようにする。そのためには、テキスト全体を一ページに表示することはできないので、ある程度分割して表示することになる。そのためにも、章・節の区切りは必要であり、あるいは、場合によっては段落なども必要かも知れない。

 表示はXSLTとCSSを使って見やすくすると同時に、生のXMLでも表示が可能なようにする。入力は生のXMLとして書くようにする。そのため、XML自体も、出来る限り単純化して、文系でも容易に入力できるように工夫する。

 表示するときに、特に校注などを別の部分、たとえば、段落の後に注記の形で表示するようにする。これはXSLTを使えば簡単にできそうである。

 一方、テキスト自体は、全体を一つのテキストとして保存しておくようにする。表示するときには、それを動的に複数ページに分割して表示する。一方、編集したあとは、再び、複数ページを一つのテキストに合成して保存する。このように動的にページ分割とページ合成を行うために、テキストを分割する単位を決める必要がある。基本的には、章・節の区切りを切り分ける境界線と考える。したがって、章・節の要素は必須であり、そかも書き方も一定の規則に従ったものにする。

 検索機能も必要である。このためには、XMLで書かれたテキストを読み込んで、本文テキスト部分のみを検索対象にする必要がある。これらの処理はPerlかPHPのXML処理機能を使用して実現する。

 具体的には、まだ何も作られてはいないが、一応現在考えられる問題点や作り方の見通しは、以上のようなものである。


XMLで文系論文作成を支援する。 [XML]

 今年度の四年生の卒論では、文系用の論文やレポート作成を支援するためのTeXのスタイルファイルを作る、というテーマを選んだ学生が2人いた。

 また、これも文系のTeXのソースをHTMLに変換するPythonスクリプトを作った学生も2名いた。

 今年度は上の二つの機能を含んだような、文系論文専用のXMLを開発し、それをXSLTでもってブラウザー表示ができたり、pLaTeX2eのソースに変換できるようにすることをテーマに卒論を書いてもらおうと思う。

 ところで、そのような仕組みには既にSmartDocがあり、さらに大きな仕組みとしてはDocBookがある。しかし、これらは技術文書をメインターゲットにしており、また多数の要素を含んでおり、普通の文系ユーザーが自分の論文などで利用できるものではない。それらを動かすためにも、かなりの知識と労力を必要とする。

 文系の論文に必要な要素のみに対応し、しかも容易に覚えられ、書くときにも分かりやすい表記になるように工夫し、エラーなくHTMLやTeXのソースに変換できるものを目指して欲しい。


この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。