JPWO2006046665A1 - 文書処理装置及び文書処理方法 - Google Patents
文書処理装置及び文書処理方法 Download PDFInfo
- Publication number
- JPWO2006046665A1 JPWO2006046665A1 JP2006543264A JP2006543264A JPWO2006046665A1 JP WO2006046665 A1 JPWO2006046665 A1 JP WO2006046665A1 JP 2006543264 A JP2006543264 A JP 2006543264A JP 2006543264 A JP2006543264 A JP 2006543264A JP WO2006046665 A1 JPWO2006046665 A1 JP WO2006046665A1
- Authority
- JP
- Japan
- Prior art keywords
- document
- name space
- namespace
- unit
- name
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/93—Document management systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/38—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
- G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/205—Parsing
- G06F40/221—Parsing markup language streams
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- General Health & Medical Sciences (AREA)
- Multimedia (AREA)
- Library & Information Science (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Document Processing Apparatus (AREA)
Abstract
マークアップ言語により記述された文書の名前空間を特定する。名前空間検出部310は、処理対象となるXML文書を読込み、名前空間が記述されている行を検出する。正確な名前空間が識別できなかったとき、名前空間特定部312は、名前空間情報格納部316に問い合わせながら、名前空間の検索、特定を行う。名前空間表示部314は、特定された名前空間または名前空間候補などを表示し、後者の場合はユーザが選択できるようにする。名前空間情報格納部316には、名前空間を導出するためのキーとなるXML文書の拡張子や、文書内部に記述されているタグ名などの文字列と、名前空間との対応関係に係る情報をあらかじめ格納しておく。
Description
本発明は、文書処理技術に関し、特に、階層構造を有する構造化文書を処理する文書処理装置及び文書処理方法に関する。
XML(eXtensible Markup Language)は、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、XML文書を作成、表示、編集するためのアプリケーションが開発されている(たとえば、特許文献1参照)。XML文書は、文書型定義などにより定義されたボキャブラリ(タグセット)に基づいて作成されている。
XMLでは、一つの文書の中に複数のボキャブラリが混在することが許されるが、複数のボキャブラリに同一の要素名または属性名が存在する場合、文書内で要素名または属性名が衝突し、いずれのボキャブラリに属する要素型または属性型なのかを特定できない事態が生じる恐れがある。このような問題を解決するために、XMLでは、「名前空間」という概念を導入し、文書内に含まれる要素型および属性型がいずれのボキャブラリに属するものであるかを記述することになっている。
特開2001−290804号公報
しかし、名前空間が適切に記述していない文書を処理する場面も想定される。このような場合であっても、文書を適切に処理できるよう支援する技術が求められる。
本発明はこうした状況に鑑みてなされたものであり、その目的は、名前空間などの情報を識別できない構造化文書に対して適切な処理を行い、表示、編集を滞りなく遂行できる技術を提供することにある。
本発明のある態様は、文書処理装置に関する。この文書処理装置は、マークアップ言語により記述された文書に含まれる構成要素が属する名前空間を検出する名前空間検出部と、前記名前空間検出部において正確な名前空間が検出されなかった際に、前記文書から所定の条件に基づいたキーワードを抽出し、それをもとに前記名前空間を特定する名前空間特定部と、前記キーワードと前記名前空間との対応関係に係る情報を記憶する名前空間情報格納部と、を備え、前記名前空間特定部は前記抽出されたキーワードをもとに、前記名前空間情報格納部を参照することにより前記名前空間を特定し、前記名前空間検出部または前記名前空間特定部において特定された前記名前空間に基づき、前記文書を表示し、ユーザによる前記文書の編集を受け付けることを特徴とする。
マークアップ言語は、XMLの一形態、例えば、XHTML(eXtensible HyperText Markup Language)、SVG(Scalable Vector Graphics)、MathML(Mathematical Markup Language)などであってもよく、SGML(Standard Generalized Markup Language)、HTML(HyperText Markup Language)などであってもよい。キーワードとは文書のファイル名に含まれる拡張子や、文書内に記述された要素名(タグ名)または属性名など、名前空間を推し量ることのできるものでよい。
また、本文書処理装置は、前記データ名特定部において検出された複数の名前空間をユーザに提示し、ユーザがそのいずれかを選択することにより名前空間を特定する、名前空間提示部をさらに含んでもよい。さらに、前記名前空間情報格納部は、過去に処理した文書に含まれる構成要素が属する名前空間と、その文書に含まれるキーワードとの対応関係に係る情報を逐次記憶し、その情報をもとに名前空間特定を行ってもよい。
本発明の別の態様は、文書処理方法に関する。この文書処理方法は、マークアップ言語により記述された文書に含まれる構成要素が属する名前空間を検出するステップと、前記検出するステップにおいて正確な名前空間が識別されなかった際に、前記文書から所定の条件に基づいたキーワードを抽出し、それをもとに、あらかじめ記憶された前記キーワードと前記名前空間との対応関係に係る情報を参照して前記名前空間を特定するステップと、検出または特定された前記名前空間に基づき、前記文書を表示し、ユーザによる前記文書の編集を受け付けるステップと、を含むことを特徴とする。
なお、以上の構成要素の任意の組合せ、本発明の表現をシステム、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、構造化文書の適切な処理を支援する技術を提供することができる。
20 文書処理装置、22 主制御ユニット、24 編集ユニット、30 DOMユニット、32 DOM提供部、34 DOM生成部、36 出力部、40 CSSユニット、42 CSS解析部、44 CSS提供部、46 レンダリング部、50 HTMLユニット、52,62 制御部、54,64 編集部、56,66 表示部、60 SVGユニット、80 VCユニット、82 マッピング部、84 定義ファイル取得部、86 定義ファイル生成部、300 文書処理装置、310 名前空間検出部、312 名前空間特定部、314 名前空間表示部、316 名前空間情報格納部。
以下、本発明の前提となる技術の説明を行った上で、本実施例の詳細を説明する。
(前提技術)
図1は、前提技術に係る文書処理装置20の構成を示す。文書処理装置20は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてXML文書を処理する例について説明する。文書処理装置20は、主制御ユニット22、編集ユニット24、DOMユニット30、CSSユニット40、HTMLユニット50、SVGユニット60、及び変換部の一例であるVCユニット80を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
図1は、前提技術に係る文書処理装置20の構成を示す。文書処理装置20は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてXML文書を処理する例について説明する。文書処理装置20は、主制御ユニット22、編集ユニット24、DOMユニット30、CSSユニット40、HTMLユニット50、SVGユニット60、及び変換部の一例であるVCユニット80を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
主制御ユニット22は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット24は、XML文書を編集するためのフレームワークを提供する。文書処理装置20における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット22又は編集ユニット24によりロードされる。主制御ユニット22又は編集ユニット24は、処理対象となるXML文書の名前空間を参照して、XML文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置20には、HTML文書の表示及び編集を行うHTMLユニット50、SVG文書の表示及び編集を行うSVGユニット60など、ボキャブラリ(タグセット)ごとに表示系及び編集系がプラグインとして実装されており、HTML文書を編集するときはHTMLユニット50が、SVG文書を編集するときはSVGユニット60が、それぞれロードされる。後述するように、HTMLとSVGの双方の構成要素を含む複合文書が処理対象となっている場合は、HTMLユニット50とSVGユニット60の双方がロードされる。
このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。
編集ユニット24は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行(リドゥ)又は実行の取消(アンドゥ)などの処理を制御する。
DOMユニット30は、DOM提供部32、DOM生成部34、及び出力部36を含み、XML文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル(Document Object Model:DOM)に準拠した機能を実現する。DOM提供部32は、編集ユニット24に定義されているインタフェースを満たすDOMの実装である。DOM生成部34は、XML文書からDOMツリーを生成する。後述するように、処理対象となるXML文書が、VCユニット80により他のボキャブラリにマッピングされる場合は、マッピング元のXML文書に対応するソースツリーと、マッピング先のXML文書に対応するデスティネーションツリーが生成される。出力部36は、例えば編集終了時に、DOMツリーをXML文書として出力する。
CSSユニット40は、CSS解析部42、CSS提供部44、及びレンダリング部46を含み、CSSに準拠した表示機能を提供する。CSS解析部42は、CSSの構文を解析するパーサの機能を有する。CSS提供部44は、CSSオブジェクトの実装であり、DOMツリーに対してCSSのカスケード処理を行う。レンダリング部46は、CSSのレンダリングエンジンであり、CSSを用いてレイアウトされるHTMLなどのボキャブラリで記述された文書の表示に用いられる。
HTMLユニット50は、HTMLにより記述された文書を表示又は編集する。SVGユニット60は、SVGにより記述された文書を表示又は編集する。これらの表示/編集系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部(Canvas)56、66、編集指示を含むイベントを送受信する制御部(Editlet)52、62、編集コマンドを受けてDOMに対して編集を行う編集部(Zone)54、64を備える。制御部52又は62が外部からDOMツリーの編集コマンドを受け付けると、編集部54又は64がDOMツリーを変更し、表示部56又は66が表示を更新する。これらは、MVC(Model-View-Controller)と呼ばれるフレームワークに類似する構成をとっており、概ね、表示部56及び66が「View」に、制御部52及び62が「Controller」に、編集部54及び64とDOMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置20では、XML文書をツリー表示形式で編集するだけでなく、それぞれのボキャブラリに応じた編集を可能とする。例えば、HTMLユニット50は、HTML文書をワードプロセッサに類似した方式で編集するためのユーザインターフェースを提供し、SVGユニット60は、SVG文書を画像描画ツールに類似した方式で編集するためのユーザインターフェースを提供する。
VCユニット80は、マッピング部82、定義ファイル取得部84、及び定義ファイル生成部86を含み、あるボキャブラリにより記述された文書を、他のボキャブラリにマッピングすることにより、マッピング先のボキャブラリに対応した表示編集用プラグインで文書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機能を、ボキャブラリコネクション(Vocabulary Connection:VC)と呼ぶ。定義ファイル取得部84は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファイルは、ノードごとに、ノード間の対応(コネクション)を記述する。このとき、各ノードの要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を用いた演算式を記述してもよい。これらの機能については、後で詳述する。マッピング部82は、定義ファイル取得部84が取得したスクリプトファイルを参照して、DOM生成部34にデスティネーションツリーを生成させ、ソースツリーとデスティネーションツリーの対応関係を管理する。定義ファイル生成部86は、ユーザが定義ファイルを生成するためのグラフィカルユーザインターフェースを提供する。
VCユニット80は、ソースツリーとデスティネーションツリーの間のコネクションを監視し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザから編集指示を受け付けると、まずソースツリーの該当するノードを変更する。DOMユニット30が、ソースツリーが変更された旨のミューテーションイベントを発行すると、VCユニット80は、そのミューテーションイベントを受けて、ソースツリーの変更にデスティネーションツリーを同期させるべく、変更されたノードに対応するデスティネーションツリーのノードを変更する。デスティネーションツリーを表示/編集するプラグイン、例えばHTMLユニット50は、デスティネーションツリーが変更された旨のミューテーションイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新する。このような構成により、少数のユーザにより利用されるローカルなボキャブラリにより記述された文書であっても、他のメジャーなボキャブラリに変換することで、文書を表示することができるとともに、編集環境が提供される。
文書処理装置20により文書を表示又は編集する動作について説明する。文書処理装置20が処理対象となる文書を読み込むと、DOM生成部34が、そのXML文書からDOMツリーを生成する。また、主制御ユニット22又は編集ユニット24は、名前空間を参照して文書を記述しているボキャブラリを判別する。そのボキャブラリに対応したプラグインが文書処理装置20にインストールされている場合は、そのプラグインをロードして、文書を表示/編集させる。プラグインがインストールされていない場合は、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する場合、定義ファイル取得部84が定義ファイルを取得し、その定義に従って、デスティネーションツリーが生成され、マッピング先のボキャブラリに対応するプラグインにより文書が表示/編集される。複数のボキャブラリを含む複合文書である場合は、後述するように、それぞれのボキャブラリに対応したプラグインにより、文書の該当箇所がそれぞれ表示/編集される。定義ファイルが存在しない場合は、文書のソース又はツリー構造を表示し、その表示画面において編集が行われる。
図2は、処理対象となるXML文書の例を示す。このXML文書は、生徒の成績データを管理するために用いられる。XML文書のトップノードである構成要素「成績」は、配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞれ、国語、数学、理科、社会の成績を格納する。例えば、名前が「A」である生徒の国語の成績は「90」、数学の成績は「50」、理科の成績は「75」、社会の成績は「60」である。以下、この文書で使用されているボキャブラリ(タグセット)を、「成績管理ボキャブラリ」と呼ぶ。
本前提技術の文書処理装置20は、成績管理ボキャブラリの表示/編集に対応したプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示するためには、前述したVC機能が用いられる。すなわち、成績管理ボキャブラリを、プラグインが用意された別のボキャブラリ、例えば、HTMLやSVGなどにマッピングするための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成するためのユーザインターフェースについては後述することにして、ここでは、既に定義ファイルが用意されているとして説明を進める。
図3は、図2に示したXML文書をHTMLで記述された表にマッピングする例を示す。図3の例では、成績管理ボキャブラリの「生徒」ノードを、HTMLにおける表(「TABLE」ノード)の行(「TR」ノード)に対応づけ、各行の第1列には属性値「名前」を、第2列には「国語」ノードの要素値を、第3列には「数学」ノードの要素値を、第4列には「理科」ノードの要素値を、第5列には「社会」ノードの要素値を、それぞれ対応付ける。これにより、図2に示したXML文書を、HTMLの表形式で表示することができる。また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザがHTMLによる表示画面上で、HTMLユニット50の編集機能により、これらの値を編集することができる。第6列には、国語、数学、理科、社会の成績の加重平均を算出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集時のユーザの利便性を向上させることができる。なお、第6列は、編集不可であることが指定されており、平均点のみを個別に編集することができないようにしている。このように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの誤操作を防ぐことができる。
図4(a)及び図4(b)は、図2に示したXML文書を図3に示した表にマッピングするための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義されたスクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプレートが記述されている。図4(a)(b)の例では、コマンドとして、「生徒の追加」と「生徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テンプレートとして、表の第1行に「名前」、「国語」などの見出しが表示され、第2行以降に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生徒」の内容を表示する行のうち、第6列には、「(src:国語 + src:数学 + src:理科 + src:社会) div 4」という計算式が記述されており、生徒の成績の平均が表示されることを意味する。
図5は、図2に示した成績管理ボキャブラリで記述されたXML文書を、図3に示した対応によりHTMLにマッピングして表示した画面の例を示す。表90の各行には、左から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平均点が表示されている。ユーザは、この画面上で、XML文書を編集することができる。たとえば、第2行第3列の値を「70」に変更すると、このノードに対応するソースツリーの要素値、すなわち、生徒「B」の数学の成績が「70」に変更される。このとき、VCユニット80は、デスティネーションツリーをソースツリーに追従させるべく、デスティネーションツリーの該当箇所を変更し、HTMLユニット50が、変更されたデスティネーションツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「B」の数学の成績が「70」に変更され、更に、平均点が「55」に変更される。
図5に示した画面には、図4(a)(b)に示した定義ファイルに定義されたように、「生徒の追加」及び「生徒の削除」のコマンドがメニューに表示される。ユーザがこれらのコマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。このように、本前提技術の文書処理装置20では、階層構造の末端の構成要素の要素値を編集するのみではなく、階層構造を編集することも可能である。このようなツリー構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応づけられてもよい。また、他のボキャブラリを埋め込むコマンドがユーザに提供されてもよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データを追加することもできる。以上のように、VC機能により、HTMLユニット50の表示/編集機能を利用しつつ、成績管理ボキャブラリで記述された文書を編集することが可能となる。
図6は、ユーザが定義ファイルを生成するために、定義ファイル生成部86がユーザに提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域91には、マッピング元のXML文書がツリー表示されている。画面右側の領域92には、マッピング先のXML文書の画面レイアウトが示されている。この画面レイアウトは、HTMLユニット50により編集可能となっており、ユーザは、画面右側の領域92において、文書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポインティングデバイスにより、画面左側の領域91に表示されたマッピング元のXML文書のノードを、画面右側の領域92に表示されたHTMLによる画面レイアウト中へドラッグ&ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとのコネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、HTML画面の表90の第1行第3列にドロップすると、「数学」ノードと、3列目の「TD」ノードの間にコネクションが張られる。各ノードには、編集の可否が指定できるようになっている。また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定義ファイル生成部86は、画面レイアウトとノード間のコネクションを記述した定義ファイルを生成する。
XHTML、MathML、SVGなどの主要なボキャブラリに対応したビューワやエディタは既に開発されているが、図2に示した文書のようなオリジナルなボキャブラリで記述された文書に対応したビューワやエディタを開発するのは現実的でない。しかし、上記のように、他のボキャブラリにマッピングするための定義ファイルを作成すれば、ビューワやエディタを開発しなくても、VC機能を利用して、オリジナルなボキャブラリで記述された文書を表示・編集することができる。
図7は、定義ファイル生成部86により生成された画面レイアウトの他の例を示す。図7の例では、成績管理ボキャブラリで記述されたXML文書を表示するための画面に、表90と、円グラフ93が作成されている。この円グラフ93は、SVGにより記述される。後述するように、本前提技術の文書処理装置20は、一つのXML文書内に複数のボキャブラリを含む複合文書を処理することができるので、この例のように、HTMLで記述された表90と、SVGで記述された円グラフ93とを、一つの画面上に表示することができる。
図8は、文書処理装置20によるXML文書の編集画面の一例を示す。図8の例では、一つの画面が複数に分割されており、それぞれの領域において、処理対象となるXML文書を異なる複数の表示形式により表示している。領域94には、文書のソースが表示されており、領域95には、文書のツリー構造が表示されており、領域96には、図5に示したHTMLにより記述された表が表示されている。これらのいずれの画面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインが、ソースツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通知するミューテーションイベントのリスナーとして、それぞれの編集画面の表示を担当するプラグインの表示部を登録しておき、いずれかのプラグイン又はVCユニット80によりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行されたミューテーションイベントを受け取って画面を更新する。このとき、プラグインがVC機能により表示を行っている場合は、VCユニット80がソースツリーの変更に追従してデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照してプラグインの表示部が画面を更新する。
例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において編集が行われると、ソース表示用プラグインとツリー表示用プラグインは、変更されたソースツリーを参照して画面を更新し、領域96の画面を担当しているHTMLユニット50は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して画面を更新する。
ソース表示及びツリー表示は、VC機能を利用して実現することもできる。すなわち、ソース、ツリー構造をHTMLによりレイアウトし、そのHTMLにXML文書をマッピングして、HTMLユニット50により表示してもよい。この場合、ソース形式、ツリー形式、表形式の3つのデスティネーションツリーが生成されることになる。いずれかの画面において編集が行われると、VCユニット80は、ソースツリーを変更した後、ソース形式、ツリー形式、表形式の3つのデスティネーションツリーをそれぞれ変更し、HTMLユニット50は、それらのデスティネーションツリーを参照して、3つの画面を更新する。
このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザの利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示により文書の階層構造を把握しつつ、表90などを用いて視覚的に分かりやすい形式で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数の表示形式による画面を同時に表示したが、一つの画面に一つの表示形式による画面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主制御ユニット22が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに指示して表示を切り替える。
図9は、文書処理装置20により編集されるXML文書の他の例を示す。図9に示したXML文書では、SVG文書の「foreignObject」タグの中にXHTML文書が埋め込まれており、さらに、XHTML文書の中にMathMLで記述された数式が入っている。このような場合、編集ユニット24が、名前空間を参照して、適切な表示系に描画作業を振り分ける。図9の例では、編集ユニット24は、まず、SVGユニット60に四角形を描画させ、つづいて、HTMLユニット50にXHTML文書を描画させる。さらに、図示しないMathMLユニットに、数式を描画させる。こうして、複数のボキャブラリを包含する複合文書が適切に表示される。表示結果を図10に示す。
文書編集中、カーソル(キャリッジ)の位置に応じて、表示されるメニューを切り替えてもよい。すなわち、カーソルが、SVG文書が表示された領域内に存在するときは、SVGユニット60が提供するメニュー、又はSVG文書をマッピングするための定義ファイルに定義されたコマンドを表示し、カーソルが、XHTML文書が表示された領域内に存在するときは、HTMLユニット50が提供するメニュー、又はXHTML文書をマッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編集位置に応じて適切なユーザインターフェースを提供することができる。
複合文書において、あるボキャブラリに対応する適切なプラグイン又はマッピング定義ファイルがなかった場合は、そのボキャブラリにより記述された部分は、ソース表示又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を開くとき、埋め込まれた文書を表示するアプリケーションがインストールされていないと、その内容を表示することができなかったが、本前提技術では、表示用のアプリケーションが存在しなくても、テキストデータにより構成されたXML文書をソース表示又はツリー表示することにより内容を把握することができる。これは、テキストベースであるXMLなどの文書ならではの特徴といえる。
データがテキストベースで記述されることの他の利点として、例えば、複合文書中の、あるボキャブラリにより記述される部分において、同一文書内の他のボキャブラリで記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、SVGなどの図に埋め込まれた文字列も検索対象とすることができる。
あるボキャブラリにより記述された文書内に、他のボキャブラリのタグを用いてもよい。このXML文書は、妥当(valid)ではないが、整形式(well-formed)であれば、有効なXML文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、XHTML文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。
図10に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はVCユニット80がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はVCユニット80がリスナーとして登録される。DOM提供部32は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図9に示した文書において、<html>ノードの下位のノードが変更された場合、<html>ノードにリスナーとして登録されたHTMLユニット50にミューテーションイベントが通知されるとともに、その上位の<svg>ノードにリスナーとして登録されたSVGユニット60にもミューテーションイベントが通知される。このとき、HTMLユニット50は、変更されたソースツリーを参照して表示を更新する。SVGユニット60は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。
編集の内容によっては、HTMLユニット50による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、HTMLユニット50による表示領域が以前より大きくなった場合、HTMLユニット50は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
以上の前提技術をもとに、以下実施の形態の詳細について説明する。
以上の前提技術をもとに、以下実施の形態の詳細について説明する。
(実施の形態)
本発明の実施の形態における文書処理装置は、上述の前提技術を基礎として構成されており、前提技術における文書処理装置は基本的に本実施の形態の文書処理装置の一部に含まれるものとする。また本実施の形態では主に、構造化文書の一例としてXMLで構造化された文書ファイルを処理する例について説明する。
本発明の実施の形態における文書処理装置は、上述の前提技術を基礎として構成されており、前提技術における文書処理装置は基本的に本実施の形態の文書処理装置の一部に含まれるものとする。また本実施の形態では主に、構造化文書の一例としてXMLで構造化された文書ファイルを処理する例について説明する。
図11は、本実施の形態に係る文書処理装置300を示す。本図において図1と同一の符号を付した構成は、図1で説明した構成と同一または同様の機能を有する。本実施の形態に係る文書処理装置300において図1に記載のない構成として、主制御ユニット22は、名前空間検出部310、名前空間特定部312、名前空間表示部314を備え、名前空間情報格納部316と接続されている。名前空間検出部310は、処理対象となるXML文書を読込み、名前空間を識別するための情報、例えば名前空間URIが記述されている行を検出する。名前空間を識別するための情報が検出されなかった場合、または検出された名前空間URIが誤りであった場合など、正確な名前空間が識別できなかったとき、名前空間特定部312は、その旨の信号を名前空間検出部310より受け取り、名前空間情報格納部316に問い合わせながら、名前空間の検索、特定を行う。名前空間表示部314は、特定された名前空間または名前空間候補を表示する。候補となる名前空間が最終的に特定されなかった場合は、名前空間表示部314は、例えばXML文書のソースなどを表示してもよい。名前空間情報格納部316には、名前空間を導出するためのキーとなる文字列、例えば処理対象となるXML文書のファイル名に含まれる拡張子や、文書内部に記述されている要素名や属性名などと、名前空間との対応関係を表す情報をあらかじめ格納しておく。対応関係を表す情報については後述するが、例えば、拡張子「html」に対して、名前空間URI「http://www.w3.org/1999/xhtml」を対応付けたテーブルなどである。以後、名前空間情報格納部316には拡張子またはタグ名と、名前空間との対応関係を表す情報が格納されているとして説明する。
図12は名前空間特定部312が名前空間情報格納部316との連携により、名前空間を特定する手順を示すフローチャートである。まず、名前空間検出部310より、処理対象のXML文書中に正確な名前空間を識別できなかった旨の信号を受け取ると(S10)、XML文書のファイル名から拡張子を取得する(S12)。取得された拡張子をもとに、名前空間情報格納部316に問い合わせを行い、当該拡張子に対応付けられている名前空間を検索する(S14)。拡張子に対応した名前空間が唯一存在する場合(S16のY)、その名前空間のデータを名前空間表示部314へ送出する(S18)。名前空間情報格納部316において当該拡張子の対応付けが存在しない場合、または複数の名前空間が検出された場合(S16のN)、XML文書中に含まれる構成要素の要素名(タグ名)の抽出を行う(S20)。ここでの抽出はタグ名以外に属性名でもよい。以後、それらのキーワードを代表して、タグ名を用いて説明を行う。タグ名が抽出されたら(S22のY)抽出されたタグ名に基づき、後述するような所定の手法により名前空間の検出を行い(S24)、名前空間が得られた場合は(S26のY)、そのデータを名前空間表示部314へ送出する(S28)。抽出された全てのタグ名に対して、それに対応する名前空間の情報が名前空間情報格納部316に存在しなかった場合など、名前空間が検出できなかったときや(S26のN)、タグ名が抽出されなかったとき(S22のN)は、対応付け不在信号を名前空間表示部314へ送信する(S30)。
名前空間表示部314では、名前空間特定部312において唯一特定された名前空間の表示を行い、ユーザが最終的に確認を行えるようにしてもよい。このようにして特定された名前空間を参照し、前提技術と同様に、主制御ユニット22または編集ユニット24において、XML文書のボキャブラリを判別し、そのボキャブラリに対応した表示又は編集用のプラグインを利用して表示や編集を実行する。ここで、特定された名前空間のボキャブラリを処理するプラグインが当該文書処理装置にインストールされていない場合は、プラグインのロードを促すメッセージをユーザに示したり、自動的にダウンロードさせるようにしてもよい。
以上の構成により、名前空間の記載がなかったり、誤記があったりしたXML文書を処理したときでも、ファイルの拡張子や文書中の要素名、属性名などから自動的に名前空間を特定することが可能となるため、ユーザが文書中、名前空間のない箇所を捜索したり、名前空間の検索を自ら行ったりする手間をかけることなく、文書処理を続行させることができる。従って処理にかかる時間的コストが軽減される。さらに本実施の形態は、このようなXML文書を読込んだときに発生しがちなシステムダウンを回避する措置としても位置づけられ、ユーザに対して原因および解決策を提示することができるため、理解し易く、親しみやすい文書処理装置となる。
名前空間特定部312では、名前空間候補が複数存在する場合に、その最終的な特定を自動的に行わずに、名前空間表示部314に表示するようにしてもよい。例えば図12のS16では、唯一検出された名前空間のみS18におけるデータ送出対象としたが、複数検出された場合でもそのデータを名前空間表示部314へ送出し、全ての候補を表示するようにしてもよい。このときユーザはそれらの中から適切な名前空間を選択し、設定を行えるようにしてもよい。また、後述する計算手法により確率を計算し、確率の高い名前空間をいくつか表示するようにしてもよい。
このように、拡張子やタグ名など、複数のキーワードから名前空間を特定する場合は、検出された名前空間の確率計算を行ったりすることで、名前空間特定に対する確度が増す。また、名前空間の自動的な特定ができなかった場合でも、名前空間の候補を絞り込みユーザに提示することで、ユーザが全ての作業を行う場合に比べ、その手間が軽減される。
上述した拡張子からの検索や、タグ名からの検索は、先にタグ名からの検索を行ったり、どちらか一方のみを行うなど、任意の組み合わせ方でよい。また、検索キーは拡張子や要素名、属性名に限定されるものではない。
名前空間表示部314は、名前空間特定部312からの対応付け不在信号を受け取ると、処理中のXML文書のソースファイルをそのまま表示し、名前空間が検出されない旨の表示をユーザに対して行ってもよい。さらにユーザが名前空間を識別するための記述を挿入するなどXML文書を直接修正できるようにしてもよい。
ここで、名前空間特定部312において名前空間を特定、またはその候補を絞り込む手法について具体的に説明する。図13は名前空間を識別するための情報である、URIの記載がないXHTML文書の例である。図13に示した文書の例では、<head>、<title>、<body>といった要素型が属する名前空間を識別するための情報が記載されていない。このように、XHTML文書などの一般的な文書において名前空間を推測する場合は、ルールベースの手法により名前空間の特定を行うのが現実的である。
図14は、ルールベースの手法で参照される、名前空間情報格納部316に格納されたテーブルの構成例400を示す。このテーブルは、拡張子名欄400a、名前空間情報欄400bより構成されている。このテーブルを参照し名前空間を特定するステップは、図12のS14に相当する。例えば、処理対象となる文書のファイル名が「bunsho.html」であった場合、拡張子「html」に基づきこのテーブルを検索することにより、名前空間を示すURIが「http://www.w3.org/1999/xhtml」であることが特定される。この検索手法は、当該文書が単独のXMLファイルとして提供されており、非複合文書である場合には、計算コストが少なく有効である。
拡張子からの検索によって複数の名前空間が検出されたときや、名前空間が検出されなかった場合などは、図14に示したテーブルの構成例400のうち拡張子名欄400aの代わりにタグ名欄を構成要素としたテーブルを参照して、ルールベースの手法を適用してもよい。このステップは、図12のS24に相当する。例えば、図13に示したXML文書では、ルートノードのタグ名が「html」である。それに基づき図14と同様のテーブルを参照することにより、名前空間が「http://www.w3.org/1999/xhtml」と特定される。ユーザまたはシステム構築者は、図14に示したようなテーブルをあらかじめ作成し、名前空間情報格納部316に格納する。
ルートノードのタグ名によって検出された名前空間が複数ある場合などは、さらに下位の階層の構成要素について同様の特定を行ってもよい。このとき、名前空間情報格納部316には、例えば、第1層タグ名欄、第2層タグ名欄および名前空間情報欄が設けられたテーブルを格納してもよい。図13に示したXHTML文書の場合は、例えば第1層のタグ名が「html」であり、第2層のタグ名が「head」、「title」、「body」であることに基づき、名前空間情報格納部316に記憶されたテーブルを検索し、名前空間を特定する。その他の例として、第1層のタグ名が「svg」であり、第2層のタグ名が「desc」、「rect」、「polyline」などであったらSVGで記述されている、第1層のタグ名が「math」であり、第2層のタグ名が「mi」、「mo」、「mfrac」であったらMathMLで記述されている、というように名前空間を特定してよい。このように、検索キーとなるタグ名の階層を増やすことにより、名前空間特定の確度を上げることができ、また、候補の絞込みを効率よく行うことができる。なお、これまでの記述では、拡張子、第1層のタグ名、第2層のタグ名というように段階的に検索キーを増加させていったが、最初から拡張子および複数層のタグ名を検索キーとしてもよいし、タグ名のみを検索キーとしてもよい。
名前空間情報格納部316には、名前空間の記載があるXML文書などを文書処理装置にあらかじめ学習させ、その文書が参照した名前空間と、その文書中のタグ名やファイルの拡張子などとの対応関係の情報を保持する、教師有り学習を行う確率的分類器(図示せず)をさらに設けてもよい。教師有り学習を行う確率的分類器には、ベイズの定理やSVM(Support Vector Machine)など既存の手法を適用してよい。
以下に、ベイズの定理によって名前空間を絞り込む簡単な計算例を示す。まず、SVGのファイルを判定する教師データとして、「svg」要素が1回、「desc」要素が3回、「rect」要素が3回出現するファイルを分類器に学習させたとする。これを分類Aとする。次に、MathMLを判定する教師データとして、「math」要素が1回、「mi」要素が4回、「mfrac」要素が2回出現するファイルを学習させたとする。これを分類Bとする。ここで、名前空間が識別できず、「desc」要素が3回、「rect」要素が1回、「mi」要素が1回出現する文書Cを処理したとする。このとき、文書Cの名前空間が分類A、分類Bである確率は、ベイズの定理を用いてそれぞれ、
P(A|C)=P(C&B)/P(C)
=P(B)×P(C|A)/(P(A)×P(C|A)+P(B)×P(C|B))
=0.75
P(B|C)=0.25
と求められる。これにより、文書Cの名前空間は分類AのSVGである確率が高いことがわかる。例えば図13に示したXHTML文書の場合、図15に示した名前空間URIの記載のあるXHTML文書などをあらかじめ教師データとして学習させておけば、名前空間URIが「http://www.w3.org/1999/xhtml」であることが、上記のような確率計算に基づき特定できる。
P(A|C)=P(C&B)/P(C)
=P(B)×P(C|A)/(P(A)×P(C|A)+P(B)×P(C|B))
=0.75
P(B|C)=0.25
と求められる。これにより、文書Cの名前空間は分類AのSVGである確率が高いことがわかる。例えば図13に示したXHTML文書の場合、図15に示した名前空間URIの記載のあるXHTML文書などをあらかじめ教師データとして学習させておけば、名前空間URIが「http://www.w3.org/1999/xhtml」であることが、上記のような確率計算に基づき特定できる。
上述のごとき確率的な手法では、タグ名の出現回数から名前空間候補を確率で順位付けできるため、例えば確率の上位3つを名前空間候補としたり、確率が50%以上など所定のしきい値を設定してそれ以上の確率を有する名前空間を候補としたりして、名前空間表示部314に表示してもよい。ユーザがそれらの名前空間候補の中から選択することにより、名前空間の最終的な特定を行ってもよい。
図16は名前空間URIの記載がない、日記タグを用いたXML文書の例である。このような独自のボキャブラリを識別するときは、例えば、あらかじめ図17に示すような名前空間URIの記載のあるXML文書を学習させておけば、上述した確率的手法が有効である。この場合、過去に処理した、名前空間識別情報について記載のある文書を全て学習させておけば、ある文書処理装置を使用するユーザの処理内容の傾向に応じた確率計算を行うことができ、名前空間の候補を効率よく絞り込むことができる。
これまで述べてきた名前空間の特定手法は、XML文書などの他、XSL(eXtensible Stylesheet Language)などの言語による文書にもそのまま適用できる。その例として、図18は、図17のXML文書において指定されたXMLスタイルシートのファイル「case2.xsl」の内容を示している。この場合は、「http://xmlns.justsystem.co.jp/diary」なる名前空間URIが記載されているため、図17に示したXML文書の表示、編集は滞りなく行われる。
次に、図17と同様のXML文書の例を図19に示す。ここでは、スタイルシートのファイルとして「case2b.xsl」が指定されている。図20にそのスタイルシートファイル「case2b.xsl」の内容を示す。図18のスタイルシートファイル「case2.xsl」と比較すると、図20のスタイルシートでは、名前空間URIが「http://xmlns.justsystem.co.jp/dialy」となっており、「diary」のつづりに誤りがあることがわかる。このように、名前空間識別情報の記載はあるが誤っている場合などは、名前空間特定部312は、類似の名前空間を探すようにしてもよい。この場合、名前空間情報格納部316にあらかじめ、名前空間リストを記憶させておき、その中から文書に記載の誤った名前空間と最も類似性の高い名前空間を検出するようにしてもよい。ここで類似性の判断には、編集距離(レーベンシュタイン距離)を数え上げるなど、既存の手法を適用してよい。
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、その各構成要素や各処理プロセスの組合せにいろいろな変形が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下、変形例を挙げる。
実施の形態では、XML文書を処理する例について説明したが、本実施例の文書処理装置300は、他のマークアップ言語、例えば、SGML、HTMLなどで記述された文書も同様に処理可能である。
実施の形態では、まず名前空間を特定することにより、そのボキャブラリに対応したプラグインをロードし、文書を表示/編集させる通常の処理を可能にしたが、同様の手続きにより名前空間に代えて候補となるプラグインをユーザに提示し、ユーザが選択したプラグインによって文書を表示/編集させてもよい。
本発明は、構造化文書を処理する装置に利用することができる。
Claims (7)
- マークアップ言語により記述された文書に含まれる構成要素が属する名前空間を検出する名前空間検出部と、
前記名前空間検出部において正確な名前空間が検出されなかった際に、前記文書から所定の条件に基づいたキーワードを抽出し、それをもとに前記名前空間を特定する名前空間特定部と、
前記キーワードと前記名前空間との対応関係に係る情報を記憶する名前空間情報格納部と、
を備え、
前記名前空間特定部は前記抽出されたキーワードをもとに、前記名前空間情報格納部を参照することにより前記名前空間を特定し、
前記名前空間検出部または前記名前空間特定部において特定された前記名前空間に基づき、前記文書を表示し、ユーザによる前記文書の編集を受け付けることを特徴とする文書処理装置。 - 前記キーワードは、前記文書のファイル名に含まれる拡張子であることを特徴とする請求項1に記載の文書処理装置。
- 前記キーワードは、前記構成要素の要素名または属性名であることを特徴とする請求項1または2に記載の文書処理装置。
- 前記名前空間特定部において検出された複数の名前空間をユーザに提示する名前空間提示部をさらに備え、前記名前空間特定部はユーザによって前記複数の名前空間より選択された名前空間を、前記特定された名前空間とすることを特徴とする請求項1から3のいずれかに記載の文書処理装置。
- 前記名前空間情報格納部は、過去に処理した文書に含まれる構成要素が属する名前空間と、その文書に含まれるキーワードとの対応関係に係る情報を逐次記憶していくことを特徴とする請求項1から4のいずれかに記載の文書処理装置。
- マークアップ言語により記述された文書に含まれる構成要素が属する名前空間を検出するステップと、
前記検出するステップにおいて正確な名前空間が識別されなかった際に、前記文書から所定の条件に基づいたキーワードを抽出し、それをもとに、あらかじめ記憶された前記キーワードと前記名前空間との対応関係に係る情報を参照して前記名前空間を特定するステップと、
検出または特定された前記名前空間に基づき、前記文書を表示し、ユーザによる前記文書の編集を受け付けるステップと、
を含むことを特徴とする文書処理方法。 - マークアップ言語により記述された文書に含まれる構成要素が属する名前空間を検出する機能と、
前記検出するステップにおいて正確な名前空間が識別されなかった際に、前記文書から所定の条件に基づいたキーワードを抽出し、それをもとに、あらかじめ記憶された前記キーワードと前記名前空間との対応関係に係る情報を参照して前記名前空間を特定する機能と、
検出または特定された前記名前空間に基づき、前記文書を表示し、ユーザによる前記文書の編集を受け付ける機能と、
をコンピュータに実現させることを特徴とするコンピュータプログラム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004312835 | 2004-10-27 | ||
JP2004312835 | 2004-10-27 | ||
PCT/JP2005/019824 WO2006046665A1 (ja) | 2004-10-27 | 2005-10-27 | 文書処理装置及び文書処理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPWO2006046665A1 true JPWO2006046665A1 (ja) | 2008-05-22 |
Family
ID=36227907
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006543264A Pending JPWO2006046665A1 (ja) | 2004-10-27 | 2005-10-27 | 文書処理装置及び文書処理方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20080141112A1 (ja) |
JP (1) | JPWO2006046665A1 (ja) |
WO (1) | WO2006046665A1 (ja) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007148944A (ja) * | 2005-11-30 | 2007-06-14 | Ricoh Co Ltd | 通信端末装置 |
US8140969B2 (en) * | 2007-12-03 | 2012-03-20 | International Business Machines Corporation | Displaying synchronously documents to a user |
JP5690349B2 (ja) * | 2009-11-13 | 2015-03-25 | アビニシオ テクノロジー エルエルシー | レコード形式情報の管理 |
CN102169431A (zh) * | 2010-02-26 | 2011-08-31 | 国际商业机器公司 | 用于优化用户界面的生成的方法与装置 |
US11385954B2 (en) * | 2019-01-28 | 2022-07-12 | Yahoo Assets Llc | Graphical management of big data pipelines |
CN112740635B (zh) * | 2019-02-21 | 2022-04-05 | 华为技术有限公司 | 报文解析的方法、数据发送端、数据接收端和系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001101049A (ja) * | 1999-09-28 | 2001-04-13 | Mitsubishi Electric Corp | ファイル復元装置 |
JP2001290803A (ja) * | 2000-04-07 | 2001-10-19 | Just Syst Corp | 文書処理方法、文書処理装置、および記録媒体 |
US20040002937A1 (en) * | 2002-06-27 | 2004-01-01 | Microsoft Corporation | System and method for providing namespace related information |
JP2004017418A (ja) * | 2002-06-14 | 2004-01-22 | Brother Ind Ltd | 印刷装置、プリンタ装置、レイアウト装置、及びレンダリング装置 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040062937A1 (en) * | 2002-09-16 | 2004-04-01 | Amorim Industrial Solutions, Inc. | Flooring system underlayment |
US7120864B2 (en) * | 2004-01-27 | 2006-10-10 | International Business Machines Corporation | Eliminating superfluous namespace declarations and undeclaring default namespaces in XML serialization processing |
US7559020B2 (en) * | 2004-12-30 | 2009-07-07 | Microsoft Corporation | Methods and systems for preserving unknown markup in a strongly typed environment |
-
2005
- 2005-10-27 US US11/576,239 patent/US20080141112A1/en not_active Abandoned
- 2005-10-27 JP JP2006543264A patent/JPWO2006046665A1/ja active Pending
- 2005-10-27 WO PCT/JP2005/019824 patent/WO2006046665A1/ja active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001101049A (ja) * | 1999-09-28 | 2001-04-13 | Mitsubishi Electric Corp | ファイル復元装置 |
JP2001290803A (ja) * | 2000-04-07 | 2001-10-19 | Just Syst Corp | 文書処理方法、文書処理装置、および記録媒体 |
JP2004017418A (ja) * | 2002-06-14 | 2004-01-22 | Brother Ind Ltd | 印刷装置、プリンタ装置、レイアウト装置、及びレンダリング装置 |
US20040002937A1 (en) * | 2002-06-27 | 2004-01-01 | Microsoft Corporation | System and method for providing namespace related information |
Also Published As
Publication number | Publication date |
---|---|
US20080141112A1 (en) | 2008-06-12 |
WO2006046665A1 (ja) | 2006-05-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20100107048A1 (en) | Document processor and document processing method | |
US20100100807A1 (en) | Data processing device, and data processing method | |
US20090083300A1 (en) | Document processing device and document processing method | |
JPWO2006137562A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006046665A1 (ja) | 文書処理装置及び文書処理方法 | |
US20070198915A1 (en) | Document Processing Device And Document Processing Method | |
JPWO2005098658A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006051869A1 (ja) | 文書処理装置及び文書処理方法 | |
WO2007081017A1 (ja) | 文書処理装置 | |
JP4566196B2 (ja) | 文書処理方法および装置 | |
US20080005662A1 (en) | Server Device and Name Space Issuing Method | |
JP4627530B2 (ja) | 文書処理方法および装置 | |
JPWO2005098662A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2005098661A1 (ja) | 文書処理装置及び文書処理方法 | |
US20090287994A1 (en) | Document processing device and document processing method | |
US20080005085A1 (en) | Server Device and Search Method | |
JP4417384B2 (ja) | 文書処理装置および文書処理方法 | |
JPWO2006051974A1 (ja) | 文書処理装置および文書処理方法 | |
JP2007183849A (ja) | 文書処理装置 | |
JPWO2005098698A1 (ja) | 文書処理装置 | |
US20090083620A1 (en) | Document processing device and document processing method | |
JPWO2005098659A1 (ja) | 文書処理装置及び文書処理方法 | |
JP4719743B2 (ja) | グラフ処理装置 | |
JPWO2006046664A1 (ja) | 時間共有管理装置、文書作成装置、文書閲覧装置、時間共有管理方法、文書作成方法および文書閲覧方法 | |
JP2008257277A (ja) | 文書処理装置、方法、及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090915 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091113 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100302 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100914 |