４．開発内容
ここでは、プロジェクト遂行の過程で行ったことを、行った順を追って説明します。
本 文を読んでいると、時々、読み方の分からないものが出てきます。また、渋谷教授は本文をローマ字で書き直したローマ字版も提供されているのですが、その
ローマ字版を覘いててみると、意外な読み方をしているものに気づくことがあります。しかし、ローマ字というのは日本人には読みにくいもの。なかなか、ロー マ字版をチェックしてみようという気にはなりません。
そこで、このローマ字版をひらがな版に変換し、これと本文をつき合わせてルビを抽出しようというのがこの課題です。すでに、昨年のプロジェクトの中で、XML形式のひらがな版のファイルは作成済みなので、これと本文をつき合わせてルビを抽出するための適切な比較処理を作成することが、この課題のポイントでした。
比較処理は、行単位ではなく、文字単位になるため、diffコマンドなどの既存の比較ツールを利用できません。一般的な比較アルゴリズムは調べて参考にさせていただいたものの、最後は試行錯誤によって比較精度を向上させることになりました。
今回の比較対象は、源氏物語全５４帖に限定されているため、個別に誤比較事例を蓄積して、その事例に該当するところは、強制的に正しい判定に倒すような処理も入れました。この結果、大きな比較誤りはなくなりました。計ったわけではありませんが、比較結果の正答率は既に99%を大きく超えているものと思います。
しかし、まだ、「殿の内」とすべきところを「殿の内」としてしまう類の誤比較は少なからず残っています。このため、比較結果正答率99.9%には、まだ届いていないものと考えています。
このような誤比較は、プログラムロジックでは対応困難であり、誤比較事例を蓄積して対応すべきところと考えます。しかし、それを抽出するには全54帖全体にわたっての精査が必要で工数がかかること、プログラムとしては誤比較事例を蓄積する機能は実装済みであることから、このような事例だけを抽出するための精査は未踏プロジェクトにはなじまないと考え、本プロジェクト終了後に実施する予定です。
以上のようにして作成したルビデータのサンプルは以下のとおりです。
<?xml
version="1.0" encoding="Shift_JIS"?>
<コメント name="本文のルビ" for="本文">
<帖 no="01" name="桐壺">
<章 no="1" name="第一章 光る源氏前史の物語">
<段 no="1" name="第一段 父帝と母桐壺更衣の物語">
<ルビ no="1" keyword="御時">おほんとき<開始 行="1" 桁="4"/><終了 行="1"
桁="6"/></ルビ>
<ルビ no="2" keyword="女御">にょうご<開始 行="1" 桁="9"/><終了 行="1"
桁="11"/></ルビ>
<ルビ no="3" keyword="更衣">かうい<開始 行="1" 桁="12"/><終了 行="1"
桁="14"/></ルビ>
<ルビ no="4" keyword="際">きは<開始 行="1" 桁="38"/><終了 行="1"
桁="39"/></ルビ>
<ルビ no="5" keyword="時">とき<開始 行="1" 桁="50"/><終了 行="1"
桁="51"/></ルビ>
（以下略）
また、このルビデータを使用した再編集結果の一例を以下に示します。
源氏物語の愛好家たちにとって、縦書きには根強いニーズがあります。横書きで書かれた源氏物語関係のWebサイトは多数ありますが、Webブラウザが縦書きをサポートしてくれないため、やむを得ず横書きを使っているだけです。
昨年のプロジェクトではXML/XSLTを使った動的再編集を実現したので、これをうまく使って、縦書きをサポートしたＸＭＬスタイルシートを追加し、必要に応じて切り替えて使用することでサポートできると考え、今年のテーマの1つにしました。
今回は、以下の2つの縦書き用スタイルシートを追加しました。
● Internet Explorer上で縦書き表示するためのＸＭＬスタイルシート。IE5以降限定。印刷はうまくいかない。
● Word 2003以降で印刷するための縦書き文書を生成するＸＭＬスタイルシート。文字は90度左回転して表示される。
（１）Internet Explorer上で縦書き表示
Internet Explorerでは、5.5から縦書きをサポートしています。この機能を使って、以下のような縦書き表示ができるようにしました。
この機能の開発では、Internet Explorerのバグの回避に結構悩まされました。縦書きの印刷には大きなバグがあって使い物にならないことが最初から分かっていたため、印刷用に別途、Word 2003による縦書き印刷用文書作成機能を作ることにしていましたが、他にも以下のような問題がありました。
● ルビを表示すると、行の並びが乱れて読みにくくなる問題。回避策を色々試みてみましたが結局回避できなかったため、この機能では、ルビを非サポートにしました。本件、IE7のBetaテスト結果として縦書き印刷の問題とともに報告済みです。
● 段組の高さを自動設定できず、％指定で相対的に指定することもできません。結局、段組の高さはポイント数で絶対値を指定することにしました。省略すると、180ポイントを仮定します。上の例は、本文、渋谷栄一訳、与謝野晶子訳を各140pt、注釈等の記述を300ptに設定したものです。
（２）Word 2003による縦書き印刷用文書作成
この機能は、Internet
Explorerの縦書き印刷のバグの回避策として始めたものですが、実際に作ってみると結構使い勝手の良いものになったように思います。以下のような文書が作成されます。
ただし、現在、以下の問題が未解決のまま残っています。これらの問題は今回のプロジェクト期間中には解決することができませんでしたが、プロジェクト終了後でも、できるだけ早い時期に解決したいと考えています。
●
文書に挿絵を挿入する機能が未実装です。
昨年のプロジェクトでは、挿絵だけでなく、動画や音声などのマルチメディアオブジェクトもHTMLで表現できるオブジェクトであれば文書中に挿
入できるようにするために、任意のHTMLタグをCDATA文字列としてXMLの中に持つ方法で実現しました。しかし、WordのXML形式文書の中ではHTMLは
使えないので、このデータは、そのままでは使えません。
もっとも、このWordの文書は印刷用なので、動画や音声などのマルチメディアオブジェクトは不要です。昨年のプロジェクトで作成した「ユネスコによる絵入源氏物語の挿絵と解説」のような静的なオブジェクトは、あれば便利ですが、HTMLに依存するため、Wordでは実現困難と考え、これも割愛できます。しかし、挿絵だけは必要だと考えています。Wordにも対応する機能があるので、XML内での挿絵の情報をCDATA文字列ではなく通常のXML要素で表現すれば、実現可能です。
そこで、現在、挿絵をオブジェクトから独立させ、Wordでは挿絵だけをサポートすることを考えています。
●
与謝野晶子訳の中に外字データがあると処理できない問題は未対策です。（全230ファイル中8ファイルに存在）
この外字データは<IMG>タグで表現されており、それが非XMLタグとして与謝野晶子訳のテキスト中に埋め込まれています。これを、そのままテキストとして処理しようとするために問題が生じます。
もともと、与謝野晶子訳には、ルビも<RUBY>タグで表現されてテキスト中に埋め込まれていました。これを昨年のプロジェクトでは、<RUBY>タグ部分を「与謝野晶子訳のルビ」として独立させ、テキストから<RUBY>タグを除外しました。
そこで、今回も、この外字データの<IMG>タグ部分を「与謝野晶子訳の外字」として独立させ、テキストから<IMG>タグを除外することを考えていま
す。こうすれば、XMLスタイルシートの中で外字を認識してWord文書にあわせた処理ができるので、本機能でも外字を使用できるようになります。
●
外字にルビが振られていると処理できない問題（Wordの仕様）の回避は未実施です。
この問題は、上の問題の解決後に控えている問題ですが、すでに実験によって、このような問題が生じることが分かっています。
対策は、「与謝野晶子訳のルビ」から外字のルビを取り除き、「与謝野晶子訳の外字」に外字のルビを追加した上で、本機能では外字のルビを無視することを考えています。
●
1つのセルのデータが、1ページに収まりきらない場合、あふれた部分は表示されません。これはWordの仕様で、セルの幅を広げる、フォントサイズを小さくする、ページサイズを大きくする、行間を詰めるなどの対策で、なんとか1ページに押し込める必要があります。しかし、中には、1行が1000字を超えるものもあり、このような方法だけで対処するのは難しいものも少なくありません。
そこで、長すぎる行を2行以上に分割して短くしたデータを作り、私の名前で公開することを考えています。
 昨年、実現した再編集仕様の設定ページは左図のようなものでした。
このうち、特に「リンクするコメント」で指定できる内容には不満がありました。上部に「リンク 太字 斜体 下線 文字色 背景色 強調 拡大 ルビ」という見出しがありましたが、これは、それぞれ、HTMLの<A>、<B>、<I>、<U>、<FONT>、<SPAN>、<EM>、<BIN>、<RUBY>の各タグに対応するものでした。そして、そこには以下のような制限があったためです。
①
コメントとタグは１：ｎ対応である。つまり、出典を太字にしたら、注釈や校訂を太字にはできない。
②
文字色は赤に、背景色は黄色に固定されている。
③
フォントサイズも<BIG>タグで多少拡大できる以外は固定されている。
このうち、①の制限には技術的な背景がありました。注釈、出典、校訂には互いに入れ子関係が無いため、その範囲を正確に表現するには、互いに異なったタグを割り当てる必要があるという点です。これが、コメントとタグは１：ｎ対応という制限になりました。
しかし、この場合でも、タグとスタイルの関係には言及していません。CSSをうまく使えば、タグとスタイルの関係は変更できます。たとえば、注釈、出典、校訂の三者をともに太字にしたいが、斜体にしたいものは無いという場合、<I>タグと<EM>タグを<I style=”font-style:normal; font-weight:bold;”>のようにすれば、このタグを<B>タグの代わりに使うことができ、①の制限は事実上乗り越えることができます。そして、このようにCSSを使うのであれば、②③の制限も解消できます。
このような考え方で、上記の不満を解消した以下のような画面を作りました。（「リンクするコメント」だけ抜粋）
このページは最終版ではなく上の考えを検証するために作ったものなので、不要な列があったり、ルビの指定方法が変だったりしますが、そこは無視してください。ポイントは注釈、出典、校訂の三者をともに太字にしたことと、互いに異なる色を割り当てたことです。CSSを使っているので、フォント名や行ピッチなどを指定可能にすることもできます。反面、ルビはコメントとして統一して処理するには無理があることも見えてきました。
補足 このページの変更は、前述の「４．２ 縦書きのサポート」の開発作業中に並行して開発していました。Word 2003による縦書き印刷用文書を作成するとき、色やフォント属性はHTMLとは異なった発想で実現する必要があり、その実現方法の検討と合わせて画面での指定方法も検討したためです。縦書き印刷用Word文書作成処理のために、色やフォント属性を指定する画面を上のような画面にするのは自然な発想なのですが、この画面はInternet Explorerで縦書き表示や横書き表示する場合も共通にしたいという思いがあり、そのために考えたのが、上で述べた、CSSでタグとスタイルの関係を変更してしまう方式でした。
（１） データ管理の枠組み
以上の開発を終えた状態で、開発は大きな区切りを迎えました。私は、この状態をＶ２．５と呼んでいます。というのも、ここまでは、以下のような点で、いわばＶ２（昨年のプロジェクト）の延長だったからです。
●
「ル ビの追加」は、もともと、Ｖ２の目標「第三者による注釈・解説の類を追加できる」の最初の適用例にしようと考えていたものでした。しかし、その奥が深く、
結局、Ｖ２ではひらがな版を作成するところまでにとどまりました。なお、ひらがな版はＶ２の目標「第三者による新たな現代語訳などのテキストを追加でき、 自動的に対象表示されるようになる」の最初の適用例になりました。
●
「縦書きのサポート」も、Ｖ２の開発途上から、すでに、Word
2003のXML形式を使えば、スタイルシートを替えるだけで実現できるのではないかという考えを持っていましたし、多少の実験を行って、実現方法を検討したりしていました。
この後の最初の課題は会員の登録・認証・管理機能とアップロード機能の追加です。しかし、その課題に着手する前に判断しなければならないことが１つありました。
こ れらの機能では、会員情報や、アップロードするコンテンツの情報などのデータを管理する必要がありますが、そのデータ管理の枠組みとして、既存の枠組みを
使い続けるか、新しい枠組みに乗り換えるかです。乗り換える場合には、プログラム構造は大きく変わり、かなりの部分を作り直す必要が生じるなど、もはや、 Ｖ２の延長とはいえない状況になります。
この２つの枠組みを比較すると、下表のようになります。
|
項目
|
既存の枠組み
|
新しい枠組み
|
|
プロバイダ
|
ぶっとびねっと
|
さくらインターネット
|
|
データ管理方法
|
テキストファイル 【×】
|
MySQLデータベース 【○】
|
|
独自ドメイン
|
使用不可 【×】
|
使用可 【○】
|
|
費用
|
無償 【○】
|
有償 【×】
\5000/年＋\1800/年（独自ドメイン）
|
|
セキュリティ
|
低 【×】
全ファイルをインターネットに公開する。
会員情報等もテキストファイルなので、.htaccessで保護したとしても、URLが分かり、パスワードが破られればアクセスできてしまう。
|
高 【○】
htdocsサブフォルダ配下のみをインターネットに公開。
（非公開ファイルを自由に作れる。）
|
|
今後の開発（新機能分）
|
作りにくい 【×】
（データの処理を、文字列処理と正規表現を駆使して実現要）
|
作りやすい 【○】
（PHPがMySQLをAPIとツール(phpMyadmin)の両面でサポートしている）
|
|
今後の開発（既存機能分）
|
修正不要？ 【○】
（新機能の影響が出る可能性あり）
|
修正要 【×】
（データ管理方法変更）
|
|
結論
|
×
|
○
|
私は、この両者のどちらにするかでずいぶん迷いましたが、最終的には新しい枠組みに乗り換えることにしました。既存の枠組みの良い点は「無償」と既存機能部分は「修正不要」だけで、他は新しい枠組みの方が良いこと、「修正不要」といっても「?」付きで、新機能の影響が出ることが見込まれることを考えて、そうしました。
（２） プログラム構造への疑問
Ｖ２．５のプログラムの構造には疑問も出てきました。それは、再編集形式が増えても、再編集仕様設定ページは1種類だけなのかということでした。ここで、再編集形式とは、横書き表示、縦書き表示、縦書き印刷用Word文書、といった、動的再編集処理で出力するデータ形式のことです。
確かに、再編集仕様設定ページで指定する項目は、この３つの再編集形式の間では同じでした。将来、項目を増やしたとしても、そんなに大きく変わらないだろうという見通しもありました。
しかし、Ｖ２．５で縦書き印刷用Word文 書の再編集形式を追加したとき、再編集仕様設定ページも変更したので、横書き表示や縦書き表示の機能は動作しなくなっていました。これでよいのでしょう
か。将来、指定項目を増やしたとき、全ての再編集形式で一斉に、その項目をサポートしなければならないのでしょうか。あるいは新しい再編集形式を追加した とき、その形式の特性上重要な項目を追加したとしたらどうでしょう。あまり重要ではない他の形式でも一斉に、その項目をサポートしなければならないとした
ら、それでよいのでしょうか。
私は、この疑問に対してひとつの回答を考えていました。それは、分離・独立と部品化です。
再編集仕様設定ページで指定する項目を、共通項目と、再編集形式毎に個別に指定すべき項目とに分け、個別に指定すべき項目は再編集形式毎に専用のページを作って独立させます。そして、独立させた各ページ間で共通する部分は部品として切り出して共有します。
例えば、帖・章を選択する項目と、再編集形式を指定する項目は共通項目です。反面、再編集結果の書式を指定する項目は個別に指定すべき項目です。色やフォント属性、段組の幅、行ピッチといった属性がこれに該当します。
一 方、対象コンテンツを選択する項目はどちらなのか迷いました。例えば、左の段組には本文を表示し、中央の段組には渋谷栄一訳、右の段組には与謝野晶子訳を
表示するといった指定や、本文に注釈・出典・校訂などの情報を付加するかどうかの指定、挿絵・動画・音声などのオブジェクトを挿入するかどうかの指定など です。これらは、再編集形式によってはサポートできない項目が出てくる可能性があります。例えば、縦書き印刷用Word文書では、動画や音声などのオブジェクトの挿入には意味がありません。しかし、対象コンテンツは再編集形式によらず共通であること、サポートできないコンテンツの指定は動的再編集処理で無視すればよいことなどから、これらは共通項目と考えることにしました。
当時。現在は段組の幅や行ピッチが追加され、指定方法には微妙な違いがあります。
（３） Ｖ３に新目標追加： アップロード機能を使って新たな再編集形式を第三者が追加できること。
こ こまでは、再編集仕様設定ページだけについて触れましたが、同様な議論が動的再編集処理ページにもあります。このページはＸＭＬスタイルシートを使って実
際に動的再編集処理を実行するページです。Ｖ２．５では、このページと再編集仕様設定ページの関係は以下のようになっていました。
し たがって、先の疑問「将来、指定項目を増やしたとき、全ての再編集形式で一斉に、その項目をサポートしなければならないのでしょうか」を解消するために
は、再編集書式設定ページ（個別指定すべき書式情報などを設定するための再編集形式毎の専用ページ）と動的再編集処理ページの両方を再編集形式ごとに分 離・独立化する必要があります。（下図）
そ して、このような構成にした場合は、①再編集書式設定ページと、②動的再編集処理ページ、③ＸＭＬスタイルシートの三者一組で追加することで、新たな再編
集形式を追加できます。そこで、これをＶ３の新たな目標「アップロード機能を使って新たな再編集形式を第三者が追加できること」として追加しました。
Ｖ３では、悪意を持った第三者によるデータ改竄を防止するため必要になる最低限の会員管理機能を実現することにしました。具体的には、以下のようなポリシーに基づく会員管理機能を実現しました。
● 個人情報はメールアドレス、名前（ニックネーム可）、ユーザID、パスワード、自己紹介を管理します。このうち、メールアドレスとパスワードは非公開ですが、他は公開します。
● 金銭授受を伴わないため、本人確認は重要ではありません。しかし、無確認では悪意を持った第三者に利用された場合に有効な対策が取れないので、最低限、メールアドレスの有効性だけは確認します。すなわち、登録されたメールアドレス宛に、確認用のURLを記入したメールを送信し、所定期間内にそのURLにアクセスされたことを確認することによって、メールアドレスの有効性を確認します。
● 認証はユーザIDとパスワードで行います（基本認証）。ユーザID忘れやパスワード忘れには対応しません。
● ユーザID以外の個人情報は変更可能です。変更された場合は、登録メールアドレスに対して、その内容を報告します。
● メールアドレスが変更された場合は、再度、メールアドレスの有効性を確認します。
●
簡単な更新履歴情報として、会員登録日時と最終更新日時を管理します。トップページの再編集仕様設定メニューに複数会員のコンテンツが列挙される場合は、会員登録日時の上昇順に列挙されます。
以上のように、この機能自体はオーソドックスなもので、新規性はあまりありません。そこで、この機能のために使えそうなオープンソースソフトが無いか探してみましたが、適切なものは見つかりませんでした。
しかし、この機能は源氏物語の鑑賞支援ツールを実用化する上では重要な機能になること、新しい枠組みではMySQLデータベースが使えるので開発は比較的容易と思われること、などを考え、未踏ソフトプロジェクトの一環として、この機能を開発しました。
開発したページのサンプルを以下に示します。
４．６ アップロード機能の追加
この機能は、動的再編集処理の対象となるコンテンツをアップロードするための機能ですが、動的再編集処理との連携のためにいくつかの情報を管理するなどの関連機能を含みます。
具体的には、以下のような機能を実現しました。
● 会員ごとにフォルダを割り当て、アップロードするコンテンツの種類ごとにサブフォルダを作成します。会員は、自分のフォルダ内のサブフォルダにコンテンツをアップロードできます。
● このサブフォルダを作成・変更・削除・一覧表示するためのフォルダ管理機能を提供します。以下、単に「フォルダ」というときは、このサブフォルダを指すものとします。
● フォルダを作成・変更・削除すると、その内容は、ただちに、トップページの再編集仕様設定メニューに反映されるようにしました。
● 「コンテンツ名」と、その「概要」、および、コンテンツの表示「順序」も、このフォルダ情報として管理し、必要に応じて変更できるようにしました。
● 再編集仕様設定ページは、このフォルダ情報からコンテンツ名、提供者名、概要を抜き出して、コンテンツの種類ごとに一覧表示する方式に変更しました。この結果、どのようなコンテンツがあるのかが分かりやすい再編集仕様設定ページに変身しました。
● フォルダ内のコンテンツファイルの操作としては、アップロードと削除を提供します。削除では複数のファイルをチェックして一括削除できるようにしました。反面、リネームは無く、削除と再アップロードで対応してもらいます。
● 動 的再編集処理では、コンテンツファイル名が一定の命名規則に従って付与されている必要があります。そこで、ファイル命名規則をフォルダ情報として管理し、
必要に応じて変更できるようにするとともに、命名規則に従わないファイル名の場合はアップロード時のリネームを促すなど、命名規則に従ったファイルだけが アップロードできるような仕掛けにしました。
● 目標「アップロード機能を使って新たな再編集形式を第三者が追加できること」に対応するため、動的再編集処理も再編集形式ごとに１つのフォルダを割り当てることにしました。
新たな再編集形式を追加する場合は、このフォルダを追加して、そこに①再編集書式設定ページと、②動的再編集処理ページ、③ＸＭＬスタイルシートを三者一組でアップロードします。
これらの機能の実現後のページサンプルを以下に示します。
ページサンプル
|
概要
|
|
|
このページはログインした会員がフォルダの作成とフォルダ情報の変更を行うためのページです。そのためのボタンが、新規作成ボタンと、一括変更ボタンです。
一括変更ボタンでは、複数のフォルダ情報を一括して変更できます。内容を比較して変更の有無を認識するので、変更箇所をチェックするなどの操作は不要です。
|
|
ページサンプル
|
概要
|
|
|
このページはログインした会員がファイルのアップロードと削除を行うためのページです。
最初の表は、アップロード先のフォルダを選択するためのもので、どれかをチェックすると、次のアップロードフォームと最後のファイル一覧が現れます。
次の表はアップロードフォームです。通常は、対象ファイルを選択して
アップロードボタンを押すだけでアップロードできます。しかし、選択したファイル名がXMLファイル命名規則に一致しない場合は、その下のリストボックスから帖と章を選択すれば、命名規則通りのファイル名に変更してアップロードされます。
複数のファイルをアップロードする場合も、操作は１ファイルずつ、繰り返して行います。
最後の表は、そのフォルダのファイル一覧です。各行の左端のチェックボックスをチェックして
一括削除ボタンを押すことでファイルを削除できます。複数ファイルチェックすることで、複数ファイルの一括削除にも対応しています。
フォルダ内にファイルが１つもない場合、ファイル一覧の代わりにフォルダ削除フォームが現れます。（このサンプルには表示されていません）
|
４．７ 再編集書式設定ページと動的再編集処理ページの作成
ここまで開発してくると、機能的には、Ｖ３で目標にしていたものが出揃いました。しかし、まだ、連携して動作することができません。
縦書きとルビをサポートした新しい動的再編集処理はすでに動作していましたが、それは、データ管理の枠組みに古い枠組みを使用しており、古い再編集仕様設定ページと連携して動作するものでした。
こ れに対して、会員の登録・認証・管理・アップロードの仕掛けは、データ管理の新しい枠組みを使用して開発されました。そして、それと連係動作する新しい再
編集仕様設定ページもありましたが、そこには再編集書式の設定機能が省かれていました。代わりに再編集書式設定ページに遷移する書式設定ボタンがあります が、遷移先のページがまだ無いため、押しても何も動作しない状態でした。実行ボタンも同様で、データ管理の新しい枠組みで動作する動的再編集処理ページが
無いため、何もできない状態でした。
したがって、ここで、新たに、データ管理の新しい枠組みで動作する再編集書式設定ページと動的再編集処理ページを作成する必要がありました。
この２つのページの機能を整理すると、以下のようになります。
ただし、このイメージは分かりやすいのですが、そのまま実現しようとすると、セキュリティ上に問題があります。
このイメージはＶ２．５のプログラム構造がベースになっているのですが、Ｖ２．５では、再編集仕様設定ページと再編集書式設定ページは一体になっていて、PHPで書かれていました。サーバ側で会員情報やフォルダ情報を保持しているデータベース（Ｖ２．５ではテキストファイルで作られていましたが）にアクセスする必要があったためです。
Ｖ３では再編集書式設定ページと動的再編集処理ページは第三者がアップロードできることが目標になっています。しかし、PHPで記述するページを第三者がアップロードできるようにして良いのでしょうか。
ＰＨＰ はサーバ側で実行されるスクリプト言語です。これを第三者がアップロードできるようにするということは、第三者が好きなプログラムをサーバにアップロード
して実行できるようにすることなので、セキュリティ上、非常に危険なことです。決して許されるべきことではありません。
第三者がアップロードできるファイルは、以下のいずれかに制限する必要があると考えました。
①
クライアント側で参照されるデータファイル。XMLファイルや、ＸＭＬスタイルシート、GIF/JPEGファイルなど。
②
クライアント側で実行されるもの。HTML、JavaScript、Javaアプレット、ActiveXコントロールなど。
③
サーバ側で参照するデータファイル。その中には、上の①②を展開するためのテンプレートファイルも含む。
私は、この制限の元で先の機能を実現する方法として、以下のような構成を考えました。
そのポイントは以下のとおりです。
● 第三者がアップロードするものは以下の３つとなり、先の制限を満足します。
・
再編集書式設定ページ（HTML &
JavaScript）
・
動的再編集処理ページのテンプレート
・
ＸＭＬスタイルシート
● 再編集書式設定ページとサーバ側のPHPで書かれたページの間ではクッキー経由で情報を交換します。
このクッキーは３０日間保存のアプリケーションクッキーとすることで、３０日以内に再びアクセスされたときには再編集仕様設定や再編集書式設定をやりなおす必要が無いようにしました。
●
動的再編集処理ページのテンプレートはHTML
& JavaScriptの形式で記述し、単体でも実行できるようにします。
ただし、単体で実行した場合は、いつも決め打ちで固定の設定と帖・章のデータを使って再編集します。これにより、動的再編集処理ページの単体テストが簡単にできるようになります。
● 動 的再編集処理ページ生成（ＰＨＰ）では、動的再編集処理ページのテンプレートを読み込み、その中に決め打ちで固定の設定や帖・章のデータ参照を検出した
ら、それを再編集仕様設定ページや再編集書式設定ページで指定された設定値や帖・章のデータ参照に書き換えて動的再編集処理ページを生成します。
今回は、私が、この３つのアップロード対象ファイル（再編集書式設定ページ、動的再編集処理ページのテンプレート、ＸＭＬスタイルシート）を、３つの再編集形式（①横書き表示、②縦書き表示、③縦書き印刷用Word文書作成）ごとに３組作成してアップロードしました。
以上により、Ｖ３の目標が達成されました。このＶ３の目標が達成された最初の版は 2006/8/18 にインターネットにアップしました。それ以後も、バグ修正やマイナーチェンジなどでしばしば更新しており、現在の最新版は以下のURLにアップしています。
http://www.genji-monogatari.net/xml/
|
