IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  XML  >

パブリッシングのための XML

コンテンツを円滑に XML に移行する

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

原文はこちら


レベル: 中級

Kay Whatley, Technology Author, Freelance

2008年 10月 28日

印刷版としてパブリッシュされるように意図された文書を円滑に XML に移行してください。適切な要素、属性、階層を使用することで、XML の構造を使用した印刷版 (そして PDF 版) のパブリッシングがいかに容易になるかを学んでください。

XML ベースのパブリッシング環境に移行する際に構造が適切に計画、設計されていれば、正しい手法によって時間を節約できるだけでなく、新しいパブリッシング・パラダイムを実現することもできます。XML はコンテンツを運ぶ強力な媒体として、テキストとオブジェクトが入り混じった文書を、ソートも調整もできる階層型のコンポーネントの集合に変換します。パブリッシングの目標を達成するには、それが短期の目標であろうと、長期の目標であろうと、構造化されていない既存のコンテンツを評価することが必須です。

この記事では、印刷版としてパブリッシュされるように意図された文書を構造化文書に変換する方法を説明します。以降のセクションでは、パブリッシングを可能に、しかも容易に行うために当然必要な事項を取り上げ、続いて XML への移行を説明します。この記事で焦点とするのは、コンテンツの構造を設計する方法です。

XML の長期的目標を念頭に置いた計画

よく使われる頭字語
  • DITA: Darwin Information Typing Architecture
  • HTML: Hypertext Markup Language
  • PDF: Portable Document Format
  • XML: Extensible Markup Language
  • XSLT: Extensible Stylesheet Language Transformations

著者としての皆さんは、ワード・プロセッサーのフォーマット設定と Enter キーで作業するのに慣れていることでしょう。つまり、テキストを入力し、フォーマットを選択し、Enter キーを押し、さらに入力して別のフォーマットを選択し、Enter キーを押すという流れです。構造を使用するときには、Enter キーを使う代わりに構造要素を挿入し、コンテンツのフォーマットについては考えないように考え方を転換してください。構造の世界では、オーサリング・ツールあるいは XML スタイルシートがフォーマットを扱います。

ワード・プロセッサーで処理した文書には、入力テキスト、グラフィック、表が含まれます。これらのコンポーネントが構造に変換されると、そのそれぞれが特殊な情報とともに識別されます。特殊な情報とは、パブリッシング・プロセスを進める上で必要な情報であることもあれば、フォーマット設定を制御するために必要な情報であることもあります。文書の各部分は XML 要素となり、データベースのフィールドのように扱うことができ、検索したり、ソートしたり、データを読み出すために使用したりするなど、さまざまに操作できるようになります。要素はそのコンテキストに応じて扱い方が変わることもあります。つまり、その要素がネストされている親要素、あるいは文書ツリー内でその要素の上の階層に位置する要素 (祖先要素) が影響するということです。

どのツールを使用して構造化に取り掛かるかによって、構造に移行する際の最初のステップが変わることはありません。最初のステップは常に、パブリッシングの目標を確認し、その目標を念頭に既存の文書を分析することです。以下の質問について考えてみてください。

  • どのような種類のデータが文書に含まれているか
  • 複雑な情報からなる表があるかどうか
  • 文書を小さなトピックまたはセクションに簡単に分類できるかどうか
  • コンテンツがセクションごとに体系付けられているのではなく、フリーフォームのテキストを主体としているかどうか
  • 文書のどの部分を特殊な要素または属性として識別する必要があるか (必要に応じて再利用や、ソート、追跡、またはその他の XML ならではの利点を生かす対象にできるようにするため)
  • 翻訳が目標に含まれている場合には、翻訳済みのコンテンツを識別する属性を組み込む必要があるかどうか
  • 文書のコンテンツにコメントを付けたり、文書の別のバージョンとして使うためにマークを付ける必要があるかどうか

文書の構造を決定する

既存のコンテンツを評価して、そのコンテンツがどのような構造をしているのかを明らかにしてください。例えば技術マニュアルをパブリッシュする場合、文書はテキストのセクション、スクリーンショット、図、表、手順、参照データなどで構成されているはずです。テキストについては、本文の段落、リスト、キャプション、見出し、そして強調表示した語句に分類できる場合もあります。図 1 に、サンプル文書の 1 つのセクションを記載します。このセクションには、見出し、複数の段落、そしてある手順を示す一連のステップが含まれています。


図 1. サンプル文書のセクション

段落のタイプを要素に割り当てる

上記のコンポーネントを評価したら、次に、要素に論理名を指定して段落のタイプを割り当てます。最初にあるのは <title> または <head> 要素です (「Checking Your Installation」という見出し)。これに続く段落は <p> 要素に、番号付き手順は <procedure> 要素内の <step> 要素にマッピングすることができます。ステップを組み込む場合には、文書のなかでステップの部分を <task> タイプのセクションとして識別するか、あるいは単に <section> 要素と呼ぶかを決めることになります。

このように、コンテンツの構成部分を 1 つひとつ評価して、最終的にどのような構造にするかを決定します。要素名は (既成の構造を使うことにしない限り) 各自の判断で自由に決められますが、自分にとっても、文書にとっても論理的な名前にしてください。

この文書を例に評価すると、見出しのフォーマットには「Heading 1」を使用することになります (図 2 を参照)。


図 2. サンプル・セクションでのフォーマットに関する注釈

この見出しを <title> 要素に含めることにした場合には、当然、見出しをこの要素に変換するためのマッピングが必要であると判断できます。同様に、他の段落 (Body Text First、Numbered、Body Text) のそれぞれについて、変換中に作成する要素を決定します。その際、斜体および太字のテキスト・フォーマット、相互参照、そして各段落に含まれるその他の項目も忘れずに考慮に入れてください。

図 2 には、段落のタイプ (見出し、番号付きステップなど) が示されています。これらすべての段落に関して段落そのものと併せて、段落のなかに含まれる特殊な項目も検討してください。図 2 を例にとると、ここには強調表示されたテキストと引用符で囲まれた語句があります。文書を構成する各セクションは <title><p><steps> に分類するだけだけでなく、<xref><italic>、あるいは <user_action> に分類することも考えられます。その場合、斜体 (または太字や強調表示) のテキストをステップ内に含めることも、以降の段落での相互参照を含めることも、あるいは引用符で囲まれた情報を特殊な要素で識別することも可能になります。上記の図には示されていませんが、このコンテンツでは用語集や索引の項目となっている単語も識別されているはずです。そのような単語を囲むための要素を作成することもできます。

要素ごとの階層を検討する

要素を設定したら、次は各要素の階層を検討する必要があります。構造 (XML) には、要素の使用方法に関する規則が組み込まれます。一部の要素は親要素 (つまり、別の要素全体を包含する要素) のなかにラップされることになります。親要素に含まれる要素は、子要素と呼ばれます。子要素は、同じ親要素に含まれる兄弟を持つこともできます。このように、要素のなかに要素を含む複数レベルのネストによって、文書の階層が形成されます。それぞれの要素を定義すると同時に、その要素を含めることのできる親要素、そしてその要素に含めることのできる子要素 (該当する場合) も識別しなけばなりません。

属性を検討する

パブリッシングの目標を確実に達成するためには、必要な属性 (要素に組み込む追加データ) についても検討しなければなりません。例えば <title> 要素に ID を指定する属性を設定するなど、属性は文書の該当する部分をより具体的に識別するために設定することができます (<title type="summary"> の場合、属性名は type で、属性値は summary です)。属性にも追加情報 (著者の名前や発行日) を含めることができます。さらに、ソートや、データの取得、文書管理をする上で重要な情報である一方、パブリッシュされた文書には現れない情報を含めることも可能です。

必要に応じて作成しなおす

このように詳細な評価を行う過程では、コンテンツを構造に移行する計画を開始できるだけでなく、構造がコンテンツにどれだけ上手く適合するかを確認することもできます。何らかの不適合に対処するには、構造を変更することも (この方法が選択可能な場合)、コンテンツを作成しなおすこともできます。選択した構造にぴったり合わせるためには、ある程度の再作成も必要になるはずです。そのため、最初は比較的大まかな分析を行い、それから全体を見直して構造を強化し、文書が必要事項をすべて満たすために再作成が必要となる領域を特定してください。分析を進めている間は、現行の構造化されてない状態のコンテンツでそのまま作業できます。

カスタム要素と業界標準との比較

文書を分析し、自分で名前を付けて設計した要素を使ってその文書にふさわしい構造を作成することもできますが、その一方で、業界標準の構造 (MIL-SPEC、DITA、DocBook など) を使用するという方法もあります。既存の構造に適合させる必要がある場合、その特定の構造に収まるようにコンテンツを変更しなければならないこともあるはずです。例えば前に記載したサンプルに DITA を適用するには、手順を示すステップに続く段落を作成しなおすことになります。このサンプル文書で DITA タスク構造を使用するとなると、手順を示すステップに続くコンテンツに使用できる <task> 要素のオプションが限られてしまうからです。そのため、例えば論理的にはステップの後の段落には結果に関するテキストが含まれていないとしても、コンテンツを複数の <p> 要素として <result> 要素のなかに収めなければなりません。あるいは、<task> 要素の子要素、<related-links> に収まるように、これらの段落を作成し直さなければならないことも考えられます。コンテンツをどれだけ変更しなければならないかは、その文書がどのような文書でどんな構造に適合させる必要があるかに依存しており、わずかで済む場合もあれば、大掛かりなものになる場合もあります。構造を決定して文書の変換を開始する際には、不適合の可能性を念頭に置いください。




上に戻る


変換のためのフォーマット・マッピング

構造を決定してフォーマットをマッピングし、ツールを使用できるように準備した段階で、変換を実行して構造を文書に組み込めるようになります。図 3 は、マッピングの一例です。最初の列には元の構造化されていない文書内でのオブジェクトが示されています。この列にはまず段落が示され、次にテキストの範囲 (文字レベルのフォーマット)、そしてその他の文書コンポーネントが続きます。2 番目の列に示されているのは、それぞれのコンテンツに対応する要素の名前です。3 番目の列は論理的な任意の方法で表現できる注釈で、変換後の構造でどのような階層 (系図) になるかを示します。


図 3. マッピングの例 (表形式)

このデータを使用して、いよいよ変換計画を立てることができます。変換は、使用するツールや利用できる専門技術に応じたさまざまなプロセスで行うことができます。変換プロセスを提供するツールには、例えば Adobe® FrameMaker® などがあります。一方、自動的に構造への変換を行わないツールの場合には、まずコンテンツを中間フォーマット (テキスト、HTML、または未加工の XML など) にエクスポートする必要がある場合があります。中間フォーマットを用意した後は、Perl や XSLT、またはその他のスクリプトの選択肢を使用して未加工の出力をパブリッシング用に使用できる構造 (XML) に変換するために、内部 (または外部) の専門技術を活用する必要も出てくるかもしれません。

変換が完了したら、構造化されたコンテンツを確認して、コンテンツに (そして自分に) 適した構造になっていることを確認します。


図 4. サンプル・セクションに対して作成される構造の一例

変換に必要な時間を判断するには、文書全体であるか、1 つの章であるかに関わらず、パイロット・プロジェクトが役立ちます。パイロット・プロジェクトでは文書の小さな一部分を使用して変換プロセス全体を実行し、プロセスが完了した時点で構造化されたコンテンツがパブリッシング用に適切なフォーマットにされていることを確認できます。構造とコンテンツが上手く適合していると確信したら、今度は十分なサイズのサンプルで変換ワークフロー全体を実行し、結果を確認してください。設計が慎重に行われていて、構造がコンテンツにぴったり合っているとすれば、この時点で、再作業することなく変換を進められます。




上に戻る


短期間での配布の必要性

この記事で説明した手順 (文書の分析、構造のマッピング、再作成) は多くの場合、パブリッシュが行われている一方で実行されますが、その場合も文書は配布できる形にしなければなりません。そのため、構造に移行するときには文書を使用に適したフォーマットに維持する必要があります。配布の形態 (印刷物、PDF、HTML など) によっては、非構造化コンテンツと構造化コンテンツの両方からパブリッシュすることも考えられます。

コンテンツを構造化する準備が整ったら、以下のプロセスに従ってください。

  1. 元の構造化されていないファイルのバックアップを作成します。
  2. 1 つの文書で変換を行います。
  3. 変換結果を確認します。
  4. 変換した文書を (任意のツールでの) 構造化文書または XML ファイルとして保存します。
  5. 変換した文書からパブリッシュし、必要に応じてパブリッシュすることを確認します。
  6. 他の文書に対してこのプロセスを繰り返します (一度に 1 つの文書を使用)。

このプロセスを使えば、構造化されていない文書と、このプロセスをすでに実行した文書の両方が混在しているとしても、随時、文書をパブリッシュすることができます。文書がすべて変換された後は、そのまま円滑にすべてのコンテンツを使って必要に応じてパブリッシュできるようになります。




上に戻る


まとめ

構造を使用しないパブリッシングから構造を使用したパブリッシングに移行するには、時間も労力もかかります。前もって計画を立てることで、問題を防ぎ、円滑な移行を確実にすることができます。円滑な移行は、さまざまな選択肢の慎重な検討、パイロット・プロジェクトによる変換時間の事前予測、そして素早い変換を可能にする事前のセットアップから生まれる結果です。

論理にかなった要素、属性、階層を確実に用意することは、すなわち、XML への変換後にパブリッシングを円滑に行えることを意味します。



参考文献

学ぶために
  • New to XML: XML 初心者を対象としたこの入門サイトにアクセスしてください。

  • Introduction to XML」(Doug Tidwell 著、developerWorks、2002年8月): XML とは何か、なぜ XML が開発されたのか、そして電子コマースの将来に XML がどのような影響を与えているかを学んでください。さらにこの記事では、一連の重要な XML プログラミング・インターフェースと標準、そして XML でビジネス問題を解決する 2 つ事例研究も紹介しています。

  • Introduction to XSLT」(Nicholas Chase 著、developerWorks、2007年1月): XML の変換は一般的なニーズとなっているため、XSLT は基本的な XML 仕様の 1 つとしてみなされています。このチュートリアルでは XML データのフォーマットを変換する方法を、XSLT スタイルシートの作成方法、XML 文書の特定の部分を選択可能にする XPath の基礎知識、そしてXSLT が提供するさらに高度な機能を説明しながら案内します。

  • Darwin Information Typing Architecture (DITA XML): DITA についての詳細を調べてください。DITA は、トピック指向の情報タイプを定義したコンテンツを作成し、再使用可能なコンテンツを単一の情報源から提供するためのアーキテクチャーです。

  • developerWorks technical events and Webcasts: 最新技術についての情報を入手してください。

  • XML Technical library: 広範な技術に関する記事とヒント、チュートリアル、標準、そして IBM Redbooks については、developerWorks XML ゾーンを参照してください。

  • technology bookstore: この記事で紹介した技術やその他の技術に関する本を参照してください。

  • IBM XML 認証: XML や関連技術の IBM 認定開発者になる方法について調べてください。

  • developerWorks podcasts: ソフトウェア開発者向けの興味深いインタービューとディスカッションを聞いてください。


製品や技術を入手するために
  • IBM 製品評価用の試用版ソフトウェア: developerWorks から直接ダウンロードできるトライアル・ソフトウェアで、次のプロジェクトを構築してください。DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® によるアプリケーション開発ツールおよびミドルウェア製品のトライアル版が揃っています。


議論するために


著者について

Photo of Kay Whatley

Kay Whatley は技術研修インストラクターであると同時に、本の著作活動を行っています。『XML Weekend Crash Course for Hungry Minds』(Wiley、2000年) の執筆に参加し、『Advanced FrameMaker』(TIPS、2004 年) では主執筆者を務めました。著書には、『XML and FrameMaker』(Apress、2004年)、そして最新の技術書『XML: Problem-Design-Solutio』(Wiley、2006年) があります。本だけでなく、彼女は業界の雑誌や Web サイトにも頻繁に記事を書いています。




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



 


 


不充分・不完全である大変素晴らしい
 


この記事を共有する

del.icio.us del.icio.us newsing newsing FC2ブックマーク FC2ブックマーク
Choix! Choix! ニフティクリップ ニフティクリップ Yahoo!ブックマーク Yahoo!ブックマーク
MM/memo MM/memo CZブックマーク CZブックマーク livedoorクリップ livedoorクリップ
はてなブックマーク はてなブックマーク Buzzurl(バザール) Buzzurl(バザール)




上に戻る


Adobe、FrameMaker、Adobe ロゴ、PostScript、および PostScript ロゴは、Adobe Systems Incorporated の米国およびその他の国における登録商標または商標です。 IBM、IBM ロゴ、ibm.com、DB2、developerWorks、Lotus、Rational、Tivoli、WebSphere、および pureXML は、International Business Machines Corporation の米国およびその他の国における商標または登録商標です。 他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。

    日本IBMについて プライバシー お問い合わせ