WO2006121051A1 - 文書処理装置および文書処理方法 - Google Patents

文書処理装置および文書処理方法 Download PDF

Info

Publication number
WO2006121051A1
WO2006121051A1 PCT/JP2006/309337 JP2006309337W WO2006121051A1 WO 2006121051 A1 WO2006121051 A1 WO 2006121051A1 JP 2006309337 W JP2006309337 W JP 2006309337W WO 2006121051 A1 WO2006121051 A1 WO 2006121051A1
Authority
WO
WIPO (PCT)
Prior art keywords
tag
document
entity
annotation
name
Prior art date
Application number
PCT/JP2006/309337
Other languages
English (en)
French (fr)
Inventor
Nobuyuki Otomori
Yusuke Fujimaki
Yasuo Akai
Toshio Ueda
Original Assignee
Justsystems Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Justsystems Corporation filed Critical Justsystems Corporation
Priority to JP2007528290A priority Critical patent/JP5073494B2/ja
Priority to US11/913,602 priority patent/US20090070295A1/en
Publication of WO2006121051A1 publication Critical patent/WO2006121051A1/ja

Links

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/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G06F16/88—Mark-up to mark-up conversion
    • 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/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/151—Transformation
    • G06F40/157—Transformation using dictionaries or tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting

Definitions

  • the present invention relates to a data processing technique, and more particularly to a technique for processing document data in a structured manner.
  • V knowledge management which utilizes personal knowledge and information throughout the organization, has become an important management technique.
  • Many companies have in-house database systems that store information from employees in electronic files.
  • employees also access the files stored in this in-house database via the network.
  • the work efficiency of the entire organization can be improved.
  • HTML Hyper Text Markup
  • HTML is a language for describing web pages.
  • HTML is a type of markup language that defines how document files are displayed.
  • XML like HTML, is not a language that aims to describe web pages directly, but rather a language that has a function to define the data structure of data contained in a document file. I can say that.
  • Document files created in XML are displayed as web pages by giving display layout information separately. In other words, in the XML document, the data structure and its display layout can be handled separately.
  • a language for generating markup languages, such as XML is also called a metalanguage.
  • XML is a format suitable for sharing data with others over a network.
  • Applications that create, display, and edit XML documents are being developed (see, for example, Patent Document 1).
  • An XML document is created based on a vocabulary (tag set) defined by a document type definition or the like.
  • Patent Document 1 Japanese Patent Laid-Open No. 2001-290804
  • the security administrator checks personal information contained in document files such as forms that are handled by each department.
  • An object of the present invention is to provide a technique for improving user convenience in handling data contained in a plurality of structure document files.
  • a document processing apparatus holds a child document file generated by a schema that inherits the schema of a parent document file in which a plurality of tags are structured.
  • the user to specify the name of the entity tag that is the tag of the child document file inherited from the model tag that is the tag included in the parent document file
  • a tag renaming processing unit that changes according to input, and a tag mapping table that holds a tag mapping table that associates the name of the entity tag contained in the child document file with the name of the model tag from which the entity tag is inherited
  • a search instruction input by the user using the model tag name as a search key the tag mapping table is referenced and the corresponding entity tag name is detected, and the entity tag name is used as a new search key.
  • a tag data search unit for detecting data of the entity tag.
  • the apparatus may further include a filtering processing unit that classifies the tags included in the document file according to a filtering condition that defines a tag type to be filtered.
  • This filtering processing unit specifies a model tag to be classified and extracted according to the filtering condition, and instructs the tag data searching unit to detect the data of the actual tag using the name of the model tag as a search key.
  • tag data to be filtered may be classified and extracted.
  • a tag for inputting data that is not suitable for display or transmission to the outside is defined as a filtering condition
  • the data having such a specific attribute is stored in the document file card. It becomes easy to extract from.
  • This apparatus detects a model tag that is an inheritance source of an entity tag designated by a user with reference to a tag mapping table, and refers to a plurality of tag mapping tables held in a tag mapping table holding unit.
  • a related tag search unit that detects other entity tags that inherit the model tag may be further provided.
  • Another embodiment of the present invention is also a document processing device.
  • This device includes a file holding unit that holds a child document file generated by a schema that inherits the schema of a parent document file in which a plurality of tags are structured, and a model that is an annotation included in the parent document file.
  • the annotation rename processing unit that changes the name of the entity annotation that is the annotation of the child document file that has inherited the annotation power according to the user's instruction input, and the name of the entity annotation included in the child document file
  • the annotation mapping table holding section that holds the annotation mapping table that associates the name of the model annotation that is the inheritance source of the entity annotation, and the data specified by the user included in the child document file
  • An annotation setting section for setting a body annotation and a search instruction input by the user using the model annotation name as a search key, the corresponding entity annotation name is detected by referring to the annotation mapping table.
  • the apparatus may further include a file transmission unit that transmits the child document file to an external apparatus.
  • the annotation data search unit uses the model annotation set in the data to be prohibited from external transmission among the data contained in the child document file as a search key, and the child document filter also detects the data and sends the file.
  • the department may suppress transmission of the detected data to the external device.
  • Another embodiment of the present invention is also a document processing device.
  • This device detects the entity tag included in the structured document file and the document acquisition unit that acquires the structured document file described by the entity tag belonging to the predetermined tag set, and is different from the predetermined tag set.
  • Correspondence detection unit that detects model tags that have a predetermined relationship with the detected entity tags among the model tags that belong to the tag set, and mapping that records the entity tags and model tags that have a predetermined relationship in the tag mapping table
  • Tag search that detects the element data of the entity tag that is associated with the tag mapping table when the user inputs search input using the recording unit and model tag as a search key.
  • the apparatus includes a data display unit for displaying data included in the structured document file on a screen;
  • the entity tag associated with the tag mapping table is detected and specified in the structure file by the entity tag. And a display control unit that excludes the element data to be displayed from the display target force.
  • the correspondence detection unit of this apparatus refers to a synonym data table in which a combination of words having a synonym relation is defined, and a model of a name having a synonym relation with the name of the detected entity tag The tag may be detected as a model tag with a predetermined relationship.
  • the correspondence detection unit of this device refers to a concept data table in which a combination of words having a relationship between a superordinate concept and a subordinate concept is defined.
  • a model tag with a name corresponding to a superordinate concept may be detected as a model tag having a predetermined relationship.
  • FIG. 1 is a diagram showing a configuration of a document processing apparatus according to a prerequisite technology.
  • FIG. 2 is a diagram showing an example of an XML document to be processed.
  • FIG. 3 is a diagram showing an example of mapping the XML document shown in FIG. 2 to a table described in HTML.
  • FIG. 4 (a) is a diagram showing an example of a definition file for mapping the XML document shown in FIG. 2 to the table shown in FIG.
  • FIG. 4 (b) is a diagram showing an example of a definition file for mapping the XML document shown in FIG. 2 to the table shown in FIG.
  • FIG. 5 is a diagram showing an example of a screen displayed by mapping the XML document described in the grade management vocabulary shown in FIG. 2 to HTML according to the correspondence shown in FIG.
  • FIG. 6 is a diagram showing an example of a graphical user interface that the definition file generation unit presents to the user in order for the user to generate a definition file.
  • FIG. 7 is a diagram showing another example of the screen layout generated by the definition file generation unit.
  • FIG. 8 is a diagram showing an example of an XML document editing screen by the document processing apparatus.
  • FIG. 9 is a diagram showing another example of an XML document edited by the document processing apparatus.
  • FIG. 10 is a diagram showing an example of a screen displaying the document shown in FIG.
  • FIG. 11 (a) is a diagram showing a basic configuration of a document processing system.
  • FIG. 11 (b) is a diagram showing a block diagram of the entire document processing system.
  • FIG. 11 (c) is a diagram showing a block diagram of the entire document processing system.
  • FIG. 13 is a diagram showing details of the vocabulary connection subsystem.
  • FIG. 14 is a diagram showing details of the relationship between the program starter and other components.
  • FIG. 15 is a diagram showing the details of the structure of the application service loaded by the program startup unit.
  • FIG. 16 is a diagram showing details of the core component.
  • ⁇ 17 It is a diagram showing details of the document management unit.
  • FIG. 18 is a diagram showing details of an undo framework and an undo command.
  • FIG. 19 is a diagram showing how a document is loaded in the document processing system.
  • FIG. 21 is a diagram showing a relationship between a model and a controller.
  • FIG. 22 is a diagram showing details of the plug-in sub-system, the library connection, and the connector.
  • FIG. 23 shows an example of a VCD file.
  • FIG. 24 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 25 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 26 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 27 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 28 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 29 is a diagram showing a command flow.
  • FIG. 30 is a schematic diagram showing a layer cake of the semantic web.
  • FIG. 32 is a diagram showing a flow of the personal information management support system in the present embodiment.
  • FIG. 33 is a schematic diagram for explaining scene 1 in FIG. 32 in detail.
  • FIG.34 Relationship between global ontology and local ontology in the research department It is a figure.
  • FIG.35 A diagram showing the relationship between global and local ontologies in the sales department.
  • FIG. 36 is a schematic diagram for explaining an aspect in which annotation is given to a child document file.
  • FIG. 37 is a schematic diagram for explaining security management by annotation.
  • FIG. 38 is a diagram showing another example of the tag mapping table described in relation to FIG. 34 and FIG.
  • FIG. 39 is a functional block diagram of a document processing apparatus that implements a mapping function between an entity tag and a model tag while using various functions of the document processing apparatus described in the base technology.
  • FIG. 40 is a schematic diagram for explaining a mapping structure of model tags and entity tags. Explanation of symbols
  • FIG. 1 shows the configuration of the document processing apparatus 20 according to the base technology.
  • the document processing apparatus 20 processes a structured document in which data in the document is classified into a plurality of components having a hierarchical structure.
  • an example of processing an XML document as an example of a structured document is used. I ’ll explain it.
  • the document processing apparatus 20 includes a main control unit 22, an editing unit 24, a DOM unit 30, a CSS unit 40, an HTML unit 50, an SVG unit 60, and a VC unit 80 which is an example of a conversion unit.
  • these configurations are the power realized by the CPU, memory, and programs loaded in the memory of any computer.
  • functional blocks realized by their cooperation are depicted. Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.
  • the main control unit 22 provides a framework for loading plug-ins and executing commands.
  • the editing unit 24 provides a framework for editing XML documents.
  • the document display and editing functions in the document processing device 20 are realized by plug-ins, and necessary plug-ins are loaded by the main control unit 22 or the editing unit 24 according to the document type.
  • the main control unit 22 or the editing unit 24 refers to the name space of the XML document to be processed, determines whether the XML document is described by a misplaced library, and displays or displays the document corresponding to the missing library. Load the editing plug-in to display or edit.
  • the document processing device 20 has a display system and an editing system plug-in for each vocabulary (tag set) such as an HTML unit 50 that displays and edits HTML documents and an SVG unit 60 that displays and edits SVG documents.
  • the HTML unit 50 is loaded when editing an HTML document
  • the SVG unit 60 is loaded when editing an S VG document.
  • both HTML unit 50 and SVG unit 60 are loaded.
  • the user can select and install only the necessary functions, and can add or delete functions as needed, so that the recording medium such as a hard disk for storing the program can be used.
  • the storage area can be used effectively, and memory can be prevented from being wasted during program execution.
  • it has excellent function expandability and is mainly developed
  • development becomes easy, and the user can follow up functions easily and at low cost by adding plug-ins.
  • the editing unit 24 accepts an editing instruction event via the user interface, notifies the appropriate plug-in of the event, and re-executes the event (redo) or cancels execution (undo). Control the process.
  • the DOM unit 30 includes a DOM providing unit 32, a DOM generating unit 34, and an output unit 36, and is a document object model (Document) defined to provide an access method when an XML document is handled as data. Implements functions that conform to Object Model (DOM).
  • the DOM provider 32 is a DOM implementation that satisfies the interface defined in the editing unit 24.
  • the DOM generator 34 also generates a DOM tree with XML document capabilities. As will be described later, when XML document power to be processed is mapped to another library by VC unit 80, the source tree corresponding to the mapping source XML document and the destination tree corresponding to the mapping destination XML document Is generated.
  • the output unit 36 outputs the DOM tree as an XML document at the end of editing, for example.
  • the CSS unit 40 includes a CSS analysis unit 42, a CSS providing unit 44, and a rendering unit 46, and provides a display function compliant with CSS.
  • the CSS analysis unit 42 has a function of a parser that analyzes the syntax of CSS.
  • the CSS provider 44 is an implementation of a CSS object and performs CSS cascade processing on the DOM tree.
  • the rendering unit 46 is a CSS rendering engine, and is used to display a document described in a vocabulary such as HTML that is laid out using CSS.
  • the HTML unit 50 displays or edits a document described in HTML.
  • the SVG unit 60 displays or edits documents written in SVG.
  • These display Z editing systems are realized in the form of plug-ins.
  • Each display unit (Canvas) 56 and 66 displays a document, and each control unit (Editlet) 52 and 62 receives and transmits an event including an editing instruction. It is equipped with editing sections (Zone) 54 and 64 that receive editing commands and edit the DOM.
  • the control unit 52 or 62 accepts a DOM tree editing command even when an external force is received, the editing unit 54 or 64 changes the DOM tree, and the display unit 56 or 66 updates the display.
  • MVC Model-Vi
  • the display unit 56 and 66 are set to “View”
  • the control units 52 and 62 are set to “Controller”
  • the editing units 54 and 64 and the DOM.
  • Each entity corresponds to “Model”.
  • the document processing apparatus 20 of the base technology enables not only editing of an XML document in a tree display format but also editing according to the respective vocabulary.
  • the HTML unit 50 provides a user interface for editing an HTML document in a manner similar to a word processor
  • the SVG unit 60 provides a user interface for editing an SVG document in a manner similar to an image drawing tool.
  • the VC unit 80 includes a mapping unit 82, a definition file acquisition unit 84, and a definition file generation unit 86.
  • a mapping destination Provides a framework for displaying or editing documents with a display editing plug-in that supports the vocabulary. In this base technology, this function is called Vocabulary Connection (VC).
  • the definition file acquisition unit 84 acquires a script file in which the mapping definition is described. This definition file describes the correspondence (connection) between nodes for each node. At this time, whether to edit the element value or attribute value of each node may be specified. Also, an arithmetic expression using the element value or attribute value of the node may be described.
  • the mapping unit 82 refers to the script file acquired by the definition file acquisition unit 84, causes the DOM generation unit 34 to generate a destination tree, and manages the correspondence between the source tree and the destination tree.
  • the definition file generator 86 provides a graphical user interface for the user to generate a definition file.
  • the VC unit 80 monitors the connection between the source tree and the destination tree and receives an editing instruction from the user interface provided by the plug-in responsible for display, the VC unit 80 first applies the corresponding of the source tree. Change the node to perform.
  • DOM unit 30 issues a mutation event indicating that the source tree has been changed
  • VC unit 80 receives the mutation event and synchronizes the destination tree with the change in the source tree. Change the destination tree node corresponding to the changed node.
  • a plugin to display / edit the destination tree For example, the HTML unit 50 receives a mutation event indicating that the destination tree has been changed, and updates the display with reference to the changed destination tree.
  • the DOM generation unit 34 When the document processing device 20 reads a document to be processed, the DOM generation unit 34 generates a DOM tree for the XML document power. Further, the main control unit 22 or the editing unit 24 refers to the name space to determine the vocabulary describing the document. If a plug-in corresponding to the vocabulary is installed in the document processing apparatus 20, the plug-in is loaded to display / edit the document. If the plug-in linker S is not installed, check whether the mapping definition file exists. If the definition file exists, the definition file acquisition unit 84 acquires the definition file, generates a destination tree according to the definition, and displays and edits the document by the plug-in corresponding to the mapping destination library.
  • the corresponding parts of the document are displayed and edited by plug-ins corresponding to each vocabulary as described later. If the definition file does not exist, the document source or tree structure is displayed and edited on the display screen.
  • FIG. 2 shows an example of an XML document to be processed.
  • This XML document is used to manage student grade data.
  • the component “score” that is the top node of the XML document has a plurality of component “students” provided for each student under the subordinate.
  • the component “student” has an attribute value “name” and child elements “national language”, “mathematics”, “science”, and “society”.
  • the attribute value “name” stores the name of the student.
  • the constituent elements “National language”, “Mathematics”, “Science”, and “Society” store the results of national language, mathematics, science, and society, respectively.
  • the student with the name “A” has a national grade of “90”, a mathematical grade of “50”, a science grade of “75”, and a social grade of “60”.
  • the vocabulary (tag set) used in this document will be referred to as the “results management vocabulary”.
  • the document processing apparatus 20 of the base technology supports display Z editing of the grade management vocabulary.
  • the VC function described above is used.
  • the user interface for creating a definition file by the user himself will be described later.
  • the description will proceed assuming that a definition file has already been prepared.
  • FIG. 3 shows an example of mapping the XML document shown in FIG. 2 to a table described in HTML.
  • the “Student” node in the Grade Management Library is associated with the row (“TR” node) of the table (“TA BLE” node) in HTML, and the attribute value “name” appears in the first column of each row.
  • the element value of the "National Language” node the element value of the "Mathematics” node in the third column, the element value of the "Science” node in the fourth column, and " Associate the element values of the “Society” node.
  • the XML document shown in FIG. 2 can be displayed in an HTML table format.
  • the sixth column specifies the formula for calculating the weighted average of national language, mathematics, science, and society, and displays the average score of the students. In this way, by making it possible to specify an arithmetic expression in the definition file, more flexible display is possible, and user convenience during editing can be improved. Note that the sixth column specifies that editing is not possible, so that only the average score cannot be edited individually. In this way, by making it possible to specify whether or not editing can be performed in the mapping definition, it is possible to prevent erroneous operations by the user.
  • FIGS. 4A and 4B show examples of definition files for mapping the XML document shown in FIG. 2 to the table shown in FIG.
  • This definition file is described in the script language defined for the definition file.
  • the definition file contains command definitions and display templates.
  • "add student” and “delete student” are defined as commands, respectively, the operation of inserting the node “student” into the source tree, and the source tree The operation of deleting the node “student” from the node is associated.
  • headings such as “Name” and “National Language” are displayed in the first row of the table, and the second and subsequent rows are displayed. Describes that the content of the node “student” is displayed.
  • FIG. 5 shows an example of a screen displayed by mapping the XML document described in the grade management vocabulary shown in FIG. 2 to HTML according to the correspondence shown in FIG.
  • Table 90 shows, from the left, each student's name, national language grade, mathematics grade, science grade, social grade, and average score.
  • the user can edit the XML document on this screen. For example, if the value in the second row and third column is changed to “70”, the element value of the source corresponding to this node, that is, the math grade of the student “B” is changed to “70”.
  • the VC unit 80 changes the corresponding part of the destination tree that makes the destination tree follow the source tree, and updates the display based on the changed destination tree. Therefore, also in the table on the screen, the mathematics score of the student “B” is changed to “70”, and the average score is changed to “55”.
  • the screen shown in Fig. 5 shows the command menu for "Add Student" and "Delete Student". Is displayed.
  • the node “Student” is added or deleted in the source tree.
  • Such a single-structure editing function may be provided to the user in the form of a command.
  • a command for adding or deleting a table row may be associated with an operation for adding or deleting the node “student”.
  • FIG. 6 shows an example of a graphical user interface that the definition file generator 86 presents to the user in order for the user to generate a definition file.
  • the XML document of the mapping source is displayed in a tree.
  • the area 92 on the right side of the screen shows the screen layout of the mapping destination XML document.
  • This screen layout can be edited by the HTML unit 50, and the user creates a screen layout for displaying a document in an area 92 on the right side of the screen. Then, for example, with a pointing device such as a mouse, drag and drop the node of the mapping source XML document displayed in the area 91 on the left side of the screen into the screen layout using HTML displayed in the area 92 on the right side of the screen.
  • a pointing device such as a mouse
  • the connection between the mapping source node and the mapping destination node is specified. For example, if you drop “math”, which is a child element of the element “student”, into the first row and third column of Table 90 on the HTML screen, it will be between the “math” node and the “TD” node in the third column.
  • a connection is established.
  • Each node can be designated for editing.
  • An arithmetic expression can also be embedded in the display screen.
  • FIG. 7 shows another example of the screen layout generated by the definition file generator 86.
  • a table 90 and a pie chart 93 are created on the screen for displaying the XML document described in the grade management vocabulary.
  • This pie chart 93 is described in SVG.
  • the document processing apparatus 20 of the base technology can process a compound document including a plurality of libraries in one XML document, and thus a table described in HTML as in this example. 90 and a pie chart 93 written in SVG can be displayed on one screen.
  • FIG. 8 shows an example of an XML document editing screen by the document processing apparatus 20. In the example of Fig. 8, one screen is divided into multiple parts, and the XML document to be processed is displayed in different display formats in each area.
  • the document 94 is displayed in the area 94, the tree structure of the document is displayed in the area 95, and the table described in HTML shown in FIG. 5 is displayed in the area 96.
  • Documents can be edited on any of these screens.
  • the source tree is changed and the plug-in and source trees responsible for displaying each screen are displayed. Update the screen to reflect your changes.
  • the display section of the plug-in responsible for displaying each editing screen is registered, and either plug-in or VC unit 80 is registered.
  • the source tree is changed by, all the display units displaying the edit screen receive the issued mutation event and update the screen.
  • the VC unit 80 changes the destination tree following the change of the source tree, and then refers to the changed destination tree.
  • the display unit updates the screen.
  • the source display plug-in and the tree display plug-in directly refer to the source tree without using the destination tree. And display.
  • the source display plug-in and the tree display plug-in update the screen with reference to the changed source tree, and take charge of the screen in area 96! /
  • the HTML unit 50 updates the screen by referring to the changed destination tree following the change of the source tree.
  • the source display and the tree display can also be realized by using the VC function. That is, the source and tree structure may be laid out in HTML, an XML document may be mapped to the HTML, and displayed by the HTML unit 50. In this case, three destination trees are generated: source format, tree format, and tabular format.
  • the VC unit 80 changes the source tree, then changes the three destination trees in the source format, tree format, and table format.
  • the knit 50 updates the three screens with reference to those destination trees.
  • the convenience of the user can be improved by displaying the document in a plurality of display formats on one screen.
  • the user can display and edit a document in a format that can be easily visually divided using the table 90 or the like while grasping the hierarchical structure of the document by the source display or the tree display.
  • the ability to divide a screen and display a screen in multiple display formats at the same time may display a screen in a single display format on a single screen, and the display format can be switched by a user instruction.
  • the main control unit 22 receives a display format switching request from the user, and instructs each plug-in to switch the display.
  • FIG. 9 shows another example of an XML document edited by the document processing device 20.
  • the XHTML document is embedded in the “foreignObject” tag of the SVG document, and moreover, the mathematical expression described in MathML is included in the XHTML document.
  • the editing unit 24 refers to the name space and distributes the drawing work to an appropriate display system.
  • the editing unit 24 first causes the SVG unit 60 to draw a rectangle, and then causes the HTML unit 50 to draw an XHTML document.
  • the MathML unit (not shown) is made to draw mathematical expressions. In this way, a compound document including a plurality of vocabularies is appropriately displayed.
  • Figure 10 shows the display results.
  • the displayed menu may be switched according to the position of the cursor (carriage). That is, when the cursor is in the area where the SVG document is displayed, the menu defined by the SVG unit 60 or the command defined in the definition file for mapping the SVG document is displayed.
  • the menu defined by the HTML unit 50 or the command defined in the definition file for mapping the XHTML document is displayed. Thereby, an appropriate user interface can be provided according to the editing position.
  • the part described by the specified library may be displayed in the source display or the tree display.
  • the application power to display the embedded document is installed.
  • the content can be grasped by displaying the XML document composed of text data in the source display or tree display. can do. This is a unique feature of text-based documents such as XML.
  • a tag of another vocabulary may be used in a document described by a certain vocabulary. This XML document is not valid, but if it is well-formed (welH rmed), it can be processed as a valid XML document. In this case, the tag of another inserted library may be mapped by the definition file. For example, you can use tags such as “Important” and “Most important” in an XHTML document and highlight the parts enclosed by these tags, or sort them in order of importance. Moyo.
  • the plug-in or VC unit 80 in charge of the edited part changes the source tree. Mutation event listeners can be registered for each node in the source tree. Normally, the plug-in display or VC cut 80 corresponding to the vocabulary to which each node belongs is registered as a listener. Is done.
  • the DOM provider 32 traces from the changed node to a higher hierarchy, and if there is a registered listener, issues a mutation event to that listener. For example, in the document shown in Fig.
  • the entire layout may be updated as the display is updated by the HTML unit 50. Out may change.
  • the layout of the display area for each plug-in is updated by a configuration that manages the layout of the screen, for example, a plug-in that is responsible for displaying the top node.
  • the HTML unit 50 first draws a part that it is in charge of and determines the size of the display area. Then, it notifies the configuration that manages the layout of the screen of the size of the display area after the change, and requests a layout update.
  • the configuration that manages the layout of the screen receives the notification and re-lays out the display area for each plug-in. In this way, the display of the edited part is updated appropriately, and the layout of the entire screen is updated.
  • a document described in a markup language is usually expressed in the form of a tree data structure in a browser or other application. This structure corresponds to the tree of the results of parsing the document.
  • the DOM (Document Object Model) is a well-known tree-based data structure model used to represent and manipulate documents.
  • the DOM provides a standard set of objects for representing documents, including HTML and XML documents.
  • DOM is how an object representing a component in a document It includes two basic components: a standard model for connectedness and a standard interface for accessing and manipulating those objects.
  • a DOM tree is a hierarchical representation of a document based on the contents of the corresponding DOM.
  • a DOM tree contains a “root” and one or more “nodes” that originate from the root. In some cases, the root represents the entire document. Intermediate nodes can represent elements such as rows and columns in a table and its table, for example.
  • a “leaf” in a DOM tree usually represents data such as text or images that cannot be further decomposed!
  • Each node in the DOM tree may be associated with attributes that describe the parameters of the element represented by the node, such as font, size, color, and indentation.
  • HTML is a language for power formatting and layout, which is a commonly used language for creating documents, and is not a language for data description.
  • a node in the DOM tree that represents an HTML document is an element that is predefined as an HTML formatting tag. Normally, HTML does not provide functions for data detailing or tagging Z labeling of data. So, it is often difficult to formulate queries for data in HTML documents.
  • XML documents can contain document type definitions that describe the tags used in the document and the “grammar” of their interrelationships.
  • CSS CSS
  • XSL XML Style Language
  • Xpath provides common syntax and semantics for specifying the location of parts of an XML document.
  • An example of functionality is traversing (moving) a DOM tree corresponding to an XML document. It provides basic functionality for string, number, and Boolean character manipulation associated with various representations of XML documents.
  • Xpath is the visual syntax of XML documents, such as the number of lines and the number of characters when viewed as text! It works with a simple structure. Using Xpath, you can specify a location through a hierarchical structure in the DOM tree of an XML document, for example. In addition to its use for addressing, Xpath is also designed to be used to test whether a node in a DOM tree matches a pattern. More details on XPath can be found at http: ⁇ www. W3.org/TR/xpath.
  • MVC Mod-View-Controller
  • model M
  • view V
  • controller C
  • the controller acts to interpret input such as mouse and keyboard input from the user and map these user actions to commands sent to the model and Z or view to bring about appropriate changes.
  • the model acts to manage one or more data elements, responds to queries about its state, and responds to instructions to change the state. Views work to manage the rectangular area of the display and have the ability to present data to the user through a combination of graphics and text
  • FIG. 11 (a) shows a conventional configuration example of elements that function as the basis of a document processing system of the type described later.
  • Configuration 10 includes a processor of the type such as a CPU or mic processor 11 connected to memory 12 by communication path 13.
  • Memory 12 may be in any ROM and Z or RAM format available now or in the future.
  • the communication path 13 is typically provided as a bus.
  • An input / output interface 16 for user input device 14 and display device 15 (or other user interface) such as a mouse, keyboard, voice recognition system, etc. is also connected to the bus for communication between processor 11 and memory 12.
  • This configuration may be stand-alone, or may be a networked form in which a plurality of terminals and one or more servers are connected, or may be configured in a known manner. Yes.
  • the present invention is not limited by the arrangement of these components, the centralized or distributed architecture, or the communication method of the various components.
  • the present system and the embodiments discussed herein are discussed as including several components and subcomponents that provide various functionality. These components and sub-components can be realized with hardware only or software alone, not just a combination of hardware and software, to provide the noted functionality.
  • hardware, software, and combinations thereof are general purpose It can be realized by the above computing device, dedicated hardware, or a combination thereof.
  • the configuration of a component or subcomponent includes a general-purpose Z-only computing device that executes specific software to provide the functionality of the component or subcomponent.
  • FIG. 11 (b) shows an overall block diagram of an example of a document processing system.
  • a document is generated and edited.
  • These documents may be described in any language having markup language characteristics, such as XML.
  • markup language characteristics such as XML.
  • the document processing system can be regarded as having two basic configurations.
  • the first configuration is an “execution environment” 101 that is an environment in which the document processing system operates.
  • the execution environment provides basic utilities and functions that support the system as well as the user during document processing and management.
  • the second configuration is an “application” 102 that also includes application capabilities that run in the execution environment. These applications include the document itself and various representations of the document.
  • Programlnvoker 103 program invoking power: program activation unit.
  • Programlnvokerl03 is a basic program that is accessed to activate the document processing system. For example, when a user logs on to a document processing system and starts, Programlnvokerl03 is executed.
  • Programlnvoker 103 can, for example, read and execute functions stored as plug-ins in the document processing system, start and execute applications, and read properties related to documents.
  • the function of Programlnvokerl03 is not limited to these.
  • Programlnvokerl03 finds the application, launches it, and executes the application.
  • Programlnvoker 103 includes plug-in subsystem 104, command subsystem 105 And several components such as the Resource module 109 are attached. These configurations will be described in detail below.
  • Plug-in subsystem 104 is used as a highly flexible and efficient configuration for adding functionality to a document processing system.
  • the plug-in subsystem 104 can also be used to modify or delete functionality that exists in the document processing system.
  • a wide variety of functions can be added or modified using the plug-in subsystem. For example, it is possible to add an Editlet function that works to support the drawing of a document on the screen.
  • the Editlet plug-in also supports editing of vocabularies that are added to the system.
  • the plug-in subsystem 104 includes a Service Broker (service broker: service mediation unit) 1041.
  • ServiceBrokerl041 mediates services added to the document processing system by managing plug-ins added to the document processing system.
  • Service 1042 Individual functions that achieve the desired functionality are added to the system in the form of Service 1042.
  • Available Servicel042 types are: Application service, ZoneFactory (zone factory: zone generator) Service, Editlet (editlet: editor) Service, CommandFactory (command factory: command generator) Service ⁇ C onnectXPath (Connect XPath: XPath Management Department) Service, CSSComputation (CSS Combination: CSS Calculation Department) Services including, but not limited to, these.
  • a plug-in is a unit that can contain one or more Service Providers (Service Providers). Each ServiceProvider has one or more classes of Service associated with it. For example, by using a single plug-in with the appropriate software application, one or more services can be added to the system, thereby adding the corresponding functionality to the system.
  • Service Providers Service Providers
  • Each ServiceProvider has one or more classes of Service associated with it. For example, by using a single plug-in with the appropriate software application, one or more services can be added to the system, thereby adding the corresponding functionality to the system.
  • Command subsystem Command subsystem 105 is used to execute instructions in the form of commands related to document processing.
  • a user can execute an operation on a document by executing a series of instructions. For example, a user edits an XML DOM tree corresponding to an XML document in the document processing system by issuing an instruction in the form of a command, and processes the XML document. These commands may be entered using keystrokes, mouse clicks, or other valid user interface actions.
  • One command may execute more than one instruction. In this case, these instructions are wrapped in one command and executed sequentially. For example, suppose a user wants to replace an incorrect word with a correct word. In this case, the first command is to find the wrong word in the document, the second command is to delete the wrong word, and the third command is to insert the correct word. It may be. These three instructions may be wrapped in one command.
  • the command may have an associated function, for example, an "Undo" function, which will be described in detail later. These functions may also be assigned to some base classes that are used to create objects.
  • a key component of the command subsystem 105 is a Commandlnvoker (command invoking force: command initiating unit) 105 1 that acts to selectively give and execute a command. Although only one Commandlnvoker is shown in Fig. 11 (b), one or more commands may be executed at the same time.
  • Com mandlnvokerl051 holds functions and classes necessary for executing commands.
  • a Command 1052 to be executed is loaded into Queue 1 053.
  • Commandlnvoker creates a command thread that runs continuously. If there is no Command already running in Commandlnvoker, Commandl052 intended to be executed by Commandlnvoker 1051 is executed.
  • Commandlnvoker 1051 are not limited to forces including UndoableCommand 1054, AsynchronousCommand 1055, and VCCo mmand 1056.
  • UndoableCommand 10 54 is a command that can cancel the result of the command if the user desires it. Examples of UndoableCommands include cut, copy, and insert text. In operation, when a user selects a part of a document and applies a cut command to that part, the cut-out part can be “cut off, if necessary” by using UndoableCommand. Can be.
  • VCCommand1056 is stored in a Vocabulary Connection Descriptor (VCD) script file. These are user-specified commands that can be defined by the programmer.
  • the Command may be a more abstract combination of Comm and for adding an XML fragment, deleting an XML fragment, or setting an attribute, for example. These commands are specifically focused on document editing.
  • AsynchronousCommand 1055 3 ⁇ 4 A command from the system, such as loading and saving of a document, and is executed asynchronously separately from UndoableCommand and VCCommand. Async hronousCommand is not an UndoableCommand and cannot be undone.
  • Resourcel09 is an object that provides several functions to various classes. For example, string resources, icons, and default key bindings are examples of resources used in the system.
  • the application component 102 which is the second main feature of the document processing system, is executed in the execution environment 101.
  • Application component 102 includes the actual document and various logical and physical representations of the document in the system.
  • the application component 102 includes the configuration of the system used to manage the document.
  • the application component 102 further includes a UserApplication (user application) 106, an application core 108, a user interface 107, and a Core. Includes Component 110.
  • UserApplicationl06 is loaded on the system together with Programlnvokerl03.
  • User Application 106 is an adhesive that connects the document, various representations of the document, and the user interface required to interact with the document. For example, suppose a user wants to generate a set of documents that are part of a project. When these documents are loaded, an appropriate representation of the document is generated. The user interface function is added as part of UserApplication06. In other words, UserApplication 106 holds both the representation of the document that allows the user to interact with the document that forms part of the project, and various aspects of the document. And once UserApplication06 is created, whenever the user wants to interact with the documents that form part of the project, the user can easily load UserApplication10 on the execution environment.
  • CoreComponentl 10 provides a way to share documents between multiple panes.
  • Pane displays the DOM tree and handles the physical layout of the screen.
  • a physical screen can also have multiple Pane forces in the screen that depict individual pieces of information.
  • Documents visible to the user from the screen can appear in one or more panes.
  • two different documents may appear in two different panes on the screen!
  • the physical layout of the screen is also in the form of a tree.
  • a Pane can be a RootPane 1084 or a SubPane 1085.
  • RootPanel084 is a Pane that hits the root of the Pane tree, and
  • SubPane 10 85 is any Pane other than RootPanel084.
  • CoreComponentl 10 also provides fonts and serves as a source of multiple functional operations for documents, such as toolkits.
  • An example of a task performed by CoreComponentl 10 is moving the mouse cursor between multiple panes.
  • Another example of a task to be performed is to mark a part of a document in one pane and copy it onto another pane that contains a different document.
  • the application component 102 consists of documents that are processed and managed by the system. This includes various logical and physical representations of documents within the system.
  • the application core 108 is a configuration of the application component 102. Its function is to keep the actual document with all the data it contains.
  • the application core 108 includes DocumentManager (document manager: document management unit) 1081 and Document (document: document) 1082 itself.
  • DocumentManagerl081 manages Documentl082.
  • DocumentManagerl081 is also connected to RootPanel084, Sub Pane 1085, ClipBoard (clipboard) utility 1087, and Snapshot (snapshot) utility 1088.
  • the ClipBoard utility 1087 provides a way to keep the portion of the document that the user decides to add to the clipboard. For example, a user may want to cut a part of a document and save it in a new document for later review. In such cases, it is added to the clipped partial force SClipBoard.
  • the Snapshot utility 1088 allows the current state of an application to be stored when the application transitions from one state force to another.
  • a user interface 107 that provides a means for a user to physically interact with the system.
  • the user interface is used by users to upload, delete, edit, and manage documents.
  • the user interface includes Frame 1071, MenuBar 1072, StatusBar 1073, and URLBar 1074.
  • Frame 071 is considered to be an active area of the physical screen, as is generally known.
  • MenuBarl072 is a screen area that contains menus that provide selection to the user.
  • StatusBarl073 is a screen area that displays the execution status of the application.
  • URLBarl074 enters URL address to navigate the internet Provide area.
  • FIG. 12 shows the details of DocumentManagerl081. This includes the data structures and structures used to represent the document within the document processing system. For simplicity, the configuration described in this subsection is described using the MVC paradigm.
  • the DocumentManagerl 081 includes a DocumentContainer (document container: document container) 203 that holds and hosts all the documents in the document processing system.
  • the tool kit 201 attached to Document Managerl081 provides various tools used by DocumentManagerl081.
  • DomService DOM service
  • IOManager input / output manager
  • StreamHandler is a tool that handles uploading documents using bitstreams.
  • the model (M) includes a DOM tree model 202 of the document. As mentioned above, all documents are represented as DOM trees in the document processing system. The document also forms part of the DocumentContainer 203.
  • a DOM tree representing a document is a tree having Node 2021.
  • Zone 209 which is a subset of the DOM tree, contains the associated region of one or more nodes in the DOM tree. For example, only a part of the document can be displayed on the screen, but this part of the visualized document is displayed using the Zone 209.
  • ZoneFactory zone factory: zone generation unit
  • a Zone may use a “namespace” with a power of 1 or more to express part of the DOM.
  • a namespace is a collection of names that are unique within a namespace. In other words In this case, the same name does not exist in the namespace.
  • the Facet 2022 is another configuration within the model (M) part of the MVC paradigm. Facet is used to edit Nodes in the Zone. Facet 2022 organizes access to the DOM using procedures that can be executed without affecting the contents of the Zone itself. As explained next, these procedures perform important and useful operations related to Node.
  • Each Node has a corresponding Facet. Instead of directly manipulating Nodes in the DOM, the integrity of the DOM is protected by using Facet to perform the operations. If the operation is performed directly on Node, several plug-ins can modify the DOM at the same time, resulting in inconsistencies.
  • the DOM standard established by the W3C is the ability to define a standard interface for operating Nodes. Actually, there are operations specific to each library or each Node. It is convenient to prepare it as an API. In the document processing system, APIs specific to each node are prepared as Facet and attached to each node. This makes it possible to add useful APIs while complying with the DOM standard. In addition, by adding a specific API to a standard DOM implementation that does not implement a specific DOM for each vocabulary, various vocabularies can be processed in a unified manner. It is possible to appropriately process a document in which multiple bubbly libraries are mixed in any combination.
  • a vocabulary is a set of tags (for example, XML tags) belonging to a namespace.
  • a namespace has a unique set of names (here, tags).
  • the vocabulary appears as a subtree of the DOM tree that represents the XML document. This subtree contains Z one.
  • tag set boundaries are defined by Zones.
  • Zone 209 is generated using a service called ZoneFactory205. As described above, Zone 209 is an internal representation of a part of the DOM tree that represents a document. A logical representation is required to provide access to some of these documents. This logical representation tells the computer how the document is logically represented on the screen. To know.
  • Canvas 210 is a service that acts to provide a logical layout corresponding to the Zone.
  • Pane211 is a physical screen layout corresponding to the logical layout provided by Canvas210.
  • the user sees only the rendering of the document with text and images on the display screen. Therefore, the document must be drawn on the screen by the process of drawing characters and images on the screen.
  • the document is rendered on the screen by Canvas 210 based on the physical layout provided by Pane211.
  • Canvas 210 corresponding to Zone 209 is generated using Editlet 206.
  • the document DOM is edited using Editlet 206 and Canvas 210.
  • Editlet 206 and Canvas 210 use Facet corresponding to one or more Nodes in Zone209. These services do not directly operate Zone and Node in DOM. Facet is operated using Command207.
  • a user generally interacts with the screen by moving a cursor on the screen or typing a command.
  • the Canvas 210 that provides a logical layout on the screen accepts this cursor operation.
  • Canvas210 can cause Facet to execute the corresponding action.
  • the cursor subsystem 204 functions as a controller (C) of the MVC paradigm with respect to DocumentManager 081.
  • Canvas210 also has a task to handle events. For example, Canvas 210 handles events such as mouse clicks, focus movements, and similar actions triggered by the user.
  • Documents in a document processing system can be viewed from at least four perspectives. 1) data structure used to maintain document content and structure in the document processing system, 2) means to edit document content without affecting document integrity, 3) document content Logical layout on the screen, 4) Physical layout on the document screen. Z one, Facet, Canvas, and Pane represent the components of the document processing system that correspond to the above four viewpoints.
  • UndoManager Undo Manager 2121 holds operations for all documents that may be canceled by the user.
  • the undo subsystem 212 supports such operations.
  • the UndoManager 2121 holds the operation of such an Undoabl eEdit (Undoable Edit) 2122.
  • the controller portion of the MVC may include a cursor subsystem 204.
  • the cursor subsystem 204 also accepts user power. These inputs generally have the nature of commands and Z or editing operations.
  • the cursor subsystem 204 can be thought of as the controller (C) portion of the MVC paradigm associated with DocumentManager1081.
  • Canvas 210 represents a logical layout of a document to be presented on the screen.
  • Canvas 210 may include a box tree 208 that logically represents how the document looks on the screen. This box tree 208 will be included in the view (V) portion of the MVC paradigm associated with DocumentManager 1081.
  • XML documents can be handled by mapping them to other representations, and if the mapped representations are edited, the edits remain consistent with the original XML document. It is to provide an environment that is reflected.
  • a document described in a markup language such as an XML document, is created based on a vocabulary defined by a document type definition.
  • a bokeh library is a set of tags. Since a vocabulary may be arbitrarily defined, there can be an infinite number of vocabularies. However, it is impractical to provide a dedicated processing Z management environment for each of the many possible bubbly libraries. Vocabulary connection solves this problem Provide a method.
  • a document may be described in two or more markup languages.
  • Documents may be written in, for example, XHTML (.extensible HyperText Markup Language), 3 ⁇ 4 V "G (Scalable Vector Grap hies), MathML (Mathematical Markup Language), or other markup languages.
  • XHTML .extensible HyperText Markup Language
  • 3 ⁇ 4 V "G Scalable Vector Grap hies
  • MathML MathML
  • a markup language may be viewed in the same way as a vocabulary tag set in XML.
  • the vocabulary is processed using the vocabulary plug-in.
  • Documents written in a library where plug-ins are not available in the document processing system are displayed by mapping to documents in another library where plug-ins are available. Because of this feature, it is possible to properly display a document in a library that does not have a plug-in.
  • a vocabulary connection includes the ability to obtain a definition file and map between two different vocabularies based on the obtained definition file.
  • a document written in one vocabulary can be mapped to another vocabulary.
  • the vocabulary connection allows the document to be displayed and edited by the display Z editing plug-in corresponding to the vocabulary to which the document is mapped.
  • each document is generally described in the document processing system as a DOM tree having a plurality of nodes.
  • the “definition file” describes the correspondence between each node and other nodes. It is specified whether the element value and attribute value of each node can be edited. An arithmetic expression using the element value or attribute value of the node may be described.
  • a destination DOM tree to which a definition file is applied is generated using the feature of mapping. In this way, the relationship between the source DOM tree and the destination DOM tree is constructed and maintained.
  • the vocabulary connection monitors the correspondence between the source DOM tree and the destination DOM tree. When user power is also instructed to edit, the vocabulary connection changes the associated node in the source DOM tree. A “mutation event” is issued to indicate that the source DOM tree has changed, and the destination DOM tree is changed accordingly.
  • a relatively minor vocabulary known only to a small number of users can be converted into another major vocabulary. Therefore, even a minor library used by a small number of users can properly display a document and provide a desirable editing environment.
  • the vocabulary connection subsystem that is a part of the document processing system provides a function that enables a plurality of expressions of a document.
  • FIG. 13 shows a Vocabulary Connection (VC) subsystem 300.
  • the VC subsystem 300 provides a way to maintain the consistency of two alternative representations of the same document.
  • the two representations may be representations of the same document from two different vocabularies.
  • one may be the source DOM tree and the other may be the destination DOM tree.
  • the functions of the vocabulary connection subsystem 300 are realized in a document processing system using a plug-in called VocabularyConnection301.
  • VocabularyConnection301 For each Vocabulary 305 in which the document is represented, a corresponding plug-in is required. For example, if a part of a document is written in HTML and the rest is written in SVG, a browser library corresponding to HTML and SVG is required.
  • the VocabularyConnection plug-in 301 generates an appropriate VCCanvas 310 for the Zone209 or Pane211 corresponding to the appropriate Vocabulary305 document.
  • VocabularyConnection 301 changes to Zone 209 in the source DOM tree are communicated to the corresponding Zone in another DOM tree 306 by the conversion rule.
  • the conversion rule is described in the form of a Vocabulary Connection Descriptor (VCD). For each VCD file corresponding to such a conversion between the source DOM and the destination DOM! /, A corresponding VCMa nager 302 is created.
  • Connector 304 connects the source node of the source DOM tree and the destination node of the destination DOM tree.
  • Connector304 source DOM tree Operates to see the modifications (changes) in the source node inside and the source document corresponding to the source node. Then modify the corresponding destination DOM tree node.
  • Connector 304 is the only object that can modify the destination DOM tree. For example, the user can make modifications only to the source document and the corresponding source DOM tree. Connector 304 then makes the corresponding modifications to the destination DOM tree.
  • Connector 304 is logically linked to form a tree structure.
  • the tree formed by the connector 304 is called ConnectorTree (connector tree).
  • Connect or 304 is generated using a service called ConnectorFactory (connector factory: connector generation unit) 303.
  • ConnectorFactory303 generates Connector304 from the source document and links them to form ConnectorTree.
  • VocabularyConnectionManager r302 holds ConnectorFactory303.
  • the bubbly library is a set of tags in the namespace.
  • Vocabulary 305 is generated for a document by VocabularyConnection 301. This is done by parsing the document file and generating an appropriate VocabularyConnectionManager 302 for mapping between the source DOM and the destination DOM.
  • an appropriate relationship is created between the ConnectorFactory 303 that generates the Connector, the ZoneF actory 205 that generates the Zone 209, and the Editlet 206 that generates the Canvas corresponding to the nodes in the Zone.
  • the corresponding vocabulary connection manager 302 is deleted.
  • Vocabulary 305 generates VCCanvas310. Further, a connector 304 and a destination DOM tree 306 are generated correspondingly.
  • the source DOM and Canvas correspond to the model (M) and the view (V), respectively.
  • M model
  • V view
  • the depiction is done by a bokeh rib laggin.
  • Vocabulary plug-ins are provided for major vocabulary libraries such as XHTML, SVG, and MathML.
  • Bobber rib lagins are used in conjunction with the target bobbler. These are mapped between vocabularies using the vocabulary connection descriptor. Provide a method.
  • mapping is meaningful only when the target vocabulary is mappable and the method of drawing on the screen is predefined.
  • rendering methods are standards defined by organizations such as W3C, such as XHTML.
  • VCCanvas is used when a vocabulary connection is required.
  • the source canvas cannot be generated because the source view cannot be generated directly.
  • it is generated using VCCanvas force ConnectorTree. This VCCanvas only handles event conversion and does not assist in rendering the document on the screen.
  • the purpose of the vocabulary connection subsystem is to simultaneously generate and maintain two representations of the same document.
  • the second representation is also in the form of a DOM tree, which has already been described as a destination DOM tree. DestinationZone, Canvas and Pane are needed to see the document in the second representation.
  • VCCanvas When VCCanvas is created, a corresponding DestinationPane307 is created. In addition, an associated DestinationCanvas 308 and a corresponding BoxTree 309 are generated. Similarly, VCC anvas 310 is associated with Pane 211 and Zone 209 for the source document.
  • DestinationCanvas 308 provides a logical layout of the document in the second representation.
  • DestinationCanvas 308 provides user interface functions such as cursors and selections to depict documents in the destination representation. Events that occur in Destination Canvas 308 are supplied to the Connector.
  • DestinationCanvas 308 notifies Connector 304 of mouse events, keyboard events, drag and drop events, and events specific to the document destination (second) representation of the library.
  • VC vocabulary connection
  • VCCommand Bob library connection command
  • the VCCo mmand can be generated by using the built-in CommandTemplate 318 and by using the script language in the Z or script subsystem 314 to generate the scratch command as well.
  • Command templates include, for example, an “If” command template, a “When” command template, an “Insert” command template, and the like. These templates are used to create V CCommand.
  • Connector 304 generally includes xpath information. As mentioned above, one of the tasks of the vocabulary connection is to reflect changes in the source DOM tree in the destination DOM tree.
  • the xpath information contains one or more xpath expressions that are used to determine the subset of the source DOM tree that should be monitored for change Z modifications.
  • the source DOM tree is a DOM tree or Zone that represents a document in a vocabulary before being converted to another vocabulary.
  • the node in the source DOM tree is called the source node.
  • the destination DOM tree is a DOM tree or Zone that represents the same document in a different vocabulary after being converted by mapping, as described above in connection with the vocabulary connection.
  • a node in the destination DOM tree is called a destination node.
  • ConnectorTree is a hierarchical expression based on a Connector that represents a correspondence between a source node and a destination node.
  • the Connector monitors the source node and modifications made to the source document and modifies the destination DOM tree.
  • the Connector is the only object that is allowed to modify the destination DOM tree.
  • I Bent is a method for describing and executing user actions executed on a program.
  • programs had to actively gather information to understand user actions and execute them themselves. This means, for example, that after the program initializes itself, it enters a loop that repeatedly checks the user's actions to take appropriate action when the user takes action on the screen, keyboard, mouse, etc. To do.
  • this process is cumbersome.
  • it requires a program that consumes CPU cycles and loops while waiting for the user to do something.
  • the document processing system defines and uses its own events and how to handle these events.
  • a mouse event is an event that occurs from a user's mouse action.
  • User actions involving the mouse are passed to the mouse event by Canva s210.
  • Canvas can be said to be at the forefront of interaction by users of the system. If necessary, the canvas at the front passes the content related to the event to the child.
  • a keystroke event flows from the Canvas 210.
  • Keystroke events have immediate focus. That is, it relates to work at any moment.
  • the keystroke event input on Canvas210 is passed to its parent.
  • Keystrokes are handled by different events that can handle string insertion.
  • Sentence The event that handles string insertion occurs when a character is inserted using the keyboard.
  • Other “events” include, for example, other events that are handled in the same way as drag events, drop events, and mouse events.
  • X HTMLCanvasl06 an example of DestinationCanvas
  • receives events that occur such as mouse events, keyboard events, drag and drop events, and events specific to the library. These events are notified to the connector 304. More specifically, as shown in FIG. 21 (b), the event flow in the VocabularyConnection plug-in 301 is as follows. It passes through the destination DOM tree and ConnectorTree.
  • Programlnvokerl03 is a basic program in the execution environment that is executed to start the document processing system.
  • User Application 106, 3 ⁇ 4erviceBrokerl04l, Commandlnvokerl051, and Resourcel09 are all connected to Programlnvokerl03.
  • the application 102 is a component that is executed in the execution environment.
  • ServiceBrokerl041 manages plug-ins that support various functions in the system.
  • Commandlnvokerl051 executes instructions provided by the user and holds classes and functions used to execute the commands.
  • ServiceBrokerl041 will be described in more detail with reference to FIG. 14 (b). As mentioned above, ServiceBrokerl041 is a plug-in (and function that adds various functions to the system). Manage linked services). Service 1042 is the lowest layer that can add or change features to the document processing system. “Service” consists of two parts, ServiceCategory 401 and ServiceProvider 402. As shown in FIG. 14 (c), one ServiceCategory 401 can have a plurality of related ServiceProviders 402. Each ServiceProvider acts to execute some or all of a specific ServiceCategory. On the other hand, ServiceCategory 401 defines the type of Service.
  • Service 1) to provide specific features to the document processing system "feature service”, 2) is an application executed by the document processing system “application service”, 3) necessary throughout the document processing system It can be classified into three types: “environmental services” that provide special features.
  • FIG. 14 An example of Service is shown in Fig. 14 (d).
  • Application Category is an example of ServiceProvider supported by the system utility.
  • Editlet 206 is a Category
  • HTMLEditlet and SVGEditlet are corresponding ServiceProviders.
  • the ZoneFactory 205 is another Category of Service and has a corresponding ServiceProvider (not shown).
  • a plug-in may be considered a unit consisting of several ServiceProviders 402 and their associated classes that have already been described as providing functionality to a document processing system. Each plug-in has dependencies and ServiceCategory 401 described in the declaration file.
  • Figure 14 (e) shows further details about the relationship between Programlnvokerl03 and UserApplicationl06. Necessary documents and data are loaded from the storage. All necessary plug-ins are loaded on ServiceBrokerl041. ServiceBrokerl041 holds and manages all plug-ins. Plug-ins can be physically added to the system, and their functionality can also be loaded by the storage card. When the plug-in content is loaded, ServiceBrokerl041 defines the corresponding plug-in. Next, the corresponding UserApplicationl06 is generated, loaded into the execution environment 101, and attached to Programlnvokerl03. [0151] G. Relationship between application service and environment
  • Figure 15 (a) shows further details about the configuration of the application service loaded on Programlnvokerl03.
  • Comm and lnvokerl051 which is a component of the command subsystem 105, activates or executes Commandl052 in Programlnvokerl03.
  • Commandl052 is a command used to process a document such as XML and edit a corresponding XMLDOM tree in a document processing system.
  • Commandlnvokerl05 1 holds classes and functions necessary for executing Commandl052.
  • ServiceBrokerl041 is also executed in Programlnvokerl03.
  • UserApplicationl06 is connected to the user interface 107 and CoreComponentllO.
  • CoreCompone ntl lO provides a way to share documents between all panes.
  • CoreComponentl lO also provides fonts and serves as a toolkit for Pane.
  • FIG. 15 (b) shows the relationship between Framel071, MenuBarl072, and StatusBarl073.
  • FIG. 16 (a) provides further explanation of the application core 108 that holds all documents and parts of the documents and data belonging to the documents.
  • CoreComponentl lO is attached to DocumentManagerl081 that manages document 1082.
  • DocumentManager 1081 is the owner of all documents 1082 stored in memory associated with the document processing system.
  • DocumentManager1081 is also connected to RootPanel 084 to facilitate the display of the document on the screen.
  • the functions of ClipBoardl087, SnapShotl088, Drag & Drop601, and Overlay602 are also attached to CoreComponentl10.
  • SnapShotl088 is used to restore the application state.
  • the current status of the application is detected and stored. Then, when the application state changes to another state, the contents of the stored state are saved. SnapShotl088 is illustrated in FIG. 16 (b). In operation, SnapShotl088 remembers the previous state so that when an application moves to another URL force, it is possible to seamlessly execute a backward operation and a forward operation.
  • Document structure in DocumentManager Figure 17 shows further explanation of DocumentManager1081 and how documents are organized and maintained in DocumentManager.
  • the DocumentManager 1081 manages the document 1082.
  • one of the plurality of documents is RootDocument (root document) 701
  • the remaining documents are SubDocument (subdocument) 702.
  • DocumentManager 1081 is connected to RootDocument 701
  • Root Document 701 is connected to all SubDocuments 702.
  • DocumentManager 1081 is coupled to DocumentContainer 203, which is an object that manages all documents 1082.
  • a tool that opens a part of a tool kit 201 (for example, an XML tool kit) including the DOMService 703 and the IOManager 704 is also supplied to the DocumentManager 1081.
  • DOMService703 generates a DOM tree based on the document managed by DocumentManager1081.
  • Each Document 705 is managed by the corresponding DocumentContainer 203 regardless of whether it is a RootDocument 701 or a SubDocument 702.
  • FIG. 17 (b) shows how documents A to E are arranged hierarchically.
  • Document A is RootDocume nt.
  • Document B—D is a SubDocument of Document A.
  • Document E is a SubDocument of Document D.
  • the left side of Fig. 17 (b) shows an example where the same document hierarchy is displayed on the screen.
  • Document A which is a RootDocument, is displayed as a basic frame.
  • Document B—D which is the SubDocument of Document A, is displayed as a subframe in Basic Frame A.
  • Document E which is a SubDocument of Document D, is displayed on the screen as a subframe of Subframe D.
  • UndoManager Undo Manager: Undo Manager
  • UndoWrapper Undo Wrapper
  • UndoManager 706 and UndoWrapper 707 are generated for each DocumentContainer 203.
  • UndoManager 706 and UndoWrapper 707 are used to execute a cancelable command.
  • SubDocument changes are also closely related to Root Document.
  • the undo operation takes into account changes that affect other documents in the hierarchy, for example, to maintain consistency among all documents in a chained hierarchy as shown in Figure 17 (b). Guarantee that.
  • UndoWrapper707 wraps the undo objects related to SubDocument in DocumentContainer203 and binds them to the undo object related to RootDocument. UndoWrapper707 collects undo objects that can be used in UndoableEditAcceptor (Undoable EditAcceptor: Undoable Edit Accepting Unit) 709.
  • UndoableEditAcceptor Undoable EditAcceptor: Undoable Edit Accepting Unit
  • UndoManager 706 and UndoWrapper 707 are connected to UndoableEditAcceptor 709 and Undo ableEditSource (Undoable Edit Source) 708.
  • Document705 may be an undoableEditSource708 or a source of undoable edit objects.
  • Figures 18 (a) and 18 (b) provide further details about the undo framework and undo commands.
  • UndoCommand 801, RedoCommand 802, and UndoableEditCommand 803 are commands that can be placed on Commandlnvoker 1051 as shown in FIG. 11 (b), and are executed in order.
  • UndoableEditCommand 8 03 is further attached to UndoableEditSource708 and UndoableEditAcceptor709. Examples of "foo" Edit ommand804 and "bar" Edit ommand805i UndoableEditCommand.
  • Figure 18 (b) shows the execution of UndoableEditCommand.
  • the UndoableEditActceptor709 force Document705 is attacked by UndoableEditSource708, which is the DOM tree.
  • the second step S2 Docum ent705 is edited using the DOM API based on the command issued by the user.
  • the third step S3 it is notified that the listener power of the mutation event has been changed. That is, in this step, the listener that monitors all changes in the DOM tree detects the editing operation.
  • UndoableEdit is stored as an object of UndoManager706.
  • UndoableEditAcceptor709 is detected from UndoableEditSource708.
  • UndoableEditSource 708 may be Document 705 itself. [0165] K. Procedure for loading documents into the system
  • Figure 19 (a) shows an overview of how a document is loaded into the document processing system. Each step is detailed in relation to a specific example in Figures 24-28.
  • a document processing system generates a DOM from a binary data stream consisting of data power included in a document.
  • ApexNode (apex node) is generated for the part of the document that is the target of attention and belongs to the Zone.
  • the corresponding Pane is identified.
  • the identified pane creates a zone and canvas from the ApexNode and the physical screen surface.
  • the Zone then creates Facets for each node and provides the information needed for them.
  • Canvas generates a data structure for rendering nodes from a DOM tree.
  • a DOM tree 902 of the document is generated.
  • a corresponding DocumentContainer 903 is generated to hold the document.
  • DocumentContainer 903 is attached to DocumentManager 904.
  • a DOM tree includes a root node and sometimes multiple secondary nodes.
  • the DOM tree may have, for example, an SVG subtree as well as an XHTML subtree.
  • the XHTML subtree has an XHTML ApexNode905.
  • SVG sub-tree has SVG ApexNode906.
  • Step 1 the ApexNode906 force screen is touched by Pane907, which is the logical layout of the screen.
  • Pane907 requests a ZoneFactory for ApexNode906 from CoreComponent PaneOwner (pane owner) 908.
  • PaneOwner908 returns a ZoneFactory and an Editlet that is a CanvasF actory for ApexNode906.
  • step 4 a Pane907 force 3 ⁇ 4one909 is generated. Zone909 is attached to Pane907.
  • Zone909 generates a facet for each node and attaches to the corresponding node.
  • step 6 the Pane907 force Canvas 910 is generated. Canv as910 is attached to Pane907.
  • Canvas910 includes various commands.
  • Step 7 the Canvas 910 builds a data structure for rendering the document on the screen. For XHTML, this includes a box tree structure.
  • Figure 19 (b) shows an overview of the Zone configuration using the MVC paradigm.
  • the model (M) since Zone and Facet are inputs related to the document, the model (M) includes Zone and Facet. Since the canvas and the data structure for rendering the document on the screen are the output that the user sees on the screen, the view (V) corresponds to the canvas and the data structure. Since Command performs control operations on the document and its various relationships, Control contains the Command contained in the Canvas.
  • the document used in this example contains both text and images.
  • Text is represented using XHTML, and images are represented using SVG.
  • Figure 20 details the MVC representation of the relationship between the document components and the corresponding object.
  • DocumentlOOl is attached to DocumentContainer 1002 that holds Document 1001.
  • the document is represented by a DOM tree 1003.
  • the DOM tree includes ApexNodel004.
  • ApexNode is represented by a black circle. Nodes that are not vertices are represented by white circles. A Facet used to edit a node is represented by a triangle and is attached to the corresponding node. Since a document has text and images, the DOM tree for this document contains an XHTML part and an SV G part.
  • ApexNodel004 is the top node of the XHTML subtree. This is attached to XHTMLPanelO 05, the top pane for the physical representation of the XHTML part of the document. ApexNodel004 is also attached to XHTMLZ onel006, which is part of the document's DOM tree.
  • Facet corresponding to Nodel004 is also attached to XHTMLZonel006.
  • XHTMLZone 1006 is attached to XHTMLPanel005.
  • XHTMLEditlet generates XHTMLCanvasl007, which is a logical representation of the document.
  • XHTMLCanvasl007 is attached to XHTMLPane 1005.
  • XHTMLCanvasl007 is an XHTML component of Document 1001 Creates BoxTreel009 for a single item.
  • Various Commandl008 required to hold and render the XHTML part of the document are also added to XHTMLCanvasl007.
  • SVGZone 1011 which is part of the Document 1001 DOM tree that represents the document's SVG component.
  • ApexNodelOlO is attached to SV GPanelO 13, which is the highest Pane in the physical representation of the SVG part of the document.
  • SVGCanvas 1012 representing the logical representation of the SVG part of the document is generated by SVGEditlet and attached to SVGPanel013.
  • Data structures and commands for rendering the SVG portion of the document on the screen are attached to the SVGCanvas.
  • the data structure may include circles, lines, rectangles, etc. as shown.
  • FIG. 21 (a) shows a simplified MV relationship in the XHTM L component of document 1001.
  • the model is XHTMLZone 1101 for DocumentlOOl's XHTML component.
  • the XHTMLZone tree contains several Nodes and their corresponding Facets.
  • the corresponding XHTMLZone and Pane are part of the model (M) part of the MVC paradigm.
  • the View (V) part of the MVC paradigm is the corresponding XHTML Canvasl 102 and BoxTree of DocumentlOOl's XHTML component.
  • the XHTML portion of the document is rendered on the screen using the Canvas and the commands it contains. Events such as keyboard and mouse input proceed in the reverse direction as shown.
  • SourcePane has an additional function: the role as DOM holder.
  • Figure 21 (b) provides a vocabulary connection to the DocumentlOl component shown in Figure 21 (a).
  • SourcePanel 103 which acts as a DOM holder, contains the document's source DOM tree.
  • ConnectorTree is created by ConnectorFactory and creates DestinationPanel 105 that also functions as the destination DOM holder.
  • DestinationPanel 105 is laid out in the form of a box tree as XHTMLDestinationCanvasl 106.
  • Plug-in Subsystem Box Library Connection, and Connector Figures 22 (a)-(c) show further details related to the plug-in subsystem, the library connection, and the connector, respectively.
  • Plug-in subsystems are used to add or replace functionality in a document processing system.
  • the plug-in subsystem includes ServiceBrokerl041.
  • a ZoneFactoryServicel 201 attached to ServiceBrokerl041 generates a Zone for a part of a document.
  • EditletService 1202 is also attached to ServiceBroke rl041.
  • EditletServicel202 generates Canvas corresponding to Node in Zone.
  • ZoneFactory examples are XHTMLZone Factoryl211 and SVGZoneFactoryl 212, which generate XHTMLZone and SVGZone, respectively.
  • the text component of the document may be represented by generating XHTMLZone, and the image may be represented using SVGZone.
  • EditletService examples include XHTMLEditle U221 and SVGEditletl222.
  • Figure 22 (b) shows further details related to the vocabulary connection.
  • the vocabulary connection is an important feature of a document processing system, and enables consistent expression and display of documents in two different ways.
  • the VCManager 302 that holds the ConnectorFactory 303 is a part of the vocabulary connection subsystem.
  • ConnectorFactory 303 generates a connector 304 for the document.
  • the Connector monitors the nodes in the source DOM and modifies the nodes in the destination DOM to maintain consistency between the two representations.
  • Template 317 represents the conversion node of several nodes.
  • a vocabulary connection descriptor (VCD) file is a list of Templates that represent a number of rules that transform an element or set of elements that satisfy a particular path or rule into another element.
  • Template 317 and Command Template 318 are all attached to VCManager 302.
  • VCManager is an object that manages all sections in a VCD file. One VCManager object is created for one VCD file.
  • FIG. 22 (c) provides further details related to the Connector.
  • ConnectorFactory303 generates a connector such as “No ⁇ ”.
  • ConnectorFactory303 is attached to Vocabulary ⁇ T emplate ⁇ and ElementTemplate, respectively, VocabularyConnector ⁇ T Generate emplateConnector and ElementConnector.
  • the VCManager 302 holds a ConnectorFactory 303.
  • the corresponding VCD file is read to generate the Vocabulary.
  • ConnectorFactory303 is generated.
  • the onnectorFactory30d is related to the ZoneFactory that generates the Zone and the Editlet that generates the anvas.
  • VCCa nvas also creates an ApexNode Connector in the source DOM tree or Zone. Child connectors are generated recursively as needed. ConnectorTree is created by a set of templates in a VCD file.
  • a template is a set of rules for converting an element of a markup language into another element. For example, each template is matched to the source DOM tree or Zone. If it matches properly, a vertex connector is created. For example, the template “/ * / D” matches all branches that start with node A and end with node D, regardless of what nodes are in between. Similarly, “ ⁇ B” matches all “B” nodes from the root.
  • FIG. 23 shows an example of a VCD script using VCManager and ConnectorFactoryTree for the MySampleXMLj file. It shows the vocabulary section, template section and corresponding components in VCManager in the script file.
  • vcd vocabulary
  • the attribute “match_ ⁇ 3 ⁇ 4“ sample: root ”,“ label ”is“ MySampleXML ”, and“ caU-temp late ” is sample template.
  • Vocabulary includes a vertex element as “sample: root” in VCManager of “MySampleXML”.
  • the corresponding UI label is “MySampleXML”.
  • the tag is “vcd: template” and the name is “sample: template”.
  • FIG. 24 (a) shows a detailed description of loading the document “MySampleXML”.
  • the document is loaded from the storage 1405.
  • DOMService Generates DocumentContainerl401 corresponding to DOM tree and DocumentManagerl406.
  • DocumentContainerl401 is attached to DocumentManagerl406.
  • the document contains XHTML and MySampleXML subtrees.
  • XHTML ApexNode 1403 is the top node of XHTML with the tag “xhtml: html”.
  • “The ApexNodel404 of MySampleX MLJ is the top node of“ MySampleXML ”with the tag“ sample: root ”.
  • RootPane In step 2 shown in Fig. 24 (b), RootPane generates XHTMLZone, Facet, and Canvas of the document. It is generated corresponding to Panel407, XHTMLZonel408, XHTMLCanvasl409, and BoxTreel410 force ApexNode 1403.
  • step 3 shown in Fig. 24 (c) a tag "sample: root” that XHTMLZone does not know is found, and a SubPane is generated from the XHTMLCanvas area.
  • Step 4 shown in FIG. 25 SubPane can handle “sample: root”, and generate an appropriate Zone.
  • This ZoneFactoryi; ZoneFactory line is located in the correct Vocabulary. It contains the contents of the VocabularySection of “MySampleXML”.
  • Step 5 shown in FIG. 26 Vocabulary corresponding to “MySampleXML” generates Default Zonel601. A corresponding Editlet is generated and SubPanel501 is provided to generate the corresponding Canvas. Editlet generates VCCanvas. And that is called Template3 ⁇ 4ection. Connectorractory freet a.3; And onnectorFactoryTree becomes ConnectorTree and generates all connectors.
  • each Connector creates a destination DOM object.
  • Some of the connectors contain xpath information.
  • the xpath information contains one or more xpath expressions that are used to determine the subset of the source DOM tree that needs to be monitored for change Z modifications.
  • step 7 shown in Figure 28 the vocabulary creates a DestinationPane for the destination DOM tree from the source DOM pane. This is done based on the SourcePane. The ApexNode of the destination tree is set to DestinationPane and the corresponding Zone. DestinationPane creates a DestinationCanvas and tests the document You will be provided with your own Editlet that will build the data structure and commands to render in the format of the tenion.
  • Figure 29 (a) shows the flow when an event occurs on a node that does not have a corresponding source node and exists only in the destination tree.
  • Events acquired by Canvas such as mouse events and keyboard events, pass through the destination tree and reach the ElementTemplateConnector izs. Since ElementTemplateConnector does not have a corresponding node, the transmitted event is not an editing operation on the source node. If the ElementTemplateConnector matches the command set in the OmmandTemplate, the corresponding Action will be executed. If there is no matching command, ElementTemplateConnector ignores the transmitted event.
  • Fig. 29 (b) shows the flow when an event occurs on a node of the destination tree associated with the source node by TextOfConnector.
  • TextOfConnector gets the node force text node specified by the XPath of the source DOM tree and maps it to the node of the destination DOM tree.
  • Events acquired by Canvas, such as mouse events and keyboard events, pass through the destination tree and are transmitted to the Text OlConnector.
  • TextO! Connector maps the transmitted event to the edit command of the corresponding source node and loads it on Queuel053.
  • An edit command is a set of DOM API calls that are executed via Face t. When the queued command is executed, the source node is edited.
  • TextOfConnector reconstructs the destination tree so that changes in the source node are reflected in the corresponding destination node.
  • ConnectorFactory re-evaluates this control statement and reconstructs TextOfConnector, and then the destination. The tree is rebuilt.
  • FIG. 30 is a schematic diagram showing a Semantic Web layer cake.
  • the document processing device 20 shown in the base technology is a compound document, Web service, etc. As described above, it is effective as an XML document (XML data) handling technology in each scene.
  • the XML handling technology shown in the premise technology may be the key technology that connects existing XML data and semantic web applications with a common language called “XML”.
  • Fig. 31 is a schematic diagram showing a general handling form of various document files including personal information.
  • the purpose of this embodiment is to collectively manage document files such as forms created individually in each department and the input browser therefor without major changes.
  • FIG. 32 is a diagram showing the flow of the personal information management support system in the present embodiment.
  • a security administrator collects personal information contained in the document file of each department. There is a vast number of nominations for local terms used in each department's document file. As a result, security administrators do not fully understand these local terms.
  • the ontologies for document structure and attributes are based on internal standards.
  • a global ontology Each department links its local terminology to the global ontology terminology as a local ontology.
  • the company's internal standards for Groon Leologies and local ontologies for each department are seamlessly linked.
  • a search based on semantic high-level concepts is performed based on the global ontologies of internal standards. This semantic superordinate concept is translated into terms that are actually used in each department.
  • In-house database capability XML structure documents are searched and the results are listed.
  • the document files listed as search results are distributed to each department.
  • the manager of each department checks personal information such as a person's name and address with respect to the distributed document file, and gives an annotation such as “applicable to personal information processing”. At this time, annotations are given using the local terms of each department.
  • FIG. 33 is a schematic diagram for explaining the scene 1 of FIG. 32 in detail.
  • tags used as internal standards are defined as a global ontology.
  • the company as a whole has abstract and general-purpose definitions for the types of document files and the tags described there.
  • tags such as “Creater” and “CreateDate”, that is, a global ontology
  • a schema that includes tags such as “Creater” and “CreateDate”, that is, a global ontology
  • the “business daily report” tag is a tag that inherits the “Doc” tag.
  • tags such as “reporter” and “report date” inherit the “Creater” tag and “CreateDate” tag, respectively.
  • tags defined based on the global ontology are referred to as “model tags”.
  • the "MeetingPlace” tag related to the address is a model tag defined in the Global Ontology.
  • the security administrator searches for the data in the document file based on the local ontology using the model tag name such as “MeetingPlace”.
  • “The model tag“ MeetingPlaceJ ” has been renamed as a“ business trip ”tag in the research department. In the sales department, it is renamed as “address”.
  • the tag “MeetingPlace” in the Global Renology is a tag name corresponding to the business of each department, such as “business trip destination” or “address”, in the low power theory.
  • a tag defined based on a local ontology is referred to as an “entity tag”.
  • FIG. 34 is a diagram showing the relationship between the global ontology and the local ontology in the research department.
  • the “MeetingPlace” tag in the global ontology is the “business trip” tag in this research department.
  • “MeetingPlace” is defined as a property of the DocumentEntityJ class. ⁇
  • the data structure of the model tag as an internal standard is inherited as it is as the data structure of the entity tag of the document file of each department.
  • the document file created based on the internal standard global ontology is called “parent document file”, and the tag structure is called “parent schema”.
  • a document file that has a schema inherited from the parent schema (hereinafter referred to as a “child schema”) and is generated in each department based on the local ontology is referred to as a “child document file”.
  • the child document file display layout may be created for each department, or a standard display layout may be provided.
  • the property of the entity tag accepts the property of the model tag as it is.
  • the name of the entity tag can be renamed according to the business of each department.
  • the child document file is held as a set together with a tag mapping table for mapping entity tags to model tags. For example, the “Business trip destination” tag is mapped to the “MeetingPlace” tag that is the successor!
  • FIG. 35 is a diagram showing the relationship between the global ontology and the local ontology in the sales department.
  • the “MeetingPlace” tag in the global ontology is an “address” tag for this sales department.
  • the security administrator can, for example, search for the data entered corresponding to the entity tag that inherits the MeetingPl acej t model tag for various child document files in the company.
  • the security administrator searches the internal database using the “MeetingPlace” tag as a search key
  • the entity tag name corresponding to each child schema is specified by the tag mapping table described above. For example, if a search instruction is given using a “MeetingPlace” tag as a search key for a child document file used in the research department, the search key is converted to a tag name “business trip destination”.
  • the child document file can also be detected for data having the “business trip” tag as an input item.
  • the security administrator can search for the desired data in the company document by using the model tag name without knowing the entity tag name.
  • child document file users in each department can freely set the entity tag name as long as they follow the global ontology. This improves the convenience for security administrators and users in each department to handle internal documents. be able to.
  • FIG. 36 is a schematic diagram for explaining an aspect in which annotation is added to a child document file.
  • Annotation indicating “personal information target data” is set for the name and address of personal information in the research department.
  • Sales departments also set annotations that indicate “personal information target data” for names and addresses of personal information.
  • the security system of the company sets this annotation and masks the part that prevents personal information from being leaked to the outside.
  • Such an annotation is also a kind of component of the structure document file like the tag.
  • the parent schema includes multiple types of annotations based on the global ontology, for example, “Important” annotation.
  • the child schema includes an annotation that inherits this “Important” annotation.
  • entity annotation The user can rename the annotation in this child schema (hereinafter referred to as “entity annotation”) in the same manner as the entity tag.
  • entity annotation can be renamed according to the business, such as “Business Secret” annotation.
  • model annotation which is defined based on the global ontology. Inherit as it is.
  • the child document file is held as a set together with an annotation mapping table for mapping the entity annotation to the model annotation by the parent schema.
  • the security administrator searches the internal database using the model annotation as a search key
  • the entity annotation name corresponding to each child schema is specified by the annotation mapping table described above.
  • the security administrator Even without knowing the name of the entity annotation, it is possible to search for the desired data in the in-house literacy using the model annotation name.
  • child document file users in each department can freely set annotation names as long as they follow the global ontology, which can improve the convenience for security administrators and users in each department to handle internal documents. it can.
  • annotation there is a merit that it is not necessarily restricted by the schema called tag.
  • one type of annotation may be set for two types of data input in the “ ⁇ ⁇ 61 3 ⁇ 4? 1 & 06” and “ ⁇ ⁇ 61 3 ⁇ 40 0” tags.
  • annotation may be set for a part of the input data to the “MeetingPlace” tag.
  • model annotations for example, various types of annotations such as annotations for specifying personal information and annotations for specifying important information may be prepared.
  • Entity annotation power inheriting model annotation for specifying personal information for child document file may be set in the data range corresponding to personal information. Then, for example, data for which the inherited entity annotation for designating personal information is set may be prevented from being transmitted outside the company. More specifically, by using the model annotation for the security system to specify personal information as a search key, the personal information of the child document file is specified, and these data are masked so that the personal information is externally disclosed. It can be treated so as not to leak.
  • FIG. 37 is a schematic diagram for explaining security management by annotation.
  • a tag for specifying personal information is managed with a tag name of “SecurityName” in order to give a tag to the in-house document file.
  • Annotations may be set for tags in child document files, all or part of the data entered for tags, or sets of data entered for multiple tags. .
  • Model tag power that is the inheritance source of the specified entity tag List of entity tags in all domains that are inherited
  • FIG. 38 shows another example of the tag mapping table described in relation to FIG. 34 and FIG.
  • model tag power defined as “Customer” is defined as “business trip destination” in the research department and “customer name” in the sales department.
  • RDF Resource Description Framework Shema
  • OWL Web Ontology Language
  • Semantic Web technology and XML technology can be seamlessly combined.
  • the document processing apparatus 20 can handle the consistency of data and the browser that handles data that is a problem in the real world.
  • a personal information management support system that links the above two technologies can be implemented using the document processing device 20 as a platform.
  • the processing method shown in the above embodiment has an effect that it is easy to maintain data consistency of a document file handled in a business organization such as a company.
  • model tag set a standard set of model tags (hereinafter referred to as “model tag set”) is prepared in-house, and each department creates entity tags based on the model tag set based on the entity tags. You may create an XML document file. In this case, the development department, marketing department, and sales department each create an XML document with separate entity tags.
  • entity tag set the set of entity tags
  • the inheritance source is the same model tag set, so information retrieval based on model tags is possible.
  • model tag [employee]> force entity tag [department manager] and [license manager] is inherited, and an XML document file described by such entity tags is assumed. More specifically, if this XML document file contains two elements such as section manager> Kato / section manager>, ⁇ license manager> Hasegawa ⁇ / license manager>, model tag ⁇ employee If data detection is instructed for>, two element data, “Kato” and “Hasegawa”, can be detected. This is because the model tag ⁇ employee> is associated with the entity tag ⁇ section manager> and the license manager.
  • the required information can be obtained from the element data of the entity tag using the model tag as a search key.
  • annotations as well as tags.
  • the method of generating entity tags in a form inherited from such model tags and mapping the model tags to the entity tags is referred to as a “top-down approach”.
  • tags included in an existing XML document file can be automatically linked to standard model tags.
  • FIG. 39 is a functional block diagram of the document processing apparatus 3000 that realizes the mapping function between the entity tag and the model tag while using the various functions of the document processing apparatus 20 described in the base technology.
  • Document processing apparatus 3000 includes a user interface processing unit 3100, a communication unit 3130, a data processing unit 3200, and a data holding unit 3250.
  • the user interface processing unit 3100 is in charge of processing related to the entire user interface, such as input processing from the user and information display to the user.
  • the user interface processing unit 3100 will be described as being provided with the user interface service of the document processing apparatus 3000.
  • the user may The document processing apparatus 3000 may be operated via a network.
  • the communication unit 3130 receives the operation instruction information on the user terminal power, and transmits the processing result information executed based on the operation instruction to the user terminal.
  • the data processing unit 3200 executes various types of data processing based on data acquired from the user interface processing unit 3100 and the communication unit 3130.
  • the data processing unit 3200 also serves as an interface between the user interface processing unit 3100 and the data holding unit 3250.
  • the data holding unit 3250 stores various data such as setting data prepared in advance and data received from the data processing unit 3200.
  • the user interface processing unit 3100 includes an input unit 3110 that receives input from the user and a display unit 3120 that displays various types of information to the user.
  • the function of the display unit 3120 is realized by the display unit 56 of the document processing apparatus 20 described in the base technology.
  • the input unit 3110 includes an annotation setting unit 3112 and a document acquisition unit 3114.
  • An annotation setting unit 3112 sets an annotation for an XML document based on an instruction input from the user. Annotations are set as tag attributes.
  • the document acquisition unit 3114 acquires an XML document file to be processed.
  • the communication unit 3130 communicates with an external device such as another document processing device 3000 or a predetermined server device.
  • Communication unit 3130 includes a document transmission unit 3132 and a document reception unit 3134.
  • the document transmission unit 3132 transmits the XML document file to the external device.
  • the document receiver 3134 receives an XML document file from an external device.
  • the document processing apparatus 3000 acquires the XML document file to be processed via the document acquisition unit 3114 and the document reception unit 3134.
  • the data holding unit 3250 includes a file holding unit 3252, a tag mapping table holding unit 3254, and an annotation mapping table holding unit 3256.
  • the file holding unit 3252 holds an XML document file, particularly an XML document file described by entity tags.
  • the tag mapping table holding unit 3254 holds a tag mapping table in which entity tags and model tags are associated with each other.
  • An annotation mapping table holding unit 3256 holds an annotation mapping table in which entity annotations and model annotations are associated with each other.
  • the data processing unit 3200 includes a document editing unit 3210, a search unit 3220, a mapping processing unit 3230, and a mask processing unit 3240.
  • the document editing unit 3210 executes an XML document file editing process in response to an input from the user.
  • the main functions of the document editing unit 3210 are realized by the basic functions of the document processing apparatus 20 described in the base technology, in particular, the editing unit 24.
  • a user may convert an XML document file described by a model tag set into an XML document file described by entity tags.
  • XML document files may be created by freely defining entity tags from the beginning.
  • the document editing unit 3210 includes a tag renaming unit 3212 and an annotation renaming unit 3214.
  • the tag renaming unit 3212 When the top-down approach is taken, the tag renaming unit 3212 generates an entity tag by changing the model tag name.
  • the mapping recording unit 3234 of the mapping processing unit 3230 records the entity tag and the change source model tag in association with the tag mapping table.
  • the annotation rename part 3214 is the same, and an entity annotation is generated by changing the model annotation name.
  • the mapping recording unit 3234 records the entity annotation and the change source model annotation in association with the model mapping table.
  • the mapping recording unit 3234 When entity tags and entity annotations are generated by the top-down approach, the mapping recording unit 3234 automatically performs association.
  • the correspondence detection unit 3322 of the mapping processing unit 3230 automatically detects the correspondence between the model tag and the entity tag, and the model annotation and the entity annotation. The detection method will be described later.
  • the search unit 3220 searches the tag document for the XML document file.
  • Search unit 3220 includes a tag search unit 3222 and an annotation search unit 3224.
  • Tag search unit 3222 searches for a tag. For example, in the case of the previous example, when the model tag ⁇ Employee> is used as the search key, the tag search unit 3222 refers to the tag mapping table and selects the entity tag associated with the model tag [Employee]. To detect. In other words, entity tag section manager and license manager are detected from the XML document file, and their element data is acquired.
  • the search method is not limited to such a model tag ⁇ entity tag ⁇ entity tag ⁇ model tag ⁇
  • a search method called an entity tag is also possible. For example, suppose that an XML document file A uses entity tag manager> and another XML document file B uses entity tag license manager>. At this time, it is possible to search for XML document file B entity tag> license manager> using the section tag of entity tag of XML document file A as a search key. In this case, the tag search unit 3222 identifies the employee> who is the model tag associated with the entity mapping section of the XML document file A> and the tag mapping table.
  • the tag search unit 3222 identifies the model tag “employee >> and the entity tag“ license manager> ”associated with the tag mapping table. In this way, another entity tag mapped to the same model tag can be searched.
  • a tag mapping table is prepared for each combination of model tag set and entity tag set.
  • another entity tag that is included in the same XML document file A and mapped with the same model tag can be searched using the entity tag of the XML document file A as a search key.
  • the annotation search unit 3224 searches for annotations. Similarly to the tag search, the annotation search unit 3224 searches the corresponding entity annotation in the XML document file using the model annotation as a search key. You can also search for another entity annotation that is mapped to the same model annotation using the entity annotation as a search key.
  • the mapping processing unit 3230 manages the mapping of tag annotations.
  • the basic mechanism is the same as the mechanism of the Vocabulary connection by VC unit 80 explained in the base technology.
  • the mapping processing unit 3230 includes a correspondence detection unit 3232 and a mapping recording unit 3234.
  • the correspondence detection unit 3232 detects the correspondence between the entity tag and the model tag, and the entity annotation and the model annotation in the bottom-up approach.
  • the correspondence detection unit 3232 refers to a synonym table or a concept word table prepared in advance and detects the correspondence.
  • the synonym table describes combinations of words that are related to the synonym. For example, for the word “car”, words such as “train” and “bicycle” are registered as synonyms. Model tag "car” is defined , And the user has defined the entity tag in the XML document file.
  • the correspondence detection unit 3232 refers to the synonym table to detect the correspondence between the model tag car> and the real tag train>, and the mapping recording unit 3234 records both tags in the tag mapping table. To do.
  • the concept word table combinations of words having a relationship between a superordinate concept and a subordinate concept are described. For example, for the word “car”, words corresponding to subordinate concepts such as “luxury car” and “new model car” are registered. If the model tag ⁇ car> is defined, when the user defines a high-class car in the XML document file> and the entity tag, the correspondence detection unit 3232 refers to the synonym table to The tagging car 3> detects the correspondence between the entity tag and the luxury car>, and the mapping recording unit 3234 records each tag in the tag mapping table in association with each other.
  • the correspondence detection unit 3232 detects the correspondence between tags with reference to both or one of the synonym table and the concept word table. The same applies to annotations.
  • users may explicitly map any model tag in any model tag set to entity tags.
  • the mapping recording unit 3234 records the correspondence between the entity tag and the model tag in the tag mapping table. You can associate multiple types of entity tag sets with a single model tag set, or you can associate one entity tag set with multiple types of model tag sets.
  • the mask processing unit 3240 makes the information designated by the user private. For example, when displaying an XML document file held in the file holding unit 3252 on the screen, suppose that information related to the employee name is excluded from display for personal information protection. In this case, the user specifies the data to be hidden by the model tag ⁇ employee>.
  • the mask processing unit 3240 refers to the tag mapping table and detects the corresponding entity tag in the XML document file. Then, “Kato”, which is the element data of the corresponding entity tag ⁇ section manager> ya ⁇ license manager>, excludes “Hasegawa” from the display target.
  • an XML document file from which hidden data is excluded is newly generated by converting the XML document file with an XSL style sheet.
  • the data contained in the generated XML document file becomes the actual display target.
  • XML document sent to external device by document sending unit 3132 Data can also be masked when sending a document file.
  • the XML document file from which hidden data is excluded is the transmission target.
  • element data of various entity tags mapped with the model tag can be unpublished centrally by designating the non-display target data by the model tag.
  • the display color and font of the corresponding data may be changed. In this way, the mask processing unit 3240 changes the display mode of information specified by the user.
  • FIG. 40 is a schematic diagram for explaining the mapping structure between the model tag and the entity tag.
  • Model tag set 1 and model tag set 2 may be provided by different vendors.
  • the entity tag included in the XML document file 3300 or the XML document file 3302 is a tag arbitrarily set by the user other than the renamed model tag. In other words, a bottom-up approach is assumed.
  • Model tag set 1 includes model tag person and model tag employee as a subordinate concept word.
  • the word “employee” is associated with words such as “employee” as a synonym and “section manager”, “president”, “deputy manager” as subordinate concept words in the synonym table and concept word table.
  • Model tag set 2 includes “important” and “unnecessary” as model tags.
  • the XML document file 3300 includes the entity tag Employee>.
  • the correspondence detection unit 32 32 refers to the synonym table and detects that “employee”, !! word and “employee” t ⁇ ⁇ word have a synonym relation.
  • the mapping recording unit 3234 records the entity tag “employee >> of the XML document file 3300 in association with the model tag“ employee >> of the model tag set 1 in the tag mapping table.
  • the XML document file 3302 includes an entity tag section manager, a president, and a section manager representative.
  • the correspondence detection unit 3232 refers to the concept word table and detects that the word “section manager” is a subordinate concept word of the word “employee”.
  • the mapping recording unit 3234 associates the entity tag section manager of the XML document file 3302 with the model tag section of the model tag set 1 and records it in the tag mapping table.
  • the user explicitly maps the entity tag [President] to the model tag [Important] in Model Tag Set 2.
  • the mapping recording unit 3234 records the entity tag in the XML document file 3302 as the president> and the model tag in the model tag set 2 as important> in the tag mapping table. Also, the user explicitly maps the entity tag [deputy section manager] to the model tag [unnecessary]. For this reason, these tags are also associated in the tag mapping table.
  • This mapping between the entity tag ⁇ President> and the model tag ⁇ Important> is based on user judgment. Therefore, for the same model tag set 2, the entity tag “president” may be mapped to the model tag “unnecessary”> and the section manager> ya ⁇ deputy section manager> may be mapped to the model tag “important”.
  • the mapping may change depending on the user's value judgment and evaluation criteria.
  • the situation may change as the entity tag “deputy manager” should be mapped to ⁇ important> rather than ⁇ unnecessary>.
  • the correspondence between the entity tag and the model tag in the tag mapping table is changed.
  • the mapping table may be set for each user. For example, when ⁇ important> is mapped to user A post president, and ⁇ unnecessary> is mapped to user B post president>. In this case, even if the combination of the model tag set and the entity tag set is the same, the mapping table for user A and the mapping table for user B are additional IJs.
  • an existing XML document file can be mapped to one or more model tag sets. Therefore, even in XML document files described by various entity tag sets, it is possible to easily retrieve important element data simply by mapping the important entity tag to the model tag ⁇ important>.
  • the bottom-up approach eliminates the need to force users to use model tags or generate entity tags based on model tags. Therefore, different entity tag sets can be linked via model tag sets. For example, the entity tag set used in the development department and the marketing Although the entity tag sets used in the management part may not be separate, the information of both departments can be rationally linked through the common model tag set.
  • model tag sets can be searched from various viewpoints.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Document Processing Apparatus (AREA)

Abstract

　複数の構造化文書ファイルに含まれるデータを扱う上でのユーザの利便性を向上させる。 　子文書ファイルは、複数のタグが構造化された親文書ファイルのスキーマを継承したスキーマによって生成される。親文書ファイルに含まれるタグであるモデルタグから継承された子文書ファイルのタグである実体タグの名前は、ユーザによる指示入力に応じて変更可能である。このとき、子文書ファイルに含まれる実体タグの名前と、その実体タグの継承元であるモデルタグの名前を対応づけたタグマッピングテーブルが保持される。モデルタグの名前を検索キーとしてタグマッピングテーブルを参照して対応する実体タグの名前を検出し、その実体タグの名前を新たな検索キーとして子文書ファイルからその実体タグのデータを検出する。

Description

明 細 書
文書処理装置および文書処理方法
技術分野
[0001] この発明は、データ処理技術に関し、とくに、文書データを構造化して処理する技 術に関する。
背景技術
[0002] 近年、コンピュータの普及とネットワーク技術の進展に伴い、ネットワークを介した電 子情報の交換が盛んになつている。これにより、従来においては紙ベースで行われ ていた事務処理の多く力 ネットワークベースの処理に置き換えられつつある。
[0003] 企業にぉ 、ても、個人の知識や情報を組織全体で活用する、 Vヽゎゆるナレツジマ ネジメントが、重要な経営手法となってきている。多くの企業においては、社内にデー タベースシステムを有し、従業員からの情報を電子ファイルィ匕して蓄積する。その一 方で、従業員も、この社内データベースに蓄積されたファイルにネットワークを介して アクセスする。これによつて、組織全体としての業務効率の向上が図られる。
[0004] この社内データベースに蓄積されるファイルの多くは、 HTML (Hyper Text Markup
Language)とよばれる言語によって作成されている。また、近年においては、 XML (e Xtensible Markup Language)とよばれる言語を用いて、これらのファイルが作成される 例も多くなつてきている。
[0005] HTMLは、ウェブページを記述するための言語である。すなわち、 HTMLは文書 ファイルの表示方法を定義するマークアップ言語の一種である。これに対して、 XML は HTMLの様に、直接的にウェブページを記述することを目的とする言語というより は、むしろ、文書ファイルに含まれるデータのデータ構造を定義する機能を有する言 語といえる。 XMLによって作成された文書ファイルは、別に表示レイアウト情報を与 えることによって、ウェブページとして表示される。すなわち、 XML文書においては、 データの構造とその表示レイアウトが別々のものとして扱うことができる。 XMLのよう に、マークアップ言語を生成するための言語はメタ言語ともよばれる。
[0006] XMLは、ネットワークなどを介して他者とデータを共有するのに適した形式として注 目されており、 XML文書を作成、表示、編集するためのアプリケーションが開発され ている（たとえば、特許文献 1参照)。 XML文書は、文書型定義などにより定義された ボキヤブラリ（タグセット）に基づいて作成されている。
特許文献 1：特開 2001— 290804号公報
発明の開示
発明が解決しょうとする課題
[0007] 企業内の多くの部署では、通常、個人情報を含んだ各種文書ファイルがオリジナル のフォーマット (XMLによる構造ィ匕は行われて 、る）で存在して 、る。個人情報の流 出を防ぐため、セキュリティ管理者は、個人情報データを管理する必要がある。しかし 、こうした個人情報データは各部署において通用するローカルな用語で登録されて いる。たとえば、営業では「顧客情報」として「氏名」や「住所」が、研究開発部門でも「 データ入手先」として「氏名」「住所」が登録されている。また、こうした情報を入力する ためのブラウザ画面における表示レイアウトは各部署単位で開発されている場合が 多い。ここで、もし顧客情報を管理し、社外にこうした情報が流出することを防ごうとし た場合に、そのシステム変更として以下の業務が発生する。
[0008] 1.セキュリティ管理者が各部署で扱っている帳票などの文書ファイルに含まれる個 人情報をチェックする。
2.社内システムとして、こうした帳票の個人情報に「個人情報注意」を示すァノテ一 シヨンを付与するといつた作業と個人情報データベースの構築。
3.各部署で使用している入力画面の変更。
これら業務は非常にコストがかかる。
[0009] 本発明は、複数の構造ィ匕文書ファイルに含まれるデータを扱う上でのユーザの利 便性を向上させるための技術を提供することにある。
課題を解決するための手段
[0010] 上記課題を解決するために、本発明のある態様の文書処理装置は、複数のタグが 構造ィ匕された親文書ファイルのスキーマを継承したスキーマによって生成された子文 書ファイルを保持するファイル保持部と、親文書ファイルに含まれるタグであるモデル タグから継承された子文書ファイルのタグである実体タグの名前をユーザによる指示 入力に応じて変更するタグリネーム処理部と、子文書ファイルに含まれる実体タグの 名前と、その実体タグの継承元であるモデルタグの名前を対応づけたタグマッピング テーブルを保持するタグマッピングテーブル保持部と、モデルタグの名前を検索キー とするユーザによる検索指示入力により、タグマッピングテーブルを参照して対応す る実体タグの名前を検出し、その実体タグの名前を新たな検索キーとして子文書ファ ィルカ その実体タグのデータを検出するタグデータ検索部と、を備える。
[0011] また、この装置は、フィルタリング対象となるべきタグの種類を定めたフィルタリング 条件にしたがって、文書ファイルに含まれるタグを分類するフィルタリング処理部を備 えてもよい。このフィルタリング処理部は、分類抽出の対象となるべきモデルタグをフ ィルタリング条件にしたがって特定し、そのモデルタグの名前を検索キーとして実体タ グのデータを検出するようにタグデータ検索部に指示することにより、フィルタリングす べきタグのデータを分類抽出してもよい。
このような態様においては、たとえば、表示や外部への送信に適さないデータが入 力されるタグをフィルタリング条件として定義しておけば、このような特定の属性を持 つデータを文書ファイルカゝら抽出しやすくなる。
[0012] この装置は、ユーザにより指定された実体タグの継承元であるモデルタグをタグマツ ビングテーブルを参照して検出し、タグマッピングテーブル保持部に保持されて 、る 複数のタグマッピングテーブルを参照することによりそのモデルタグを継承するその 他の実体タグを検出する関連タグ検索部を更に備えてもよい。
[0013] 本発明の別の態様もまた、文書処理装置である。
この装置は、複数のタグが構造ィ匕された親文書ファイルのスキーマを継承したスキ 一マによって生成された子文書ファイルを保持するファイル保持部と、親文書フアイ ルに含まれるァノテーシヨンであるモデルァノテーシヨン力も継承された子文書フアイ ルのァノテーシヨンである実体ァノテーシヨンの名前をユーザによる指示入力に応じ て変更するァノテーシヨンリネーム処理部と、子文書ファイルに含まれる実体ァノテ一 シヨンの名前と、その実体ァノテーシヨンの継承元であるモデルァノテーシヨンの名前 を対応づけたァノテーシヨンマッピングテーブルを保持するァノテーシヨンマッピング テーブル保持部と、子文書ファイルに含まれるユーザによって指示されたデータに実 体ァノテーシヨンを設定するァノテーシヨン設定部と、モデルァノテーシヨンの名前を 検索キーとするユーザによる検索指示入力により、ァノテーシヨンマッピングテーブル を参照して対応する実体ァノテーシヨンの名前を検出し、その実体ァノテーシヨンの 名前を新たな検索キーとして子文書ファイル力 その実体ァノテーシヨンが設定され るデータを検出するァノテーシヨンデータ検索部と、を備える。
[0014] この装置は、子文書ファイルを外部装置に送信するファイル送信部を更に備えても よい。ァノテーシヨンデータ検索部は、子文書ファイルに含まれるデータのうち外部送 信を禁止すべきデータに設定されるモデルァノテーシヨンを検索キーとして子文書フ アイルカも該当データを検出し、ファイル送信部は、その検出されたデータの外部装 置に対する送信を抑止してもよ 、。
[0015] 本発明の別の態様もまた、文書処理装置である。
この装置は、所定のタグセットに属する実体タグによって記述された構造ィ匕文書フ アイルを取得する文書取得部と、構造化文書ファイルに含まれる実体タグを検出し、 所定のタグセットとは異なるタグセットに属するモデルタグのうち、検出した実体タグと 所定の関係にあるモデルタグを検出する対応検出部と、所定の関係にある実体タグ とモデルタグを対応づけてタグマッピングテーブルに記録するマッピング記録部と、 モデルタグを検索キーとする検索指示入力をユーザ力 受け付けると、タグマツピン グテーブルにお ヽて対応づけられて ヽる実体タグの要素データを構造ィ匕文書フアイ ルから検出するタグ検索部と、を備える。
[0016] この装置は、構造化文書ファイルに含まれるデータを画面表示させるデータ表示部 と、
表示対象外となる要素データに対応するモデルタグの指定入力をユーザ力 受け 付けると、タグマッピングテーブルにおいて対応づけられている実体タグを検出し、構 造ィ匕文書ファイルにおいてその実体タグにより特定される要素データを表示対象力 除外する表示制御部と、を更に備えてもよい。
[0017] この装置の対応検出部は、類語関係にある単語の組み合わせが定義された類語 データテーブルを参照して、構造ィ匕文書ファイル力 検出した実体タグの名前と類語 関係にある名前のモデルタグを所定の関係にあるモデルタグとして検出してもよ 、。 [0018] この装置の対応検出部は、上位概念と下位概念の関係にある単語の組み合わせ が定義された概念データテーブルを参照して、構造ィ匕文書ファイルカゝら検出した実 体タグの名前に対して上位概念にあたる名前のモデルタグを所定の関係にあるモデ ルタグとして検出してもよい。
[0019] なお、以上の構成要素の任意の組合せや、本発明の構成要素や表現を方法、装 置、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体、 データ構造などの間で相互に置換したものもまた、本発明の態様として有効である。 発明の効果
[0020] 本発明によれば、複数の構造ィ匕文書ファイルに含まれるデータを扱う上でのユーザ の利便性を向上させる上で効果がある。
図面の簡単な説明
[0021] [図 1]前提技術に係る文書処理装置の構成を示す図である。
[図 2]処理対象となる XML文書の例を示す図である。
[図 3]図 2に示した XML文書を HTMLで記述された表にマッピングする例を示す図 である。
[図 4(a)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイ ルの例を示す図である。
[図 4(b)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイ ルの例を示す図である。
[図 5]図 2に示した成績管理ボキヤブラリで記述された XML文書を、図 3に示した対 応により HTMLにマッピングして表示した画面の例を示す図である。
[図 6]ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示 するグラフィカルユーザインタフェースの例を示す図である。
[図 7]定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
[図 8]文書処理装置による XML文書の編集画面の一例を示す図である。
[図 9]文書処理装置により編集される XML文書の他の例を示す図である。
[図 10]図 9に示した文書を表示した画面の例を示す図である。
[図 11(a)]文書処理システムの基本構成を示す図である。 [図 11(b)]文書処理システム全体のブロック図を示す図である。
[図 11(c)]文書処理システム全体のブロック図を示す図である。
圆 12]文書管理部の詳細を示す図である。
[図 13]ボキヤブラリコネクションサブシステムの詳細を示す図である。
[図 14]プログラム起動部と他の構成の関係の詳細を示す図である。
[図 15]プログラム起動部によりロードされたアプリケーションサービスの構造の詳細を 示す図である。
[図 16]コアコンポーネントの詳細を示す図である。
圆 17]文書管理部の詳細を示す図である。
[図 18]アンドゥフレームワークとアンドゥコマンドの詳細を示す図である。
[図 19]文書処理システムにおいて文書がロードされる様子を示す図である。
圆 20]文書とその表現の例を示す図である。
[図 21]モデルとコントローラの関係を示す図である。
[図 22]プラグインサブシステム、ボキヤブラリコネクション、及びコネクタの詳細を示す 図である。
[図 23]VCDファイルの例を示す図である。
[図 24]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 25]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 26]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 27]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 28]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 29]コマンドの流れを示す図である。
[図 30]セマンティックウェブのレイヤケーキを示す模式図である。
圆 31]個人情報を含んだ各種文書ファイルの一般的な取り扱い形態を示す模式図 である。
圆 32]本実施例における個人情報管理支援システムのフローを示す図である。
[図 33]図 32のシーン 1について詳細に説明するための模式図である。
[図 34]研究部門におけるグローバルオントロジ一とローカルオントロジ一の関係を示 す図である。
[図 35]営業部門におけるグローバルオントロジ一とローカルオントロジ一の関係を示 す図である。
[図 36]子文書ファイルにァノテーシヨンを付与する態様を説明するための模式図であ る。
[図 37]ァノテーシヨンによるセキュリティ管理を説明するための模式図である。
[図 38]図 34や図 35に関連して説明したタグマッピングテーブルの別例を示す図であ る。
[図 39]前提技術で説明した文書処理装置の各種機能を利用しつつ、実体タグとモデ ルタグのマッピング機能を実現する文書処理装置の機能ブロック図である。
[図 40]モデルタグと実体タグのマッピング構造を説明するための模式図である。 符号の説明
[0022] 20 文書処理装置、 22 主制御ユニット、 24 編集ユニット、 30 DOMユニット、 3 2 DOM提供部、 34 DOM生成部、 36 出力部、 40 CSSュ-ッ K 42 CSS解 析部、 44 CSS提供部、 46 レンダリング部、 50 HTMLユニット、 52, 62 制御部 、 54, 64 編集部、 56, 66 表示部、 60 SVGユニット、 80 VCユニット、 82 マツ ビング部、 84 定義ファイル取得部、 86 定義ファイル生成部、 3000 文書処理装 置、 3100 ユーザインタフェース処理部、 3110 入力部、 3112 ァノテーシヨン設 定部、 3114 文書取得部、 3120 表示部、 3130 通信部、 3132 文書送信部、 3 134 文書受信部、 3200 データ処理部、 3210 文書編集部、 3212 タグリネーム 部、 3214 ァノテーシヨンリネーム部、 3220 検索部、 3222 タグ検索部、 3224 ァノテーシヨン検索部、 3230 マッピング処理部、 3232 対応検出部、 3234 マツ ビング記録部、 3240 マスク処理部、 3250 データ保持部、 3252 ファイル保持部 、 3254 タグマッピングテーブル保持部、 3256 ァノテーシヨンマッピングテーブル 保持部。
発明を実施するための最良の形態
[0023] 以下、本実施例における前提技術について述べた後、本発明の特徴を説明する。
[0024] (前提技術） 図 1は、前提技術に係る文書処理装置 20の構成を示す。文書処理装置 20は、文 書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理 するが、本前提技術では構造化文書の一例として XML文書を処理する例にっ ヽて 説明する。文書処理装置 20は、主制御ユニット 22、編集ユニット 24、 DOMユニット 3 0、 CSSユニット 40、 HTMLユニット 50、 SVGユニット 60、及び変換部の一例である VCユニット 80を備える。これらの構成は、ハードウェアコンポーネントでいえば、任意 のコンピュータの CPU、メモリ、メモリにロードされたプログラムなどによって実現され る力 ここではそれらの連携によって実現される機能ブロックを描いている。したがつ て、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合 せによっていろいろな形で実現できることは、当業者には理解されるところである。
[0025] 主制御ユニット 22は、プラグインのロードや、コマンド実行のフレームワークを提供 する。編集ユニット 24は、 XML文書を編集するためのフレームワークを提供する。文 書処理装置 20における文書の表示及び編集機能は、プラグインにより実現されてお り、文書の種別に応じて必要なプラグインが主制御ユニット 22又は編集ユニット 24に よりロードされる。主制御ユニット 22又は編集ユニット 24は、処理対象となる XML文 書の名前空間を参照して、 XML文書が 、ずれのボキヤブラリにより記述されて 、る かを判別し、そのボキヤブラリに対応した表示又は編集用のプラグインをロードして表 示や編集を実行させる。例えば、文書処理装置 20には、 HTML文書の表示及び編 集を行う HTMLユニット 50、 SVG文書の表示及び編集を行う SVGユニット 60など、 ボキヤブラリ（タグセット)ごとに表示系及び編集系がプラグインとして実装されており、 HTML文書を編集するときは HTMLユニット 50が、 S VG文書を編集するときは S V Gユニット 60が、それぞれロードされる。後述するように、 HTMLと SVGの双方の構 成要素を含む複合文書が処理対象となって ヽる場合は、 HTMLユニット 50と SVG ユニット 60の双方がロードされる。
[0026] このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後 力 適宜機能を追加又は削除することができるので、プログラムを格納するハードデ イスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行 時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体 としても、プラグインの形で新たなボキヤブラリに対応することが可能なので開発が容 易となり、ユーザとしても、プラグインの追カ卩により容易かつ低コストにて機能を追カロ することができる。
[0027] 編集ユニット 24は、ユーザインターフェースを介してユーザ力も編集指示のイベント を受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実 行 (リドウ）又は実行の取消（アンドゥ）などの処理を制御する。
[0028] DOMユニット 30は、 DOM提供部 32、 DOM生成部 34、及び出力部 36を含み、 X ML文書をデータとして扱うときのアクセス方法を提供するために定められた文書ォ ブジェクトモデル（Document Object Model: DOM)に準拠した機能を実現する。 DO M提供部 32は、編集ユニット 24に定義されているインタフェースを満たす DOMの実 装である。 DOM生成部 34は、 XML文書力も DOMツリーを生成する。後述するよう に、処理対象となる XML文書力 VCユニット 80により他のボキヤブラリにマッピング される場合は、マッピング元の XML文書に対応するソースツリーと、マッピング先の X ML文書に対応するデスティネーションツリーが生成される。出力部 36は、例えば編 集終了時に、 DOMツリーを XML文書として出力する。
[0029] CSSユニット 40は、 CSS解析部 42、 CSS提供部 44、及びレンダリング部 46を含 み、 CSSに準拠した表示機能を提供する。 CSS解析部 42は、 CSSの構文を解析す るバーサの機能を有する。 CSS提供部 44は、 CSSオブジェクトの実装であり、 DOM ツリーに対して CSSのカスケード処理を行う。レンダリング部 46は、 CSSのレンダリン グエンジンであり、 CSSを用いてレイアウトされる HTMLなどのボキヤブラリで記述さ れた文書の表示に用いられる。
[0030] HTMLユニット 50は、 HTMLにより記述された文書を表示又は編集する。 SVGュ ニット 60は、 SVGにより記述された文書を表示又は編集する。これらの表示 Z編集 系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部（Canvas) 56、 66、編集指示を含むイベントを送受信する制御部（Editlet) 52、 62、編集コマン ドを受けて DOMに対して編集を行う編集部 (Zone) 54、 64を備える。制御部 52又は 62が外部力も DOMツリーの編集コマンドを受け付けると、編集部 54又は 64が DO Mツリーを変更し、表示部 56又は 66が表示を更新する。これらは、 MVC (Model-Vi ew-Controller)と呼ばれるフレームワークに類似する構成をとつており、概ね、表示部 56及び 66が「View」に、制御部 52及び 62が「Controller」に、編集部 54及び 64と D OMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置 20では、 XML文書をツリー表示形式で編集するだけでなく、それぞれのボキヤブラリに応じた 編集を可能とする。例えば、 HTMLユニット 50は、 HTML文書をワードプロセッサに 類似した方式で編集するためのユーザインターフェースを提供し、 SVGユニット 60は 、 SVG文書を画像描画ツールに類似した方式で編集するためのユーザインターフエ ースを提供する。
[0031] VCユニット 80は、マッピング部 82、定義ファイル取得部 84、及び定義ファイル生 成部 86を含み、あるボキヤブラリにより記述された文書を、他のボキヤブラリにマツピ ングすることにより、マッピング先のボキヤブラリに対応した表示編集用プラグインで文 書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機 能を、ボキヤブラリコネクション（Vocabulary Connection: VC)と呼ぶ。定義ファイル取 得部 84は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファ ィルは、ノードごとに、ノード間の対応 (コネクション)を記述する。このとき、各ノードの 要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を 用いた演算式を記述してもよい。これらの機能については、後で詳述する。マツピン グ部 82は、定義ファイル取得部 84が取得したスクリプトファイルを参照して、 DOM生 成部 34にデスティネーションツリーを生成させ、ソースツリーとデスティネーションッリ 一の対応関係を管理する。定義ファイル生成部 86は、ユーザが定義ファイルを生成 するためのグラフィカルユーザインターフェースを提供する。
[0032] VCユニット 80は、ソースツリーとデスティネーションツリーの間のコネクションを監視 し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザ 力も編集指示を受け付けると、まずソースツリーの該当するノードを変更する。 DOM ユニット 30が、ソースツリーが変更された旨のミューテーシヨンイベントを発行すると、 VCユニット 80は、そのミューテーシヨンイベントを受けて、ソースツリーの変更にデス ティネーシヨンツリーを同期させるベぐ変更されたノードに対応するデスティネーショ ンツリーのノードを変更する。デスティネーションツリーを表示/編集するプラグイン、 例えば HTMLユニット 50は、デスティネーションツリーが変更された旨のミューテー シヨンイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新 する。このような構成により、少数のユーザにより利用されるローカルなボキヤブラリに より記述された文書であっても、他のメジャーなボキヤブラリに変換することで、文書を 表示することができるとともに、編集環境が提供される。
[0033] 文書処理装置 20により文書を表示又は編集する動作について説明する。文書処 理装置 20が処理対象となる文書を読み込むと、 DOM生成部 34が、その XML文書 力も DOMツリーを生成する。また、主制御ユニット 22又は編集ユニット 24は、名前空 間を参照して文書を記述しているボキヤブラリを判別する。そのボキヤブラリに対応し たプラグインが文書処理装置 20にインストールされて 、る場合は、そのプラグインを ロードして、文書を表示/編集させる。プラグインカ Sインストールされていない場合は 、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する 場合、定義ファイル取得部 84が定義ファイルを取得し、その定義に従って、デスティ ネーシヨンツリーが生成され、マッピング先のボキヤブラリに対応するプラグインにより 文書が表示 Z編集される。複数のボキヤブラリを含む複合文書である場合は、後述 するように、それぞれのボキヤブラリに対応したプラグインにより、文書の該当箇所が それぞれ表示 Z編集される。定義ファイルが存在しない場合は、文書のソース又はッ リー構造を表示し、その表示画面にぉ 、て編集が行われる。
[0034] 図 2は、処理対象となる XML文書の例を示す。この XML文書は、生徒の成績デー タを管理するために用いられる。 XML文書のトップノードである構成要素「成績」は、 配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、 属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」 は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞ れ、国語、数学、理科、社会の成績を格納する。例えば、名前カ^ A」である生徒の国 語の成績は「90」、数学の成績は「50」、理科の成績は「75」、社会の成績は「60」で ある。以下、この文書で使用されているボキヤブラリ（タグセット）を、「成績管理ボキヤ ブラリ」と呼ぶ。
[0035] 本前提技術の文書処理装置 20は、成績管理ボキヤブラリの表示 Z編集に対応し たプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示 するためには、前述した VC機能が用いられる。すなわち、成績管理ボキヤブラリを、 プラグインが用意された別のボキヤブラリ、例えば、 HTMLや SVGなどにマッピング するための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成す るためのユーザインターフェースについては後述することにして、ここでは、既に定義 ファイルが用意されているとして説明を進める。
[0036] 図 3は、図 2に示した XML文書を HTMLで記述された表にマッピングする例を示 す。図 3の例では、成績管理ボキヤブラリの「生徒」ノードを、 HTMLにおける表（「TA BLE」ノード)の行（「TR」ノード）に対応づけ、各行の第 1列には属性値「名前」を、第 2 列には「国語」ノードの要素値を、第 3列には「数学」ノードの要素値を、第 4列には「 理科」ノードの要素値を、第 5列には「社会」ノードの要素値を、それぞれ対応付ける 。これにより、図 2に示した XML文書を、 HTMLの表形式で表示することができる。 また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザ が HTMLによる表示画面上で、 HTMLユニット 50の編集機能により、これらの値を 編集することができる。第 6列には、国語、数学、理科、社会の成績の加重平均を算 出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定 義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集 時のユーザの利便性を向上させることができる。なお、第 6列は、編集不可であること が指定されており、平均点のみを個別に編集することができないようにしている。この ように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの 誤操作を防ぐことができる。
[0037] 図 4 (a)及び図 4 (b)は、図 2に示した XML文書を図 3に示した表にマッピングする ための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義された スクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプ レートが記述されている。図 4 (a) (b)の例では、コマンドとして、「生徒の追加」と「生 徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作 と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テン プレートとして、表の第 1行に「名前」、「国語」などの見出しが表示され、第 2行以降 に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を 表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し 、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生 徒」の内容を表示する行のうち、第 6列には、「(src:国語 + src:数学 + src:理科 + src: 社会） div 4」という計算式が記述されており、生徒の成績の平均が表示されることを 意味する。
[0038] 図 5は、図 2に示した成績管理ボキヤブラリで記述された XML文書を、図 3に示した 対応により HTMLにマッピングして表示した画面の例を示す。表 90の各行には、左 から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平 均点が表示されている。ユーザは、この画面上で、 XML文書を編集することができる 。たとえば、第 2行第 3列の値を「70」に変更すると、このノードに対応するソースッリ 一の要素値、すなわち、生徒「B」の数学の成績が「70」に変更される。このとき、 VC ユニット 80は、デスティネーションツリーをソースツリーに追従させるベぐデスティネ ーシヨンツリーの該当箇所を変更し、 HTMLユニット 50力 変更されたデスティネー シヨンツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「 B」の数学の成績が「70」に変更され、更に、平均点が「55」に変更される。
[0039] 図 5に示した画面には、図 4 (a) (b)に示した定義ファイルに定義されたように、「生 徒の追加」及び「生徒の削除」のコマンドカ -ユーに表示される。ユーザがこれらの コマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。 このように、本前提技術の文書処理装置 20では、階層構造の末端の構成要素の要 素値を編集するのみではなぐ階層構造を編集することも可能である。このようなッリ 一構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表 の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応 づけられてもよい。また、他のボキヤブラリを埋め込むコマンドがユーザに提供されて もよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データ を追加することもできる。以上のように、 VC機能により、 HTMLユニット 50の表示 Z 編集機能を利用しつつ、成績管理ボキヤブラリで記述された文書を編集することが可 能となる。 [0040] 図 6は、ユーザが定義ファイルを生成するために、定義ファイル生成部 86がユーザ に提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域 91には、 マッピング元の XML文書がツリー表示されている。画面右側の領域 92には、マツピ ング先の XML文書の画面レイアウトが示されている。この画面レイアウトは、 HTML ユニット 50により編集可能となっており、ユーザは、画面右側の領域 92において、文 書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポイン ティングデバイスにより、画面左側の領域 91に表示されたマッピング元の XML文書 のノードを、画面右側の領域 92に表示された HTMLによる画面レイアウト中へドラッ グ&ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとの コネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、 HTML画 面の表 90の第 1行第 3列にドロップすると、「数学」ノードと、 3列目の「TD」ノードの間 にコネクションが張られる。各ノードには、編集の可否が指定できるようになつている。 また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定 義ファイル生成部 86は、画面レイアウトとノード間のコネクションを記述した定義フアイ ルを生成する。
[0041] XHTML, MathML、 SVGなどの主要なボキヤブラリに対応したビューヮゃエディ タは既に開発されて 、るが、図 2に示した文書のようなオリジナルなボキヤブラリで記 述された文書に対応したビューヮゃエディタを開発するのは現実的でな 、。しかし、 上記のように、他のボキヤブラリにマッピングするための定義ファイルを作成すれば、 ビューヮゃエディタを開発しなくても、 VC機能を利用して、オリジナルなボキヤブラリ で記述された文書を表示 ·編集することができる。
[0042] 図 7は、定義ファイル生成部 86により生成された画面レイアウトの他の例を示す。図 7の例では、成績管理ボキヤブラリで記述された XML文書を表示するための画面に 、表 90と、円グラフ 93が作成されている。この円グラフ 93は、 SVGにより記述される。 後述するように、本前提技術の文書処理装置 20は、一つの XML文書内に複数のボ キヤブラリを含む複合文書を処理することができるので、この例のように、 HTMLで記 述された表 90と、 SVGで記述された円グラフ 93とを、一つの画面上に表示すること ができる。 [0043] 図 8は、文書処理装置 20による XML文書の編集画面の一例を示す。図 8の例で は、一つの画面が複数に分割されており、それぞれの領域において、処理対象とな る XML文書を異なる複数の表示形式により表示している。領域 94には、文書のソー スが表示されており、領域 95には、文書のツリー構造が表示されており、領域 96に は、図 5に示した HTMLにより記述された表が表示されている。これらのいずれの画 面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行 うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインカ、ソー スツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通 知するミューテーシヨンイベントのリスナーとして、それぞれの編集画面の表示を担当 するプラグインの表示部を登録しておき、いずれかのプラグイン又は VCユニット 80に よりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行さ れたミューテーシヨンイベントを受け取って画面を更新する。このとき、プラグインが V C機能により表示を行っている場合は、 VCユニット 80がソースツリーの変更に追従し てデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照 してプラグインの表示部が画面を更新する。
[0044] 例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は 、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用 いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において 編集が行われると、ソース表示用プラグインとツリー表示用プラグインは、変更された ソースツリーを参照して画面を更新し、領域 96の画面を担当して!/、る HTMLユニット 50は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して 画面を更新する。
[0045] ソース表示及びツリー表示は、 VC機能を利用して実現することもできる。すなわち 、ソース、ツリー構造を HTMLによりレイアウトし、その HTMLに XML文書をマツピン グして、 HTMLユニット 50により表示してもよい。この場合、ソース形式、ツリー形式、 表形式の 3つのデスティネーションツリーが生成されることになる。いずれかの画面に おいて編集が行われると、 VCユニット 80は、ソースツリーを変更した後、ソース形式、 ツリー形式、表形式の 3つのデスティネーションツリーをそれぞれ変更し、 HTMLュ ニット 50は、それらのデスティネーションツリーを参照して、 3つの画面を更新する。
[0046] このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザ の利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示 により文書の階層構造を把握しつつ、表 90などを用いて視覚的に分力りやすい形式 で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数 の表示形式による画面を同時に表示した力 一つの画面に一つの表示形式による画 面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主 制御ユニット 22が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに 指示して表示を切り替える。
[0047] 図 9は、文書処理装置 20により編集される XML文書の他の例を示す。図 9に示し た XML文書では、 SVG文書の「foreignObject」タグの中に XHTML文書が埋め込 まれており、さら〖こ、 XHTML文書の中に MathMLで記述された数式が入っている 。このような場合、編集ユニット 24が、名前空間を参照して、適切な表示系に描画作 業を振り分ける。図 9の例では、編集ユニット 24は、まず、 SVGユニット 60に四角形 を描画させ、つづいて、 HTMLユニット 50に XHTML文書を描画させる。さらに、図 示しない MathMLユニットに、数式を描画させる。こうして、複数のボキヤブラリを包 含する複合文書が適切に表示される。表示結果を図 10に示す。
[0048] 文書編集中、カーソル (キャリッジ）の位置に応じて、表示されるメニューを切り替え てもよい。すなわち、カーソルが、 SVG文書が表示された領域内に存在するときは、 SVGユニット 60が提供するメニュー、又は SVG文書をマッピングするための定義フ アイルに定義されたコマンドを表示し、カーソルが、 XHTML文書が表示された領域 内に存在するときは、 HTMLユニット 50が提供するメニュー、又は XHTML文書を マッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編 集位置に応じて適切なユーザインターフェースを提供することができる。
[0049] 複合文書にお!、て、あるボキヤブラリに対応する適切なプラグイン又はマッピング定 義ファイルがな力つた場合は、そのボキヤブラリにより記述された部分は、ソース表示 又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を 開くとき、埋め込まれた文書を表示するアプリケーション力 Sインストールされて 、な 、と 、その内容を表示することができな力つた力 本前提技術では、表示用のアプリケー シヨンが存在しなくても、テキストデータにより構成された XML文書をソース表示又は ツリー表示することにより内容を把握することができる。これは、テキストベースである XMLなどの文書ならではの特徴と 、える。
[0050] データがテキストベースで記述されることの他の利点として、例えば、複合文書中の 、あるボキヤブラリにより記述される部分において、同一文書内の他のボキヤブラリで 記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、 S VGなどの図に埋め込まれた文字列も検索対象とすることができる。
[0051] あるボキヤブラリにより記述された文書内に、他のボキヤブラリのタグを用いてもよい 。この XML文書は、妥当（valid)ではないが、整形式 (welH rmed)であれば、有効な XML文書として処理可能である。この場合、挿入された他のボキヤブラリのタグは、 定義ファイルによりマッピングされてもよい。例えば、 XHTML文書中に、「重要」、「 最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよ 、し、 重要度の順にソートして表示してもよ 、。
[0052] 図 10に示した編集画面において、ユーザにより文書が編集されると、編集された部 分を担当するプラグイン又は VCユニット 80がソースツリーを変更する。ソースツリー には、ノードごとにミューテーシヨンイベントのリスナーを登録できるようになっており、 通常は、各ノードが属するボキヤブラリに対応したプラグインの表示部又は VCュ-ッ ト 80がリスナーとして登録される。 DOM提供部 32は、ソースツリーが変更されると、 変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリス ナ一へミューテーシヨンイベントを発行する。例えば、図 9に示した文書において、く html >ノードの下位のノードが変更された場合、く html >ノードにリスナーとして登 録された HTMLユニット 50にミューテーシヨンイベントが通知されるとともに、その上 位のく svg>ノードにリスナーとして登録された SVGユニット 60にもミューテーシヨン イベントが通知される。このとき、 HTMLユニット 50は、変更されたソースツリーを参 照して表示を更新する。 SVGユニット 60は、自身のボキヤブラリに属するノードが変 更されて!/、な!/、ので、ミューテーシヨンイベントを無視してもよ！/、。
[0053] 編集の内容によっては、 HTMLユニット 50による表示の更新に伴って、全体のレイ アウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば 最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイ アウトが更新される。例えば、 HTMLユニット 50による表示領域が以前より大きくなつ た場合、 HTMLユニット 50は、まず自身の担当する部分を描画して、表示領域の大 きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の 大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、 通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部 分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
[0054] つづいて、前提技術の文書処理装置 20を実現する機能構成について更に詳細に 説明する。以下の説明では、クラス名などを記載する際には、英字をそのまま用いて 記載することにする。
[0055] A.概要
インターネットの出現により、ユーザによって処理され管理される文書の数力 ほぼ 指数関数的に増加してきた。インターネットの核を形成するウェブ (World Wide Web) は、そのような文書データの大きな受け皿となっている。ウェブは、文書にカ卩えて、こ のような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ 言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つに H TML (HyperText Markup Language)がある。このような文書は、ウェブの他の位置に 格納されている他の文書へのリンクをさらに含む。 XML (eXtens¾le Markup Languag e)は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、 閲覧するためのシンプルなブラウザ力 Java (登録商標）のようなオブジェクト指向の プログラミング言語で開発されて 、る。
[0056] マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーション の中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結 果のツリーに相当する。 DOM (Document Object Model)は、文書を表現し、操作す るために使用される、よく知られたツリーベースのデータ構造モデルである。 DOMは 、 HTMLや XML文書などを含む文書を表現するための標準的なオブジェクトのセッ トを提供する。 DOMは、文書内のコンポーネントを表現するオブジェクトがどのように つながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作した りするための標準インタフェイスという、 2つの基本的なコンポーネントを含む。
[0057] アプリケーション開発者は、独自のデータ構造や API (Application Program Interfac e)へのインタフェイスとして DOMをサポートすることができる。他方、文書を作成する アプリケーション開発者は、彼らの APIの独自インタフェイスではなぐ DOMの標準 インタフェイスを使用することができる。したがって、標準を提供するというその能力に より、 DOMは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるた めに有効である。 DOMのいくつかのバージョンが定義されており、異なるプログラミ ング環境及びアプリケーションによって使用されている。
[0058] DOMツリーは、対応する DOMの内容に基づいた文書の階層的表現である。 DO Mツリーは「根 (ルート）」、及びルートから発生する 1つ以上の「節（ノード）」を含む。 ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテ 一ブル中の行及び列のような要素を表すことができる。 DOMツリーの「葉」は、通常、 それ以上分解できな!、テキストや画像のようなデータを表す。 DOMツリーの各ノード は、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを 記述する属性に関連付けられてもよい。
[0059] HTMLは、文書を作成するために一般に用いられる言語である力 フォーマット及 びレイアウト用の言語であり、データ記述のための言語ではない。 HTMLドキュメント を表現する DOMツリーのノードは、 HTMLのフォーマッティングタグとして予め定義 されたエレメントであって、通常、 HTMLは、データの詳述や、データのタギング Zラ ベリングのための機能を提供しな!、ので、 HTMLドキュメント中のデータに対するク エリを定式ィ匕することは多くの場合困難である。
[0060] ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーシ ヨンによってクエリされたり処理されたりできるようにすることである。表示方法とは無関 係で、階層的に構造ィ匕された言語であれば、そのようにクエリされ処理されることがで きる。 XML (extensible Markup Language)のようなマークアップ言語は、これらの特 徴を提供することができる。
[0061] HTMLとは逆に、 XMLのよく知られた利点は、文書の設計者が自由に定義可能 な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このよ うなデータ要素は、階層的に構造ィ匕することができる。さらに、 XML文書は、文書内 で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むこと ができる。構造ィ匕された XML文書の表示方法を定義するために、 CSS (Cascading S tyle Sheet)又は XSL (XML Style Language)が使用される。 DOM、 HTML, XML、 CSS、 XSL及び関連する言語の特徴に関する付加的な情報は、ウェブからも得るこ とができる。 （例えば、 http://www.w3.org/TR/)
[0062] Xpathは、 XML文書の部分の位置を指定するために共通のシンタックス及びセマ ンテイクスを提供する。機能性の例として、 XML文書に対応する DOMツリーのトラバ ース (移動）がある。それは、 XML文書の様々な表現に関連した文字列、数、及びブ ーリアン文字の操作のための基本的な機能を提供する。 Xpathは、 XML文書の見 た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であ るとかと!/、つた文法ではなぐ DOMツリーなどの抽象的 ·論理的な構造にぉ 、て動 作する。 Xpathを使用することにより、例えば XML文書の DOMツリー内の階層的構 造を通じて場所を指定することができる。アドレシングのための使用の他に、 Xpath は、 DOMツリー中のノードがパターンにマッチするか否かをテストするために使用さ れるようにも設計されている。 XPathに関する更なる詳細は、 http：〃 www. w3.org/TR /xpathで得ることができる。
[0063] XMLの既知の利点及び特徴により、マークアップ言語 (例えば XML)で記述され た文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタ フェイスを提供することができる、効果的な文書処理システムが求められる。
[0064] ここで説明されるシステムの構成のうちのいくつかは、 MVC (Modd-View-Controll er)と呼ばれる、よく知られた GUI (Graphical User Interface)パラダイムを用いて説明 される。 MVCパラダイムは、アプリケーション又はアプリケーションのインタフェイスの 一部を、 3つの部分、すなわち、モデル、ビュー、コントローラに分割する。 MVCは、 元は、 GUIの世界に、従来の入力、処理、出力の役割を割り当てるために開発され た。
[入力]→ [処理]→ [出力] [コントローラ]→ [モデル]→ [ビュー]
[0065] MVCパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、 及びユーザの入力は、モデル（M)、ビュー（V)、及びコントローラ（C)オブジェクトに より分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のよう な入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル 及び Z又はビューに送られるコマンドにマップするように作用する。モデルは、 1以上 のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変 更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作 用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する
[0066] B.文書処理システムの全体構成
文書処理システムの実施例は、図 11— 29に関連して明らかにされる。
[0067] 図 11 (a)は、後述するタイプの文書処理システムの基礎として機能する要素の従来 の構成例を示す。構成 10は、通信経路 13によりメモリ 12に接続された CPU又はマ イク口プロセッサ 11などの形式のプロセッサを含む。メモリ 12は、現在又は将来に利 用可能な任意の ROM及び Z又は RAMの形式であってもよい。通信経路 13は、典 型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ 入力装置 14及び表示装置 15 (又は他のユーザインタフェイス）に対する入出力イン タフェイス 16も、プロセッサ 11とメモリ 12の通信のためのバスに接続される。この構成 は、スタンドアロンであってもよいし、複数の端末及び 1以上のサーバが接続されてネ ットワーク化された形式であってもよ 、し、既知の 、かなる方式により構成されてもよ い。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャ 一、あるいは様々なコンポーネントの通信方法により制限されない。
[0068] さらに、本システム及びここで議論される実施例は、様々な機能性を提供する 、く つかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらの コンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハ 一ドウエアとソフトウェアの組合せだけでなぐハードウェアのみ、ソフトウェアのみによ つても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用 の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがつ て、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポ 一ネントの機能性を提供するための特定のソフトウェアを実行する汎用 Z専用の計 算装置を含む。
[0069] 図 11 (b)は、文書処理システムの一例の全体のブロック図を示す。このような文書 処理システムにおいて文書が生成され編集される。これらの文書は、例えば XMLな ど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜 上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しか しながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべ きではない。
[0070] 文書処理システムは、 2つの基本的な構成を有するものととらえることができる。第 1 の構成は、文書処理システムが動作する環境である「実行環境」 101である。例えば 、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、 基本的なユーティリティ及び機能を提供する。第 2の構成は、実行環境において走る アプリケーション力も構成される「アプリケーション」 102である。これらのアプリケーシ ヨンは、文書自身及び文書の様々な表現を含む。
[0071] 1.実行環境
実行環境 101のキーとなるコンポーネントは Programlnvoker (プログラムインボー力： プログラム起動部） 103である。 Programlnvokerl03は、文書処理システムを起動す るためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理シス テムにログオンして開始するとき、 Programlnvokerl03が実行される。 Programlnvoker 103は、例えば、文書処理システムにプラグインとしてカ卩えられた機能を読み出して 実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティ を読み出すことができる。 Programlnvokerl03の機能はこれらに限定されない。ユー ザが実行環境内で実行されるように意図されたアプリケーションを起動した 、とき、 Pr ogramlnvokerl03は、そのアプリケーションを見つけ、それを起動して、アプリケーシ ヨンを実行する。
[0072] Programlnvoker 103には、プラグインサブシステム 104、コマンドサブシステム 105 、及び Resource (リソース）モジュール 109などのいくつかのコンポーネントがアタッチ されている。これらの構成については、以下に詳述する。
[0073] a)プラグインサブシステム
プラグインサブシステム 104は、文書処理システムに機能を追加するための高度に 柔軟で効率的な構成として使用される。プラグインサブシステム 104は、また、文書処 理システムに存在する機能を修正又は削除するために使用することができる。さらに 、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができ る。例えば、画面上への文書の描画を支援するように作用する Editlet (エディットレツ ト:編集部)機能を追加することもできる。 Editletプラグインは、システムに追加される ボキヤブラリの編集も支援する。
[0074] プラグインサブシステム 104は、 ServiceBroker (サービスブローカ：サービス仲介部） 1041を含む。 ServiceBrokerl041は、文書処理システムに加えられるプラグインを管 理することにより、文書処理システムに加えられるサービスを仲介する。
[0075] 所望の機能性を実現する個々の機能は、 Service (サービス） 1042の形でシステム に追加される。利用可能な Servicel042のタイプは、 Application (アプリケーション）サ 一ビス、 ZoneFactory (ゾーンファクトリ：ゾーン生成部） Service, Editlet (エディットレツ ト：編集部） Service、 CommandFactory (コマンドファクトリ：コマンド生成部） Serviceゝ C onnectXPath (コネクト XPath:XPath管理部） Service、 CSSComputation (CSSコンビ ユーテーシヨン： CSS計算部） Serviceなどを含む力 これらに限定されない。これらの Service,及びシステムの他の構成とそれらとの関係は、文書処理システムについての よりよい理解のために、以下に詳述される。
[0076] プラグインと Serviceの関係は以下の通りである。プラグインは、 1以上の ServiceProvi der (サービスプロバイダ：サービス提供部）を含むことができるユニットである。それぞ れの ServiceProviderは、それに関連した Serviceの 1以上のクラスを有する。例えば、 適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、 1 以上の Serviceをシステムに追加することができ、これにより、対応する機能をシステム に追加することができる。
[0077] b)コマンドサブシステム コマンドサブシステム 105は、文書の処理に関連したコマンドの形式の命令を実行 するために使用される。ユーザは、一連の命令を実行することにより、文書に対する 操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行すること により、文書処理システム中の XML文書に対応する XMLの DOMツリーを編集し、 XML文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の 有効なユーザインタフェイスアクションを使用して入力されてもよい。 1つのコマンドに より 1以上の命令が実行されることもある。この場合、これらの命令が 1つのコマンドに ラップ (包含）され、連続して実行される。例えば、ユーザが、誤った単語を正しい単 語に置換したいとする。この場合、第 1の命令は、文書中の誤った単語を発見するこ とであり、第 2の命令は、誤った単語を削除することであり、第 3の命令は、正しい単語 を挿入することであってもよい。これらの 3つの命令が 1つのコマンドにラップされても よい。
[0078] コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもょ 、。こ れらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割 り当てられてもよい。
[0079] コマンドサブシステム 105のキーとなるコンポーネントは、選択的にコマンドを与え、 実行するように作用する Commandlnvoker (コマンドインボー力：コマンド起動部） 105 1である。図 11 (b)には、 1つの Commandlnvokerのみが示されているが、 1以上の Co mmandlnvokerが使用されてもよぐ 1以上のコマンドが同時に実行されてもよい。 Com mandlnvokerl051は、コマンドを実行するために必要な機能及びクラスを保持する。 動作において、実行されるべき Command (コマンド：命令） 1052は、 Queue (キュー） 1 053に積まれる。 Commandlnvokerは、連続的に実行するコマンドスレッドを生成する 。 Commandlnvoker内で既に実行中の Commandがなければ、 Commandlnvoker 1051 により実行されるように意図された Commandl052が実行される。 Commandlnvokerが 既にコマンドを実行している場合、新しい Commandは、 Queuel053の最後に積まれ る。しかしながら、それぞれの Commandlnvokerl051では、一度に 1つの Commandの みが実行される。指定された Commandの実行に失敗した場合、 CommandlnvokerlO 51は例外処理を実行する。 [0080] Commandlnvoker 1051により実行される Commandの型は、 UndoableCommand (取 消可能コマンド） 1054、 AsynchronousCommand (非同期コマンド） 1055、及び VCCo mmand (VCコマンド） 1056を含む力 これらに限定されない。 UndoableCommand 10 54は、ユーザが望めば、その Commandの結果を取り消すことが可能な Commandであ る。 UndoableCommandの例として、切り取り、コピー、テキストの挿入、などがある。動 作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用する とき、 UndoableCommandを用いることにより、切り取られた部分は、必要であれば、「 切り取られて ヽな 、」ようにすることができる。
[0081] VCCommandl056は、ボキヤブラリコネクション記述子（Vocabulary Connection De scriptor: VCD)スクリプトファイルに格納される。これらは、プログラマにより定義されう るユーザ指定の Commandである。 Commandは、例えば、 XMLフラグメントを追加した り、 XMLフラグメントを削除したり、属性を設定したりするための、より抽象的な Comm andの組合せであってもよい。これらの Commandは、特に、文書の編集に焦点を合わ せている。
[0082] AsynchronousCommand 1055 ¾ ,文書のロードや保存など、システムよりの Comman dであり、 UndoableCommandや VCCommandとは別に、非同期的に実行される。 Async hronousCommandは、 UndoableCommandではないので、取り消すことはできない。
[0083] c)リソース
Resourcel09は、様々なクラスに、いくつかの機能を提供するオブジェクトである。 例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用 される Resourceの例である。
[0084] 2.アプリケーションコンポーネント
文書処理システムの第 2の主要な特徴であるアプリケーションコンポーネント 102は 、実行環境 101において実行される。アプリケーションコンポーネント 102は、実際の 文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、ァ プリケーシヨンコンポーネント 102は、文書を管理するために使用されるシステムの構 成を含む。アプリケーションコンポーネント 102は、さらに、 UserApplication (ユーザァ プリケーシヨン） 106、アプリケーションコア 108、ユーザインタフェイス 107、及び Core Component (コアコンポーネント） 110を含む。
[0085] a)ユーザアプリケーション
UserApplicationl06は、 Programlnvokerl03と共にシステム上にロードされる。 User Applicationl06は、文書と、文書の様々な表現と、文書と対話するために必要なユー ザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部であ る文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表 現が生成される。ユーザインタフェイス機能は、 UserApplicationl06の一部として追 カロされる。言いかえれば、 UserApplicationl06は、ユーザがプロジェクトの一部を形 成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に 保持する。ー且 UserApplicationl06が生成されると、ユーザがプロジェクトの一部を 形成する文書との対話を望むたびに、ユーザは簡単に実行環境上に UserApplicatio nl06をロードすることができる。
[0086] b)コアコンポーネント
CoreComponentl 10は、複数の Pane (ペイン）の間で文書を共有する方法を提供す る。後で詳述するように、 Paneは、 DOMツリーを表示し、画面の物理的なレイアウトを 扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数の Pane 力もなる。ユーザから画面上に見える文書は、 1又はそれ以上の Paneに出現しうる。 また、 2つの異なる文書が画面上で 2つの異なる Paneに現れてもよ!、。
[0087] 図 11 (c)に示されるように、画面の物理的なレイアウトもツリーの形式になっている。
Paneは、 RootPane (ルートペイン） 1084にもなり得るし、 SubPane (サブペイン） 1085 にもなり得る。 RootPanel084は、 Paneのツリーの根に当たる Paneであり、 SubPane 10 85は、 RootPanel084以外の任意の Paneである。
[0088] CoreComponentl 10は、さらに、フォントを提供し、ツールキットなど、文書のための 複数の機能的な操作のソースの役割を果たす。 CoreComponentl 10により実行され るタスクの一例に、複数の Pane間におけるマウスカーソルの移動がある。実行される タスクの他の例として、ある Pane中の文書の一部をマークし、それを異なる文書を含 む別の Pane上にコピーする。
[0089] c)アプリケーションコア 上述したように、アプリケーションコンポーネント 102は、システムにより処理され管 理される文書から構成される。これは、システム内における文書の様々な論理的及び 物理的な表現を含む。アプリケーションコア 108は、アプリケーションコンポーネント 1 02の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに 保持することである。アプリケーションコア 108は、 DocumentManager (ドキュメントマネ 一ジャ：文書管理部） 1081及び Document (ドキュメント：文書） 1082自身を含む。
[0090] DocumentManagerl081の様々な態様を以下に詳述する。 DocumentManager 108 1は、 Documentl082を管理する。 DocumentManagerl081は、 RootPanel084、 Sub Pane 1085, ClipBoard (クリップボード）ユーティリティ 1087、及び Snapshot (スナップ ショット）ユーティリティ 1088にも接続される。 ClipBoardユーティリティ 1087は、ユー ザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。 例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを 保存することを望んだとする。このような場合、切り取られた部分力 SClipBoardに追加さ れる。
[0091] つづいて、 Snapshotユーティリティ 1088についても説明する。 Snapshotユーティリ ティ 1088は、アプリケーションがある状態力も別の状態まで移行するときに、アプリケ ーシヨンの現在の状態を記憶することを可能とする。
[0092] d)ユーザインタフェイス
アプリケーションコンポーネント 102の別の構成は、ユーザがシステムと物理的に対 話する手段を提供するユーザインタフェイス 107である。例えば、ユーザインタフェイ スは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするた めに使用される。ユーザインタフェイスは、 Frame (フレーム） 1071、 MenuBar (メ -ュ 一バー） 1072、 StatusBar (ステータスバー） 1073、及び URLBar(URLバー） 1074 を含む。
[0093] Framel071は、一般に知られているように、物理的な画面のアクティブな領域であ るとみなされる。 MenuBarl072は、ユーザに選択を提供するメニューを含む画面領 域である。 StatusBarl073は、アプリケーションの実行状態を表示する画面領域であ る。 URLBarl074は、インターネットをナビゲートするために URLアドレスを入力する 領域を提供する。
[0094] C.文書管理及び関連するデータ構造
図 12は、 DocumentManagerl081の詳細を示す。これは、文書処理システム内で 文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするた めに、このサブセクションで説明される構成は、 MVCパラダイムを用いて説明される
[0095] DocumentManagerl081は、文書処理システム内にある全ての文書を保持しホスト する DocumentContainer (ドキュメントコンテナ：文書コンテナ） 203を含む。 Document Managerl081にアタッチされたツールキット 201は、 DocumentManagerl081により 使用される様々なツールを提供する。例えば、 DomService (DOMサービス）は、文書 に対応する DOMを生成し、保持し、管理するために必要とされる全ての機能を提供 するために、ツールキット 201により提供されるツールである。ツールキット 201により 提供される別のツールである IOManager (入出力管理部）は、システムへの入力及び システムからの出力を管理する。同様に、 StreamHandler (ストリームハンドラ）は、ビッ トストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に 特に示さず、参照番号を割り当てないが、ツールキット 201のコンポーネントを形成す る。
[0096] MVCパラダイムの表現によれば、モデル（M)は、文書の DOMツリーモデル 202 を含む。前述したように、全ての文書は、文書処理システムにおいて DOMツリーとし て表現される。文書は、また、 DocumentContainer203の一部を形成する。
[0097] 1. DOMモデノレ及びゾーン
文書を表現する DOMツリーは、 Node (ノード） 2021を有するツリーである。 DOMッ リーの部分集合である Zone (ゾーン） 209は、 DOMツリー内の 1以上の Nodeの関連 領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された 文書の一部は Zone209を用いて表示される。 Zoneは、 ZoneFactory (ゾーンファクトリ： ゾーン生成部） 205と呼ばれるプラグインを用いて、生成され、取り扱われ、処理され る。 Zoneは DOMの一部を表現する力 1以上の「名前空間」を使用してもよい。よく 知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言 すれば、名前空間内に同じ名前は存在しない。
[0098] 2. Facet及び Facetと Zoneとの関係
Facet (ファセット） 2022は、 MVCパラダイムのモデル（M)部分内の別の構成であ る。 Facetは、 Zoneにおいて Nodeを編集するために使用される。 Facet2022は、 Zone 自身の内容に影響を与えずに実行することができる手続 (プロシージャ）を使用して、 DOMへのアクセスを編成する。次に説明するように、これらの手続は、 Nodeに関連 した重要で有用な操作を実行する。
[0099] 各 Nodeは、対応する Facetを有する。 DOMの中の Nodeを直接操作する代わりに、 操作を実行するために Facetを使用することによって、 DOMの保全性は保護される。 操作が Node上で直接実行される場合、いくつかのプラグインが DOMを同時に変更 することができ、その結果矛盾を引き起こす。
[0100] W3Cが策定した DOMの標準規格は、 Nodeを操作するための標準的なインタフエ イスを定義する力 実際には、ボキヤブラリごと又は Nodeごとに特有の操作があるの で、これらの操作を APIとして用意しておくのが好都合である。文書処理システムで は、このような各 Nodeに特有の APIを Facetとして用意し、各 Nodeにアタッチする。こ れにより、 DOMの標準規格に準拠しつつ、有用な APIを付加することができる。また 、ボキヤブラリごとに特有の DOMを実装するのではなぐ標準的な DOMの実装に、 後から特有の APIを付加するようにすることで、多様なボキヤブラリを統一的に処理 することができるともに、複数のボキヤブラリが任意の組合せで混在した文書を適切 に処理することができる。
[0101] ボキヤブラリは、名前空間に属するタグ (例えば XMLのタグ）のセットである。上述し たように、名前空間は、ユニークな名前 (ここではタグ)のセットを有する。ボキヤブラリ は、 XML文書を表現する DOMツリーのサブツリーとして現れる。このサブツリーは Z oneを含む。特定の例においては、タグセットの境界は Zoneによって定義される。 Zon e209は、 ZoneFactory205と呼ばれる Serviceを利用して生成される。上述したように 、 Zone209は、文書を表現する DOMツリーの一部の内部表現である。このような文 書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的 表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通 知する。 Canvas (キャンバス） 210は、 Zoneに対応する論理的なレイアウトを提供する ように作用する Serviceである。
[0102] 他方、 Pane211は、 Canvas210により提供される論理的なレイアウトに対応する物 理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文 書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画する プロセスにより、画面上に描写されなければならない。文書は、 Pane211により提供さ れる物理的なレイアウトに基づいて、 Canvas210により画面上に描写される。
[0103] Zone209に対応する Canvas210は、 Editlet206を使用して生成される。文書の DO Mは、 Editlet206及び Canvas210を使用して編集される。元の文書の完全性を維持 するために、 Editlet206及び Canvas210は、 Zone209における 1以上の Nodeに対応 する Facetを使用する。これらの Serviceは、 Zone及び DOM内の Nodeを直接操作しな い。 Facetは、 Command207を利用して操作される。
[0104] ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりするこ とによって、画面と対話する。画面上の論理的なレイアウトを提供する Canvas210は、 このカーソル操作を受け付ける。 Canvas210は、対応するアクションを Facetに実行さ せることができる。この関係により、カーソルサブシステム 204は、 DocumentManagerl 081に対して、 MVCパラダイムのコントローラ（C)として機能する。 Canvas210は、ィ ベントを扱うタスクも有する。例えば、 Canvas210は、マウスクリック、フォーカス移動、 及びユーザにより起こされた同様のアクションなどのイベントを扱う。
[0105] 3. Zone, Facet, Canvas及び Paneの間の関係の概要
文書処理システム内の文書は、少なくとも 4つの観点から見ることができる。すなわ ち、 1)文書処理システムにおいて文書の内容及び構造を保持するために用いられる データ構造、 2)文書の保全性に影響を与えずに文書の内容を編集する手段、 3)文 書の画面上の論理的なレイアウト、 4)文書の画面上の物理的なレイアウト、である。 Z one, Facet, Canvas及び Paneは、前述の 4つの観点に相当する、文書処理システム のコンポーネントをそれぞれ表す。
[0106] 4.アンドゥサブシステム
上述したように、文書に対するいかなる変更 (例えば編集)も取消可能であることが 望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したと する。図 12に関連して、アンドゥサブシステム 212は、文書管理部の取消可能なコン ポーネントを実現する。 UndoManager (アンドゥマネージャ：アンドゥ管理部） 2121は、 ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
[0107] 例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする 。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシ ステム 212は、このような操作を支援する。 UndoManager2121は、このような Undoabl eEdit (アンドゥアプルエディット：取消可能な編集） 2122の操作を保持する。
[0108] 5.カーソノレサブシステム
前述したように、 MVCのコントローラ部分は、カーソルサブシステム 204を備えても よい。カーソルサブシステム 204は、ユーザ力も入力を受け付ける。これらの入力は、 一般にコマンド及び Z又は編集操作の性格を有している。したがって、カーソルサブ システム 204は、 DocumentManagerl081に関連した MVCパラダイムのコントローラ（ C)部分であると考えることができる。
[0109] 6.ビュー
前述したように、 Canvas210は、画面上に提示されるべき文書の論理的なレイアウト を表す。 XHTML文書の例では、 Canvas210は、文書が画面上でいかに見えるかを 論理的に表現したボックスツリー 208を含んでもよい。このボックスツリー 208は、 Doc umentManager 1081に関連した MVCパラダイムのビュー（V)部分に含まれよう。
[0110] D.ボキヤブラリコネクション
文書処理システムの重要な特徴は、 XML文書を、他の表現にマップして取り扱うこ とが可能で、かつ、マップした先の表現を編集すると、その編集が元の XML文書に 整合性を保ちつつ反映される環境を提供することにある。
[0111] マークアップ言語により記述された文書、例えば XML文書は、文書型定義により定 義されたボキヤブラリに基づいて作成されている。ボキヤブラリは、タグのセットである 。ボキヤブラリは、任意に定義されてもよいため、無限に多くのボキヤブラリが存在しう る。し力しながら、多数の可能なボキヤブラリのそれぞれに対して専用の処理 Z管理 環境を提供するのは現実的ではない。ボキヤブラリコネクションは、この問題を解決す る方法を提供する。
[0112] 例えば、文書は 2以上のマークアップ言語により記述されてもよい。文書は、例えば 、 XHTML (.extensible HyperText Markup Language)、 ¾ V"G (Scalable Vector Grap hies)、 MathML (Mathematical Markup Language)、その他のマークアップ言語によ り記述されてもよい。換言すれば、マークアップ言語は、 XMLにおけるボキヤブラリゃ タグセットと同様に見なされてもよい。
[0113] ボキヤブラリは、ボキヤブラリプラグインを用いて処理される。文書処理システムにお いてプラグインが利用不可能であるボキヤブラリにより記述された文書は、プラグイン が利用可能である別のボキヤブラリの文書にマッピングすることにより表示される。こ の特徴により、プラグインが用意されていないボキヤブラリの文書も適切に表示するこ とがでさる。
[0114] ボキヤブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づい て 2つの異なるボキヤブラリの間でマッピングする能力を含む。あるボキヤブラリで記 述された文書は、別のボキヤブラリにマッピングすることができる。このように、ボキヤ ブラリコネクションは、文書がマッピングされるボキヤブラリに対応した表示 Z編集ブラ グィンにより文書を表示し編集することを可能にする。
[0115] 上述したように、各文書は、一般に複数のノードを有する DOMツリーとして文書処 理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そ のノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能 か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよ い。
[0116] マッピングという特徴を利用して、定義ファイルを適用したデスティネーション DOM ツリーが生成される。このように、ソース DOMツリーとデスティネーション DOMツリー の関係が構築され保持される。ボキヤブラリコネクションは、ソース DOMツリーとデス ティネーシヨン DOMツリーの対応を監視する。ユーザ力も編集指示を受けると、ボキ ャブラリコネクションは、ソース DOMツリーの関連したノードを変更する。ソース DOM ツリーが変更されたことを示す「ミューテーシヨンイベント」が発行され、デスティネーシ ヨン DOMツリーがそれに応じて変更される。 [0117] ボキヤブラリコネクションの使用により、少数のユーザのみに知られていた比較的マ イナ一なボキヤブラリを、別のメジャーなボキヤブラリに変換することができる。したが つて、少数のユーザによって利用されるマイナーなボキヤブラリであっても、文書を適 切に表示し、望ましい編集環境を提供することができる。
[0118] このように、文書処理システムの一部であるボキヤブラリコネクションサブシステムは 、文書の複数の表現を可能にする機能を提供する。
[0119] 図 13は、ボキヤブラリコネクション（VC : Vocabulary Connection)サブシステム 300 を示す。 VCサブシステム 300は、同一の文書の 2つの代替表現の整合性を維持す る方法を提供する。例えば、 2つの表現は、同一文書の、 2つの異なるボキヤブラリに よる表現であってもよい。前述したように、一方はソース DOMツリーであってもよぐ 他方はデスティネーション DOMツリーであってもよい。
[0120] 1.ボキヤブラリコネクションサブシステム
ボキヤブラリコネクションサブシステム 300の機能は、 VocabularyConnection301と 呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現 される Vocabulary305ごとに、対応するプラグインが要求される。例えば、文書の一部 が HTMLで記述され、残りが SVGで記述されている場合、 HTMLと SVGに対応す るボキヤブラリブラグィンが要求される。
[0121] VocabularyConnectionプラグイン 301は、適切な Vocabulary305の文書に対応した 、 Zone209又は Pane211のための適切な VCCanvas (ボキヤブラリコネクションキャン バス） 310を生成する。 VocabularyConnection301を用いて、ソース DOMツリー内の Zone209に対する変更は、変換ルールにより、別の DOMツリー 306の対応する Zone に伝達される。変換ルールは、ボキヤブラリコネクション記述子（Vocabulary Connecti on Descriptor: VCD)の形式で記述される。このようなソース DOMとデスティネーショ ン DOMの間の変換に対応するそれぞれの VCDファイルにつ!/、て、対応する VCMa nager (ボキヤブラリコネクションマネージャ） 302が生成される。
[0122] 2. Connector
Connector304は、ソース DOMツリーのソースノードと、デスティネーション DOMッ リーのデスティネーションノードとを接続する。 Connector304は、ソース DOMツリー 中のソースノード、及びソースノードに対応するソース文書に対する修正 (変更）を見 るために作用する。そして、対応するデスティネーション DOMツリーのノードを修正 する。 Connector304は、デスティネーション DOMツリーを修正することができる唯一 のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソース DOMッリ 一に対してのみ修正を行うことができる。その後、 Connector304がデスティネーショ ン DOMツリーに、対応する修正を行う。
[0123] Connector304は、ツリー構造を形成するために、論理的にリンクされる。 Connector 304により形成されたツリーは、 ConnectorTree (コネクタツリー）と呼ばれる。 Connect or304は、 ConnectorFactory (コネクタファクトリ：コネクタ生成部） 303と呼ばれる Servi ceを用いて生成される。 ConnectorFactory303は、ソース文書から Connector304を 生成し、それらをリンクして ConnectorTreeを形成する。 VocabularyConnectionManage r302は、 ConnectorFactory303を保持する。
[0124] 前述したように、ボキヤブラリは名前空間におけるタグのセットである。図示されるよ うに、 Vocabulary305は、 VocabularyConnection301によって文書に対して生成され る。これは、文書ファイルを解析し、ソース DOMとデスティネーション DOMの間の写 像のための適切な VocabularyConnectionManager302を生成することにより行われる 。さらに、 Connectorを生成する ConnectorFactory303と、 Zone209を生成する ZoneF actory205と、 Zone内のノードに対応する Canvasを生成する Editlet206との間の適切 な関係が作られる。ユーザがシステム力も文書を処分又は削除するとき、対応する Vo cabularyConnectionManager302が肖 lj除される。
[0125] Vocabulary305は、 VCCanvas310を生成する。さらに、 Connector304及びデステ イネーシヨン DOMツリー 306が対応して生成される。
[0126] ソース DOM及び Canvasは、それぞれ、モデル（M)及びビュー（V)に対応する。し 力しながら、このような表現は、ターゲットのボキヤブラリが画面上に描写可能である 場合に限って意味がある。描写は、ボキヤブラリブラグィンにより行われる。ボキャプラ リプラグインは、主要なボキヤブラリ、例えば、 XHTML, SVG, MathMLについて 提供される。ボキヤブラリブラグィンは、ターゲットのボキヤブラリに関連して使用され る。これらは、ボキヤブラリコネクション記述子を用いてボキヤブラリ間でマッピングする 方法を提供する。
[0127] このようなマッピングは、ターゲットのボキヤブラリが、マッピング可能で、画面上に描 写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリ ング方法は、例えば XHTMLなどのように、 W3Cなどの組織により定義された標準 規格となっている。
[0128] ボキヤブラリコネクションが必要であるとき、 VCCanvasが使用される。この場合、ソー スのビューを直接生成することができないので、ソースの Canvasは生成されない。こ の場合、 VCCanvas力 ConnectorTreeを使用して生成される。この VCCanvasは、ィ ベントの変換のみを扱い、画面上の文書の描写を援助しない。
[0129] 3. DestinationZone、 Pane、及びし anvas
上述したように、ボキヤブラリコネクションサブシステムの目的は、同一の文書の 2つ の表現を同時に生成し保持することである。第 2の表現も、 DOMツリーの形式であり 、これはデスティネーション DOMツリーとして既に説明した。第 2の表現における文 書を見るために、 DestinationZone, Canvas及び Paneが必要である。
[0130] VCCanvasが作成されると、対応する DestinationPane307が生成される。さらに、関 連する DestinationCanvas308と、対応する BoxTree309が生成される。同様に、 VCC anvas310も、ソース文書に対する Pane211及び Zone209に関連づけられる。
[0131] DestinationCanvas308は、第 2の表現における文書の論理的なレイアウトを提供す る。特に、 DestinationCanvas308は、デスティネーション表現における文書を描写す るために、カーソルや選択のようなユーザインタフェイス機能を提供する。 Destination Canvas308に生じたイベントは、 Connectorに供給される。 DestinationCanvas308は 、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデス ティネーシヨン（第 2)表現のボキヤブラリに特有なイベントを、 Connector304に通知 する。
[0132] 4.ボキヤブラリコネクションコマンドサブシステム
ボキヤブラリコネクション (VC)サブシステム 300の要素として、ボキヤブラリコネクシ ヨン (VC)コマンドサブシステム 313がある。ボキヤブラリコネクションコマンドサブシス テム 313は、ボキヤブラリコネクションサブシステム 300に関連した命令の実行のため に使用される VCCommand (ボキヤブラリコネクションコマンド） 315を生成する。 VCCo mmandは、内蔵の CommandTemplate (コマンドテンプレート） 318を使用して、及び Z 又は、スクリプトサブシステム 314においてスクリプト言語を使用してスクラッチカもコ マンドを生成することにより、生成することができる。
[0133] コマンドテンプレートには、例えば、「If」コマンドテンプレート、「When」コマンドテン プレート、「挿入（Insert)」コマンドテンプレートなどがある。これらのテンプレートは、 V CCommandを作成するために使用される。
[0134] 5. XPathサブシステム
？&1^サブシステム316は、文書処理システムの重要な構成であり、ボキヤブラリコ ネクシヨンの実現を支援する。 Connector304は、一般に xpath情報を含む。上述した ように、ボキヤブラリコネクションのタスクの 1つは、ソース DOMツリーの変化をデステ イネーシヨン DOMツリーに反映させることである。 xpath情報は、変更 Z修正を監視さ れるべきソース DOMツリーのサブセットを決定するために用いられる 1以上の xpath 表現を含む。
[0135] 6.ソース DOMツリー、デスティネーション DOMツリー、及び ConnectorTreeの概要 ソース DOMツリーは、別のボキヤブラリに変換される前のボキヤブラリで文書を表 現した DOMツリー又は Zoneである。ソース DOMツリーのノードは、ソースノードと呼 ばれる。
[0136] それに対して、デスティネーション DOMツリーは、ボキヤブラリコネクションに関連し て前述したように、同一の文書を、マッピングにより変換された後の異なるボキヤブラリ で表現した DOMツリー又は Zoneである。デスティネーション DOMツリーのノードは、 デスティネーションノードと呼ばれる。
[0137] ConnectorTreeは、ソースノードとデスティネーションノードの対応を表す Connector に基づく階層的表現である。 Connectorは、ソースノードと、ソース文書になされた修 正を監視し、デスティネーション DOMツリーを修正する。 Connectorは、デスティネー シヨン DOMツリーを修正することを許された唯一のオブジェクトである。
[0138] E.文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザ力 のコマンドに応答しなければならない。ィ ベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。 多くの高級言語、例え «Java (登録商標）は、ユーザアクションを記述するイベントに 頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行する ために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を 初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに 適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ること を意味する。し力しながら、このプロセスは扱いにくい。さらに、それは、ユーザが何か をするのを待つ間、 CPUサイクルを消費してループするプログラムを必要とする。
[0139] 多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している 。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントド リブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「ィベン ト」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユー ザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収 集するのではなぐ監視すべきイベントが生じたときに、システムがプログラムに通知 する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言 われる。
[0140] これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する 「Event (イベント）」クラスを使用して扱われる。
[0141] 文書処理システムは、 自身のイベント、及びこれらのイベントを扱う方法を定義して 使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザ のマウスアクションから起こるイベントである。マウスを含むユーザアクションは、 Canva s210によって、マウスイベントに渡される。このように、 Canvasは、システムのユーザ による相互作用の最前部にあると言える。必要であれば、最前部にある Canvasは、そ のイベントに関連した内容を子へ渡す。
[0142] それに対して、キーストロークイベントは、 Canvas 210から流れる。キーストロークイ ベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に 関連する。 Canvas210上に入力されたキーストロークイベントは、その親に渡される。 キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文 字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生す る。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同 様に扱われる他のイベントを含む。
[0143] 1.ボキヤブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。 Canvas210は、イベントを受け取ると 、その状態を変更する。必要であれば、 Commandl052力 Canvas210により Comman dQueuel053にポストされる。
[0144] 2.ボキヤブラリコネクション内のイベントの取り扱い
VocabularyConnectionプラグイン 301を用いて、 DestinationCanvasの一例である X HTMLCanvasl l06は、発生したイベント、例えば、マウスイベント、キーボードィベン ト、ドラッグアンドドロップイベント、及びボキヤブラリに特有のイベントなどを受け取る。 これらのイベントは、コネクタ 304に通知される。より詳細には、図 21 (b)に図示される ように、 VocabularyConnectionプラグイン 301内のイベントフローは、 SourcePanel lO 3、 Vし Canvas丄 104、 DestinationPanel lOo、 DestinationCanvasの一 f列で fcoDestin ationCanvasl 106、デスティネーション DOMツリー及び ConnectorTreeを通過する。
[0145] F. Programlnvoker及び Programlnvokerと他の構成との関係
Programlnvokerl03及びそれと他の構成との関係は、図 14 (a)に更に詳細に示さ れる。 Programlnvokerl03は、文書処理システムを開始するために実行される実行環 境中の基本的なプログラムである。図 11 (b)及び図 11 (c)に図示されるように、 User Application 106、 ¾erviceBrokerl04l、 Commandlnvokerl051、及び Resourcel09 は、全て Programlnvokerl03に接続される。前述したように、アプリケーション 102は、 実行環境中で実行されるコンポーネントである。同様に、 ServiceBrokerl041は、シ ステムに様々な機能をカ卩えるプラグインを管理する。他方、 Commandlnvokerl051は 、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラ ス及びファンクションを保持する。
[0146] 1.プラグイン及びサービス
ServiceBrokerl041について、図 14 (b)を参照して更に詳細に説明する。前述した ように、 ServiceBrokerl041は、システムに様々な機能を追加するプラグイン (及び関 連するサービス）を管理する。 Servicel042は、文書処理システムに特徴を追加又は 変更可能な最も下の層である。「Service」は、 ServiceCategory401と ServiceProvider 402の 2つの部分からなる。図 14 (c)に図示されるように、 1つの ServiceCategory401 は、複数の関連する ServiceProvider402を持ちうる。それぞれの ServiceProviderは、 特定の ServiceCategoryの一部または全部を実行するように作用する。 ServiceCatego ry401は、他方では、 Serviceの型を定義する。
[0147] Serviceは、 1)文書処理システムに特定の特色を提供する「特色サービス」、 2)文書 処理システムにより実行されるアプリケーションである「アプリケーションサービス」、 3) 文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の 3つ の型に分類することができる。
[0148] Serviceの例は、図 14 (d)に示される。アプリケーション Serviceの Categoryにおいて は、システムユーティリティが対応する ServiceProviderの例である。同様に、 Editlet20 6は Categoryであり、 HTMLEditlet及び SVGEditletは対応する ServiceProviderである 。 ZoneFactory205は、 Serviceの別の Categoryであり、対応する ServiceProvider (図 示せず)を有する。
[0149] プラグインは、文書処理システムに機能性をカ卩えると既に説明した力 いくつかの Se rviceProvider402及びそれらに関連するクラスからなるユニットと見なされてもよい。 各プラグインは、宣言ファイルに記述された依存性及び ServiceCategory401を有す る。
[0150] 2. Programlnvokerとアプリケーションとの関係
図 14 (e)は、 Programlnvokerl03と UserApplicationl06との関係についての更なる 詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグ インは、全て ServiceBrokerl041上にロードされる。 ServiceBrokerl041は、全てのプ ラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、 又、その機能はストレージカもロードすることができる。プラグインの内容がロードされ ると、 ServiceBrokerl041は、対応するプラグインを定義する。つづいて、対応する Us erApplicationl06が生成され、実行環境 101にロードされ、 Programlnvokerl03にァ タツチされる。 [0151] G.アプリケーションサービスと環境との関係
図 15 (a)は、 Programlnvokerl03上にロードしたアプリケーションサービスの構成に ついての更なる詳細を示す。コマンドサブシステム 105のコンポーネントである Comm andlnvokerl051は、 Programlnvokerl03内の Commandl052を起動又は実行する。 Commandl052は、文書処理システムにおいて、 XMLなどの文書を処理し、対応す る XMLDOMツリーを編集するために用いられる命令である。 Commandlnvokerl05 1は、 Commandl052を実行するために必要なクラス及びファンクションを保持する。
[0152] ServiceBrokerl041も、 Programlnvokerl03内で実行される。 UserApplicationl06 は、ユーザインタフェイス 107及び CoreComponentl lOに接続される。 CoreCompone ntl lOは、全ての Paneの間で文書を共有する方法を提供する。 CoreComponentl lO は、さらにフォントを提供し、 Paneのためのツールキットの役割を果たす。
[0153] 図 15 (b)は、 Framel071、 MenuBarl072、及び StatusBarl073の関係を示す。
[0154] H.アプリケーションコア
図 16 (a)は、全ての文書、及び文書の一部及び文書に属するデータを保持するァ プリケーシヨンコア 108についての更なる説明を提供する。 CoreComponentl lOは、 文書 1082を管理する DocumentManagerl081にアタッチされる。 DocumentManager 1081は、文書処理システムに関連づけられたメモリに格納される全ての文書 1082 の所有者である。
[0155] 画面上の文書の表示を容易にするために、 DocumentManagerl081は RootPanel 084にも接続される。 ClipBoardl087、 SnapShotl088、 Drag&Drop601、及び Overla y602の機能も、 CoreComponentl 10にアタッチされる。
[0156] SnapShotl088は、アプリケーションの状態を元に戻すために使用される。ユーザが SnapShotl088を起動したとき、アプリケーションの現状が検知され、格納される。そ の後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保 存される。 SnapShotl088は、図 16 (b)に図示される。動作において、アプリケーショ ンがある URL力 他へ移動するときに、前に戻る動作及び先に進む動作をシームレ スに実行可能とするために、 SnapShotl088は以前の状態を記憶する。
[0157] I. DocumentManager内における文書の構成 図 17 (a)は、 DocumentManagerl081の更なる説明と、 DocumentManagerにおいて 文書が構成され保持される様子を示す。図 11 (b)に示したように、 DocumentManager 1081は、文書 1082を管理する。図 17 (a)に示される例において、複数の文書のう ちの 1つは RootDocument (ルート文書） 701であり、残りの文書は SubDocument (サブ 文書） 702である。 DocumentManager 1081は、 RootDocument701に接続され、 Root Document701は、全ての SubDocument702に接続される。
[0158] 図 12及び図 17 (a)に示すように、 DocumentManager 1081は、全ての文書 1082を 管理するオブジェクトである DocumentContainer203に結合される。 DOMService703 及び IOManager704を含むツールキット 201 (例えば XMLツールキット）の一部を开 成するツールも、 DocumentManager 1081に供給される。再び図 17 (a)を参照して、 DOMService703は、 DocumentManagerl081により管理される文書に基づいた DO Mツリーを生成する。各 Document705は、それが RootDocument701であっても SubD ocument702であっても、対応する DocumentContainer203によって管理される。
[0159] 図 17 (b)は、文書 A— Eが階層的に配置される様子を示す。文書 Aは RootDocume ntである。文書 B— Dは、文書 Aの SubDocumentである。文書 Eは、文書 Dの SubDocu mentである。図 17 (b)の左側は、これと同じ文書の階層が画面上に表示された例を 示す。 RootDocumentである文書 Aは、基本フレームとして表示される。文書 Aの SubD ocumentである文書 B— Dは、基本フレーム Aの中のサブフレームとして表示される。 文書 Dの SubDocumentである文書 Eは、サブフレーム Dのサブフレームとして画面に 表示される。
[0160] 再び図 17 (a)を参照して、 UndoManager (アンドゥマネージャ：アンドゥ管理部） 706 及び UndoWrapper (アンドゥラッパ一） 707は、それぞれの DocumentContainer203に 対して生成される。 UndoManager706及び UndoWrapper707は、取消可能なコマンド を実行するために使用される。この特徴を使用することにより、編集操作を使用して 文書に対して実行された変更を取り消すことができる。 SubDocumentの変更は、 Root Documentとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する 変更を考慮に入れて、例えば、図 17 (b)に示されるような連鎖状の階層における全 ての文書の間で整合性が維持されることを保証する。 [0161] UndoWrapper707は、 DocumentContainer203内の SubDocumentに関連するアンド ゥオブジェクトをラップし、それらを RootDocumentに関連するアンドゥオブジェクトに結 合させる。 UndoWrapper707は、 UndoableEditAcceptor (アンドゥァブルエデイットァク セプタ：アンドゥ可能編集受付部） 709に利用可能なアンドゥオブジェクトの収集を実 行する。
[0162] UndoManager706及び UndoWrapper707は、 UndoableEditAcceptor709及び Undo ableEditSource (アンドゥァブルエディットソース） 708〖こ接続される。当業者には理解 されるように、 Document705が UndoableEditSource708であってもよぐ取消可能な 編集オブジェクトのソースであってもよ 、。
[0163] J.アンドゥコマンド及びアンドゥフレームワーク
図 18 (a)及び図 18 (b)は、アンドゥフレームワーク及びアンドゥコマンドについて更 なる詳細を提供する。図 18 (a)に示されるように、 UndoCommand801、 RedoComman d802、及び UndoableEditCommand803は、図 11 (b)に示したように Commandlnvoke r 1051に積むことができるコマンドであり、順に実行される。 UndoableEditCommand8 03は、 UndoableEditSource708及び UndoableEditAcceptor709に更にアタッチされ る。「foo」 Editし ommand804及び「bar」 Editし ommand805i 、 UndoableEditCommand の例である。
[0164] 1. UndoableEditCommandの実行
図 18 (b)は、 UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを 使用して Document705を編集すると仮定する。第 1ステップ S 1では、 UndoableEditA cceptor709力 Document705の DOMツリーである UndoableEditSource708にァタツ チされる。第 2ステップ S2では、ユーザにより発行されたコマンドに基づいて、 Docum ent705が DOMの APIを用いて編集される。第 3ステップ S3では、ミューテーシヨンィ ベントのリスナー力 変更がなされたことを通知される。すなわち、このステップでは、 DOMツリーの全ての変更を監視するリスナーが編集操作を検知する。第 4ステップ S 4では、 UndoableEditが UndoManager706のオブジェクトとして格納される。第 5ステツ プ S5では、 UndoableEditAcceptor709が UndoableEditSource708からデタツチされる 。 UndoableEditSource708は、 Document705自身であってもよい。 [0165] K.システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネン トについて説明した。以下、これらのコンポーネントの使用に関する方法論について 説明する。図 19 (a)は、文書処理システムに文書がロードされる様子の概要を示す。 それぞれのステップは、図 24— 28において、特定の例に関連して詳述される。
[0166] 簡単には、文書処理システムは、文書に含まれるデータ力 なるバイナリデータスト リームから DOMを生成する。 ApexNode (エイペックスノード：頂点ノード）が、注目対 象であり Zoneに属する文書の一部のために生成される。つづいて、対応する Paneが 同定される。同定された Paneは、 ApexNode及び物理的な画面表面から Zone及び Ca nvasを生成する。 Zoneは、次に、それぞれのノードに Facetを生成し、それらに必要と される情報を提供する。 Canvasは、 DOMツリーから、ノードをレンダリングするための データ構造を生成する。
[0167] より詳細には、文書はストレージ 901からロードされる。文書の DOMツリー 902が生 成される。文書を保持するための、対応する DocumentContainer903が生成される。 DocumentContainer903は、 DocumentManager904にアタッチされる。 DOMツリーは 、ルートノードと、ときには複数のセカンダリノードを含む。
[0168] 一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、 D OMツリーは、例えば、 XHTMLサブツリーだけでなく SVGサブツリーを有してもよい 。 XHTMLサブツリーは、 XHTMLの ApexNode905を有する。同様に、 SVGサブッ リーは、 SVGの ApexNode906を有する。
[0169] ステップ 1では、 ApexNode906力 画面の論理的なレイアウトである Pane907にァタ ツチされる。ステップ 2では、 Pane907は、 PaneOwner (ペインオーナー：ペインの所有 者） 908である CoreComponentに、 ApexNode906のための ZoneFactoryを要求する。 ステップ 3では、 PaneOwner908は、 ZoneFactoryと、 ApexNode906のための CanvasF actoryである Editletとを返す。
[0170] ステップ 4では、 Pane907力 ¾one909を生成する。 Zone909は Pane907にアタッチ される。ステップ 5では、 Zone909がそれぞれのノードに対して Facetを生成し、対応 するノードにアタッチする。ステップ 6では、 Pane907力 Canvas910を生成する。 Canv as910は Pane907にアタッチされる。 Canvas910には様々な Commandが含まれる。ス テツプ 7では、 Canvas910が文書を画面にレンダリングするためのデータ構造を構築 する。 XHTMLの場合、これはボックスツリー構造を含む。
[0171] 1. Zoneの MVC
図 19 (b)は、 MVCパラダイムを用いて Zoneの構成の概要を示す。この場合、 Zone 及び Facetは文書に関連した入力であるから、モデル（M)は Zone及び Facetを含む。 Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に 見る出力であるから、ビュー（V)は Canvas及びデータ構造体に対応する。 Command は、文書とその様々な関係に対して制御操作を実行するので、コントロールお)は Ca nvasに含まれる Commandを含む。
[0172] L.文書の表現
図 20を用いて、文書及びその様々な表現の例について以下に説明する。この例で 使用される文書は、テキストと画像の双方を含む。テキストは、 XHTMLを用いて表さ れ、画像は、 SVGを用いて表される。図 20は、文書のコンポーネント及び対応するォ ブジエタトの関係の MVC表現を詳細に示す。この例において、 DocumentlOOlは、 Document 1001を保持する DocumentContainer 1002にアタッチされる。文書は DO Mツリー 1003により表現される。 DOMツリーは、 ApexNodel004を含む。
[0173] ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集 するために用いられる Facetは、三角形で表され、対応するノードにアタッチされる。 文書がテキストと画像を有するので、この文書の DOMツリーは、 XHTML部分と SV G部分を含む。 ApexNodel004は、 XHTMLサブツリーの最上のノードである。これ は、文書の XHTML部分の物理的な表現のための最上 Paneである XHTMLPanelO 05にアタッチされる。 ApexNodel004は、文書の DOMツリーの一部である XHTMLZ onel006にもアタッチされる。
[0174] Nodel004に対応する Facetも、 XHTMLZonel006にアタッチされる。 XHTMLZone 1006は、 XHTMLPanel005にアタッチされる。 XHTMLEditletは、文書の論理的な 表現である XHTMLCanvasl007を生成する。 XHTMLCanvasl007は、 XHTMLPane 1005にアタッチされる。 XHTMLCanvasl007は、 Document 1001の XHTMLコンポ 一ネントのための BoxTreel009を生成する。文書の XHTML部分を保持し描画する ために必要な様々な Commandl008も、 XHTMLCanvasl007に追加される。
[0175] 同様に、文書の SVGサブツリーの ApexNodelOlOは、文書の SVGコンポーネント を表現する Document 1001の DOMツリーの一部である SVGZone 1011にアタッチさ れる。 ApexNodelOlOは、文書の SVG部分の物理的な表現の最上の Paneである SV GPanelO 13にアタッチされる。文書の SVG部分の論理的な表現を表す SVGCanvas 1012は、 SVGEditletにより生成され、 SVGPanel013にアタッチされる。画面上に文 書の SVG部分をレンダリングするためのデータ構造及びコマンドは、 SVGCanvasに アタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを 含んでもよい。
[0176] 図 20に関連して説明された文書例の表現の一部について、図 21 (a)に関連して、 前述した MVCパラダイムを用いて更に説明する。図 21 (a)は、文書 1001の XHTM Lコンポーネントにおける MVの関係を簡略化して示す。モデルは、 DocumentlOOl の XHTMLコンポーネントのための XHTMLZone 1101である。 XHTMLZoneのッリ一 には、いくつかの Node及びそれらに対応する Facetが含まれる。対応する XHTMLZon e及び Paneは、 MVCパラダイムのモデル（M)部分の一部である。 MVCパラダイムの ビュー（V)部分は、 DocumentlOOlの XHTMLコンポーネントの、対応する XHTML Canvasl 102及び BoxTreeである。文書の XHTML部分は、 Canvasと、それに含まれ る Commandを使用して画面に描写される。キーボードやマウス入力などのイベントは 、図示されるように、逆方向へ進む。
[0177] SourcePaneは、更なる機能、すなわち、 DOMの保有者としての役割を有する。図 2 1 (b)は、図 21 (a)に示した DocumentlOOlのコンポーネントに対するボキヤブラリコ ネクシヨンを提供する。 DOMホルダーとして機能する SourcePanel l03は、文書のソ ース DOMツリーを含む。 ConnectorTreeは、 ConnectorFactoryにより生成され、デス ティネーシヨン DOMの保有者としても機能する DestinationPanel 105を生成する。 D estinationPanel 105は、 XHTMLDestinationCanvasl 106としてボックスツリーの形式 でレイアウトされる。
[0178] M.プラグインサブシステム、ボキヤブラリコネクション、及びコネクタの関係 図 22 (a) - (c)は、それぞれ、プラグインサブシステム、ボキヤブラリコネクション、及 び Connectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理シ ステムに機能を追加又は交換するために用いられる。プラグインサブシステムは、 Ser viceBrokerl041を含む。 ServiceBrokerl041にアタッチされる ZoneFactoryServicel 201は、文書の一部に対する Zoneを生成する。 EditletService 1202も、 ServiceBroke rl041にアタッチされる。 EditletServicel202は、 Zone中の Nodeに対応する Canvasを 生成する。
[0179] ZoneFactoryの例は、 XHTMLZone及び SVGZoneをそれぞれ生成する XHTMLZone Factoryl211及び SVGZoneFactoryl 212である。文書例に関連して前述したように、 文書のテキストコンポーネントは、 XHTMLZoneを生成することにより表現されてもよ!ヽ し、画像は SVGZoneを用いて表現されてもよい。 EditletServiceの例は、 XHTMLEditle U221及び SVGEditletl222を含む。
[0180] 図 22 (b)は、ボキヤブラリコネクションに関連する更なる詳細を示す。ボキヤブラリコ ネクシヨンは、前述したように、文書処理システムの重要な特徴であり、 2つの異なる 方法で文書の整合のとれた表現及び表示を可能とする。 ConnectorFactory303を保 持する VCManager302は、ボキヤブラリコネクションサブシステムの一部である。 Conn ectorFactory303は、文書の Connector304を生成する。前述したように、 Connector は、ソース DOM中のノードを監視し、 2つの表現の間の整合性を維持するために、 デスティネーション DOM中のノードを修正する。
[0181] Template317は、いくつかのノードの変換ノレ一ノレを表す。ボキヤブラリコネクション 記述子 (VCD)ファイルは、特定のパス又はルールを満たす要素又は要素の集合を 他の要素に変換するいくつかのルールを表す Templateのリストである。 Template317 及び CommandTemplate318は、全て VCManager302にアタッチされる。 VCManager は、 VCDファイル中の全てのセクションを管理するオブジェクトである。 1つの VCDフ アイルに対して、 1つの VCManagerオブジェクトが生成される。
[0182] 図 22 (c)は、 Connectorに関連する更なる詳細を提供する。 ConnectorFactory303 は、ノ、 ' ~~ス文善力ら Connectorを生成する。 ConnectorFactory303は、 Vocabulary ^ T emplateゝ及び ElementTemplateにアタッチされ、それぞれ、 VocabularyConnectorゝ T emplateConnector、 ElementConnectorを生成ずる。
[0183] VCManager302は、 ConnectorFactory303を保持する。 Vocabularyを生成するため に、対応する VCDファイルが読み込まれる。こうして、 ConnectorFactory303が生成 れる。このし onnectorFactory30dは、 Zoneを生成する ZoneFactory及びし anvasを生 成する Editletに関連する。
[0184] つづ!/、て、ターゲットボキヤブラリの EditletServiceが、 VCCanvasを生成する。 VCCa nvasも、ソース DOMツリー又は Zoneにおける ApexNodeの Connectorを生成する。必 要に応じて、子の Connectorが再帰的に生成される。 ConnectorTreeは、 VCDフアイ ル中のテンプレートの集合により生成される。
[0185] テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集 合である。例えば、各テンプレートは、ソース DOMツリー又は Zoneにマッチされる。 適切にマッチした場合には、頂点 Connectorが生成される。例えば、テンプレートお/ */D」は、間にどんなノードがあるかに関係なぐノード Aで始まりノード Dで終わる全 ての枝に合致する。同様に、「〃B」は、ルートからの全ての「B」ノードに一致する。
[0186] N. ConnectorTreeに関係する VCDファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MyS ampleXML」というタイトルの文書が文書処理システムにロードされる。図 23は、「MySa mpleXMLjファイルのための、 VCManager及び ConnectorFactoryTreeを用いた VCD スクリプトの例を示す。スクリプトファイル中のボキヤブラリセクシヨン、テンプレートセク シヨンと、 VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabula ry」において、属'性「match_^¾「sample:root」、「label」は「MySampleXML」、「caU— temp late」は sample template となって 、る。
[0187] この例では、 Vocabularyは、「MySampleXML」の VCManagerにおいて「sample:root」 として頂点要素を含む。対応する UIラベルは、「MySampleXML」である。テンプレート セクションにお 、て、タグは「vcd:template」であり、名前は「sample:template」である。
[0188] O.ファイルがシステムにロードされる方法の詳細な例
図 24— 28は、文書「MySampleXML」のロードについての詳細な記述を示す。図 24 (a)に示されるステップ 1では、文書がストレージ 1405からロードされる。 DOMService は、 DOMツリー及び DocumentManagerl406と対応する DocumentContainerl401 を生成する。 DocumentContainerl401は、 DocumentManagerl406にアタッチされる 。文書は、 XHTML及び MySampleXMLのサブツリーを含む。 XHTMLの ApexNode 1403は、タグ「xhtml:html」が付された XHTMLの最上のノードである。「MySampleX MLJの ApexNodel404は、タグ「sample:root」が付された「MySampleXML」の最上ノ ードである。
[0189] 図 24 (b)に示されるステップ 2では、 RootPaneが文書の XHTMLZone、 Facet,及び Canvasを生成する。 Panel407、 XHTMLZonel408、 XHTMLCanvasl409、及び Bo xTreel410力 ApexNode 1403に対応して生成される。
[0190] 図 24 (c)に示されるステップ 3では、 XHTMLZoneが知らないタグ「sample:root」を発 見し、 XHTMLCanvasの領域から SubPaneを生成する。
[0191] 図 25に示されるステップ 4では、 SubPaneが「sample:root」を扱うことができ、適切な Zoneを生成 Γ會な ZoneFactory 得る。この ZoneFactoryi；、 ZoneFactory 行 n丁 能な Vocabulary内にある。それは、「MySampleXML」の VocabularySectionの内容を含 む。
[0192] 図 26に示されるステップ 5では、「MySampleXML」に対応する Vocabularyが Default Zonel601を生成する。対応する Editletが生成され、対応する Canvasを生成するた めに SubPanel501が提供される。 Editletは、 VCCanvasを生成する。そして、それは T emplate¾ection 呼ふ。 Connectorractory freet a.3；れて 、る。し onnectorFactoryTr eeは、 ConnectorTreeとな 全飞の Connectorを生成する。
[0193] 図 27に示されるステップ 6では、各 Connectorがデスティネーション DOMオブジェク トを生成する。コネクタのうちのいくつかは xpath情報を含んでいる。 xpath情報は、変 更 Z修正を監視する必要のあるソース DOMツリーの部分集合を決定するために使 用される 1以上の xpath表現を含む。
[0194] 図 28に示されるステップ 7では、ボキヤブラリは、ソース DOMのペインからデスティ ネーシヨン DOMツリーの DestinationPaneを作成する。これは、 SourcePaneに基づい てなされる。デスティネーションツリーの ApexNodeは、 DestinationPane及び対応する Zoneにァタツテされる。 DestinationPaneは、 DestinationCanvasを生成し、文書をテス ティネーシヨンのフォーマットでレンダリングするためのデータ構造及びコマンドを構 築する、自身の Editletを提供される。
[0195] 図 29 (a)は、対応するソースノードを持たず、デスティネーションツリーにのみ存在 するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードィ ベントなど、 Canvasが取得したイベントは、デスティネーションツリーを通過して、 Elem entTemplateConnectorに izs達 れる。 ElementTemplateConnectorは对 、す oソ ~~ス ノードを持たな 、ので、伝達されたイベントはソースノードに対する編集操作ではな ヽ 。 ElementTemplateConnectorは、 1ZS達 れた ヘント し ommandTemplateに己 さ れたコマンドに合致すれば、それに対応する Actionを実行する。合致するコマンドが なければ、 ElementTemplateConnectorは、伝達されたイベントを無視する。
[0196] 図 29 (b)は、 TextOfConnectorによりソースノードに対応づけられているデステイネ ーシヨンツリーのノード上でイベントが発生したときのフローを示す。 TextOfConnector は、ソース DOMツリーの XPathで指定されたノード力 テキストノードを取得して、デ スティネーシヨン DOMツリーのノードにマッピングする。マウスイベント、キーボードィ ベントなど、 Canvasが取得したイベントは、デスティネーションツリーを通過して、 Text OlConnectorに伝達される。 TextO!Connectorは、伝達されたイベントを、対応するソ ースノードの編集コマンドにマッピングし、 Queuel053に積む。編集コマンドは、 Face tを介して実行される DOMの APIコールの集合である。キューに積まれたコマンドが 実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーショ ンイベントが発行され、リスナーとして登録された TextOfConnectorにソースノードの 変更が通知される。 TextOfConnectorは、ソースノードの変更を、対応するデステイネ ーシヨンノードに反映させるように、デスティネーションツリーを再構築する。このとき、 TextO!Connectorを含むテンプレートに、「for each」 「for loop」などの制御文が含ま れている場合、 ConnectorFactoryがこの制御文を再評価し、 TextOfConnectorを再構 築した後、デスティネーションツリーが再構築される。
[0197] (実施例）
図 30は、セマンティックウェブのレイヤケーキを示す模式図である。
前提技術において示した文書処理装置 20は、複合ドキュメント、 Webサービスなど 各シーンにおける XML文書 (XMLデータ)ハンドリング技術として有効であることは上 記した通りである。
1)同図のレイヤケーキで示されるセマンティック Webの進化において、 "XMじ，から" R DF(Resource Description Framework)以上"のデータ構造をシームレスに扱うことは、 大きな課題といえる。
2)また、すべての文書が RDFで記述されるということがすぐに実現されることは難しい ことが予想される。
3)そこでこれまでの XMLベースのデータと RDF以降のデータとを連結する技術が望 まれる。
4)この時、前提技術にて示した XMLハンドリング技術は、「XML」という共通言語によ つて、既存の XMLによるデータとセマンティック Webアプリケーションをつなげるキー テクノロジ一となる可能性がある。
[0198] 図 31は、個人情報を含んだ各種文書ファイルの一般的な取り扱い形態を示す模式 図である。
こうした各部署で個別に作成している帳票などの文書ファイルやそのための入カブ ラウザを大きく変更することなく一括管理することが本実施例において目的とするとこ ろである。
そのために、社内基準としてグローバルな (モデルとなる）データを定義した後、各 部署におけるローカルなデータ定義との関係をオントロジー技術で連携し、既存の X ML構造化された社内文書と文書入力ブラウザに対して XMLハンドリング技術により 最小のコストでデータの収集と付加情報の追カ卩が可能としている。
[0199] 図 32は、本実施例における個人情報管理支援システムのフローを示す図である。
<シーン 1 >
セキュリティ管理者が、各部署の文書ファイルに含まれる個人情報を収集する。各 部署の文書ファイルで使用されているローカルな用語については、膨大なノリエーシ ヨンがある。そのため、セキュリティ管理者は、これらのローカルな用語を完全に把握 してはいない。
しかし、同図においては、文書の構造や属性についてのオントロジ一が社内基準に よって定義されている（以下、このようなオントロジーを「グローバルオントロジー」とよ ぶ)。各部署では、ローカルオントロジーとしてその部署のローカルな用語をグローバ ルオントロジ一の用語にリンクさせている。これにより、社内基準としてのグローノ レオ ントロジ一と部署ごとのローカルオントロジ一がシームレスに連係することになる。 社内データベースからローカルオントロジーに基づいて作成された文書ファイルを 検索するにあたり、社内基準のグローバルオントロジーに基づいて意味的な上位概 念での検索を行う。この意味的な上位概念は各部署において実際に使用されている 用語に変換される。そして、社内データベース力 XML構造ィ匕文書を検索してその 結果が一覧表示される。
[0200] 使用する要素技術：
1.社内全体で基準化されているグローバルオントロジ一と、そのグローバルオント ロジ一にマッピングされているローカルオントロジー。
2.グローバルオントロジ一からローカルオントロジ一に展開した上で、社内データ ベースを検索して一覧表示する機能。
[0201] <シーン 2>
検索結果として一覧された文書ファイルを、各部署に配信する。そして、配信された 文書ファイルに対して、各部署の部長は、人名や住所といった個人情報をチェックし 、たとえば、「個人情報処理該当」といったァノテーシヨンを付与する。このとき、各部 署のローカルな用語を使ってァノテーシヨンが付与される。
[0202] 営業部門と開発部門の文書ファイルをもとにして、外部提出用の新しい文書を作成 した場合においても、ァノテーシヨンが設定されたテキストを使っている場合には、「 個人情報処理該当」ァノテーシヨンがそのまま利用可能となる。
すなわち、文書ファイルのデータが、 2次的、あるいは、 3次的に利用される場合で あっても、このようなァノテーシヨン情報が保持される。
[0203] 図 33は、図 32のシーン 1について詳細に説明するための模式図である。
図 34以降に関連して説明するように、社内基準として利用するタグは、グローバル なオントロジ一として定義されている。つまり、会社全体としては、文書ファイルの種類 や、そこに記述される各タグについては抽象的、汎用的な定義がなされている。 一例として、「Doc」タグのプロパティとして、「Creater」、「CreateDate」といったタグ が含まれるようなスキーマ、いわば、グローバルオントロジ一が定義されているとする。 一方、営業部門では、「営業日報」タグのプロパティとして、「報告者」、「報告日」とい つたタグが含まれるようなスキーマ、いわば、ローカルオントロジ一が定義される。ここ で、「営業日報」タグは「Doc」タグを継承したタグである。同様に「報告者」、「報告日」 といったタグは、それぞれ「Creater」タグや「CreateDate」タグを継承している。以下、 グローバルオントロジーに基づ 、て定義されるタグのことを「モデルタグ」とよぶ。
[0204] さて、住所に関連する「MeetingPlace」タグはグローバルオントロジ一にて定義され ているモデルタグであるとする。セキュリティ管理者は、ローカルオントロジ一に基づく 文書ファイル内のデータを、この「MeetingPlace」と!、うモデルタグ名で検索する。「Me etingPlaceJというモデルタグは、研究部門では「出張先」タグとしてリネームされている 。また、営業部門では「住所」としてリネームされている。
すなわち、グローバノレオントロジ一における「MeetingPlace」というタグは、ロー力ノレ オントロジーにおいては、「出張先」であったり「住所」であったりと部署ごとの業務に 応じたタグ名となる。以下、ローカルオントロジーに基づいて定義されるタグのことを「 実体タグ」とよぶ。
[0205] 図 34は、研究部門におけるグローバルオントロジ一とローカルオントロジ一の関係 を示す図である。
ここに示すように、グローバルオントロジ一における「MeetingPlace」タグは、この研 究部門においては「出張先」タグとなっている。グローノ レオントロジ一においては、「 DocumentEntityJと 、うクラスのプロパティとして「MeetingPlace」が定義されて 、る。 ヽ わば、社内基準としてのモデルタグのデータ構造力 そのまま各部署の文書ファイル の実体タグのデータ構造として継承されている。以下、社内基準であるグローバルォ ントロジーに基づいて作成された文書ファイルを「親文書ファイル」、また、そのタグ構 造を「親スキーマ」とよぶ。また、親スキーマを継承したスキーマ（以下、「子スキーマ」 とよぶ）をもち、ローカルオントロジーに基づいて各部署において生成された文書ファ ィルを「子文書ファイル」とよぶ。子文書ファイルの表示レイアウトは、各部署ごとに作 成されてもよ 、し、標準的な表示レイアウトがあら力じめ提供されてもょ 、。 [0206] 同図に示すように、実体タグのプロパティは、モデルタグのプロパティをそのまま ϋ 承している。その一方で、実体タグの名前は、各部署の業務に応じてリネーム可能と なっている。子文書ファイルは、モデルタグに実体タグをマッピングするためのタグマ ッビングテーブルとセットで保持されることになる。たとえば、「出張先」タグは、その継 承元である「MeetingPlace」タグにマッピングされて!/、る。
[0207] 図 35は、営業部門におけるグローバルオントロジ一とローカルオントロジ一の関係 を示す図である。
ここに示すように、グローバルオントロジ一における「MeetingPlace」タグは、この営 業部門にお 、ては「住所」タグとなって 、る。
[0208] セキュリティ管理者は、たとえば、社内の様々な子文書ファイルに対して「MeetingPl acej t ヽぅモデルタグを継承する実体タグに対応して入力されて ヽるデータを検索す ることができる。セキュリティ管理者が「MeetingPlace」タグを検索キーとして社内デー タベースを検索すると、先述したタグマッピングテーブルによって、子スキーマごとに 対応する実体タグ名が特定される。たとえば、研究部門において使用されている子文 書ファイルに対して、「MeetingPlace」タグを検索キーとして検索指示した場合、検索 キーは「出張先」というタグ名に変換される。そして、「出張先」タグを入力項目とする データを子文書ファイル力も検出することができる。そのため、セキュリティ管理者は、 実体タグ名を知らなくても、モデルタグの名前で一元的に社内文書力 所望のデー タを検索できる。一方、各部署における子文書ファイルユーザは、グローバルオントロ ジ一にしたがっている限り、自由に実体タグ名を設定できるため、セキュリティ管理者 と各部署のユーザが社内文書を扱うための利便性を向上させることができる。
[0209] 図 36は、子文書ファイルにァノテーシヨンを付与する態様を説明するための模式図 である。
1.研究部門で個人情報となる人名や住所などに「個人情報対象データ」を示すァ ノテーシヨンを設定する。
2.この時、子文書ファイルが 2種類以上の表示レイアウトにて表示されているときに は、一方の表示画面に対するァノテーシヨン設定はその他の表示画面に対するァノ テーシヨン設定として同時的に反映される。これは、ァノテーシヨンが子文書ファイル の「データ」に設定される力 である。前提技術において説明したミューテーシヨンィ ベントによる技術が応用される。
3.営業部門でも、個人情報となる人名や住所などに「個人情報対象データ」を示 すァノテーシヨンを設定する。
4.企画者力 Sこのふたつの文書、すなわち、研究部門の子文書ファイルと営業部門 の子文書ファイルを利用してひとつの企画書ファイルを作成しても、それぞれのァノ テーシヨン情報は残って 、る。
5.外部へ企画書ファイルを送信する場合には、会社のセキュリティシステムがこの ァノテーシヨンが設定されて 、る部分をマスキングすることで、個人情報にかかわる箇 所が外部流出することを防ぐ。
[0210] このようなァノテーシヨンもタグと同じく構造ィ匕文書ファイルの構成要素の一種といえ る。親スキーマには、たとえば、「Important」ァノテーシヨンのように、グローバルオント ロジ一に基づく複数種類のァノテーシヨンが含まれている。一方、子スキーマには、こ の「Important」ァノテーシヨンを継承したァノテーシヨンが含まれることになる。ユーザ は、この子スキーマにおけるァノテーシヨン（以下、「実体ァノテーシヨン」とよぶ）の名 前を、実体タグと同様にリネームできる。たとえば、「Important」ァノテーシヨンを「営業 秘密」ァノテーシヨンといった具合に業務に応じたリネームが可能である。
[0211] 子スキーマの各実体ァノテーシヨンのプロパティは、親スキーマにおけるァノテーシ ヨン（以下、グローバルオントロジ一に基づ 、て定義されて 、るァノテーシヨンのことを 「モデルァノテーシヨン」とよぶ）のプロパティをそのまま継承して 、る。子文書ファイル は、この親スキーマによるモデルァノテーシヨンに実体ァノテーシヨンをマッピングす るためのァノテーシヨンマッピングテーブルとセットで保持されることになる。
[0212] セキュリティ管理者は、モデルァノテーシヨンを検索キーとして、社内データベース を検索すると、先述したァノテーシヨンマッピングテーブルによって、子スキーマごとに 対応する実体ァノテーシヨン名が特定される。たとえば、「Important」ァノテーシヨンを 検索キーとして検索指示した場合、営業部門の子文書ファイルについては「営業秘 密」ァノテーシヨンに変換される。そして、「営業秘密」ァノテーシヨンが設定されている データを子文書ファイル力も検出することができる。そのため、セキュリティ管理者は、 実体ァノテーシヨン名を知らなくても、モデルァノテーシヨンの名前で一元的に社内文 書力も所望のデータを検索できる。一方、各部署における子文書ファイルユーザは、 グローバルオントロジーにしたがっている限り、自由にァノテーシヨン名を設定できる ため、セキュリティ管理者と各部署のユーザが社内文書を扱うための利便性を向上さ せることができる。
[0213] ァノテーシヨンの場合、タグというスキーマに必ずしも制約されることがないというメリ ットがある。たとえば、「\^61 ¾?1&06」と「\^61 ¾じ0 6 」タグに入力される 2種類の データに 1種類のァノテーシヨンが設定されてもよい。あるいは、「MeetingPlace」タグ への入力データの一部に対してァノテーシヨンが設定されてもよい。
モデルァノテーシヨンとしては、たとえば、個人情報を指定するためのァノテーシヨン 、重要情報を指定するためのァノテーシヨンなどさまざまな種類のァノテーシヨンが用 意されてもよい。子文書ファイルに対し、個人情報を指定するためのモデルァノテ一 シヨンを継承した実体ァノテーシヨン力 個人情報に相当するデータ範囲に設定され てもよい。そして、たとえば、個人情報を指定するためのモデルァノテーシヨン力 継 承された実体ァノテーシヨンが設定されているデータについては、社外に送信されな いように処置してもよい。より具体的には、セキュリティシステムが個人情報を指定す るためのモデルァノテーシヨンを検索キーとして、子文書ファイルの個人情報を特定 し、これらのデータをマスキングすることによって、個人情報が外部に流出しないよう に処置することができる。
[0214] 図 37は、ァノテーシヨンによるセキュリティ管理を説明するための模式図である。
1.セキュリティ管理者としては、個人情報を指定するためのタグを社内文書フアイ ルに付与させるため、「SecurityName」というタグ名で管理している。
2.営業部門では、部署内の文書ファイルにおいてわ力りやすいように「非流出顧 客情報」として、研究部門では「研究者情報」として独自のァノテーシヨン名にてァノ テーシヨンを設定している。同図に示すように、営業部門においては、「A氏」というデ ータをァノテートするために、「非流出顧客情報」というァノテーシヨンがタグとして設 定されている。一方、研究部門においては「B氏」というデータをァノテートするために 、「研究者情報」 t 、うァノテーシヨンがタグとして設定されて 、る。 3.この関係は VCDにより連結されている。すなわち、個人情報のァノテーシヨン時 に利用される各部署のタグは、社内基準である「SecurityName」タグにマッピングする 処理が VCDとして提供される。
4.これにより各部署におけるローカルな用語にてァノテーシヨンが設定されても、セ キユリティ管理は「SecurityName」により一元的に管理することができる。
[0215] ァノテーシヨンは、子文書ファイルのタグや、タグに対して入力されたデータの全部 または一部、あるいは、複数のタグに対して入力されたデータのセットに対して設定さ れてもよい。
[0216] 次に、タグに基づくデータ処理関数を 2例挙げる。
関数名： ont_searh
引数:ローカルドメイン、実体タグ
返値：指定した実体タグの継承元であるモデルタグ力 継承されて 、る、全てのドメ インにおける実体タグの一覧
説明：指定した実体タグと同じグローノ レオントロジ一のクラスに該当する全ての実 体タグの一覧を取得する。この関数は、まず、 DOMツリーを取得した後、営業部門 の「住所」と 、う実体タグの継承元である「MeetingPlace」 t 、うモデルタグを取得する 。そして、このモデルタグを継承している研究部門の「出張先」タグを検出する。
これにより、取得したいノードに相当する概念 (オントロジ一のクラス)あるいは、それ に相当する他のドメインのタグを指定することで、検索が可能となる。いいかえれば、 検索対象のドメインがわ力もなくても検索が可能となる。
サンフノレ：く vcd:for— each select= ¾inction:ont— search(function:aocument、 *.xml / /*/営業部門:住所)"〉
このサンプルの場合、カレントディレクトリの拡張子が xmlである全てのファイルを par seし、その中で営業部門：住所と同じグローバルオントロジ一のクラスに該当するノー ドの一覧を取得する。
[0217] 関数名： ont_call
引数：ターゲットドメイン、コマンド名
返値：ターゲットドメインの VCDに定義されて 、るコマンドを実行する。 説明:オントロジ一におけるドメイン変換を行って、表示や編集を行う場合、編集コ マンドを記述してあるドメインと編集対象となるドメインが異なるため、編集対象ドキュ メントのスキーマを保つことを保証しがたい。そこで、たとえば、個人情報にタグを付 けるといった特定の編集コマンドのインタフェースをグローバルオントロジ一で定義す る。そして、各ドメインにおけるローカルオントロジ一において、これらの編集コマンド を実装することにより、各ドメインにおけるスキーマにしたがった形で編集コマンドを定 義できる。このコマンドは各ドメインを処理するための VCDコマンドとして定義する。 サンプノレ：、 vcd: action event= event:mouse— clicked >^instruction:callname= functi on:ont— call(annotate— privacy,$contextNS)7〉く/ vcd:action〉
このサンプルの場合、該当箇所でマウスがクリックされると、 $contextNSドメインで定 義された annotate-privacyというコマンドが実行される。
[0218] 図 38として、図 34や図 35に関連して説明したタグマッピングテーブルの別例を示 す。
ここでは、「Customer」として定義されたモデルタグ力 研究部門においては「出張 先」、営業部門では「顧客名」として定義されている。こうした知識があれば、セキユリ ティ管理者は、個人情報となりえる情報を検索する場合において、
研究部門-〉出張報告書-〉出張先
営業部門-〉営業日報-〉顧客名
t ヽぅローカルなタグ名で該当データを検索する必要はなく、
DocumentEntry―〉し ustomer
だけで、必要な情報を検索できる。
[0219] 以上、本実施例における文書処理技術の特徴をまとめると以下の通りである。
1. XML技術とセマンティック Web技術の融合
文書処理装置 20をプラットフォームとすることで、 RDF、 RDFS(Resource Description Framework Shema)、 OWL(Web Ontology Language)といつァこセマンティック Web技 と XML技術がシームレスに結合可能となる。
2.ヒューマンリーダブルからマシーンリーダブルのデータ整合性
セマンティック Webの展望であるヒューマンリーダブルからマシーンリーダブルととも に、現実世界で問題となるデータを扱うブラウザとデータの整合性が文書処理装置 2 0にて統一して扱うことができる。
3.上記 2の各技術を連携した個人情報管理支援システムを文書処理装置 20を プラットフォームとして実現することができる。
以上の実施例に示した処理方法には、企業などの業務組織において取り扱われる 文書ファイルのデータ整合性を保持しやすくなるという効果がある。
[0220] 本発明に関連して更に付言する。
これまでに、モデルタグと実体タグのマッピング、およびその利用場面を中心として 説明した。たとえば、社内において標準的なモデルタグのセット（以下、「モデルタグ セット」とよぶ）を用意しておき、各部署ではモデルタグセットをベースとして業務に即 した実体タグを作り、実体タグに基づいて XML文書ファイルを作成してもよい。この 場合、開発部とマーケティング部、営業部はそれぞれ別々の実体タグにより XML文 書を作成することになる。しかし、実体タグのセット（以下、「実体タグセット」とよぶ）は 別々であってもその継承元は同じモデルタグセットであるため、モデルタグに基づく 情報検索が可能である。
[0221] たとえば、モデルタグく従業員〉力 実体タグく課長〉やくライセンス担当〉が継 承されているとし、このような実体タグによって記述されている XML文書ファイルを想 定する。より具体的には、この XML文書ファイルにく課長 >加藤く/課長 >、 <ラ ィセンス担当 >長谷川 < /ライセンス担当 >と 、う 2つの要素が含まれて 、る場合、 モデルタグ <従業員 >を対象としてデータ検出を指示すると、「加藤」、「長谷川」とい う 2つの要素データを検出できる。これは、モデルタグ <従業員 >と実体タグ <課長 >およびくライセンス担当〉が内部的に対応づけられているためである。モデルタグ を継承するかたちで実体タグを作成する限り、モデルタグを検索キーとして実体タグ の要素データから求める情報を取得できる。タグに限らず、ァノテーシヨンについても 同様である。以下、このようなモデルタグから継承するかたちで実体タグを生成し、モ デルタグと実体タグをマッピングするやり方を「トップダウンアプローチ」とよぶことにす る。
[0222] これとは別の場面として、 XML文書ファイルにおいて既に使用されているさまざま な実体タグをモデルタグにマッピングしてもよい。以下、このようなマッピングの仕方を 「ボトムアップアプローチ」とよぶことにする。ボトムアップアプローチにおいては、実体 タグはモデルタグから継承して作成する必要はなぐユーザが任意に定義できる。仮 に、ある XML文書ファイルに実体タグく課長 >ゃ<ライセンス担当 >が含まれてい るとする。これらの実体タグは、モデルタグをベースとして作成されたタグではなぐュ 一ザが特段の制約もなく自由に定義したタグであるとする。一方、さきほどのモデルタ グく従業員〉には、く社長〉、く課長〉、くライセンス担当〉、く新入社員〉、 < プロジェクトリーダ〉、 · · ·のようにさまざまな下位概念語や類語にあたるタグがあらか じめ定義されて!ヽる。モデルタグの名前と実体タグの名前が上位概念語と下位概念 語の関係にあるとき、これらのタグは自動的に対応づけられることになる。 XML文書 ファイルの実体タグく課長 >は、モデルタグく従業員 >の下位概念語となって!/、る ことから、実体タグく課長 >に対してモデルタグく従業員 >が自動的に対応づけら れる。このような方法によれば、既存の XML文書ファイルに含まれているタグを標準 的なモデルタグに自動的に結びつけることができる。
[0223] 図 39は、前提技術で説明した文書処理装置 20の各種機能を利用しつつ、実体タ グとモデルタグのマッピング機能を実現する文書処理装置 3000の機能ブロック図で ある。
ここに示す各ブロックは、ハードウェア的には、コンピュータの CPUをはじめとする 素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実 現される力 ここでは、それらの連携によって実現される機能ブロックを描いている。 したがって、これらの機能ブロックはハードウェア、ソフトウェアの組み合わせによって いろいろなかたちで実現できることは、当業者には理解されるところである。
[0224] 文書処理装置 3000は、ユーザインタフェース処理部 3100、通信部 3130、データ 処理部 3200およびデータ保持部 3250を含む。
ユーザインタフェース処理部 3100は、ユーザからの入力処理やユーザに対する情 報表示のようなユーザインタフェース全般に関する処理を担当する。本実施例にお いては、ユーザインタフェース処理部 3100により文書処理装置 3000のユーザインタ フェースサービスが提供されるものとして説明する。別例として、ユーザはインターネ ットを介して文書処理装置 3000を操作してもよい。この場合、通信部 3130が、ユー ザ端末力 の操作指示情報を受信し、またその操作指示に基づ 、て実行された処 理結果情報をユーザ端末に送信することになる。
[0225] データ処理部 3200は、ユーザインタフェース処理部 3100や通信部 3130から取 得されたデータを元にして各種のデータ処理を実行する。データ処理部 3200は、ュ 一ザインタフエース処理部 3100とデータ保持部 3250の間のインタフェースの役割も 果たす。データ保持部 3250は、あらかじめ用意された設定データや、データ処理部 3200から受け取ったデータなど、さまざまなデータを格納する。
[0226] ユーザインタフェース処理部 3100は、ユーザからの入力を受け付ける入力部 311 0とユーザに対して各種情報を表示する表示部 3120を含む。表示部 3120の機能は 、前提技術で説明した文書処理装置 20の表示部 56等により実現される。入力部 31 10は、ァノテーシヨン設定部 3112と文書取得部 3114を含む。ァノテーシヨン設定部 3112は、ユーザからの指示入力に基づき、 XML文書に対してァノテーシヨンを設定 する。ァノテーシヨンはタグの属性 (attribute)として設定される。文書取得部 3114は 、処理対象となる XML文書ファイルを取得する。
[0227] 通信部 3130は、他の文書処理装置 3000や所定のサーバ装置などの外部装置と 通信する。通信部 3130は、文書送信部 3132と文書受信部 3134を含む。文書送信 部 3132は、外部装置に XML文書ファイルを送信する。文書受信部 3134は、外部 装置から XML文書ファイルを受信する。このように、文書処理装置 3000は文書取得 部 3114と文書受信部 3134の 、ずれかを介して処理対象となる XML文書ファイル を取得する。
[0228] データ保持部 3250は、ファイル保持部 3252、タグマッピングテーブル保持部 325 4およびァノテーシヨンマッピングテーブル保持部 3256を含む。
ファイル保持部 3252は、 XML文書ファイル、特に、実体タグによって記述された X ML文書ファイルを保持する。タグマッピングテーブル保持部 3254は、実体タグとモ デルタグを対応づけたタグマッピングテーブルを保持する。ァノテーシヨンマッピング テーブル保持部 3256は、実体ァノテーシヨンとモデルァノテーシヨンを対応づけたァ ノテーシヨンマッピングテーブルを保持する。 [0229] データ処理部 3200は、文書編集部 3210、検索部 3220、マッピング処理部 3230 およびマスク処理部 3240を含む。
文書編集部 3210は、ユーザからの入力に応じて XML文書ファイルの編集処理を 実行する。文書編集部 3210の主たる機能は、前提技術で説明した文書処理装置 2 0の基本的な機能、特に、編集ユニット 24により実現される。トップダウンアプローチと して、ユーザは、モデルタグセットによって記述されている XML文書ファイルを、実体 タグで記述された XML文書ファイルに変換してもよい。また、ボトムアップアプローチ として、はじめから自由に実体タグを定義して XML文書ファイルを作成してもよい。
[0230] 文書編集部 3210は、タグリネーム部 3212とァノテーシヨンリネーム部 3214を含む 。トップダウンアプローチを採る場合において、タグリネーム部 3212は、モデルタグ 名を変更することにより実体タグを生成する。このとき、マッピング処理部 3230のマツ ビング記録部 3234は、実体タグと変更元のモデルタグをタグマッピングテーブルに 対応づけて記録する。ァノテーシヨンリネーム部 3214も同様であり、モデルァノテ一 シヨン名を変更することにより実体ァノテーシヨンを生成する。マッピング記録部 3234 は、実体ァノテーシヨンと変更元のモデルァノテーシヨンをモデルマッピングテーブル に対応づけて記録する。トップダウンアプローチにより実体タグや実体ァノテーシヨン が生成されるときには、マッピング記録部 3234が対応づけを自動的に行う。一方、ボ トムアップアプローチの場合においては、マッピング処理部 3230の対応検出部 323 2がモデルタグと実体タグ、モデルァノテーシヨンと実体ァノテーシヨンとの対応関係 を自動検出する。検出方法については後述する。
[0231] 検索部 3220は、 XML文書ファイル中力もタグゃァノテーシヨンを検索する。検索 部 3220はタグ検索部 3222とァノテーシヨン検索部 3224を含む。
タグ検索部 3222はタグを検索する。たとえば、先ほどの例の場合、モデルタグく従 業員〉を検索キーとする場合、タグ検索部 3222は、タグマッピングテーブルを参照 してモデルタグく従業員〉と対応づけられている実体タグを検出する。すなわち、 X ML文書ファイル中から実体タグく課長〉やくライセンス担当〉を検出し、それらの 要素データを取得する。
[0232] このようなモデルタグ→実体タグという検索方法に限らず、実体タグ→モデルタグ→ 実体タグという検索方法も可能である。たとえば、ある XML文書ファイル Aでは実体 タグく課長 >が使用されており、別の XML文書ファイル Bでは実体タグくライセンス 担当 >が使用されていたとする。このとき、 XML文書ファイル Aの実体タグく課長 > を検索キーとして、 XML文書ファイル B力 実体タグくライセンス担当〉を検索して もよい。この場合、タグ検索部 3222は、 XML文書ファイル Aの実体タグく課長〉と タグマッピングテーブルにお ヽて対応づけられて ヽるモデルタグく従業員 >を特定 する。次に、タグ検索部 3222は、モデルタグく従業員〉とタグマッピングテーブルに おいて対応づけられている実体タグくライセンス担当 >を特定する。このようにして、 同じモデルタグにマッピングされて 、る別の実体タグを検索することもできる。タグマツ ビングテーブルは、モデルタグセットと実体タグセットの組み合わせごとに用意される 。無論、 XML文書ファイル Aの実体タグを検索キーとして、同じ XML文書ファイル A に含まれ、同じモデルタグとマッピングされて 、る別の実体タグを検索することもでき る。
[0233] ァノテーシヨン検索部 3224はァノテーシヨンを検索する。ァノテーシヨン検索部 322 4もタグ検索と同様に、モデルァノテーシヨンを検索キーとして、 XML文書ファイル中 力も該当する実体ァノテーシヨンを検索する。また、実体ァノテーシヨンを検索キーと して、同じモデルァノテーシヨンにマッピングされて!/、る別の実体ァノテーシヨンを検 索することちでさる。
[0234] マッピング処理部 3230は、タグゃァノテーシヨンのマッピングを管理する。基本的 な仕組みは、前提技術で説明した VCユニット 80によるボキヤブラリコネクションの仕 組みと同様である。マッピング処理部 3230は、対応検出部 3232とマッピング記録部 3234を含む。対応検出部 3232は、ボトムアップアプローチにおいて実体タグとモデ ルタグ、実体ァノテーシヨンとモデルァノテーシヨンの対応関係を検出する。
[0235] 対応検出部 3232は、あらカゝじめ用意されている類語テーブルや概念語テーブル を参照して、対応関係を検出する。類語テーブルには、類語関係にある単語の組み 合わせ記述されている。たとえば、「自動車」という単語に対しては、「電車」、「自転車 」などの単語が類語として登録されている。モデルタグく自動車〉が定義されている
Figure imgf000064_0001
、て、ユーザが XML文書ファイル中にく電車 >と 、う実体タグを定義した ときには、対応検出部 3232は類語テーブルを参照して、モデルタグく自動車〉と実 体タグく電車〉の対応関係を検出し、マッピング記録部 3234はタグマッピングテー ブルに両タグを対応づけて記録する。
[0236] 概念語テーブルには、上位概念と下位概念の関係にある単語の組み合わせが記 述されている。たとえば、「自動車」という単語に対しては、「高級車」、「新型車」など の下位概念にあたる単語が登録されている。モデルタグく自動車〉が定義されてい る場合にぉ 、て、ユーザが XML文書ファイル中にく高級車〉と 、う実体タグを定義 したときには、対応検出部 3232は類語テーブルを参照して、モデルタグく自動車〉 と実体タグく高級車〉の対応関係を検出し、マッピング記録部 3234はタグマツピン グテーブルに各タグを対応づけて記録する。
[0237] このように、対応検出部 3232は、類語テーブルおよび概念語テーブルの双方また は一方を参照してタグ間の対応関係を検出する。ァノテーシヨンについても同様であ る。ボトムアップアプローチにおいて、ユーザは実体タグに対して任意のモデルタグ セットにおける任意のモデルタグを明示的にマッピングしてもよ 、。明示的なマツピン グが指示されると、マッピング記録部 3234はタグマッピングテーブルに実体タグとモ デルタグの対応関係を記録する。 1つのモデルタグセットに対して複数種類の実体タ ダセットをそれぞれ対応づけてもょ 、し、複数種類のモデルタグセットに対して 1つの 実体タグセットを対応づけてもよ 、。
[0238] マスク処理部 3240は、ユーザによって指定された情報を非公開化する。たとえば、 ファイル保持部 3252に保持されて ヽる XML文書ファイルを画面表示させるとき、個 人情報保護のために従業員名に関わる情報を表示対象外としたいとする。この場合 、ユーザは非表示対象データをモデルタグ <従業員 >により指定する。マスク処理 部 3240は、タグマッピングテーブルを参照して、 XML文書ファイル中力 対応する 実体タグを検出する。そして、対応する実体タグ <課長 >ゃ<ライセンス担当 >の要 素データである「加藤」は「長谷川」を表示対象から除外する。具体的には、 XML文 書ファイルを XSLスタイルシートにて変換することにより、非表示データが除外された XML文書ファイルを新たに生成する。そして、生成された XML文書ファイルに含ま れるデータが実際の表示対象となる。文書送信部 3132によって外部装置に XML文 書ファイルを送信するときにも、データのマスクが可能である。この場合には、非表示 データが除外された XML文書ファイルが送信対象となる。このような処理方法によれ ば、モデルタグにより非表示対象データを指定することにより、モデルタグとマツピン グされているさまざまな実体タグの要素データを一元的に非公開化できる。また、非 公開化以外にも、たとえば、該当データの表示色やフォントを変更してもよい。このよ うにマスク処理部 3240は、ユーザによって指定された情報の表示態様を変化させる ことちでさる。
[0239] 図 40は、モデルタグと実体タグのマッピング構造を説明するための模式図である。
ここではモデルタグセット 1、モデルタグセット 2と!、う 2種類のモデルタグセットが提 供されて!ヽるとする。モデルタグセット 1とモデルタグセット 2は別々のベンダー (vende r)によって提供されてもよい。 XML文書ファイル 3300や XML文書ファイル 3302に 含まれている実体タグは、モデルタグをリネームしたものではなぐユーザが任意に設 定したタグである。すなわち、ボトムアップアプローチを前提としている。モデルタグセ ット 1は、モデルタグく人間〉と、その下位概念語としてのモデルタグく従業員〉を 含む。単語「従業員」には、類語として「社員」、下位概念語として「課長」、「社長」、「 課長代理」等の単語が類語テーブルや概念語テーブルにお 、て対応づけられて ヽ るものとする。モデルタグセット 2は、モデルタグとしてく重要〉とく不要〉を含む。
[0240] XML文書ファイル 3300には、実体タグく社員〉が含まれている。対応検出部 32 32は、類語テーブルを参照して「社員」と!ヽぅ単語と「従業員」 t ヽぅ単語が類語関係 にあることを検出する。このとき、マッピング記録部 3234は、 XML文書ファイル 3300 の実体タグく社員 >とモデルタグセット 1のモデルタグく従業員 >とを対応づけてタ グマッピングテーブルに記録する。
[0241] XML文書ファイル 3302は、実体タグく課長 >、く社長 >、く課長代理 >を含む 。対応検出部 3232は、概念語テーブルを参照して「課長」という単語が「従業員」と いう単語の下位概念語であることを検出する。このとき、マッピング記録部 3234は、 X ML文書ファイル 3302の実体タグく課長 >とモデルタグセット 1のモデルタグく従業 員 >とを対応づけてタグマッピングテーブルに記録する。 <社長 >やく課長代理 > についても同様である。 [0242] ユーザは、モデルタグセット 2のモデルタグく重要 >に対して実体タグく社長 >を 明示的にマッピングしている。このため、マッピング記録部 3234は、 XML文書フアイ ル 3302の実体タグく社長 >とモデルタグセット 2のモデルタグく重要 >とを対応づ けてタグマッピングテーブルに記録する。また、ユーザはモデルタグく不要〉に対し て実体タグく課長代理〉を明示的にマッピングしている。このため、これらのタグもタ グマッピングテーブルにおいて対応づけられる。
このような実体タグく社長 >とモデルタグく重要 >のマッピングはユーザの判断に 基づいている。そのため、同じモデルタグセット 2に対して、実体タグく社長〉にモデ ルタグく不要 >をマッピングし、く課長 >ゃ<課長代理 >に対してはモデルタグく 重要 >をマッピングしてもよい。中間管理職 =重要という観点に立つならば、このよう なマッピングも想定し得る。特に、「重要」や「不要」のように評価に関わるモデルタグ の場合、ユーザの価値判断や評価基準に応じてマッピングが変化する可能性もある 。たとえば、システムの運用中に、実体タグく課長代理 >は<不要 >ではなく <重 要〉にマッピングされるべきであるとして状況変化することがある。この場合、タグマツ ビングテーブルにおける実体タグとモデルタグの対応関係を変更する。このように、 実体タグとモデルタグの対応関係は、状況に応じて柔軟に変更可能であることが望ま しい。更に、マッピングテーブルは、ユーザごとに設定してもよい。たとえば、ユーザ A はく社長 >に <重要 >をマッピングし、ユーザ Bはく社長 >に <不要 >をマツピン グするといつた具合である。この場合、モデルタグセットと実体タグセットの組み合わ せは同じでも、ユーザ A用のマッピングテーブルとユーザ B用のマッピングテーブル は另 IJ々となる。
[0243] このような処理モデルによると、既存の XML文書ファイルを 1以上のモデルタグセッ トにマッピングできる。そのため、さまざまな実体タグセットによって記述された XML 文書ファイルであっても、重要な実体タグをモデルタグ <重要 >とマッピングするだ けで重要な要素データを簡単に検索できる。ボトムアップアプローチによれば、ユー ザにモデルタグの使用やモデルタグをベースとした実体タグの生成を強いる必要が ない。そのため、モデルタグセットを介することによって、別々の実体タグセットを結び つけることができる。たとえば、開発部で使用されている実体タグセットと、マーケティ ング部で使用されている実体タグセットは別々のものである力もしれないが、共通の モデルタグセットを介することによって両部署の情報を合理的に結びつけることがで きる。また、さまざまな種類のモデルタグセットを用意しておけば、さまざまな観点から 実体タグを検索することができる。
産業上の利用可能性
本発明によれば、複数の構造ィ匕文書ファイルに含まれるデータを扱う上でのユーザ の利便性を向上させる上で効果がある。

Claims

請求の範囲
[1] 複数のタグが構造ィ匕された親文書ファイルのスキーマを継承したスキーマによって 生成された子文書ファイルを保持するファイル保持部と、
親文書ファイルに含まれるタグであるモデルタグから継承された子文書ファイルのタ グである実体タグの名前をユーザによる指示入力に応じて変更するタグリネーム処理 部と、
子文書ファイルに含まれる実体タグの名前と、その実体タグの継承元であるモデル タグの名前を対応づけたタグマッピングテーブルを保持するタグマッピングテーブル 保持部と、
モデルタグの名前を検索キーとするユーザによる検索指示入力により、前記タグマ ッビングテーブルを参照して対応する実体タグの名前を検出し、その実体タグの名前 を新たな検索キーとして子文書ファイル力 その実体タグの要素データを検出するタ グデータ検索部と、
を備えることを特徴とする文書処理装置。
[2] ユーザにより指定された実体タグの継承元であるモデルタグを前記タグマッピング テーブルを参照して検出し、前記タグマッピングテーブル保持部に保持されて!ヽる複 数のタグマッピングテーブルを参照することによりそのモデルタグを継承するその他 の実体タグを検出する関連タグ検索部を更に備えることを特徴とする請求項 1に記載 の文書処理装置。
[3] 複数のタグが構造ィ匕された親文書ファイルのスキーマを継承したスキーマによって 生成された子文書ファイルを保持するファイル保持部と、
親文書ファイルに含まれるァノテーシヨンであるモデルァノテーシヨンから継承され た子文書ファイルのァノテーシヨンである実体ァノテーシヨンの名前をユーザによる指 示入力に応じて変更するァノテーシヨンリネーム処理部と、
子文書ファイルに含まれる実体ァノテーシヨンの名前と、その実体ァノテーシヨンの 継承元であるモデルァノテーシヨンの名前を対応づけたァノテーシヨンマッピングテ 一ブルを保持するァノテーシヨンマッピングテーブル保持部と、
子文書ファイルに含まれるユーザによって指示されたデータに実体ァノテーシヨン を設定するァノテーシヨン設定部と、
モデルァノテーシヨンの名前を検索キーとするユーザによる検索指示入力により、 前記ァノテーシヨンマッピングテーブルを参照して対応する実体ァノテーシヨンの名 前を検出し、その実体ァノテーシヨンの名前を新たな検索キーとして子文書ファイル 力 その実体ァノテーシヨンが設定されるデータを検出するァノテーシヨンデータ検 索部と、
を備えることを特徴とする文書処理装置。
[4] 子文書ファイルを外部装置に送信するファイル送信部を更に備え、
前記ァノテーシヨンデータ検索部は、子文書ファイルに含まれるデータのうち外部 送信を禁止すべきデータに設定されるモデルァノテーシヨンを検索キーとして子文書 ファイルカゝら該当データを検出し、
前記ファイル送信部は、その検出されたデータの外部装置に対する送信を抑止す ることを特徴とする請求項 3に記載の文書処理装置。
[5] 所定のタグセットに属する実体タグによって記述された構造ィ匕文書ファイルを取得 する文書取得部と、
前記構造ィ匕文書ファイルに含まれる実体タグを検出し、前記所定のタグセットとは 異なるタグセットに属するモデルタグのうち、前記検出した実体タグと所定の関係にあ るモデルタグを検出する対応検出部と、
前記所定の関係にある実体タグとモデルタグを対応づけてタグマッピングテーブル に記録するマッピング記録部と、
モデルタグを検索キーとする検索指示入力をユーザ力 受け付けると、前記タグマ
Figure imgf000070_0001
、る実体タグの要素データを前記構造ィ匕 文書ファイル力 検出するタグ検索部と、
を備えることを特徴とする文書処理装置。
[6] 前記構造化文書ファイルに含まれるデータを画面表示させるデータ表示部と、 表示対象外となる要素データに対応するモデルタグの指定入力をユーザ力 受け 付けると、前記タグマッピングテーブルにお ヽて対応づけられて!/ヽる実体タグを検出 し、前記構造ィ匕文書ファイルにお 、てその実体タグにより特定される要素データを表 示対象から除外する表示制御部と、
を更に備えることを特徴とする請求項 5に記載の文書処理装置。
[7] 前記対応検出部は、類語関係にある単語の組み合わせが定義された類語データ テーブルを参照して、前記構造ィ匕文書ファイル力 検出した実体タグの名前と類語 関係にある名前のモデルタグを前記所定の関係にあるモデルタグとして検出すること を特徴とする請求項 5または 6に記載の文書処理装置。
[8] 前記対応検出部は、上位概念と下位概念の関係にある単語の組み合わせが定義 された概念データテーブルを参照して、前記構造ィ匕文書ファイル力 検出した実体 タグの名前に対して上位概念にあたる名前のモデルタグを前記所定の関係にあるモ デルタグとして検出することを特徴とする請求項 5または 6に記載の文書処理装置。
[9] 複数のタグが構造ィ匕された親文書ファイルのスキーマを継承したスキーマによって 生成された子文書ファイルにつ 、て、親文書ファイルに含まれるタグであるモデルタ グから継承された子文書ファイルのタグである実体タグの名前をユーザによる指示入 力に応じて変更するステップと、
モデルタグの名前を検索キーとするユーザによる検索指示入力により、子文書ファ ィルに含まれる実体タグの名前とその実体タグの継承元であるモデルタグの名前を 対応づけたタグマッピングテーブルを参照して、対応する実体タグの名前を検出し、 その実体タグの名前を新たな検索キーとして子文書ファイル力 その実体タグの要 素データを検出するステップと、
を備えることを特徴とする文書処理方法。
[10] 複数のタグが構造ィ匕された親文書ファイルのスキーマを継承したスキーマによって 生成された子文書ファイルにつ 、て、親文書ファイルに含まれるァノテーシヨンである モデルァノテーシヨン力も継承された子文書ファイルのァノテーシヨンである実体ァノ テーシヨンの名前をユーザによる指示入力に応じて変更するステップと、
子文書ファイルに含まれるユーザによって指示されたデータに実体ァノテーシヨン を設定するステップと、
モデルァノテーシヨンの名前を検索キーとするユーザによる検索指示入力により、 子文書ファイルに含まれる実体ァノテーシヨンの名前とその実体ァノテーシヨンの継 承元であるモデルァノテーシヨンの名前を対応づけたァノテーシヨンマッピングテー ブルを参照して対応する実体ァノテーシヨンの名前を検出し、その実体ァノテーショ ンの名前を新たな検索キーとして子文書ファイル力 その実体ァノテーシヨンが設定 されるデータを検出するステップと、
を備えることを特徴とする文書処理方法。
[11] 複数のタグが構造ィ匕された親文書ファイルのスキーマを継承したスキーマによって 生成された子文書ファイルにつ 、て、親文書ファイルに含まれるタグであるモデルタ グから継承された子文書ファイルのタグである実体タグの名前をユーザによる指示入 力に応じて変更する機能と、
モデルタグの名前を検索キーとするユーザによる検索指示入力により、子文書ファ ィルに含まれる実体タグの名前とその実体タグの継承元であるモデルタグの名前を 対応づけたタグマッピングテーブルを参照して、対応する実体タグの名前を検出し、 その実体タグの名前を新たな検索キーとして子文書ファイル力 その実体タグの要 素データを検出する機能と、
をコンピュータに発揮させることを特徴とする文書処理プログラム。
[12] 複数のタグが構造ィ匕された親文書ファイルのスキーマを継承したスキーマによって 生成された子文書ファイルにつ 、て、親文書ファイルに含まれるァノテーシヨンである モデルァノテーシヨン力も継承された子文書ファイルのァノテーシヨンである実体ァノ テーシヨンの名前をユーザによる指示入力に応じて変更する機能と、
子文書ファイルに含まれるユーザによって指示されたデータに実体ァノテーシヨン を設定する機能と、
モデルァノテーシヨンの名前を検索キーとするユーザによる検索指示入力により、 子文書ファイルに含まれる実体ァノテーシヨンの名前とその実体ァノテーシヨンの継 承元であるモデルァノテーシヨンの名前を対応づけたァノテーシヨンマッピングテー ブルを参照して対応する実体ァノテーシヨンの名前を検出し、その実体ァノテーショ ンの名前を新たな検索キーとして子文書ファイル力 その実体ァノテーシヨンが設定 されるデータを検出する機能と、
をコンピュータに発揮させることを特徴とする文書処理プログラム。
[13] 所定のタグセットに属する実体タグによって記述された構造ィ匕文書ファイルを取得 するステップと、
前記構造ィ匕文書ファイルに含まれる実体タグを検出し、前記所定のタグセットとは 異なるタグセットに属するモデルタグのうち、前記検出した実体タグと所定の関係にあ るモデルタグを検出するステップと、
前記所定の関係にある実体タグとモデルタグを対応づけてタグマッピングテーブル に記録するステップと、
モデルタグを検索キーとする検索指示入力をユーザ力 受け付けると、前記タグマ
Figure imgf000073_0001
、る実体タグの要素データを前記構造ィ匕 文書ファイル力 検出するステップと、
を備えることを特徴とする文書処理方法。
[14] 所定のタグセットに属する実体タグによって記述された構造ィ匕文書ファイルを取得 する機能と、
前記構造ィ匕文書ファイルに含まれる実体タグを検出し、前記所定のタグセットとは 異なるタグセットに属するモデルタグのうち、前記検出した実体タグと所定の関係にあ るモデルタグを検出する機能と、
前記所定の関係にある実体タグとモデルタグを対応づけてタグマッピングテーブル に記録する機能と、
モデルタグを検索キーとする検索指示入力をユーザ力 受け付けると、前記タグマ
Figure imgf000073_0002
、る実体タグの要素データを前記構造ィ匕 文書ファイルから検出する機能と、
をコンピュータに発揮させることを特徴とする文書管理プログラム。
PCT/JP2006/309337 2005-05-09 2006-05-09 文書処理装置および文書処理方法 WO2006121051A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007528290A JP5073494B2 (ja) 2005-05-09 2006-05-09 文書処理装置および文書処理方法
US11/913,602 US20090070295A1 (en) 2005-05-09 2006-05-09 Document processing device and document processing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005-135764 2005-05-09
JP2005135764 2005-05-09

Publications (1)

Publication Number Publication Date
WO2006121051A1 true WO2006121051A1 (ja) 2006-11-16

Family

ID=37396559

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/309337 WO2006121051A1 (ja) 2005-05-09 2006-05-09 文書処理装置および文書処理方法

Country Status (3)

Country Link
US (1) US20090070295A1 (ja)
JP (1) JP5073494B2 (ja)
WO (1) WO2006121051A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009093389A (ja) * 2007-10-09 2009-04-30 Obic Business Consultants Ltd 情報処理装置、情報処理方法、およびプログラム
JPWO2022113219A1 (ja) * 2020-11-25 2022-06-02

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8356053B2 (en) * 2005-10-20 2013-01-15 Oracle International Corporation Managing relationships between resources stored within a repository
JP2008083769A (ja) * 2006-09-26 2008-04-10 Just Syst Corp 文書検索装置および文書検索方法
US9183321B2 (en) * 2006-10-16 2015-11-10 Oracle International Corporation Managing compound XML documents in a repository
US8499238B2 (en) * 2007-07-11 2013-07-30 International Business Machines Corporation Manipulating design models by editing generated reports
US7765236B2 (en) * 2007-08-31 2010-07-27 Microsoft Corporation Extracting data content items using template matching
US8301646B2 (en) * 2008-08-21 2012-10-30 Centurylink Intellectual Property Llc Research collection and retention system
US9317599B2 (en) * 2008-09-19 2016-04-19 Nokia Technologies Oy Method, apparatus and computer program product for providing relevance indication
US20100125616A1 (en) * 2008-11-19 2010-05-20 Sterling Commerce, Inc. Automatic generation of document translation maps
US20110252313A1 (en) * 2008-12-19 2011-10-13 Ray Tanushree Document information selection method and computer program product
JP5708495B2 (ja) * 2009-12-11 2015-04-30 日本電気株式会社 辞書作成装置、単語収集方法、及び、プログラム
US9600468B2 (en) * 2009-12-11 2017-03-21 Nec Corporation Dictionary creation device, word gathering method and recording medium
US9262185B2 (en) * 2010-11-22 2016-02-16 Unisys Corporation Scripted dynamic document generation using dynamic document template scripts
US9639631B2 (en) * 2013-02-27 2017-05-02 Cellco Partnership Converting XML to JSON with configurable output
AU2014253672B2 (en) 2013-04-19 2019-05-30 Commonwealth Scientific And Industrial Research Organisation Checking undoability of an API-controlled computing system
US11556578B2 (en) * 2014-05-12 2023-01-17 Semantic Technologies Pty Ltd Putative ontology generating method and apparatus
US20200321107A1 (en) * 2015-05-19 2020-10-08 Iryou Jyouhou Gijyutu Kenkyusyo Corporation Integrated multi-facility electronic medical record system
US10528612B2 (en) * 2017-02-21 2020-01-07 International Business Machines Corporation Processing request documents
US10679002B2 (en) * 2017-04-13 2020-06-09 International Business Machines Corporation Text analysis of narrative documents
US11003796B2 (en) * 2017-06-30 2021-05-11 Accenture Global Solutions Limited Artificial intelligence based document processor
US11562143B2 (en) 2017-06-30 2023-01-24 Accenture Global Solutions Limited Artificial intelligence (AI) based document processor
JP6638053B1 (ja) * 2018-12-05 2020-01-29 グレイステクノロジー株式会社 ドキュメント作成支援システム
CN109977385B (zh) * 2019-03-18 2023-04-25 合肥智慧联接科技有限公司 一种数据智能填充方法、装置、存储介质及终端
US11483294B2 (en) 2019-08-28 2022-10-25 University Of Maryland, Baltimore County Method for anonymizing network data using differential privacy

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000250938A (ja) * 1999-03-03 2000-09-14 Kdd Corp Ｘｍｌ文書検索装置
JP2001092827A (ja) * 1999-09-20 2001-04-06 Toshiba Corp データ管理装置および方法
JP2002099561A (ja) * 2000-09-21 2002-04-05 Toshiba Corp データ変換方法およびデータ変換システム並びに記憶媒体
JP2003058523A (ja) * 2001-08-21 2003-02-28 Nippon Telegr & Teleph Corp <Ntt> 構造化文書の変換ルール作成方法および装置と変換ルール作成プログラムおよび該プログラムを記録した記録媒体

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0581320A (ja) * 1991-09-25 1993-04-02 Matsushita Electric Ind Co Ltd 情報検索装置
JP2001229067A (ja) * 2000-02-16 2001-08-24 Fujitsu Ltd 構造化文書記述データ処理装置および構造化文書記述データ処理プログラム記録媒体
GB0011426D0 (en) * 2000-05-11 2000-06-28 Charteris Limited A method for transforming documents written in different XML-based languages
JP3914081B2 (ja) * 2002-03-26 2007-05-16 株式会社東芝 アクセス権限設定方法および構造化文書管理システム
JP2004336562A (ja) * 2003-05-09 2004-11-25 Canon Inc 画像送信装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000250938A (ja) * 1999-03-03 2000-09-14 Kdd Corp Ｘｍｌ文書検索装置
JP2001092827A (ja) * 1999-09-20 2001-04-06 Toshiba Corp データ管理装置および方法
JP2002099561A (ja) * 2000-09-21 2002-04-05 Toshiba Corp データ変換方法およびデータ変換システム並びに記憶媒体
JP2003058523A (ja) * 2001-08-21 2003-02-28 Nippon Telegr & Teleph Corp <Ntt> 構造化文書の変換ルール作成方法および装置と変換ルール作成プログラムおよび該プログラムを記録した記録媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NAGAO K.: "Arayuru Kiki ni Awasete Content o Jiyu Jizai ni Henkan", NIKKEI ELECTRONICS, no. 770, 22 May 2000 (2000-05-22), pages 165 - 176, XP003005294 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009093389A (ja) * 2007-10-09 2009-04-30 Obic Business Consultants Ltd 情報処理装置、情報処理方法、およびプログラム
JPWO2022113219A1 (ja) * 2020-11-25 2022-06-02
WO2022113219A1 (ja) * 2020-11-25 2022-06-02 株式会社日立製作所 タグドメイン提示装置およびタグドメイン提示方法、およびそれを用いた情報処理システム
JP7218451B2 (ja) 2020-11-25 2023-02-06 株式会社日立製作所 タグドメイン提示装置およびタグドメイン提示方法、およびそれを用いた情報処理システム

Also Published As

Publication number Publication date
US20090070295A1 (en) 2009-03-12
JP5073494B2 (ja) 2012-11-14
JPWO2006121051A1 (ja) 2008-12-18

Similar Documents

Publication Publication Date Title
JP5073494B2 (ja) 文書処理装置および文書処理方法
JP5020075B2 (ja) 文書処理装置
WO2006051715A1 (ja) 文書処理装置及び文書処理方法
WO2006085455A1 (ja) 文書処理装置および文書処理方法
WO2006051905A1 (ja) データ処理装置およびデータ処理方法
WO2006137565A1 (ja) 文書処理装置及び文書処理方法
WO2006051870A1 (ja) データ処理装置、文書処理装置及び文書処理方法
WO2006046666A1 (ja) 文書処理装置および文書処理方法
WO2006051964A1 (ja) データ処理システム、データ処理方法、及び管理サーバ
WO2006051975A1 (ja) 文書処理装置
WO2006051713A1 (ja) 文書処理装置及び文書処理方法
WO2006051960A1 (ja) 文書処理装置及び文書処理方法
WO2006051969A1 (ja) 文書処理装置及び文書処理方法
WO2006051954A1 (ja) 文書処理装置及び文書処理方法
WO2006120926A1 (ja) 入力フォーム設計装置および入力フォーム設計方法
WO2006051904A1 (ja) データ処理装置およびデータ処理方法
WO2006051712A1 (ja) 文書処理装置及び文書処理方法
WO2006051716A1 (ja) 文書処理装置及び文書処理方法
WO2006051955A1 (ja) サーバ装置及び名前空間発行方法
WO2006051966A1 (ja) 文書管理装置及び文書管理方法
WO2006051959A1 (ja) 文書処理装置及び文書処理方法
WO2006051721A1 (ja) 文書処理装置及び文書処理方法
WO2006046668A1 (ja) 文書処理装置および文書処理方法
WO2007007529A1 (ja) 文書処理装置および文書処理モジュール
WO2006051972A1 (ja) データ処理装置、文書処理装置および文書処理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2007528290

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 11913602

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 06746168

Country of ref document: EP

Kind code of ref document: A1