JPH0210455A - データ・ストリームの処理方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明はデイシイタル通信、より詳細に言えば、データ
・ストリームを生じるアプリケーション・プログラムの
動作とは独立して、データ・ストリームの効果的で正確
な管理を達成するような方法でデータ・ストリームのコ
ンストラクト（構造）を管理し、処理することに関する
。本発明は、一方のアプリケーション・プログラムから
他方のアプリケーション・プログラムへ文書データ、フ
ォーマツティング情報及びリソースを、高度の融通性を
以って伝送し、しかもデータ・ストリームの混乱を顕著
に減少するデータ・ストリームのアーキテクチャを与え
る。

Ｂ、従来の技術 ローカル・エリア・ネットワーク（ＬＡＮ）、または大
規模なテレプロセッシング・ネットワークのようなディ
ジタル通信ネットワークにおけるデータ・ストリームの
管理は、特に、種々のアプリケーション・プログラムに
よって動作する端末装置、またはワークステーションに
おいて発生されたデータ・ストリームが、異なった制御
特性及び異なったプロトコルを有するデータ・ストリー
ムを発生する場合に、多くの問題が生じる。これらの問
題を、より良く理解するために、２つ以上のエンド・ユ
ーザの間の通信をサポートする仮想的なテレプロセッシ
ング・ネットワークを考えてみる。ここでいうエンド・
ユーザとは、アプリケーション・プログラムでも、スト
レージ装置でも、デイスプレー装置を操作するオペレー
タであってもよい。エンド・ユーザに与えられるものは
、フォーマツティングし、翻訳し、そして編集すること
を含むプログラム言語を取扱う通信機能と、データ・フ
ロー、即ちデータ流を制御する対話式の訓練方法と、デ
ータ流の速度の制御及びデータ流の順序の制御を含む伝
送制御と、アドレス可能なユニット間の複雑な伝送ネッ
トワークを介する通過信号を含む伝送である。

システム・アーキテクチャ・ネットワーク（ＳＮＡ）は
ネットワークを通じて配分される通信開運機能を定義す
る。またＳＮＡは、これらの配分機能に関するフォーマ
ット及びプロトコルを、ネットワーク中の他の端末装置
に対して定義する。

ＳＮＡネットワークは高度に透明である。換言すれば、
ＳＮＡは任意のビット・ストリームが通過可能であり、
エンド・ユーザはネット・ワークのトポロジーとか、ル
ート選択や媒体の選択とかを心配する必要がない。セツ
ションは、そのセツションに委ねられた一組のＳＮＡ機
能に従ってメツセージを交換するために、ネットワーク
中のアドレス可能なユニット間の臨時的な論理的接続で
あると定義される。従って、ＳＮＡネットワークは一対
のユーザの間の対話を容易にする配分されたサービスを
与える。ＳＮＡのサービスは層状の構成に組織されてい
るので、論理的に独立している機能を、設計し、実行す
ることが出来、且つそれを独立して呼び出すことができ
る。１つのエンド・ユーザは、複数のネットワーク・ア
ドレスの下にある他の複数のエンド・ユーザと通信する
ために、同時セツションを使うことができる。

既に述べたように、ＳＮＡネットワーク内のエンドユー
ザはアプリケーション・プログラムでも、人／出力（Ｉ
ｌｏ　＞装置のオペレータでも、またはストレージ媒体
でもよい。最も一般的な形式のエンド・ユーザはアプリ
ケーション・プログラムである。プログラムとＳＮＡネ
ットワークとの間の対話は、データ交換、必要に応じて
コマンドの交換、及びＳＮＡ機能の制御のための標識を
含む。

ＳＮＡネットワーク内の異なったアプリケーション・プ
ログラムは、そのプログラムに独特のデータ・ストリー
ムを発生するのが普通である。ＳＮＡのアーキテクチャ
はネットワーク内のエンド・ユーザ間の通信を容易にす
るけれども、若し、エンド・ユーザが互換性を持たない
データ・ストリームを発生するアプリケーションであれ
ば、意味のある通信は達成できない。従来から、データ
・ストリームは、構成されたフィールドの集合であり、
構成されたフィールドのシンタックス（ｓｙｎｔａｘ）
即ち構文と、セマンテイツク（ｓｅｍａｎＨｃ　）即ち
意味によって定義される。構成されたフィールド及びパ
ラメータが、それらの意味、またはそれらの解釈及び使
用の態様とは独立して、グループ分けされたものが、シ
ンタックスによって意味付けられるものである。構成さ
れたフィールド及びパラメータの解釈及び使用とは独立
して、構成されたフィールド及びパラメータの意味が、
セマンテイツクによって意味付けられるものである。デ
ータ・ストリームは、文書のような視覚的なエンティテ
ィ、または観念的なエンティティを作成するものである
と解釈される。転じて、文書はページ、データ・オブジ
ェクト、リソース及びコマンドで構成されており、そし
て修正されるか、表示されるか、またはリソース・デー
タ・フォーマットにあるかの何れかである。

テキスト処理のアプリケーションの１つの例は、フォー
マツティング及びテキスト用の組込みコマンド（ｅｍｂ
ｅｄｄｅｄ　ｆｏｒｍａｔｔｉｎｇ　ａｎｄ　ｔｅｘｔ
ｕａｌ　ｃｏｍｍａｎｄ　）を持つデータ・ストリーム
を発生する。通常、これらのコマンドは一方のアプリケ
ーション・プログラムから他方のアプリケーション・プ
ログラムに変更する。異なったテキストを処理するアプ
リケーションからのデータ・ストリームを交換するため
に開発された「変更可能なフォーマット・テキスト文書
内容アーキテクチャＪ　（ＲｅｖｉｓａｂｌｅＦｏｒｍ
ａｔ　Ｔｅｘｔ　Ｄｏｃｕｍｅｎｔ　Ｃｏｎｔｅｎｔ　
Ａｒｃｈｉｔｅｃｔｕｒｅ−ＲＦＴＤＣＡ　）があり、
これにより、フォーマツティング及びテキスト用組込み
コマンドの矛盾のない解釈を可能としている。

国際標準機構（ＩＳＯ）は文書処理及び文書交換のため
のスタンダードを決めている。特に、包括的な標準マー
カツブ言語（５ｔａｎｄａｒｄＧｅｎｅｒａｌｉｚｅｄ
　Ｍａｒｋａｐ　Ｌａｎｇｕａｇｅ−ＳＧＭＬ　）の公
表文書８８７９、及びオフィス文書のアーキテクチャと
オフィス文書の交換設備（０ｆｆｉｃｅ　Ｄｏｃｕｍｅ
ｎｔＡｒｃｈｉｔｅｃｔｕｒｅｌｏｆｆｉｃｅ　Ｄｏｃ
ｕｍｅｎｔ　ＩｎｔｅｒｃｈａｎｇｅＦａｃｉｌｉｔｙ
−ＯＤ　Ａ／　ＯＤＩＦ　）の公表文書８６１３の２つ
は、そのようなスタンダードに関する文書である。ＳＧ
ＭＬはキャラクタ（文字、記号）のテキストのための代
表的な言語であり、公表されたシステムの使用を定義す
るのに使用することが出来る。文書エレメントの役割を
識別する包括的なマーカツブは、ＳＧＭＬの基礎である
が、これは、文書のエレメントをどのように表示するか
について基礎を置くものではない。また、ＳＧＭＬは、
テキスト文書を交換するのにも用いられるが、走査され
たイメージや、グラフィックのような非テキスト・デー
タが文書と共存することがあり得るから、非テキスト・
データを含む文書を交換する要求は、ＳＧＭＬによって
すべてをアドレスすることはできない。この要求はＯＤ
Ａによって、より適正に処理することができる。

ＯＤＡは、文書の構造と、文書に含まれるべき全ての形
式のテキスト情報及び非テキスト情報を記述する方法で
ある。この構成された記述はアーキテクチャと称され、
そして文書の表示は、交換するのに適当なフオームにあ
る。交換するためのＯＤＡのエンコーディングはデータ
・ストリームである直列フオームに限定される。ＯＤＡ
の文書は、矛盾のない１つのデータ・ストリームに集合
された走査イメージ及びグラフィック・データと、文字
、記号のテキストとを含ませることができる。

ＯＤＡはフォーマツティングの組込みコマンドによるの
ではなく、文書構造の記述によって定義されたオブジェ
クトと結び付けられたレイアウト及び表示の指示（１ａ
ｙｏｕｔ　ａｎｄ　ｐｒｅｓｅｎｔａｔｉｏｎｄｉｒｅ
ｃｔｉｖｅ　）と呼ばれる属性（ａｔｔｒ　１ｂｕｔｅ
　）を特定することによってフォーマツティング処理の
制御を行う。これらの指示はレイアウト及び表示スタイ
ルを形成するために一緒にグループ別にされ、それらの
スタイルは、転じて文書構造中の１つまたはそれ以上の
オブジェクトによって照合することができる。ＯＤＡス
タイルは文書の外部から与えるものであってもよいが、
但し、スタイルの属性及び属性値はＯＤＡスタンダード
によって明白に制御される。ＯＤＡのデータ・ストリー
ム中のポイントから、スタイルの仕様中の位置への明白
なリンクはない。ＯＤＡ文書のクリエータ−（ｃｒｅａ
ｔｏｒ　）は、ＯＤＡオブジェクトの記述内でユーザが
定義した属性の名前及び属性値を組込むことによって、
スタイルの仕様を増加することができる。ユーザが定義
した属性は、文書処理のフェースの間で、ＯＤＡオブジ
ェクトに適用されるべきアプリケーションに従属する機
能を特定する。この情報は、作成のアプリケーションの
内でのみ意味があり、その他のユーザによって解釈する
ことはできない。

インターリーフ、ゼロックス・ベンチュラ・パブリツシ
ャー及びマイクロソフト・ワードは、フォーマツティン
グ及びレイアウトを制御するために、組込み制御コード
、または組込みコマンドを使用する編集アプリケーショ
ンではなく、スタイル・シートを使用する編集アプリケ
ーションの例である。この方法は、ひとたびその特性が
文書の内容に割り当てられると、システム的でグローバ
ルな変更は、単調で疲労度の高い作業を伴う困難な仕事
であり、使い易いとはいえない。また、スタイル・シー
トの変更は、文書を作成するアプリケーションの範囲内
においてだけしか行うことができない。ベンチュラ・パ
ブリツシャーはテキスト処理アプリケ−シコンによって
作成されるファイルのフォーマットの多様性を受入れる
強力な移入ファシリティを持っている。これらのファイ
ルはベンチュラに規則を移入し、そこで、細部のフォー
マツティングが、ファイル移入タスクを開始したオペレ
ータによって選ばれたスタイル・シートに基づく後処理
タスクとして遂行される。デフォルト（ｄｅｆａｕｌｔ
　）のスタイル・シートはベンチュラ・パブリツシャー
及びマイクロソフト・ワードの両方に別々にストアされ
、そして、ベンチュラ及びマイクロソフト・ワードのア
プリケーションのうちから複数の文書によってアクセス
することができる。マイクロソフト・ワードの文書は通
常、オペレータが各文書を異なったスタイル・シートに
したいと望んだ場合に編集することができるローカル・
スタイル・シートを含んでいる。両方のアプリケーショ
ンにおいて、スタイル・シートのカスタマイゼーション
（ｃｕｓｔｏｍｉｚａｔｉｏｎ　）　（特別仕様にする
こと）は、アプリケーション・プログラム内からのみ行
うことが可能であり、文書中のポイントからスタイル・
シート内の位置への明白な基準はない。スタイル・シー
トを修正することが出来るエンド・ユーザだけがベンチ
ュラ・パブリツシャー、またはマイクロソフト・ワード
のエンド・ユーザである。

更に、一般に、ＩＳＯスタンダードか、またはアプリケ
ーション・プログラム・プロダクトによるかのいずれか
の下で作成されたデータ・ストリームは、予期し得るフ
ォーマツティングの要件にできるだけ広く適合させる要
求によって、複雑にならざるを得ない。例えば、スプレ
ッドシート（ｓｐｒｅａｄｓｈｅｅ　ｔ）アプリケーシ
ョン・プログラムを考えてみる。内部セルと、列及び行
の処理要件は、各オペレータによって異なる。あり得る
全ての要求を取り扱うためのアプリケーション・プログ
ラムを設計することは、極めて複雑なデータ・ストリー
ムを生じることになる。必要なのは、ネットワーク内の
種々のアプリケーション・プログラムに対して複雑でな
く、かつ互換性ある通信を許容するデータ・ストリーム
・アーキテクチャである。

より特定して言えば、混合オブジェクト文書内容アーキ
テクチャは、矛盾のない状態で文書のデータを処理する
ために、種々のプロダクトの間で、文書交換ができるこ
とが望ましい。そのような混合オブジェクト文書内容ア
ーキテクチャにおいて、種々のフォーマツティング・コ
マンドのデータ・ストリームに過度の負担を与えず、そ
の結果、データ・ストリーム・アーキテクチャを単純化
し、且つ、より互換性のある文書のデータ交換を容易に
するデータ・ストリームのスタンダードの出現が望まれ
ている。

Ｃ０発明が解決しようとする問題点 従って、本発明の目的は伝送効率を向上させたディジタ
ル通信の文書交換環境を与えることにある。

本発明の他の目的はデータ・ストリームを作成する機能
を分離して、データ・ストリームを管理し、これにより
データ・ストリームのアプリケーションの管理を独立し
た機能としたデータ・ストリームのアーキテクチャを提
供することにある。

Ｄ１問題点を解決するための手段 本発明に従って構成されたシェルは、データ内容とは独
立しているコンストラクトであるにも拘らず、エディタ
ー（ｅｄｉｔｏｒ　）または他の同じようなアプリケー
ションによって作成された文書のデータ・ストリーム表
示中のデータと同時に出現することが出来るようなタグ
を付されたコンストラクト、またはエレメントを、どの
ように管理し、処理するかを特定する。コンストラクト
の意味は、データ・ストリーム中に存在する、作成され
たものを意味し、換言すれば、データ・ストリームの中
にあって、構成されたエレメントを意味する。

シェル構造はデータ・ストリームからは分離されており
、独立して伝送することが出来、そして、ネットワーク
によって認識される任意のフオームで記憶することが出
来る。

本発明は、シェルの中にあり、名前を付けられたコンス
トラクトを照合することによって、データ・ストリーム
中のコンストラクトをリンク（連結）するタグ論理エレ
メント（ＴＬＥ）機能な含んでいる。名前を付したシェ
ル・コンストラクトは、リファレンス（照合符号）を含
むデータ・ストリームの処理及び管理を制御する規則、
相互関係及びフォーマツティング情報を直接、または間
接に特定する。加えて、ＴＬＥ機能は、タグを付したコ
ンストラクトにデータ内容を結び付けるために用いられ
る。所望の内容情報をどのように分析するかを記載した
エキスプレッション（ｅｘｐｒｅｓｓｉｏｎ　）　（表
示）を発生する所望の内容情報、または内容を含むデー
タ・サブジェクト・エンベロープに対して、内部リファ
レンス、または外部リファレンスを与えることによって
、明白な結び付きが可能である。データ・サブジェクト
・エンベロープがデータ・ストリーム中で、順次にタグ
が付されたコンストラクト′ｆ！：直後に従えている時
、暗黙の結び付きが生じる。若し、ＴＬＥが内容発生エ
キスプレッションのリファレンスを含んでいれば、その
エキスプレッションは、結び付けられるデータ内容を分
析するために評価されねばならない。また、ＴＬＥは、
若しエンド・ユーザがコンストラクトそれ自身か、また
は入れ子にされ、タグを付されたコンストラクトのシェ
ル中の仕様を特定しなかったならば、無効にされる宣言
値、及び１つ以上の属性（ａｔｔｒｉｂｕｔｅ　）を特
定するのにも用いられる。フォーマット記述及び指示に
加えて、属性のシンタックス（構文）及び許容された属
性値は、シェルに直接に含ませることも出来るし、シェ
ルから照合することも出来るし、またはＴＬＥから照合
することも出来る。シェル、またはＴＬＥから照合出来
るものは、マクロ、プロシージャ、リソース・オブジェ
クト、或は、フォーマツティング情報を特定する他のそ
のようなコンストラクトである。照合されたコンストラ
クトを、同じシェル、または異なったシェルに含ませる
ことが出来、そして、それらは他のコンストラクトのリ
ファレンスを含むことも出来る。ＴＬＥからのリファレ
ンスは、それらの関連するシェル中の片割れと臨時に置
換する。置換の長さは、タグを付されたコンストラクト
の範囲の長さと等しい。タグを付されたコンストラクト
の範囲は、シェル中の照合され名付けられたコンストラ
クトの階層的位置によって分析される。シェルは本構造
、即ちノードを持つトリーに構成され、名前を付けられ
たコンストラクトは、トリー構造中のノードにある。ノ
ードは入れ子にされ、そして入れ子のレベルはノードに
よって表示され、名付けられたコンストラクトの範囲を
決める。

処理しているデータ・ストリームにおいて、若し、タグ
を付されたコンストラクトが照合されたならば、次のよ
うな動作が生じる。先ず、シェル・コンストラクトの名
前、リファレンスが分析され、そして管理情報及び処理
規則が検索される。分析（ｒｅｓｏｌｕｔｉｏｎ　）は
１つまたはそれ以上のシェル構造を含む。次に、タグ付
けされたコンストラクトと共に含まれているパラメータ
が、シェルの仕様に対して行われた修正、または付加に
ついてチエツクされる。若し変更が特定されていなけれ
ば、管理情報が解釈され、処理規則が実行され、そして
、その結果は、タグ付けされたコンストラクトに結び付
けられたデータ内容に適用される。若し、変更が特定さ
れており、そしてエンド・ユーザがシェルの名のコンス
トラクトをカスタマイズ（ｃｕｓｔｏｍｉｚｅ　）　（
特別化）していなければ、照合された管理情報、及び処
理規則の全てが分析され、そしてその結果は、前のステ
ップで特定されたように適用される。上述のステップに
従うように設計されたアプリケーションの例は、対話式
エディター、またはバッチ式エディター、または文書フ
ォーマツタ、パーザ−（ｐａｒｓｅｒ　）及び交換デー
タ・ストリーム・インターブレターである。

Ｅ、実施例 第１図を参照すると、データ・ストリームを定義する幾
つかのアーキテクチャの構造的な全体像を説明するため
の図が示されている。最初のアーキテクチャは特定のデ
ータ形式、即ちデータ・タイプの構造及び制御を与える
「オブジェクト内容アーキテクチャＪ（ＯＣＡ）である
。これらアーキテクチャの例として、タブ、マージン等
を特定する変更可能テキストＯＣＡと、分解能、圧縮ア
ルゴリズム等を特定するイメージＯＣＡがある。

これらのＯＣＡは、データ及び制御コードに先行する開
始コードを持ち、終了コードで終了されるデータ・スト
リーム構造を有している。

文書内容アーキテクチャ（ＤＣＡ）の中で、「混合す、
ブジエクト文書内容アーキテクチャ」（ＭＯ：ＤＣＡ）
と呼ばれる特別のタイプのアーキテクチャが、本発明の
好ましい環境であり、ページのレイアウトや、オブジェ
クト間の関係等々を与える。第１図に示したように、Ｏ
ＣＡデータ・ストリームはＤＣＡデータ・ストリームの
オブジェクト及び制御部分に含まれている。ＤＣＡデー
タ・ストリームは、転じて、「文書交換ユニット」（Ｄ
ＩＵ）のデータ・ストリームを定義する文書交換アーキ
テクチャの一部である。このアーキテクチャは文書分配
サービス、文書ライブラリ・サービス及びアプリケーシ
ョン処理サービスを与える。

このデータ・ストリームはコマンド・コード及びデータ
・ユニット・コードを従えた接頭部を持っている。それ
らの次に、文書ユニットとしてＤＣＡデータ・ストリー
ムが続いている。接尾部がＤＩＵデータ・ストリームを
終了する。

上述したシステム・ネットワーク・アーキテクチャ（Ｓ
ＮＡ）はネットワークのエンティティの間で情報の交換
を制御する。このアーキテクチャは、伝送ヘッダ、要求
ヘッダ及び要求ユニットを含む「経路情報ユニットＪ（
ＰＩＵ）のデータ・ストリームを定義する。最後に、例
えば「同期ディジタル・リンク制御Ｊ（ＳＤＬＣ）のよ
うなデータ・リンクのプロトコルがデータ・リンクに関
して同期と、エラー回復を与える。このプロトコルはリ
ーディング・フラグ、アドレス、制御ビット、データ、
エラー検出用のＢＣＣチエツク・ビット及びトレイリン
グ・フラグを含む伝送フレームを定義する。このデータ
はＰＩＵデータ・ストリームである。データ・ストリー
ムの定義及びプロトコルの全般の情報は、アデイソン・
ウニスリー（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ）　（１９
７８年）で刊行されたシブサー（Ｒ，Ｊ、Ｃｙｐｓｅｒ
　）著の「配分されたシステムのための通信用アーキテ
クチャ」（ＣｏｍｍｕｎｉｃａｔｉｏｎｓＡｒｃｈｉｔ
ｅｃｔｕｒｅ　ｆｏｒ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｓｙ
ｓｔｅｍｓ　）中に、より詳しく記載されている。

本発明を実施するための望ましい環境は、混合オブジェ
クト文書内容アーキテクチャの範囲内にあり、本発明の
特定の実施例を説明する前に、このアーキテクチャを以
下に簡単に説明する。混合オブジェクト文書内容アーキ
テクチャ（ＭＯ：ＤＣＡ）は、アプリケーション・プロ
グラム相互の間でオブジェクト・データを交換する際に
、異なったアプリケーション・プロ゛グラムの使用を許
容する単一のインターフェースの定義を与えているから
、このデータは変化する特性及び意図を処理することに
よって、編集し、表示し、または操作することが出来る
。ＭＯ：　ＤＣＡはサポートされた任意のオブジェクト
・タイプを含む文書の要素に対して論理的構造及びレイ
アウト構造の両方を提供する。オブジェクトのタイプは
、例えば、テキスト・オブジェクト、グラフィック・オ
ブジェクト、イメージ・オブジェクト、テーブル・オブ
ジェクト等々である。単一のデータ・ストリームの定義
、の範囲内で、ＭＯ：　ＤＣＡ及びそのデータ・オブジ
ェクトは高度の変更可能コンストラクト（ｃｏｎｓｔｒ
ｕｃｔ　）及び高度の変更不能コンストラクトの両方を
特定することができる。従って、ＭＯ＝ＤＣＡにおける
述語「混合」は、混合データ・オブジェクトと、混合文
書コンストラクトの両方に関係する。混合オブジェクト
文書は、リソースと、データ・オブジェクトと、文書内
容に遂行される処理機能を指令するフォーマツティング
仕様との集合である。各コンポーネントは明白に定義さ
れ、区切られている。コンポーネントの内容は他のコン
ポーネント及び構成されたフィールド（即ち、コマンド
）である。構成されたフィールドは、順番に、１つまた
はそれ以上のパラメータで構成されており、各パラメー
タはアーキテクチャで定義された値から選択された１つ
の値を与える。

ＭＯ：　ＤＣＡデータ・ストリーム及びそれに結び付け
られたオブジェクト内容の特性の中で、データ・ストリ
ームのアーキテクチャは第２図に階層的に示されている
。第２図において、文書は、コンポーネント１．２００
．で示された複数の文書コンポーネントを従えた文書開
始コードを含み、文書終了コードで終了するデータ・ス
トリームによって記述される。例えば文書コンポーネン
ト２のような、文書コンポーネントの１つは、ページで
あってよく、転じて、そのページはコンポーネント１．
２３．、で示された複数のページ・コンポーネントを従
えたページ開始コードを含み、ページ終了コードで終了
するデータ・ストリームのその部分によって記述されて
いる。例えば、コンポーネント２のように、これらのペ
ージ・コンポーネントの１つは、１つのオブジェクトで
あってよく、そのオブジェクトは、転じて、オブジェク
ト記述を従えたオブジェクト開始コードと、オブジェク
ト・データと、最後のオブジェクト終了コードとを含ん
だデータ・ストリームの部分によって記述される。オブ
ジェクト記述は、複数個のパラメータを従えた構成され
たフィールド導入部で構成されるコマンドである。従っ
て、データ・ストリームは構成されたフィールド（即ち
、コマンド）で作られたオブジェクトの順序付けられた
入れ子（ｎｅｓｔ　）を含んでいる。更に、データの多
重タイプ、例えばテキスト、イメージ、グラフィック等
々を１ページに表わすことができる。ＭＯ：　ＤＣＡの
データ・ストリームを含むすべての機能及びデータは、
構成されたフィールドと呼ばれる論理的レコードにグル
ープ分けされる。これらの構成されたフィールドは、実
際上、パラメータ・フィールドを含まない「コマンド」
、または１つ以上のパラメータ・フィールドを含む「コ
マンド」である。

構成されたフィールドのすへては、開始コード／終了コ
ードの対の間に置かれる。

文書のページはページ・モデルの記述に従って形成され
る文書の表示部分、または変更される一部であるデータ
・オブジェクトを含んでいる。第３図はページ・モデル
によって定義されたページのエレメントの１例を示して
いる。このモデルで示されているように、すべてのエレ
メントを全てのページに含ませる必要はない。主文のデ
ータ・オブジェクトは、例えばテキスト、グラフィック
等の任意のタイプのもの、またはそれらの混合であって
よい。テキスト・オブジェクトは１列、または複数列に
あってもよい。変更し得る文書はデータの表示を目的と
したデータ及び情報を含む。文書の起草者は、文書の各
セクション毎に別々にフォーマットを特定する必要はな
く、フォーマットについての成る種の指示を文書の始め
に一度だけ述べることが出来る。勿論、フォーマットに
ついての他の指示を文書の中に述べることも出来る。

また、変更可能な文書は、その文書が表示フオームに転
換される時点で、現在の文書に使われ、または含まれて
いるリソースを照合することも出来る。表示する文書は
、プリントされ、またはデイスプレーされる文書を表わ
すデータ・ストリームがどのように組織されているかを
定義する。

本発明はフォーマツティング・コンストラクトの代りに
、データ・ストリーム中のタグ論理エレメント（ＴＬＥ
）の構成されたフィールドを用いる。ＴＬＥはマクロ及
びパス・パラメータを呼び出すのに用いることが出来る
。また、ＴＬＥは論理エレメントの特例を開始し、そし
て終了するのに用いることが出来る。ＴＬＥが、例えば
、図形等の論理エレメントを開始するのに使用された時
、それは、例えばフレームのような１つ、またはそれ以
上の属性を特定し、そして各属性のための、例えばボッ
クスのような論理エレメント及びその値を特定する。エ
ンド・ユーザのワークステーションにおける構成された
シェルが、データ・ストリームに組込まれたＴＬＥをど
のように管理し、処理するかを特定するのに使用される
。構成されたシェルは、データ・ストリームから分離さ
れ、文書の作成者、またはエンド・ユーザのいずれかに
よって作成される。シェルがオペレータによって作成さ
れた場合、シェルはデータ・ストリームとは独立して伝
送され、そしてネットワークによって識別される任意の
形式で記憶されているので、これにより、シェルはネッ
トワークの任意のワークステーションによってアクセス
することが出来る。シェルがエンド・ユーザによって作
成された場合、シェルはエンド・ユーザだけで使用する
ために、局所的に記憶させることが出来る。また、エン
ド・ユーザがフォーマツティングの要件、及びその処理
要件を満足させるようカスタマイズするために、エンド
・ユーザは、作成者によって作成されたシェルを修正す
ることが出来る。

ＴＬＥは、シェル中で、名付けられたコンストラクトｔ
！：ＷＡ合することによって、データ・ストリーム中の
コンストラクトとリンクする。名付けられたシェル・コ
ンストラクトは、リファレンスを含むデータ・ストリー
ムのコンストラクトの処理及び管理を制御する規則、相
互関係、及びフォーマツティング情報を直接、または間
接に特定する。

加えて、ＴＬＥはデータ内容を、タグを付したコンスト
ラクトに結び付けるのに用いられる。所望の内容の情報
をどのように分析するかを記載したエクスプレッション
（表示）を発生する所望の内容情報、または内容を含む
データ・サブジェクト・エンベロープに対して、内部リ
ファレンスまたは外部リファレンスを与えることによっ
て、明白な結び付きが可能である。暗黙の結び付き・は
、データ・オブジェクト・エンベロープがデータ・スト
リーム中で順番にタグが付けられたコンストラクトを直
後に従えている場合に生じる。若し、ＴＬＥが内容発生
エクスプレッションのリファレンス（照合符号）を含ん
でいれば、そのエクスプレッションは、結び付けられた
データ内容を分析するために評価されなければならない
。また、若しエンド・ユーザが、コンストラクトそれ自
身か、または、入れ子にされタグ付けされたコンストラ
クトのいずれかに対するシェルの仕様を、特定しなかっ
たならば、無効となる１つ以上の宣言値及び１つ以上の
属性を特定するのにＴＬＥを用いることが出来る。フォ
ーマット・ディスクリブタ−及び指示に加えて、属性の
シンタックス及び許容された属性値は、シェルに直接食
ませることもできるし、またはシェルから照合すること
もできるし、あるいは、ＴＬＥから照合することもでき
る。シェルまたはＴＬＥから照合できるものは、マクロ
、プロシージャ、リソース・オブジェクト、あるいはフ
ォーマツティング情報を特定する他のそのようなコンス
トラクトである。照合されるコンストラクトは同じシェ
ル、または他のシェル中に含ませることが出来、そして
、それらは他のコンストラクトのリファレンスを含ませ
ることが出来る。

ＴＬＥからのリファレンスは、シェル中のそれらに関連
したカウンターパートと臨時に置換する。

置換の長さはタグされたコンストラクトの範囲の長さと
同じである。タグを付されたコンストラクトの範囲は、
シェル中の、照合され名付けられたコンストラクトの階
層的位置によって決められる。

シェルは本構造、即ちノードを有するトリー構造を持ち
、名前を付けられたコンストラクトはトリー中のノード
である。ノードは入れ子にされ、そして入れ子のレベル
はノードによって表示され名付けられたコンストラクト
の範囲を決める。

次に、第４図を参照して、本発明をより具体的に説明す
る。第４図において、シェル構造１２が表示されている
表示装置のスクリーン１１が示されている。このシェル
構造はスクリーン１１に接続されているエンド・ユーザ
の装置１４のオペレータによって開始されたアプリケー
ション１３の一部として発生される。このアプリケーシ
ョンはシェル構造を作成し、または修正することを許容
する。シェル構造は作成できるので、アプリケーション
１３は「開始／終了シェル」制御を自動的に挿入し、そ
して、プロンプトによって、オペレータに対してシェル
の名前が表示される。オペレータは「名前」プロンプト
のうしろに「シェルＡ２（１）」を挿入する。アプリケ
ーション１３は付加的なシェル・ディスクリブタ（記述
子）と、１つまたは、それ以上の「シェル制御」コンポ
ーネント、即ちシェルのインデックス・コンポーネント
を与える。各シェル制御コンポーネントに対して、オペ
レータは、例えば「タグ１」または「タグＡ」のような
コンストラクトの名前を与えなければならない。オペレ
ータは任意選択的に、フォーマツティングの指示（例え
ば５のインデント、中心点など）、副コンストラクトの
名前、論理的及び位置的関係、前のコンストラクトの名
前、表示の属性及びデフォルト（例えばタイムス・ロー
マンのフォント）、レイアウトの情報（例えば、含まれ
ている名付けられたコンストラクトに関する水平方向及
び垂直方向の位置）、または各シェルの制御コンポーネ
ントの処理ルーチン（例えば、呼び出しのためのＲＥＸ
Ｘプロシージャ）等を特定することが出来る。シェル・
インデックス・コンポーネントは、属性の名前／属性値
の対、デフォルトの値、シェル制御コンポーネントのた
めの副コンストラクト、前のコンストラクト等のリスト
を作るために用いられる。シェルのインデックス・コン
ポーネントはポインタのリファレンスによって、シェル
のコンポーネントにリンク（結合）される。終了時にお
いて、アプリケーション１３はオペレータにより特定さ
れたようにシェル構造１２をストアする。

第５図はローカル・ストレージ１５にストアされた「シ
ェルＡ２（１）Ｊを示す。第５図は、通信口１１ｉ［１
７を介してデータ・ストリーム１６がエンド・ユーザの
装置１４に到着している状態を示している。データ・ス
トリーム到着の通知を受けた後、エンド・ユーザの装置
１４のオペレータは、データ・ストリームを処理するた
めに、アプリケーション１８を開始する。スクリーン１
１上に表示されたアプリケーション１８は、データ・ス
トリームを処理するために使用されるシェル構造の名前
を入力するために、オペレータに対してプロンプトの表
示をする。オペレータはそのプロンプトに応答して、名
前「シェルＡ２　（１）Ｊを、キーボードによって入力
する。この時点で、若し、カスタマーゼイションが望ま
れているのならば、オペレータは、シェルを編集するた
めの選択権が与えられる。カスタマーゼーションは望ま
れていないから、オペレータは「シェルを編集しますか
？」というプロンプトに応答して「ノー」を入力する。

データ・ストリーム１６はタグ論理エレメント（ＴＬＥ
）のコンポーネントを含んでおり、ＴＬＥコンポーネン
トは、データ・ストリームの解析プロセッサ（ｐａｒｓ
ｉｎｇ　ｐｒｏｃｅｓｓｏｒ　）に遭遇した時、シェル
の照合のリンクを分析する。矢印を付した線４０．４１
及び４２は、夫々、タグ４３及びシェル・コンストラク
トの名前４６の間に作られた照合のリンクと、タグ４５
及びシェル・コンストラクトの名前４７の間に作られた
照合のリンクと、タグ４４及びシェル・コンストラクト
の名前４８の間に作られた照合リンクとを示している。

矢印を付した線４０により表わされた照合リンクの分析
は呼び出されるべきローカル・ストレージ１５中のプロ
シージャを発生する。プロシージャの呼び出しは点１＆
１ｉ５０によって表わされており、この呼び出しは、タ
グ処理のアプリケーションがシェル中のタグ４８により
定義された処理規則及びフォーマツティング情報を検索
した時に、発生される。矢印を付された線４２によって
示された照合リンクの分析は、ローカル・ストレージ１
５からイメージ・オブジェクト５１の検索を発生させる
。

イメージ・オブジェクト５１は、タグ処理アプリケーシ
ョンによりタグ４４と結び付けられたデータ内容である
。矢印を持った線５２はシェル・コンストラクト５３か
らイメージ・オブジェクト５１への照合リンクを表わし
ており、それは、どのデータの内容がそのタグに結び付
けられたかをタグ処理アプリケーションに知らせる。

第６図において、シェル構造６８は、ユーザの装置１４
からユーザの装置６０へ送られる。シェル構造６８は、
第４図のアプリケーション１３によって作成されたシェ
ル構造のコピーである。装置１４はローカル・ストレー
ジ１５、システム・ストレージ６５及びネットワーク・
ストレージ６３に接続されている。装置６０はローカル
・ストレージ６４及びシステム・ストレージ６６に接続
されている。通信リンク６２は装置１４及び装置６０の
間のデータの交換をサポートする。通信リンク内にシェ
ル構造６８を位置付ける前に、データ・ストリーム開始
制御は、交換データ・ストリームの開始を識別するため
に、シェル構造６８の開始シェル制御の前に挿入され、
そして、終了データ・ストリーム制御はデータ・ストリ
ームの終端を識別するために、終了シェル制御の後に、
挿入される。結果のデータ・ストリームは、第６図に示
されているデータ・ストリーム６１であり、それはロー
カル・ストレージ６４に記憶されるシェル構造のリソー
スを作成するために、装置６０によって解釈される。

第７図に示されたエンド・ユーザの装置６０にデータ・
ストリームが到着した後、その装置のオペレータは、そ
のシェル構造が修飾される必要があることを分析し、そ
してシェルを編集するためのアプリケーション７１を始
動させる。スクリーン７０に表示されたアプリケーショ
ン７１はシェル構造の名前を入力することをプロンプト
によってオペレータに知らせる。プロンプトに応答して
、オペレータはキーボードを介してシェルの名前「シェ
ルＡ２（１）Ｊを入力する。シェルＡ２（１）はメモリ
７２に存在していることが表示される。シェルのカスタ
マイゼーション （ｃｕｓｔｏｍｉｚａｔｉｏｎ　）が望まれているので
、オペレータは、「シェルを編集しますか？」というプ
ロンプトに対して「イエス」と応答し、そしてアプリケ
ーション７１は第８図に示したように、スクリーン７０
上にシェル構造６８の内容を表示する。タグを照合した
シェルのコンストラクトの名前４６がデータ・ストリー
ム中で照合された時、オペレータは、異なったプロシー
ジャが呼び出されるのを特定するように、プロシージャ
を選択する。これを達成するために、オペレータはシェ
ル制御パラメータ７４の内容を、プロシージャＰｒｏｃ
Ａ２（Ｔ１）のリファレンスからプロシージャ、Ｐｒｏ
ｃＢｎ（ＴＩ）のリファレンスに変更する。矢印を持っ
た線７３は、シェル制御パラメータ７４からローカル・
ストレージ６４中のプロシージャ７５への照合のリンク
を示している。

第９図はエンド・ユーザの装置６０に到着する通信リン
ク８１上のデータ・ストリーム８０を示している。装置
６０のオペレータは、アプリケーション７１がスクリー
ン７０上に再び表示されることを要求する。アプリケー
ション７１は、そのデータ・ストリームを処理するのに
使用されるべきシェル構造の名前を人力するよう、プロ
ンプトを通じてオペレータに知らせる。オペレータはそ
のプロンプトに応答して、シェルの名前「シェルＡ２（
１）Ｊを入力する。シェルＡ２（１）はアプリケーショ
ン７１の要求によりメモリ７２にロードされる。点線８
２はシェルＡ２（１）がメモリ７２中にロードされるこ
とを示している。既に説明したように、オペレータはシ
ェルを編集する選択権が与えられる。オペレータは、所
望のフォーマツティングの要求を、第８図に示した修飾
処理のときに特定したので、「シェルを編集しますか？
」というプロンプトに応答して「ノー」と入力する。

第５図のデータ・ストリーム１６に示されているように
、データ・ストリーム８０は、ＴＬＥコンポーネントに
遭遇した時にシェルＡ２（１）への照合リンクを活性化
するＴＬＥコンポーネントを含んでいる。矢印を持った
線８３及び８４は、タグ８５とシェル・コンストラクト
名８７との間の照合のリンクと、タグ８６とシェル・コ
ンストラクト名８８との間の照合のリンクとを夫々表わ
している。矢印を持つ線８３によって表わされた照合リ
ンク（連結）の分析（ｒｅｓｏｌｕｔｉｏｎ　）は、ロ
ーカル・ストレージ６４中のプロシージャ７５を呼び出
す。シェル・コンストラクトのパラメータ９０からの点
線８９は、プロシージャ７５の呼び出しを示している。

テキスト・オブジェクト９１は、リファレンス・リンク
８４が分析された時のタグ８６とリンクされたデータ内
容である。第５図において、タグ１と名付けられたシェ
ル・コンストラクト８９はプロシージャＰｒｏｃＡ２（
ＴＩ）ヲ呼び出し、タグＡと名付けられたシェル・コン
ストラクトはイメージ・オブジェクトに結び付けられる
が、オペレータによるシェルのカスタマーゼーションの
ために、タグ１はプロシージャ、ＰｒｏｃＢｎ（ＴＩ）
を呼び出し、そしてタグＡはテキスト・オブジェクトに
リンクされる。

第１０図は、データ・ストリーム中のＴＬＥ＆解釈し、
そして、シェルに従ってデータ・ストリームを処理する
ことが出来るタグ・データ・ストリーム・プロセッサの
論理を説明するための流れ図である。このプロセッサは
、機能ブロック１１０において、初期データ・ストリー
ム試態を設定することによって開始し、次に機能ブロッ
ク１１２において、シェル構造を付勢する。シェル構造
がネットワークの中にストアされているならば、そのシ
ェル構造がアクセスされなければならず、そして、ロー
カルのワークステーションにストアされているのならば
、シェル構造のコピーを付勢するためにアクセスされな
ければならない。機能ブロック１１４において、データ
・ストリームの処理は、次のデータ・ストリームのコマ
ンド、または制御コードを検索することによって開始す
る。機能ブロック１１６において、各コマンド、または
制御コードは、それがタグであるか否かを決定するため
にテストされる。若し、タグでなければ、決定ブロック
１１８において、それがデータ・ストリームの終了コー
ドであるか否かのテストが行われ、若し、それが終了コ
ードでなければ、制御ループは機能ブロック１１４に戻
る。データ・ストリーム中でタグが照合された時、決定
ブロック１２０において、タグがブロック１１２で付勢
された構造とは異なったシェル構造であるか否かを決定
するテストが行われる。若し、異なった構造であれば、
識別されたシェルは、機能ブロック１２４において、シ
ェルのタグの照−合の位置を分析する前に、機能ブロッ
ク１２２において、付勢される。若し、タグが異なった
シェル構造を識別しなければ、制御は機能ブロック１２
４に直接進む。

タグの照合の位置が分析された時、機能ブロック１２６
において、処理規則及びフォーマツティング情報がシェ
ルから検索される。次に、決定ブロック１２８において
、タグに結び付けられたデータの内容の決定が行われる
。次に、決定ブロック１３０において、そのシェルの中
に特別処理の呼び出しがあるか否かについてのテストが
行われる。

若しそうであれば、機能ブロック１３２において、夫々
個別の処理が発生し、その他の場合には、機能ブロック
１３４にデフォルト処理が行われる。

次に、決定ブロック１１８において、データ・ストリー
ムの端部に達したか否かを決定するテストが行われ、若
し端部に達していれば、処理は終了する。

以下のプログラムに関する記載は、データ・スドリーム
中のタグ処理を管理するために、シェル構造を使用する
ワークステーション、又はホスト・コンピュータ中のプ
ロセッサによって使用可能なアプリケーション・プログ
ラムを説明するものである。このプログラムは、ソース
・コード及びオブジェクト・コードを誘導することがで
きるプログラム・デザイン言語（ＰＤＬ）である、以下
の説明において、ワークステーションは少なくともキー
ボードの制御の下にあること、そして、エンド・ユーザ
であるオペレータは、データ・ストリーム中に処理タグ
が組込まれたアプリケーションを始動したこととを前提
としている。データ・ストリームのヘッダ、開始コマン
ド及び制御コードは、現在の状態の環境を設定すること
、組込まれたタグの処理を管理すること、そしてタグに
結び付けられたデータ内容のフォーマツティングを特定
することのために使用されるシェル構造の識別を与える
。

また、シェルの処理があるものと仮定する。この修飾処
理によって、エンド・ユーザは、そのワークステーショ
ンにおいて、フォーマツティングのすべての制限条件を
管理することが出来るし、そしてまた、組込みタグを含
むデータ・ストリームのクリエータ−によって決められ
た条件の代りに、エンド・ユーザによって決められた規
則に従って、タグに結び付けられた情報を処理するルー
チンを、シェルの呼び出しに組込むことが出来る。エン
ド・ユーザは、属性の付加、除去、または修正（即ち、
属性の名前、デフォルト、属性値）、内容データ（デー
タまたはデータを含むリソース・オブジェクト、エクス
プレッションを発生する動的な内容データ）、フォーマ
ツティング指示（データのディスクリブタ、またはリソ
ース・オブジェクトのディスクリブタ、全てのパラメー
タ及びその値を含むデータ・ストリーム・マクロ）、処
理ルーチン（シンタックス・パーザ−、パラメータ及び
その値を通過させることができる外部から呼び出し可能
なルーチン）等にわたってすべて制御することができる
。この修飾処理に開運付けられたユーザのインターフェ
ースは、本発明にとって重要ではなく、この処理を達成
するための多くの方法が知られているので、これ以上の
説明は行わない。

フォーマツティングという意味は、マージン・オフセッ
ト、フォント、アライメント、ジャステイフイケーショ
ン、キャラクタ・スペーシング、クリッピング、画素ス
ペーシング及びタブ・パラメータ等がその例である。内
容データは、例えばテキスト、イメージ、グラフィック
、またはスプレッド・シート、及び評価の際に動的に発
生するオブジェクト・、データ・エクスプレッションの
ようなすべての交換可能なオブジェクト・タイプを含む
。処理ルーチンは、サブルーチンと、エンド・ユーザの
ワークステーションで使用する任意のプロシージャ的言
語、または翻訳可能な言語でコード化されている機能と
を含む。

（始動時のデータ・ストリームの状態は決定されており
、そしてシェル構造はオペレータによって、またはデー
タ・ストリーム中のマスク設定環境制御によって識別さ
れている。シェル識別子可変数（ＳＩＤ）は識別された
シェル構造と同じにセットされている。） Ｃａｌｌ　Ａｃｔｉｖｅ　５ｈｅｌｌ（ＳＩＤ）　（シ
ェル−付勢を呼び出せ（ＳＩＤ）） Ｒｅｐｅａｔ　（繰り返せ） Ｃａｌｌ　Ｐａｒｓｅ　ＤＳｔｒｅａｍ（ＳＦ　Ｔｙｐ
ｅ）（データ・ストリーム（ＤＳｔｒｅａｍ）−パーザ
−（解析）を呼び出せ（ＳＦ−タイプ）） Ｉｆ　ＳＦ　Ｔｙｐｅ　＝　Ｔａｇ　（若しＳＦ−タイ
プ＝タグならば） Ｔｈｅｎ　Ｃａ１ｌ　Ｐａｒｓｅ　ＴＰａｒｍｓ（ＮＳ
ＴＤ）　（タグのパラメータ（ＴＰａｒｍ）−パーザ−
を呼び出せ（ＮＳＩＤ）） Ｉｆ　Ｎ５ＩＤ　ｎｏｔ　ｎｕｌｌ　（若しＮ５ＩＤが
無効でなければ） ｔｈｅｎ　Ｃａ１ｌ　５ａｖｅ　ＩＤ（ＳＩＤ）　（識
別子（ＩＤ）−保存を呼び出せ（ＳＩＤ）） Ｃａｌｌ　Ａｃｔｉｖａｔｅ　５ｈｅｌｌ（ＮＳＩＤ　
）　（シェル−付勢を呼び出せ（ＮＳＩＤ）） Ｅｎｄ　Ｉｆ（Ｉ　Ｆの終了） Ｃａｌｌ　Ｒｅ５ｏｌｖｅ　Ｔｒｅｆ（ＴＮａｍｅ、５
Ｐｔｒ）　（タブのり）アレンス（Ｔｒｅｆ）−分析を
呼び出せ（タブの名前（ＴＮａｍｅ）、シェルのポイン
タ（ＳＰｔｒ）） Ｃａｌｌ　Ｒｅｔｒｉｅｖｅ　５Ｉｎｆｏ（ＳＰｔｒ、
ＳＰａｒｍｓ）　（シェルの情報（ＳＩｎｆｏ）−検索
を呼び出せ（シェルのポインタ、シェルのパラメータ）
） Ｃａｌｌ　Ｄｅｔｅｒｍｉｎｅ　ＴＣｏｎｔｅｎｔ（Ｔ
Ｎａｍｅ、ＴＤａｔａ）　（タグの内容（ＴＣｏｎｔ）
−決定を呼び出せ（タグの名前、タグのデータ（ＴＤａ
ｔａ））Ｉｆ　ＳＰａｒｍｓ　ｃｏｎｔａｉｎ　ｐｒｏ
ｃｅｓｓｉｎｇ　ｃａｌｌｓ（若しシェルのパラメータ
が処理コールを含んでいれば）Ｔｈｅｎ　Ｄｏ　Ｉｎｄ
ｉｖｉｄｕａｌｉｚｅｄ　Ｐｒｏｃｅｓｓｉｎｇ　（個
々の処理を行え） ｅｌｓｅ　Ｄｏ　Ｄｅｆａｕｌｔ　Ｐｒｏｃｅｓｓｉｎ
ｇ（その他の場合、デフォルト処理を行え） ＥｎｄＩＦ　（Ｔ　Ｆの終了） Ｕｎｔｉｌｌ　Ｅｎｄ　ｏｆ　ＤＳｔｒｅａｍ　（デー
タ・ストリーム（ＤＳｔｒｅａｍ）の終了まで） 始動データ・ストリーム状態を設定し、組込みタグの管
理のためのシェル構造を識別した後、システムはシェル
構造を付勢するためのルーチンを呼び出す（シェル−付
勢を呼び出せ（ＳｒＤ）（Ｃａｌｌ　Ａｃｔｉｖｅ　５
ｈｅｌｌ（ＳＩＤ）　）。ＳＩＤはシェルの識別子を含
む出力パラメータである。ＳＩＤを使用して、システム
はローカル・ストレージ、または遠隔ストレージ中の識
別されたシェル構造を位置付け、そのシェル構造をスト
レージからメモリにコピーし、そしてタグ・プロセッサ
によって使用するために、シェルのメモリ位置に操作子
（ポインタ）を戻す。次に、システムはデータ・ストリ
ームを解析するルーチンを呼び出す（データ・ストリー
ム−解析を呼び出せ）（ＳＦ−タイプ）（Ｃａ１ｌ　Ｐ
ａｒｓｅ　ＤＳｔｒｅａｍ　）（ＳＦ　Ｔｙｐｅ　）デ
ータ・ストリームの解析子、即ちパーザ−（ｐａｒｓｅ
ｒ　）は全てのコマンド及び制御コードのデータ・スト
リーム中の開始ポイントを位置付ける。可変数のＳＦ−
タイプ（ＳＦ　　Ｔｙｐｅ）はパーザ−によって遭遇さ
れたコマンド及び制御コードのタイプを返還するのに使
用する出力パラメータである。若し、ＳＦタイプがタグ
でなければ、パーザ−はコマンド、または制御コードの
内容部分全体をスキップするために、コマンド又は制御
ヘッダ中の長さ情報を使用し、これにより、次のコマン
ド、または制御コードを位置付ける。データ・ストリー
ムの終端を特定する制御コードが照合されるまで、デー
タ・ストリーム全体が同様に解析される。データ・スト
リームの終端を特定する制御コードが照合された時点で
タグの処理は終了する。

若しＳＦ　　Ｔｙｐｅがタグであれば、システムはタグ
の範囲内に含まれたデータ・ストリームの内容を処理す
る管理に使用される異なったシェル構造（ＮＳＩＤ）の
仕様をチエツクする組込みタグ制御（タグのパラメータ
ー解析を呼び出せ（ＮＳＩＤ））のパラメータを解析す
るルーチンを呼び出す（Ｃａ１ｌ　Ｐａｒｓｅ　ＴＰａ
ｒｍｓ（ＮＳＩＤ）　）。若し、Ｎ５ＩＤが無効でなけ
れば（即ち、タグのパラメータのパーザ−が有効シェル
構造識別子を返還したこと）、現在の付勢されたシェル
構造の識別子（ＳＩＤ）は、タグの範囲が終了した時に
復帰させるために、保存されねばならない。（識別子（
ＳｌＤ）−保存を呼び出せ）　（Ｃａ１ｌ　５ａｖｅ　
ＩＤ（ＳＩＤ）　）。

現在付勢されているシェル構造を保存した後、システム
はＮ５ＩＤによって識別されたシェル構造を付勢するた
めに、「シェル・ルーチン−付勢を呼び出せＪ　（Ａｃ
ｔｉｖｅ　５ｈｅｌｌ　ｒｏｕｔｉｎｅ　）を呼び出す
。

本発明において、シェル構造は他のシェル構造を照合す
ることができることには、注意を払う必要がある。この
状態は、最後に照合されたシェル構造に適用された修正
を検索するために（例えば、リストの終端にあるシェル
構造識別子）、シェル構造識別子のリンクされたリスト
を横切らせ、これにより新しいシェル構造を作成する。

この場合、例えば、アレー状のリスト、単一のリスト、
または二重にリンクされたリスト、または層試のリスト
のような、より複雑なデータ構造が、保存された識別子
を正しい順序で再付勢するために必要とされる。

シェル構造の付勢の後、システムはシェルの位置を照合
するタグ・ポインタを分析するルーチンを呼び出す（Ｃ
ａｔ　ｌ　Ｒｅ５ｏｌｖｅ　ＴＲｅｆ（ＴＮａｍｅ、　
５Ｐｔｒ）　）。

このルーチンへの入力はタグの名前（ＴＮａｍｅ）であ
り、その出力はタグの名前（ＴＮａｍｅ）により照合さ
れているシェルの位置へのポインタ（ＳＰｔｒ）である
。タグの照合符号を分析した後、システムは、シェル中
の照合された位置から処理規則及びフォーマツティング
情報を検索するためのルーチンを呼び出す（Ｃａｌｌ　
Ｒｅｔｒｉｅｖｅ　５Ｉｎｆ。

（ＳＰｔｒ、ＳＰａｒｍｓ）　）。処理規則及びフォー
マツティング情報はＳＰａｒｍｓのデータ構造に返還さ
れる。

ＳＰａｒｍｓ中のデータのフォーマットは可変数であり
、それは、属性の名前／属性値の対（例えばｒマージン
１０．１マージン７２（右マージンを１０に、そして左
マージンを７２にセットすること））、または、処理規
則又はフォーマツティング情報を含むアーキテクチャさ
れたフォーマットでシステム中にストアされたリソース
・オブジェクトの名前、または、タグ・データ・ストリ
ーム処理アプリケーションによって定義されたコンチク
ストにおいて、システムにより実行することの出来るサ
ブルーチン及び機能の呼び出し等である。

他のルーチンがデータ・ストリーム中のタグ（ＴＮａｍ
ｅ）の範囲を決定するのに呼び出される（　Ｃａ１ｌ　
Ｄｅｔｅｒｍｉｎｅ　ＴＣｏｎｔｅｎｔ（ＴＮａｍｅ、
ＴＤａｔａ）　）。

タグの範囲はシェル構造中で定義されたエレメント階層
によって決定され、そしてデータ・ストリーム中のＴＮ
ａｍｅ及び次のタグとの間に発生するすべてのデータ・
ストリームのコマンド及び制御コードに適用される。Ｔ
Ｄａ　ｔ　ａはタグ範囲に含まれているコマンド及び制
御コードについての情報を含ませるのに用いられる構造
である。

次に、若しＳＰａｒｍｓが処理ルーチンを含んでいるな
らば、これらのルーチンはシステムによって呼び出され
、そしてフォーマツティングの指示は、タグ（ＴＤａｔ
ａ）の範囲内でデータ・ストリーム制御及びコマンドに
適用される。若しシェルが修飾されていれば、実行され
た処理ルーチン及びフォーマツティング指示は、エンド
・ユーザで特定されたものである。若し、シェルが修飾
されていなければ、実行された処理ルーチン及びフォー
マツティング指示はデータ・ストリーム・クリエータに
よって特定されたものである。

この時点で、フォーマットされたデータは、タグ・デー
タ・ストリーム・プロセッサを呼び出したアプリケーシ
ョン・プログラムによって要求された最終フオームに変
換されなければならない。

最終フオームは、対話式デイスプレー、プリンタ、また
は記憶ファイルの何れかのためのものである。

３２７０データ・ストリームのようなデイスプレー・フ
ォーマット、またはポストスクリプト（ｐｏｓｔｓｃｒ
ｉｐｔ　）のようなプリンタ、または交換データ・スト
リームのようなストアされたフォーマットへデータを転
送するために、ルーチン（Ｔｒａｎｓ（転送）　　Ｒｅ
５ｕｌｔｓ（結果））が、呼び出される。

本発明の１つの利点は、伝送効率が文書交換の環境で改
善されることがある６シエル構造によって特定された情
報及びインストラクションは、システム・ネットワーク
中の伝送のためのデータ・ストリーム内に重複させたり
含ませる必要がない。

データ・ストリームの混乱はより少なくなる。

本発明の第２の利点は、シェル構造及びデータ・ストリ
ームが別個のアプリケーション・プログラムによって作
成することが出来ることにある。データ・ストリームを
作成するアプリケ−シコンは、シェルが知っており、デ
ータ・ストリームのタグ付けされたコンストラクトは、
シェル中で適当に名付けられたコンストラクトに闇係付
けられるから、データ・ストリームの内容が修正される
時に、データ・ストリームの内部的な矛盾を生じないよ
うに維持することを保証する。データ・ストリームを管
理する能力はシェルを処理するアプリケーションの部分
にある。

本発明の他の利点は、付加的なタグ・コンストラクトを
データ・ストリーム内で作成することが、容易であるこ
とにある。シェルを処理し、管理するアプリケーション
は、エディターなどで、更に処理するために、アプリケ
ーション中にデータ・ストリームを人力する前に、デー
タ・ストリーム中に、タグを付された任意のコンストラ
クトを作成し、修正し、そして置換することが出来る。

Ｆ０発明の効果 上述したように、本発明は、一方のアプリケーション・
プログラムから他方のアプリケーション・プログラムへ
文書データ、フォーマツティング情報及びリソースを、
高度の融通性を以て伝送し、しかもデータ・ストリーム
の混乱を顕著に減少するデータ・ストリームのアーキテ
クチャを与える。

【図面の簡単な説明】

第１図はデゴタ・ストリームを定義する幾つかのアーキ
テクチャの関係を説明するための図、第２図は本発明の
環境を作る混合オブジェクト文書制御アーキテクチャの
コンポーネント階層を説明するための機能的ブロック図
、第３図はデータ・ストリームによって記述された文書
内のページのエレメントを説明するための図、第４図は
本発明に従ったシェル構造の作成を説明するための図、
第５図は通信リンクを介して装置に送られるサンプル・
データのストリームを示すブロック図であって、シェル
構造の中で夫々に名付けられたコンストラクトの、デー
タ・ストリーム中にあるタグの名前から照合リンクを分
析することにより、タグの処理が、どのように生じるか
を説明するための図、第６図はネットワーク内の２つの
装置の間のシェル構造の交換を示すブロック図、第７図
は第６図のシェル構造に対して、シェル構造修飾処理の
開始を説明するブロック図、第８図は第７図に示したシ
ェル構造のカスタマイゼーションを説明するブロック図
、第９図は第８図に示したエンド・ユーザによってカス
タマイズされたシェルを用いたタグの処理を示すブロッ
ク図、第１０図は本発明に従ったシェル構造を用いたデ
ータ・ストリームを解釈するためのプログラムのロジッ
クを示す流れ図である。 １２・・・・シェル構造、１３．１８・・・・アプリケ
ーション、１４・・・・エンド・ユーザの装置、１５．
６４・・・・ローカル・ストレージ、１６・・・・デー
タ・ストリーム、１７・・・・通信回線、１９・・・・
メモリ、６３・・・・ネットワーク・ストレージ、６５
．６６・・・・システム・ストレージ。 第２図 第１図

Claims (3)

【特許請求の範囲】
1. （１）１つのアプリケーションから別のアプリケーシヨ
   ンへ、文書データ、フオーマツテイング情報及びリソー
   スを、高度の融通性を以て伝送し、しかもデータ・スト
   リームの混乱を減少させるように、ネットワーク上で処
   理され伝送されたデータ・ストリームを管理する方法で
   あつて、 （ａ）フオーマツテイング・シェルを作成する段階と、 （ｂ）データ・ストリーム中に、上記シェルに対するタ
   グを組みこむ段階と、 （ｃ）上記データ・ストリーム中にタグが検出されたと
   きに上記シェルにアクセスすることによつて上記データ
   ・ストリームを処理する段階とを有する、 データ・ストリームの処理方法。
2. （２）データ・ストリームを作成したアプリケーション
   ・プログラムとは独立なデータ・ストリーム・コンスト
   ラクトを伝送し、管理し、処理する方法であつて、 （ａ）送信側から受信側へ伝送するためのデータ・スト
   リームを作成する段階と、 （ｂ）上記送信側において、上記データ・ストリームを
   作成する段階の一部として処理コールを含むシェルを作
   成し、そのとき上記データ・ストリームには上記処理コ
   ールに対するタグが組みこまれるようにする段階と、 （ｃ）上記データ・ストリームと上記シェルを上記受信
   側に別々に伝送する段階と、 （ｄ）上記タグを検出するために上記受信側で上記デー
   タ・ストリームを処理する段階と、 （ｅ）上記シェルから上記タグによつて識別された処理
   コールを検索する段階と、 （ｆ）上記検索された処理コールに従つて上記データ・
   ストリームを処理する段階を有する、 データ・ストリームの処理方法。
3. （３）１つのアプリケーションから別のアプリケーシヨ
   ンへ、文書データ、フオーマツテイング情報及びリソー
   スを、高度の融通性を以て渡すことを可能ならしめるデ
   ータ処理システムにおいてデータ・ストリームを処理お
   よび管理する方法であつて、 （ａ）文書を記述し、フオーマツテイング・タグを組み
   こまれてなるデータ・ストリームを、第１のアプリケー
   ション・プログラムを使用して作成する段階と、 （ｂ）上記フオーマツテイング・タグによつて関連付け
   られる処理コールのシェルを個別に作成する段階と、 （ｃ）第２のアプリケーション・プログラムを使用して
   、上記組みこまれたフオーマツテイング・タグを検出し
   、上記シェルからの上記処理コールにアクセスすること
   によつて上記データ・ストリームを処理する段階とを有
   する、 データ・ストリームの処理方法。