FrameMaker構造化
FrameMakerの構造化についてです。
この記事での「構造化」の意味するところは、FrameMakerデータのXML化です。
eXtensible Markup Langageの名の通り、XMLはタグ付けする言語です。タグ付けは意味付けです。
テキストの意味付け
FrameMakerの非構造化データ（通常のデータ）があるとします。
FrameMakerでは、非構造化データを構造化データにする際に、とても便利な機能が備わっていますが、そのひとつが「変換表」です。
この段落書式（スタイル）は、このエレメントにするんだよー。という指示をFrameMakerに伝える表ですね。
しかし、それを使うのはエレメント定義が終わってからです。エレメント定義ができていないと、「このエレメントにするんだよー」の部分ができませんから、当然ですね。
また、「変換表」を使う際には、既存のデータにおいて段落書式は正しく適用されているか？という問題もあります。
それを保証してくれる人はほぼいません。経験上で言っているのでいるかもしれませんが、ほとんどは「正しく適用されているはずだが調べてくれ」となることが多いです。
さらにこの段落書式（スタイル）が曲者で、「8_pt」とか見た目の定義をしているのはそのままエレメントには変換できません。
技術的にできないのではなく、XMLにする目的が「他のデバイスで表示する」「HTMLにする」「部分的に抜き出して違うマニュアルを構築する」だったりすることが多いので、紙（PDF）の見栄えだけに合わせたエレメントを作っても異なる方法でデータを使用したい場合に意味が希薄になってしまいます。
「XMLにすることで達成したいタスク（目的）」が問われます。
見た目も大事です。とても理解できる主張です。そもそもデザイン（設計という意味ではなく）にもそのデザインにした重要な理由があるはずですし、外せないこだわりもあるはずです。
しかし、ここで言うテキストの「意味」は「8_pt」からは推測できません。
パターンの把握
テキストの意味付けを行うためには、既存データのテキストの意味を知る必要があります。
それが明確ではないなら、文書を解析することから始める必要があります。全てのテキストに意味付けするわけですから、「おおよそ」とか「たぶん」はいけません。「すべての」です。
分析するには、「この部分はどのような意図で文字を太くしているのか」など「どのような意図で」が重要になります。ですのでライターさんの協力が欠かせません。まずライティングの仕様の有無を確認しますが、文書にまとめられていて更に現状でそれが厳守されていることはまれです。
結局、「文書の再定義をしましょう」ということになることが殆どではないでしょうか。
で、文書に使用されているパターンを把握する必要があるのですが、「この文字サイズのパターン」「インデント量のパターン」「複数コラムのパターン」など、パターンといっても色々です。そして、既存のデータで使用されているパターンが、本当に必要なのかを、内容変更の決定権者に確認して進めていく必要があるかと思います。この「決定権者」がライターさんなのか重役さんなのかどなたなのかは組織によって異なるでしょうが、これをしないと、後でこんなはずじゃなかった論議に花が咲くことになりますので、XML化をする前によくよく話し合いをすべきだと思います。
話し合いで、パターンの種類を机上に出し、共有化できるものなのか個別のものにすべきものなのか話し合って種類を最小限にし、それぞれに定義していきます。
文書の構造化
皆さんお気づきでしょうが、既存の文書をXML化しようとしたら、まず、既存の文書が「文書の構造」を正しく持っているかどうかを検証する必要があります。
FrameMakerにはとても便利な機能が備わっていますが、既存の文書を自動で思い通りのXMLにすることはできません。地道な作業が必要（もちろんFrameMakerに限りません）なので、それを認識したうえでXMLにすることによって、今後どのような展開をし、どのようなメリット、デメリットが考えられるのかを話し合ったうえで、腰を据えて取り組むのが良いと思います。
・・・いつのまにやら具体的な話ではなくなってしまいましたが、弊社では費用と時間をかけても文書は構造化したうえで運用していくべきだと考えています。
文書の今後の展開をどう見積もることができるか？が重要ですね。そしてそれはクライアント側にしかできない見積もりです。