CN101203848A - Document processing apparatus and document processing method - Google Patents

Abstract

The present invention provides techniques for appropriately processing documents structured using a markup language. The view template (78) operates with data in the document to provide a predetermined function. A prompting unit (72) prompts the user for available view templates (78). A receiving unit (74) receives an indication from a user to insert a view template (78) into a document. After the receiving unit (74) receives an instruction to insert the view template (78) into the document, the editing unit (76) inserts a component element (tag) for starting the view template at a position in the document where the instruction is inserted. The editing unit (76) also describes parameters and the like required for the operation of the view template in the document.

Description

Document processing device and document processing method

technical field

The present invention relates to document processing technology, in particular to a document processing device and method for processing documents described by markup language.

Background technique

In recent years, technology using the Internet has made remarkable progress, allowing us to access all kinds of information in the world. Previously, text-based web pages described in HTML were the mainstream. Now, however, infrastructure is advancing, and posting rich forms of expression such as images, music, and animations on web pages has become mainstream.

Furthermore, in addition to simply transmitting information on a web page, various functions can be realized by describing scripts and the like on the web page. For example, by controlling an application developed as an ActiveX control with the VB script language, various applications can be operated even on a web page.

Contents of the invention

The problem to be solved by the invention

However, since the inside of the ActiveX control itself is formed into a black box, it is impossible to implement an application in which the ActiveX controls are directly linked to each other and operated. In order to provide a more flexible, highly expandable and versatile application program development environment, the present invention conceives of a new technical idea of programming or scripting.

The present invention has been made in view of such a situation, and an object of the present invention is to provide a technique for appropriately processing data structured in a markup language.

Solution to the problem

In order to solve the above-mentioned problems, the document processing device according to the embodiment of the present invention includes: a document acquisition unit, which acquires a document described by a predetermined tag set; a processing system, which processes the tag set to which the constituent elements of the document belong, wherein, when the When a constituent element included in a document has pointer information pointing to other data contained in the document, the processing system operates referring to the data pointed to by the pointer information, and the processing system processes the constituent element The other data are used as reference data when belonging to the tag set.

The above pointer information can be described by xpath. The above pointer information may be clearly defined concept information. The above-mentioned document processing apparatus may further include an analyzing unit, when the above-mentioned pointer information is provided as the above-mentioned conceptual information, determines the data indicated by the above-mentioned pointer information according to the above-mentioned conceptual information.

When multiple constituent elements contain pointer information pointing to the same data source, multiple processing systems that process the tag sets to which each constituent element belongs can use the same data source as a shared memory.

The processing system above may further include a management unit, the management unit creates document object model data based on the document, so as to manage the document. The processing system refers to the data indicated by the pointer information through the interface provided by the management unit. When the document object model data is changed, the management unit notifies the processing system of the change, and upon receiving the notification that the document object model data is changed from the management unit, the processing system according to The modified execution process.

A destination receiving notification from the management unit that the document object model data has been changed is specified in the form of clearly defined concept information. In addition, the document processing apparatus further includes an analysis unit that, when the target party receiving the notification specified in the form of concept information, receives a notification from the management unit that the object model data has been changed, the analysis unit A target party to be actually notified is identified based on the conceptual information.

The above-mentioned constituent elements may also include parameter information necessary for the operation of the above-mentioned processing system. The above parameter information may include clearly defined semantic type information related to the data pointed to by the pointer information. The above-mentioned parameter information is clearly defined conceptual information. When the above-mentioned parameter information contains clearly defined semantic type information, the above-mentioned analysis unit can refer to the above-mentioned semantic type information to determine from the above-mentioned concept information that the above-mentioned pointer information points to The data.

Another embodiment of the present invention is a document processing device. The device includes: a receiving unit, configured to receive an instruction to attach a processing module to a document, the processing module using data in the document to embody a predetermined function; and an editing unit, when receiving the instruction, to insert into the document a There is a constituent element of pointer information pointing to data used by the processing module.

The apparatus may further include: an activation unit that activates a processing module that processes the constituent elements inserted into the document. The editing unit may insert parameters necessary for the operation of the processing module into the document.

Still another embodiment of the present invention relates to a document processing device. The document processing device includes: a document acquisition unit, which acquires a document described by a predetermined tag set; a first processing system, which processes the tag set to which the constituent elements of the document belong; a second processing system, which uses data in the document to provide a predetermined function, wherein, when receiving an instruction to switch the processing system processing the constituent elements of the document from the first processing system to the second processing system, the second processing system refers to the a file of information on data to be used, to identify the data to be used, and to provide the predetermined function using the identified data.

The second processing system may receive the information for determining the usage data from a user and create the file if the file does not exist.

In addition, it should be understood that any combination of the above-mentioned components or expression forms achieved by modifying the method, device, system, etc. of the present invention is equivalent to the embodiment of the present invention.

The effect of the invention

According to the present invention, it is possible to provide a technique for appropriately processing data structured using a markup language.

Description of drawings

FIG. 1 is a schematic diagram of the composition of a document processing device related to the premise technology;

Figure 2 shows an embodiment of an XML document processed by a document processing device;

Fig. 3 exemplarily shows that the XML document shown in Fig. 2 is mapped to a table described by HTML;

Fig. 4 (a) shows the embodiment that is used for mapping the XML document shown in Fig. 2 to the definition file of the table shown in Fig. 3;

Fig. 4 (b) shows the embodiment that is used for mapping the XML document shown in Fig. 2 to the definition file of the table shown in Fig. 3;

Fig. 5 shows the embodiment of the display screen that the XML document shown in Fig. 2 is mapped to HTML and displayed through the correspondence shown in Fig. 3;

Fig. 6 shows a graphical user interface that provides a definition file generation unit to a user for the user to create a definition file;

Fig. 7 shows another embodiment of the screen layout created by the definition file generating unit;

FIG. 8 shows an embodiment of an editing screen of an XML document provided by a document processing device;

Fig. 9 shows another embodiment of an XML document edited by a document processing device;

Figure 10 shows an embodiment of a screen display displaying the document shown in Figure 9;

Figure 11(a) shows the basic composition of the document processing system;

Figure 11(b) shows a general block diagram of the document processing system;

Figure 11(c) shows an overall block diagram of the document processing system;

Figure 12 shows the details of the document management unit;

Figure 13 shows the details of the vocabulary connection subsystem;

Figure 14 shows the details of the relationship between the program call unit and other components;

Figure 15 shows the structural details of the application program service loaded into the program call unit;

Figure 16 shows the details of the core components;

Figure 17 shows the details of the document management unit;

Figure 18 shows the details of the undo frame and the undo command;

Figure 19 shows the operation of loading a document in the document processing system;

Figure 20 shows an embodiment of a document and its presentation;

Figure 21 shows the relationship between models and controllers;

Figure 22 shows the details of the plug-in subsystem, vocabulary connections and connectors;

Figure 23 shows an example of a VCD file;

Figure 24 illustrates operations for loading a compound document into a document processing system;

Figure 25 illustrates operations for loading a compound document into a document processing system;

Figure 26 illustrates operations for loading a compound document into a document processing system;

Figure 27 illustrates operations for loading a compound document into a document processing system;

Figure 28 illustrates operations for loading a compound document into a document processing system;

Figure 29 shows the command flow;

Figure 30 (a), (b) and (c) have shown the example of the data structure of the XML document of processing target;

Figure 31 (a) and (b) have shown the embodiment of pointer information;

Figures 32(a) and (b) illustrate the mechanism for issuing notifications that the DOM has changed;

FIG. 33 shows the composition of the document processing apparatus according to the first embodiment of the present invention;

Fig. 34 shows an editing screen of a document;

Figure 35 shows the edit screen with the View Template for Scheduling activated;

FIG. 36 shows the configuration of a document processing apparatus according to the second embodiment;

Figure 37 shows an embodiment of an XML document inserted with attributes of an AVC component;

Fig. 38 shows the processing operation of the document processing method according to the second embodiment of the present invention;

FIG. 39 shows an embodiment of a screen displayed by an AVC component;

FIG. 40 shows the composition of a document processing apparatus according to a third embodiment of the present invention;

FIG. 41 shows processing operations of the document processing method according to the third embodiment of the present invention.

Symbol Description

20 Document processing device 22 Main control unit 24 Editing unit

27 Concept Analysis Engine 28 Notification Unit 30 DOM Unit

32 DOM providing unit 34 DOM generating unit 36 Output unit

40CSS unit 42CSS analysis unit 44CSS provision unit

46 presentation units 50 HTML units 52, 62 control units

54, 64 editing unit 56, 66 display unit 60SVG unit

70 view template control unit 71 acquisition unit 72 prompt unit

74 receiving unit 76 editing unit 78 view template

80VC unit 82 Mapping unit 84 Definition file acquisition unit

86 Definition file generation unit 100 Document processing device

3000AVC control unit 3002AVC attribute setting unit

3004 AVC attribute generating unit 3006 Definition file generating unit

3010 AVC component for displaying tables 3020 AVC component for displaying graphs

3030 AVC components for displaying UI components 3040 AVC components for displaying trees

Detailed ways

(prerequisite technology)

FIG. 1 shows the structure of a document processing apparatus 20 related to the premise technology. The document processing device 20 processes a structured document in which data is divided into a plurality of constituent elements having a hierarchical structure. In this premise technology, the processing of an XML document as a structured document is taken as an example for illustration. The document processing device 20 includes a main control unit 22, an editing unit 24, a DOM (Document Object Module) unit 30, a CSS (Cascading Style Sheet) unit 40, an HTML (Hypertext Markup Language) unit 50, and an SVG (Scalable Vector Graphics) unit 60 and a VC (Vocabulary Connection) unit 80 as an example of a transformation unit. In terms of hardware components, these unit structures can be realized by a CPU, a memory, a program loaded into the memory, etc. of any computer. Here, the functional modules realized by their cooperation are described. Therefore, those skilled in the art can understand that these functional modules can be implemented in various forms such as hardware only, software only, or a combination of the two.

The main control unit 22 provides the loading of plug-ins or provides a framework for executing commands. Editing unit 24 provides a framework for editing XML documents. The document display and editing functions in the document processing device 20 are realized through plug-ins, and the necessary plug-ins are loaded through the main control unit 22 or the editing unit 24 according to the types of documents to be processed. The main control unit 22 or the editing unit 24 determines which or which vocabulary describes the content of the XML document to be processed by referring to the namespace of the XML document to be processed, and loads the corresponding display and Editing plug-in to perform display and editing. For example, in the document processing device 20, an HTML unit 50 for displaying and editing an HTML document, an SVG unit 60 for displaying and editing an SVG document, and the like are realized as a display system and editing system for each vocabulary (tag set). A plug-in of the system to load the HTML unit 50 when editing an HTML document, and load the SVG unit 60 when editing an SVG document. As will be described below, when a compound document including both HTML and SVG components is to be processed, both the HTML unit 50 and the SVG unit 60 are loaded.

By realizing the above structure, since the user can select and install only necessary functions, and then add or delete appropriate functions, the storage area of the recording medium (such as a hard disk) can be effectively used, and the memory area can be avoided when the program is executed. waste. In addition, since this structure is conducive to performance expansion, developers themselves can process new vocabularies in the form of plug-ins, thereby facilitating the development process; users can also easily add functions at a low cost by adding plug-ins.

The editing unit 24 receives an event of an editing instruction from the user through the user interface. The editing unit 24 notifies an appropriate plug-in or the like of the event, and controls processing including redo (redo) and undo (undo) of the event.

The DOM unit 30 includes a DOM providing unit 32 , a DOM generating unit 34 , and an output unit 36 . The DOM element 30 implements functions conforming to the Document Object Model (DOM) defined to provide access methods for manipulating data in the form of an XML document. The DOM providing unit 32 is an implementation of a DOM that satisfies the interface defined by the editing unit 24 . The DOM generation unit 34 creates a DOM tree from the XML document. As will be described below, when the XML document to be processed is mapped to other vocabularies by the VC unit 80, a source tree corresponding to the XML document in the mapping source and an object tree corresponding to the XML document in the mapping destination are created. Tree. For example, at the end of editing, the output unit 36 outputs a DOM tree as an XML document.

The CSS unit 40 provides a display function conforming to CSS, and includes a CSS analysis unit 42 , a CSS providing unit 44 and a presentation unit 46 . The CSS analysis unit 42 has an analysis function for analyzing CSS syntax. The CSS providing unit 44 is an implementation of a CSS object, and performs cascading processing of CSS on a DOM tree. The rendering unit 46 is a rendering engine of CSS, and is used to display a document described in a vocabulary such as HTML set with CSS.

The HTML unit 50 displays or edits documents described in HTML. The SVG unit 60 displays or edits documents described in SVG. These display/editing systems are implemented in the form of plug-ins, and each system includes a display unit (also referred to herein as "Canvas)" 56, 66 for displaying documents, and a control unit for sending and receiving events including editing commands. (also referred to herein as an "Editlet") 52, 62, and an editing unit (also referred to herein as a "zone)" 54, 64 that edits the DOM upon receipt of an editing command. When the control unit 52 or 62 receives an editing command for the DOM tree from an external source, the editing unit 54 or 64 modifies the DOM tree and the display unit 56 or 66 updates the display. These units have a structure similar to the frame called MVC (Model-View-Controllers, Model-View-Controller), usually, the display units 56 and 66 correspond to "View (View)", and the control units 52 and 62 corresponds to "Controller", and the editing units 54 and 64 and DOM entities correspond to "Model". In the document processing apparatus 20 of the present premise technology, not only the XML document can be edited in the tree view display format, but also the editing can be completed according to the corresponding vocabulary. For example, the HTML unit 50 provides a user interface that can be used to edit HTML documents in a way similar to a Word processor, and the SVG unit 60 also provides a user interface that can be used to edit SVG documents in a way similar to an image drawing tool. The user interface for editing documents.

The VC unit 80 includes a mapping unit 82 , a definition file acquisition unit 84 , and a definition file generation unit 86 . The VC unit 80 can map a document described with a certain vocabulary to another given vocabulary, thereby providing a framework capable of displaying or editing a document through a display or editing plug-in corresponding to the mapped vocabulary. In this premise technology, this function is called VC (Vocabulary Connection, vocabulary connection). The definition file acquisition unit 84 acquires a script file describing a mapping definition. This definition file describes the correspondence (connection) between nodes on a node-by-node basis. At this time, it can be specified whether the element value or attribute value of each node can be edited. Operation expressions using element values or attribute values of nodes can also be described. These functions will be described later. The mapping unit 82 causes the DOM generation unit 34 to create the destination tree by referring to the script file that the VC definition file acquisition unit 84 has acquired, so as to manage the correspondence between the source tree and the destination tree. The definition file generation unit 86 provides a graphical user interface for the user to create a definition file.

The VC unit 80 monitors the connection between the source tree and the destination tree. When the VC unit 80 receives editing instructions from the user through the user interface provided by the plug-in responsible for display, it first modifies the relevant nodes of the source tree. Accordingly, DOM unit 30 will emit a change event indicating that the source tree has been modified. Then, the VC unit 80 receives the change event, and modifies the node corresponding to the modified node in the destination tree, so that the modification of the destination tree and the source tree are synchronized. When a plug-in for displaying/editing an object tree (such as the HTML unit 50) receives a change event indicating that the object tree has been modified, the plug-in updates the display by referring to the modified object tree. By performing the above-described structure of converting a vocabulary into another main vocabulary, even if a document is described with a partial vocabulary used by a small number of users, the document can be displayed and an editing environment provided therefor.

The operation of displaying or editing a document by the document processing apparatus 20 will be described below. When the document processing apparatus 20 loads a document to be processed, the DOM generation unit 34 creates a DOM tree from the XML document. The main control unit 22 or the editing unit 24 discriminates the vocabulary describing the XML document by referring to the namespace of the XML document to be processed. If a plug-in corresponding to a vocabulary is installed in the document processing apparatus 20, the plug-in is loaded to display/edit the document. On the other hand, if the plugin is not installed there, a check is made to see if there is a mapped definition file. If there is a definition file, the definition file acquisition unit 84 acquires the definition file, and creates a purpose tree according to the definition so that a document can be displayed/edited by a plug-in corresponding to a vocabulary to be mapped. If the document is a compound document including a plurality of vocabularies, as described later, the relevant part of the document is displayed/edited by a plug-in corresponding to each vocabulary. If no definition file exists, the source or tree structure of the document is shown and edited in the display.

Fig. 2 shows an example of an XML document as a processing object. This XML document is used to manage student grade data. The constituent element "grade" which is the upper node of the XML document includes a plurality of elements "student" set for each student under "grade". The constituent element "Shengtu" has an attribute value "Namae", and sub-elements "National Language" (Japanese), "Mathematics", "Science", and "Society" (Social Science). The attribute value "first name" stores the student's first and last name. The constituent elements "national language", "mathematics", "science" and "society" respectively store grades of Japanese, mathematics, natural science and social science. For example, the grades of a student named "A" are: "90" in Japanese, "50" in mathematics, "75" in natural science, and "60" in social science. Hereinafter, the vocabulary (label set) used in this document is referred to as "score management vocabulary".

Since the document processing device 20 of the present premise technology does not have a plug-in corresponding to the display and/or editing of the performance management vocabulary, it will be displayed using the VC function described above without using other display methods of source display and tree display the document. That is, by preparing a definition file, the grade management vocabulary can be mapped to another vocabulary that already has a plug-in, such as HTML or SVG. The following description is based on the assumption that the definition file already exists, but the user interface necessary for the user to create the definition file will be described later.

FIG. 3 shows an example of mapping the XML document shown in FIG. 2 into a table described in HTML. In the example shown in FIG. 3, the "student" node described in the grade management vocabulary is made to correspond to the row ("TR" node) of the table ("TABLE" node) described in HTML. The first column of each row corresponds to the attribute value "Name Front", the second column corresponds to the element value of the "Mandarin" node, the third column corresponds to the element value of the "Mathematics" node, and the fourth column corresponds to the "Science" node corresponds to the element value of the , while the fifth column corresponds to the element value of the "society" node. Therefore, the XML document shown in FIG. 2 can be displayed in the list format of HTML. Furthermore, these attribute values and element values are designated as editable so that the user can edit these values on a screen displayed with HTML using the editing function of the HTML unit 50 . In the sixth column, an operation expression for calculating the weighted average of scores of Japanese, mathematics, natural science, and social science is specified, and the average value of the scores of each student is displayed. In this way, more flexible display is accomplished by specifying operation expressions in the definition file, thereby improving user's convenience when editing. In addition, editing of the sixth column is specified as disallowed, so that editing of the average itself alone is not possible. Therefore, in the mapping definition, it is possible to designate editable or non-editable to avoid possible erroneous operations by the user.

4(a) and 4(b) show examples of definition files to map the XML document shown in FIG. 2 into the table shown in FIG. The definition file is described by a script language defined for use with the definition file. In the examples shown in Figures 4(a) and 4(b), “shengtuのappend” and “shengtuのcut” are defined as commands, and involve the operation of inserting the node “shengtu” into the source tree and inserting the node "Students" operations that are removed from the source tree. The definition file describes in the form of a template that titles such as "Name Front" and "Guoyu" are displayed in the first row of the table, and the content of the node "Shengtu" is displayed in the second row and subsequent rows. In the template showing the contents of the node "Student", items containing "text-of" indicate that editing is allowed, while items containing "value-of" indicate that editing is not allowed. In the rows showing the content of the node "Shengtu", the operation expression "(src: Mandarin + src: mathematics + src: science + src: society) div 4" is described in the sixth column. This is meant to display the average of student grades.

FIG. 5 shows an example of the display screen when the XML document described by the performance management vocabulary shown in FIG. 2 is mapped to HTML using the correspondence shown in FIG. 3 so as to be displayed on the display screen. Displayed from left to right in each row of Table 90 are the names, Japanese scores, math scores, natural science scores, social science scores and their average values of each student. The user can edit the XML document on this screen. For example, when the value in the third column of the second row becomes "70", the value of the element corresponding to the node in the source tree (that is, the math score of student "B") becomes "70". At this time, in order to make the target tree consistent with the source tree, the corresponding part of the target tree is changed accordingly, so that the HTML unit 50 can update the display according to the changed target tree. Thus, student "B"'s math score becomes "70" and the average accordingly becomes "55".

On the screen shown in FIG. 5, commands such as "addition of students" and "deletion of students" are displayed as menus, as defined in the definition files shown in FIGS. 4(a), (b). When the user selects one of these commands, a node "Student" is added to or removed from the source tree. In this way, with the document processing apparatus 20 according to the present premise technology, not only the element values of the components in the end of the hierarchical structure but also the hierarchical structure can be edited. The editing functions with the above tree structure can be presented to the user in the form of commands. Furthermore, the commands to add or delete rows in the table may be related, for example, to the operation of adding or deleting the node "Student". Commands embedded in other vocabularies can be presented to the user. This form can be used as an input template so that performance data for new students can be added in a fill-in-the-blank fashion. As described above, while using the display/edit function of the HTML unit 50, the document described in the grade management vocabulary can be edited by the VC function.

FIG. 6 shows an example of a graphical user interface presented to the user by the definition file generating unit 86 to enable the user to create a definition file. The XML document to be mapped is displayed as a tree in the left area 91 of the screen. The screen layout of the mapped XML document is displayed in the right area 92 of the screen. The screen layout can be edited through the HTML unit 50, and the user determines and creates the screen layout for displaying the document in the right area 92 of the screen. Then, for example, a node to be mapped of the XML document displayed in the left area 91 of the screen is dragged and dropped into the HTML screen layout in the left area 91 of the screen using a pointing device such as a mouse to specify the mapping source The connection between the node at and the node at the destination of the map. For example, when "Mathematics" which is a child element of the element "Student" is placed at the intersection of the first row and the third column in Table 90 on the HTML screen, the "Mathematics" node and "TD" in the third column Connections are established between nodes. Each node is designated as editable or non-editable as such. In addition, arithmetic expressions can be embedded in the display. When screen editing is completed, the definition file generating unit 86 creates a definition file describing the layout of the screen and connections between nodes.

Browsers or editors have been developed that can handle major vocabularies such as XHTML (Extensible Hypertext Markup Language), MathML (Mathematical Markup Language), and SVG (Scalable Vector Graphics). However, it is impossible to develop a browser or an editor suitable for all documents described in self-created vocabularies, such as the documents shown in FIG. 2 . However, if definition files for mapping to other vocabularies are created as described above, documents described in self-created vocabularies can be displayed and/or edited using VC functions without constantly developing new browsers or editors.

FIG. 7 shows another example of the screen layout created by the definition file generating unit 86. As shown in FIG. In the example shown in FIG. 7, a table 90 and a pie chart 93 for displaying an XML document described in a grade management vocabulary are generated on the screen. The circular graph 93 is described in SVG. As will be discussed below, since the document processing apparatus 20 according to the present premise technology can process a compound document described in a plurality of vocabularies within a single XML document, as shown in this example, the table 90 described in HTML and A circular graph 93 described in SVG can be displayed on the same screen.

FIG. 8 shows an example of an editing screen for an XML document processed by the document processing apparatus 20. As shown in FIG. In the example shown in FIG. 8 , a single screen is divided into multiple areas, and the XML document to be processed is displayed in various display formats in each area. The source of the document is displayed in area 94 , the tree structure of the document is displayed in area 95 , and the table described in HTML shown in FIG. 5 is displayed in area 96 . The document can be edited in any of these areas, and when the user edits the contents of any of these areas, the source tree will be modified accordingly, so that the plug-in responsible for the display of each screen will update the screen to reflect the source Tree changes. In particular, the display unit of the plug-in responsible for displaying the corresponding editing screen is pre-registered as a listener for change events that provide notification that a change has occurred in the source tree. When the source tree is modified by any plug-in or VC unit 80, all display units displaying the edit screen receive one or more change events emitted and update the screen accordingly. At this time, if the plug-in is being displayed by the VC function, the VC unit 80 modifies the destination tree according to the modification of the source tree. Afterwards, the display unit of the plug-in modifies the screen by referring to the above-mentioned modified object tree.

For example, when the source display and the tree view display are implemented by dedicated plug-ins, the source display plug-in and the tree display plug-in achieve their display by directly referring to the source tree instead of utilizing the destination tree. In this case, the source display plugin and the tree display plugin update the screen by referring to the modified source tree when editing is done in any area of the screen. Likewise, the HTML unit 50 responsible for the display area 96 updates the screen by referring to the destination tree which has been modified according to the modification to the source tree.

Source display and tree display can also be realized by using the VC function. That is, for example, if HTML is used for the source and layout of the tree structure, the XML document can be mapped to HTML to be displayed by the HTML unit 50 . In this case, three destination trees will be created with source format, tree format, and table format. If editing is performed in any one of the three areas on the screen, the VC unit 80 modifies the source tree, and then modifies the three destination trees in source format, tree format, and table format respectively. Then, the HTML unit 50 updates the three areas of the screen by referring to these object trees.

In this way, documents are displayed in a plurality of display formats on a single screen, thereby improving user convenience. For example, a user can display and edit a document in a visually understandable format using a table 90 or the like while understanding the hierarchical structure of the document through source display or tree display. In the above-described embodiments, a single screen is divided into a plurality of display formats, which are displayed simultaneously. However, it is also possible to display a single display format on a single screen so that the display format can be switched by a user instruction. In this case, the main control unit 22 receives a request from the user for switching the display format, and then instructs each plug-in to perform display switching.

FIG. 9 shows another example of an XML document edited by the document processing apparatus 20. As shown in FIG. In the XML document shown in FIG. 9, an XHTML document containing a formula described in MathML is embedded in a "foreignObject" tag of an SVG document. In this case, the editing unit 24 assigns or assigns the rendering task to an appropriate display system by referring to the namespace. In the embodiment shown in FIG. 9, editing unit 24 first causes SVG unit 60 to draw a rectangle, and then makes HTML unit 50 to draw an XHTML document. Furthermore, the editing unit 24 causes a MathML unit (not shown) to draw a formula. In this way, compound documents containing a plurality of vocabularies are properly displayed. Figure 10 shows the display results.

During editing of the document, the menu to be displayed can be switched according to the position of the cursor. That is, when the cursor is located in an area where an SVG document is displayed, a menu provided by the SVG unit 60, or a command defined in a definition file for mapping the SVG document is displayed. When the cursor is located in an area where an XHTML document is displayed, a menu provided by the HTML unit 50, or a command defined in a definition file for mapping the XHTML document is displayed. Therefore, an appropriate user interface can be provided according to the editing position.

If no suitable plug-in or mapping definition for a vocabulary exists in the compound document, the parts described with that vocabulary can be displayed in source or tree format. In conventional practice, when a compound document with other documents embedded in a document is to be opened, their contents cannot be displayed if no application program capable of displaying the embedded document is installed. However, according to the present premise technology, even if there is no application program for display, an XML document composed of text data can be displayed in a source or tree format, thereby being able to specify its content. This is a characteristic of text-based XML documents or similar.

Another beneficial aspect of describing data in a text-based language is, for example, that parts of data described in other vocabularies in the same document can be referenced by another document described in a certain vocabulary in the compound document. In addition, when searching in the document, character strings embedded in images such as SVG can also be searched.

In a document described by a certain vocabulary, tags of other vocabulary can be used. Although the XML document is usually not valid, it can be processed as a valid XML document as long as it is well-formed. In this case, the inserted tags belonging to other vocabularies can be mapped using the definition file. For example, in an XHTML document, tags such as "important" and "most important" can be used to display parts around these tags in an emphasized manner, or these tags can be sorted in order of importance for corresponding display.

When a user edits a document on the editing screen shown in FIG. 10, the plug-in or VC unit 80 responsible for processing the edited portion modifies the source tree. Ability to register listeners for change events for each node in the source tree. Typically, the display unit or VC unit 80 of the plug-in corresponding to the vocabulary to which each node belongs is registered as a listener. When the source tree is modified, the DOM providing unit 32 explores from the modified node to a higher level. If there is a registered listener, the DOM providing unit 32 sends a change event to the listener. For example, referring to the document as shown in FIG. 9, if a node located below the <html> node is modified, the change event is notified to the HTML unit 50 registered as a listener for the <html> node. At the same moment, the change event is notified to the SVG element 60 registered as a listener in the <svg> node located above the <html> node. At this time, the HTML unit 50 updates the display by referring to the modified source tree. Since the nodes belonging to the vocabulary of SVG unit 60 itself have not been modified, SVG unit 60 can ignore this change event.

Depending on the edited content, the overall layout may change as the HTML unit 50 modifies the display. In this case, the layout of each display area for each widget will be updated by the component managing the screen layout (eg the widget responsible for displaying the highest node). For example, when the area displayed by the HTML unit 50 becomes larger than before, the HTML unit 50 first draws the area that the HTML unit 50 itself is responsible for, and then determines the size of the display area. Then, the size of the display area is notified to the component that manages the screen layout to request an update to the layout. As soon as the component responsible for the screen layout receives this notification, it rearranges the display area for each widget. Accordingly, the display of the edited portion is updated appropriately, and the overall screen layout is updated.

Next, the functional configuration of the document processing device 20 that realizes the premise technology will be further described in detail. In the following description, class names and the like are described using English names.

A. Summary

Since the advent of the Internet, the number of documents handled and managed by users has increased roughly exponentially. The Web (World Wide Web: World Wide Web), which forms the core of the Internet, has become a large container for receiving these document data. In addition to documents, the Web also provides information retrieval systems for these documents. These documents are usually described by a markup language. As a simple and commonly used example of a markup language, HTML (HyperText Markup Language: Hypertext Markup Language) is one of them. Such documents also include links to other documents recorded elsewhere on the Web. XML (eXtensible Markup Language: Extensible Markup Language) is a more highly popular markup language. A simple browser for accessing and viewing Web documents is developed by an object-oriented programming language like Java (registered trademark).

Documents described by markup languages are usually represented in the form of tree data structures in browsers or other applications. This structure is equivalent to a tree of the result of parsing a document. DOM (Document Object Model: Document Object Model) is a well-known tree-based data structure model for representing and manipulating documents. DOM provides representations for collections of objects including HTML or XML documents, etc. The DOM consists of two basic components, a standard model of how objects representing components within a document are connected together, and a standard interface for accessing or manipulating these objects.

A developer of an application can support the DOM as an interface with its own data structure or an API (Application Program Interface: Application Programming Interface). On the other hand, developers of applications that create documents can use the DOM's standard interface rather than the specific interface of its own API. Therefore, the ability of DOM to provide a standard interface effectively facilitates the sharing of documents in various environments, especially on the Web. There are several versions of the DOM definition, which are used according to different programming environments and applications.

A DOM tree is a hierarchical representation of a document based on the content of the corresponding DOM. The DOM tree includes a "root" and one or more "nodes" that grow from the root. The root sometimes refers to the entire document. Intermediate nodes may represent elements such as tables and the rows and columns in tables. The "leaves" of the DOM tree usually represent data, such as text or images that cannot be further decomposed. Each node of the DOM tree may also be associated with attributes describing parameters such as font, size, color, index, etc. of the element represented by the node.

Although HTML is a language generally used for authoring documents, it is a language for formatting and layout rather than a language for describing data. A node representing a DOM tree of an HTML document is an element previously defined as a formatting tag of HTML. In general, query formatting of data in HTML documents is difficult on many occasions because HTML does not provide functionality for elaboration of data or tagging/annotating data.

The goal of web designers is to enable documents on the web to be queried or processed by software applications. Regardless of the display method, as long as it is a hierarchically structured language, query processing can be performed in the same way. Markup languages such as XML (eXtensible Markup Language) can provide such features.

As we all know, contrary to HTML, the advantage of XML is that the designer of the document can use freely definable "tags" to mark the data elements. Such data elements may be structured hierarchically. Furthermore, an XML document can contain a document type definition, which describes the "syntax" of the tags used within the document and their interrelationships. In order to define a display method of a structured XML document, CSS (Cascading Style Sheet: Cascading Style Sheet) or XSL (XML StyleLanguage: Extensible Markup Language Style Language) is used. Additional information about DOM, HTML, XML, CSS, XSL, and their related language features is also available from the Web. (eg http://www.w3.org/TR/)

XPath provides a common syntax and semantics for specifying the location of parts of an XML document. As an example of functionality, is traversal (movement) of a DOM tree corresponding to an XML document. This provides basic functionality for manipulating strings, numbers, and Boolean characters associated with various representations of XML documents. XPath is not the syntax expressed by XML documents (such as the syntax of which line or character when viewed as text), but operates in an abstract and logical structure such as a DOM tree. By using XPath, for example, it is possible to navigate through a hierarchical structure within the DOM tree of an XML document. In addition to its use for addressing, XPath was designed to test whether a node in a DOM tree matches a pattern. Details involving XPath can be found at http://www.w3.org/TR/XPath.

It is desired to have an effective document processing system that can utilize the known advantages and characteristics of XML, process documents described by markup languages (such as XML), and provide a friendly user interface for creating and modifying documents.

Some of the configurations of the system described here will be described using a well-known GUI (Graphical User Interface: Graphical User Interface) paradigm called MVC (Model-View-Controller: Model-View-Controller). The MVC paradigm decomposes an application or part of an application's interface into three parts, namely, the model, the view, and the controller. MVC was originally developed to distribute traditional input, processing, and output tasks to GUI areas.

Input -> Processing -> Output

Controller -> Model -> View

According to the MVC paradigm, modeling of the outside world, visual feedback to the user, and user input are handled separately through Model (M), View (V) and Controller (C) objects. The controller operates to interpret input such as the user's mouse and keyboard input, and to map these user actions into commands sent to the model and/or view to effect appropriate changes. A model functions to manage one or more data elements, respond to queries about its state, and respond to indications to change state. Views operate to manage a rectangular area of display and have the ability to present data to the user through a combination of graphics and text.

B. General configuration of the document processing system

Embodiments of the document processing system will be clearly described with reference to FIGS. 11-29.

FIG. 11( a ) illustrates a configuration structure including basic functions according to the prior art capable of providing a document processing system to be described below. Apparatus 10 includes a processor 11 in the form of a CPU or microprocessor or the like connected to a memory 12 via a communication path 13 . Memory 12 may be in any form of ROM and/or RAM that can be used now or in the future. The communication path 13 is provided as a typical bus. Input and output interfaces 16 for user input devices 14 such as mouse, keyboard and voice recognition system, and display device 15 (or other user interfaces) are also connected to the bus used for communication between processor 11 and memory 12 . This structure may be an independent form, or may be a networked form in which a plurality of terminals and one or more servers are connected, or may be constructed in any known manner. The invention is not limited by the configuration of these components, their centralized or distributed architecture, or the manner in which the various components communicate.

Furthermore, the present system and the embodiments discussed herein will be discussed as examples comprising several components and subcomponents that provide various functionality. In order to provide desired functions, these components and subcomponents may be a combination of hardware and software, or may be realized only by hardware or only by software. Also, hardware, software, and combinations thereof can be implemented by general purpose computing devices, special purpose hardware, or combinations thereof. Accordingly, a component or sub-component is constituted including a general/special purpose computing device executing specific software for providing the functionality of the component or sub-component.

Fig. 11(b) shows an overall block diagram of an example of a document processing system. Documents are created and edited in such document processing systems. These documents (such as XML, etc.) can be expressed in any language that has markup language features. Also, terms and headings for specific components and subcomponents have been created for convenience. However, these should not be viewed as limitations on the scope of the general teachings disclosed herein.

A document processing system can be viewed as having two basic components. One component is the "execution environment" 101, which is the environment in which the document processing system operates. For example, the execution environment supports not only the user but also the system in the processing and management of documents, providing basic utility and functionality. The second component is "applications" 102, which consists of application programs running in the execution environment. These applications include the document itself and its various representations.

1. Execution environment

A key component of the execution environment 101 is a program invoker (ProgramInvoker, ie, a program launching unit) 103 . The program invoker 103 is a basic program accessed for starting the document processing system. For example, when a user logs in and starts the document processing system, the program invoker 103 is executed. The program invoker 103 can, for example, read and execute functions added as plug-ins to the document processing system, start and run application programs, and read attributes related to documents. The function of the program caller 103 is not limited thereto.

When the user wishes to start an application program planned to run in the execution environment, the program invoker 103 finds and starts the application program, and then executes the application program.

Several components such as a plug-in subsystem 104 , a command subsystem 105 , and a resource module 109 are connected to the program invoker 103 . These constitutions will be described in more detail later.

a) Plug-in subsystem

The plug-in subsystem 104 enables highly flexible and efficient addition of functionality to the document processing system. Plug-in subsystem 104 may also be used to modify and remove functionality present in the document processing system. In addition, various functions can be added or modified using the plug-in subsystem. For example, an editing function (Editlet: editing unit) may be added to play a role of supporting presentation of a document on a screen. The editing plugin also supports editing of vocabularies added to the system.

The plug-in subsystem 104 includes a service broker (Service Broker: service broker unit) 1041 . The service broker 1041 acts as an intermediary for the services added to the document processing system by managing the plug-ins added to the document processing system.

Each desired functionality is added to the system in the form of a Service 1042 . Available types of service 1042 include but are not limited to: application program (Application) service, district factory (ZoneFactory, i.e. district generating unit) service, Editlet (editing unit) service, command factory (CommandFactory: command generating unit) service, connection xpath ( ConnectXPath: XPath management unit) service, CSS calculation (CSSComputation: CSS calculation unit) service, etc. These services and their relationship to the rest of the system are described in detail later to better understand the document processing system.

The relationship between plugins and services is described below. A plug-in is a unit that may include one or more service providers (ServiceProvider: service providing unit). Each service provider has one or more classes of services associated with it. For example, more than one service can be added to the system by using a single plug-in with an appropriate software application, thereby adding corresponding functionality to the system.

b) command subsystem

Command subsystem 105 is used to execute commands in the form of commands related to the processing of documents. Users can perform operations on documents by executing a series of instructions. For example, by issuing an instruction in the form of a command, the user edits the XML DOM tree corresponding to the XML document in the document processing system to process the XML document. These commands may be entered using keyboard keystrokes, mouse clicks, or other valid user interface actions. Sometimes, more than one instruction can be executed by one command. In this case, these instructions are packaged (contained) into one command and executed consecutively. For example, a user wants to replace a wrong word with a correct word. In this case, the first command can be used to find the wrong word in the document, the second command can be used to delete the wrong word, and the third command can be used to enter the correct word. These three commands can be packaged into one command.

Commands may have associated functions, such as an "undo" function described in detail below. These functions can be assigned to several base classes used to create objects.

A key component of the command subsystem 105 is a command invoker (CommandInvoker, ie, a command initiating unit) 1051, which is operable to selectively provide and execute commands. Although only one command invoker is shown in FIG. 11(b), more than one command invoker may be used and more than one command may be executed simultaneously. Command Invoker 1051 maintains the functions and classes needed to execute commands. In operation, commands 1052 are placed in queue 1053 to be executed. The command invoker creates command threads that execute continuously. If there is no command being executed in the command invoker, the command 1052 to be executed is executed by the command invoker 1051 . The new command is placed at the end of the command queue 1053 if the command invoker is executing a command. However, for each command invoker 1051, only one command is executed at a time. If the specified command fails to execute, the command invoker 1051 will perform exception handling.

Types of commands that can be executed by Command Invoker (CommandInvoker) 1051 include, but are not limited to: Undoable Command (UndoableCommand) 1054 , Asynchronous Command (AsynchronousCommand) 1055 , and Vocabulary Connection Command (VCCommand) 1056 . Undoable commands 1054 are those commands whose results can be undone if the user so desires. Examples of undoable commands are: cut, copy, insert text, etc. In operation, when a user selects a portion of a document and applies a cut command to that portion, the cut portion can be returned to its uncut state, if desired, by using an undoable command.

The vocabulary connection command 1056 is loaded into a vocabulary connection descriptor (Vocabulary Connection Descriptor: VCD) script file. The vocabulary connection command 1056 is a user-specified command that can be defined by a programmer. Commands may be a combination of more abstract commands such as adding XML fragments, removing XML fragments, and setting attributes. These commands relate specifically to editing documents.

The asynchronous command 1055 is a system-based command for loading or saving a document, and is executed asynchronously, unlike an undoable command or a word link command. Since asynchronous commands are not undoable commands, the results of their execution cannot be cancelled.

c) resources

Resources 109 are objects that provide certain functionality to various classes. For example, string resources, icons, and default keybindings are examples of resources used in the system.

2. Application components

The application program component 102, which is the second main feature of the document processing system, runs in the execution environment 101. Application components 102 include actual documents and various logical and physical representations within the system. Application components 102 also include system components used to manage documents. The application component 102 further includes a user application (UserApplication) 106 , an application core 108 , a user interface 107 and a core component (CoreComponent) 110 .

a) User application

A user application 106 is loaded into the system along with a program invoker 103 . User applications 106 are the "glue" that holds together the document, its various representations, and the user interface required to interact with the document. For example, a user may wish to create a set of documents as part of a project. Once these documents are loaded, the appropriate representations for the documents will be created. User interface functions are added as part of the user application 106 . In other words, the user application 106 maintains both representations of documents and forms of documents that enable users to interact with documents that form part of a project. Once the user application 106 has been created, the user can simply load the user application 106 into the execution environment whenever the user wishes to interact with documents forming part of the project.

b) Core components

The core component (CoreComponent) 110 provides a method for sharing documents between multiple panes (Pane). As described later, panes display the DOM tree and handle the physical layout of the screen. For example, a physical screen includes a plurality of panes within the screen that describe pieces of information. In practice, the documents seen by the user on the screen may be displayed in one or more panes. Also, two different documents can appear in two different panes on the screen.

As shown in FIG. 11(c), the physical layout of the screen also has a tree form. Therefore, a pane can be implemented as a root pane (RootPane) 1084 or as a subpane (SubPane) 1085 . A root pane 1084 is the pane at the root of the pane tree, and a child pane 1085 is any pane other than the root pane 1084 .

The core component 110 also provides fonts, and serves as a source of toolkits and the like for various functional operations of the document. One example of a task performed by core component 110 is moving a mouse cursor between multiple panes. As another example of a task being performed, mark a portion of a document in one pane and copy it to another pane containing a different document.

c) Application Core

As noted above, application components 102 consist of documents that are processed and managed by the system. These include various logical and physical representations of documents within the system. Application core 108 is a component of application component 102 . Its function is to hold the actual document and all the data within it. The application core 108 includes a document manager (DocumentManager: document management unit) 1081 and a document (Document) 1082 itself.

Aspects of the document manager 1081 will be described in detail subsequently. A document manager 1081 manages documents 1082 . The document manager 1081 is also connected to a root pane 1084 , a subpane 1085 , a clipboard (ClipBoard) utility 1087 , and a snapshot (SnapShot) utility 1088 . Clipboard utility 1087 provides a method for maintaining portions of a document that the user decides to add to the clipboard. For example, a user may wish to cut out a portion of a document and save it to a new document for viewing at a later time. In this case, the cut part is added to the clipboard.

Next, the snapshot utility 1088 will also be described. The snapshot utility 1088 is capable of remembering the current state of an application as it changes from one state to another.

d) User interface

Another component of the application component 102 is the user interface 107, which provides a way for the user to physically interact with the system. For example, a user interface is used for users to upload, delete, edit, and manage documents. The user interface includes a frame (Frame) 1071 , a menu bar (MenuBar) 1072 , a status bar (StatusBar) 1073 and a URL bar (URLBar) 1074 .

As is generally known, frame 1071 is considered the active area of the physical screen. Menu bar 1072 is the area of the screen that contains a menu of options for the user. The status bar 1073 is a screen area that displays the execution status of the application. URL field 1074 provides an area to enter a URL address for locating on the Internet.

C. Document Management and Related Data Structures

FIG. 12 shows details of the document manager 1081 . These include the data structures and components used to represent documents within document processing systems. For better understanding, the components described in this section will be illustrated using the Model-View-Controller (MVC) representation paradigm.

The document manager 1081 includes a document container (DocumentContainer) 203, which holds and accommodates all documents in the document processing system. Toolkit 201 coupled to document manager 1081 provides various tools used by document manager 1081 . For example, DOM Service (DOMService) is a tool provided by the toolkit 201 capable of providing all functions required to create, maintain and manage a DOM corresponding to a document. An IO manager (IOManager: input/output management unit) which is another tool provided by the toolkit 201 manages input to the system and output from the system, respectively. Likewise, a StreamHandler is a tool that handles uploading files in bitstream form. These tools form components of tool kit 201 , but are not specifically shown and assigned reference numerals in the figures.

Model (M) includes the DOM tree model 202 of the document, according to the MVC paradigm. As mentioned above, all documents are represented as DOM trees in the document processing system. Furthermore, documents also form part of the document container 203 .

1. DOM model and area

A DOM tree representing a document is a tree having nodes (Node) 2021 . A zone (Zone) 209 which is a subset of the DOM tree includes an area corresponding to one or more nodes inside the DOM tree. For example, only a portion of the document may appear on the screen, and the visible portion of the document may be described using a "zone" 209 . Zones are created, manipulated and processed using a plug-in called ZoneFactory (ZoneFactory: zone generation unit) 205 . Although a section represents a part of the DOM, it can also use more than one "namespace". As is known in the art, a namespace is a collection or collection of names that are unique within that namespace. In other words, the same name does not exist in a namespace.

2. "Aspects" and their relationship to districts

Facet 2022 is another component within the Model (M) part of the MVC paradigm. It is used to edit nodes in the zone. "Aspects" 2022 organize access to the DOM using executable procedures (programs) that do not affect the content of the zone itself. As will be explained below, these procedures perform important and useful operations related to nodes.

Each node has a corresponding "facet". By utilizing "aspects" to perform operations instead of directly operating on nodes in the DOM, the integrity of the DOM is ensured. Otherwise, if operations are performed directly on nodes, several plugins may make changes to the DOM at the same time, causing inconsistent results.

Although the DOM standard constructed by W3C defines a standard interface for operating nodes, in fact, since there are specific operations for each vocabulary or each node, it is preferable to prepare these operations as APIs. The document processing system provides specific APIs to each node in the form of "aspects", and is attached to each node. Accordingly, a useful API conforming to the DOM standard can be provided. Furthermore, by adding a specific API later on the standard DOM instead of implementing a specific DOM for each vocabulary, various vocabularies can be uniformly processed, and a mixed document composed of various vocabularies in any combination can be properly processed.

A vocabulary is a collection of tags (eg XML tags) belonging to a namespace. As mentioned above, a namespace has a unique set of names (in this case labels). Vocabularies represent subtrees of the DOM tree that represent XML documents. This subtree includes Zones. In a particular embodiment, the boundaries of a tag set are defined by regions. Zones 209 are created using a service called "Zone Factory" 205 . As mentioned above, region 209 is an internal representation of a portion of the DOM tree representing the document. In order to provide access to the aforementioned parts of the document, a logical representation is required. This logical representation tells the computer how to logically display the document on the screen. Canvas (Canvas) 210 is a service operable to provide a logical layout corresponding to a zone.

On the other hand, the pane 211 is a physical screen layout corresponding to the logical layout provided by the canvas 210 . In fact, the user just looks at the document presented on the display screen in the form of characters and pictures. Therefore, documents must be presented on the screen through processing for drawing characters and pictures on the screen. Documents are rendered on-screen by canvas 210 according to the physical layout provided by pane 211 .

Canvas 210 corresponding to area 209 is created using Editlet 206. The DOM of the document is edited using Editlet 206 and canvas 210. To maintain the integrity of the original document, Editlet 206 and canvas service 210 use "aspects" corresponding to one or more nodes in region 209. These services do not directly manipulate regions and nodes in the DOM. "Aspects" are manipulated using commands 207 .

Users typically interact with the screen by, for example, moving an on-screen cursor or typing commands. The canvas 210, which provides the logical layout of the screen, receives these cursor operations. The canvas 210 can cause the "aspect" to take the corresponding action. According to this relationship, the cursor subsystem 204 acts as a controller (C) for the MVC paradigm of the document manager 1081 . Canvas 210 also provides tasks for handling events. For example, the canvas 210 handles events such as mouse clicks, focus movements, and similar actions initiated by the user.

3. Overview of the relationship between Zones, Facets, Canvases, and Panes

Documents within a document processing system can be described from at least four perspectives. Namely: 1) the data structure used to maintain the content and structure of the document in the document processing system; 2) the means by which the content of the document can be edited without compromising the integrity of the document; 3) the logical layout of the document on the screen; and 4) The physical layout of the document on the screen. "Area", "Aspect", "Canvas" and "Pane" represent components of the document processing system corresponding to the above four aspects, respectively.

4. Undo Subsystem

As noted above, it is desirable that any changes (eg, edits) to a document be undoable. For example, a user may perform an edit operation and then decide to undo the change. Referring to FIG. 12, the undo subsystem 212 is a component of the document manager that can perform undo operations. The undo manager (UndoManager: undo management unit) 2121 saves all operations performed on the document that can be undone by the user. For example, a user may execute a command to replace a term in a document with another term. Later, the user may change his mind and decide to keep the original word. Undo subsystem 212 assists in the above operations. The undo manager 2121 saves the operation of the above-mentioned undoable edit (UndoableEdit: undoable edit) 2122 .

5. Cursor subsystem

As mentioned above, the controller portion of the MVC may include cursor subsystem 204 . The cursor subsystem 204 accepts input from a user. These inputs are usually in the nature of commands and/or editing operations. Accordingly, the cursor subsystem 204 can be viewed as the controller (C) part of the MVC paradigm associated with the document manager 1081 .

6. View

As mentioned above, the canvas 210 represents the logical layout of the document to be presented on the screen. For the XHTML document embodiment, the canvas 210 may include a box tree 208, which is a logical representation of how the document is viewed on the screen. The box tree 208 described above may be included in the view (V) portion of the MVC paradigm associated with the document manager 1081 .

D. Lexical Connections

An important feature of a document processing system is to provide an environment that can map XML documents to other representations for processing, and when editing the mapped representations, the edits are reflected in the source XML document while maintaining the XML document integrity.

Documents described by a markup language, such as XML documents, are created based on a vocabulary defined by a document type. A vocabulary is a set of tags. Since vocabulary can be defined arbitrarily, this makes the number of vocabulary potentially infinite. However, it is impractical to provide a dedicated separate processing and management environment for each of the many possible vocabularies. Lexical connections provide one way to solve this problem.

For example, a document can be expressed using two or more markup languages. These documents can be, for example, XHTML (Extensible Hypertext Markup Language), SVG (Scalable Vector Graphics), MathML (Mathematical Markup Language) or other markup languages. In other words, a markup language can be considered the same as the vocabulary and tag set in XML.

Vocabulary is implemented using the Vocabulary plugin. In the document processing system, it is displayed by mapping a document described in a vocabulary not available to the plug-in to another vocabulary available to the plug-in. Therefore, documents described in terms for which no plug-in is prepared can still be displayed correctly.

Vocabulary linking includes the ability to take a definition file, and map between two different vocabularies based on the taken definition file. Documents described by a certain vocabulary can be mapped to another vocabulary. Thus, vocabulary links provide the ability to display or edit documents through display and editing plug-ins corresponding to the vocabulary into which the document has been mapped.

As mentioned above, individual documents are described in a document processing system as a DOM tree usually having a plurality of nodes. A "definition file" describes for each node the connections between that node and other nodes. Specifies whether the element value and attribute value of each node can be edited. Operational expressions using element values and attribute values of nodes can also be described.

Using the mapping feature, an object DOM tree using a definition file can be created. In this way, the relationship between the source DOM tree and the target DOM tree is established and maintained. Lexical links monitor the links between the source DOM tree and the destination DOM tree. Upon receiving an editing instruction from the user, the lexical link modifies the relevant node in the source DOM tree. A "change event" is emitted indicating that the source DOM tree has been modified, and the destination DOM tree is modified accordingly.

By using lexical concatenation, relatively minor vocabularies known to only a small number of users can be transformed into other major vocabularies. As a result, documents can be accurately displayed and an ideal editing environment is provided even for secondary vocabulary that is used by only a few users.

Thus, the Lexical Connection Subsystem, which is part of a document processing system, provides functionality that enables multiple representations of documents.

FIG. 13 shows a vocabulary connection (VC: Vocabulary Connection) subsystem 300 . The VC subsystem 300 provides a way to maintain consistency between two alternative representations of the same document. For example, two representations may be the same document represented by two different vocabularies. As mentioned above, one of them can be the source DOM tree, and the other can be the destination DOM tree.

1. Lexical Connection Subsystem

The function of the vocabulary connection subsystem 300 is implemented in the document processing system by using a plug-in called a vocabulary connection (VocabularyConnection) 301 . Each vocabulary 305 representing a document requires a corresponding plug-in. For example, if part of the document is expressed in HTML and other parts in SVG, separate vocabulary plugins are required for HTML and SVG.

The vocabulary connection plugin 301 creates the appropriate vocabulary connection canvas (VCCanvas) 310 for the field 209 or pane 211 corresponding to the documents of the appropriate vocabulary 305 . Using lexical connections 301, changes to regions 209 of the source DOM tree are propagated to corresponding regions of the other DOM tree 306 according to transformation rules. The conversion rules are given in the form of Vocabulary Connection Descriptor (VCD). For each VCD file corresponding to this transition between source DOM and destination DOM, a corresponding Vocabulary Connection Manager (VCManager) 302 is created.

2. Connector

The connector 304 connects the source node in the source DOM tree and the destination node in the destination DOM tree. The role of the connector 304 is to observe the source node in the source DOM tree, and the modification (change) made to the source document corresponding to the source node. Next, modify the node in the corresponding target DOM tree. Connector 304 is the only object capable of making modifications to the destination DOM tree. For example, a user may only make modifications to the source document and the corresponding source DOM tree. Afterwards, the connector 304 makes corresponding modifications to the target DOM tree.

Connectors 304 are logically linked together to form a tree structure. The tree formed by the connectors 304 is called a connector tree (ConnectorTree). The connector 304 is created by a service (Service) called a service of a connector factory (ConnectorFactory: connector generating unit) 303 . A connector factory 303 creates connectors 304 from source documents and links them together to form a connector tree. The vocabulary connection manager 302 maintains a connector factory 303 .

As mentioned above, a vocabulary is a set of tags in a namespace. As shown, a vocabulary 305 is created for a document through vocabulary connections 301 . This is accomplished by analyzing the document file and creating an appropriate lexical connection manager 302 for the mapping between the source and destination DOMs. In addition, an appropriate association is established between a connector factory 303 that creates a connector, a zone factory (ZoneFactory) 205 that creates a zone 209, and an Editlet 206 that creates a canvas corresponding to a node in a zone. When a user discards or deletes a document from the system, the corresponding vocabulary connection manager 302 will be deleted.

Vocabulary 305 creates Vocabulary Connection Canvas 310 . Furthermore, a connector 304 and a destination DOM tree 306 are created accordingly.

The source DOM and canvas correspond to the model (M) and view (V) respectively. However, this representation is only meaningful if the target vocabulary can be represented on the screen. This rendering takes place via a vocabulary plugin. Vocabulary plugins are provided for major vocabularies such as XHTML, SVG, and MathML. Vocabulary plugins are used in association with the target vocabulary. They provide a way to map between vocabularies using lexical join descriptors.

This mapping only makes sense if the target vocabulary can be mapped and has a predefined screen representation. Such a presentation method is, for example, a standard specification such as XHTML defined by the W3C organization.

Use the Vocabulary Connection Canvas (VCCanvas) when lexical connections are required. In this case, since a view cannot be created directly for the source, no canvas for the source is created. In this case, a Connector Tree is used to create a Vocabulary Connection Canvas. This Lexicon Connection Canvas only handles event transitions and does not contribute to rendering the document on the screen.

3. DestinationZone, Pane and Canvas

As mentioned above, the purpose of the Lexical Connection subsystem is to simultaneously create and maintain two representations of the same document. The second representation is also in the form of a DOM tree, which was previously described as the destination DOM tree. In order to browse documents in the second representation, destinations, canvases, and panes are required.

After creating the Vocabulary Connection Canvas, a corresponding DestinationPane (DestinationPane) 307 will be created. Furthermore, an associated DestinationCanvas (DestinationCanvas) 308 and a corresponding BoxTree (BoxTree) 309 are created. Likewise, the Lexical Connections Canvas 310 is also associated with the pane 211 and section 209 of the source document.

The destination canvas 308 provides the logical layout of the second representation of the document. In particular, the intent canvas 308 provides user interface functionality, such as cursor and selection, for presenting documents in an intent representation. Events that occur in the destination canvas 308 are provided to the connector. The destination canvas 308 notifies the connector 304 of a mouse event, a keyboard event, a drag and drop event, and an event specific to the vocabulary of the destination (second type) expression of the document.

4. Lexical Connection Command Subsystem

As part of the vocabulary connection (VC) subsystem 300 is the vocabulary connection (VC) command subsystem 313 . The vocabulary connection command subsystem 313 creates a vocabulary connection command (VCCommand) 315 , which is used to execute instructions related to the vocabulary connection subsystem 300 . Lexical connection commands may be created through built-in CommandTemplate 318 and/or may be created from scratch using a scripting language in scripting subsystem 314 .

Command templates include, for example, an "If" command template, a "When" command template, an "Insertfragment" command template, and the like. These templates are used to create lexical join commands.

5. XPath subsystem

The XPath subsystem 316 is an important component of the document processing system that facilitates lexical connections. Connector 304 typically includes XPath information. As mentioned above, one of the tasks of lexical linking is to reflect changes in the source DOM tree to the destination DOM tree. The XPath information includes one or more XPath expressions used to identify the subset of the source DOM tree to monitor for changes/modifications.

6. Overview of source DOM tree, destination DOM tree and connector tree (ConnectorTree)

A source DOM tree is a DOM tree or region that represents a document of a vocabulary before conversion to another vocabulary. Nodes in the source DOM tree are called source nodes.

On the other hand, as described above in connection with vocabulary connection, the target DOM tree is the DOM tree or region of the document expressed in different vocabulary after conversion through mapping. A node in the destination DOM tree is called a destination node.

A connector tree is a hierarchical representation based on connectors used to express the correspondence between source nodes and destination nodes. The linker monitors the source node and changes made to the source document, modifying the destination DOM tree. Connectors are the only objects that are allowed to modify the destination DOM tree.

E. Event Flow in a Document Processing System

To be usable, a program must respond to commands from the user. Events are a way to describe and execute actions performed by the user on a program. Many high-level languages such as Java(registered trademark) rely on events to describe user actions. In the prior art, the program needs to actively collect information to understand the user's operation and the program itself executes the user's operation. This means, for example, that after initializing the program itself, in order to perform appropriate processing when the user performs any operation on the screen, keyboard, mouse, etc., entering a loop repeatedly confirms the user's operation. However, this process is difficult to manipulate. Additionally, this processing consumes CPU cycles by executing a looping program while waiting for the user to do something.

Many languages address these issues by including different paradigms. One such paradigm, event-driven, forms the basis of all modern view systems. In this paradigm, all user actions belong to a collection of abstract phenomena called "events". Events describe specific user actions in sufficient detail. The program does not actively collect user-created events, but the system notifies the program when the event to be monitored occurs. Programs that handle user interaction in this way are said to be "event-driven".

In most cases, the "event (Event)" class is used for processing, where the event class obtains the basic characteristics of all user-created events.

The document processing system defines and uses its own events and how to handle them. Several types of events are used. For example, a mouse event is an event caused by a user's mouse operation. User operations related to the mouse are passed by the canvas 210 to mouse events. As such, the canvas can be considered the forefront of user interaction with the system. A canvas that is the forefront will pass its event-related content down to its lower (child) levels if necessary.

On the other hand, a key event is generated from the canvas 210 . Keypress events have instant focus. That is, a key event always involves an action. A key event input to the canvas 210 is then passed to its superior (parent). Keyboard input is handled through different events that can handle string insertion. Events that handle string insertion will occur when characters are inserted using the keyboard. Other "events" include, for example, other events handled in a similar manner to drag events, drop events, and mouse events.

1. Event handling outside of lexical connections

Events are delivered using the event thread. Upon receiving an event, the canvas 210 changes its state. The canvas 210 posts the command (Command) 1052 to the command queue (CommandQueue) 1053 if necessary.

2. Event handling within lexical connections

By using the vocabulary connection plug-in 301, the XHTML Canvas (XHTMLCanvas) 1106 as an example of the destination canvas receives existing events such as mouse events, keyboard events, drag and drop events, and unique events in the vocabulary. These events are then notified to connector 304 . More specifically, as shown in Figure 21 (b), the event flow in the vocabulary connection plug-in 301 passes through the source pane (SourcePane) 1103, the vocabulary canvas 1104, the destination pane 1105, and the destination canvas 1106 as an embodiment of the destination canvas , the destination DOM tree and the connector tree.

F. Program Invoker (ProgramInvoker) and its relationship with other components

The procedure invoker 103 and its relationship to other components are shown in more detail in Fig. 14(a). The program invoker 103 is a basic program executed in the execution environment to start the document processing system. As shown in Figure 11(b) and Figure 11(c), user application program (UserApplication) 106, service agent (ServiceBroker) 1041, command invoker (CommandInvoker) 1051 and resource (Resource) 109 are all connected to the program invoker 103. As previously mentioned, applications 102 are components that run within an execution environment. Likewise, the Service Broker 1041 manages plug-ins that add various functions to the system. On the other hand, the command invoker 1051 executes instructions provided by the user and maintains classes and functions for executing commands.

1. Plugins and Services

The service agent 1041 will be described in detail below with reference to FIG. 14(b). As noted above, the Service Broker 1041 manages plugins (and associated services) that add various functionality to the system. Services 1042 are at the lowest level and can add features to or change features of the document processing system. "Service" consists of two parts: service category (ServiceCategory) 401 and service provider (ServiceProvider) 402 . As shown in FIG. 14( c ), a single service category 401 may have multiple associated service providers 402 . Each service provider is operable to perform all or part of a particular service category. On the other hand, service category 401 defines the type of service.

Services can be divided into three types: 1) "feature services", which provide specific features to document processing systems; 2) "application services", which are applications run by document processing systems; 3) "environment services", which provide Features needed in the overall document processing system.

An example of the service is shown in Fig. 14(d). According to the category of application service (Category), the system utility is an example of the corresponding service provider. Likewise, Editlet 206 is a category, and HTML Editlet and SVG Editlet are corresponding service providers. The zone factory 205 is another type of service and has a corresponding service provider (not shown).

The plug-ins that have been described to add functionality to the document processing system can be viewed as a unit composed of several service providers 402 and their associated classes. Each plug-in has an affiliation and a service type 401 described in a definition file.

2. The relationship between the program invoker (ProgramInvoker) and the application

FIG. 14(e) shows the relationship between the program invoker 103 and the user application 106 in detail. Required documents, data, etc. are loaded from memory. All required plugins are loaded into the service agent 1041 . Service Broker 1041 maintains and manages all plug-ins. Plug-ins can be physically added to the system, or their functionality can be loaded from memory. After loading the content of the plug-in, the service proxy 1041 defines the corresponding plug-in. Next, a corresponding user application 106 is created, loaded into the execution environment 101 and linked to the program invoker 103 .

G. Relationship between application services and environments

FIG. 15(a) shows the structure of the application service loaded in the program invoker 103 in more detail. A command invoker 1051 , which is a component of the command subsystem 105 , invokes or executes a command 1052 within the program invoker 103 . Command 1052 is an instruction for processing documents such as XML and editing corresponding XML DOM trees in the document processing system. Command invoker 1051 maintains the classes and functions needed to execute commands 1052 .

The service invoker 1041 is also executed in the program invoker 103 . User applications 106 are connected to user interface 107 and core components 110 . Core component 110 provides a way to share documents across all panes. The core component 110 also provides fonts and acts as a toolkit for panes.

FIG. 15( b ) shows the relationship among frame (frame) 1071 , menu bar (MenuBar) 1072 and status bar (StatusBar) 1073 .

H. Application Core

Figure 16(a) further explains the application core 108, which maintains all documents and the data that is part of and belonging to the documents. The core component 110 is coupled to a document manager (DocumentManager) 1081 that manages documents 1082 . The document manager 1081 is the owner of all documents 1082 stored into memory associated with the document processing system.

The document manager 1081 is also connected to a root pane (RootPane) 1084 in order to display documents on the screen. Functions of ClipBoard 1087 , SnapShot 1088 , Drag & Drop 601 , and Overlay 602 are also coupled to the core component 110 .

Snapshot 1088 is used to undo application state. When the user initiates the functionality of snapshot 1088, the current state of the application is detected and stored. Later, when the state of the application changes to another state, the contents of the stored state are preserved. A snapshot 1088 is shown in Figure 16(b). In operation, as the application moves from one URL to another, snapshot 1088 remembers the previous state, enabling back and forward operations to be performed seamlessly.

I. Organizing Documents in Document Manager

Figure 17(a) describes the document manager 1081 in more detail and how documents are organized and saved in the document manager. As shown in FIG. 11( b ), a document manager 1081 manages documents 1082 . In the embodiment shown in FIG. 17( a ), one of the multiple documents is a root document (RootDocument) 701 , and the other documents are subdocuments (SubDocument) 702 . The document manager 1081 is connected to the root document 701 , and the root document 701 is connected to all subdocuments 702 .

As shown in FIGS. 12 and 17( a ), the document manager 1081 is coupled to a document container 203 which is an object for managing all documents 1082 . Tools forming part of the toolkit 201 (eg XML Toolkit) including a DOM Service (DOMService) 703 and an IO Manager (IOManager) 704 are also provided to the Document Manager 1081 . Referring again to FIG. 17( a ), the DOM service 703 creates a DOM tree based on the document managed by the document manager 1081 . Each document 705, whether it is the root document 701 or the sub-document 702, is managed by the corresponding document container 203.

Figure 17(b) shows an example of how a set of documents A-E are arranged in a hierarchical structure. Document A is the root document. Documents B-D are subdocuments of Document A. Document E is a subdocument of Document D. The left side of Fig. 17(b) shows an example in which the hierarchical structure of the same document is displayed on the screen. Document A, which is the root document, is displayed as the base frame. Document A's subdocuments B-D appear as subframes within base frame A. Subdocument E of document D is displayed on the screen as a subframe of subframe D.

Referring again to FIG. 17( a ), an undo manager 706 (UndoManager: undo management unit) and an undo wrapper (Undo Wrapper) 707 are created for each document container 203 . Undo manager 706 and undo wrapper 707 are used to execute undoable commands. Using this feature, changes made to a document using editing operations can be undone. Changes in subdocuments also affect the root document. The undo operation takes into account changes affecting other documents within the hierarchy, eg, as shown in Figure 7(c), ensuring that consistency between all documents in the hierarchy chain is maintained.

The undo wrapper 707 encapsulates the undo objects related to the sub-documents in the container 203 and couples them with the undo objects related to the root document. The undo wrapper 707 collects the undo objects available to the undoable edit acceptor (UndoableEditAcceptor: undoable edit accepting unit) 709 .

Undo manager 706 and undo wrapper 707 are connected to undoable edit sink 709 and undoable edit source (UndoableEditResource) 708 . It should be understood by those skilled in the art that the document 705 can be the source of undo editable edits 708, and can also be the source of undo editable objects.

J. Undo commands and undo frames

Figures 18(a) and 18(b) show the undo frame and undo command in further detail. As shown in Figure 18 (a), undo command (UndoCommand) 801, redo command (RedoCommand) 802 and undoable editing command (UndoableEditCommand) 803 can be arranged in the command invoker 1051 as shown in Figure 11 (b) commands and are executed sequentially. The undoable edit command 803 is also further coupled to the undoable edit source 708 and the undoable edit acceptor 709 . The "foo" edit command 804 and the "bar" edit command 805 are examples of undoable edit commands.

1. Execution of undoable editing commands

Figure 18(b) shows the execution of the undoable edit command. First, assume that a user edits a document 705 using an edit command. In a first step S1 , the undoable edit acceptor 709 is coupled to the undoable edit source 708 , which is the DOM tree of the document 705 . In a second step S2, the document 705 is edited using the DOM API based on commands issued by the user. In a third step S3, the change event listener is notified that a change has occurred. That is, at this step, edit operations are detected by a listener monitoring all changes in the DOM tree. In a fourth step S4, undoable edits are stored as objects of the undo manager 706 . In a fifth step S5, the undoable edit acceptor 709 is separated from the undoable edit source 708 . Source of undoable edits 708 may also be document 705 itself.

K. Steps Related to Loading Documents into the System

The preceding subsections describe the individual components and subcomponents of the system. The methods used when using these components are described below. Figure 19(a) shows an overview of how documents are loaded into the document processing system. In FIGS. 24-28, each step is described in detail with specific examples.

In short, a document processing system creates a DOM from a binary stream of data contained in a document. An apex node (ApexNode: apex node) is created for a part of the document that is of interest and belongs to the "region". Then identify the appropriate "pane". The determined pane creates a "zone" and "canvas" from the top node and the physical screen surface. Next, "districts" create "aspects" for each node and provide them with the required information. The canvas creates the data structure used to render the nodes of the DOM tree.

Specifically, the document is loaded from the memory 901 . A DOM tree 902 of the document is created. A corresponding document container 903 is created to hold the documents. The document container 903 is then coupled to the document manager 904 . A DOM tree includes a root node, and in some cases may include multiple secondary nodes.

Such documents typically contain both text and graphics. Thus, for example, a DOM tree can have not only an XHTML subtree but also an SVG subtree. The XHTML subtree has an XHTML apex node (ApexNode) 905 . Likewise, the SVG subtree has an SVG top node 906 .

In step 1, a top node 906 is joined to a pane 907, which is the logical layout of the screen. In step 2, pane 907 requests 906 area factory for top node from core component as window owner (PaneOwner) 908 . In step 3, the window owner 908 returns the zone factory and the Editlet for the top node 906.

In step 4, pane 907 creates region 909 , which is joined to pane 907 . In step 5, the zone 909 creates "aspects" for each node and links to the corresponding nodes. At step 6, pane 907 creates canvas 910. Canvas 910 is coupled to pane 907 . Various commands are included in the canvas 910 . In step 7, the canvas 910 builds a data structure for presenting the document on the screen. In the case of XHTML, this includes the box tree structure.

1. MVC for Zone

Fig. 19(b) shows an outline of the structure of an area using the MVC paradigm. In this case, since regions and "facets" are document-related inputs, the model (M) includes regions and "facets". Since the canvas and the data structure that renders 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. Control (C) includes the commands contained in the canvas, since the commands perform control operations on the document and its various relationships.

L. Document representation

Examples of documents and various expressions thereof will be described below using FIG. 20 . The documents used in this embodiment contain both text and pictures. Text is represented using XHTML, while images are represented using SVG. Figure 20 shows in detail the MVC representation of document components and the relationship of the corresponding objects. In this example, document 1001 is coupled to document container 1002 that holds document 1001 . A document is represented by a DOM tree 1003 . The DOM tree includes a top node 1004 .

Top nodes are indicated by shaded circles. Non-top nodes are indicated by unshaded circles. "Aspects" for editing nodes are represented by triangles and are linked to the corresponding nodes. Since the document has text and pictures, the DOM tree of the document includes an XHTML part and an SVG part. Top node 1004 is the topmost node of the XHTML subtree. This node is linked to the XHTML Pane 1005, which is the topmost pane of the physical representation of the XHTML portion of the document. Top node 1004 is also linked to XHTML zone (XHTMLZone) 1006, where XHTML zone 1006 is part of the document's DOM tree.

The "facet" corresponding to node 1004 is also linked to XHTML zone 1006 . The XHTML area 1006 is then linked to the XHTML pane 1005 . The XHTML Editlet creates an XHTML Canvas 1007, which is a logical representation of a document. The XHTML canvas 1007 is linked to the XHTML pane 1005 . The XHTML canvas 1007 creates a Box Tree (BoxTree) 1009 for the XHTML components of the document 1001 . Various commands 1008 required to maintain and render the XHTML portion of the document are also added to the XHTML canvas 1007 .

Likewise, the top node 1010 of the document's SVG subtree is linked to an SVG zone (SVGZone) 1011, which is the portion of the document's 1001 DOM tree for expressing the document's SVG components. Top node 1010 is linked to SVG pane (SVGPane) 1013, which is the topmost pane of the physical representation of the SVG portion of the document. An SVG Canvas (SVGCanvas) 1012 representing a logical representation of the SVG portion of the document is created by the SVGEditlet and linked to the SVG Pane 1013 . The data structures and commands used to render the SVG portion of the document to the screen are linked to the SVG canvas. For example, as shown, such data structures may include circles, lines, rectangles, and the like.

For a part of the document example expression described in conjunction with FIG. 20 , further description will be made with the already described MVC example with reference to FIG. 21( a ). FIG. 21(a) provides a simplified diagram of the MV relationships in the XHTML components of document 1001. A model is an XHTML zone (XHTMLZone) 1101 for XHTML components of a document 1001 . Several nodes and their corresponding "aspects" are included in the tree of the XHTML zone. The corresponding XHTML fields and panes are part of the model (M) part of the MVC paradigm. The view (V) part of the MVC paradigm is the corresponding XHTML Canvas (XHTMLCanvas) 1102 and box tree for the HTML components of the document 1001 . The XHTML portion of the document is rendered on the screen through the canvas and the commands contained within it. Events such as keyboard and mouse input are processed in the opposite direction as shown in the figure.

The source pane (SourcePane) has additional functionality, that is to say, acts as a DOM keeper. Figure 21(b) provides the lexical connections for the components of document 1001 shown in Figure 21(a). Source pane 1103, which is a source DOM holder, contains the document's source DOM tree. The connector tree is created by the connector factory, creating a Destination Pane (DestinationPane) 1105 that also acts as a holder for the Destination DOM. The destination pane 1105 is arranged as an XHTML Destination Canvas (XHTMLDestinationCanvas) 1106 in the form of a box tree.

M. Relationships between plugin subsystems, lexical connections, and connectors

Figures 22(a)-(c) show further details related to the plug-in subsystem, vocabulary connections, and connectors, respectively. The plug-in subsystem is used to add functionality to, or exchange functionality with, the document processing system. The plug-in subsystem includes a service broker (ServiceBroker) 1041 . The zone factory service 1201 coupled to the service broker 1041 creates zones for parts of the document. Editlet Service (EditletService) 1202 is also coupled to Service Broker 1041 . Editlet service 1202 creates canvases corresponding to the nodes in the region.

Examples of zone factories are an XHTML zone factory (XHTMLZoneFactory) 1211 and an SVG zone factory (SVGZoneFactory) 1212 that create an XHTML zone and an SVG zone, respectively. As mentioned in the document example above, the text component of a document can be represented by creating an XHTML block, while an image can be represented using an SVG block. Examples of Editlet services include XHTML Editlet 1221 and SVGEditlet 1222.

Figure 22(b) shows the lexical connections in further detail. As mentioned above, lexical connection is an important feature of a document processing system, which can make the expression and display of documents in two different ways consistent. The Vocabulary Connection Manager 302, which maintains the Connector Factory 303, is part of the Vocabulary Connection Subsystem. A connector factory 303 creates connectors 304 for documents. As mentioned above, the linker monitors the nodes in the source DOM and modifies the nodes in the destination DOM to maintain consistency between the two representations.

Template (Template) 317 expresses conversion rules for some nodes. A Vocabulary Concatenation Descriptor (VCD) file is a list of templates representing rules for transforming elements or collections of elements satisfying certain paths or rules into other elements. Both template 317 and command template 318 are coupled to vocabulary connection manager 302 . A Lexical Connection Manager is an object that manages all sections in a VCD file. Creates a vocabulary connection manager object for a VCD file.

Figure 22(c) provides further details about the connector. Connector factory 303 creates connectors from source documents. Connector factory 303 connects with vocabulary, template and element template, and creates vocabulary connector (VocabularyConnector), template connector (TemplateConnector) and element connector (ElementConnector) respectively.

The vocabulary connection manager 302 maintains a connector factory 303, which reads the corresponding VCD file in order to create a vocabulary. Then create a connector factory 303 . The connector factory 303 is associated with the district factory for creating districts and the Editlet for creating canvases.

Next, the Editlet service for the target vocabulary creates a vocabulary connection canvas. The Lexical Connection Canvas also creates connectors for vertices in the source DOM tree or region. Create sub-connectors recursively as needed. Create a connector tree from a set of templates in a VCD file.

A template is a collection of rules for transforming elements of a markup language into other elements. For example, each template matches a source DOM tree or region. When matched correctly, a vertex connector is created. For example, the template "A/*/D" matches all tree branches starting at node A and ending at node D, regardless of nodes between nodes A and D. Likewise, "//B" corresponds to all "B" nodes from the root node.

N. Example of a ConnectorTree associated with a VCD file

Processing related to a specific document will be explained below. A document named "MySampleXML" is loaded into the document processing system. Fig. 23 shows an embodiment of a VCD script using a vocabulary connection manager and a ConnectorFactoryTree for a "MySampleXJML" file.

The figure shows the vocabulary section within the script file, the template section and the corresponding components in the vocabulary connection manager. The attributes "match" as "sample:root", "label" as "MySampleXML", and "call-template" as "sampleTemplate" are provided under the tag "vcd:vocabulary".

In this embodiment, in the vocabulary connection manager of "MySampleXML", the vocabulary includes the vertex element "sample:root". The corresponding UI is labeled "MySampleXML". In the template section, the label is "vcd:template" and the name is "sample template".

O. Detailed Embodiments of Methods of Loading Files into a System

Figures 24-28 show the detailed description of the loaded document "MySampleXML". In step 1, a document is loaded from the memory 1405 as shown in FIG. 24( a ). The DOM service (DOMService) creates a DOM tree and a document container 1401 corresponding to the document manager 1406 . Document container 1401 is coupled to document manager 1406 . Documentation includes subtrees for XHTML and MySampleXML. The XHTML top node 1403 is the topmost node of XHTML with the label "xhtml:html". The top node 1404 of "MySampleXML" is the topmost node of "MySampleXML" with the label "sample:root".

In step 2, as shown in Figure 24(b), the root pane creates the XTML area, "facets" and canvas for the document. A pane 1407 corresponding to the top node 1403, an XHTML region 1408, an XHTML canvas 1409 and a box tree 1410 are created.

In step 3, as shown in FIG. 24(c), after finding the tag "sample:root" which the XHTML section does not understand, a child pane is created from the area on the XHTML canvas.

Figure 25 shows step 4, where the child pane gets a zone factory that can handle the "sample:root" tag and create the appropriate zone. This kind of zone factory is in the vocabulary capable of implementing zone factories. The district factory includes the contents of the VocabularySection in "MySampleXML".

FIG. 26 shows step 5, in which a default zone (DefaultZone) 1061 is created for the vocabulary corresponding to "MySampleXML". Create a corresponding Editlet and provide a subpane 1501 for creating a corresponding canvas. Editlet to create vocabulary connection canvas. Next, the Vocabulary Connection Canvas invokes the Template Section (TemplateSection) that includes the Connector Factory tree. The connector factory tree creates all the connectors that will make up the connector tree.

In step 6 shown in FIG. 27, each connector creates a target DOM object. Some connectors include XPath information. The XPath information includes one or more XPath expressions used to determine the subset of the source DOM tree that needs to be monitored for changes/modifications.

In step 7 shown in FIG. 28, vocabulary forms the destination pane of the destination DOM tree from the panes of the source DOM. This is done based on the SourcePane. The top node of the destination tree is linked to the destination pane (DestinationPane) and the corresponding area. The destination pane creates a destination canvas (DestinationCanvas). Furthermore, the destination pane is provided with data structures and commands for rendering documents in the destination format, as well as Editlets for the destination pane itself.

Figure 29(a) shows the flow of events when they occur on nodes that exist only on the destination tree, without corresponding source nodes. Events captured by the canvas, such as mouse events and keyboard events, are delivered to the ElementTemplateConnector through the destination tree. The element template connector does not have a corresponding source node, so the event being delivered is not an edit operation on the source node. If the transmitted event matches the command described in the command template (CommandTemplate), the element template connector performs the corresponding action. If there is no matching command, the element template connector ignores the passed event.

Fig. 29(b) shows the flow in case an event occurs on a node of a destination tree which is associated with a source node through a text connector (TextOfConnector). The text connector obtains a text node from the node specified by the XPath of the source DOM tree, and maps the text node to a node of the destination DOM tree. Events captured by the canvas, such as mouse events and keyboard events, are passed to the text connector through the destination tree. The text linker maps the transmitted events to editing commands of corresponding source nodes, and sets these commands in a queue (Queue) 1053 . Editing commands are collections of DOM API calls executed through "aspects". When executing a command set in the queue, edit the source node. When the source node is edited, a change event is emitted and the modification to the source node is notified to the text connector registered as a listener. The text linker rebuilds the destination tree so that modifications to the source nodes are reflected in the corresponding destination nodes. At this point, if the template containing the text connector includes control declarations such as "for each" and "for loop", the connector factory re-evaluates the control declarations. After rebuilding the text connector, rebuild the destination tree.

(first embodiment)

The first embodiment proposes a new technical solution using XML, and also proposes a new programming paradigm.

As mentioned above, web page developers can develop web pages with various functions by using the VB scripting language to control ActiveX controls. However, since the ActiveX control itself is black-boxed internally, it is impossible to realize the free customization of the functions of the ActiveX control and the direct correlation between multiple ActiveX controls.

The present inventors noticed that the XML processing technology described in the premise technology is a technology suitable for solving the above-mentioned problems. For existing general applications, since the data required for its own operation is stored in a specific binary format, it is impossible to reference and use internal data from the outside without preparing an API that can be referenced externally. However, if the data used by the application is stored in XML, other applications can easily refer to the data by using the technology described in the prerequisite technology. That is, since the document processing device 20 of the premise technology stores the XML document in the DOM format, the data can be freely accessed from the outside by using the standard API of the DOM. By using this so-called "white box" technique, a highly flexible programming paradigm can be built. The present inventors conceived of a new technical idea using XML described below that is more advanced than the XML processing technology described in the premise technology.

Here, the relationship between the data structure of the XML document and the XML document processing technology will be described. Fig. 30(a), (b) and (c) show examples of data structures of XML documents as processing objects. As the simplest example, an XML document described by a single vocabulary is shown in FIG. 30(a). This XML document processing system can process an XML document described in a specific vocabulary, like a browser displaying a web page described in XHTML.

In contrast, the present applicant has developed a document processing device that can properly process XML documents in which constituent elements of a certain vocabulary (white circles in the figure) are mixed with constituent elements of other vocabulary (black circles in the figure). processing, as shown in Figure 30(b). In the document processing device 20 according to the premise technology, for an XML compound document combining various XML vocabularies, the main control unit 22 which is an example of a startup unit calls up a processing system suitable for each fragment, assigns processing and constructs a view , edit the XML compound document according to the editing operation of the user. These systems may be hard-coded plug-ins (for example, HTML unit 50 or SVG unit 60 ) developed by Java (registered trademark) language or the like, or scripts executed based on VC unit 80 described by definition files. In many cases, processing systems for mainstream vocabularies such as XHTML are provided as hard-coded plugins. On the other hand, processing systems for user-specific vocabularies are provided in the form of definition files. According to such a technique, for example, in the example of FIG. 30( b ), it is possible to insert a part of the document described by vocabulary (constituent elements of black circles) for displaying graphics into a document described in XHTML (constituent elements of white circles), Graphics are thus arranged on the screen of the XHTML document.

Here, look at the relationship between XML fragments and processing systems. The processing system is invoked for each XML fragment to build a view based on the XML content. Then, get the UI event initiated by the user and edit the XML. From another point of view, when calling out the processing system responsible for displaying and editing a specific vocabulary, the XML fragment described by the vocabulary is used as a parameter when calling out.

The inventor noticed that using such an architecture can provide an execution environment for a more free and flexible processing system. In other words, the processing system is not limited to displaying and editing a certain XML, and can perform various processing more freely. For example, based on the data in the XML fragment, the server can be accessed through the Web Service API, and natural language processing such as summarization and translation can also be performed. The XML fragment is used as a parameter to start the corresponding processing system, and also serves as the heap memory used in the operation. Viewed in this way, the document processing apparatus 20 of the premise technology provides an execution environment for a unique program, such as setting a tag in an XML document, thereby allowing processing (processing system) to be started. In this way, when performing the above processing, parameters can be used as attributes, or text parts surrounded by tags can be used as operation objects.

In this embodiment, the data structure shown in FIG. 30(c) is proposed as the data structure of the new XML document. In FIG. 30( c ), constituent elements 25 with oblique lines include pointer information to other data 26 in the document. The processing system in charge of the vocabulary to which this constituent element 25 belongs operates with reference to the data 26 indicated by the pointer information. For example, as described above, when a graphic is inserted in an XHTML document, instead of describing the graphic data entity in the graphic display vocabulary as shown in FIG. 30(b), the graphic is created with reference to other data described in the XHTML document. Applications that operate with reference to other data in the document or data of other documents can be constructed through such a data structure.

The document processing apparatus activates an appropriate processing system by referring to the namespace of the constituent elements contained in the document. Therefore, in the example of FIG. 30( c ), the constituent elements 25 indicated by oblique lines have a function of activating a processing system for displaying graphics. In addition, the activated processing system does not process the constituent element existing below the constituent element 25 , but operates referring to the data 26 indicated by the pointer information included in the constituent element 25 . This constituent element 25 also has a "fixer" function that indicates the arrangement position of graphics in the document. The pointer information of the constituent element 25 may be designated as an attribute of the constituent element 25, or may be designated as an element value of the constituent element 25 itself or its subordinate constituent elements. Parameter information and the like necessary for the operation of the processing system may also be described in the XML fragment including the constituent element 25 .

According to such a technique, the processing system can also use the external data of the segment it is responsible for as a parameter for adjusting its own operation or as a heap area. That is to say, a mode is adopted in which only a reference position pointing to an actual value is entered in the fragment part by means of xpath or the like. For example, it is equivalent to using a pointer as a parameter of a function.

If the above-mentioned technology is viewed from the viewpoint of programming paradigms, it will be possible to provide an application runtime environment that can operate with reference to data anywhere in a document. Moreover, as described above, since the data in the document can be used by any application program by using the API of DOM, a new programming environment will be provided in which the data stored as DOM in the The data in the document is used as a shared memory. In the document, constituent elements 25 for starting an application are described. The application program activated by the constituent element 25 refers to the pointer information contained in the constituent element 25 and uses other data 26 of the document as a shared memory. In this way, a new programming paradigm in which documents and applications work seamlessly will be realized.

Since the document processing device 20 has a function of notifying the occurrence of the modification through a change event when the DOM is modified, even if the data 26 referred to by the processing system for graphic display is modified by another processing system, the processing system for graphic display is notified. , so the modification can be properly reflected. As described above, even when a plurality of applications operate with reference to the same data set, since the data is appropriately shared, the plurality of applications can be easily coordinated. It can be said that multiple processing systems operate with reference to the same pointer, which is equivalent to the multiple processing systems operating in cooperation with each other using the XML document as a shared memory.

In an existing spreadsheet application, since a calculation formula is described in a cell, calculation processing can be started. In addition, when filling a graph, generally specify the range of the reference cell, and then use the data in the cell to create the graph. The technology of the present embodiment applies the above-mentioned schema to an XML compound document, thereby including features unique to XML.

If a "functional" document is created using a spreadsheet application with an aggregation function or a graph display function, the user can perform data entry, recalculation, and simulate operations with reference to the calculation results during operation. Similarly, the document processing device of this embodiment can create "functional" XML composite documents dedicated to various purposes by cooperating various processes (processing systems) using the above-mentioned technology. Furthermore, unlike spreadsheet applications, the document processing device of this embodiment is based on open XML technology and can provide a platform with good transparency and scalability. Users can use this kind of functional XML document to complete various operations.

31(a) and (b) show examples of pointer information. Fig. 31(a) shows an example when the pointer information is described in xpath. In this example, pointer information indicating the location of the data 26 to be referred to by the processing system is described by xpath. The processing system can know the location of the data 26 to be referred to by itself through the xpath method.

Fig. 31(b) shows an example when pointer information is provided by concept information. The constituent element 25 conceptually shows, as an element value or an attribute value, clearly defined concept information of the location of the data 26 to be referenced by the processing system. "Clearly defined conceptual information" may be, for example, conceptual information based on ontology technology. At this time, a concept analysis engine 27 is provided in order to interpret the concept information and determine actual data. After acquiring concept information, the concept analysis engine 27 converts the concept information into tag names, for example. When "important data" is specified as the concept information, the concept analysis engine 27 returns tag names such as <important>, <important>, and <company confidential>, for example. Thus, the processing system can know that it should refer to data with tags such as <important> in the document. Which information is required can be specified when a resolution request is made to the concept analysis engine 27 . For example, after specifying the concept of "important data", when it is required to convert to English tags, the concept analysis engine 27 can return tag names such as <important> and <secret>.

When parameter information necessary for processing system operations is described in advance in the XML fragment including the constituent element 25, as one of the parameter information, clearly defined semantic type information can be specified with reference to the object data pointed to by the pointer information. "Information of a clearly defined semantic type" may be, for example, information of a semantic type based on "ontological" technology. For example, when specifying the concept of "important" as pointer information, information such as "commercial" and "commercial" can be specified as semantic type information. In addition, when the concept of "amount" is specified as pointer information, information such as "sales", "retail price", and "loan" can be specified as semantic type information. Thus, the processing system can match the semantic type sex to check.

In existing programming languages, types cannot have semantic meaning. For example, when the numeric type is "int", you can check whether the substituted numeric value is a valid integer value, but you cannot check the semantics of the substituted numeric value. For this reason, for example, in calculating the cost per person per month, the person and the month are erroneously added, or the person is multiplied by the person, as a programming language, such a semantic error cannot be recognized. In contrast, according to the technology of this embodiment, even if the amount is the same, it will be possible to determine whether it is "sales" or "loan", or whether it is "1 yen unit" or "1,000 dollar unit", whether it is "number of people" or Confirmation of semantic consistency of "year, month", etc. When the processing system confirms the consistency of the semantic type, for example, the concept analysis engine 27 may be used to check whether the tag name of the referenced data is consistent with the specified semantic type information.

The technology of using ontology technology to provide semantic type information to data can be generalized as a new programming technology. In this way, compared with the existing programming technology, the programming technology including the technical idea of semantics is called "semantic programming".

Here, as an embodiment of the semantic programming technology, the extension of the change event from the DOM unit 30 described in the premise technology will be described. After the DOM is modified, if the DOM contains "clearly defined semantic type information", a change event will be sent to the processing system that references the type information. Conversely, the processing system not only directly specifies the DOM that it wants to monitor itself for changes (monitors whether the DOM has changed), but also indirectly specifies "clearly defined semantic type information".

Fig.32 (a), (b) shows the structure for explaining the notification of DOM change. Specifically, FIG. 32(a) shows a mechanism for issuing a transformation event in the document processing apparatus 20 according to the premise technology. The processing system 29 specifies a change to be monitored by an xpath method or the like, and is registered as a listener of a change event. The DOM unit 30 sends a change event to registered listeners after the DOM changes.

Fig. 32(b) shows the technical solution of the structure of the change event newly proposed in this embodiment. In the document processing apparatus 20, a notification unit 28 that mediates change event notification is newly provided. The notification unit 28 accepts designation of a node to be monitored from the processing system 29 . When the DOM changes, the DOM unit 30 notifies the notification unit 28 of the change. After receiving the DOM change notification from the DOM unit 30, the notification unit 28 sends a change event to the processing system 29 monitoring the changed node.

The notification unit 28 can receive the notification of the nodes to be monitored by the processing system 29 through xpath. However, in order to provide a more flexible and highly versatile programming environment, the notification unit 28 can also receive clearly defined concept information. In this case, when the notification unit 28 receives the notification that the DOM issued by the DOM unit 30 has changed, it transmits the label name of the node to the concept analysis engine 27, and obtains the concept corresponding to the label name from the concept analysis engine 27. information. The notification unit 28 sends a change event to the processing system 29 registered with the acquired concept information. Thus, the processing system 29 may instruct the notification unit 28, eg, to send it a notification when "important information" is modified. After the notification unit 28 receives the change event from the DOM unit 30, the command concept analysis engine 27 determines whether the modified node is "important information", and if so, notifies the processing system 29 of the change of the DOM.

According to such semantic programming technology, more flexible and highly versatile programs can be easily developed.

Next, a technique for editing a document having various functions using the data structure shown in FIG. 30(c) will be described.

The processing system of the vocabulary of the namespace to which the constituent element 25 belongs (ie the processing system activated by the constituent element 25 ) can be provided in the form of a customizable application component. Since this processing system is a component for constituting the document view system, it is called a "view template". View templates can be in the form of script-based definition files or hard-coded plugins. In order to use the view template function, the following operations are performed: describe the constituent element 25 as a view template fixer in the document; describe the pointer information pointing to the data to be referred to by the processing system in the constituent element 25; and describe the additional information for . In order to make view templates universal, it is preferable to provide an environment in which pointer information can be specified in the form of clearly defined conceptual information. In addition, data to be referred to may be specified using arithmetic operations, logical operations, natural language processing, and conditional expressions composed of other arbitrary operations.

FIG. 33 shows the configuration of the document processing apparatus according to this embodiment. The document processing device 100 of this embodiment includes a view template control unit 70 , an acquisition unit 71 , and a view template 78 in addition to the configuration of the document processing device 20 of the premise technology shown in FIG. 1 . The view template control unit 70 includes a prompt unit 72 , a receiving unit 74 and an editing unit 76 .

The acquisition unit 71 acquires a document as a processing object. As described above, the view template 78 is a processing system that provides a predetermined function using data contained in a document, and is also a constituent element of an editing screen of a document.

The prompting unit 72 presents the view template 78 usable in the document processing apparatus 100 to the user. The prompt unit 72 can display the list of view templates 78 installed in the document processing apparatus 100 on the display screen, and can also select an available view template 78 corresponding to the content of the document being edited, so that the view template 78 is displayed. For example, when editing an SVG document, a view template 78 that can be inserted into the SVG document can be selected and displayed.

The receiving unit 74 receives an instruction to add the view template 78 in the document from the user. After the user performs a drag-and-drop operation in the document display screen in the editing mode, and thus moves an icon of one of the view templates 78 displayed in the list screen presented by the prompting unit 72, the receiving unit 74 receives the Inserts an indication of the view template 78 that was moved.

After the receiving unit 74 receives the insertion instruction of the view template 78, the editing unit 76 inserts a constituent element (tag) for activating the view template 78 at a predetermined insertion position in the document. At this time, the editing unit 76 may display a screen for allowing the user to specify a data range for operating the view template 78 . The editing unit 76 can automatically determine the data range used to operate the view template 78 . The editing unit 76 describes pointer information of data used for the operation of the view template 78 in the document. The editing unit 76 can also describe the parameters required for the operation of the view template 78 received from the user after automatic judgment, and describe in the document.

When the editing unit 76 adds a constituent element used to start the view template 78 in the document, the main control unit 22 starts the processing system for processing the constituent element, that is, the view template 78, and the view provided by the view template 78 will be displayed on the document editing screen. show. Afterwards, the functions provided by the launched view template 78 can be used on the document editing screen.

Figure 34 shows one embodiment of an edit screen for a document. Displayed on the document editing screen 97 is a view template palette 98 displayed through the prompt unit 72 . Documents in edit mode record information such as personal schedules, ToDo lists, and emails. In the editing screen 97 shown in FIG. 34, since these information are not provided to the view, they are not displayed.

Here, after the user selects the view template 78 for displaying the progress table on the view template option board 98, when performing a drag-and-drop operation on the editing screen, the request is received by the receiving unit 74, and the editing unit 76 places a file in the specified position of the document. The constituent elements are inserted to activate the view template 78 that displays the progress meter. At this time, the editing unit 76 specifies the pointer information of a part in the document in which schedule information is stored in the form of an attribute of a constituent element.

Figure 35 shows the edit screen after the view template 78 for the schedule has been activated. When the editing unit 76 inserts into the document a constituent element used to start the view template 78 for the schedule, the main control unit 22, which is an embodiment of the startup unit, starts to process the view template 78 for the constituent element, that is, the view template 78 for the schedule. View Template 78. The schedule information 99 described in the portion pointed to by the pointer information will be displayed in the form of a table.

Thus, according to the technique of this embodiment, the view template 78 having various common functions can be added to a document, and a functional document can be constructed easily.

(second embodiment)

The technology for providing general document processing functions described in the first embodiment will be further described below. The function called "view template" in the first embodiment is hereinafter called AVC (Adaptive Vocabulary Component: Adaptive Vocabulary Component), which means a processing system that provides general-purpose VC functions.

FIG. 36 shows the configuration of the document processing device according to this embodiment. In the document processing apparatus 100 of this embodiment, the view template control unit 70 and the view template 78 of the document processing apparatus 100 in the first embodiment are replaced by the AVC control unit 3000 . The AVC control unit 3000 includes: an AVC component 3010 for displaying a table; an AVC component 3020 for displaying a graph; an AVC component 3030 for displaying UI parts; an AVC component 3040 for displaying a tree; and an AVC attribute setting unit 3002 , which is used to set attribute information necessary for the operation of these AVC components. Each of components 3010, 3020, 3030, and 3040 is a processing system that provides AVC functionality.

Fig. 37 shows an example of an XML document into which attributes of an AVC element are inserted. This XML document is described with a "doc" vocabulary for describing dictionary data. The "page" element is a child element of the root element "doc" and represents a page of the dictionary. Set multiple "page" elements according to the number of pages. Each "page" element includes an "English" element storing English words, and a "Japanese" element storing Japanese characters.

In the example shown in FIG. 37, in order to display the above-mentioned dictionary in the form of a table, an AVC attribute 3012 describing attribute information necessary for the operation of the AVC component 3010 for displaying the table is inserted. The AVC attribute 3012 is described in a vocabulary "tbl" for display tables that can be processed by the AVC component 3010 for display tables. In the AVC attribute 3012, the correspondence of the "tbl" word and the "doc" word is described by the word "avc" for describing the AVC attribute. The following will describe the vocabulary of the original XML document, i.e., the "doc" vocabulary, called the "main vocabulary"; ".

In the example of FIG. 37 , an element "column" in which data of each column of a table is recorded includes two property elements "property" as child elements. The first element "property" records the parameter "label-transfer 1", which refers to the attribute information of the element "english" of the main vocabulary. The second element "property" records a parameter "label-transfer2" indicating attribute information referring to the element "japanese" of the main vocabulary. The AVC component 3010 for displaying the table refers to the information of the attribute "property", and inputs and displays the values of the main vocabulary elements "english" and "japanese" in each column of the table. In this way, any desired document data can be passed to a processing system having common functional components (such as the AVC component 3010 for displaying tables, etc.) for processing.

FIG. 38 shows steps related to the document processing method of this embodiment. When the user issues an instruction to insert the view provided by the AVC component (S10), the main vocabulary processing system inserts the AVC attribute template of the AVC component into the insertion target position of the source DOM according to the insertion instruction (S12). This function can be performed by the main control unit 22 of the document processing device 20 or by the AVC control unit 3000 . Specifically, the instruction for inserting the AVC component can be received by selecting a menu or command, etc., or by dragging and dropping an icon representing the AVC component to the insertion position in the screen display of the document. . By referring to the pattern of the main vocabulary, it can be judged whether the AVC attribute can be inserted at the indicated position. When it is determined that the main vocabulary does not match the specified AVC attribute, insertion of the AVC attribute is not permitted.

After the source DOM is modified, the DOM unit 30 sends out a change event (S14), and the main vocabulary processing system that receives the change event displays the document again (S16). At this time, since the inserted AVC attribute is described by a vocabulary that cannot be processed by the main vocabulary processing system, the main vocabulary processing system requests the main control unit 22 to transfer the processing, and the main control unit 22 selects the AVC component as the processing system that can handle the AVC attribute And instructs its processing (S18). In the example shown in FIG. 37, since the AVC attribute 3012 is described by the AVC vocabulary "tbl", the component 3010 for displaying the table is selected. The AVC component entrusted with processing processes and displays the AVC attribute, but here, since the AVC attribute is only provided in the form of an inserted template without setting the actual attribute value, the AVC component calls the AVC attribute setting unit 3002 to set the AVC attribute (S20).

The AVC attribute setting unit 3002 issues a request to the AVC component for displaying a dialog screen for receiving AVC attribute setting (S22). This dialog screen is provided as a library that AVC components can use in common. The AVC component creates a dialog screen displaying attribute information to be set, and displays it to the user (S24). In this dialog screen, a list of elements or attributes contained in a document, for example, a list of attribute information to be set, a preview of a display screen, and data that an AVC component can refer to can be displayed. The user can select a set element from the list of elements contained in the document, such as columns, rows, labels, etc. of the table, and drag and drop it to the attribute information list screen, so that the corresponding relationship can be set.

When the user uses the dialog screen to set attribute information (S26), the AVC component receives the attribute setting information, and writes the set attribute value to the node corresponding to the AVC attribute inserted in the source DOM (S28). After the source DOM is modified, a change event is sent by the DOM unit 30 (S30), and the AVC component itself as the processing system of the AVC attribute receives and processes the AVC attribute (S32). In this way, using the information set in the AVC attribute, the functions of the AVC component are provided to realize the display desired by the user (S34). Fig. 39 shows an example of screen display.

When opening the XML document inserted with the AVC attribute, the screen shown in Fig. 39 will be displayed through the following steps. First, the processing system is assigned to the root element by the main control unit 22, and the main vocabulary is processed. Since the main vocabulary processing system cannot process the inserted AVC vocabulary, after assigning a pane to the part described in the AVC vocabulary, the processing is delegated to another processing system. The main control unit 22 selects an AVC component as a processing system suitable for processing the AVC vocabulary, and the selected AVC component creates a view with reference to the AVC attribute. In this way, the display screen shown in Fig. 39 can be obtained.

(third embodiment)

In the second embodiment, an AVC function is embodied by inserting an AVC attribute into an XML document and activating an AVC component of a processing system as the AVC attribute. In this embodiment mode, a technique for providing an AVC function without inserting an AVC attribute in an XML document will be described.

FIG. 40 shows the configuration of the document processing apparatus according to this embodiment. The document processing device 100 of this embodiment has the structure of the document processing device 100 of the second embodiment shown in FIG. Other configurations and operations are the same as those of the second embodiment.

When the AVC attribute setting unit 3002 receives from the user the setting of the attribute information necessary for the operation of the AVC component, the AVC attribute generating unit 3004 does not insert the AVC attribute 3012 into the source document as shown in FIG. The AVC property file of property 3012 is regarded as a file different from the source document. A definition file generating unit 3006 creates a module for reading out an AVC property file. Here, what is created is a script-based definition file using VC functions.

FIG. 41 shows the steps of the document processing method involved in this embodiment. When the user issues an instruction to use the processing system for the entire document or a certain "zone", switch from the first processing system that processes the tag set to which the constituent elements of the zone belong to the AVC component that is an embodiment of the second processing system At this time (S50), the AVC attribute setting unit 3002 obtains a list of AVC components registered as available to the user in the document processing apparatus 100, and displays them so that the user can select an AVC component to use (S52). When the AVC attribute setting unit 3002 receives the user's selection of the AVC component used (S54), in order to allow the user to set the setting of the parameters required for the AVC component operation, the AVC attribute generating unit 3004 creates the AVC attribute of the selected AVC component instance (S56), and requests the AVC component to display a setting dialog screen (S58). The requested AVC component creates a setting dialog using the common library, and displays it to the user (S60).

After the user sets attribute information using the dialog screen (S62), the AVC attribute generating unit 3004 creates an AVC attribute file. Here, the AVC component issues a request for displaying a registration dialog screen to the definition file generation unit 3006 to register the definition file (S64). The definition file generating unit 3006 asks the user for the file name of the definition file to be registered (S66), receives the name of the definition file from the user (S68), and then creates the definition file. This definition file will be invoked as the processing system for the source document or apex (Apex) elements of the specified "region". The definition file generation unit 3006 registers the definition file to be used by the document processing apparatus 100 as reference data (S70). The definition file contains commands to read an AVC property file, and at the same time, delegates the processing of the AVC property for reading to another appropriate processing system, that is, an appropriate AVC component.

After the creation of the AVC property file and the definition file is completed, the AVC property setting unit 3002 switches the processing system according to the created definition file (S72). Specifically, based on this definition file, an AVC property file is read, thereby delegating processing to the AVC component. The AVC component entrusted with processing refers to the AVC property file in which information for identifying the data to be used is recorded, and identifies the data used by the AVC component from the data included in the document. Thus, the AVC component provides a predetermined function using the identified data to create and display a view (S74). In this way, the functions of the AVC component are provided using the information set in the AVC attribute, thereby realizing the display desired by the user.

Using the above technology, the AVC function can be realized without inserting attribute information and the like into the source document. Therefore, new views can be added by using the AVC function while maintaining the integrity of the source document, regardless of the vocabulary describing the source document. In addition, since the created definition file is saved and applied to other documents, the definition file can be reused to provide the AVC function for multiple documents.

In addition, a command specifying an applicable processing system may be described in PI form in the source document. Thus, processing systems can be specified without any impact on the integrity of the document. The PI specifying the processing system can be described for each area where the processing system is switched. When assigning a processing system to an Apex element, the main control unit 22 assigns that system preferentially when a PI specifying a processing system is described. Using this function, by specifying in advance a definition file created for invoking the AVC function in PI format, AVC components are allocated preferentially, so that the AVC function can be realized.

The present invention has been described above based on the embodiments. The aforementioned embodiments are only exemplary, and the combination of these constituent elements or processing procedures can form various modified examples, and these modified examples also fall into the protection scope of the present invention, which will be obvious to those skilled in the art. understandable.

In the embodiment, although the processing of XML documents is described as an example, the document processing apparatus 100 can also process documents described by other markup languages such as SGML and HTML.

Possibility of industrial use

The present invention can be used in a document processing apparatus that processes documents structured using a markup language.

Claims (18)

1. Document processing device, including: a document acquiring unit, configured to acquire documents described by a predetermined tag set; a processing system for processing the set of tags to which the constituent elements of said document belong, Wherein, when the constituent elements contained in the document contain pointer information, the processing system operates with reference to the data pointed to by the pointer information, and the pointer information points to processing the tag set to which the constituent elements belong. Other data in the document that the processing system refers to when operating. 2. The document processing device according to claim 1, wherein the pointer information is described in xpath. 3. The document processing apparatus according to claim 1, wherein the pointer information is clearly defined concept information. 4. The document processing apparatus according to claim 3, further comprising an analysis unit that, when the pointer information is provided in the form of the concept information, determines data pointed to by the pointer information based on the concept information. 5. The document processing device according to any one of claims 1 to 4, wherein when multiple constituent elements contain pointer information pointing to the same data, multiple processing systems that process the tag sets to which each constituent element belongs The same data is used as shared memory. 6. The document processing apparatus according to any one of claims 1 to 5, further comprising a management unit that creates document object model data based on the document, thereby managing the document, Wherein, the processing system refers to the data indicated by the pointer information through the interface provided by the management unit. 7. The document processing apparatus according to claim 6, wherein, when the document object model data is changed, the management unit notifies the processing system of the change, and Upon receiving a notification from the management unit that the document object model data is changed, the processing system reflects the change. 8. The document processing apparatus according to claim 7, wherein a target party receiving notification that the document object model data has been changed from the management unit is specified in the form of clearly defined concept information; and The document processing apparatus further includes an analysis unit, and when the management unit sends a change notification of the object model data to the notified target specified by the concept information, the analysis unit determines the actual object model data according to the concept information. Notify the target party. 9. The document processing apparatus according to any one of claims 1 to 8, wherein the constituent elements further include parameter information required for operation of the processing system. 10. The document processing apparatus according to claim 9, wherein said parameter information includes clearly defined semantic type information related to data pointed to by said pointer information. 11. Document processing methods, including: Get documents described with a predetermined set of tags; initiating a processing system for processing the tag set to which the constituent elements of said document belong; and processing said document by said processing system, When the constituent elements contained in the document have pointer information pointing to other data contained in the document, the processing system operates referring to the data pointed to by the pointer information, and the processing system performs operations while processing the When specifying the tag set to which the above-mentioned constituent elements belong, the other data is used as reference data. 12. A program that enables the computer to realize the following functions: Get documents described with a predetermined set of tags; initiating a processing system for processing the tag set to which the constituent elements of said document belong; and processing said document by said processing system, When the constituent elements contained in the document have pointer information pointing to other data contained in the document, the processing system operates referring to the data pointed to by the pointer information, and the processing system performs operations while processing the When specifying the tag set to which the above-mentioned constituent elements belong, the other data is used as reference data. 13. A data structure described in XML, wherein at least one structural element has pointer information pointing to other data contained in the document, and the processing system processes the tag set to which the constituent element belongs , the other data are used as reference data. 14. A document processing device comprising: a receiving unit that receives an instruction to attach a processing module to the document, the processing module using data in the document to provide a predetermined function; and The editing unit, when receiving the instruction, inserts into the document a constituent element including pointer information, and the pointer information points to the data used by the processing module. 15. The document processing apparatus according to claim 14, further comprising an activating unit for activating a processing module that processes the constituent elements inserted into the document. 16. The document processing apparatus according to claim 14 or 15, wherein the editing unit inserts parameters necessary for the operation of the processing module into the document. 17. Document processing apparatus, comprising: a document acquiring unit, configured to acquire documents described by a predetermined tag set; A first processing system, processing the tag set to which the constituent elements of the document belong; a second processing system that uses the data in the document to provide a predetermined function, Wherein, when receiving an instruction to switch the processing system for processing the constituent elements of the document from the first processing system to the second processing system, the second processing system refers to the information recorded therein for identifying the A file of information about the data, to identify the data to be used, and to provide the predetermined function using the identified data. 18. The document processing apparatus according to claim 17, wherein, when the file does not exist, the second processing system receives information for identifying the data to be used from a user, and creates the file.

Images