JP2006525609A - コンテンツを複数のフォーマットで出力するための仕様を規定するシステムおよび方法 - Google Patents

Abstract

コンテンツを複数のフォーマットで出力するための仕様を定義するシステムおよび方法である。より具体的には、複数の出力メディアフォーマットを設計することができる単独のマルチパーパススタイルシートを単独のユーザインターフェースから作成するシステムおよび方法である。例えば、マルチパーパススタイルシートは入力ＸＭＬコンテントをＨＴＭＬ、ＰＤＦ、ポストスクリプト、ＷＭＬその他の出力フォーマットに変換することができる。方法は異なる出力メディアフォーマットの多様なプロパティに対応するフォーマットルールを含むマルチパーパススタイルシートを作成し、修正することを含む。ユーザは異なるフォーマットプロパティを異なる出力メディアフォーマットのために選択することで、マルチパーパススタイルシートを構成できる。

Description

本発明は一般的に、コンテンツを複数のフォーマットで出力するための仕様（もしくはスタイルシート）を定義するシステムに関する。具体的には、コンテンツを複数の出力メディアフォーマットに出力するために単独の仕様もしくはマルチパーパススタイルシートを定義するシステムおよび方法に関する。

今日のコンテンツ公開環境において、コンテンツはＭｉｃｒｏｓｏｆｔ Ｗｏｒｄ、ウェブエディタ（例えばＡｒｂｏｒｔｅｘｔ’ｓ Ｃｏｎｔｒｉｂｕｔｏｒ）およびエクステンシブル・マークアップ言語（ＸＭＬ）等の多様なエディタ（例えば、Ａｒｂｏｒｔｅｘｔ’ｓ Ｅｐｉｃ Ｅｄｉｔｏｒ）を用いて生成され編集される。同様にこのコンテンツは、印刷、ポータブルドキュメントフォーマット（ＰＤＦ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）の多様なフォーム、ワイヤレス・マークアップ言語（ＷＭＬ）およびポストスクリプト等の複数の出力メディアフォーマットに公開される。コンテンツはまた、ＨＴＭＬヘルプ、ＭＳＲｅａｄｅｒ、パーソナルデジタルアシスタント（ＰＡＤｓ）等のコンパイルされたフォーマット、および携帯電話のフォーマットで公開される。

現在、デザイナおよびプログラマはコンテンツを所望のメディアフォーマットに所望のレイアウトで出力するために別々のスタイルシートを作成する。スタイルシートは典型的にフォントやマージン、フォーマットレイアウトおよび出力ドキュメントの外見を定義するその他のタイプの情報を含む。スタイルシートはコンテンツをあるフォーマットから別のフォーマットに変換するために用いられてもよい。例えば、ＸＭＬコンテンツを上記の複数の出力メディアフォーマットの１つに変換してもよい。

異なるスタイルシートは、コンテントおよびレイアウトのいずれの差異を含む、異なるタイプの装置へ異なるタイプの出力を作成するために用いられてもよい。このタイプのコンテントの適合化を行う必要性は新タイプのコンピュータ装置の人気の増加につれて急速に増大している。１つの例として典型的に、限られたバンド幅しか持たず、低い解像度の少ない色のみをサポートし、オーディオコンテンツをサポートしない、携帯型の装置がある。従って、ＸＭＬドキュメントはもともと、ドキュメントがフル機能のデスクトップコンピュータ画面もしくは印刷したフォームに表示されるために作成されることを期待して作成されており、携帯型装置では見られず、また見るべきでない多量のコンテントを含む。

先行技術におけるスタイルシートは、唯一の特定出力メディアフォーマットに出力を生成するよう設計されている点で制限される。もし複数のフォーマットへの出力が要求される場合、別々のスタイルシートがそれぞれの出力のタイプについて作成されなければならない。増加し続ける表示装置の数および表示フォーマットに従い、自動的に複数の出力メディアフォーマットへの出力を生成する道具の必要性が増加している。従って、単独のマルチパーパスシートに基づいて、コンテンツを複数の出力メディアフォーマットに出力する仕様を定義するシステムが必要とされている。

本発明は、単独のユーザインターフェース（“ＵＩ”）のための仕様を定義し、そのインターフェースから複数の出力メディアフォーマット（マルチチャンネル出力）を設計することが可能な単独のマルチパーパススタイルシートファイルを作成する方法およびシステムを提供する。

本発明は一般的に、多様なソースからエクステンシブル・マークアップ言語（ＸＭＬ）ベースのコンテンツを受け付けることが可能で、そのコンテントを、複数のユーザによって設定可能な様々なスタイルバリエーションを有する出力メディアフォーマットに出力することが可能な、単独のマルチパーパススタイルシートを作成する方法およびシステムを提供する。

より具体的には本発明は、マルチパーパススタイルシートおよび、ＸＭＬ入力ドキュメントを特定のフォーマット（口語表現では“ルールベースフォーマット”と呼ばれるもの）で提示するために、ＸＭＬ入力ドキュメントその他の入力ドキュメントを受け付けユーザ選択型の出力ドキュメントを適切に構成する、マルチパーパススタイルシートに関連したエディタを提供することができる。ドキュメントの“ユーザ選択型”とは、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ポータブルドキュメントフォーマット（ＰＤＦ）、Ｍｉｃｒｏｓｏｆｔ ＷＯＲＤ、もしくはその他のファイルタイプのようにファイル固有でもよいし、プリンタ、パーソナルデジタルアシスタント（ＰＤＡ）、液晶ディスプレイ（ＬＣＤ）、携帯電話、その他の装置固有でもよい。ユーザ選択型がファイル固有である場合、本発明は表示するための入力ドキュメントをコンピュータで読み取り可能なファイルとしてフォーマットする。ユーザ選択型が装置固有の場合、実施形態は選択された特定の装置で表示するための入力ドキュメントをフォーマットする。このようなフォーマット（ファイルもしくは装置のための）は一般的に“スタイル付け”と呼ばれる。スタイル付けは、スタイルシートにおいて定義付けられた１つもしくはそれ以上のフォーマットルールを入力に適用することによって行われる。

例えば、本発明の一実施形態において、入力ＸＭＬドキュメントは、コンテンツを複数の出力メディアフォーマットに出力するのに有用なマルチパーパススタイルシートを作成もしくは修正するために用いられる。本発明は、多様なスタイル付け／フォーマットルールを含むスタイルシートを開くか、あるいはそれにアクセスを行う。マルチパーパススタイルシートは第１のルールをＨＴＭＬドキュメントとして出力するドキュメントの一部分に適用するが、ＷＯＲＤ出力ファイルが望ましいドキュメントの同じ箇所には第２のルール（第１のものとは異なる）を適用する。これらのルールは例えば、出力ファイルが開かれたときの表示装置上でのテキストの位置合わせや、ドキュメントの部分の色、いずれのグラフィック（もしあれば）が観察されるとき出力ドキュメントのセクション内に表示され、またドキュメントの特定の部分が出力ファイルに含まれるかどうか、等に対応するものである。

例えば、入力ファイルもしくはドキュメントは、それぞれの異なるビューア技術に最適化された、同じグラフィックファイルの５つのバージョンもしくは、同じグラフィックファイルの５つの外部バージョンへのリンクを含むことができる。本発明において作成されたマルチパーパススタイルシートは最も低解像度のグラフィックをＨＴＭＬ出力ファイルに含めるものとして選択し、最も解像度の高いグラフィックをＰＤＦもしくはプリントのファイルに含めるものとして選択する。同様に、グラフィックはＨＴＭＬファイルを確認したときにそのファイル内のある場所に位置される（例えば、出力ファイルの左上隅）が、ＰＤＦなどの異なる出力ファイルにおいては他の場所に位置される（例えば、出力ドキュメントの中央）。

マルチパーパススタイルシートの追加的な使用法としては、プリント・ＰＤＦ出力のページ長さを定義するが、ＨＴＭＬ出力その他のページ長さに制限はないものの、ページ長さを削除する、というものがある。また、マルチパーパススタイルシートは、全ての出力タイプには適応できない任意のルールベースの機能性を含んでもよい。例えばＨＴＭＬ出力はテキスト、グラフィック、その他のオブジェクトの表示装置上もしくは出力ファイル内での絶対的な位置決めを可能にすることができるが、ＷＯＲＤおよび／もしくはＰＤＦドキュメントではできない。マルチパーパススタイルシートはこのような違いを認識し、ＨＴＭＬドキュメントにおいては絶対的な位置決めを可能にする適切なルールを適用し、その他の出力フォーマットには相対的な位置決めを適用する。

本発明がフォーマットルールを適用する方法は、複数のフォーマットでのコンテンツの出力をさらに自動化する“スタイルアーキアイプ”の識別、作成および使用を介してである。スタイルアーキタイプは、目次、インデックス、黒丸付きもしくは番号付きリスト、ハイパーリンク等の、共通のパブリッシング構築の処理に用いられるモデルもしくはプロトタイプである。特定のスタイルアーキタイプのインスタンスとしての入力要素の識別は、特定のアーキタイプに共通のデフォルトのフォーマット特性を自動的に適用してもよく、追加の出力フォーマットアプリケーションにおける入力要素の使用に影響を及ぼすことも可能であり、スタイルアーキタイプに割り当てられた他の要素の出力に影響を及ぼしてもよい。ドキュメント中の各要素、もしくは要素グループは、スタイルアーキタイプを割り当てられ、それによって関連したフォーマットルールおよびオプションを要素に割り当ててもよい。

一般的に上記の説明は出力ファイルタイプのみを参照して行われてきた。しかし同じルールは出力が装置ベースの場合にも適用できる。例えば、同じ絵を異なる解像度で示す複数のグラフィックにおいては、本発明の実施形態は、プリンタへの出力を液晶表示（ＬＣＤ）ディプレーへの出力よりも高い解像度のグラフィックを含むようにスタイル付けする。

さらに、本発明にかかるマルチパーパススタイルシートはコンテキスト固有のルールを含んでもよい。つまり、１組のテキストは、入力ドキュメント内の階層的な位置に応じて、異なるようにスタイル付けされてもよい。例えば、連続的なテキストセクションは、テキストがＸＭＬチャプターレベルで現れたときに一度インデントされ、サブチャプターレベルで現れたときに二度インデントされる（もしくは下線をひかれたり、太字にされたり、全て大文字で示されたり、省略されたりする）。

またさらに、本発明に従ってスタイル付けは、出力固有、および／またはコンテキスト固有に加え、ユーザ固有で行われてもよい。出力が異なるユーザによって提示されるとき、それぞれのユーザはレベル、クラス、コンテキスト、セキュリティクリアランス、その他の識別子を割り当てられる。ユーザ識別子はスタイルシートに含まれてもよいので、ある特定のクラスや識別子を有するユーザが出力ファイルにアクセスしたり、あるいはスタイルシートを操作したりする場合、出力は、異なるクラスや識別子を有するユーザの場合とは異なるようにフォーマットされる。

上記の機能性は全て一般的にユーザ指定である。本発明の他の実施形態において、このようなユーザ指定は、マルチパーパススタイルシートの作成を単純化するように特に構成された１つもしくはそれ以上のグラフィクユーザインターフェース（ＧＵＩｓ）を通じて完成される。

さらに、本発明はユーザが、例えば手作業で特定の出力メディアタイプもしくは装置の、特定の要素、コンテキストもしくは条件（後に説明される）を編集することにより、ユーザがマルチパーパススタイルシートのフォーマット特性を拡張することを可能にする。より具体的には、ソフトウェアはユーザが例えばエクステンシブル・スタイルシート言語（ＸＳＬ）やフォーマット出力指定インスタンス（ＦＯＳＩ）等を特定の出力に書き込むことを可能にする。このコードは．ｓｔｙｌｅファイルに格納されている。将来の使用の間、このコードフラグメントは管理、再利用されてもよい。さらに、コードが複数のスタイルシートで用いられるのを可能にする．ｓｔｙｌｅファイル外部のライブラリが備えられてもよい。例えば、ユーザＸＳＬコードはカスタムダイナミックＨＴＭＬスクリプトをＨＴＭＬ出力に追加して編集される。このコードは全てのパートナンバー定義付けコンテントをウェブサイト上の特定のページに自動的にハイパーリンクさせるために用いられる。

従って本発明は、一般的に、単独のマルチパーパススタイルシートを作成するためのシステムおよび方法を提供し、単独のマルチパーパススタイルシート・アブストラクションを用いることで多様な出力で公開するのに用いるドキュメントをフォーマットする基準は一度に定義される。それぞれのフォーマット固有もしくは装置固有の出力は、基準フォーマットに優先する定義されたフォーマットを有する。

多様な実施形態が開示されているが、次の詳細な説明により、本発明の他の実施形態が当業者にとって明らかになるであろう。当然のことながら本発明は、本発明の精神と範囲を外れることなく、明白な様々の様態に改変することができる。従って、図面および詳細な説明は例示的なものと見なされるものであり、発明を制限するものではない。

一般的に本発明は、コンテンツを複数のフォーマットで出力するための仕様（スタイルシート）を定義するシステムを提供する。より具体的には本発明は、多様なファイルフォーマットのうちのいずれかに格納される入力ファイルを受け付け、その入力ファイルをマルチパーパススタイルシートを用いた第２のフォーマットに変換して出力することが可能な、単独のマルチパーパススタイルシートを定義するシステムを提供する。そのようにして、本発明のソフトウェアは単独のマルチパーパススタイルシートを用いたマルチチャンネルで（コンテンツは、１つまたはそれ以上のソースから取得される）ドキュメントを公開することを可能とする。入力ファイルと同様、出力ファイルは、コンピュータで読み取り可能な多様なファイルフォーマットのうちのいずれかとしてフォーマットされることができる。本発明は、所望のファイルタイプに基づく、出力固有および／またはコンテキスト固有スタイルを提供する。ファイルタイプは、印刷、ポータブルドキュメントフォーマット（ＰＤＦ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ワイヤレス・マークアップ言語（ＷＭＬ）、ポストスクリプト等の出力メディア形式に基づくもの、もしくは出力装置に基づくものが可能である。本発明の一実施形態において用いられる典型的な出力装置としては、モニタ、プリンタ、テレビ、液晶ディスプレイ（ＬＣＤ）、ウェブ・タブレット、携帯電話のディスプレイ、ポケットベル、その他の通信（有線もしくは無線）を受信し、英数字もしくは画像による出力を表示できる装置がある。

本発明は、出力固有および／またはコンテキスト固有のスタイルに加え、ユーザ固有のスタイルに用いることもできる。従って、出力が異なるユーザに提供された場合、それぞれのユーザはレベル、クラス、コンテキスト、セキュリティクリアランス、その他の識別子を割り当てられる。ユーザ識別子はマルチパーパススタイルシートに含まれてもよいので、ある特定のクラスや識別子を有するユーザが出力ファイルにアクセスしたり、あるいはマルチパーパススタイルシートを操作したりした場合、出力は、異なるクラスや識別子を有するユーザの場合とは異なるようにフォーマットされる。

本発明のシステムや方法を用いることで、一連の同一の要素を用いる全てのドキュメントを個々に“スタイル”付けたり、フォーマットしたりする必要がなくなる。本発明のマルチパーパススタイルシートを用いることで、“ドキュメントタイプ”の全てのドキュメントは手動による介入を経ずにフォーマットされる。

入力ファイルをスタイル付けするには、ファイルもしくはファイルの一部分にフォーマットルールが適用される。所定のドキュメント部分（もしくは“要素”）に正確にいずれのフォーマットルールが適用されるのかについては、図１を参照してより詳細に説明する。一般的に“フォーマットルール”とは、要素に適用されるある特定の出力フォーマット、配列、フォント、グラフィック、その他等を指定する、コンピュータで実行可能な命令、もしくは仕様である。あるいは、フォーマットルールは要素の表示を制御および／もしくは修正できる。フォーマットルールは、ユーザが関与できる、ハイパーリンクや動画のスタート／ストップ等の対話を定義することができる。

本発明がフォーマットルールを適応する方法として、複数のフォーマットでのコンテンツの出力をさらに自動化する“スタイルアーキタイプ”の識別、作成、および使用を介して行う。スタイルアーキタイプは要素スタイル割り当てのフォーマットおよび使用に影響を及ぼすように用いられてもよい。スタイルアーキタイプは、特定の要素がドキュメントにおいてどのようにフォーマットされるかということに関してその要素の目的を獲得する。各スタイルアーキタイプはスタイルシートの他の領域におけるプロセス動作を決定する。スタイルアーキタイプは、目次、インデックス、黒丸付きもしくは番号付きリスト、ハイパーリンク等の、共通のパブリッシング構築の処理に用いられるモデルもしくはプロトタイプである。特定のスタイルアーキタイプのインスタンスとしての入力要素の識別は、特定のアーキタイプに共通のデフォルトのフォーマット特性を自動的に適用してもよく、追加の出力フォーマットアプリケーションにおける入力要素の使用に影響を及ぼしてもよく、スタイルアーキタイプに割り当てられた他の要素の出力に影響を及ぼしてもよい。ドキュメント中の各要素、もしくは要素グループは、スタイルアーキタイプを割り当てられ、それによって関連したフォーマットルールおよびオプションを要素に割り当ててもよい。

図１は第一のフォーマットの入力ファイルを、第２のフォーマットの異なる出力ファイルのグループにスタイル付けする例示的な処理を説明するフローチャートである。本実施形態においては、エクステンシブル・マークアップ言語（ＸＭＬ）に準拠した入力ファイルが入力ファイルとして受け付けられる。一般的にＸＭＬは、コンテンツ、メタ・データ、リンク、クエリ、変換および設定情報を表すために有用で、人と機械によって読み取り可能な標準化された文法を提供し、動的コンテンツの単純化された処理を可能にする。ドキュメントコンテンツ（散文）はＸＭＬネイティブで作成されてもよく、独自仕様のアプリケーションからＸＭＬに変換されてもよい。多くのデータベースから直接のものを含む多様なソフトウェアアプリケーションからのデータは、ＸＭＬとしてアクセス可能である。ＸＭＬリンク言語（Ｘｌｉｎｋ）、ＸＭＬパス言語（ＸＰａｔｈ）、エクステンシブル・スタイルシート言語（ＸＳＬ）等のＷ３Ｃスタンダードは、アプリケーションのプログラマとユーザがアプリケーション間で互換性のある、スタンダード文法を使用することを可能にするために活用できる。

その他のファイルタイプの入力ファイル（例えばＷＯＲＤ、ＰＤＦ、ＨＴＭＬ等）は、上述のスタイル付け処理に先立って、ＸＭＬファイルに変換される。示された実施形態はこの変換を実行するためにコンピュータで読み取り可能な別々のプログラムもしくはモジュールを用いるが（ＡｒｂｏｒｔｅｘｔのＩｎｔｅｒｃｈａｎｇｅ等）、このような変換プロセスは本発明の追加的な実施形態によって行われてもよい。追加的な実施形態において、ＸＭＬ以外のファイルタイプは入力ファイルとしてネイティブに受け付けられる。

ここに説明されたように、本発明はマルチパーパススタイルシートを作成する。例示的な実施形態において、本発明は“．ｓｔｙｌｅ”ファイルと呼ばれるＸＭＬスタイルシートを作成する。本発明は任意にこのｓｔｙｌｅファイルから標準準拠型ＸＳＬもしくはＸＳＬフォーマットオブジェクト（ＸＳＬ−ＦＯ）スタイルシートファイルを生成してもよい。ＸＳＬスタイルシートは、出力結果を作成するために用いる、入力パターンとテンプレートを定義するテンプレートルールを含む。スタイルシートを適用する場合には、テンプレート内のパターンはＸＭＬソースドキュメントの文法に一致させる。テンプレートパターンに一致が確認された場合、テンプレート内で特定される動作に従って、出力ドキュメントのフラグメントが作成される。ソースドキュメントは一致パターンが確認されなくなるまで再帰的構文解析を行う。結果として得られるドキュメント破片はその時マージされて完全な出力ドキュメントが作成される。もちろん他のタイプのスタイルシートも本発明に従って作成されてもよい。

一般的にスタイルはドキュメントの要素に関連付けられている。コンテキストは入力ファイル内の要素の位置（もしくは“要素セレクタ”）を参照する。要素の中には、その要素が発生するコンテキストによって異なるプロパティを用いるものもある。従って、本発明は一般的にフォーマットプロパティを要素コンテキストに、もしくは要素に直接関連付ける。さらに、異なるフォーマットプロパティを同じコンテキストに関連付けるために“条件”が用いられる。条件は一連の属性テストとフォーマットプロパティの集合から構成される。

図１を参照すると、本発明のスタイル付け処理は、ターゲットドキュメントが解析される操作１００から開始する。一もしくはそれ以上の入力ファイル（もしくは“ドキュメント”）は、本発明もしくは本発明のユーザによって解析され、各要素をラベリングするタグを有するドキュメントタイプデフィニション（ＤＴＤ）、もしくはＸＭＬスキーマを作成してもよい。

図２は、要素タグ２２、コンテキストタグ２４、スタイルタグ２６、および出力ベーススタイルエディタ２８を示すユーザインターフェース２０のスクリーンショットである。図１に示す操作１０５において、本発明は入力ファイル内の各要素の位置とタイプを決定する。一般的に、“要素”とは特定のファイルマーカ、タグ、およびヘッダに対応するドキュメントの部分である。要素を定義するために用いられるタグは一般的に、入力ファイルの一部分であり、入力ファイルの一部として自動的に作成されても、手動で入力されてもよい。要素タグは入力内の各“要素”に割り当てられる。例えば、図２に示されるように、要素は“セクション”、“サブタイトル”、“表”、“タイトル”等とタグ付けされる。好適なタグのいずれが用いられてもよく、これらリストされたおよび／もしくは示されたものは、例示する目的のみのためである。ＸＭＬ入力ドキュメントはネイティブに割り当てられたタグを有する。もし入力ドキュメントがＸＭＬドキュメントでない場合、タグは他の方法で割り当てられる必要がある。適切なファイルタグが認識され、ファイルが個々の要素に構文解析されると、各要素は特定の要素カテゴリに割り当てられる。ここでまた一般的に、これらの要素は多様なＸＭＬ要素に対応している。

要素が識別され、割り当てられると、本発明は図１の操作１２５において各要素に関連付けられた特定のフォーマットルールを決定する。“要素”は一連のフォーマットプロパティを有するドキュメントの一部と考えられている。要素と関連付けられたフォーマットプロパティはコンテキストおよび／もしくは要素に関連付けられた条件に依存する。従って、要素に関連付けられた特定のフォーマットルールが決定される前に、本発明は要素のコンテキストおよび条件を決定し、図１の操作１１０，１１５および１２０に示される関連付けられたコンテキストと条件ルールを適用する。コンテキスト、コンテキストに関連付けられた条件およびルールならびに条件は、後により詳細に説明される。

後により詳細に説明されるように、プロパティは異なるコンテキストごとに変化するが、特定のタイプの各要素は一般的に同一のフォーマットプロパティを有する。例えば、“パラ”要素であると識別された一連のテキストは、“１タブスペースを常にインデントする；要素の終わりで改段落；１２ポイントのＴｉｍｅ Ｎｅｗ Ｒｏｍａｎフォント”等の単純なフォーマットルールを有してもよい。フォーマットルールは、その後に適用される特定のフォーマットルールが存在しなくなると、要素がどのように表示されるかを定義する。

図３から図１１は、フォーマットされるプロパティを示すスクリーンショットである。図３は、フォント、サイズ、太字、斜体、色、影付け、全大文字化、スモールキャピタル、上／下付き、下線、取り消し線等のフォントプロパティを編集するための、フォントダイアログボックス３０を示す。図４は、位置合わせ、一行目インデント、左、右等のインデントプロパティを編集するための、インデントダイアログボックス４０を示す。図５は、行間隔、前間隔、後間隔等のスペースプロパティを編集するための、スペースダイアログボックス５０を示す。図６は、構造型、カラム、ハイフネーション等のブレークプロパティを編集するための、ブレークダイアログボックス６０を示す。図７は、ページ先頭を維持するための行数や、ページ下部とコンテンツが分かれないように維持するための行数ないずれのアドバンストブレークプロパティを編集するための、図６のブレークダイアログボックス６０を介してアクセス可能なアドバンストブレークプロパティダイアログボックス７０を示す。図８は、要素の前に付加されるべきテキストや、要素の後に付加されるべきテキストないずれのｇｅｎｔｅｘｔテキストプロパティを編集するための、ｇｅｎｔｅｘｔ（自動生成テキスト）ダイアログボックス８０を示す。

図９はマルチパーパススタイルシート（利用可能プロパティセット９２）内のプロパティセットおよびカレントオブジェクトによって参照されるプロパティセット（利用済プロパティセット９４）を示すセットダイアログボックス９０を示す。記述フィールド９６は選択されたプロパティセットの記述を表示する。図１０はプロパティセットを編集するための、ダイアログボックス１５０を示す。図１１は、新たなプロパティセットを付加するためのダイアログボックス１６０を示す。

本発明のプロセスによれば、スタイルアーキタイプを用いることにより、ユーザインターフェースの変化／動作を生成することができる。スタイルアーキタイプの識別、作成および使用は、複数のフォーマットでのコンテンツの出力をさらに自動化する。各スタイルアーキタイプはスタイルシートの他の領域におけるプロセス動作を決定する。スタイルシート内において、定義された一連のフォーマットルールを有するスタイルアーキタイプは、タグに基づく各要素に割り当てられる。例えば、図２に示されるように、割り当てられるスタイルアーキタイプは“タイトル”、“表”等であってもよい。スタイルアーキタイプ割り当ての使用は、フォーマットおよびその他の要素のスタイル割り当ての使用に影響を及ぼす。スタイルアーキタイプは、目次、インデックス、黒丸付きもしくは番号付きリスト、ハイパーリンク等の、共通のパブリッシング構築の処理に用いられるモデルもしくはプロトタイプである。特定のスタイルアーキタイプのインスタンスとしての入力要素の識別は、特定のアーキタイプに共通のデフォルトのフォーマット特性を自動的に適用してもよく、追加の出力フォーマットアプリケーションにおける入力要素の使用に影響を及ぼしてもよく、スタイルアーキタイプに割り当てられた他の要素の出力に影響を及ぼしてもよい。

図１２に示されるように、各スタイルアーキタイプ２６に関連付けられているのは、フォント、インデント、スペース、ブレーク、ｇｅｎｔｅｘｔ、およびセット等のフォーマットオプションである。もちろん、その他のフォーマットオプションが各スタイルアーキタイプに関連付けられてもよい。図２を参照して説明されるように、各エレメントにはスタイルアーキタイプが割り当てられており、関連付けられたフォーマットルールおよびオプションを要素に割り当てる。３入力要素の例を用いる。入力要素をディビジョンとして識別し、ディビジョンの始まる前と、ディビジョンの終わった後の、強制改行や強制改ページのデフォルトフォーマットを適用する；その他の要素をタイトルアーキタイプとして識別し、改行と太字フォントを適用する；第三の要素を目次アーキタイプとして識別し、ベーシックアウトラインフォーマットを適用し、自動的にもしくはユーザの選択によって、目次の出力への入力としてディビジョンのタイトルの含有もしくは排除を可能にする。スタイルアーキタイプが決定されれば、異なるユーザもしくは異なる出力メディアに特化した動作を作成するために修正もしくは延長されることができる。例えば、印刷されたドキュメントの従来型の目次はウェブブラウザ上やＰＤＡの場合とは全く異なるフォームで表されるであろう。スタイルアーキタイプは特定の要素がドキュメント内でどのようにフォーマットされるかという点に関して、その特定の要素の目的を獲得する。例えば、ディビジョンおよびフォーマルブロック内のタイトルは、ドキュメント内の位置に特定のフォーマットを持っているとして識別されてもよいが、それは目次、図のリスト、表のリストに出現することもある。ドキュメント内の各要素もしくは要素グループはスタイルアーキタイプに割り当て、関連付けられているフォーマットルールおよびオプションを、要素に割り当てることができる。

割り当てられたスタイル特性は出力に基づくものでもよい。ベースライン特性は出力固有のオーバーライドが特定の特徴を割り当てない限り、全ての出力に割り当てられる。出力固有のオーバーライドは編集特性でもよい（例えば、Ｅｐｉｃ Ｅｄｉｔｏｒ、Ｃｏｎｔｒｉｂｕｔｏｒ （ウェブ編集）、Ｃｏｍｐａｎｉｏｎ （Ｗｏｒｄ ２００３編集等）。一方、出力特性オーバーライドはパブリッシング特性であってもよい（例えば、ＨＴＭＬファイル（フラットファイル）、ＨＴＭＬ Ｈｅｌｐ（ＭＳ ヘルプコンパイラ）、ウェブ（多くのＨＴＭＬファイル、インデックスおよびＴＯＣのフォルダ）、プリント／ＰＤＦ）。要素のフォーマットルールは要素と直接関連付けられなくてもよいが、後に詳細に説明するように、要素コンテキストに関連付けられる。加えて、各要素は“デフォルトコンテキスト”を有してもよい。各要素のデフォルトコンテキストは同一のもので、要素のベースフォーマットルールを有する。

さらに、スタイル特性は単独の出力ターゲットもしくは出力の組み合わせに割り当てられてもよい。図１５は、スタイル特性を割り当てるための出力の組み合わせを作成するための編集ユース／出力リストダイアログボックス１８０のスクリーンショットを示す。図に示されているように、出力の組み合わせはＣｏｍｐａｎｉｏｎとＣｏｎｔｒｉｂｕｔｏｒである。この組み合わせは出力が最終的にＣｏｍｐａｎｉｏｎでもＣｏｎｔｒｉｂｕｔｏｒでも、要素に割り当てられる同じスタイル特性を可能とする。もちろん、いかなる出力の組み合わせが選択されてもよい。この機能はユーザをしてプロパティが全体として同じである出力を組み合わせることを可能にする。出力が組み合わされている場合、それらは後に分離されることができるので、１つの出力に特有の変更ができる。出力が組み合わされている時、なされた変更は各出力になされる。さらに、ユーザはそれぞれ自身の出力を定義し、その出力を出力リスト１８２に加えることができる
実施形態においては、各要素は常にスタイルに割り当てられる。代替例においては複数のスタイルに要素をマッピングすることができるが一般的に、要素はただ１つのスタイルのみにマッピングされる。このような実施形態においては、潜在的に衝突するフォーマットルールが生じる。このような衝突はスタイルルールの最も具体的な一連のスタイルルールを適用し、要素コンテキストに基づく最も適切なスタイルルールを決定し、もしくはフォーマットルール衝突を解消するために設計されたユーザ実行基準を適用することで解決される（下により詳細に説明される図１の操作１３０において）。

前述のように、ユーザは所与のスタイルに関連付けられたフォーマットルールを修正することができる。ユーザがあるスタイルのフォーマットルールを修正する場合、そのスタイルに関連付けられた全ての要素は適切に更新される。

図１の説明に戻ると、操作１１０において、本発明は各要素が出力に現れるところの多様なコンテキストを決定する。コンテキストは、要素セレクタと上記セレクタにマッチする要素に用いられるフォーマットプロパティの組み合わせによって定義される。一方、“コンテキスト”は要素セレクタのみを参照することもできる。コンテキストは一般的にＸＳＬスタイルシートによるテンプレートおよびフォーマット出力指定インスタンス（ＦＯＳＩ）スタイルシートによるコンテキスト内要素と密接に対応する。

フォーマットルールは、所与のコンテキストへの適切なフォーマットルールセットが、要素固有のフォーマットルールと衝突することなく要素に適用されることを確保するために、一般的に要素よりもコンテキストに関連付けられている。コンテキストは、入力ファイル内の要素（“要素セレクタ”）の位置によって変化する。一般的に、ＸＭＬ入力ファイルを参考にして、要素はサブ要素内にネストされてもよい。例えば、“タイトル”要素は“ブック”要素、“チャプター”要素、“アブストラクト”要素、“図”要素その他の中に位置する。これらの各組み合わせは、タイトル要素に対する異なる要素セレクタであり、従って、それぞれが異なる一連のフォーマットルールを有する。

図２を参照すると、“タイトル”要素は位置２３に示される。タイトル要素２３の後に記載されているのは、例えば“セクション内タイトル”、“付録内タイトル”、“図内タイトル”、“項目内タイトル”等を含む、この要素に対する各コンテキスト２４である。要素タイトルを選択することは、それに従って現れる各コンテキスト内のタイトルを選択することであり、適用されるプロパティは全てのコンテキストのタイトルに適用される。しかしコンテキストを１つ選択することで、プロパティはそのコンテキスト内のタイトルのみに適用される。

図１の操作１１５において要素のコンテキストが決定されれば、スタイルシートはこれらコンテキスト固有のフォーマットルールを各要素に適用する。従って、タイトルが表示されているところのスタイルはタイトル要素のコンテキストに依存しているので変化する。例えば、ブックコンテキスト内のタイトル要素は２４ポイントのフォントで中央揃えで表示され、同時に図コンテキストのタイトル要素は太字の青字で１０ポイントのフォントで右揃えで表示されてもよい。従って、要素に適用されるコンテキストルールは、各コンテキストを基準ごとに決定される。

複数のコンテキストが単独の要素に適用される場合、最も具体的なコンテキストフォーマットルールのみが適用される。従って、図１の操作１３０ではフォーマットルールが解決される。上記の例に戻ると、入れ替わりでブック要素内に位置するところの、アブストラクト要素内のタイトル要素は、２つの有効なコンテキストを有する。“アブストラクト内タイトル”と“ブック内タイトル”である（これらのコンテキストは例示のために挙げられただけである）。タイトル要素は、即座にアブストラクト内にネストされる。それに対して、タイトルはブック内に位置するが、そこには少なくとも１つの介在要素、すなわちアブストラクトがある。従ってこの例においては、“アブストラクト内タイトル”フォーマットルールはより具体的であるので、適用される。“ブック内タイトル”フォーマットルールは適用されない。

従って、本発明に基づいて、フォーマットプロパティは要素に対して特定される。要素は、各ドキュメント内の全ての要素の発現に適用する一連のフォーマットプロパティの１つを有してもよいし、異なるコンテキスト毎に異なるプロパティを特定してもよい。要素の所与の発現に対しては１つのコンテキストのみが用いられる。

具体的な実施形態において、コンテキストはＦＯＳＩｓのｅｉｃｓにマッピングされる。コンテキストは一般的に、コンテキストを用いてスタンダードなｅｉｃｓとしてＦＯＳＩｓに翻訳され、属性を有するように構成される。ＸＳＬにおいて、コンテキストはＸＳＬ：テンプレート要素一致属性として実施される。出力固有プロパティは、異なるオプションのための、スタイラを放出する異なるＸＳＬによって処理される。

ある状況下において、属性テストに基づいて、同一のコンテキストに用いられる異なるフォーマットプロパティを有することが望ましい。このために、本発明はコンテキストに“条件”を関連付けることを可能にする。条件は、一連の属性テストおよび一連のフォーマットプロパティを含む。全てのテストがｔｒｕｅである場合（もしくは一連の特定のテストがｔｒｕｅである場合）、プロパティはコンテキストによって特定されたプロパティをオーバーレイする。

図１の操作１２０において、本実施形態は条件に基づいたフォーマットルールを要素に適用する。“条件”とはここでは、少なくとも１つの属性テストに加えて少なくとも１つのフォーマットルールを言及するものである。上述のように、属性テストの結果が適合していれば、フォーマットルールが適用される。

図１６は新しい条件を作成するダイアログボックス１９０のスクリーンショットである。示される条件ダイアログボックス１９０は、要素−＞新しい条件メニュー項目もしくは要素リストのコンテキストメニューにおいて開始する。図１６はユーザがｎｅｗをクリックするかテストを選択して編集するためにクリックすることで現れるダイアログボックス１９０を示す。

条件には２つの部分があり、条件がｔｒｕｅであるかどうかを決定するテストと、条件がｔｒｕｅの場合にコンテキストのフォーマットプロパティにオーバーレイされるフォーマットプロパティである。ユーザによって、マルチパーパススタイルシートに属性テストが追加されてもよい。図１７は新しい条件に属性テストを割り当てるダイアログボックス２００のスクリーンショットである。単独の条件は、それに関連付けられる複数の属性テストを有してもよい。この場合ユーザは、関連付けられたフォーマットルールを適用するためには、全ての属性テストが適合していなければならないのか、もしくは単独のテストだけが適合すればよいのかという条件をいつ作成するのかを特定してもよい。ブール項においては、ユーザは属性テストが“ＡＮＤ”もしくは“ＯＲ”スタイルのテストであるかどうかを特定することができる。

条件は全ての出力に当てはまる。しかし、ユーザは条件がｔｒｕｅであった場合に適用される、出力固有のフォーマットプロパティを特定することができる。例えばユーザは、属性をテストするための条件を追加し、条件のためのフォーマットプロパティにおいてリストを編集するためのプロパティ内の特定の出力（例えばＨＴＭＬファイル）を選択し、オーバーレイされるプロパティを特定することができる。このような条件は選択された出力にのみ影響を及ぼすことになる。同様にユーザは、属性をテストする条件を追加し、条件のためのフォーマットプロパティにおいて異なる出力に異なる設定をすることができる。

一般的に、条件はコンテキストによって変化する。コンテキストと異なり、複数の条件フォーマットルールが単独の要素に適用されてもよい。要素が複数の適応可能な条件を有する場合、適合する各条件のフォーマットルールは要素に適用される。ユーザは条件テストの順序を特定することができる。一番目の条件がまずチェックされ、次いで二番目、それ以降、となる。

複数の条件がフォーマットルールを単独の要素に適用してもよいが、２つ以上の条件が、相反するフォーマットルールを適用しようとすることがある。適用された異なる条件のフォーマットルールが対立する場合、ユーザ固有の順序で後にくる条件が、この順序で先にくる条件の対立するフォーマットルールをオーバーレイする。一方、本発明はいずれのフォーマットルールを適用するかをランダムに選択する。再び、図１の操作１３０において、フォーマットルールの対立が解消される。

より具体的なコンテキストフォーマットルールが、具体性の低いフォーマットルールに優先するのであるが、これはクラスベースもしくは出力ベースのルールに必ずしも当てはまるわけではない。例えば、特定のファイルフォーマットにおいて、特定のクラスのユーザに見られるために特定の表示装置への出力ファイルにスタイル付けされる入力ファイルは、これら適用される３組の出力フォーマットルール（すなわち、クラス、出力およびファイルのフォーマットルール）全てを有してもよい。複数のフォーマットルール（例えば、クラス、出力、および／もしくはファイルのフォーマットルール）がお互いに相反する場合、ユーザはスタイルシート作成の間、このような衝突を解消することができる。あるいは、本発明はあるルールセットを支配的なフォーマットルールセットとして選択することができる。この場合、ユーザは選択を指示するプロンプトもしくは警告を受ける場合がある。

コンテキストや条件を用いてユーザは、全てのクラスおよびドキュメントに関してＥｐｉｃ ｅｄｉｔｏｒと同様に、印刷物やウェブページにおいて所望の外見を作り出す正確な“ルールベースフォーマット”を特定することができる。プロパティセットはマルチパーパススタイルシートのメンテナンスを単純化するために用いられてもよい。プロパティセットダイアログボックスは図９、１０および１１に示されている。図９は使用可能なプロパティセット９２のリストからプロパティセットを適用するためのダイアログボックス９０を示す。図１０はプロパティセットを編集するためのダイアログボックス１５０、図１１は新しいプロパティセットを付加するためのダイアログボックス１６０を示す。プロパティセットは、特定のスタイルプロパティを有する、名付けられたセットである。例えば、１０の要素が１０ポイントの斜字体、赤字であるように設定されている場合、これらのスタイルプロパティを有するプロパティセットを作成することは有用である。従って、プロパティセットは１０ポイント、斜字体、赤字のスタイルプロパティと関連付けられたスタイルプロパティとともに警告フォントと呼ばれてもよい。スタイルプロパティを１０の要素に適用するために、警告フォントが各要素に適用される。プロパティセットを用いる優位な点は次のようである。もし後にこれら１０の要素全てを１１ポイントで斜字体の赤字にしたいと思った時は、ユーザは警告フォントのフォントサイズプロパティを変更するだけでよく、１０の要素全てに関して変更する必要はない。

本発明は、ユーザが所与の出力のコンテキストおよび／もしくは条件における所与の要素に対するソーススタイルシートコードを編集することを可能にする。より具体的には、ソフトウェアはユーザがＸＳＬ等のスタイルシート言語固有のコードを特定の出力に書き込むことを可能にする。カスタムスタイルシートコードは．ｓｔｙｌｅファイルに格納されている。ソフトウェアの将来の使用の間、カスタムスタイルシートコードは管理、再利用されてもよい。さらに、カスタムスタイルシートコードの複数のスタイルシートでの使用を許可する．ｓｔｙｌｅファイル外部のライブラリが与えられてもよい。カスタムスタイルシートコード（例えばｊａｖａｓｃｒｉｐｔを含む）は図１のブロック１３５におけるように追加される。マルチパーパススタイルシートの出力結果は、カスタムスタイルシートコードと同様に、マルチパーパススタイルシートのフォーマット特性を含む（開発者によって削除／修正されていない限り）。

本発明の処理はさらに開発者による他の全ての要素／コンテキスト／出力のスタイラコントロールを保持しながらの、特定の要素／コンテキストおよび出力のカスタマイズを可能にする。マルチパーパススタイルシートはフォーマットを超えた広範なカスタマイズを可能にする。要素ソースを編集することは、マルチパーパススタイルシートによって他の全ての要素および出力が修正されることを可能にしながら、開発者が追加の性能を提示することを可能にする。図１３に示されるように、要素ソースを編集するために要素ソースは識別される（例えば、ＸＳＬ−ＨＴＭＬファイル、ＸＳＬ−ＦＯ、ＸＳＬ−ＨＴＭＬヘルプＸＳＬウェブ、ＸＳＬコントリビュータもしくはＦＯＳＩ）。ＸＳＬ−ＨＴＭＬファイルソースを編集する例は図１４に示されている。図１４では、ＨＴＭＬファイル出力の“コピーライト”要素１７０が編集されている。

図１８は特定の出力にエクスポートするユーザオプションを示すダイアログボックス２００を示す。マルチパーパススタイルシート（単独の．ｓｔｙｌｅファイル）に基づいて、複数の、ターゲット指定のスタイルシート言語がエクスポートされてもよい。従って、単独のユーザインターフェースおよび単独の．ｓｔｙｌｅファイルは出力、例えば、フラットなＨＴＭＬファイルのＸＳＬＴ、ＭＳ ＨＴＭＬヘルプファイルのＸＳＬＴ、ウェブ出力のＸＳＬＴ、プリント出力のＸＳＬ−ＦＯ、プリントおよびＥｐｉｃ Ｅｄｉｔｏｒにおける編集のためのＦＯＳＩ（ＳＧＭＬフォーマットのＤＯＤスタンダード）、コントリビュータにおける編集のためのＸＳＬＴ、コンパニオン（ＭＳ Ｗｏｒｄ２００３へのアドイン）における編集のための．ｗｓｔｙｌｅやその他の出力に用いられてもよい。列記された出力は例示のためであり、これらに限定されるものではない。

最後に、出力スタイリングプロセスは保存操作等の終了操作１４０で終了する。

上記の操作は特定の順序で並べられたが、本発明の実施形態はある操作を省略したり、他の操作を追加したり、および／もしくは操作の実行順序を変更したりしてもよい。例えば、リンクはスタイルの適用に先立って決定され管理されてもよく、ユーザベースのフォーマットルールが出力ベースのフォーマットルールより先に適用されてもよい。従って、上記操作は、本発明の単独の実施形態の操作方法を例示するためのものであり、全ての実施形態を限定するものではない。

一般的に、上記のスタイリング手順は本発明によってマルチパーパススタイルシートを入力ファイルに適用することで実行される。マルチパーパススタイルシートは、入力ファイルで作動する複数のフォーマットルール、条件、コンテキスト、スタイルその他を含む。マルチパーパススタイルシートコンテンツはユーザ指定であっても実施形態によるデフォルト指定であってもよい。

ユーザは本発明の実施形態に関係するグラフィカルユーザインターフェース（ＧＵＩ）の使用を介して、本発明に従ってマルチパーパススタイルシートを作成、編集、もしくは修正することができる。ＧＵＩレイヤはシングルドキュメントインターフェース（ＳＤＩ）をメインウィンドウに用いることができる。通常、ＳＤＩアプリケーションは、メインフレームウィンドウ（ＣＦｒａｍｅＷｎｄ）、ツールバー（ＣｔｏｏｌＢａｒ）、図（ＣＶｉｅｗ）、および下部のステータスバー（ＣｓｔａｔｕｓＢａｒ）の４つの視覚オブジェクトを含む。図２、１２および１３に示される実施形態において、スタイラのメインウィンドウベースクラスであるＳｔｙｌｅｒＦｒａｍＷｎｄはＭＦＣ ＣｆｒａｍｅＷｎｄｃｌａｓｓから派生している。従って、図に示されるように、スタイラは３つの分割ダイアログウィンドウを含む。分割ウィンドウ、ＳｔｙｌｅｒＴｒｅｅＶｉｅｗ２１０、ＳｔｙｌｅｒＤｅｓｃｒｉｐｔｉｏｎ Ｖｉｅｗ ２１２、およびＳｔｙｌｅｒＰｒｏｐＶｉｅｗ ２１４はＭＦＣのＣｆｏｒｍＶｉｅｗｃｌａｓｓのサブクラスであるＳｔｙｌｅｒＶｉｅｗから派生している。

ＳｔｙｌｅｒＴｒｅｅＶｉｅｗ２１０は要素２２およびスタイラ２６ツリーコントロールが表示される上部分割ウィンドウを表示する。ＳｔｙｌｅｒＤｅｓｃｒｉｐｔｉｏｎＶｉｅｗ２１２は記述テキストが表示される中央分割ウィンドウを表示する。典型的に、ＳｔｙｌｅｒＤｅｓｃｒｉｐｉｔｉｏｎＶｉｅｗ２１２に表示される情報は、上部ツリーコントロールで現在選択されている項目の読み取り専用テキスト記述情報である。ＳｔｙｌｅｒＰｒｏｐＶｉｅｗ２１４はプロパティが表示される下部分割ウィンドウを表示する。ＳｔｙｌｅｒＰｒｏｐＶｉｅｗ２１４は、上部ツリーコントロールにおいて選択された項目に関連付けられたプロパティの表示および修正を管理する。上部、中央、下部が参照されるが、これらはもちろん例示のために示されたもので、限定するものではない。

使用中、ユーザは項目（例えば、要素、コンテキスト、もしくは条件）を上部ビュー、ＳｔｙｌｅｒＴｒｅｅＶｉｅｗ２１０のツリーコントロールにおいて選択する。現在下部ビューのＳｔｈｌｅｒＰｒｏｐＶｉｅｗ２１４に表示されているタブページは、選択されたツリーコントロール項目に適用される解決値を示す。ユーザはドロップダウンの中から新しい値を選択することで、もしくは編集ボックスに手入力することで、値を変更してもよい。

要素が示されると、編集するプロパティのドロップダウンリスト２１６がプロパティタブ上に見えるようになる。プロパティセットが示されたとき、このコントロールは消滅する。図２に示される実施形態において、リスト２１６はまず＜このリストを編集する＞、ベース（全ての出力）、Ｅｐｉｃ Ｅｄｉｔｏｒ、ＨＴＭＬファイル、ＨＴＭＬヘルプ、プリント／ＰＤＦ、ウェブ、Ｗｏｒｄ ＸＭＬおよびＥ３ Ｅｄｉｔｏｒを含む。ベース（全ての出力）は一般的にデフォルトで選択される。ベース（全ての出力）が選択されると、ユーザはプロパティタブ内の共通セッティングを見て、変更されたプロパティは全ての出力のベースセッティングとして適用される。異なる出力が選択された場合、選択された出力に対する異なるセッティングがない限りユーザはやはり共通セッティングを観察する。異なるセッティングがあるときにはそのセッティングが示される。

ユーザが初めて本発明にかかるマルチパーパススタイルシートを作成するとき、要素は“アンスタイルド”のスタイルを割り当てられる。新しいマルチパーパススタイルシートを作成する第一段階は、要素を“ディビジョン”、“タイトル”、“番号付きリスト”、“リスト項目”、“パラグラフ”等の“スタイル”にマップすることである。これらのマッピングを用いて、スタイラはいずれのコンテキストが要素に作成されるべきかを知り、またデフォルトのプロパティを割り当てることができる。単純に全ての要素を正しいスタイルにマップすることで、大変有効なスタイルシートが短時間で作成される。“スタイル”に要素をマップすることはエディタでスタイル付けされるべき要素を選択してクリックするだけで行われる。ユーザはドキュメントの冒頭で始めて終わりまで続けてもよいし、いくつかのセクションを飛ばして、後で戻ってきてもよい。一般的に、取り組むセクションの全てのアンセスタをスタイル付けするのが有効である。

そこでユーザは、要素ベースでフォーマットプロパティを微調整してもよい。この状態においては、ユーザは各要素を拡張したり特定のコンテキストを選択したりせず、その代わりに失われた要素を選択し、全てのコンテキストに当てはまる変更を行う。ユーザはそこでコンテキストに特有のフォーマットプロパティを選択するための特定のコンテキストを選択してもよい。さらに、ユーザは多様なコンテキストに条件を追加してもよい。ユーザは異なる出力の結果をプレビューし、結果に満足するまで修正を続けてもよい。

そこでユーザはマルチパーパススタイルシートを．ｓｔｙｌｅファイルとして保存する。将来の使用のために、ユーザがこのドキュメントタイプのドキュメントを編集するときには、保存された．ｓｔｙｌｅファイルがマルチパーパススタイルシートとして特定されたドキュメントを出力するために用いられる。

スタイラユーザインターフェースはとりわけＷｉｎｄｏｗｓ（登録商標）プラットフォームに適している。しかし、スタイラマルチパーパススタイルシートはエディタ表示や、Ｕｎｉｘ（登録商標）やその他の適したプラットフォームの作成においても用いられる。

図１９は本発明におけるスタイルシートエディタ（スタイラ）の実施形態のアーキテクチャ２３０を示す。示されるアーキテクチャはマルチパーパススタイルシートエディタに好適なアーキテクチャを例示するためのものであり、発明を限定するものではない。スタイルシートデータのセントラル・レポジトリはＸＭＬドキュメント２３２（．ｓｔｙｌｅ）である。ソフトウェアデザインはスタイルシートドキュメント２３２からのデータの読み取りおよびスタイルシートドキュメント２３２へのデータの書き入れに基づいている。ユーザインターフェース（ＧＵＩレイヤ２３４）はＸＭＬドキュメント２３０と、ドキュメントオブジェクトモデル（ＤＯＭドキュメント）のインターフェースとしての役目を果たす一連のｐｏｒｔａｂｌｅ Ｃ＋＋クラス（ポータブルレイヤ２３６）を介して連絡している。エクスポート操作２３８は、ＡＣＬもしくはＡＯＭを用いた同一のドキュメント２１２に連絡している。

Ｗｉｎｄｏｗｓ（登録商標）システムにおいて、ポータブルレイヤ２３６およびＧＵＩレイヤ２３４はライブラリを作成する。Ｕｎｉｘ（登録商標）システムにおいて、ポータブルレイヤ２３６はライブラリを作成する。一般的に、ライブラリはＥｐｉｃ経由でアクセス可能であるのと同様、スタンドアロンでもある。

示されるスタイラアーキテクチャ２３０はポータブルレイヤ２３６がＧＵＩレイヤ２３４から識別され分離されるように設計される。スタイラアーキテクチャ２３０は複数のウインドウシステムのサポートを容易にする。ポータブルレイヤ２３６はＵｎｉｘ（登録商標）のシェアードオブジェクト（ｓｔｙｌｅｒ．ｓｏ）として、もしくはその他適するものとしてＷｉｎｄｏｗｓ（登録商標）のスタンドアロンＤＬＬ（ｓｔｙｌｅｒ．ｄｌｌ）に属する。ポータブルレイヤ２３６のソースファイルは一般的な用途のＣ＋＋クラスを有する。図２０、２１、２２および２３は本発明で用いるクラス例を示す。

図２０はベースクラスおよびスタイルシートレベルクラスを示す。ベースクラスとは一般的に、全てが純粋にバーチャル機能である抽象的なクラスではないが、根拠のないクラスである。ＩＳｔｙｌｅｓｈｅｅｔクラスはスタイラアプリケーションを制御するメインＸＭＬファイルを表すＩＥｌｅｍｅｎｔＢａｓｅサブクラスである。これはシステム内にスタイラｄｏｃｔｙｐｅを用いるＸＭＬファイルとして存在する。これは“スタイラ”と呼ばれるｄｏｃｔｙｐｅ要素として存続する。

図２１はＩＥｌｅｍｅｎｔＮｏｄｅサブクラスを示す。ＩＥｌｅｍｅｎｔＮｏｄｅＢａｓｅクラスはＩＥｌｅｍｅｎｔＢａｓｅから派生し、ＧＵＩレイヤのツリーコンテキスト内のノードである要素オブジェクトを表す。これらのクラスは要素、コンテキストおよび条件（以下に説明される）に当てはまる。これはアブストラクトベースのクラスで、スタイラのメインツリーコントロール内のオブジェクトによってシェアされるＲｅｓｏｌｖｅ Ｍｅｔｈｏｄ等の基礎的な方法を提供する。ＩＥｌｅｍｅｎｔクラスはＩＥｌｅｍｅｎｔＮｏｄｅＢａｓｅのサブクラスである。ＧＵＩクラスとエクスポートクラスのいずれもが、ＩＥｌｅｍｅｎｔオブジェクトをスタイラＧＵＩクラスとスタイラｄｏｃの間（典型的にはＤＯＭもしくは／またはＡＣＬ）との間のインターフェースとして用いる。これはマルチパーパススタイルシート内にその名前属性がユーザのドキュメントおよびｄｏｃｔｙｐｅにおける要素の名前を特定するエレメント要素として存続する。それはＩＣｏｎｔｅｘｔオブジェクトのリストを有してもよい。

図２２はプロパティ関連のクラスを示す。ＩＰｒｏｐｅｒｉｅｄＢａｓｅクラスは、ＢａｓｅＰｒｏｐｅｒｔｉｅｓを含む要素としてスタイラＤＴＤに表されるオブジェクトのＩＥｌｅｍｅｎｔＮｏｄｅＢａｓｅのサブクラスである。これは要素ベースオブジェクトのアブストラクトベースクラスであり、基礎的方法とＢａｓｅＰｒｏｐｅｒｔｉｅｓ要素を含む要素に特有のプロパティを提供する。ＩＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｄＢａｓｅクラスはＳｔｙｌｅｒＤＴＤでＢａｓｅＰｒｏｐｅｒｔｉｅｓおよびＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓのリストを有する要素として表されるオブジェクトのＩＰｒｏｐｅｒｔｉｅｄＢａｓｅのサブクラスである。これは要素ベースオブジェクトのアブストラクトベースクラスであり、基礎的方法とＢａｓｅＰｒｏｐｅｒｔｉｅｓ要素およびＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓ要素の両方を有する要素に特有のプロパティを提供する。

ＩＣｏｎｔｅｘｔクラスはＩＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｄＢａｓｅのサブクラスである。ＧＵＩクラスとエクスポートクラスはＩｃｏｎｔｅｘｔｏｂｊｅｃｔをスタイラＧＵＩクラスとｓｔｙｌｅｒ ｄｏｃ（典型的にＤＯＭおよび／もしくはＡＣＬ）の間のインターフェースとして用いる。これはスタイルシートにおいて、セレクタ属性が子プロパティが当てはまるＸＭＬコンテキストを特定したコンテキスト要素として存続する。これはＩＣｏｎｄｉｔｉｏｎオブジェクトのリストを有していてもよい。これはＤＴＤ内にＢａｓｅＰｒｏｐｅｒｔｉｅｓおよびＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓとして表される２つのＩＰｒｏｐｅｒｔｉｅｓオブジェクトを有する。
ＩＣｏｎｄｉｔｉｏｎクラスはＩＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｄＢａｓｅのサブクラスである。ＧＵＩクラスおよびエクスポートクラスはＩＣｏｎｄｉｔｉｏｎオブジェクトをスタイラＧＵＩクラスとｓｔｙｌｅｒｄｏｃ（典型的にＤＯＭおよび／もしくはＡＣＬ）の間のインターフェースとして用いる。これはマルチパーパススタイルシートにＡｔｔｒｉｂｕｔｅＴｅｘｔ要素およびＸＰａｔｈＴｅｓｔ要素が、子プロパティが適用されるコンテキストをさらに定義し純化するＸＭＬ条件を特定する条件要素として存続する。これはＤＴＤにおいてＩＰｒｏｐｅｒｔｉｅｓオブジェクトとＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓとして表される２つのＩＰｒｏｐｅｒｔｉｅｓオブジェクトを有する。

図２３はＩＰｒｏｐｅｒｔｙＥｌｅｍｅｎｔＢａｓｅサブクラスを示す。このクラスはＤＴＤ要素である単独のスタイラプロパティオブジェクトのアブストラクトベースクラスを表す。ポータブルレイヤオブジェクトとして、これらは特定のスタイルプロパティであるところの特定の属性リストのコンテナとして存在する。ＧＵＩに対しては、典型的にコントロール内に存在する属性のコンテナとして存在する。

ユーザはマルチパーパススタイルシートのコンテンツをカスタム値、要素、スタイル、コンテキストおよび条件を含むように修正してもよい。

ポータブルレイヤ２３６はＧＵＩレイヤの多様なダイアログにおける表示もしくは操作のためのデータを取り出し、および／もしくは送信するために、ＤＯＭと連絡している。ＧＵＩレイヤ２３４はポータブルレイヤのＩＳｔｙｌｅｓｈｅｅｔへのポインタを含み、ポータブルレイヤの機能への各ビューアクセスを可能にしている。これらの機能へのダイレクトアクセスは、ＧＵＩレイヤ２３４の制御で用いられるデータの集団とメンテナンスを容易にする。スタイラアーキテクチャ２３０はＷｉｎｄｏｗｓ（登録商標）以外のプラットフォームで機能するスタイラのポータブルな機能性を可能にする。

特定の実施形態におけるマルチパーパススタイルシートエディタは、複数の言語をサポートするＵｎｉｃｏｄｅアプリケーションである。特定の実施形態において、スタイラは１６ビットとしてのみコンパイルされている（ａ＿ＵＮＩＣＯＤＥコンパイル設定を介して）。この実施形態において、ポータブルレイヤ２３６はもっぱらＤＯＭ文字列（１６ビット）のみを用いる。この実施形態においても、ＧＵＩレイヤ２３４はＭＦＣ制御および／もしくはクラスに要求された場合、文字列操作のためにＴＣＨＡＲおよびＣ文字列を用いる。もちろん他の設定および／もしくは文字列も好適に用いられてもよい。

スタイラを用いた入力ファイルの出力ファイルへの変換は、オプションの中でとりわけ、コンテキスト指定、出力装置指定、あるいはユーザ指定のフォーマットを決定することを含んでもよい。つまり、本発明におけるマルチパーパススタイルシートは、出力ファイルのフォーマットもしくはスタイルを、出力ソースもしくは装置、出力ファイルフォーマット、入力もしくは入力ファイルを含む階層構造内のいずれかに含まれるデータもしくはファイルのコンテキストによって、もしくは、出力ファイルもしくは出力ファイルが意図しているところのものにアクセスするユーザによって変更してもよい。

フォーマットプロパティ（“プロパティ”）は、ＰｒｏｐｅｒｔｙＥｌｅｍｅｎｔｓ実体内で定義される要素の属性値によって表されるスタイル設定である。これら要素はＢａｓｅＰｒｏｐｅｒｔｉｅｓ要素およびＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓ要素の子要素である。ＢａｓｅＰｒｏｐｅｒｔｉｅｓ要素はコンテキスト、条件およびＰｒｏｐｅｒｔｙＳｅｔの子要素である。ＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓ要素はコンテキストおよび条件の子要素である。

コンテキストおよび条件には、作成プロセスの間、まずベースプロパティが適用される。そして、もし出力属性が作成されようとする出力に一致するＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓ要素があれば、出力プロパティはオーバーレイされる。

ドキュメントのどれでも所与の要素は、作成は、いずれの一連のフォーマットプロパティを要素に適用するかという問題を解決するプロセスに従う。作成者はカレント要素のいずれのコンテキストが最も一致するかを、セレクタをドキュメント内で要素が生じる場所との比較することに基づいて決定する。コンテキストは要素に用いるプロパティを特定する。プロパティはコンテキスト要素の子要素を介して直接特定されてもよく、コンテキスト要素の子要素のリファレンスであるＰｒｏｐｅｒｔｙＳｅｔｓから派生してもよい。また、コンテキストはテストとプロパティを有する条件を含んでもよい。もし条件のテストがＴｒｕｅであれば、そのプロパティはコンテキストのプロパティとマージする。もちろん、条件のプロパティは条件要素の子要素を介して直接特定されてもよく、条件要素の子要素によって参照されるＰｒｏｐｅｒｔｙＳｅｔｓから派生してもよい。

エクステンシブル・マークアップ言語（ＸＭＬ）は構成データを記述するためのフォーマットを提供するメタ・マークアップ言語である。ＸＭＬはＷｅｂベースデータを格納し，観察し、操作するためのスタンダード言語であり、開かれたテキストベースのフォーマットで構成済みデータを記述し交換する一定の方法を提供する。ＸＭＬは情報コンテンツがそのコンテンツをレンダリング／表示するメカニズムから完全に分離されることを可能にする。表示指向のマークアップ言語であるＨＴＭＬと比較すると、ＸＭＬは表示するデータをどのようにフォーマットするかを説明する情報を含まず構成データを表示する、汎用言語である。

ＸＭＬはタグベースの言語であるという点で、ＨＴＭＬと同様である。そのタグベースである性質に基づいて、ＸＭＬは厳格なツリー構造もしくは階層を定義する。ＸＭＬは固有のデータおよびビジネスロジックを記述するためのカスタムタグの作成を可能にする。ＸＭＬ“要素”とは、スタートタグ、終了もしくはクローズタグ、これらタグ間に含まれる情報もしくはコンテンツからなる構造上の構成概念である。“スタートタグ”は“＜ｔａｇｎａｍｅ＞”としてフォーマットされ、“エンドタグ”は“＜／ｔａｇｎａｍｅ＞”としてフォーマットされる。ＸＭＬドキュメントにおいてスタートタグおよびエンドタグは他のスタートタグおよびエンドタグの中にネストされることができる。特定の要素に現れる全ての要素は、特定の要素のエンドタグの前に現れる、自身のスタートタグとエンドタグを有さなければならない。これは厳格なツリー状構造を定義する。各要素はそのツリーの中にノードを形成し、潜在的に“子”ノードもしくは“枝”ノードを有する。この子ノードは“親”ノードのスタートタグとエンドタグの間に現れるＸＭＬ要素を表す。

ＸＭＬスキーマはＸＭＬドキュメントの構成の記述である。より具体的には、ＸＭＬスキーマはＸＭＬベース言語を用いてＸＭＬドキュメントの制約を特定する方法である。典型的にＸＭＬスキーマはＸＳＬスキーマ定義言語（ＸＳＤ）で書かれており、ネームスペースおよびデータタイプをサポートする。スキーマはＸＭＬ上に設けられ階層をなしている。スキーマは一義的な仕様を簡単に作成することと、コメントが適用されようとする範囲を定義することとを可能にする。

各スキーマにおいて、要素の名前の“辞書”が定義される。スキーマによって定義される要素の名前の辞書は、“ネームスペース”として参照される。ＸＭＬドキュメントにおいて、要素の名前はネームスペース識別子によって制限される。ネームスペース識別子によって制限されると、タグネームは“［ｎａｍｅｓｐａｃｅ］：［ｔａｇｎａｍｅ］”の形で現れる。このモデルは同一の要素ネームが複数のスキーマもしくはネームスペースで現れることを可能にし、これら複製の要素ネームのインスタンスが同一のＸＭＬドキュメントに衝突することなく現れることを可能にする。スタートタグは、示される要素に関連付けられた“プロパティ値”を示す“属性”の任意の番号を示すことができる。属性は以下のフォームを用いてスタートタグ内に示される：
”＜［ｔａｇｎａｍｅ］［ａｔｔｒｉｂｕｔｅ１］［ａｔｔｒｉｂｕｔｅ２］．．．［ａｔｔｒｉｂｕｔｅＮ］＞”
ここで属性１から属性Ｎはタグ属性の任意の数字の表明である。各属性の表明は“［ａｔｔｒｉｂｕｔｅＮａｍｅ］＝［”ａｔｔｒｉｂｕｔｅＶａｌｕｅ”］”の形を取っており、ここで各属性は属性の引用された値に先立つ“＝”が後に続く一意の名前で識別される。

スタイラスキーマはいくつかの主要なセクションである、上位レベル要素、パラメータ実体の定義、ＳｔｙｌｅＳｈｅｅｔＩｎｆｏ、ＰｒｏｐｅｒｔｙＳｅｔｓ、要素、スタイル、ＰｒｉｎｔｅｄＰａｇｅＳｅｔｓ、ＴａｂｌｅＯｆＣｏｎｔｅｎｔｓ、ＲｅｆｅｒｅｎｃｅＦｏｒｍａｔｓ、およびＦｏｓｉＲｓｒｃＤｅｓｃＳｏｕｒｃｅを含む。

ＳｔｙｌｅＳｈｅｅｔＩｎｆｏはスタイルシートのメタ・データである。スキーマのスタイルシート情報セクションはスタイルシートメタ・データを含む。各スタイラファイル上部の“スタイルシート識別プロセス指示”は、Ａｒｂｏｒｔｅｘｔ Ｅｄｉｔｏｒのスタイルシートがどこにあっても、そこに何が表示されるかがリストされる“タイトル”と、スタイルシートがその出力を用いることができる“作成タイプ”とを特定する。情報を特定することで、データはスキーマの中に複製されない。ＳｔｙｌｅｒＶｅｒｓｉｏｎの属性はスタイラシートが作成された時、もしくは最後に更新された時のスタイラのバージョンを含む。ＣｕｒｒｅｎｔＶｅｒｓｉｏｎの属性は、スタイラの現在のバージョンを含む。ＳｔｙｌｅｒＶｅｒｓｉｏｎが＜ｃｕｒｒｅｎｔＶｅｒｓｉｏｎ＞である場合、スタイラはｓｔｙｌｅｒＶｅｒｓｉｏｎを必要であれば自動的に更新し、変更する。ＭｉｎｏｒＶｅｒｓｉｏｎおよびｃｕｒｒｅｎｔＭｉｎｏｒＶｅｒｓｉｏｎ属性は開発の間、内部スタイルシートを最新の状態に保つ。ＳｔｙｌｅＳｈｅｅＩｎｆｏ内の要素セットは、スタイルシートがいずれのドキュメントもしくはドキュメントタイプに用いられるかについて、何らの影響も及ぼさない。それらはスタイラユーザインターフェースが、ＵＩ内の適切な要素および属性をリストすることで簡単に編集できるようにする。

ＰｒｏｐｅｒｔｙＳｅｔｓは要素セクションの中からフォーマットプロパティ値をモジュール化するために参照されるビルディングブロックである。ＰｒｏｐｅｒｔｙＳｅｔはスタイルシート内の複数の場所（ｐｒｏｐｅｒｔｙＳｅｔＲｅｆｅｒｅｎｃｅｓ属性があるところであればどこでも）から参照できるプロパティのセットである。プロパティセットはスタイルシートがモジュールかされることを許可する。ＰｒｏｐｅｒｔｙＳｅｔｓは他のＰｒｏｐｅｒｔｙＳｅｔｓを参照することができる。

フォーマットプロパティ、もしくは略してプロパティは、ＰｒｏｐｅｒｔｙＥｌｅｍｅｎｔｓ実体によって定義された要素上の属性値によって表されるスタイル設定である。これら要素は“ＢａｓｅＰｒｏｐｅｒｔｉｅｓ”要素および“ＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓ”要素の子要素である。ＢａｓｅＰｒｏｐｅｒｔｉｅｓ要素は“コンテキスト”、“条件”および“ＰｒｏｐｅｒｔｙＳｅｔ”の子要素である。ＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓ要素は“コンテキスト”および“条件”の子要素である。コンテキストと条件には、作成プロセスの間、まずベースプロパティが適用され、その後、もし出力属性が作成される出力に一致するＯｕｔｐｕｔＰｒｏｐｅｒｔｉｅｓ要素があれば、出力プロパティはオーバーレイされる。ある特定のフォーマットプロパティは特定されるか設定されずに残されないままである。これは、プロパティを表す属性の存在に関わらず、スタイルシートファイルに表される。

ドキュメントの所与の要素について、作成は、一連のフォーマットプロパティのうちのいずれを要素に適用するかを解決するプロセスに従う。このプロセスとは以下の通りである。構成者が、現在の要素のいずれのコンテキストが最も一致するかを、ドキュメント内の要素が現れる場所とセレクタを比較することに基づいて決定する。コンテキストは要素に用いるためのプロパティを特定する。プロパティは、コンテキスト要素の子要素を介して直接特定されてもよく、コンテキスト要素の子要素によって参照されるＰｒｏｐｅｒｔｙＳｅｔｓから派生してもよい。また、コンテキストはテストおよびプロパティを有する条件を含むことができる。もしコンディションのテストがＴｒｕｅであれば、そのプロパティはコンテキストのプロパティとマージする。留意すべきは、条件のプロパティはまた、条件要素の子要素を介して直接特定されることもでき、条件要素の子要素によって参照されるＰｒｏｐｅｒｔｙＳｅｔｓから派生することもできることである。もしいずれのプロパティもこのマージの終わりでまだ設定されていなければ、次の２つのうちの１つがおこる：１．もしプロパティが“引き継がれる”ものであれば、プロパティはドキュメントインスタンスの親要素から引き継がれる、すなわち、親要素と同じものになる；２．もしプロパティが引き継がれないものであれば、スタイラによってデフォルト値を与えられる。

要素は最も一般的には所与のＤＴＤもしくはスキーマの全ての要素のためのルールを含む要素のためのフォーマットルールを含む。要素セクションはスタイルシートの中心である。要素のためのルールは出力固有のフォーマットプロパティを特定してもよく、要素コンテキスト、属性値等によって変化してもよい。要素はスタイルにマップされる。要素のスタイルは、いずれのコンテキストが各スタイルにまず作成され、これらコンテキストがいずれのプロパティをまず有するのかという、可能なスタイルを決定する。

いくつかの要素について、要素が現れるところのコンテキストによって異なるプロパティを用いるのが望ましい。従って、スタイラはフォーマットプロパティを直接要素に関連付けるよりはむしろ、要素“コンテキスト”に関連付ける。“コンテキスト”とは、スタイラ内で、要素セレクタと、そのセレクタに一致する要素に用いる一連のフォーマットプロパティとの組み合わせを特定するために用いられる用語である。“セレクタ”はＸＳＬパターンを用いて特定される（パターンはあるタイプのＸＰａｔｈ ｅｘｐｒｅｓｓｉｏｎである）。所与のインスタンスに対して、ドキュメント内の要素の唯一のコンテキスト、そのセレクタがドキュメント内の要素のコンテキストに最も一致するコンテキストが、処理される。もしセレクタが削除された場合、それはその要素名のＸＳＬパターンを意味する。

ＰｒｉｎｔＰａｇｅＳｅｔｓは印刷およびＰＤＦ出力のためのページレイアウトを定義する。

ＴａｂｌｅｓＯｆＣｏｎｔｅｎｔｓは要素セクションから参照されるＴａｂｌｅＯｆＣｏｎｔｅｎｔｓの定義である。ユーザによって定義された各目次について、ＴａｂｌｅＯｆＣｏｎｔｅｎｔｓ要素がある。この要素は多様なＴａｂｌｅＯｆＣｏｎｔｅｎｔｓのプロパティをその属性によって定義する。各ＴａｂｌｅＯｆＣｏｎｔｅｎｔｓ要素は各ＴＯＣレベルに１つの、５つのＴｏｃＬｅｖｅｌＩｎｄｅｎｔ子要素を有する。これら要素はＴａｂｌｅＯｆＣｏｎｔｅｎｔｓ事項のインデントおよび番号の位置付けを制御する。

ＲｅｆｅｒｅｎｃｅＦｏｒｍａｔｓはクロスリファレンスおよびヘッダやフッタからの部分の参照に用いられるフォーマットの広範囲の定義を含む。

ＦｏｓｉＲｓｒｃＤｅｓｃＳｏｕｒｃｅは、エクスポートされたＦＯＳＩにマージする、任意のＦＯＳＩｒｓｒｃｄｅｓｃソースマークアップを含む。

本発明の例示的スキーマは付録Ａとして添付されている。

好適な実施形態を参照しながら本発明が説明されたが、本発明の精神および範囲から離れることなく、形式や詳細に変更を加えることができることは、当業者にとって明らかである。

（付録Ａ）

図１は、本発明の一実施形態による入力ファイルを出力ファイルに変換する方法を示すフローチャートである。 図２は、本発明の一実施形態に関連するエディタのインターフェースを示すスクリーンショットである。 図３は、本発明の一実施形態によるフォントプロパティを編集するフォントダイアログボックスのスクリーンショットである。 図４は、本発明の一実施形態によるインデントプロパティを編集するインデントダイアログボックスのスクリーンショットである。 図５は、本発明の一実施形態によるスペースプロパティを編集するスペースダイアログボックスのスクリーンショットである。 図６は、本発明の一実施形態によるブレークプロパティを編集するブレークダイアログボックスのスクリーンショットである。 図７は、本発明の一実施形態によるアドバンストブレークプロパティを編集する図６のブレークダイアログボックスを介してアクセス可能なアドバンストブレークダイアログボックスのスクリーンショットである。 図８は、本発明の一実施形態によるｇｅｎｔｅｘｔプロパティを編集するｇｅｎｔｅｘｔダイアログボックスのスクリーンショットである。 図９は、本発明の一実施形態による設定を確認するための設定ダイアログボックスのスクリーンショットである。 図１０は、本発明の一実施形態によるプロパティ設定を編集するための編集プロパティ設定ダイアログボックスのスクリーンショットである。 図１１は、本発明の一実施形態による新しいプロパティ設定を追加するための新しいプロパティ設定ダイアログボックスのスクリーンショットである。 図１２は、本発明の一実施形態によるエディタのスタイルアーキタイプオプションを示すユーザインターフェースのスクリーンショットである。 図１３は、本発明の一実施形態による要素のスタイルシートソースの編集を可能にするユーザインターフェースのスクリーンショットである。 図１４は、本発明の一実施形態によるスタイルシートファイル・ソースコードを編集するスクリーンショットである。 図１５は、本発明の一実施形態によるスタイル特性を出力の組み合わせに割り当てるスクリーンショットである。 図１６は、本発明の一実施形態に関する条件ダイアログボックスのスクリーンショットである。 図１７は、本発明の一実施形態に関する新しい条件の属性テストのスクリーンショットである。 図１８は、本発明の一実施形態による他のアプリケーションでの使用のために特定のスタイルシート言語にエクスポートするユーザオプションのスクリーンショットである。 図１９は、本発明の一実施形態に関するスタイルシートエディタのアーキテクチャを示す。 図２０は、Ｂａｓｅ ＣｌａｓｓｅｓおよびＳｔｙｌｅｓｈｅｅｔ Ｌｅｖｅｌ Ｃｌａｓｓｅｓを示す。 図２１は、ＩＥｌｅｍｅｎｔＮｏｄｅ Ｓｕｂｃｌａｓｓｅｓを示す。 図２２は、Ｐｒｏｐｅｒｔｙ−ｒｅｌａｔｅｄ ｃｌａｓｓｅｓを示す。 図２３は、ＩＰｒｏｐｅｒｔｙＥｌｅｍｅｎｔＢａｓｅｓｕｂｃｌａｓｓｅｓを示す。

Claims (36)

1. 出力される情報を識別する単一のスタイルシート内の命令と、
   複数の出力それぞれに対する該情報の少なくとも一部分の少なくとも１つのフォーマットを規定する該単一のスタイルシート内の命令と
   を含む、コンテンツを複数の出力で出力する仕様を規定する単一のスタイルシートであって、該情報が特定のフォーマットで出力されるときにおいて、選択された出力に対して規定されたフォーマットが適用される、スタイルシート。
2. 前記出力される情報を識別するスタイルシート内の命令は、出力される入力ファイルの要素を識別する命令を含む、請求項１に記載のスタイルシート。
3. 前記出力されると識別される前記情報の位置を識別する命令をさらに含む、請求項１に記載のスタイルシート。
4. 要素のタイプを識別する命令をさらに含む、請求項２に記載のスタイルシート。
5. 前記命令は前記要素のタイプを識別するタグを含む、請求項４に記載のスタイルシート。
6. 前記出力されると識別された情報の少なくとも一部分のフォーマットを規定する前記命令は少なくとも１つのスタイルアーキタイプを含む、請求項１に記載のスタイルシート。
7. 前記出力されると識別された情報の少なくとも一部分のフォーマットを規定する前記命令は、該情報が出力され得る複数の出力のそれぞれに該識別された情報のフォントを規定することを含む、請求項１に記載のスタイルシート。
8. 前記出力されると識別された情報の少なくとも一部分のフォーマットを規定する前記命令は、該情報が出力され得る複数の出力のそれぞれに該識別された情報のインデントプロパティを規定することを含む、請求項１に記載のスタイルシート。
9. 前記出力されると識別された情報の少なくとも一部分のフォーマットを規定する前記命令は、該情報が出力され得る複数の出力のそれぞれに該識別された情報のスペースプロパティを規定することを含む、請求項１に記載のスタイルシート。
10. 前記出力されると識別された情報の少なくとも一部分のフォーマットを規定する前記命令は、該情報が出力され得る複数の出力のそれぞれに該識別された情報のブレークプロパティを規定することを含む、請求項１に記載のスタイルシート。
11. 前記出力されると識別された情報の少なくとも一部分のフォーマットを規定する前記命令は、該情報が出力され得る複数の出力のそれぞれに該識別された情報と連動して自動的に生成されたテキストの追加を規定することを含む、請求項１に記載のスタイルシート。
12. コンピュータで使用可能なメディアと、複数のフォーマットで出力される情報をフォーマットするための１つのスタイルシートを作成するための該コンピュータで使用可能なメディア上で具体化されたコンピュータ読み取り可能なコードとを含むコンピュータプログラム製品であって、該コンピュータ読み取り可能なコードは、
    該コンピュータに入力ファイルの受け取りを達成させるべく構成された、コンピュータ読み取り可能なプログラムコード装置と、
    該コンピュータに該入力ファイル内の少なくとも１つの要素を決定させるべく構成された、コンピュータ読み取り可能なプログラムコード装置と、
    該コンピュータに該少なくとも１つの要素に適用可能なフォーマットルールを決定させるべく構成された、コンピュータ読み取り可能なプログラムコード装置と、
    該少なくとも１つの要素に該フォーマットルールを適用させるべく構成されたコンピュータ読み取り可能なプログラムコード装置と、
    第２のファイルタイプの出力ファイルとして適用される該フォーマットルールを有する該少なくとも１つの要素を格納すべく構成されたコンピュータ読み取り可能なプログラムコード装置と
    を含む、コンピュータプログラム製品。
13. 入力ファイルを受信するための命令を含むコードセグメントと、
    該入力ファイル内の少なくとも１つの要素を決定するための命令を含むコードセグメントと、
    該少なくとも１つの要素に適用可能なフォーマットルールを決定するための命令を含むコードセグメントであって、フォーマットルールは少なくとも２つの出力フォーマットのそれぞれに対して決定される、コードセグメントと、
    該少なくとも２つの出力フォーマットを出力するために適切なフォーマットルールを該少なくとも１つの要素に適用するための命令を含むコードセグメントと、
    第２のファイルタイプの出力ファイルとして適用される該フォーマットルールを有する該少なくとも１つの要素を格納するための命令を含むコードセグメントと
    を備える、転送メディア内で具体化されたコンピュータデータ信号。
14. 入力ファイルを受信し、読み取るための命令を含むコードセグメントと、
    少なくとも２つの出力フォーマットそれぞれの該入力ファイル内の少なくとも１つの要素に、少なくとも１つのフォーマットルールを適用するための命令を含むコードセグメントであって、該少なくとも２つの出力フォーマットのうちの１つで出力されたときにおいて、フォーマットルールと整合したフォーマットされた要素が得られる、コードセグメントと
    を備える、転送メディア内で具体化されたコンピュータデータ信号。
15. 出力される要素を決定することを提供することと、
    複数の出力フォーマットのそれぞれに対して該要素に適用可能なフォーマットルールを決定することを提供することと、
    該出力フォーマットと整合する要素にフォーマットルールを適用することを提供することと
    を包含する、単一のスタイルシートを用いて複数の出力フォーマットのうちの１つで情報を出力する方法。
16. 出力する要素を決定することと、
    各要素に少なくとも１つのフォーマットルールを、出力のフォームに基づいて決定することと、
    該要素のために選択された出力フォーマットと整合したフォーマットルールを適用することと
    を包含する、単一のスタイルシートを用いて複数のフォーマットで情報を出力する方法。
17. 前記要素に適用可能なフォーマットルールを決定することと、前記要素にフォーマットルールを適用することとは、該要素に適用可能なスタイルアーキタイプを決定することと、該要素に該スタイルアーキタイプを適用することとを包含する、請求項１６に記載の方法。
18. 入力ファイル内の情報を受信することと、
    単一のスタイルシートを用いてマルチチャンネルで該情報を公開することと
    を包含する情報を公開する方法であって、
    該スタイルシートは、マルチチャンネルに適応されるフォーマットルールを該入力ファイル内の要素に適用する、方法。
19. 単一のスタイルシートにおいて、入力ファイル内の少なくとも１つの要素を識別し、タグ付けすることと、
    単一のスタイルシートにおいて、スタイルを該少なくとも１つの要素に関連付けすることと、
    単一のスタイルシートにおいて、出力ファイルタイプを選択することと
    を包含する、単一のスタイルシートを用いて複数の出力ファイルタイプのうちの１つで情報を出力することが可能なスタイルシートを作成する方法であって、該スタイルは、該選択された出力ファイルタイプに従って変化し得る、方法。
20. スタイルを前記少なくとも１つの要素に関連付ける動作が、前記入力ファイル内の前記要素の場所に基づいてなされる、請求項１９に記載の方法。
21. スタイルを前記少なくとも１つの要素に関連付ける動作が、デフォルトの割り当てポリシーに基づいてなされる、請求項１９に記載の方法。
22. スタイルを前記少なくとも１つの要素に関連付ける動作が、ユーザ固有の割り当てポリシーに基づいてなされる、請求項１９に記載の方法。
23. 前記スタイルは前記少なくとも１つのフォーマットルールを有する、請求項１９に記載の方法。
24. 前記少なくとも１つの要素が、１つ以上のコンテキストに出現し、前記スタイルを該少なくとも１つの要素に関連付ける動作が、該スタイルを少なくとも１つの要素コンテキストに関連付けることを含む、請求項１９に記載の方法。
25. 条件と、前記少なくとも１つの要素コンテキストに関連付けられたフォーマットルールとを適用することをさらに包含する、請求項２４に記載の方法。
26. 前記条件は、一連の属性テストに加えて前記関連付けられたフォーマットルールを含む、請求項２５に記載の方法。
27. スタイルを前記少なくとも１つの要素に関連付ける動作は、プロパティセットを用いて行われる、請求項１９に記載の方法。
28. 前記選択された出力ファイルタイプはコンテキスト固有である、請求項１９に記載の方法。
29. 前記選択された出力ファイルタイプはユーザ固有である、請求項１９に記載の方法。
30. 前記選択された出力ファイルタイプは装置固有である、請求項１９に記載の方法。
31. スタイルを少なくとも１つの要素に関連付ける前において、ベースライン特性を該少なくとも１つの要素に関連付けることをさらに包含する、請求項１９に記載の方法。
32. 出力される情報を識別する手段と、
    少なくとも１つのフォーマットルールを該出力される情報に関連付ける手段であって、複数の出力フォームで出力するために、フォーマットルールを該出力される情報に関連付けることをさらに含む、手段と
    を備える、コンテンツを様々な出力メディアフォーマットに出力するシステム。
33. ユーザが出力フォーマットのためにコードを書くことを可能にする手段をさらに備える、請求項３２に記載のシステム。
34. 前記コードを保存する手段をさらに備える、請求項３３に記載のシステム。
35. 前記保存されたコードが、管理され再利用され得る、請求項３４に記載のシステム。
36. 前記保存されたコードは、管理され再利用され得るコードのライブラリの一部である、請求項３３に記載のシステム。

Images