+

WO2008015789A1 - Dispositif de traitement de documents et procédé de traitement de documents - Google Patents

Dispositif de traitement de documents et procédé de traitement de documents Download PDF

Info

Publication number
WO2008015789A1
WO2008015789A1 PCT/JP2007/000821 JP2007000821W WO2008015789A1 WO 2008015789 A1 WO2008015789 A1 WO 2008015789A1 JP 2007000821 W JP2007000821 W JP 2007000821W WO 2008015789 A1 WO2008015789 A1 WO 2008015789A1
Authority
WO
WIPO (PCT)
Prior art keywords
document
file
execution
breakpoint
unit
Prior art date
Application number
PCT/JP2007/000821
Other languages
English (en)
French (fr)
Inventor
Tatsuo Kato
Original Assignee
Justsystems Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Justsystems Corporation filed Critical Justsystems Corporation
Priority to JP2008527657A priority Critical patent/JPWO2008015789A1/ja
Publication of WO2008015789A1 publication Critical patent/WO2008015789A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/151—Transformation
    • G06F40/154—Tree transformation for tree-structured or markup documents, e.g. XSLT, XSL-FO or stylesheets
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/205—Parsing
    • G06F40/226—Validation

Definitions

  • the present invention relates to a document processing technique, and more particularly to a document processing apparatus and method for processing a document described in a markup language.
  • Patent Document 1 Japanese Patent Laid-Open No. 2 00 1 _ 2 90 80 4
  • a poch-library is allowed to be defined arbitrarily, and in theory, there can be an infinitely many pockies. It is impractical to provide a dedicated display and editing environment corresponding to all of these Poch libraries.
  • the source of the document composed of text data was directly edited using a text editor or the like.
  • the present invention has been made in view of such circumstances, and an object of the present invention is to provide a technique for improving user convenience when processing a document described in a markup language. .
  • One embodiment of the present invention relates to a document processing apparatus.
  • This document processing apparatus controls execution of a scribble file that describes how to convert a document described in a predetermined tag set into a document described in another tag set and process it.
  • a source view display unit that displays the content of the document that is the conversion source while the script file is being executed so that the element that is the processing target can be identified, and the script file that is being executed
  • a scribble file display that displays the contents of the file so that the position being processed can be identified, and the contents of the document to be converted to the elements to be processed during execution of the script file.
  • a destination view display section that displays the information in an identifiable manner, and a breakpoint setting section that sets a breakpoint that temporarily stops execution of the script file by the execution control section, and the breakpoint setting section includes:
  • the search request for the element that sets a breakpoint is accepted and specified from the script file. It is characterized by searching for an element and setting a breakpoint at the searched element.
  • the breakpoint setting unit may present only elements for which a breakpoint can be set when accepting specification of an element to be searched.
  • the document processing apparatus includes: an execution control unit that controls execution of a script file that describes a method of converting a document described in a predetermined tag set into a document described in another tag set and processing the document; While executing the script file, the source view display unit displays the content of the document that is the conversion source so that the element to be processed can be identified, and during the execution of the script file, the content of the script file is displayed.
  • a scribble file display that displays the position being processed in an identifiable manner, and the contents of the document at the conversion destination during the execution of the script file so that the element to be processed can be identified Destination view display section and a variable that displays the contents of variables, properties, or user data set in the script file.
  • the value of the property view display unit and the variable, the property, or the user data is a data having a hierarchical structure
  • the data is displayed in the hierarchical structure when the property view display unit displays the data.
  • Still another embodiment of the present invention also relates to a document processing apparatus.
  • This document processing device An execution control unit that controls execution of a script file that describes a method of converting a document described in a predetermined tag set into a document described in another tag set and processing the script file;
  • a source view display section that displays the contents of the document of the conversion source so that the element to be processed can be identified; and the position of the script file during the execution of the script file
  • a scribble file display section that displays in an identifiable manner, and a destination view display section that displays the contents of the document to be converted in an identifiable manner during the execution of the script file.
  • a further aspect of the present invention relates to a document processing method, comprising: a shaping unit for shaping.
  • the document processing method includes a step of controlling execution of a script file describing a method of converting a document described in a predetermined tag set into a document described in another tag set, and processing the script.
  • FIG. 1 is a diagram showing a configuration of a document processing apparatus according to a base technology.
  • FIG. 2 is a diagram showing an example of an XML document edited by a document processing apparatus.
  • FIG. 3 is a diagram showing an example of mapping the XML document shown in FIG. 2 into a table described in HTML.
  • FIG. 4 (a) is a diagram showing an example of a definition file for mapping the XML document shown in FIG. 2 into the table shown in FIG.
  • FIG. 4 (b) is a diagram showing an example of a definition file for mapping the XML document shown in FIG. 2 into the table shown in FIG.
  • FIG. 5 is a diagram showing an example of a screen displayed by mapping the XML document shown in FIG. 2 to HTML according to the correspondence shown in FIG.
  • FIG. 6 is a diagram showing an example of a graphical user interface that the definition file generation unit presents to the user in order for the user to generate a definition file.
  • FIG. 7 is a diagram showing another example of the screen layout generated by the definition file generation unit.
  • FIG. 8 is a diagram showing an example of an XML document editing screen by the document processing apparatus.
  • FIG. 9 is a diagram showing another example of an XML document edited by the document processing apparatus.
  • FIG. 10 is a diagram showing an example of a screen displaying the document shown in FIG.
  • FIG. 11 (a) is a diagram showing a basic configuration of a document processing system.
  • FIG. 11 (b) is a diagram showing a block diagram of the entire document processing system.
  • FIG. 11 (c) is a diagram showing a block diagram of the entire document processing system.
  • FIG. 12 is a diagram showing details of the document management unit.
  • FIG. 13 is a diagram showing the details of the podocaplary connection subsystem.
  • FIG. 14 is a diagram showing details of the relationship between the program starter and other components.
  • FIG. 15 is a diagram showing the details of the structure of the application service dictated by the program startup unit.
  • FIG. 16 is a diagram showing details of the core component bowl.
  • FIG. 17 is a diagram showing details of a document management unit.
  • FIG. 18 is a diagram showing details of an undo framework and an undo command.
  • FIG. 19 is a diagram showing how a document is loaded in the document processing system.
  • FIG. 20 shows an example of a document and its expression.
  • FIG. 21 is a diagram showing a relationship between a model and a controller.
  • FIG. 22 is a diagram showing the details of the plug-in subsystem, the poker library connection, and the connector.
  • FIG. 23 is a diagram showing an example of a V CD file.
  • FIG. 24 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 25 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 26 shows a procedure for loading a compound document in the document processing system.
  • FIG. 27 shows a procedure for loading a compound document in the document processing system.
  • FIG. 28 is a diagram showing a procedure for loading a compound document in the document processing system.
  • FIG. 29 is a diagram showing a command flow.
  • FIG. 30 is a diagram showing a configuration of a document processing apparatus according to the embodiment.
  • FIG. 31 is a diagram showing a sample document for explaining the function of the debugger.
  • FIG. 32 is a diagram showing a V CD file associated with the XML document shown in FIG. 31.
  • FIG. 33 A diagram showing an example of a degging screen displayed by the degging.
  • Fig.34 This is a diagram showing the state where the VCD script processing is advanced to the rhtmlj element.
  • FIG. 35 is a diagram showing a screen when step-in is executed in the state shown in FIG.
  • FIG. 36 is a diagram showing a state in which the processing of the VCD script is advanced to the “title” element.
  • FIG. 37 is a diagram showing a screen when a step-out is executed in the state shown in FIG. 36.
  • FIG. 38 is a diagram showing a state in which the VCD script process is advanced to the rbodyj element.
  • FIG. 39 is a diagram showing a screen when step over is executed in the state shown in FIG. 38.
  • FIG. 40 is a diagram showing a result of applying the VCD file script shown in FIG. 32 to the XML document shown in FIG. 31.
  • FIG. 41 is a diagram showing a search dialog screen presented by the breakpoint setting unit.
  • FIG. 42 is a diagram showing a property dialog screen in which the variable value sub-tree is formatted and displayed.
  • FIG. 43 is a diagram showing a pop-up window in which lines that do not fit in the screen width are formatted and displayed.
  • FIG. 1 shows the configuration of the document processing apparatus 20 according to the base technology.
  • the document processing device 20 processes a structured document in which data in the document is classified into a plurality of structural elements having a hierarchical structure.
  • the document processing apparatus 20 includes a main control unit 22, an editing unit 24, a DOM unit 30, a CSS unit 40, an HTML unit 50, an SVG unit 60, and a VC unit 80 as an example of a conversion unit.
  • These hardware components are realized by the CPU of any computer, memory, programs loaded in the memory, etc., but here we draw functional blocks realized by their cooperation. ing. Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.
  • the main control unit 22 provides a framework for loading plug-ins and executing commands.
  • Editing unit 24 provides a framework for editing XML documents.
  • the document display and editing functions in the document processing device 20 are realized by plug-ins, and necessary plug-ins are dictated by the main control unit 22 or the editing unit 24 according to the type of document.
  • the main control unit 22 or the editing unit 24 refers to the name space of the XML document to be processed, determines which vocabulary the XML document is described in, and displays or edits corresponding to the PoCabary. Load plug-ins for viewing and editing.
  • the document processing apparatus 20 includes an HTML unit 50 that displays and edits HTML documents, and displays and edits S VG documents.
  • the display system and editing system are implemented as plug-ins for each POB library (tag set), such as the SVG unit 60.
  • the HTM L unit 50 power
  • SVG unit 60 forces each loaded.
  • both the HTML unit 50 and the SVG unit 60 are dictated.
  • the user can select and install only the necessary functions, and can add or delete functions later as appropriate, so that the recording medium such as a hard disk for storing the program can be used. It is possible to effectively use the storage area of the memory, and it is possible to prevent memory from being wasted even during program execution. In addition, it has excellent function expandability, and as a development entity, it is possible to cope with new poker libraries in the form of plug-ins, so development is easy, and for users, it is easy and low-cost by adding plug-ins. Functions can be added.
  • the editing unit 24 accepts an editing instruction event from the user via the user interface, notifies the appropriate plug-in of the event, and re-executes the event or cancels the execution. Control processing such as (Undo).
  • the DOM unit 30 includes a DOM providing unit 32, a DOM generating unit 34, and an output unit 36, and is a document object model (Document) defined to provide an access method when handling an XML document as data. Implements functions that conform to Object Model: DO M).
  • the DOM provider 32 is an implementation of DOM that satisfies the interface defined in the editing unit 24.
  • the DOM generation unit 34 generates a DOM tree from the XML document. As will be described later, when the XML document to be processed is mapped to another vocabulary by VC Unit 80, the source tree corresponding to the mapping source XML document and the mapping destination XML document A corresponding destination tree is generated. For example, the output unit 36 converts the DOM tree into an XML document at the end of editing. Output.
  • the CSS unit 40 includes a CSS analysis unit 42, a CSS providing unit 44, and a rendering unit 46, and provides a display function compliant with CSS.
  • the CSS analysis unit 42 has a function of a parser that analyzes CSS syntax.
  • the CSS provider 44 is an implementation of CSS objects, and performs CSS force scheduling processing on the DOM tree.
  • the rendering unit 46 is a CSS rendering engine, and is used to display a document described in a vocabulary such as HTML that is laid out using the CSS.
  • the HTML unit 50 displays or edits a document described in HTML.
  • the SVG unit 60 displays or edits documents described in SVG.
  • These display / editing systems are realized in the form of plug-ins. Each of them is a display unit (Canvas) 56, 66 for displaying a document, a control unit (Editlet) 52 for sending / receiving events including editing instructions, 62. Includes editing sections (Zone) 54 and 64 that receive editing commands and edit the DOM.
  • the control unit 52 or 62 receives a DOM tree editing command from the outside, the editing unit 54 or 64 changes the DOM tree, and the display unit 56 or 66 updates the display.
  • MVC Model-View-Control ler
  • the display units 56 and 66 are set to “View”, and the control units 52 and 62 force ⁇ ⁇ Control lerj.
  • the editing parts 54 and 64 and the DOM entity correspond to “Model”, respectively.
  • the document processing apparatus 20 of the base technology enables not only editing of an XML document in a single display format but also editing according to each vocabulary.
  • the HTML unit 50 provides a user interface for editing an HTML document in a manner similar to a word processor
  • the SVG unit 60 provides a user interface for editing an SVG document in a manner similar to an image drawing tool. Provide one face.
  • the VC unit 80 includes a mapping unit 82, a definition file acquisition unit 84, and a definition file generation unit 86.
  • a mapping unit 82 By mapping a document described in a certain library to another one, the mapping destination A framework for displaying or editing a document with a plug-in for display editing corresponding to the library is provided. In this base technology, this function is called Pocabulary Connection (VC).
  • the definition file acquisition unit 84 acquires a script file describing the mapping definition. This definition file describes the correspondence (connection) between nodes for each node. At this time, whether to edit the element value or attribute value of each node may be specified. Also, an arithmetic expression using the element value or attribute value of the node may be described.
  • the mapping unit 82 refers to the scribble file acquired by the definition file acquisition unit 84, causes the DOM generation unit 34 to generate a destination tree, and manages the correspondence between the source tree and the destination tree.
  • the definition file generator 86 provides a graphical user interface for the user to generate a definition file.
  • the VC unit 80 monitors the connection between the source tree and the destination tree, and receives an editing instruction from the user via the user interface provided by the plug-in responsible for display. Change the corresponding node.
  • DOM Unit 3 0 Force When issuing a mutation event that the source tree has changed, VC Unit 8 0 receives the mutation event and synchronizes the destination tree with the source tree change. Change the node of the destination tree corresponding to the changed node.
  • Plug-ins that display / edit the destination tree for example HTML unit 50, receives a mutation event that the destination tree has changed, and updates the display with reference to the changed destination tree To do. With such a configuration, even a document described by local vocabulary used by a small number of users can be displayed by converting it to another major vocabulary, and the editing environment Provided.
  • the DOM generation unit 3 4 Generate a DOM tree from the XML document. Further, the main control unit 2 2 or the editing unit 2 4 refers to the name space to determine the poker library describing the document. A plug-in corresponding to the vocabulary is installed in the document processing device 20! If so, load the plug-in to view / edit the document. If the plug-in is not installed, check whether the mapping definition file exists. If the definition file exists, the definition file acquisition unit 84 acquires the definition file, generates a destination tree according to the definition, and displays / edits the document by the plug-in corresponding to the mapping destination library.
  • the corresponding parts of the document are displayed / edited by plug-ins corresponding to each library as described later. If the definition file does not exist, the source or tree structure of the document is displayed, and editing is performed on the display screen.
  • FIG. 2 shows an example of an XML document to be processed.
  • This XML document is used to manage student performance data.
  • the component “Grade”, which is the top node of the XML document, has multiple components “Student” provided for each student.
  • the component “student” has an attribute value “name” and child elements “national language”, “mathematics”, “science”, and “society”.
  • the attribute value “name” stores the name of the student.
  • Constituent elements “National language”, “Mathematics”, “Science” and “Society” store the results of national language, mathematics, science and society, respectively.
  • a student with the name “A” has a national language grade of “9 0”, a mathematical grade of “5 0”, a scientific grade of “7 5”, and a social grade of “6 0”.
  • the Pocabulary (tag set) used in this document will be referred to as the “Performance Management Pocabulary”.
  • the document processing apparatus 20 of the base technology does not have a plug-in that supports display / editing of the grade management vocabulary, in order to display this document by a method other than source display and tree display,
  • the VC function described above is used. In other words, prepare a definition file for mapping the grade management library to another library with plug-ins, such as HTML and SVG. There is a need.
  • the user interface for creating a definition file by the user himself will be described later. Here, the explanation will proceed assuming that a definition file has already been prepared.
  • FIG. 3 shows an example of mapping the XML document shown in FIG. 2 to a table described in HTML.
  • the “Student” node of the Grade Management Platform is mapped to a row (“TR” node) of a table (“TABLE” node) in HTML, and the attribute value “name” is assigned to the first column of each row.
  • the second column contains the element values of the “National Language” node, the third column the element values of the “Mathematics” node, the fourth column the element values of the “Science” node, and the fifth column “Society”. Associate node element values with each other.
  • the XML document shown in Fig. 2 can be displayed in the HTML table format.
  • the sixth column specifies the formula for calculating the weighted average of national language, mathematics, science, and society, and displays the average score of the students' grades. In this way, by making it possible to specify an arithmetic expression in the definition file, more flexible display is possible and user convenience during editing can be improved.
  • the sixth column specifies that editing is not possible, so that only the average score cannot be edited individually. In this way, by making it possible to specify whether editing is possible in the mapping definition, it is possible to prevent user misoperation.
  • FIG. 4 (a) and FIG. 4 (b) show examples of definition files for mapping the XML document shown in FIG. 2 to the table shown in FIG.
  • This definition file is described in the script language defined for the definition file.
  • the definition file contains command definitions and display templates.
  • "add student” and “delete student” are defined as commands, respectively, the operation of inserting the node “student” into the source tree, and the source tree The operation to delete the node “Student” from the node is associated.
  • headings such as “Name” and “National Language” in the first row of the table Is displayed, and it is described that the contents of the node “Student” are displayed after the second line.
  • FIG. 5 shows an example of a screen displayed by mapping the XML document described in the grade management platform shown in FIG. 2 to the HTML according to the correspondence shown in FIG.
  • Table 90 shows, from the left, each student's name, national language grade, mathematics grade, science grade, social grade, and average score.
  • the user can edit the XML document on this screen. For example, if you change the value in the second row and third column to “7 0”, the element value in the source tree corresponding to this node, that is, the math grade for student “B” changes to “7 0” Is done.
  • VC unit 80 should make the destination tree follow the source tree, change the corresponding part of the destination tree, and HTML unit 50 will update the display based on the changed destination tree. To do. Therefore, in the table on the screen, the mathematics score of student “B” is changed to “7 0”, and the average score is changed to “5 5”.
  • the commands "Add Student” and "Delete Student” appear in the menu as defined in the definition file shown in Fig. 4 (a) (b). Indicated.
  • the node “Student” is added or deleted in the source tree.
  • the document processing apparatus 20 of the base technology can not only edit the element value of the component at the end of the hierarchical structure but also edit the hierarchical structure.
  • Such a tree structure editing function may be provided to the user in the form of a command.
  • a command for adding or deleting a table row may be associated with an operation for adding or deleting a node “student”.
  • the command to embed other pocky libraries is May be provided. Using this table as an input template, you can also add new student grade data in the form of blanks.
  • the VC function makes it possible to edit a document described in the grade management library while using the display / editing function of the HTML unit 50.
  • FIG. 6 shows an example of a graphical user interface that the definition file generator 86 provides to the user in order for the user to generate a definition file.
  • the mapping source XML document is displayed as a tree.
  • the screen layout of the XML document to be mapped is shown. This screen layout can be edited by the HTML unit 50, and the user creates a screen layout for displaying the document in the area 92 on the right side of the screen.
  • the node of the mapping source XML document displayed in the area 91 on the left side of the screen is displayed in the screen layout using HTML displayed in the area 92 on the right side of the screen.
  • the connection between the mapping source node and the mapping destination node is specified. For example, if you drop “Mathematics”, a child element of the element “Student”, into the first row and third column of Table 90 on the HTML screen, between the “Mathematics” node and the “TD” node in the third column. A connection is stretched over.
  • Each node can be specified for editing.
  • An arithmetic expression can be embedded in the display screen.
  • FIG. 7 shows another example of the screen layout generated by the definition file generation unit 86.
  • Table 90 and the pie chart 93 are created on the screen for displaying the XML document described in the grade management platform. This pie chart 93 is described in SVG.
  • the document processing apparatus 20 of the base technology can process a composite document including a plurality of libraries in one XML document, so that it is described in HTML as in this example.
  • Table 90 and the pie chart 93 described in SVG can be displayed on one screen.
  • FIG. 8 shows an example of an XML document editing screen by the document processing apparatus 20.
  • one screen is divided into a plurality of areas, and the XML document to be processed is displayed in a plurality of different display formats in each area.
  • the source of the document is displayed.
  • the document structure is displayed.
  • the table described in HTML shown in Fig. 5 is displayed. Is displayed. Documents can be edited on any of these screens.
  • the source code is changed, and the plug-in responsible for displaying each screen Update the screen to reflect the tree changes.
  • the display unit of the plug-in responsible for displaying each edit screen is registered, and either one of the plug-in or VC unit 8 0 is used.
  • the source tree is changed, all the display units displaying the edit screen receive the issued mutation event and update the screen.
  • the VC unit 80 changes the destination tree following the change of the source tree, and then refers to the changed destination tree.
  • the display unit updates the screen.
  • the source display plug-in and the tree display plug-in do not use the destination tree, but directly use the source tree.
  • Browse and display This In this case, when editing is performed on any of the screens, the source display plug-in and the all-in-one plug-in update the screen with reference to the changed source list, and take charge of the screen in area 96.
  • the following HTML unit 50 updates the screen by referring to the changed destination tree following the change of the source tree.
  • the source display and the tree display can also be realized by using the VC function.
  • the source and tree structure may be laid out using HTML, XML documents may be mapped onto the HTML, and displayed using the HTML unit 50.
  • three destination destinations are generated: source format, tree format, and tabular format.
  • VC Unit 8 0 changes the source tree, then changes each of the three destination trees: source format, solid format, and table format. Browse the destination tree and update the three screens.
  • the user can display and edit a document in a visually easy-to-understand format using Table 90 or the like while grasping the hierarchical structure of the document by displaying the source or the tree.
  • one screen can be divided and screens in multiple display formats can be displayed at the same time.
  • One screen can be displayed in one display format, and the display format can be switched according to user instructions.
  • the main control unit 2 2 power receives a display format switching request from the user, and instructs each plug-in to switch the display.
  • FIG. 9 shows another example of an XML document edited by the document processing apparatus 20.
  • the editing unit 24 refers to the name space and distributes the drawing work to an appropriate display system.
  • the editing unit 24 first causes the SVG unit 60 to draw a rectangle, and then causes the HTML unit 50 to draw an XHTML document.
  • the Math ML unit (not shown) draw mathematical formulas. In this way, a compound document including a plurality of pages is properly displayed. The display results are shown in Fig. 10.
  • the displayed menu may be switched according to the position of the cursor (carriage). That is, when the cursor exists in the area where the SVG document is displayed, the menu defined by the SVG unit 60 or the command defined in the definition file for mapping the SVG document is displayed.
  • the menu defined by the HTML unit 50 or the command defined in the definition file for mapping the XHTML document is displayed.
  • an appropriate user interface can be provided according to the editing position.
  • the part described by the library may be displayed in a source or tree.
  • the contents could not be displayed unless an application that displayed the embedded document was installed. Then, even if there is no display application, the content can be grasped by displaying the XML document composed of text data in the source display or the tree display. This is a unique feature of text-based documents such as XML.
  • Another advantage of data being described in a text base is that, for example, in a portion of a compound document described by a certain library, data of a portion described by another library in the same document is changed. You may refer to it.
  • a search is performed in a document, a character string embedded in a figure such as SVG can be searched.
  • tags from other Pocabularies. It may be used. This XML document is not valid, but can be processed as a valid XML document if it is well-formed. In this case, the tag of the other vocabulary inserted may be mapped by the definition file. For example, you can use tags such as “Important” and “Most important” in an XHTML document and highlight the parts enclosed by these tags, or sort them in order of importance. May be.
  • the plug-in or VC unit 80 responsible for the edited part changes the source tree.
  • listeners for mutation events can be registered for each node.
  • the plug-in display section or VC unit 80 corresponding to the portal to which each node belongs is registered as a listener.
  • the DOM provider 32 traces from the changed node to a higher hierarchy, and if there is a registered listener, issues a mutation event to that listener. For example, in the document shown in Fig.
  • the mutation event is notified to the HTM Lunit 50 registered as a listener in the ⁇ htm I> node.
  • the mutation event is also notified to the SVG unit 60 registered as a listener in the upper ⁇ s V g> node.
  • the HTML unit 50 refers to the changed source tree and updates the display.
  • the SVG unit 60 may ignore the mutation event because the node belonging to its own Pocabulary has not changed.
  • the overall layout may change as the display is updated by the HTML unit 50.
  • the layout of the display area for each plug-in is updated by the configuration that manages the layout of the screen, for example, the plug-in responsible for displaying the top node. For example, if the display area of the HTML unit 50 becomes larger than before, the HTML unit 50 first draws the part that it is responsible for and determines the size of the display area. The Then, notify the configuration that manages the layout of the screen of the size of the display area after the change, and request a layout update. The configuration that manages the screen layout receives the notification and re-lays out the display area for each plug-in. In this way, the display of the edited part is updated appropriately and the layout of the entire screen is updated.
  • the web which forms the core of the Internet, has become a big receptacle for such document data.
  • the Web provides information retrieval systems for such documents.
  • These documents are usually written in a markup language.
  • HTML HyperText Markup Language
  • Such documents further include links to other documents stored elsewhere on the web.
  • XML extensible Markup Language
  • Simple browsers for accessing and browsing web documents have been developed in object-oriented programming languages such as Java (registered trademark).
  • Documents written in a markup language are usually represented in the form of a tree data structure in browsers and other applications. This structure corresponds to the tree of the result of parsing the document.
  • the DOM (Document Object Model) is a well-known tree-based data structure model used to represent and manipulate documents.
  • the DOM provides a standard set of objects for representing documents, including HTML and XML documents.
  • the DOM accesses and manipulates the standard model of how objects that represent components in a document are connected, and those objects. It includes two basic components: a standard interface for
  • a DOM tree is a hierarchical representation of a document based on the contents of the corresponding DOM.
  • the DOM tree contains a “root” and one or more “nodes” that originate from the root. In some cases, the root represents the entire document. Intermediate nodes can represent elements such as a table and the rows and columns in the table, for example.
  • a “leaf” in a DOM tree usually represents text or image-like data that cannot be further decomposed.
  • Each node in the DOM tree may be associated with attributes that describe the parameters of the element represented by the node, such as font, size, color, and indentation.
  • HTML is a language generally used for creating a document, but is a language for format and layout, not a language for data description.
  • Nodes in the DOM tree that represent HTML documents are elements that are predefined as HTML formatting tags, and HTML is usually used for data description and tagging / labeling of data. It is often difficult to formulate queries for data in HTML documents.
  • XML XML Markup Language
  • HTML HyperText Markup Language
  • XML XML Style Language
  • Additional information on DOM, HTML, XML, CSS, XS L and related language features can also be obtained from the web.
  • Xpath provides common syntax and semantics for specifying the location of parts of an XML document.
  • An example of functionality is traversing the DOM tree corresponding to an XML document. It provides basic functions for manipulating strings, numbers, and Boolean characters associated with various representations of XML documents.
  • X path is the syntax of the appearance of an XML document, for example, the grammar and the abstract syntax such as the DOM tree, not the grammar of what line or number of characters when viewed as a text string. It works in any structure. By using Xpath, you can specify a location through a hierarchical structure in the DOM tree of an XML document, for example.
  • Xpath is also designed to be used to test whether a node in a DOM tree matches a pattern. More details on XP at h can be found at http: // www. W3. Org / TR / xpath
  • MVC Model-Vie w-Control ler
  • MVC Model
  • V View
  • C Controller
  • the controller interprets input such as mouse and keyboard input from the user and maps these user actions to commands sent to the model and / or view to bring about appropriate changes.
  • the model acts to manage one or more data elements, responds to queries about that state, and responds to instructions that change the state.
  • the view acts to manage the rectangular area of the display and has the function of presenting data to the user through a combination of graphics and text.
  • FIG. 11 (a) shows a conventional configuration example of elements that function as the basis of a document processing system of the type described later.
  • Configuration 10 includes a processor of the type such as a CPU or microprocessor 11 connected to memory 12 by communication path 13.
  • the memory 12 may be in any ROM and / or RAM format available now or in the future.
  • the communication path 13 is typically provided as a bus.
  • Input / output interfaces for user input devices 14 and display devices 15 (or other user interfaces) such as mice, keyboards, speech recognition systems, etc.
  • Ace 1 6 is also connected to a bus for communication between processor 1 1 and memory 1 2.
  • This configuration may be a stand-alone, a networked form in which a plurality of terminals and one or more servers are connected, or may be configured by any known method.
  • the present invention is not limited by the arrangement of these components, the centralized or distributed architecture, or the communication methods of the various components.
  • the present system and the embodiments discussed herein are discussed as including several components and sub-components that provide various functionalities. These components and sub-components can be realized not only by a combination of hardware and software, but also by hardware alone or software alone to provide the noted functionality. Furthermore, the hardware, software, and combinations thereof can be realized by general-purpose computing devices, dedicated hardware, or combinations thereof. Thus, the configuration of a component or subcomponent includes a general purpose / dedicated computing device that executes specific software to provide the functionality of the component or subcomponent.
  • FIG. 11 (b) shows an overall block diagram of an example of a document processing system.
  • a document is generated and edited in such a document processing system.
  • These documents may be written in any language that has the characteristics of a markup language, such as XML.
  • XML markup language
  • the document processing system can be regarded as having two basic configurations.
  • the first configuration is an “execution environment” 1 0 1 which is an environment in which the document processing system operates.
  • the execution environment provides basic utilities and functions that support the system as well as the user during document processing and management.
  • the second configuration is an “application” 1 0 2 composed of applications running in the execution environment. These applications are Includes various representations of body and document.
  • Program nvoker is a basic program that is accessed to activate the document processing system. For example, when a user logs on to a document processing system and starts, Programlnvoker 1 03 force is executed. Program nvoker 1 03 can, for example, read and execute functions added as plug-ins to the document processing system, start and execute applications, and read properties related to documents. The functions of Programl nvoker 1 03 are not limited to these.
  • Program nvoker 103 finds the application, launches it, and runs the application.
  • a number of components such as a plug-in subsystem 104, a command subsystem 105, and a resource module 109 are attached to Program nvoker 1103. These configurations are described in detail below.
  • Plug-in subsystem 104 is used as a highly flexible and efficient configuration to add functionality to a document processing system.
  • the plug-in subsystem 104 can also be used to modify or delete functions that exist in the document processing system.
  • a wide variety of functions can be added or modified using the plug-in subsystem. For example, you can add an Editlet function that works to support the drawing of a document on the screen.
  • the Editlet plug-in also supports editing of the libraries added to the system.
  • the plug-in subsystem 104 includes a Service Broker (service broker: service broker) 1041.
  • ServiceBroker 1 041 is a document processing system By managing the plug-ins added to the system, it mediates the services added to the document processing system.
  • Service 1042 Individual functions that achieve the desired functionality are added to the system in the form of Service 1042.
  • Available types of Service 1042 are: Application service, ZoneFactory (zone factory: zone generator) Service, Editlet (editlet: editor) Service, Comma dFactory (command factory) : Command generation part) Service, ConnectXPath (Connect XP ath: XP ath management part) Service, CSS Computation (CSS calculation part: CSS calculation part) Service, etc., but not limited to these.
  • a plug-in is a unit that can contain one or more ServiceProviders. Each ServiceProvider has one or more classes of Service associated with it. For example, by using a single plug-in with the appropriate software application, one or more services can be added to the system, thereby adding the corresponding functionality to the system.
  • Command subsystem 105 is used to execute commands in the form of commands related to document processing.
  • a user can execute an operation on a document by executing a series of instructions. For example, a user edits an XML DOM tree corresponding to an XML document in a document processing system by issuing an instruction in the form of a command, and processes an XML document. These commands may be entered using keystrokes, mouse clicks, or other valid user interface actions.
  • One command may execute more than one instruction. In this case, these instructions are wrapped (contained) in one command and executed in succession. For example, if a user makes a mistake Suppose you want to replace a given word with the correct word. In this case, the first instruction is to find the wrong word in the document, the second instruction is to delete the wrong word, and the third instruction is to insert the correct word It may be. These three instructions may be wrapped in one command.
  • the command may have an associated function, for example, an “undo” function, described in detail below. These functions may also be assigned to any base class that is used to create objects.
  • the key component of the command subsystem 1 05 is Gommandlnvoker (command launcher: command launcher) 1 05 1 that selectively gives commands and acts to execute them. Although only one Gommandln voker is shown in Fig. 11 (b), one or more Go countries and lnvoker may be used, and one or more commands may be executed simultaneously. Gommandlnvoker 1 05 1 retains the functions and classes necessary to execute commands. In operation, the Command 1 052 to be executed is loaded into the Queue 1 053. Gommandlnvoker generates a command thread that runs continuously.
  • Command types executed by Commandlnvoker 1 05 1 include Undoab I eCommand (cancellation command) 1 054, AsynchronousCommand (asynchronous command) 1 055, and VGGo country and (VC command) 1 056, It is not limited to these.
  • Undoab I eCommand 1 054 is a Go country that can cancel the result of the command if the user wishes. Examples of Undoab leGo country and include cutting, copying, and inserting text. In operation, when a user selects a part of a document and applies a cut command to that part, UndoableG o By using country and, the cut out part can be made “not cut out” if necessary.
  • the VGGo country andl 056 is stored in a Vocabulary Connection Descriptor (VCD) script file.
  • VCD Vocabulary Connection Descriptor
  • These are user-specified commands that can be defined by the programmer.
  • the Command may be a more abstract Go country and combination, for example, to add an XML fragment, delete an XML fragment, or set an attribute. These Go countries and are particularly focused on document editing.
  • AsynchronousCommand 1 055 is a command from the system, such as saving a document, and is executed asynchronously separately from UndoableGommand and VGGommand. AsynchronousCommand cannot be undone because it is not possible with UndoableGommand.
  • Resource 109 is an object that provides several functions to various classes. For example, string resources, icons, and default key bindings are examples of resources used in the system.
  • the application component 102 which is the second main feature of the document processing system, is executed in the execution environment 101.
  • Application component 1102 includes the actual document and various logical and physical representations of the document in the system.
  • application component 102 includes the configuration of the system used to manage documents.
  • the application component 102 further includes a user application (user application) 106, an application core 108, a user interface 107, and a GoreGomponent (core component) 110.
  • UserApplication 10 06 is entered on the system together with Program nvoker 1 03.
  • UserApplication 1 06 is a document, various representations of documents, It becomes an adhesive that connects the user interface necessary for dialogue. For example, suppose a user wants to generate a set of documents that are part of a project. When these documents are loaded, an appropriate representation of the document is generated. User interface functionality is added as part of UserAppli cat on 1 0 6. In other words, UserApp li cat i on 1 0 6 holds both a representation of the document that allows the user to interact with the document that forms part of the project, and various aspects of the document. . Once UserApp li cat i on 1 0 6 is generated, whenever the user wants to interact with the document that forms part of the project ⁇ , the user can easily run the UserApp li cat i on 1 0 You can say 6.
  • CoreComponent 1 1 0 provides a way to share documents between multiple panes.
  • Pane displays a D O M tree and handles the physical layout of the screen.
  • a physical screen consists of multiple panes in the screen that depict individual pieces of information.
  • the document that the user sees on the screen is
  • a Pane can be a RootPane 1 0 8 4 or a SubPane 1 0 8 5.
  • RootPane 1 0 8 4 is a Pane that hits the root of the pane tree
  • SubPane 1 0 8 5 is an arbitrary Pane other than RootPane 1 0 8 4.
  • CoreComponent 1 1 0 also provides fonts and serves as a source of multiple functional operations for documents, such as toolkits.
  • One example of a task performed by CoreComponent 1 1 0 is the movement of a mouse force between multiple panes.
  • Another example of a task to be performed is to mark a part of a document in one pane and copy it onto another pane that contains a different document.
  • the application component 1 0 2 It consists of documents that are processed and managed more. This includes various logical and physical representations of documents within the system.
  • the application core 1 0 8 is a configuration of the application component 1 0 2. Its function is to keep the actual document with all the data it contains.
  • the application core 1 0 8 includes DocumentManager (document manager: document management unit) 1 0 8 1 and Document (document: document) 1 0 8 2 itself.
  • DocumentManager 1 0 8 1 manages Document 1 0 8 2.
  • DocumentManager 1 0 8 1 is RootPane 1 0 8 4, SubPane 1 0 8 5, CI ipBoard (Clip Port) Utility 1 0 8 7, and Snapshot (Snapshot) Utility 1 0 8 8 Also connected to.
  • the G i pBoard utility 1 0 8 7 provides a way to preserve the portion of the document that the user has decided to add to the clip pod. For example, suppose a user wants to cut a part of a document and save it in a new document for later review. In such a case, the clipped part is added to the G i pBoard.
  • the Snapshot utility 1 0 8 8 makes it possible to remember the current state of an application as it transitions from one state to another.
  • FIG. 1 0 7 Another configuration of application components 1 0 2 is a user interface 1 0 7 that provides a means for users to physically interact with the system.
  • the user interface is used by users to upload, delete, edit, and manage documents.
  • the user interface includes Frame 1 0 7 1, MenuBar 1 0 7 2, StatusBar 1 0 7 3 and URLBar 1 0 7 4 .
  • Frame 1 07 1 is considered to be an active area of the physical screen, as is generally known.
  • MenuBarl 072 is a screen area that contains menus that provide selection to the user.
  • StatusBarl 073 is a screen area that displays the execution status of the application.
  • URLBarl 074 provides an area for entering a URL address in order to navigate the Internet.
  • FIG. 12 shows the details of DocumentManager 1 081. This includes the data structures and structures used to represent the document within the document processing system. For clarity, the configuration described in this subsection is described using the MVC paradigm.
  • the DocumentManager 1 081 includes a DocumentGontainer (document container) 2 03 that holds and hosts all the documents in the document processing system.
  • a tool kit 201 that is matched to DocumentManager 1 081 provides various tools used by DocumentManager 1 081.
  • DomService DOM service
  • lOManager input / output manager
  • StreamHandler stream handler
  • These tools are not specifically shown in the figure and are not assigned a reference number, but form a component of the tool kit 201.
  • model (M) includes a DOM tree model 202 of the document. As mentioned above, all documents are represented as DOM trees in the document processing system. The document also forms part of DocumentGontainer 2 03.
  • Zone 209 which is a subset of the DOM tree, contains the associated area of one or more nodes in the DOM tree. For example, only a part of the document can be displayed on the screen, but this part of the visualized document is displayed using Zone 209.
  • ZoneFactory zone factory: zone creation unit
  • Zone represents a part of DOM, but one or more “namespaces” may be used.
  • a namespace is a collection of names that are unique within a namespace. In other words, the same name does not exist in the namespace.
  • Facet 2022 is another configuration within the model (M) part of the MVC paradigm. Facet is used to edit Nodes in the Zone. Facet2022 organizes access to the DOM using procedures that can be executed without affecting the contents of the Zone itself. As explained below, these procedures perform important and useful operations related to Node.
  • Each Node has a corresponding Facet. Instead of directly manipulating Nodes in D O M, DOM integrity is protected by using Facet to perform operations. If the operation is performed directly on Node, several plugins can modify the DOM at the same time, resulting in inconsistencies.
  • the DOM standard established by the W3 C defines a standard interface for operating Nodes. However, in practice, there are operations specific to each POD library or Node. It is convenient to prepare this operation as API. In the document processing system, APIs specific to each node are prepared as Facet and attached to each node. This makes it possible to add useful APIs while complying with the DOM standard. Also, instead of implementing a specific DOM for each POB library, a specific API is added to the standard DOM implementation later, so that various POP libraries can be processed uniformly. A sentence that contains multiple vocabulary in any combination Can be processed properly.
  • a Poch Library is a set of tags (for example, XML tags) belonging to a namespace.
  • a namespace has a set of unique names (here tags).
  • a poch library appears as a subtree of the DOM tree that represents an XML document. This subtree contains Zones. In a specific example, the tag set boundary is defined by the Zone.
  • Zone 209 is generated using a service called ZoneFactory 205.
  • Zone 209 is an internal representation of part of the DOM tree that represents the document.
  • Zone 209 is required to provide access to some of these documents. This logical representation informs the computer how the document is logically represented on the screen.
  • Canvas 210 is a service that acts to provide a logical layout corresponding to the Zone.
  • Pane 21 1 is a physical screen layout corresponding to a logical layout provided by Canvas 210.
  • the user sees only the rendering of the document with text and images on the display screen. Therefore, the document must be rendered on the screen by the process of drawing characters and images on the screen.
  • the document is drawn on the screen by Canvas 210 based on the physical layout provided by Pane 21 1.
  • Ganvas 210 corresponding to Zone 209 is generated using Editlet 206.
  • the DOM of the document is edited using Editlet 206 and Ganvas 210.
  • Editlet 206 and Ganvas 210 use Facet corresponding to one or more Nodes in Zone 209. These services do not directly operate the nodes in the Zone and DOM. Facet is operated using Gommand207.
  • Canvas 210 which provides a logical layout on the screen, accepts this powerful operation. Canvas 210 can let Facet execute the corresponding action. Due to this relationship, The Rikiichi Sol Subsystem 2 0 4 functions as a controller (C) of the MVC paradigm for DocumentManager 1 0 8 1.
  • Ganvas 2 1 0 also has a task to handle events. For example, Canvas 2 1 0 handles events such as mouse clicks, focus movements, and similar actions triggered by the user.
  • Documents in a document processing system can be viewed from at least four perspectives. 1) the data structure used to maintain the content and structure of the document in the document processing system, 2) a means for editing the content of the document without affecting the integrity of the document, 3) on the screen of the document 4) The physical layout of the document on the screen. Zone, Facet, Canvas, and Pane represent the components of the document processing system that correspond to the above four viewpoints.
  • UndoManager Undo Manager 2 1 2 1 holds operations on all documents that may be canceled by the user.
  • UndoManager 2 1 2 1 holds the operation of UndoableEdit (Undoable Edit: Undoable Edit) 2 1 2 2.
  • the controller portion of the MVC may include a force-sol subsystem 20 4.
  • Rikiichi Sol Subsystem 2 0 4 receives input from the user. Squeeze. These inputs generally have the character of commands and / or editing operations. Therefore, the Rikiichi Sol Subsystem 204 can be considered as the controller (C) part of the MVC paradigm related to DocumentManager 1 081.
  • Canvas 210 represents the logical layout of the document to be presented on the screen.
  • Ganvas 210 may include a box tree 208 that logically represents how the document looks on the screen. This box tree 208 will be included in the view (V) portion of the MVC paradigm associated with DocumentManager 1 081.
  • XML documents can be handled by mapping them to other representations, and if the mapped destination representation is edited, the editing is consistent with the original XML document.
  • a document described in a markup language such as an XML document, is created based on a library defined by a document type definition.
  • a Pokéebra is a set of tags. Since a pocabulary may be arbitrarily defined, there can be an infinite number of pocabularies. However, it is impractical to provide a dedicated processing / management environment for each of the many possible libraries. Pocabulary Connection provides a way to solve this problem
  • a document may be written in more than one markup language.
  • the document may be described in, for example, XHTML (extensible HyperText Markup Language), SVG (Scalable Vector Graphics), Math ML (Mathematical Markup Language), or other markup languages.
  • the markup language may be found in the same way as a tag library in XML.
  • the Pocabulary is processed using the Pocabulary Laguin. Documents described in a vocabulary where plug-ins are not available in the document processing system are displayed by mapping to documents in another vocabulary where plug-ins are available. This feature enables proper display of vocabulary documents without plug-ins.
  • the poker library connection includes the ability to obtain a definition file and map between two different vocabularies based on the obtained definition file.
  • a document written in one Poch library can be mapped to another Poch library.
  • the PB library connection allows a document to be displayed and edited by a display / edit plug-in corresponding to the Pb library to which the document is mapped.
  • each document is generally described in the document processing system as a DOM tree having a plurality of nodes.
  • the “definition file” describes the correspondence between each node and other nodes. It is specified whether the element value and attribute value of each node can be edited. An arithmetic expression using the element value or attribute value of the node may be described.
  • a destination DOM tree to which the definition file is applied is generated. In this way, the relationship between the source DOM tree and the destination DOM tree is established and maintained.
  • the Pocabular connection monitors the correspondence between the source DOM tree and the destination DOM tree.
  • the Pb library connection Upon receiving an editing instruction from the user, the Pb library connection changes the associated node in the source D O M tree. A “mutation event” is issued to indicate that the source D O M tree has changed, and the destination D O M tree is changed accordingly.
  • the Pocabulary Connection Subsystem which is a part of the document processing system, provides a function that enables multiple representations of a document.
  • FIG. 13 shows a Vocabulary Connection (VC) subsystem 300.
  • the VC subsystem 300 provides a way to maintain the consistency of two alternative representations of the same document.
  • the two representations may be representations of the same document in two different pockets.
  • one may be the source DOM tree and the other may be the destination DOM tree.
  • the functions of the POB library connection subsystem 300 are realized in a document processing system using a plug-in called Vocabulary Connection 301.
  • Vocabulary Connection 301 For each Vocabulary 305 in which the document is represented, a corresponding plug-in is required. For example, if a part of a document is described in HTML and the rest is described in SVG, a plug-in plug-in corresponding to HTML and SVG is required.
  • the VocabularyGonnection plug-in 301 generates an appropriate VGGanvas (Pocket library connection canvas) 310 for Zone 209 or Pane 211 corresponding to the appropriate Vocabulary 305 document.
  • VGGanvas Pocket library connection canvas
  • changes to Zone 209 in the source DOM tree are propagated to the corresponding Zone in another DOM tree 306 by the transformation rule.
  • a conversion zole is described in the form of a Vocabulary Connection Descriptor (VCD).
  • VCD Vocabulary Connection Descriptor
  • Connector 304 is connected to the source node of the source D OM tree and the destination Chillon Connects to DOM tree destination node.
  • Gonnector3 04 acts to see modifications (changes) to the source node in the source DOM tree and the source document corresponding to the source node. Then modify the node of the corresponding destination DOM tree.
  • Gonnector304 is the only object that can modify the destination DOM tree. For example, the user can make modifications only to the source document and the corresponding source DOM library. Connector 304 then makes the corresponding modifications to the destination DOM tree.
  • Connector 304 is logically linked to form a tree structure.
  • the tree formed by Connector 304 is called GonnectorTree.
  • the Connector 304 is generated using a service called GonnectorFactory (connector factory: connector generation unit) 303.
  • GonnectorFactory 303 creates Connector 304 from the source document and links them to form GonnectorTree.
  • the VocabularyGonnectionManager 302 holds a GonnectorFactory 303.
  • the Pokémonary is a set of tags in the namespace.
  • Vocabulary 305 is generated for a document by Vocabu IaryConnection 301. This is done by parsing the document file and generating an appropriate Vocabulary Connection Manager 302 for mapping between the source DOM and the destination D OM. Further, an appropriate relationship is created between the GonnectorFactory 303 that generates the Connector, the ZoneFactory 205 that generates the Zone 209, and the Editlet 206 that generates the Canvas corresponding to the node in the Zone. When a user disposes of or deletes a document from the system, the corresponding VocabularyGonnectionManager 302 is deleted.
  • the Vocabulary 305 generates VGGanvas 310. Further, a connector 304 and a destination DOM tree 306 are generated correspondingly.
  • Sources DO M and Canvas correspond to model (M) and view (V), respectively.
  • this kind of expression is Only meaningful if it can be drawn on the screen.
  • the depiction is done with Pokayabra Rib Lagoin.
  • Pocabulary plug-ins are provided for major vocabulary, eg, XHTML, SVG, and Math ML.
  • Pokaya brarib lagins are used in conjunction with the target pokary library. They provide a way to map between podapuraries using vocabulary connection descriptors.
  • Such mapping is only meaningful if the target Pocabula mapping is possible and the method depicted on the screen is predefined.
  • a rendering method is a standard defined by organizations such as W 3 C, such as X H TM L.
  • VGGanvas is used when a poker library connection is required.
  • the source Ganva s is not generated because the source view cannot be generated directly.
  • VGGanvas is created using GonnectorTree. This VGGanvas only handles event conversion and does not assist in rendering the document on the screen.
  • the purpose of the Pocabulary Connection Subsystem is to generate and maintain two representations of the same document simultaneously.
  • the second representation is also in the form of a DOM tree, which has already been described as a destination DOM tree. To see the document in the second representation, we need DestinationZone, Canv as and Pane.
  • DestinationGanvas 308 provides a logical layout of the document in the second representation.
  • DestinationGanvas308 uses user interfaces such as cursors and selections to depict documents in destination representations. Provide chair function. Events that occur in DestinationGanvas308 are fed to Gonnector. DestinationGanvas 308 notifies Connector 304 of events specific to the mouse event, key event, drag and drop event, and document destination (second) representation of the library.
  • VC POB library connection
  • the library connection command subsystem 313 generates a VGGo country and (pocket connection command) 315 used for execution of instructions related to the protocol connection subsystem 300.
  • VGGo country and can be generated by using the built-in Go country andTemplate (command template) 31 8 and / or by generating commands from scratch in the script subsystem 31 4 using script language can do.
  • Command templates include, for example, the “lf” command template, the “When” command template, and the “Insert” command template. These templates are used to create VGGommand.
  • the X P at h subsystem 31 6 is an important component of the document processing system, and supports the implementation of the poker library connection.
  • Connector 304 generally contains xpath information. As mentioned above, one of the tasks of a poker library connection is to reflect changes in the source DOM tree in the destination DOM tree.
  • the xpath information contains one or more xpath expressions that are used to determine the subset of the source DOM tree that should be monitored for changes / modifications.
  • the source DOM tree is a DOM tree or Zone that represents a document in the vocabulary before being converted to another vocabulary. No. of source DOM tree A node is called a source node.
  • the destination DOM tree is a DOM tree that represents the same document in a different vocabulary after being transformed by mapping, as described above in connection with the Pocabulary connection. Zone. Destination D O M Tree nodes are called destination nodes.
  • GonnectorTree is a hierarchical expression based on a Connector representing the correspondence between a source node and a destination node.
  • the Connector monitors the source node and modifications made to the source document and modifies the destination DOM tree.
  • the Connector is the only object that is allowed to modify the destination DOM tree.
  • An event is a way to describe and execute a user action executed on a program.
  • Many high-level languages, such as J a V a rely on events that describe user actions.
  • programs had to actively gather information to understand user actions and execute them themselves. For example, after a program initializes itself, it enters a loop that repeatedly checks the user's actions to take appropriate action when the user takes action on the screen, keyboard, mouse, etc. Means. However, this process is cumbersome. In addition, it requires a program that consumes CPU cycles and loops while waiting for the user to do something.
  • the document processing system defines and uses its own events and how to handle these events.
  • a mouse event is an event that occurs from a user mouse action.
  • User actions including the mouse are passed to the mouse event by Canvas 2 10.
  • Canvas can be said to be at the forefront of interaction by users of the system. If necessary, the canvas at the front passes the content related to the event to the child.
  • Keest event will flow from Canvas 2 1 0.
  • Key Stroke events have immediate focus. That is, it is related to work at any moment. Keystroke events entered on Ganvas 2 1 0 are passed to their parents. Keystrokes are handled by different events that can handle string insertion. Events that handle string insertion occur when a character is inserted using the keyboard. Other “events” include, for example, other events that are treated like drag events, drop events, and mouse events.
  • VocabularyConnect i on 3 0 1 3 ⁇ 4 Use the Dest i nat i onCanvas (7—the example XHTMLGanvas l 1 0 6 is the event that occurred, eg Event, key-pode event, drag-and-drop event, and event specific to poker library. These events are notified to the connector 304. More specifically, as shown in Figure 21 (b), the event flow in the VocabularyGonnection plug-in 301 is as follows: SourcePane 1 1 03, VCCanvas 1 1 04, DestinationPane 1 1 05, DestinationGanvas 1 06, go through the destination DOM tree and Go nnector ree3 ⁇ 4r.
  • Programlnvoker 1 03 is a basic program in the execution environment that is executed to start the document processing system. As shown in Figure 11 (b) and Figure 11 (c), UserApplication 10 06, ServiceBroke r 1041, Command I nvoker 1 051, and Resource 1 09 are all in Program I nvoker 1 03. Connected. As described above, the application 102 is a component that is executed in the execution environment. Similarly, ServiceBroker 1 0 41 manages plug-ins that add various functions to the system. On the other hand, Go country ndlnvoker 1 051 executes the instructions provided by the user and holds the classes and functions used to execute the commands.
  • ServiceBroker 1 041 will be described in more detail with reference to FIG. 14 (b). As mentioned above, ServiceBroker 1 041 manages plug-ins (and related services) that add various functions to the system.
  • Service 1 042 is the lowest layer that can add or change features to the document processing system.
  • “Service” consists of two components of ServiceGategory401 and ServiceProvider 402. As shown in FIG. 14 (c), one 361 ⁇ 6031: 680 ⁇ 40 1 can have multiple associated ServiceProviders 402. Each ServicePro V i der acts to run part or all of a particular Service Gategory. On the other hand, ServiceGatego401 defines the type of Service.
  • Service is 1) “spot color service” that provides a specific spot color to the document processing system, 2) “ablation service” that is an application executed by the document processing system, and 3) the entire document processing system. It can be classified into three types: “environmental services”, which provide the necessary characteristics over a wide range.
  • FIG. 14 An example of Service is shown in Figure 14 (d). In Gat egory of application Service, it is a row of system utility card ⁇ corresponding ServiceProvider. Similarly, Editlet 206 is a Category, and HTMLEditlet and SVGEdit let are corresponding ServiceProviders. ZoneFactory 205 is another Category of Service, and has a corresponding ServiceProvider (not shown).
  • plug-ins have already been described as adding functionality to a document processing system, they may be considered a unit consisting of several ServiceProviders 402 and their associated classes. Each plug-in has dependencies and ServiceGategory 401 described in the declaration file.
  • Figure 14 (e) shows further details about the relationship between Programlnvoker 1 03 and UserApplication 1 06. Necessary documents and data are loaded from storage. All necessary plug-ins are loaded on ServiceBroker 1 04 1. ServiceBroker 1 04 1 holds and manages all plug-ins. Plug-ins can be physically added to the system and their functions can be loaded from storage. When the plug-in content is loaded, ServiceBroker 1 04 1 defines the corresponding plug-in. Next, the corresponding UserApplication 1 06 is generated, loaded into the execution environment 1 0 1, and attached to the Programlnvoker 1 03.
  • Figure 15 (a) shows further details about the configuration of the application service loaded on Programlnvoker 1103.
  • Command Invoker 1 05 which is a component of command subsystem 1 05, activates or executes Command 1 052 in Programlnvoker 1 03.
  • Command 1 052 is a document processing This command is used to process documents such as XML and edit the corresponding XML DOM tree in the system.
  • Command Invoker 1 051 holds classes and functions necessary for executing Comma nd1 052.
  • ServiceBroker 1 041 is also executed in Program nvoker 1 03.
  • UserApipication 1 06 is connected to the user interface 1 07 and GoreGomponent 1 1 0.
  • GoreGomponent 1 1 0 provides a way to share documents between all panes.
  • GoreGomponent 1 1 0 provides additional fonts and acts as a toolkit for Pane.
  • FIG. 15 (b) shows the relationship between Frame 1 07 1, MenuBar 1 072, and StatusBar 1 07 3.
  • Figure 16 (a) provides further explanation of the application core 108 that holds all documents, and parts of documents and data belonging to the documents.
  • Gor eComponent 1 1 0 is attached to DocumentManager 1 081 that manages document 1 082.
  • DocumentManager 1 081 is the owner of all documents 1 082 stored in the memory associated with the document processing system.
  • DocumentManager 1 081 is also connected to Root Pane 1 084 to facilitate the display of the document on the screen.
  • the functions of GI ipBoard 1 087, SnapShot 1 088, Drag & Drop 601 and Over Iay 602 are also attached to GoreGomponent 1 1 0.
  • SnapShot 1 088 is used to restore the application state. When the user starts SnapShot 1 088, the current state of the application is detected and stored. Then, when the application state changes to another state, the stored state contents are preserved. SnapShotl 088 is illustrated in Figure 16 (b). In operation, when an application moves from one URL to another, SnapShotl 088 remembers the previous state in order to make it possible to seamlessly perform the previous and next operations.
  • Document organization in DocumentManager Figure 17 (a) shows further explanation of DocumentManager 1 081 and how documents are organized and maintained in DocumentManager.
  • DocumentManager 1 081 manages document 1 082.
  • one of the documents is RootDocument 701 and the remaining document is SubDocument 702.
  • Do cumentManager 1 081 is connected to RootDocument 701, and RootDocument 7001 is connected to all SubDocuments 702.
  • DocumentManager 1 081 is an object that manages all documents 1 082 00 (51 ⁇ 6111: 00111: 3 ⁇ 6 Tools that form part of tool kit 201 (eg, XM L tool kit) including D0MService 703 and lOManager 704 are also supplied to DocumentManager 1 081.
  • D0MService 703 generates a DOM tree based on the document managed by DocumentManager 1 081.
  • Each Document 705 is managed by the corresponding DocumentGontainer 203 regardless of whether it is a RootDocument 701 or a SubDo cument 702.
  • Figure 17 (b) shows how documents A_E are arranged hierarchically.
  • Document A is a RootDocument.
  • Document B—D is a SubDocument of Document A.
  • Document E is a SubDocument of Document D.
  • the left side of Fig. 17 (b) shows an example of the same document hierarchy displayed on the screen.
  • Document A the RootDocument
  • Document B_D which is a SubDocument of Document A
  • Document E which is a SubDocument of Document D
  • UndoManager Undo Manager: Undo Manager
  • UndoWrapper Undo Wrapper
  • UndoManager 706 and UndoWrapper 707 are used to execute undoable commands.
  • the undo operation takes into account changes that affect other documents in the hierarchy and maintains consistency among all documents in a chained hierarchy, for example, as shown in Figure 17 (b). Guarantee that.
  • UndoWrapper 707 wraps the undo objects related to SubDocument in DocumentGontainer 203 and binds them to the undo object related to RootDocument. UndoWrapper 707 executes collection of undoable objects that can be used in UndoableEditAcceptor (undoable edit acceptor).
  • UndoManager 706 and the UndoWrapper 707 are connected to the Undoab IEEditAcceptor 709 and the UndoableEditSource (Undoable Edit Source) 708.
  • Document 705 may be UndoableEditSource 708 or the source of an editable edit object.
  • Figures 18 (a) and 18 (b) provide further details about the undo framework and undo commands.
  • UndoCommand 80 1, RedoCommand 802, and UndoableEditGommand803 are commands that can be loaded on Gommandlnvoker 1 05 1 as shown in Fig. 11 (b) and executed in order. Is done.
  • UndoableEditGommand803 is further attacked by Undoable EditSource 708 and Undoab IeIdAcceptor 709.
  • “Foo” EditGommand804 and “bar” EditGommand 805 are examples of Undoab IeEditC ommand.
  • Figure 18 (b) shows the execution of UndoableEditGommand.
  • Undoab IeIdAcceptor 709 is attacked by UndoableEditSource 708 which is a DOM tree of Document 705.
  • the second step S2 Based on commands issued by the user, Document705 is edited using the DOM API.
  • the mutation event listener is notified that a change has been made. That is, in this step, the listener that monitors all changes in the DOM tree detects the editing operation.
  • UndoableEdit is stored as an object of UndoManager 706.
  • 5th step S5 it is defeated from UndoableEditAcceptor 709 ⁇ UndoableEditSource708.
  • the UndoableEditSource 708 may be the Document 705 itself.
  • Figure 19 (a) shows an overview of how a document is loaded into the document processing system. Each step is detailed in relation to a specific example in Figures 24-28.
  • a document processing system generates a DOM from a binary data stream consisting of data contained in a document.
  • ApexNode anapex node
  • the corresponding Pane is identified.
  • the identified Pane generates Zone and Canvas from ApexNode and physical screen surface.
  • the Zone then creates Facets for each node and provides the information needed for them.
  • Canvas generates a data structure for rendering nodes from the DOM tree.
  • the document is loaded from storage 901.
  • a DOM tree 902 of the document is generated.
  • a corresponding DocumentGontainer 903 is created to hold the document.
  • DocumentGonta iner 903 is attached to DocumentManager 904.
  • a DOM tree contains a root node and sometimes multiple secondary nodes.
  • a DOM tree may have, for example, an SV G subtree as well as an XH TM L subtree.
  • the XH TM L sub-tree has an XH TM L ApexNode 905.
  • the SVG subtree has an SVG ApexNode 906.
  • step 1 ApexNode 906 force is attached to Pane907, which is the logical layout of the screen.
  • Pane907 asks GoreGomponent, who is PaneOwner 908, a ZoneFactory for ApexNode 906.
  • step 3 PaneOwner 908 returns a ZoneFactory and an Edi tl et which is a GanvasFactory for ApexNode 906.
  • Step 4 Pane907 force ⁇ Zone909 is generated. Zone909 is attached to Pane 907.
  • step 5 Zone909 generates a facet for each node and attaches to the corresponding node.
  • Step 6 Pane 907 force ⁇ Ganvas9 1 0 is generated. Canvas 9 1 0 is attacked by Pane 907.
  • Ganvas9 1 0 includes various commands.
  • step 7 Ganvas9 10 builds a data structure for rendering the document on the screen. For XH TM L, this includes a box tree structure.
  • Figure 19 (b) shows an overview of the Zone configuration using the MVC paradigm.
  • Model (M) since Zone and Facet are inputs related to the document, Model (M) includes Zone and Facet. Since the canvas and the data structure for rendering the document on the screen are the output that the user sees on the screen, the view (V) corresponds to the canvas and the data structure. Since Command executes control operations on the document and its various relationships, Control (C) includes Go Country and included in Canvas.
  • the document used in this example contains both text and images.
  • the text is X Represented using HTML, images are represented using SVG.
  • Figure 20 details the MVC representation of the relationship between the document components and the corresponding objects.
  • Document 1 00 1 is attached to DocumentContainer 1 002 that holds Document 1 00 1.
  • the document is represented by a DO M tree 1 003.
  • the DOM tree contains ApexNode 1 004.
  • ApexNode is represented by a black circle. Nodes that are not vertices are represented by white circles. The Facet used to edit a node is represented by a triangle and is attached to the corresponding node. Since the document has text and images, the DOM tree of this document contains an XHTML portion and an SVG portion.
  • ApexNode 1 004 is the top node of the XH TM L subtree. This is attacked by XHTMLPane 1 005, the top pane for the physical representation of the XHTML portion of the document. ApexNode 1 004 is also attacked by XHTMLZone 1 006, which is part of the document's DOM tree.
  • Facet corresponding to Node 1 004 is also attached to XHTMLZone 1 006.
  • X HTMLZone 1 006 is attached to XHTMLPane 1 005.
  • XHTMLEditlet generates XHTMLGanvas 1007, which is a logical representation of the document.
  • XHTMLGanvas 1 007 is attacked by XHTMLPane 1 005.
  • XHTMLGanvas 1007 generates BoxTree 1 009 for the X HTML component of Document 1 00 1.
  • Various Go countries and 1 008 required to hold and render the X H TM L portion of the document are also added to XHTMLGanvas 1 007.
  • ApexNode 1 0 1 0 in the document's SVG subtree is attached to SVGZone 1 0 1 1 that is part of the DOM tree of Document 1 00 1 that represents the SVG component of the document.
  • the ApexNode 1 0 1 0 is attached to SVGPane 1 0 1 3 which is the highest Pane in the physical representation of the SVG part of the document.
  • SVGGanvas 1 0 1 2 representing the logical representation of the S VG part of the document is generated by SVGEditlet and attached to SVGPane 1 0 1 3.
  • the data structure and commands for rendering the SVG part of the document on the screen are attacked by SVGGanvas. For example, this data structure contains circles, lines, rectangles, etc. as shown. It's okay.
  • FIG. 21 (a) shows a simplified MV relationship in the XH TM L component of Document 1001.
  • the model is XHTMLZonel 1 01 for the X H TM L component of Document 1 001.
  • the XHTMLZone tree contains several Nodes and their corresponding Facets.
  • the corresponding XHTMLZone and Pane are part of the model (M) part of the MV C paradigm.
  • the View (V) portion of the MVC paradigm is the corresponding X HTML Canvas 1 1002 and BoxTree of the X H TM L component of Document 1 001.
  • the XHTML part of the document is rendered on the screen using Canvas and Go country and included. Events such as keyboard and mouse input go in the opposite direction, as shown.
  • SourcePane has an additional function: the role as a holder of DOM.
  • Figure 21 (b) provides a library connection for the Document "! 001 component shown in Figure 21 (a).
  • SourcePane 1 1 03 acting as a DOM holder, is the source D OM tree of the document.
  • Gonne ctorTree is created by GonnectorFactory and creates DestinationPane 1 1 05 which also functions as the destination DOM holder
  • Destinatio nPane 1 1 05 is a layout of the XHTMLDestinationGanvas 1 1 06 in the form of a box tree. Is done.
  • Plug-in subsystems are used to add or exchange functionality to a document processing system.
  • the plug-in subsystem includes ServiceBroker 1 041.
  • ZoneFactoryService 1 201 that is attacked by Service Broker 1 041 generates a Zone for a part of the document.
  • EditletService 1 202 generates a Ganvas corresponding to the Node in the Zone.
  • ZoneFactory examples are XHTMLZoneF actory 1 21 1 and SVGZoneFactory 1 21 2 which generate XHTMLZone and SVGZone, respectively.
  • the text component of the document may be represented by generating XHTMLZone, and the image may be represented using SVGZone.
  • EditletService examples include XHTMLEditlet 1 221 and SVGEditlet 1 222.
  • FIG 22 (b) shows further details related to the Pocabulary connection.
  • the POB library connection is an important feature of a document processing system, and enables consistent expression and display of documents in two different ways.
  • the VGManager 302 that holds the GonnectorFactory 303 is a part of the poker library connection subsystem. GonnectorFactory 303 generates a connector 304 for the document.
  • the Connector monitors the nodes in the source D OM and modifies the nodes in the destination DOM to maintain consistency between the two representations.
  • Temp late 31 7 represents the conversion rules of several nodes.
  • a poker library connection descriptor (VCD) file is a list of Templates that represent a number of rules that transform an element or set of elements that satisfy a particular path or rule into another element.
  • Temp late 31 7 and GommandTemplate 31 8 are all attached to VGMana ger302.
  • VGManager is an object that manages all sections in a V CD file. One VGManager object is generated for one VCD file.
  • Figure 22 (c) provides further details related to the Connector.
  • GonnectorF actory 303 (Connector 3 ⁇ 4: Generate from the i source document.
  • ConnectorFactory 3 03 is attached to Vocabulary, Template, and ElementTemplate, and generates Vocabu IaryConnector TemplateConnector ElementGonnector, respectively.
  • the VGManager 302 holds a ConnectorFactory 303.
  • Raw Vocabulary The corresponding VCD file is read to complete. In this way, Connect orFactory 303 force ⁇ is generated.
  • This GonnectorFactory 303 is related to a ZoneFactory that generates a Zone and an Editlet that generates a Canvas.
  • VGGanvas also creates an ApexNode Connect or in the source DOM tree or Zone. Child connectors are recursively generated as needed. Gonnec torTree is created by the set of templates in the V CD file.
  • a template is a set of rules for converting markup language elements into other elements. For example, each template is matched to the source DOM tree or Zone. If it matches properly, a vertex connector is created. For example, the template “A / * / D” matches all branches that start at node A and end at node D, regardless of what nodes are in between. Similarly, “ ⁇ B” matches all “B” nodes from the root.
  • FIG. 23 shows an example VCD script using VGManager and Connect orFactoryTree for the “MySampleXML” file. Shows the section, template section and corresponding components in VGManager in the script file.
  • the attribute “match” becomes “sample: rootj”
  • “label” becomes “MySampl eXMLj”
  • “cal temp latej becomes“ sample templatej ”.
  • Vocabulary includes a vertex element as "sampl e: root j" in the "MySampl eXML" VGManager.
  • the corresponding UI label is "MySampl eXMLj.
  • the tag is” vcd: templatej, 3 ⁇ 4 Hij (i “sample: templatej
  • Figure 24-28 shows a detailed description of loading the document “MySampleXML”.
  • the document is loaded from storage 1 405 forces.
  • the DOMService generates a DocumentGontaineM 401 that matches the D OM tree and DocumentManager 1 406.
  • DocumentGontaineM 4 01 is attached to DocumentManager 1 406.
  • the document contains XHTML and MySampleXML subtrees.
  • XHTML ApexNode 1 403 is the top node of XHTML with tag rxhtml: htmlj.
  • ApexNode 1 404 of “MySampleXML” is the top node of “MySampl eXMLj” with the tag “sample: rootj”.
  • RootPane generates XHTMLZone, Facet, and Canvas of the document.
  • Panel 407, XHTMLZone 1 408, XHTMLCanvas 1 409, and BoxTree 1 410 are generated corresponding to ApexNode 1 403.
  • step 3 shown in Fig. 24 (c) a tag "samp le: root" that XHTMLZone does not know is discovered and a SubPane is generated from the XHTMLGanvas area.
  • Step 4 shown in Fig. 25 SubPane can handle "sample: rootj and obtain a ZoneFactory that can generate an appropriate Zone.
  • This ZoneFactory is in a Vocabulary where ZoneFactory can be executed. It contains the contents of the Vo Ibu IarySection on “MySampl eXML”.
  • step 5 shown in FIG. 26 a Vocabulary force ⁇ DefaiHtZone 1 601 corresponding to "MySampleXML" is generated.
  • a corresponding Editlet is created and SubPane 1 501 is provided to create a corresponding Ganvas. Editlet is generated as VGGanvas 3 ⁇ 4 :. And that's TemplateSection3 ⁇ 4rP ⁇ .
  • GonnectorFactoryTree Ru was also included ⁇ .
  • GonnectorFactoryTree creates all Gonn ector3 ⁇ 4r that will become GonnectorTree.
  • each Connector creates a destination DOM object.
  • Some of the connectors contain xpath information.
  • the xpath information contains one or more xpath expressions that are used to determine the subset of the source DOM tree that needs to be monitored for changes / modifications.
  • the Pocabulary creates a destination DOM tree one Dest i nat i onPane from the source DOM pane. This is done based on the SourcePane.
  • the ApexNode in the destination tree is attached to the DestinationPane and the corresponding Zone.
  • the DestinationPane is provided with its own Editlet that creates a DestinationGanvas and builds data structures and commands to render the document in the destination format.
  • Figure 29 (a) shows the flow when an event occurs on a node that does not have a corresponding source node and exists only in the destination tree.
  • Events acquired by Canvas such as mouse events and keyboard events, are passed to the destination interface and transmitted to the EI ementTemp IateConnector. Since ElementTemplateGonnector does not have a corresponding source node, the transmitted event is not an edit operation on the source node.
  • ElementTemplateGonnector executes the corresponding Action if it is communicated and the new event matches the command described in GommandTemplate. If there is no matching command, El ementTemp IateConnector ignores the transmitted event.
  • Figure 29 (b) shows the flow when an event occurs on the node of the destination tree associated with the source node by TextOfGonnector.
  • the TextOf Connector gets the text node from the node specified by XP ath in the source D OM tree and maps it to the node in the destination DOM tree. Events acquired by Ganva s, such as mouse events and keyword events, pass through the destination tree and are transmitted to TextOfGonn ector. TextOf Connector maps the transmitted event to the corresponding edit command of the source node, and loads it in Queuel 053.
  • An edit command is a set of DOM API calls that are executed via Facet. When a command placed on the queue is executed, the source node is edited.
  • Text OfGonnector reconstructs the destination tree so that changes in the source node are reflected in the corresponding destination node.
  • the template including T extOf Connector includes a control statement such as “for eachj” or “for loopj”
  • the GonnectorFactory re-evaluates this control statement, rebuilds Tex tOfGonnector, and then the destination tree. Is rebuilt.
  • VCD definition file
  • FIG. 30 shows a configuration of the document processing apparatus according to the present embodiment.
  • the document processing apparatus 100 includes a VCD file to be debugged and an XML to which the VCD is applied.
  • An acquisition unit 29 for acquiring a document and a debugger 70 for providing a debugging environment for the acquired V CD file are further provided.
  • Debugger 70 has screen display ⁇ 157 1, Source view display section 72, 0 view_display section 73, destination view display section 74, property view display section 75, breakpoint setting section 76, execution control section 77, shaping Part 78, and pop-up window display part 79.
  • FIG. 31 shows a sample document for explaining the function of the debugger 70.
  • This XML document has multiple “hw: message” elements as child elements of the “hw: document” element.
  • the “hw: message” element contains “Hel lo Wor Id!” And “Hello xml World”. ! "Etc. as a text node.
  • This XML document is associated with the V CD file “HelloWorld2. Xvcd” as a processing system.
  • FIG. 32 shows a VCD file associated with the XML document shown in FIG. VCD file ⁇ loWorld2.
  • the text node of the second element “hw: message” is assigned to the variable “body_title”, which is displayed as the “h1” element of XHT ML.
  • the third element “hw: message” is assigned to the variable “nodeToShow” and its contents are displayed.
  • Figure 33 shows an example of the debug screen displayed by the debugger.
  • the source view that displays the contents of the source document to be processed the VCD view that displays the contents of the VCD file for processing the source document, and the destination that converted the source document using the VC D file
  • a destination view that displays the contents of the document a property view that displays property information such as values assigned to variables, and a history view that displays the call history of templates and functions are provided.
  • the execution control unit 77 causes the VC unit 80 to execute the instructions described in the VCD file in accordance with an instruction from the user.
  • the screen display unit 71 displays the execution status of the execution control unit 77 on the screen.
  • Source view display section 72 displays the current conversion target line in the source view so that it can be identified
  • VCD view display section 73 displays the current processing line in the VCD view so that it can be identified.
  • the destination view display section 74 displays the row converted to the destination view in an identifiable manner
  • the property view display section 75 displays the variable, property, or user set in the VCD file in the property view. Display the contents of the data.
  • VCD script is executed as a step for each node.
  • the execution control unit 77 provides three functions of step-in, step-out, and step-over in order to control the execution of the V CD script in units of steps.
  • the step-in function advances the flow of execution to “in the selected node”. If there is no child node in the content to be executed, execution proceeds to the sibling node.
  • elements with global scope global variables, user data, etc.
  • template elements The selection position is moved in the order of “xvcd: vocabulary” element and “xvcd: template” element. The movement order of the selected position does not depend on the description order in the VCD script. Instead of selecting from the top in the VCD script, elements with global scope are selected first, followed by template elements.
  • Fig. 34 shows the state in which the processing of the V CD script is advanced to the “html” element.
  • step-in is executed with the “html” element selected, the flow of execution proceeds in the “html” element.
  • the screen at this time is shown in FIG.
  • the destination DOM tree is created in the destination view and the “html” element is selected. This means that VC unit 80 has created an “html” element in the destination DOM tree. Since the flow of execution has been advanced one step inside the “html” element, the “head” element is selected.
  • step-out function advances the flow of execution up to "the node that called the selected node". If no node has called the selected node, execution proceeds to the sibling node.
  • Fig. 36 shows the state where the processing of the VCD script is advanced to the "title” element. If step out is executed with the “title” element selected, the flow of execution proceeds to the end tag of the “head” element that called the “ti tlej element”. This state is shown in Fig. 37.
  • step over function advances the flow of execution until "immediately after the call of the selected node is completed". If there is no child node in the content to be executed, execution proceeds to the sibling node.
  • Fig. 38 shows the state in which the processing of the V CD script is advanced to the "body” element. If step over is executed while the start tag of the “body” element is selected, all processing in the “body” element is completed and the flow of execution proceeds to the end tag of the “body” element. This state is shown in FIG.
  • Breakpoint setting section 7 6 sets the point at which execution of the V C D script by execution control section 7 7 is paused.
  • a breakpoint is a “location” where execution of a V C D script stops halfway.
  • the execution control unit 7 7 temporarily stops the execution of the V C D script at the “location” where the breakpoint is set.
  • the V C D view display section 7 3 displays the elements that can set breakpoints in the V C D view in a different display format from the elements that cannot be set. This makes it easy for the user to know where breakpoints can be set.
  • the breakpoint setting section 76 sets a breakpoint on that line.
  • the breakpoint setting section 7 6 displays an icon indicating that at the position where the breakpoint is set. Breakpoints can be temporarily disabled.
  • the execution controller 7 7 pauses execution at the line where a valid breakpoint is set.
  • breakpoint setting section 7 6 displays the position of the set breakpoint with the name and line number of the VCD file. At this time, whether it is valid or invalid is also displayed.
  • the breakpoint setting unit 76 When the breakpoint setting unit 76 is requested to search for an element in the VCD file in order to set a breakpoint, it displays the search dialog screen shown in Fig. 41 and accepts the specification of the element to be searched.
  • the breakpoint setting unit 76 searches for the element in the VCD file and sets a breakpoint on the line of the element.
  • Breakpoint setting part 7 6 is an element that can set breakpoints. Are presented on the search dialog screen shown in Figure 41. For example, “xvcd: xvcdj element cannot set breakpoints, so it is not presented in the search dialog screen.
  • Breakpoints can be set on the following element nodes, literal result elements in template rules, and text nodes.
  • nstruct ion : cal to next, ⁇ instruct ion: choose
  • nstruct ion : co I or-chooser, ⁇ instruct ion: command-exists
  • nstruct ion di rectory-chooser, ⁇ i nstruct i on: f i I e-chooser nstruct ion :: font-family-chooser ⁇ instruct ion: for-each
  • nstruct ion show_status_message
  • ⁇ instruct ion temp I ate-chooser nstruct ion :: throw
  • ⁇ instruct ion tree-message
  • nstruct ion : try, ⁇ instruct ion: variable
  • xvcd app I y-temp I ates
  • ⁇ xvcd app I y-vocabulary
  • xvcd choose, xvcd: comb i ne
  • xvcd if, xvcd: insert xvcd: message, ⁇ xvcd: move
  • xvcd set-attr i bute
  • ⁇ xvcd set-c I i p
  • xvcd template
  • ⁇ xvcd text
  • the shaping unit 78 shapes it into a format reflecting the subtree's hierarchical structure.
  • the value of the variable “nodeToShow” is “hw: message> Hel lo Wor ld! ⁇ Hw: message Hel lo Wor Id! ⁇ Hw: message> He 11 o Wor I d! ⁇ / hw: messageX / hw: messageX / hw: message> ”is displayed on one line, but when this is double-clicked, the property display 75 will display The property dialog screen showing the details of the variable is presented.
  • the shaping unit 78 shapes the subtree that is the value of the variable “nodeToShow” into a format in which the hierarchical structure can be recognized as shown in FIG. As a result, the user can easily grasp the hierarchical structure of the subtree.
  • Pop-up window display section 79 shows that in the source view, VCD view, destination view, property view, and history view, the user can see the line that extends beyond the width of the screen. Sol If present, it presents a pop-up window that displays the entire line. At this time, if the content of the line is a subtree, the shaping unit 78 formats the subtree into a format that reflects the hierarchical structure. As a result, the user can easily grasp the line that does not fit in the width of the screen, and can easily grasp the hierarchical structure of the subtree when the line is a subtree.
  • the document processing apparatus 100 is similar to a document described in other markup languages such as SGML and HTML. Can be processed.
  • the present invention can be used for a document processing apparatus that processes a document described in a markup language.

Landscapes

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

Description

明 細 書
文書処理装置及び文書処理方法
技術分野
[0001 ] 本発明は、 文書処理技術に関し、 特に、 マークアップ言語により記述され た文書を処理する文書処理装置及び方法に関する。
背景技術
[0002] X M Lは、 ネットワークなどを介して他者とデータを共有するのに適した 形式として注目されており、 X M L文書を作成、 表示、 編集するためのアブ リケ一シヨンが開発されている （たとえば、 特許文献 1参照） 。
特許文献 1 ：特開 2 0 0 1 _ 2 9 0 8 0 4号公報
発明の開示
発明が解決しょうとする課題
[0003] ポキヤブラリは、 任意に定義することが許されており、 理論上、 無限に多 くのポキヤブラリが存在しうる。 これらのポキヤブラリの全てに対応して専 用の表示■編集環境を提供するのは現実的ではない。 従来、 専用の編集環境 が用意されていないポキヤブラリにより記述された文書を編集する場合、 テ キストデータにより構成された文書のソースを直接テキストエディタなどで 編集していたが、 本出願人は、 任意のポキヤブラリで記述された X M L文書 を編集可能な環境の開発に成功した。 そして、 更に利便性の高い X M L文書 の処理技術の開発を目指している。
[0004] 本発明はこうした状況に鑑みてなされたものであり、 その目的は、 マーク アップ言語により記述された文書を処理する際の、 ユーザの利便性を向上さ せる技術を提供することにある。
課題を解決するための手段
[0005] 本発明のある態様は、 文書処理装置に関する。 この文書処理装置は、 所定 のタグセッ卜で記述された文書を、 別のタグセッ卜で記述された文書に変換 して処理する方法を記述したスクリブトファイルの実行を制御する実行制御 部と、 前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処 理対象となっている要素を識別可能に表示するソースビュー表示部と、 前記 スクリプトファイルの実行中に、 前記スクリプトファイルの内容を、 処理中 の位置を識別可能に表示するスクリブトフアイルビユ一表示部と、 前記スク リプトファイルの実行中に、 変換先の前記文書の内容を、 処理対象となって いる要素を識別可能に表示するデスティネーションビュー表示部と、 前記実 行制御部による前記スクリプトファイルの実行を一時的に停止させるブレー クポイントを設定するブレークポイント設定部と、 を備え、 前記ブレークポ イント設定部は、 ブレークポイントを設定する要素の検索要求を受け付け、 前記スクリプトファイルの中から指定された要素を検索し、 検索された要素 にブレークボイントを設定することを特徴とする。
[0006] 前記ブレークポイント設定部は、 検索する要素の指定を受け付けるときに 、 ブレークポイントを設定可能な要素のみを提示してもよい。
[0007] 本発明の別の態様も、 文書処理装置に関する。 この文書処理装置は、 所定 のタグセッ卜で記述された文書を、 別のタグセッ卜で記述された文書に変換 して処理する方法を記述したスクリブトファイルの実行を制御する実行制御 部と、 前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処 理対象となっている要素を識別可能に表示するソースビュー表示部と、 前記 スクリプトファイルの実行中に、 前記スクリプトファイルの内容を、 処理中 の位置を識別可能に表示するスクリブトフアイルビユ一表示部と、 前記スク リプトファイルの実行中に、 変換先の前記文書の内容を、 処理対象となって いる要素を識別可能に表示するデスティネーションビュー表示部と、 前記ス クリブトファイル中で設定された変数、 プロパティ、 又はユーザデータの内 容を表示するプロパティビュー表示部と、 前記変数、 前記プロパティ、 又は 前記ユーザデータの値が、 階層構造を有するデータであった場合、 前記プロ パティビュー表示部がそのデータを表示する際に、 そのデータを階層構造を 反映させた形式に整形する整形部と、 を備えることを特徴とする。
[0008] 本発明の更に別の態様も、 文書処理装置に関する。 この文書処理装置は、 所定のタグセッ卜で記述された文書を、 別のタグセッ卜で記述された文書に 変換して処理する方法を記述したスクリブトファイルの実行を制御する実行 制御部と、 前記スクリプトファイルの実行中に、 変換元の前記文書の内容を 、 処理対象となっている要素を識別可能に表示するソースビュー表示部と、 前記スクリプトファイルの実行中に、 前記スクリプトファイルの内容を、 処 理中の位置を識別可能に表示するスクリブトフアイルビユ一表示部と、 前記 スクリプトファイルの実行中に、 変換先の前記文書の内容を、 処理対象とな つている要素を識別可能に表示するデスティネーションビュー表示部と、 前 記ソースビュー表示部、 前記スクリプトファイルビュー表示部、 又は前記デ スティネーシヨンビュー表示部が表示した内容のうち、 画面幅におさまらな い行をポップアップ表示するポップアップ表示部と、 前記ポップアップ表示 部が表示する内容が、 階層構造を有するデータであった場合、 そのデータを 階層構造を反映させた形式に整形する整形部と、 を備えることを特徴とする 本発明の更に別の態様は、 文書処理方法に関する。 この文書処理方法は、 所定のタグセッ卜で記述された文書を、 別のタグセッ卜で記述された文書に 変換して処理する方法を記述したスクリプトファイルの実行を制御するステ ップと、 前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処理対象となっている要素を識別可能に表示するステップと、 前記スクリブ トファイルの実行中に、 前記スクリプトファイルの内容を、 処理中の位置を 識別可能に表示するステップと、 前記スクリプトファイルの実行中に、 変換 先の前記文書の内容を、 処理対象となっている要素を識別可能に表示するス テツプと、 前記実行を制御するステップによる前記スクリブトファイルの実 行を一時的に停止させるブレークポイントを設定するステップと、 を備え、 前記ブレークポイントを設定するステップは、 ブレークポイントを設定する 要素の検索要求を受け付け、 前記スクリプトファイルの中から指定された要 素を検索し、 検索された要素にブレークポイントを設定することを特徴とす る。 [0010] なお、 以上の構成要素の任意の組合せ、 本発明の表現を方法、 装置、 シス テムなどの間で変換したものもまた、 本発明の態様として有効である。
発明の効果
[0011] 本発明によれば、 マークアップ言語により記述された文書を処理する際の
、 ユーザの利便性を向上させる技術を提供することができる。
図面の簡単な説明
[0012] [図 1]前提技術に係る文書処理装置の構成を示す図である。
[図 2]文書処理装置により編集される XM L文書の例を示す図である。
[図 3]図 2に示した XM L文書を H TM Lで記述された表にマツビングする例 を示す図である。
[図 4(a)]図 2に示した XM L文書を図 3に示した表にマツビングするための 定義ファイルの例を示す図である。
[図 4(b)]図 2に示した XM L文書を図 3に示した表にマツビングするための 定義ファイルの例を示す図である。
[図 5]図 2に示した XM L文書を、 図 3に示した対応により H TM Lにマツピ ングして表示した画面の例を示す図である。
[図 6]ユーザが定義ファィルを生成するために、 定義フアイル生成部がユーザ に提示するグラフィカルユーザインタ一フェースの例を示す図である。
[図 7]定義ファイル生成部により生成された画面レイァゥ卜の他の例を示す図 である。
[図 8]文書処理装置による X ML文書の編集画面の一例を示す図である。
[図 9]文書処理装置により編集される XM L文書の他の例を示す図である。
[図 10]図 9に示した文書を表示した画面の例を示す図である。
[図 11 (a)]文書処理システムの基本構成を示す図である。
[図 11 (b)]文書処理システム全体のプロック図を示す図である。
[図 11 (c)]文書処理システム全体のプロック図を示す図である。
[図 12]文書管理部の詳細を示す図である。
[図 13]ポキャプラリコネクションサブシステムの詳細を示す図である。 [図 14]プログラム起動部と他の構成の関係の詳細を示す図である。
[図 15]プログラム起動部により口一ドされたアプリケーションサービスの構 造の詳細を示す図である。
[図 16]コアコンポーネン卜の詳細を示す図である。
[図 17]文書管理部の詳細を示す図である。
[図 18]アンドウフレームワークとアンドウコマンドの詳細を示す図である。
[図 19]文書処理システムにおいて文書がロードされる様子を示す図である。
[図 20]文書とその表現の例を示す図である。
[図 21 ]モデルとコントローラの関係を示す図である。
[図 22]プラグインサブシステム、 ポキヤブラリコネクション、 及びコネクタ の詳細を示す図である。
[図 23] V C Dファイルの例を示す図である。
[図 24]文書処理システムにおいて複合文書をロードする手順を示す図である
[図 25]文書処理システムにおいて複合文書をロードする手順を示す図である
[図 26]文書処理システムにおいて複合文書をロードする手順を示す図である
[図 27]文書処理システムにおいて複合文書をロードする手順を示す図である
[図 28]文書処理システムにおいて複合文書をロードする手順を示す図である
[図 29]コマンドの流れを示す図である。
[図 30]実施の形態の文書処理装置の構成を示す図である。
[図 31 ]デバッガの機能を説明するためのサンプル文書を示す図である。
[図 32]図 3 1に示した X M L文書に関連付けられた V C Dファイルを示す図 である。
[図 33]デ / ッガが表示するデ / ッグ画面の例を示す図である。 [図 34] rhtmlj 要素まで VCDスクリプトの処理を進めた状態を示す図であ る。
[図 35]図 34に示した状態でステップインを実行したときの画面を示す図で
[図 36] 「title」 要素まで VCDスクリプトの処理を進めた状態を示す図であ る。
[図 37]図 36に示した状態でステップァゥトを実行したときの画面を示す図 である。
[図 38] rbodyj 要素まで VCDスクリプトの処理を進めた状態を示す図であ る。
[図 39]図 38に示した状態でステツプオーバーを実行したときの画面を示す 図である。
[図 40]図 31に示した XML文書に図 32に示した VCDファイルのスクリ ブトを適用させた結果を示す図である。
[図 41]ブレークポイント設定部が提示した検索ダイアログ画面を示す図であ る。
[図 42]変数値のサブッリーを整形して表示したプロパティダイァログ画面を 示す図である。
[図 43]画面幅におさまらない行を整形して表示したポップアップゥインドウ を示す図である。
符号の説明
20 文書処理装置、 22 主制御ユニット、 24 編集ユニット、 30 DOMユニット、 32 DOM提供部、 34 DOM生成部、 36 出力 部、 40 CSSユニット、 42 CSS解析部、 44 CSS提供部、 4 6 レンダリング部、 50 HTMLユニット、 52, 62 制御部、 54 , 64 編集部、 56, 66 表示部、 60 SVGユニット、 70 デバ ッガ、 7 1 画面表示部、 72 ソースビュー表示部、 73 VCDビュー 表示部、 74 デスティネーションビュー表示部、 75 プロパティビュー 表示部、 76 ブレークポイント設定部、 77 実行制御部、 78 整形部 、 79 ポップアップウィンドウ表示部、 80 VCユニット、 82 マツ ビング部、 84 定義ファイル取得部、 86 定義ファイル生成部、 1 00 文書処理装置。
発明を実施するための最良の形態
[0014] (前提技術）
図 1は、 前提技術に係る文書処理装置 20の構成を示す。 文書処理装置 2 0は、 文書内のデータが階層構造を有する複数の構成要素に分類された構造 化文書を処理するが、 本前提技術では構造化文書の一例として XML文書を 処理する例について説明する。 文書処理装置 20は、 主制御ユニット 22、 編集ユニット 24、 DOMユニット 30、 CSSユニット 40、 HTMLュ ニット 50、 SVGユニット 60、 及び変換部の一例である VCユニット 8 0を備える。 これらの構成は、 ハ一ドウエアコンポーネントでいえば、 任意 のコンピュータの CP U、 メモリ、 メモリにロードされたプログラムなどに よって実現されるが、 ここではそれらの連携によって実現される機能ブロッ クを描いている。 したがって、 これらの機能ブロックがハードウェアのみ、 ソフトウエアのみ、 またはそれらの組合せによっていろいろな形で実現でき ることは、 当業者には理解されるところである。
[0015] 主制御ユニット 22は、 プラグインのロードや、 コマンド実行のフレーム ワークを提供する。 編集ユニット 24は、 XML文書を編集するためのフレ ームワークを提供する。 文書処理装置 20における文書の表示及び編集機能 は、 プラグインにより実現されており、 文書の種別に応じて必要なプラグィ ンが主制御ュニット 22又は編集ュニット 24により口一ドされる。 主制御 ユニット 22又は編集ュニット 24は、 処理対象となる XM L文書の名前空 間を参照して、 XM L文書がいずれのポキャプラリにより記述されているか を判別し、 そのポキヤブラリに対応した表示又は編集用のプラグインをロー ドして表示や編集を実行させる。 例えば、 文書処理装置 20には、 HTML 文書の表示及び編集を行う HTMLユニット 50、 S VG文書の表示及び編 集を行う SVGユニット 60など、 ポキヤブラリ （タグセット） ごとに表示 系及び編集系がプラグインとして実装されており、 HTML文書を編集する ときは H TM Lユニット 50力 S VG文書を編集するときは S VGュニッ ト 60力 それぞれロードされる。 後述するように、 HTMLとSVGの双 方の構成要素を含む複合文書が処理対象となっている場合は、 H TMLュニ ット 50と S VGュニット 60の双方が口一ドされる。
[0016] このような構成によれば、 ユーザは、 必要な機能のみを選択してインスト ールし、 後から適宜機能を追加又は削除することができるので、 プログラム を格納するハードディスクなどの記録媒体の記憶領域を有効に活用すること ができ、 また、 プログラム実行時にも、 メモリの浪費を防ぐことができる。 また、 機能拡張性に優れており、 開発主体としても、 プラグインの形で新た なポキヤブラリに対応することが可能なので開発が容易となり、 ユーザとし ても、 ブラグインの追加により容易かつ低コストにて機能を追加することが できる。
[0017] 編集ユニット 24は、 ユーザインタ一フェースを介してユーザから編集指 示のィベントを受け付け、 そのィベントを適切なプラグインなどに通知する ともに、 イベントの再実行 （リ ドウ） 又は実行の取消 （アンドゥ） などの処 理を制御する。
[0018] DOMユニット 30は、 DOM提供部 32、 D O M生成部 34、 及び出力 部 36を含み、 X ML文書をデータとして扱うときのアクセス方法を提供す るために定められた文書オブジェク トモデル （Document Object Model ： DO M) に準拠した機能を実現する。 DOM提供部32は、 編集ユニット 24に 定義されているインタフェースを満たす DO Mの実装である。 DOM生成部 34は、 XML文書から DOMツリーを生成する。 後述するように、 処理対 象となる XM L文書が、 VCュニット 80により他のポキャプラリにマツピ ングされる場合は、 マツビング元の XM L文書に対応するソースツリーと、 マツビング先の XM L文書に対応するデスティネーションツリーが生成され る。 出力部 36は、 例えば編集終了時に、 DOMツリーを XM L文書として 出力する。
[0019] CSSユニット 40は、 CSS解析部 42、 C S S提供部 44、 及びレン ダリング部 46を含み、 CSSに準拠した表示機能を提供する。 CSS解析 部 42は、 CSSの構文を解析するバーサの機能を有する。 CSS提供部 4 4は、 CS Sオブジェク トの実装であり、 DOMツリーに対して CS Sの力 スケ一ド処理を行う。 レンダリング部 46は、 CS Sのレンダリングェンジ ンであり、 CS Sを用いてレイァゥ卜される H TM Lなどのポキャプラリで 記述された文書の表示に用いられる。
[0020] HTMLユニット 50は、 H T M Lにより記述された文書を表示又は編集 する。 SVGユニット 60は、 SVGにより記述された文書を表示又は編集 する。 これらの表示/編集系は、 プラグインの形で実現されており、 それぞ れ、 文書を表示する表示部 （Canvas) 56、 66、 編集指示を含むイベント を送受信する制御部 （Editlet) 52、 62、 編集コマンドを受けて D O Mに 対して編集を行う編集部 （Zone) 54、 64を備える。 制御部 52又は 62 が外部から DOMツリーの編集コマンドを受け付けると、 編集部 54又は 6 4が DOMツリーを変更し、 表示部 56又は 66が表示を更新する。 これら は、 MVC (Model-View-Control ler) と呼ばれるフレームワークに類似する 構成をとつており、 概ね、 表示部 56及び 66が 「View」 に、 制御部 52及 び 62力《 Γ Control lerj に、 編集部 54及び 64と D O Mの実体が 「Model」 に、 それぞれ対応する。 本前提技術の文書処理装置 20では、 XML文書を ッリ一表示形式で編集するだけでなく、 それぞれのポキャプラリに応じた編 集を可能とする。 例えば、 HTMLユニット 50は、 HTML文書をワード プロセッサに類似した方式で編集するためのユーザインタ一フェースを提供 し、 SVGユニット 60は、 SVG文書を画像描画ツールに類似した方式で 編集するためのユーザィンタ一フェースを提供する。
[0021] VCユニット 80は、 マッピング部 82、 定義ファイル取得部 84、 及び 定義ファイル生成部 86を含み、 あるポキヤブラリにより記述された文書を 、 他のポキヤブラリにマッピングすることにより、 マッピング先のポキヤブ ラリに対応した表示編集用プラグィンで文書を表示又は編集するためのフレ —ムワークを提供する。 本前提技術では、 この機能を、 ポキヤブラリコネク シヨン （Vocabu l ary Connect i on： V C ) と呼ぶ。 定義ファイル取得部 8 4は 、 マッピングの定義を記述したスクリプトファイルを取得する。 この定義フ アイルは、 ノードごとに、 ノード間の対応 （コネクション） を記述する。 こ のとき、 各ノードの要素値や属性値の編集の可否を指定してもよい。 また、 ノードの要素値や属性値を用いた演算式を記述してもよい。 これらの機能に ついては、 後で詳述する。 マッピング部 8 2は、 定義ファイル取得部 8 4が 取得したスクリブトファイルを参照して、 D O M生成部 3 4にデスティネー シヨンツリーを生成させ、 ソースツリーとデスティネーションツリーの対応 関係を管理する。 定義ファイル生成部 8 6は、 ユーザが定義ファイルを生成 するためのグラフィカルユーザィンタ一フェースを提供する。
[0022] V Cユニット 8 0は、 ソースツリーとデスティネーションツリーの間のコ ネクシヨンを監視し、 表示を担当するプラグインにより提供されるユーザィ ンタフエースを介してユーザから編集指示を受け付けると、 まずソースッリ —の該当するノードを変更する。 D O Mユニット 3 0力 ソースツリーが変 更された旨のミューテ一シヨンィベントを発行すると、 V Cュニット 8 0は 、 そのミューテ一シヨンイベントを受けて、 ソースツリーの変更にデスティ ネ一シヨンツリーを同期させるベく、 変更されたノードに対応するデスティ ネ一シヨンツリーのノードを変更する。 デスティネーションツリーを表示/ 編集するプラグイン、 例えば H T M Lユニット 5 0は、 デスティネーション ツリーが変更された旨のミューテ一シヨンィベントを受けて、 変更されたデ ステイネ一シヨンツリーを参照して表示を更新する。 このような構成により 、 少数のユーザにより利用されるローカルなポキャプラリにより記述された 文書であっても、 他のメジャーなポキャプラリに変換することで、 文書を表 示することができるとともに、 編集環境が提供される。
[0023] 文書処理装置 2 0により文書を表示又は編集する動作について説明する。
文書処理装置 2 0が処理対象となる文書を読み込むと、 D O M生成部 3 4が 、 その X M L文書から D O Mツリーを生成する。 また、 主制御ユニット 2 2 又は編集ュニット 2 4は、 名前空間を参照して文書を記述しているポキヤブ ラリを判別する。 そのポキャプラリに対応したプラグィンが文書処理装置 2 0にインス！ ルされている場合は、 そのプラグインをロードして、 文書を 表示/編集させる。 プラグインがインスト一ルされていない場合は、 マツピ ングの定義ファイルが存在するか否かを確認する。 定義ファイルが存在する 場合、 定義ファイル取得部 8 4が定義ファイルを取得し、 その定義に従って 、 デスティネーションツリーが生成され、 マッピング先のポキヤブラリに対 応ずるプラグインにより文書が表示/編集される。 複数のポキヤブラリを含 む複合文書である場合は、 後述するように、 それぞれのポキヤブラリに対応 したプラグインにより、 文書の該当箇所がそれぞれ表示/編集される。 定義 ファイルが存在しない場合は、 文書のソース又はツリー構造を表示し、 その 表示画面において編集が行われる。
[0024] 図 2は、 処理対象となる X M L文書の例を示す。 この X M L文書は、 生徒 の成績データを管理するために用いられる。 X M L文書のトップノードであ る構成要素 「成績」 は、 配下に、 生徒ごとに設けられた構成要素 「生徒」 を 複数有する。 構成要素 「生徒」 は、 属性値 「名前」 と、 子要素 「国語」 、 「 数学」 、 「理科」 、 「社会」 を有する。 属性値 「名前」 は、 生徒の名前を格 納する。 構成要素 「国語」 、 「数学」 、 「理科」 、 「社会」 は、 それぞれ、 国語、 数学、 理科、 社会の成績を格納する。 例えば、 名前が 「A」 である生 徒の国語の成績は 「9 0」 、 数学の成績は 「5 0」 、 理科の成績は 「7 5」 、 社会の成績は 「6 0」 である。 以下、 この文書で使用されているポキヤブ ラリ （タグセット） を、 「成績管理ポキャブラリ」 と呼ぶ。
[0025] 本前提技術の文書処理装置 2 0は、 成績管理ポキャプラリの表示/編集に 対応したプラグインを有しないので、 この文書をソース表示、 ツリー表示以 外の方法で表示するためには、 前述した V C機能が用いられる。 すなわち、 成績管理ポキヤブラリを、 プラグインが用意された別のポキヤブラリ、 例え ば、 H T M Lや S V Gなどにマツビングするための定義ファイルを用意する 必要がある。 ユーザ自身が定義ファイルを作成するためのユーザインターフ エースについては後述することにして、 ここでは、 既に定義ファイルが用意 されているとして説明を進める。
[0026] 図 3は、 図 2に示した X M L文書を H T M Lで記述された表にマッピング する例を示す。 図 3の例では、 成績管理ポキヤブラリの 「生徒」 ノードを、 H T M Lにおける表 （ 「TABLE」 ノード） の行 （ 「TR」 ノード） に対応づけ、 各行の第 1列には属性値 「名前」 を、 第 2列には 「国語」 ノードの要素値を 、 第 3列には 「数学」 ノードの要素値を、 第 4列には 「理科」 ノードの要素 値を、 第 5列には 「社会」 ノードの要素値を、 それぞれ対応付ける。 これに より、 図 2に示した X M L文書を、 H T M Lの表形式で表示することができ る。 また、 これらの属性値及び要素値は、 編集可能であることが指定されて おり、 ユーザが H T M Lによる表示画面上で、 H T M Lユニット 5 0の編集 機能により、 これらの値を編集することができる。 第 6列には、 国語、 数学 、 理科、 社会の成績の加重平均を算出する演算式が指定されており、 生徒の 成績の平均点が表示される。 このように、 定義ファイルに演算式を指定可能 とすることにより、 より柔軟な表示が可能となり、 編集時のユーザの利便性 を向上させることができる。 なお、 第 6列は、 編集不可であることが指定さ れており、 平均点のみを個別に編集することができないようにしている。 こ のように、 マッピング定義において、 編集の可否を指定可能とすることによ り、 ユーザの誤操作を防ぐことができる。
[0027] 図 4 ( a ) 及び図 4 ( b ) は、 図 2に示した X M L文書を図 3に示した表 にマッピングするための定義ファイルの例を示す。 この定義ファイルは、 定 義ファイル用に定義されたスクリプト言語により記述される。 定義ファイル には、 コマンドの定義と、 表示のテンプレートが記述されている。 図 4 ( a ) ( b ) の例では、 コマンドとして、 「生徒の追加」 と 「生徒の削除」 が定 義されており、 それぞれ、 ソースツリーにノード 「生徒」 を挿入する操作と 、 ソースツリーからノード 「生徒」 を削除する操作が対応付けられている。 また、 テンプレートとして、 表の第 1行に 「名前」 、 「国語」 などの見出し が表示され、 第 2行以降に、 ノード 「生徒」 の内容が表示されることが記述 されている。 ノード 「生徒」 の内容を表示するテンプレート中、 「text-of」 と記述された項は 「編集可能」 であることを意味し、 「va l ue-of」 と記述さ れた項は 「編集不可能」 であることを意味する。 また、 ノード 「生徒」 の内 容を表示する行のうち、 第 6列には、 「（src :国語 + src :数学 + src :理科 + src :社会） d i v 4」 という計算式が記述されており、 生徒の成績の平均が表 示されることを意味する。
[0028] 図 5は、 図 2に示した成績管理ポキヤブラリで記述された X M L文書を、 図 3に示した対応により H T M Lにマツビングして表示した画面の例を示す 。 表 9 0の各行には、 左から、 各生徒の名前、 国語の成績、 数学の成績、 理 科の成績、 社会の成績、 及び平均点が表示されている。 ユーザは、 この画面 上で、 X M L文書を編集することができる。 たとえば、 第 2行第 3列の値を 「7 0」 に変更すると、 このノードに対応するソースツリーの要素値、 すな わち、 生徒 「B」 の数学の成績が 「7 0」 に変更される。 このとき、 V Cュ ニット 8 0は、 デスティネーションツリーをソースツリーに追従させるベく 、 デスティネーションツリーの該当箇所を変更し、 H T M Lユニット 5 0が 、 変更されたデスティネーションツリーに基づいて表示を更新する。 したが つて、 画面上の表においても、 生徒 「B」 の数学の成績が 「7 0」 に変更さ れ、 更に、 平均点が 「5 5」 に変更される。
[0029] 図 5に示した画面には、 図 4 ( a ) ( b ) に示した定義ファイルに定義さ れたように、 「生徒の追加」 及び 「生徒の削除」 のコマンドがメニューに表 示される。 ユーザがこれらのコマンドを選択すると、 ソースツリーにおいて 、 ノード 「生徒」 が追加又は削除される。 このように、 本前提技術の文書処 理装置 2 0では、 階層構造の末端の構成要素の要素値を編集するのみではな く、 階層構造を編集することも可能である。 このようなツリー構造の編集機 能は、 コマンドの形でユーザに提供されてもよい。 また、 例えば、 表の行を 追加又は削除するコマンドが、 ノード 「生徒」 を追加又は削除する操作に対 応づけられてもよい。 また、 他のポキヤブラリを埋め込むコマンドがユーザ に提供されてもよい。 この表を入力用テンプレートとして、 穴埋め形式で新 たな生徒の成績データを追加することもできる。 以上のように、 V C機能に より、 H T M Lユニット 5 0の表示/編集機能を利用しつつ、 成績管理ポキ ャブラリで記述された文書を編集することが可能となる。
[0030] 図 6は、 ユーザが定義ファイルを生成するために、 定義ファイル生成部 8 6がユーザに提示するグラフィカルユーザィンタフェースの例を示す。 画面 左側の領域 9 1には、 マッピング元の X M L文書がツリー表示されている。 画面右側の領域 9 2には、 マッピング先の X M L文書の画面レイァゥ卜が示 されている。 この画面レイアウトは、 H T M Lユニット 5 0により編集可能 となっており、 ユーザは、 画面右側の領域 9 2において、 文書を表示するた めの画面レイアウトを作成する。 そして、 例えば、 マウスなどのポインティ ングデ /くィスにより、 画面左側の領域 9 1に表示されたマツピング元の X M L文書のノードを、 画面右側の領域 9 2に表示された H T M Lによる画面レ ィァゥト中へドラッグ &ドロップ操作を行うことにより、 マツビング元のノ —ドと、 マッピング先のノードとのコネクションが指定される。 例えば、 要 素 「生徒」 の子要素である 「数学」 を、 H T M L画面の表 9 0の第 1行第 3 列にドロップすると、 「数学」 ノードと、 3列目の 「T D」 ノードの間にコ ネクシヨンが張られる。 各ノードには、 編集の可否が指定できるようになつ ている。 また、 表示画面中には、 演算式を埋め込むこともできる。 画面の編 集が終わると、 定義ファイル生成部 8 6は、 画面レイアウトとノード間のコ ネクシヨンを記述した定義ファイルを生成する。
[0031 ] X H T M L、 M a t h M L、 S V Gなどの主要なポキヤブラリに対応した ビューヮゃエディタは既に開発されているが、 図 2に示した文書のようなォ リジナルなポキヤブラリで記述された文書に対応したビューヮゃエディタを 開発するのは現実的でない。 しかし、 上記のように、 他のポキヤブラリにマ ッビングするための定義ファイルを作成すれば、 ビューヮゃエディタを開発 しなくても、 V C機能を利用して、 オリジナルなポキヤブラリで記述された 文書を表示■編集することができる。 [0032] 図 7は、 定義ファイル生成部 8 6により生成された画面レイアウトの他の 例を示す。 図 7の例では、 成績管理ポキャプラリで記述された X M L文書を 表示するための画面に、 表 9 0と、 円グラフ 9 3が作成されている。 この円 グラフ 9 3は、 S V Gにより記述される。 後述するように、 本前提技術の文 書処理装置 2 0は、 一つの X M L文書内に複数のポキヤブラリを含む複合文 書を処理することができるので、 この例のように、 H T M Lで記述された表 9 0と、 S V Gで記述された円グラフ 9 3とを、 一つの画面上に表示するこ とができる。
[0033] 図 8は、 文書処理装置 2 0による X M L文書の編集画面の一例を示す。 図 8の例では、 一つの画面が複数に分割されており、 それぞれの領域において 、 処理対象となる X M L文書を異なる複数の表示形式により表示している。 領域 9 4には、 文書のソースが表示されており、 領域 9 5には、 文書のッリ —構造が表示されており、 領域 9 6には、 図 5に示した H T M Lにより記述 された表が表示されている。 これらのいずれの画面上においても、 文書の編 集が可能であり、 いずれかの画面上でユーザが編集を行うと、 ソースッリ _ が変更され、 それぞれの画面の表示を担当するプラグインが、 ソースツリー の変更を反映すべく画面を更新する。 具体的には、 ソースツリーの変更を通 知するミューテ一シヨンィベン卜のリスナーとして、 それぞれの編集画面の 表示を担当するブラグインの表示部を登録しておき、 いずれかのブラグイン 又は V Cュニット 8 0によりソースツリーが変更されたときに、 編集画面を 表示中の全ての表示部が、 発行されたミューテ一シヨンィベントを受け取つ て画面を更新する。 このとき、 プラグインが V C機能により表示を行ってい る場合は、 V Cュニット 8 0がソースツリーの変更に追従してデステイネ一 シヨンツリーを変更した後、 変更されたデスティネーションツリーを参照し てプラグィンの表示部が画面を更新する。
[0034] 例えば、 ソース表示及びツリー表示を、 専用のプラグインにより実現して いる場合は、 ソース表示用プラグインとツリー表示用プラグインは、 デステ イネ一シヨンツリーを用いず、 直接ソースツリーを参照して表示を行う。 こ の場合、 いずれかの画面において編集が行われると、 ソース表示用プラグィ ンとッリ一表示用プラグィンは、 変更されたソースッリ一を参照して画面を 更新し、 領域 9 6の画面を担当している H T M Lユニット 5 0は、 ソ一スッ リーの変更に追従して変更されたデスティネーションツリーを参照して画面 を更新する。
[0035] ソース表示及びツリー表示は、 V C機能を利用して実現することもできる 。 すなわち、 ソース、 ツリー構造を H T M Lによりレイアウトし、 その H T M Lに X M L文書をマツビングして、 H T M Lュニット 5 0により表示して もよい。 この場合、 ソース形式、 ツリー形式、 表形式の 3つのデスティネー シヨンッリ一が生成されることになる。 いずれかの画面において編集が行わ れると、 V Cユニット 8 0は、 ソースツリーを変更した後、 ソース形式、 ッ リ一形式、 表形式の 3つのデスティネーションツリーをそれぞれ変更し、 H T M Lユニット 5 0は、 それらのデスティネーションツリーを参照して、 3 つの画面を更新する。
[0036] このように、 一つの画面上に複数の表示形式で文書を表示することにより 、 ユーザの利便性を向上させることができる。 例えば、 ユーザは、 ソース表 示又はッリ一表示により文書の階層構造を把握しつつ、 表 9 0などを用いて 視覚的に分かりやすい形式で文書を表示し、 編集することができる。 上記の 例では、 一つの画面を分割して複数の表示形式による画面を同時に表示した 力 一つの画面に一つの表示形式による画面を表示し、 表示形式をユーザの 指示により切り替え可能としてもよい。 この場合、 主制御ユニット 2 2力 ユーザから表示形式の切り替え要求を受け付け、 各プラグインに指示して表 示を切り替える。
[0037] 図 9は、 文書処理装置 2 0により編集される X M L文書の他の例を示す。
図 9に示した X M L文書では、 S V G文書の 「fore i gnObject」 タグの中に X H T M L文書が埋め込まれており、 さらに、 X H T M L文書の中に M a t h M Lで記述された数式が入っている。 このような場合、 編集ユニット 2 4が 、 名前空間を参照して、 適切な表示系に描画作業を振り分ける。 図 9の例で は、 編集ユニット 2 4は、 まず、 S V Gユニット 6 0に四角形を描画させ、 つづいて、 H T M Lユニット 5 0に X H T M L文書を描画させる。 さらに、 図示しない M a t h M Lユニットに、 数式を描画させる。 こうして、 複数の ポキヤブラリを包含する複合文書が適切に表示される。 表示結果を図 1 0に 示す。
[0038] 文書編集中、 カーソル （キャリッジ） の位置に応じて、 表示されるメニュ —を切り替えてもよい。 すなわち、 カーソルが、 S V G文書が表示された領 域内に存在するときは、 S V Gユニット 6 0が提供するメニュー、 又は S V G文書をマツビングするための定義ファイルに定義されたコマンドを表示し 、 カーソルが、 X H T M L文書が表示された領域内に存在するときは、 H T M Lュニット 5 0が提供するメニュー、 又は X H T M L文書をマツビングす るための定義ファイルに定義されたコマンドを表示する。 これにより、 編集 位置に応じて適切なユーザインタ一フェースを提供することができる。
[0039] 複合文書において、 あるポキヤブラリに対応する適切なプラグイン又はマ ッビング定義ファイルがなかった場合は、 そのポキヤブラリにより記述され た部分は、 ソース表示又はツリー表示されてもよい。 従来、 ある文書に他の 文書を埋め込んだ複合文書を開くとき、 埋め込まれた文書を表示するアプリ ケ一シヨンがインストールされていないと、 その内容を表示することができ なかったが、 本前提技術では、 表示用のアプリケーションが存在しなくても 、 テキストデータにより構成された X M L文書をソース表示又はツリー表示 することにより内容を把握することができる。 これは、 テキストベースであ る X M Lなどの文書ならではの特徴といえる。
[0040] データがテキストベースで記述されることの他の利点として、 例えば、 複 合文書中の、 あるポキヤブラリにより記述される部分において、 同一文書内 の他のポキヤブラリで記述された部分のデータを参照してもよい。 また、 文 書内で検索を実行する時に、 S V Gなどの図に埋め込まれた文字列も検索対 象とすることができる。
[0041 ] あるポキヤブラリにより記述された文書内に、 他のポキヤブラリのタグを 用いてもよい。 この XML文書は、 妥当 （valid) ではないが、 整形式 （well -formed) であれば、 有効な X M L文書として処理可能である。 この場合、 揷 入された他のポキャプラリのタグは、 定義ファイルによりマツビングされて もよい。 例えば、 XHTML文書中に、 「重要」 、 「最重要」 などのタグを 使用し、 これらのタグで囲まれた部分を強調表示してもよいし、 重要度の順 にソ一トして表示してもよい。
[0042] 図 1 0に示した編集画面において、 ユーザにより文書が編集されると、 編 集された部分を担当するプラグイン又は VCュニット 80がソースツリーを 変更する。 ソースツリーには、 ノードごとにミューテ一シヨンイベントのリ スナーを登録できるようになつており、 通常は、 各ノードが属するポキヤブ ラリに対応したプラグインの表示部又は VCュニット 80がリスナーとして 登録される。 DOM提供部32は、 ソースツリーが変更されると、 変更され たノードから上位の階層へたどって、 登録されたリスナーがあれば、 そのリ スナ一へミューテ一シヨンイベントを発行する。 例えば、 図 9に示した文書 において、 < h t m I >ノードの下位のノードが変更された場合、 < h t m I >ノードにリスナーとして登録された H TM Lュニット 50にミューテ一 シヨンィベン卜が通知されるとともに、 その上位の < s V g>ノードにリス ナ一として登録された SVGュニット 60にもミューテ一シヨンィベン卜が 通知される。 このとき、 HTMLユニット 50は、 変更されたソースツリー を参照して表示を更新する。 SVGユニット 60は、 自身のポキヤブラリに 属するノードが変更されていないので、 ミューテ一シヨンィベントを無視し てもよい。
[0043] 編集の内容によっては、 H TM Lユニット 50による表示の更新に伴って 、 全体のレイアウトが変わる可能性がある。 この場合は、 画面のレイアウト を管理する構成、 例えば最上位のノードの表示を担当するプラグインにより 、 プラグインごとの表示領域のレイアウトが更新される。 例えば、 HTML ュニット 50による表示領域が以前より大きくなつた場合、 HTMLュニッ ト 50は、 まず自身の担当する部分を描画して、 表示領域の大きさを決定す る。 そして、 画面のレイアウトを管理する構成に、 変更後の表示領域の大き さを通知し、 レイアウトの更新を依頼する。 画面のレイアウトを管理する構 成は、 通知を受けて、 プラグインごとの表示領域を再レイアウトする。 こう して、 編集された部分の表示が適切に更新されるとともに、 画面全体のレイ ァゥ卜が更新される。
[0044] つづいて、 前提技術の文書処理装置 20を実現する機能構成について更に 詳細に説明する。 以下の説明では、 クラス名などを記載する際には、 英字を そのまま用いて記載することにする。
[0045] A. 概要
インタ一ネッ卜の出現により、 ユーザによって処理され管理される文書の 数が、 ほぼ指数関数的に増加してきた。 インターネットの核を形成するゥェ ブ （World wide Web) は、 そのような文書データの大きな受け皿となってい る。 ウェブは、 文書に加えて、 このような文書の情報検索システムを提供す る。 これらの文書は、 通常、 マークアップ言語により記述される。 マークァ ップ言語のシンプルかつポピュラーな例の一つに H TM L (HyperText Marku p Language) がある。 このような文書は、 ウェブの他の位置に格納されてい る他の文書へのリンクをさらに含む。 XML (extensible Markup Language ) は、 さらに高度でポピュラーなマークアップ言語である。 ウェブ文書にァ クセスし、 閲覧するためのシンプルなブラウザが、 J a v a (登録商標） の ようなオブジェク ト指向のプログラミング言語で開発されている。
[0046] マークアップ言語により記述された文書は、 通常、 ブラウザや他のアプリ ケ一シヨンの中では、 ツリーデータ構造の形で表現される。 この構造は、 文 書を構文解析した結果のツリーに相当する。 DOM (Document Object Model ) は、 文書を表現し、 操作するために使用される、 よく知られたツリーべ一 スのデータ構造モデルである。 DOMは、 H TM Lや XM L文書などを含む 文書を表現するための標準的なオブジェク 卜のセットを提供する。 DOMは 、 文書内のコンポーネントを表現するォブジェク 卜がどのようにつながって いるかという標準モデルと、 それらのオブジェク 卜にアクセスしたり操作し たりするための標準インタフェイスという、 2つの基本的なコンポ一ネント を含む。
[0047] アプリケーション開発者は、 独自のデータ構造や A P I (Appl i cat ion Pro gram Interface) へのインタフェイスとして D O Mをサポートすることがで きる。 他方、 文書を作成するアプリケーション開発者は、 彼らの AP Iの独 自インタフェイスではなく、 D O Mの標準ィンタフェイスを使用することが できる。 したがって、 標準を提供するというその能力により、 DOMは、 様 々な環境、 特にウェブにおいて、 文書の相互利用を促進させるために有効で ある。 DOMのいくつかのバージョンが定義されており、 異なるプログラミ ング環境及びァプリケ一シヨンによって使用されている。
[0048] DOMツリーは、 対応する DO Mの内容に基づいた文書の階層的表現であ る。 DOMツリーは 「根 （ルート） 」 、 及びルートから発生する 1つ以上の 「節 （ノード） 」 を含む。 ルートが文書全体を表す場合もある。 中間のノー ドは、 例えば、 テーブル及びそのテーブル中の行及び列のような要素を表す ことができる。 DOMツリーの 「葉」 は、 通常、 それ以上分解できないテキ ストや画像のようなデータを表す。 DOMツリーの各ノードは、 フォント、 サイズ、 色、 インデントなど、 ノードによって表される要素のパラメータを 記述する属性に関連付けられてもよい。
[0049] HTMLは、 文書を作成するために一般に用いられる言語であるが、 フォ 一マツト及びレイァゥト用の言語であり、 データ記述のための言語ではない 。 H TM L ドキュメントを表現する DOMツリーのノードは、 HTMLのフ ォ一マツティングタグとして予め定義されたエレメントであって、 通常、 H TMLは、 データの詳述や、 データのタギング/ラベリングのための機能を 提供しないので、 HTML ドキュメント中のデータに対するクエリを定式化 することは多くの場合困難である。
[0050] ネットワーク設計者たちの目指すものは、 ウェブ上の文書がソフトウェア アプリケーションによってクエリされたり処理されたりできるようにするこ とである。 表示方法とは無関係で、 階層的に構造化された言語であれば、 そ のようにクエリされ処理されることができる。 XML (extensible Markup L anguage) のようなマークアップ言語は、 これらの特徴を提供することができ る。
[0051] HTMLとは逆に、 XMLのよく知られた利点は、 文書の設計者が自由に 定義可能な 「タグ」 を使用して、 データ要素にラベルを付けることが可能で ある点である。 このようなデータ要素は、 階層的に構造化することができる 。 さらに、 XML文書は、 文書内で用いられるタグ及びそれらの相互関係の 「文法」 を記述した文書型定義を含むことができる。 構造化された XML文 書の表示方法を定義するために、 CSS (Cascading Style Sheet) 又は XS L (XML Style Language) が使用される。 DOM、 HTML、 XML、 C S S、 XS L及び関連する言語の特徴に関する付加的な情報は、 ウェブからも 得ることができる。 （例えば、 http：〃 www. w3. org/TR/)
[0052] X p a t hは、 XM L文書の部分の位置を指定するために共通のシンタツ クス及びセマンティクスを提供する。 機能性の例として、 XML文書に対応 する DOMツリーのトラバース （移動） がある。 それは、 XML文書の様々 な表現に関連した文字列、 数、 及びブーリアン文字の操作のための基本的な 機能を提供する。 X p a t hは、 XM L文書の見た目のシンタックス、 例え ば、 テキス卜としてみたときに何行目であるとか何文字目であるとかといつ た文法ではなく、 DOMツリーなどの抽象的■論理的な構造において動作す る。 X p a t hを使用することにより、 例えば XM L文書の DOMツリー内 の階層的構造を通じて場所を指定することができる。 ァドレシングのための 使用の他に、 X p a t hは、 DOMツリー中のノードがパターンにマッチす るか否かをテストするために使用されるようにも設計されている。 XP a t hに関する更なる詳細は、 http: //www. w3. org/TR/xpathで得ることができる
[0053] XM Lの既知の利点及び特徴により、 マークアップ言語 （例えば X ML) で記述された文書を扱うことができ、 文書を作成及び修正するためのユーザ フレンドリーなインタフェイスを提供することができる、 効果的な文書処理 システムが求められる。
[0054] ここで説明されるシステムの構成のうちのいくつかは、 MVC (Model -Vie w-Control ler) と呼ばれる、 よく矢卩られた GU I (Graphical User Interfac e) パラダイムを用いて説明される。 MVCパラダイムは、 アプリケーション 又はアプリケーションのインタフェイスの一部を、 3つの部分、 すなわち、 モデル、 ビュー、 コントローラに分割する。 MVCは、 元は、 GU Iの世界 に、 従来の入力、 処理、 出力の役割を割り当てるために開発された。
[入力] → [処理] → [出力]
[コントローラ] → [モデル] → [ビュー]
[0055] MVCパラダイムによれば、 外界のモデリング、 ユーザへの視覚的なフィ —ドバック、 及びユーザの入力は、 モデル （M) 、 ビュー （V) 、 及びコン トロ一ラ （C) オブジェク トにより分離されて扱われる。 コントローラは、 ユーザからのマウスとキ _ポ_ド入力のような入力を解釈し、 これらのユー ザアクションを、 適切な変更をもたらすためにモデル及び/又はビューに送 られるコマンドにマップするように作用する。 モデルは、 1以上のデータ要 素を管理するように作用し、 その状態に関するクエリに応答し、 状態を変更 する指示に応答する。 ビューは、 ディスプレイの長方形の領域を管理するよ うに作用し、 グラフィクスとテキス卜の組合せによりユーザにデータを提示 する機能を有する。
[0056] B. 文書処理システムの全体構成
文書処理システムの実施例は、 図 1 1 _29に関連して明らかにされる。
[0057] 図 1 1 (a) は、 後述するタイプの文書処理システムの基礎として機能す る要素の従来の構成例を示す。 構成 1 0は、 通信経路 1 3によりメモリ 1 2 に接続された CPU又はマイクロプロセッサ 1 1などの形式のプロセッサを 含む。 メモリ 1 2は、 現在又は将来に利用可能な任意の ROM及び/又は R AMの形式であってもよい。 通信経路 1 3は、 典型的にはバスとして設けら れる。 マウス、 キーボード、 音声認識システムなどのユーザ入力装置 1 4及 び表示装置 1 5 (又は他のュ一ザインタフェイス） に対する入出力インタフ ェイス 1 6も、 プロセッサ 1 1 とメモリ 1 2の通信のためのバスに接続され る。 この構成は、 スタンドアロンであってもよいし、 複数の端末及び 1以上 のサーバが接続されてネットワーク化された形式であってもよいし、 既知の いかなる方式により構成されてもよい。 本発明は、 これらのコンポーネント の配置、 集中又は分散されたアーキテクチャ一、 あるいは様々なコンポ一ネ ン卜の通信方法により制限されない。
[0058] さらに、 本システム及びここで議論される実施例は、 様々な機能性を提供 するいくつかのコンポ一ネント及びサブコンポ一ネントを含むものとして議 論される。 これらのコンポーネント及びサブコンポーネントは、 注目された 機能性を提供するために、 ハードウェアとソフトウエアの組合せだけでなく 、 ハ一ドウヱァのみ、 ソフトゥヱァのみによっても実現されうる。 さらに、 ハードウェア、 ソフトウェア、 及びそれらの組合せは、 汎用の計算装置、 専 用のハードウェア、 又はそれらの組合せにより実現されうる。 したがって、 コンポ一ネント又はサブコンポ一ネン卜の構成は、 コンポ一ネント又はサブ コンポ一ネン卜の機能性を提供するための特定のソフトウエアを実行する汎 用/専用の計算装置を含む。
[0059] 図 1 1 ( b ) は、 文書処理システムの一例の全体のブロック図を示す。 こ のような文書処理システムにおいて文書が生成され編集される。 これらの文 書は、 例えば X M Lなど、 マークアップ言語の特徴を有する任意の言語によ り記述されてもよい。 また、 便宜上、 特定のコンポーネント及びサブコンポ —ネン卜の用語及び表題を創造した。 しかしながら、 これらは、 この開示の 一般的な教示の範囲を制限するために解釈されるべきではない。
[0060] 文書処理システムは、 2つの基本的な構成を有するものととらえることが できる。 第 1の構成は、 文書処理システムが動作する環境である 「実行環境 」 1 0 1である。 例えば、 実行環境は、 文書の処理中及び管理中に、 ユーザ だけでなくシステムも支援する、 基本的なユーティリティ及び機能を提供す る。 第 2の構成は、 実行環境において走るアプリケーションから構成される 「アプリケーション」 1 0 2である。 これらのアプリケーションは、 文書自 身及び文書の様々な表現を含む。
[0061] 1. 実行環境
実行環境 1 01のキ一となるコンポ一ネントは Programl nvoker (プログラ ムインポ一力 ： プログラム起動部） 1 03である。 Programl nvoker 1 03は 、 文書処理システムを起動するためにアクセスされる基本的なプログラムで ある。 例えば、 ユーザが文書処理システムにログオンして開始するとき、 Pro gramlnvoker 1 03力《実行される。 Programl nvoker 1 03は、 例えば、 文書処 理システムにプラグインとして加えられた機能を読み出して実行させたり、 アプリケーションを開始して実行させたり、 文書に関連するプロパティを読 み出すことができる。 Programl nvoker 1 03の機能はこれらに限定されない 。 ユーザが実行環境内で実行されるように意図されたアプリケーションを起 動したいとき、 Programl nvoker 1 03は、 そのアプリケーションを見つけ、 それを起動して、 アプリケーションを実行する。
[0062] Programl nvoker 1 03には、 プラグインサブシステム 1 04、 コマンドサ ブシステム 1 05、 及び Resource (リソース） モジュール 1 09などのいく つかのコンポーネントがアタッチされている。 これらの構成については、 以 下に詳述する。
[0063] a) プラグインサブシステム
プラグインサブシステム 1 04は、 文書処理システムに機能を追加するた めの高度に柔軟で効率的な構成として使用される。 プラグインサブシステム 1 04は、 また、 文書処理システムに存在する機能を修正又は削除するため に使用することができる。 さらに、 種々様々の機能をプラグインサブシステ ムを使用して追加又は修正することができる。 例えば、 画面上への文書の描 画を支援するように作用する Editlet (エディットレット ：編集部） 機能を追 加することもできる。 Editletプラグインは、 システムに追加されるポキヤブ ラリの編集も支援する。
[0064] プラグインサブシステム 1 04は、 ServiceBroker (サービスブローカ ：サ —ビス仲介部） 1 041を含む。 ServiceBroker 1 041は、 文書処理システ ムに加えられるプラグインを管理することにより、 文書処理システムに加え られるサービスを仲介する。
[0065] 所望の機能性を実現する個々の機能は、 Service (サービス） 1 042の形 でシステムに追加される。 利用可能な Service 1 042のタイプは、 Appl icat ion (アプリケーション） サービス、 ZoneFactory (ゾーンファク トリ ： ゾ一 ン生成部） Service, Editlet (エディツトレット ：編集部） Service, Comma n dFactory (コマンドファク トリ ： コマンド生成部） Service、 ConnectXPath ( コネク ト XP a t h : XP a t h管理部） Service、 CSSComputat i on (CS S コンビュ一テ一シヨン： CS S計算部） Serviceなどを含むが、 これらに限定 されない。 これらの Service、 及びシステムの他の構成とそれらとの関係は、 文書処理システムについてのよりよい理解のために、 以下に詳述される。
[0066] プラグインと Serviceの関係は以下の通りである。 プラグインは、 1以上の ServiceProvider (サービスプロバイダ：サービス提供部） を含むことができ るュニットである。 それぞれの ServiceProviderは、 それに関連した Service の 1以上のクラスを有する。 例えば、 適切なソフトウェアアプリケーション を有する単一のプラグインを使用することにより、 1以上の Serviceをシステ ムに追加することができ、 これにより、 対応する機能をシステムに追加する ことができる。
[0067] b) コマンドサブシステム
コマンドサブシステム 1 05は、 文書の処理に関連したコマンドの形式の 命令を実行するために使用される。 ユーザは、 一連の命令を実行することに より、 文書に対する操作を実行することができる。 例えば、 ユーザは、 コマ ンドの形で命令を発行することにより、 文書処理システム中の XM L文書に 対応する XM Lの DOMツリーを編集し、 XML文書を処理する。 これらの コマンドは、 キ一ストローク、 マウスクリック、 又は他の有効なュ一ザイン タフェイスアクションを使用して入力されてもよい。 1つのコマンドにより 1以上の命令が実行されることもある。 この場合、 これらの命令が 1つのコ マンドにラップ （包含） され、 連続して実行される。 例えば、 ユーザが、 誤 つた単語を正しい単語に置換したいとする。 この場合、 第 1の命令は、 文書 中の誤った単語を発見することであり、 第 2の命令は、 誤った単語を削除す ることであり、 第 3の命令は、 正しい単語を挿入することであってもよい。 これらの 3つの命令が 1つのコマンドにラップされてもよい。
[0068] コマンドは、 関連した機能、 例えば、 後で詳述する 「アンドゥ」 機能を有 してもよい。 これらの機能は、 オブジェク トを生成するために使用されるい <つかの基本クラスにも割り当てられてもよい。
[0069] コマンドサブシステム 1 05のキ一となるコンポーネントは、 選択的にコ マンドを与え、 実行するように作用する Gommandlnvoker (コマンドインポ一 力 ： コマンド起動部） 1 05 1である。 図 1 1 (b) には、 1つの Gommandln vokerのみが示されているが、 1以上の Go國 andlnvokerが使用されてもよく、 1以上のコマンドが同時に実行されてもよい。 Gommandlnvoker 1 05 1は、 コマンドを実行するために必要な機能及びクラスを保持する。 動作において 、 実行されるべき Command (コマンド：命令） 1 052は、 Queue (キュー） 1 053に積まれる。 Gommandlnvokerは、 連続的に実行するコマンドスレツ ドを生成する。 Commandlnvoker内で既に実行中の Commandがなければ、 Comma n dlnvoker 1 05 1により実行されるように意図された Go國 and 1 052が実行 される。 Gommandlnvokerが既にコマンドを実行している場合、 新しし、 Command は、 Queue 1 053の最後に積まれる。 し力、しな力《ら、 それぞれの Command Inv oker 1 05 1では、 一度に 1つの Commandのみが実行される。 指定された Gomm andの実行に失敗した場合、 Go國 andlnvoker 1 05 1は例外処理を実行する。
[0070] Commandlnvoker 1 05 1により実行される Commandの型は、 Undoab I eComman d (取消可能コマンド） 1 054、 AsynchronousCommand (非同期コマンド） 1 055、 及び VGGo國 and (VCコマンド） 1 056を含むが、 これらに限定 されない。 Undoab I eCommand 1 054は、 ユーザが望めば、 その Commandの結 果を取り消すことが可能な Go國 andである。 Undoab leGo國 andの例として、 切 り取り、 コピー、 テキストの挿入、 などがある。 動作において、 ユーザが文 書の一部を選択し、 その部分に切り取りコマンドを適用するとき、 UndoableG o國 andを用いることにより、 切り取られた部分は、 必要であれば、 「切り取 られていない」 ようにすることができる。
[0071] VGGo國 andl 056は、 ポキヤブラリコネクション記述子 （Vocabulary Con nection Descriptor： V C D) スクリプトファイルに格納される。 これらは 、 プログラマにより定義されうるュ一ザ指定の Commandである。 Commandは、 例えば、 XM Lフラグメントを追加したり、 XM Lフラグメントを削除した り、 属性を設定したりするための、 より抽象的な Go國 andの組合せであっても よい。 これらの Go國 andは、 特に、 文書の編集に焦点を合わせている。
[0072] AsynchronousCommand 1 055は、 文書の口一ドゃ保存など、 システムより の Commandであり、 UndoableGommandや VGGommandとは別に、 非同期的に実行さ れる。 AsynchronousCommandは、 UndoableGommandではなしゝので、 取り消すこ とはできない。
[0073] c) リソース
Resource 1 09は、 様々なクラスに、 いくつかの機能を提供するオブジェ ク トである。 例えば、 ストリングリソース、 アイコン、 及びデフオルトキ一 バインドは、 システムで使用される Resourceの例である。
[0074] 2. アプリケーションコンポーネント
文書処理システムの第 2の主要な特徴であるアプリケ一シヨンコンポ一ネ ント 1 02は、 実行環境 1 01において実行される。 アプリケーションコン ポ一ネント 1 02は、 実際の文書と、 システム内における文書の様々な論理 的、 物理的な表現を含む。 さらに、 アプリケーションコンポーネント 1 02 は、 文書を管理するために使用されるシステムの構成を含む。 アプリケ一シ ヨンコンポーネント 1 02は、 さらに、 UserAppl ication (ユーザアプリケ一 シヨン） 1 06、 アプリケーションコア 1 08、 ュ一ザインタフェイス 1 0 7、 及び GoreGomponent (コアコンポーネント） 1 1 0を含む。
[0075] a) ユーザアプリケーション
UserAppl ication 1 06は、 Programl nvoker 1 03と共にシステム上に口一 ドされる。 UserAppl ication 1 06は、 文書と、 文書の様々な表現と、 文書と 対話するために必要なユーザィンタフェイスとをつなぐ接着剤となる。 例え ば、 ユーザが、 プロジェク 卜の一部である文書のセットを生成したいとする 。 これらの文書がロードされると、 文書の適切な表現が生成される。 ユーザ インタフェイス機能は、 UserApp l i cat i on 1 0 6の一部として追加される。 言 いかえれば、 UserApp l i cat i on 1 0 6は、 ユーザがプロジェク 卜の一部を形成 する文書と対話することを可能とする文書の表現と、 文書の様々な態様とを 、 共に保持する。 一旦 UserApp l i cat i on 1 0 6が生成されると、 ユーザがプロ ジェク 卜の一部を形成する文書との対話を望むたびに、 ユーザは簡単に実行 環境上に UserApp l i cat i on 1 0 6を口一ドすることができる。
[0076] b ) コアコンポ一ネント
CoreComponent 1 1 0は、 複数の Pane (ペイン） の間で文書を共有する方法 を提供する。 後で詳述するように、 Paneは、 D O Mツリーを表示し、 画面の 物理的なレイアウトを扱う。 例えば、 物理的な画面は、 個々の情報の断片を 描写する画面内の複数の Paneからなる。 ユーザから画面上に見える文書は、
1又はそれ以上の Paneに出現しうる。 また、 2つの異なる文書が画面上で 2 つの異なる Paneに現れてもよい。
[0077] 図 1 1 ( c ) に示されるように、 画面の物理的なレイアウトもツリーの形 式になっている。 Paneは、 RootPane (ルートペイン） 1 0 8 4にもなり得る し、 SubPane (サブペイン） 1 0 8 5にもなり得る。 RootPane 1 0 8 4は、 Pa neのツリーの根に当たる Paneであり、 SubPane 1 0 8 5は、 RootPane 1 0 8 4 以外の任意の Paneである。
[0078] CoreComponent 1 1 0は、 さらに、 フォントを提供し、 ツールキットなど、 文書のための複数の機能的な操作のソースの役割を果たす。 CoreComponent 1 1 0により実行されるタスクの一例に、 複数の Pane間におけるマウス力一ソ ルの移動がある。 実行されるタスクの他の例として、 ある Pane中の文書の一 部をマークし、 それを異なる文書を含む別の Pane上にコピーする。
[0079] c ) アプリケーションコア
上述したように、 アプリケーションコンポーネント 1 0 2は、 システムに より処理され管理される文書から構成される。 これは、 システム内における 文書の様々な論理的及び物理的な表現を含む。 アプリケーションコア 1 0 8 は、 アプリケーションコンポーネント 1 0 2の構成である。 その機能は、 実 際の文書を、 それに含まれる全てのデータとともに保持することである。 ァ プリケ一シヨンコア 1 0 8は、 DocumentManager (ドキュメントマネージャ ： 文書管理部） 1 0 8 1及び Document (ドキュメント ：文書） 1 0 8 2自身を 含む。
[0080] DocumentManager 1 0 8 1の様々な態様を以下に詳述する。 DocumentManage r 1 0 8 1は、 Document 1 0 8 2を管理する。 DocumentManager 1 0 8 1は、 R ootPane 1 0 8 4、 SubPane 1 0 8 5、 C I i pBoard (クリップポ一ド） ュ一ティ リティ 1 0 8 7、 及び Snapshot (スナップショット） ュ一ティリティ 1 0 8 8にも接続される。 G l i pBoardュ一ティリティ 1 0 8 7は、 ユーザがクリップ ポードに加えることを決定した文書の部分を保持する方法を提供する。 例え ば、 ユーザが、 文書の一部を切り取り、 後で再考するために新規文書にそれ を保存することを望んだとする。 このような場合、 切り取られた部分が G l i pB oardに追加される。
[0081 ] つづいて、 Snapshotュ一ティリティ 1 0 8 8についても説明する。 SnapSho tユーティリティ 1 0 8 8は、 アプリケーションがある状態から別の状態まで 移行するときに、 アブリケーションの現在の状態を記憶することを可能とす る。
[0082] d ) ュ一ザインタフェイス
アプリケーションコンポ一ネント 1 0 2の別の構成は、 ユーザがシステム と物理的に対話する手段を提供するユーザインタフェイス 1 0 7である。 例 えば、 ユーザインタフェイスは、 ユーザが文書をアップロードしたり、 削除 したり、 編集したり、 管理したりするために使用される。 ユーザインタフエ イスは、 Frame (フレーム） 1 0 7 1 、 MenuBar (メニューバ一） 1 0 7 2、 S tatusBar (ステータスバ一） 1 0 7 3、 及び URLBar ( U R Lバ一） 1 0 7 4 を含む。 [0083] Frame 1 07 1は、 一般に知られているように、 物理的な画面のアクティブ な領域であるとみなされる。 MenuBarl 072は、 ユーザに選択を提供するメ ニューを含む画面領域である。 StatusBarl 073は、 アプリケーションの実 行状態を表示する画面領域である。 URLBarl 074は、 インタ一ネットをナ ビゲー卜するために U R Lァドレスを入力する領域を提供する。
[0084] C. 文書管理及び関連するデータ構造
図 1 2は、 DocumentManager 1 081の詳細を示す。 これは、 文書処理シス テム内で文書を表現するために用いられるデータ構造及び構成を含む。 分か りやすくするために、 このサブセクションで説明される構成は、 MVCパラ ダイムを用いて説明される。
[0085] DocumentManager 1 081は、 文書処理システム内にある全ての文書を保持 しホストする DocumentGontainer (ドキュメントコンテナ：文書コンテナ） 2 03を含む。 DocumentManager 1 081にァタツチされたツールキット 201 は、 DocumentManager 1 081により使用される様々なツールを提供する。 例 えば、 DomService (DOMサービス） は、 文書に対応する D OMを生成し、 保持し、 管理するために必要とされる全ての機能を提供するために、 ツール キット 201により提供されるツールである。 ツールキット 201により提 供される別のツールである lOManager (入出力管理部） は、 システムへの入力 及びシステムからの出力を管理する。 同様に、 StreamHandler (ストリームハ ンドラ） は、 ビットストリームによる文書のアップロードを扱うツールであ る。 これらのツールは、 図中に特に示さず、 参照番号を割り当てないが、 ッ —ルキット 201のコンポ一ネントを形成する。
[0086] MVCパラダイムの表現によれば、 モデル （M) は、 文書の DOMツリー モデル 202を含む。 前述したように、 全ての文書は、 文書処理システムに おいて DOMツリーとして表現される。 文書は、 また、 DocumentGontainer 2 03の一部を形成する。
[0087] 1. DOMモデル及びゾーン
文書を表現する DOMツリーは、 Node (ノード） 2021を有するツリー である。 DOMツリーの部分集合である Zone (ゾーン） 209は、 DOMッ リー内の 1以上の Nodeの関連領域を含む。 例えば、 画面上で文書の一部のみ を表示し得るが、 この可視化された文書の一部は Zone 209を用いて表示さ れる。 Zoneは、 ZoneFactory (ゾーンファク トリ ： ゾーン生成部） 205と呼 ばれるプラグインを用いて、 生成され、 取り扱われ、 処理される。 Zoneは D OMの一部を表現するが、 1以上の 「名前空間」 を使用してもよい。 よく知 られているように、 名前空間は、 名前空間内でユニークな名前の集合である 。 換言すれば、 名前空間内に同じ名前は存在しない。
[0088] 2. Facet及び Facetと Zoneとの関係
Facet (ファセット） 2022は、 MVCパラダイムのモデル （M) 部分内 の別の構成である。 Facetは、 Zoneにおいて Nodeを編集するために使用される 。 Facet2022は、 Zone自身の内容に影響を与えずに実行することができる 手続 （プロシージャ） を使用して、 DOMへのアクセスを編成する。 次に説 明するように、 これらの手続は、 Nodeに関連した重要で有用な操作を実行す る。
[0089] 各 Nodeは、 対応する Facetを有する。 D O Mの中の Nodeを直接操作する代わ りに、 操作を実行するために Facetを使用することによって、 DOMの保全性 は保護される。 操作が Node上で直接実行される場合、 いくつかのプラグイン が DOMを同時に変更することができ、 その結果矛盾を引き起こす。
[0090] W3 Cが策定した DOMの標準規格は、 Nodeを操作するための標準的なィ ンタフェイスを定義するが、 実際には、 ポキヤブラリごと又は Nodeごとに特 有の操作があるので、 これらの操作を AP I として用意しておくのが好都合 である。 文書処理システムでは、 このような各 Nodeに特有の A P Iを Facetと して用意し、 各 Nodeにアタッチする。 これにより、 DOMの標準規格に準拠 しつつ、 有用な AP Iを付加することができる。 また、 ポキヤブラリごとに 特有の DO Mを実装するのではなく、 標準的な DO Mの実装に、 後から特有 の AP Iを付加するようにすることで、 多様なポキヤブラリを統一的に処理 することができるともに、 複数のポキャプラリが任意の組合せで混在した文 書を適切に処理することができる。
[0091] ポキヤブラリは、 名前空間に属するタグ （例えば XMLのタグ） のセット である。 上述したように、 名前空間は、 ユニークな名前 （ここではタグ） の セットを有する。 ポキヤブラリは、 XM L文書を表現する DOMツリーのサ ブツリーとして現れる。 このサブツリーは Zoneを含む。 特定の例においては 、 タグセットの境界は Zoneによって定義される。 Zone209は、 ZoneFactory 205と呼ばれる Serviceを利用して生成される。 上述したように、 Zone 20 9は、 文書を表現する DOMツリーの一部の内部表現である。 このような文 書の一部へのアクセスを提供するために、 論理的な表現が要求される。 この 論理的表現は、 文書が画面上で論理的にどのように表現されるかについてコ ンピュータに通知する。 Canvas (キャンバス） 21 0は、 Zoneに対応する論 理的なレイァゥトを提供するように作用する Serviceである。
[0092] 他方、 Pane 21 1は、 Canvas 21 0により提供される論理的なレイァゥト に対応する物理的な画面レイアウトである。 実際、 ユーザは表示画面上で文 字や画像によって文書のレンダリングのみを見る。 したがって、 文書は、 画 面上に文字や画像を描画するプロセスにより、 画面上に描写されなければな らない。 文書は、 Pane21 1により提供される物理的なレイアウトに基づい て、 Canvas 21 0により画面上に描写される。
[0093] Zone209に対応する Ganvas21 0は、 Editlet206を使用して生成され る。 文書の DOMは、 Editlet206及び Ganvas21 0を使用して編集される 。 元の文書の完全性を維持するために、 Editlet206及び Ganvas21 0は、 Zone 209における 1以上の Nodeに対応する Facetを使用する。 これらの Serv iceは、 Zone及び D OM内の Nodeを直接操作しない。 Facetは、 Gommand207 を利用して操作される。
[0094] ユーザは、 一般に、 画面上のカーソルを移動させたり、 コマンドをタイプ したりすることによって、 画面と対話する。 画面上の論理的なレイアウトを 提供する Canvas 21 0は、 この力一ソル操作を受け付ける。 Canvas 21 0は 、 対応するアクションを Facetに実行させることができる。 この関係により、 力一ソルサブシステム 2 0 4は、 DocumentManager 1 0 8 1に対して、 M V C パラダイムのコントローラ （C ) として機能する。 Ganvas 2 1 0は、 ィベン トを扱うタスクも有する。 例えば、 Canvas 2 1 0は、 マウスクリック、 フォ —カス移動、 及びユーザにより起こされた同様のアクションなどのィベント を扱う。
[0095] 3 . Zone, Facet, Canvas及び Paneの間の関係の概要
文書処理システム内の文書は、 少なくとも 4つの観点から見ることができ る。 すなわち、 1 ) 文書処理システムにおいて文書の内容及び構造を保持す るために用いられるデータ構造、 2 ) 文書の保全性に影響を与えずに文書の 内容を編集する手段、 3 ) 文書の画面上の論理的なレイアウト、 4 ) 文書の 画面上の物理的なレイアウト、 である。 Zone、 Facet, Canvas及び Paneは、 前 述の 4つの観点に相当する、 文書処理システムのコンポ一ネントをそれぞれ 表す。
[0096] 4 . アンドゥサブシステム
上述したように、 文書に対するいかなる変更 （例えば編集） も取消可能で あることが望ましい。 例えば、 ユーザが編集操作を実行し、 次に、 その変更 の取消を決定したとする。 図 1 2に関連して、 アンドゥサブシステム 2 1 2 は、 文書管理部の取消可能なコンポーネントを実現する。 UndoManager (アン ドウマネージャ ： アンドウ管理部） 2 1 2 1は、 ユーザによって取り消され る可能性のある全ての文書に対する操作を保持する。
[0097] 例えば、 ユーザが、 文書中の単語を別の単語に置換するコマンドを実行し たとする。 その後、 ユーザは考え直し、 元の単語に戻すことを決定したとす る。 アンドゥサブシステム 2 1 2は、 このような操作を支援する。 UndoManag er 2 1 2 1は、 このような Undoab l eEd i t (アンドゥアプルエディツト ：取消 可能な編集） 2 1 2 2の操作を保持する。
[0098] 5 . 力一ソルサブシステム
前述したように、 M V Cのコントローラ部分は、 力一ソルサブシステム 2 0 4を備えてもよい。 力一ソルサブシステム 2 0 4は、 ユーザから入力を受 け付ける。 これらの入力は、 一般にコマンド及び/又は編集操作の性格を有 している。 したがって、 力一ソルサブシステム 204は、 DocumentManager 1 081に関連した MVCパラダイムのコントローラ （C) 部分であると考え ることができる。
[0099] 6. ビュー
前述したように、 Canvas 21 0は、 画面上に提示されるべき文書の論理的 なレイアウトを表す。 XHTML文書の例では、 Ganvas21 0は、 文書が画 面上でいかに見えるかを論理的に表現したボックスツリー 208を含んでも よい。 このボックスツリー 208は、 DocumentManager 1 081に関連した M VCパラダイムのビュー （V) 部分に含まれよう。
[0100] D. ポキヤブラリコネクション
文書処理システムの重要な特徴は、 X ML文書を、 他の表現にマップして 取り扱うことが可能で、 かつ、 マップした先の表現を編集すると、 その編集 が元の X ML文書に整合性を保ちつつ反映される環境を提供することにある
[0101] マークアップ言語により記述された文書、 例えば XML文書は、 文書型定 義により定義されたポキヤブラリに基づいて作成されている。 ポキヤブラリ は、 タグのセットである。 ポキヤブラリは、 任意に定義されてもよいため、 無限に多くのポキヤブラリが存在しうる。 しかしながら、 多数の可能なポキ ャブラリのそれぞれに対して専用の処理/管理環境を提供するのは現実的で はない。 ポキヤブラリコネクションは、 この問題を解決する方法を提供する
[0102] 例えば、 文書は 2以上のマークアップ言語により記述されてもよい。 文書 は、 例えば、 XHTML (extensible HyperText Markup Language) 、 S V G (Scalable Vector Graphics) 、 Ma t h M L (Mathematical Markup Lan guage) 、 その他のマークアップ言語により記述されてもよい。 換言すれば、 マークアップ言語は、 XMLにおけるポキヤブラリゃタグセッ卜と同様に見 なされてもよい。 [0103] ポキヤブラリは、 ポキヤブラリブラグィンを用いて処理される。 文書処理 システムにおいてプラグィンが利用不可能であるポキャプラリにより記述さ れた文書は、 プラグィンが利用可能である別のポキャプラリの文書にマツピ ングすることにより表示される。 この特徴により、 プラグインが用意されて いないポキャプラリの文書も適切に表示することができる。
[0104] ポキヤブラリコネクションは、 定義ファイルを取得し、 取得した定義ファ ィルに基づいて 2つの異なるポキャプラリの間でマツビングする能力を含む 。 あるポキヤブラリで記述された文書は、 別のポキヤブラリにマッピングす ることができる。 このように、 ポキヤブラリコネクションは、 文書がマツピ ングされるポキヤブラリに対応した表示/編集プラグインにより文書を表示 し編集することを可能にする。
[0105] 上述したように、 各文書は、 一般に複数のノードを有する D O Mツリーと して文書処理システムにおいて記述される。 「定義ファイル」 は、 それぞれ のノードについて、 そのノードと他のノードとの対応を記述する。 各ノード の要素値及び属性値が編集可能か否かが指定される。 ノードの要素値又は属 性値を用いた演算式が記述されてもよい。
[0106] マッピングという特徴を利用して、 定義ファイルを適用したデステイネ一 シヨン D O Mツリーが生成される。 このように、 ソース D O Mツリーとデス ティネ一シヨン D O Mッリ一の関係が構築され保持される。 ポキヤブラリコ ネクシヨンは、 ソース D O Mツリーとデスティネーション D O Mツリーの対 応を監視する。 ユーザから編集指示を受けると、 ポキヤブラリコネクション は、 ソース D O Mツリーの関連したノードを変更する。 ソース D O Mツリー が変更されたことを示す 「ミューテ一シヨンイベント」 が発行され、 デステ イネ一シヨン D O Mツリーがそれに応じて変更される。
[0107] ポキヤブラリコネクションの使用により、 少数のユーザのみに知られてい た比較的マイナーなポキャプラリを、 別のメジャーなポキャプラリに変換す ることができる。 したがって、 少数のユーザによって利用されるマイナーな ポキヤブラリであっても、 文書を適切に表示し、 望ましい編集環境を提供す ることができる。
[0108] このように、 文書処理システムの一部であるポキヤブラリコネクションサ ブシステムは、 文書の複数の表現を可能にする機能を提供する。
[0109] 図 1 3は、 ポキヤブラリコネクション （VC ： Vocabulary Connection) サ ブシステム 300を示す。 VCサブシステム 300は、 同一の文書の 2つの 代替表現の整合性を維持する方法を提供する。 例えば、 2つの表現は、 同一 文書の、 2つの異なるポキヤブラリによる表現であってもよい。 前述したよ うに、 一方はソース DOMツリーであってもよく、 他方はデスティネ一ショ ン D O Mッリ—であってもよい。
[0110] 1. ポキヤブラリコネクションサブシステム
ポキヤブラリコネクションサブシステム 300の機能は、 VocabularyGonne ction301 と呼ばれるプラグインを使用して、 文書処理システムにおいて実 現される。 文書が表現される Vocabulary305ごとに、 対応するプラグイン が要求される。 例えば、 文書の一部が H TM Lで記述され、 残りが SVGで 記述されている場合、 H T M Lと S V Gに対応するポキヤブラリプラグィン が要求される。
[0111] VocabularyGonnectionプラグイン 301は、 適切な Vocabulary 305の文 書に対応した、 Zone209又は Pane21 1のための適切な VGGanvas (ポキヤ ブラリコネクションキャンバス） 31 0を生成する。 VocabularyGonnection 301を用いて、 ソース DOMツリー内の Zone209に対する変更は、 変換 ルールにより、 別の DOMツリー 306の対応する Zoneに伝達される。 変換 ゾレ一ゾレは、 ポキヤブラリコネクション記述子 (Vocabulary Connection Descr iptor： VCD) の形式で記述される。 このようなソース DOMとデスティネ —シヨン DOMの間の変換に対応するそれぞれの VC Dファイルについて、 対応する VGManager (ポキヤブラリコネクションマネージャ） 302が生成さ れる。
[0112] 2. Connector
Connector 304は、 ソース D OMツリーのソースノードと、 デステイネ一 シヨン DOMツリーのデスティネーションノ一ドとを接続する。 Gonnector3 04は、 ソース DO Mツリー中のソースノード、 及びソースノードに対応す るソース文書に対する修正 （変更） を見るために作用する。 そして、 対応す るデスティネーション DOMツリーのノ一ドを修正する。 Gonnector304は 、 デスティネーション DOMツリーを修正することができる唯一のオブジェ ク トである。 例えば、 ユーザは、 ソース文書、 及び対応するソース DOMッ リ一に対してのみ修正を行うことができる。 その後、 Connector 304がデス ティネ一シヨン DOMツリーに、 対応する修正を行う。
[0113] Connector 304は、 ツリー構造を形成するために、 論理的にリンクされる 。 Connector 304により形成されたツリーは、 GonnectorTree (コネクタッ リ一） と呼ばれる。 Connector 304は、 GonnectorFactory (コネクタファク トリ ： コネクタ生成部） 303と呼ばれる Serviceを用いて生成される。 Gonn ectorFactory 303は、 ソース文書から Connector 304を生成し、 それらを リンクして GonnectorTreeを形成す 。 Vocabu laryGonnectionManager 302 は、 GonnectorFactory 303を保持する。
[0114] 前述したように、 ポキヤブラリは名前空間におけるタグのセットである。
図示されるように、 Vocabulary 305は、 Vocabu I aryConnect i on 301によ つて文書に対して生成される。 これは、 文書ファイルを解析し、 ソース DO Mとデスティネ一シヨン D O Mの間の写像のための適切な Vocabu I aryConnect ionManager 302を生成することにより行われる。 さらに、 Connectorを生成 する GonnectorFactory 303と、 Zone 209を生成する ZoneFactory 205と 、 Zone内のノードに対応する Canvasを生成する Editlet206との間の適切な 関係が作られる。 ユーザがシステムから文書を処分又は削除するとき、 対応 する Vocabu laryGonnectionManager 302が削除される。
[0115] Vocabulary305は、 VGGanvas31 0を生成する。 さらに、 Connector 30 4及びデスティネーション DOMツリー 306が対応して生成される。
[0116] ソース DO M及び Canvasは、 それぞれ、 モデル （M) 及びビュー （V) に 対応する。 しかしながら、 このような表現は、 ターゲットのポキヤブラリが 画面上に描写可能である場合に限って意味がある。 描写は、 ポキヤブラリブ ラグインにより行われる。 ポキャプラリプラグィンは、 主要なポキャプラリ 、 例えば、 XHTML、 SVG、 Ma t h M Lについて提供される。 ポキヤ ブラリブラグィンは、 ターゲットのポキヤブラリに関連して使用される。 こ れらは、 ポキャプラリコネクション記述子を用いてポキャプラリ間でマッピ ングする方法を提供する。
[0117] このようなマッピングは、 ターゲットのポキヤブラリカ マッピング可能 で、 画面上に描写される方法が予め定義されたものである場合にのみ意味が ある。 このようなレンダリング方法は、 例えば X H TM Lなどのように、 W 3 Cなどの組織により定義された標準規格となっている。
[0118] ポキヤブラリコネクションが必要であるとき、 VGGanvasが使用される。 こ の場合、 ソースのビューを直接生成することができないので、 ソースの Ganva sは生成されない。 この場合、 VGGanvasが、 GonnectorTreeを使用して生成さ れる。 この VGGanvasは、 イベントの変換のみを扱い、 画面上の文書の描写を 援助しない。
[0119] 3. DestinationZone、 Pane、 及び Canvas
上述したように、 ポキヤブラリコネクションサブシステムの目的は、 同一 の文書の 2つの表現を同時に生成し保持することである。 第 2の表現も、 D OMツリーの形式であり、 これはデスティネーション DOMツリーとして既 に説明した。 第 2の表現における文書を見るために、 DestinationZone、 Canv as及び Paneが必要である。
[0120] VGGanvasが作成されると、 対応する DestinationPane307が生成される。
さらに、 関連する0651^1131^011031^35308と、 対応する BoxTree309が生 成される。 同様に、 VGGanvas 31 0も、 ソース文書に対する Pane 21 1及び Z one209に関連づけられる。
[0121] DestinationGanvas308は、 第 2の表現における文書の論理的なレイァゥ トを提供する。 特に、 DestinationGanvas308は、 デスティネーション表現 における文書を描写するために、 カーソルや選択のようなユーザインタフエ イス機能を提供する。 DestinationGanvas308に生じたイベントは、 Gonnec torに供給される。 DestinationGanvas308は、 マウスイベント、 キ一ポ一 ドイベント、 ドラッグアンドドロップイベント、 及び文書のデスティネ一シ ヨン （第 2) 表現のポキヤブラリに特有なイベントを、 Connector 304に通 知する。
[0122] 4. ポキヤブラリコネクションコマンドサブシステム
ポキヤブラリコネクション （VC) サブシステム 300の要素として、 ポ キヤブラリコネクション （VC) コマンドサブシステム 31 3がある。 ポキ ャブラリコネクションコマンドサブシステム 31 3は、 ポキヤブラリコネク シヨンサブシステム 300に関連した命令の実行のために使用される VGGo國 a nd (ポキヤブラリコネクションコマンド） 31 5を生成する。 VGGo國 andは、 内蔵の Go國 andTemplate (コマンドテンプレー ト） 31 8を使用して、 及び/ 又は、 スクリプトサブシステム 31 4においてスクリプト言語を使用してス クラッチからコマンドを生成することにより、 生成することができる。
[0123] コマンドテンプレートには、 例えば、 「lf」 コマンドテンプレート、 「Whe n」 コマンドテンプレート、 「揷入 （Insert) 」 コマンドテンプレートなどが ある。 これらのテンプレートは、 VGGommandを作成するために使用される。
[0124] 5. XP a t hサブシステム
X P a t hサブシステム 31 6は、 文書処理システムの重要な構成であり 、 ポキヤブラリコネクションの実現を支援する。 Connector 304は、 一般に xpath情報を含む。 上述したように、 ポキヤブラリコネクションのタスクの 1 つは、 ソース DOMツリーの変化をデスティネーション DOMツリーに反映 させることである。 xpath情報は、 変更/修正を監視されるべきソース DOM ツリーのサブセットを決定するために用いられる 1以上の xpath表現を含む。
[0125] 6. ソース DOMツリー、 デスティネーション DOMツリー、 及び Connect orTreeの概要
ソース DO Mツリーは、 別のポキャプラリに変換される前のポキャプラリ で文書を表現した D O Mッリ一又は Zoneである。 ソース D O Mツリーのノ一 ドは、 ソースノードと呼ばれる。
[0126] それに対して、 デスティネーション D O Mツリーは、 ポキヤブラリコネク シヨンに関連して前述したように、 同一の文書を、 マッピングにより変換さ れた後の異なるポキャプラリで表現した D O Mッリ一又は Zoneである。 デス ティネ一シヨン D O Mツリーのノードは、 デスティネーションノードと呼ば れる。
[0127] GonnectorTreeは、 ソースノードとデスティネーションノードの対応を表す Connectorに基づく階層的表現である。 Connectorは、 ソースノードと、 ソ一 ス文書になされた修正を監視し、 デスティネーション D O Mツリーを修正す る。 Connectorは、 デスティネーション D O Mツリーを修正することを許され た唯一のオブジェク トである。
[0128] E . 文書処理システムにおけるイベントフロー
実用のためには、 プログラムはユーザからのコマンドに応答しなければな らない。 イベントは、 プログラム上で実行されたユーザアクションを記述し 実行する方法である。 多くの高級言語、 例えば J a V a (登録商標） は、 ュ —ザアクションを記述するイベントに頼っている。 従来、 プログラムは、 ュ 一ザアクションを理解し、 それを自身で実行するために、 積極的に情報を集 める必要があった。 これは、 例えば、 プログラムが自身を初期化した後、 ュ —ザが画面、 キーボード、 マウスなどでアクションを起こしたときに適切な 処理を講じるために、 ユーザのアクションを繰り返し確認するループに入る ことを意味する。 しかしながら、 このプロセスは扱いにくい。 さらに、 それ は、 ユーザが何かをするのを待つ間、 C P Uサイクルを消費してループする プログラムを必要とする。
[0129] 多くの言語が、 異なるパラダイムを採用することにより、 これらの問題を 解決している。 そのうちの一つは、 現代の全てのウィンドウシステムの基礎 となっている、 イベントドリブンプログラミングである。 このパラダイムで は、 全てのユーザアクションは、 「イベント」 と呼ばれる抽象的な事象の集 合に属する。 イベントは、 十分詳細に、 特定のユーザアクションを記述する 。 プログラムがユーザにより生成されたィベントを積極的に収集するのでは なく、 監視すべきイベントが生じたときに、 システムがプログラムに通知す る。 この方法によりユーザとの対話を扱うプログラムは 「イベントドリブン 」 であると言われる。
[0130] これは、 多くの場合、 全てのユーザにより生成されたイベントの基本特性 を獲得する 「Event (イベント） 」 クラスを使用して扱われる。
[0131 ] 文書処理システムは、 自身のイベント、 及びこれらのイベントを扱う方法 を定義して使用する。 いくつかの型のイベントが使用される。 例えば、 マウ スイベントは、 ユーザのマウスアクションから起こるイベントである。 マウ スを含むユーザアクションは、 Canvas 2 1 0によって、 マウスイベントに渡 される。 このように、 Canvasは、 システムのユーザによる相互作用の最前部 にあると言える。 必要であれば、 最前部にある Canvasは、 そのイベントに関 連した内容を子へ渡す。
[0132] それに対して、 キースト口一クイベントは、 Canvas 2 1 0から流れる。 キ —ストロークイベントは、 即時的なフォーカスを有する。 すなわち、 それは 、 いかなる瞬間でも作業に関連する。 Ganvas 2 1 0上に入力されたキースト ロークイベントは、 その親に渡される。 キー入力は、 文字列挿入を扱うこと が可能な、 異なるイベントによって処理される。 文字列の挿入を扱うィベン トは、 キーボードを使用して文字が挿入されたときに発生する。 他の 「ィべ ント」 は、 例えば、 ドラッグイベント、 ドロップイベント、 マウスイベント と同様に扱われる他のィベントを含む。
[0133] 1 . ポキヤブラリコネクション外のイベントの取り扱い
イベントは、 イベントスレッドを用いて渡される。 Ganvas 2 1 0は、 ィべ ントを受け取ると、 その状態を変更する。 必要であれば、 Go國 and l 0 5 2が Canvas 2 1 0により GommandQueue 1 0 5 3にポストされる。
[0134] 2 . ポキヤブラリコネクション内のイベントの取り扱い
Vocabu l aryConnect i on 3 0 1 ¾：用しゝて、 Dest i nat i onCanvas(7— 例である XHTMLGanvas l 1 0 6は、 発生したイベント、 例えば、 マウスィベン ト、 キ一ポ一ドイベント、 ドラッグァンドドロップイベント、 及びポキヤブ ラリに特有のイベントなどを受け取る。 これらのイベントは、 コネクタ 30 4に通知される。 より詳細には、 図 21 (b) に図示されるように、 Vocabul aryGonnectionプラグイン 301内のイベントフローは、 SourcePane 1 1 03 、 VCCanvas 1 1 04、 DestinationPane 1 1 05、 DestinationGanvasの一例 である DestinationGanvas 1 1 06、 デスティネーション D O Mツリー及び Go nnector丁 ree¾r通過する。
[0135] F. Programlnvoker及び Programlnvokerと他の構成との関係
Programlnvoker 1 03及びそれと他の構成との関係は、 図 1 4 (a) に更 に詳細に示される。 Programlnvoker 1 03は、 文書処理システムを開始する ために実行される実行環境中の基本的なプログラムである。 図 1 1 (b) 及 び図 1 1 (c) に図示されるように、 UserAppl ication 1 06、 ServiceBroke r 1 041、 Command I nvoker 1 051、 及び Resource 1 09は、 全て Program I nvoker 1 03に接続される。 前述したように、 アプリケーション 1 02は、 実行環境中で実行されるコンポーネントである。 同様に、 ServiceBroker 1 0 41は、 システムに様々な機能を加えるプラグインを管理する。 他方、 Go國 a ndlnvoker 1 051は、 ユーザにより提供される命令を実行して、 コマンドを 実行するために使用されるクラス及びファンクションを保持する。
[0136] 1. プラグイン及びサービス
ServiceBroker 1 041について、 図 1 4 (b) を参照して更に詳細に説明 する。 前述したように、 ServiceBroker 1 041は、 システムに様々な機能を 追加するプラグイン （及び関連するサービス） を管理する。 Service 1 042 は、 文書処理システムに特徴を追加又は変更可能な最も下の層である。 「Ser vice」 は、 ServiceGategory401 と ServiceProvider 402の 2つの咅 |5分力、 らなる。 図 1 4 ( c ) に図示されるように、 1っの361^ 6031：680^40 1は 、 複数の関連する ServiceProvider402を持ちうる。 それぞれの ServicePro V i derは、 特定の Serv i ceGategoryの一部または全部を実行するように作用す る。 ServiceGategory401は、 他方では、 Serviceの型を定義する。 [0137] Serviceは、 1 ) 文書処理システムに特定の特色を提供する 「特色サービス 」 、 2) 文書処理システムにより実行されるアプリケーションである 「アブ リケ一シヨンサービス」 、 3) 文書処理システムの全体にわたって必要な特 色を提供する 「環境サービス」 、 の 3つの型に分類することができる。
[0138] Serviceの例は、 図 1 4 ( d ) に示される。 アプリケーション Serviceの Gat egoryにおいては、 システムユーティリティカ《対応する ServiceProviderのイ列 である。 同様に、 Editlet206は Categoryであり、 HTMLEditlet及び SVGEdit letは対応する ServiceProviderであ 。 ZoneFactory 205は、 Serviceの別 の Categoryであり、 対応する ServiceProvider (図示せず） を有する。
[0139] プラグインは、 文書処理システムに機能性を加えると既に説明したが、 い <つかの ServiceProvider 402及びそれらに関連するクラスからなるュニッ 卜と見なされてもよい。 各プラグインは、 宣言ファイルに記述された依存性 及び ServiceGategory40 1を有する。
[0140] 2. Program Invokerとアプリケーションとの関係
図 1 4 ( e ) は、 Programlnvoker 1 03と UserAppl ication 1 06との関係 についての更なる詳細を示す。 必要な文書やデータなどは、 ストレージから ロードされる。 必要なプラグインは、 全て ServiceBroker 1 04 1上にロード される。 ServiceBroker 1 04 1は、 全てのプラグインを保持し管理する。 プ ラグインは、 システムに物理的に追加することができ、 又、 その機能はスト レ一ジからロードすることができる。 プラグインの内容がロードされると、 S erviceBroker 1 04 1は、 対応するプラグインを定義する。 つづいて、 対応 する UserAppl ication 1 06が生成され、 実行環境 1 0 1にロードされ、 Prog ramlnvoker 1 03にアタッチされる。
[0141] G. アプリケーションサービスと環境との関係
図 1 5 (a) は、 Programlnvoker 1 03上にロードしたアプリケーション サービスの構成についての更なる詳細を示す。 コマンドサブシステム 1 05 のコン不一ネン卜である Command Invoker 1 05 1は、 Programlnvoker 1 03 内の Command 1 052を起動又は実行する。 Command 1 052は、 文書処理シ ステムにおいて、 XM Lなどの文書を処理し、 対応する XM L DOMツリー を編集するために用いられる命令である。 Command I nvoker 1 051は、 Comma nd1 052を実行するために必要なクラス及びファンクションを保持する。
[0142] ServiceBroker 1 041も、 Programl nvoker 1 03内で実行される。 UserAp pi i cat ion 1 06は、 ュ一ザインタフェイス 1 07及び GoreGomponent 1 1 0 に接続される。 GoreGomponent 1 1 0は、 全ての Paneの間で文書を共有する方 法を提供する。 GoreGomponent 1 1 0は、 さらにフォントを提供し、 Paneのた めのツールキッ卜の役割を果たす。
[0143] 図 1 5 ( b ) は、 Frame 1 07 1、 MenuBar 1 072、 及び StatusBar 1 07 3の関係を示す。
[0144] H. アプリケーションコア
図 1 6 (a) は、 全ての文書、 及び文書の一部及び文書に属するデータを 保持するアプリケーションコア 1 08についての更なる説明を提供する。 Gor eComponent 1 1 0は、 文書 1 082を管理する DocumentManager 1 081にァ タツチされる。 DocumentManager 1 081は、 文書処理システムに関連づけら れたメモリに格納される全ての文書 1 082の所有者である。
[0145] 画面上の文書の表示を容易にするために、 DocumentManager 1 081は Root Pane 1 084にも接続される。 GI ipBoard 1 087、 SnapShot 1 088、 Drag &Drop601、 及び Over I ay602の機能も、 GoreGomponent 1 1 0にアタッチ される。
[0146] SnapShot 1 088は、 アプリケーションの状態を元に戻すために使用され る。 ユーザが SnapShot 1 088を起動したとき、 アプリケーションの現状が 検知され、 格納される。 その後、 アプリケーションの状態が別の状態に変わ るとき、 格納された状態の内容は保存される。 SnapShotl 088は、 図 1 6 (b) に図示される。 動作において、 アプリケーションがある U R Lから他 へ移動するときに、 前に戻る動作及び先に進む動作をシームレスに実行可能 とするために、 SnapShotl 088は以前の状態を記憶する。
[0147] I . DocumentManager内における文書の構成 図 1 7 (a) は、 DocumentManager 1 081の更なる説明と、 DocumentMana gerにおいて文書が構成され保持される様子を示す。 図 1 1 (b) に示したよ うに、 DocumentManager 1 081は、 文書 1 082を管理する。 図 1 7 (a) に示される例において、 複数の文書のうちの 1つは RootDocument (ルート文 書） 701であり、 残りの文書は SubDocument (サブ文書） 702である。 Do cumentManager 1 081は、 RootDocument 701に接糸元され、 RootDocument 7 01は、 全ての SubDocument 702に接続される。
[0148] 図 1 2及び図 1 7 (a) に示すように、 DocumentManager 1 081は、 全て の文書 1 082を管理するォブジェク トでぁる00(51^6111:00111：3^6「203に結 合される。 D0MService703及び lOManager 704を含むツールキット 201 (例えば XM Lツールキット） の一部を形成するツールも、 DocumentManager 1 081に供給される。 再び図 1 7 (a) を参照して、 D0MService703は 、 DocumentManager 1 081により管理される文書に基づいた D O Mツリーを 生成する。 各 Document 705は、 それが RootDocument 701であっても SubDo cument702であっても、 対応する DocumentGontainer 203によって管理さ れる。
[0149] 図 1 7 (b) は、 文書 A_Eが階層的に配置される様子を示す。 文書 Aは R ootDocumentである。 文書 B— Dは、 文書 Aの SubDocumentである。 文書 Eは 、 文書 Dの SubDocumentである。 図 1 7 (b) の左側は、 これと同じ文書の階 層が画面上に表示された例を示す。 RootDocumentである文書 Aは、 基本フレ —ムとして表示される。 文書 Aの SubDocumentである文書 B_ Dは、 基本フレ —ム Aの中のサブフレームとして表示される。 文書 Dの SubDocumentである文 書 Eは、 サブフレーム Dのサブフレームとして画面に表示される。
[0150] 再び図 1 7 (a) を参照して、 UndoManager (アンドゥマネージャ ： アンド ゥ管理部） 706及び UndoWrapper (アンドゥラッパ一） 707は、 それぞれ の DocumentGontainer 203に対して生成される。 UndoManager706及び Und oWrapper 707は、 取消可能なコマンドを実行するために使用される。 この 特徴を使用することにより、 編集操作を使用して文書に対して実行された変 更を取り消すことができる。 SubDocumentの変更は、 RootDocumentとも密接な 関係を有する。 アンドゥ操作は、 階層内の他の文書に影響する変更を考慮に 入れて、 例えば、 図 1 7 (b) に示されるような連鎖状の階層における全て の文書の間で整合性が維持されることを保証する。
[0151] UndoWrapper 707は、 DocumentGontainer 203内の SubDocumentに関連す るアンドゥオブジェク トをラップし、 それらを RootDocumentに関連するアン ドウオブジェク 卜に結合させる。 UndoWrapper 707は、 UndoableEditAccept or (アンドウアプルエディットァクセプタ ： アンドウ可能編集受付部） 70 9に利用可能なアンドウオブジェク 卜の収集を実行する。
[0152] UndoManager 706及び UndoWrapper 707は、 Undoab I eEd i tAcceptor 70 9及び UndoableEditSource (アンドゥァブルエディットソース） 708に接 続される。 当業者には理解されるように、 Document705が UndoableEditSou rce708であってもよく、 取消可能な編集オブジェク 卜のソースであっても よい。
[0153] J . アンドゥコマンド及びアンドゥフレームワーク
図 1 8 (a) 及び図 1 8 (b) は、 アンドゥフレームワーク及びアンドゥ コマンドについて更なる詳細を提供する。 図 1 8 (a) に示されるように、 U ndoCommand 80 1、 RedoCommand 802、 及び UndoableEditGommand803は 、 図 1 1 (b) に示したように Gommandlnvoker 1 05 1に積むことができる コマンドであり、 順に実行される。 UndoableEditGommand803は、 Undoab le EditSource708及び Undoab I eEd i tAcceptor 709に更にァタツチされる。
「foo」 EditGommand804及び 「bar」 EditGommand 805は、 Undoab I eEd i tC ommandの例である。
[0154] 1. UndoableEditGommandの実行
図 1 8 ( b) は、 UndoableEditGommandの実行を示す。 まず、 ユーザが編集 コマンドを使用して Document 705を編集すると仮定する。 第 1ステップ S 1では、 Undoab I eEd i tAcceptor 709が、 Document 705の D O Mツリーで ある UndoableEditSource 708にァタツチされる。 第 2ステップ S 2では、 ユーザにより発行されたコマンドに基づいて、 Document705が DOMの A P Iを用いて編集される。 第 3ステップ S 3では、 ミューテ一シヨンィベン 卜のリスナーが、 変更がなされたことを通知される。 すなわち、 このステツ プでは、 DOMツリーの全ての変更を監視するリスナーが編集操作を検知す る。 第 4ステップ S 4では、 UndoableEditが UndoManager 706のォブジェク トとして格納される。 第 5ステップ S 5では、 UndoableEditAcceptor 709 ^UndoableEditSource708からデタツチされる。 UndoableEditSource70 8は、 Document705自身であってもよい。
[0155] K. システムへの文書のロードに関する手順
上記のサブセクションでは、 システムの様々なコンポ一ネント及びサブコ ンポ一ネントについて説明した。 以下、 これらのコンポーネントの使用に関 する方法論について説明する。 図 1 9 (a) は、 文書処理システムに文書が ロードされる様子の概要を示す。 それぞれのステップは、 図 24— 28にお いて、 特定の例に関連して詳述される。
[0156] 簡単には、 文書処理システムは、 文書に含まれるデータからなるバイナリ デ一タストリームから DOMを生成する。 ApexNode (エイペックスノード： 頂点ノード） 力 注目対象であり Zoneに属する文書の一部のために生成され る。 つづいて、 対応する Paneが同定される。 同定された Paneは、 ApexNode及 び物理的な画面表面から Zone及び Canvasを生成する。 Zoneは、 次に、 それぞ れのノードに Facetを生成し、 それらに必要とされる情報を提供する。 Canvas は、 DOMツリーから、 ノードをレンダリングするためのデータ構造を生成 する。
[0157] より詳細には、 文書はストレ一ジ 901からロードされる。 文書の DOM ツリー 902が生成される。 文書を保持するための、 対応する DocumentGonta i ner 903が生成される。 DocumentGonta iner 903は、 DocumentManager 9 04にアタッチされる。 DOMツリーは、 ルートノードと、 ときには複数の セカンダリノードを含む。
[0158] 一般に、 このような文書は、 テキスト及びグラフィクスの双方を含む。 し たがって、 DOMツリーは、 例えば、 X H TM Lサブツリーだけでなく SV Gサブツリーを有してもよい。 X H TM Lサブツリーは、 X H TM LのApexN ode905を有する。 同様に、 SVGサブツリーは、 S V Gの ApexNode 906 を有する。
[0159] ステップ 1では、 ApexNode 906力 画面の論理的なレイァゥトである Pan e907にアタッチされる。 ステップ 2では、 Pane907は、 PaneOwner (ぺ インオーナ一：ペインの所有者） 908である GoreGomponentに、 ApexNode 9 06のための ZoneFactoryを要求する。 ステップ 3では、 PaneOwner 908は 、 ZoneFactoryと、 ApexNode 906のための GanvasFactoryである Edi tl etとを 返す。
[0160] ステップ 4では、 Pane907力《Zone909を生成する。 Zone909は Pane 907にアタッチされる。 ステップ 5では、 Zone909がそれぞれのノード に対して Facetを生成し、 対応するノードにアタッチする。 ステップ 6では、 Pane 907力《Ganvas9 1 0を生成する。 Canvas 9 1 0は Pane 907にァタッ チされる。 Ganvas9 1 0には様々な Commandが含まれる。 ステップ 7では、 Ga nvas9 1 0が文書を画面にレンダリングするためのデータ構造を構築する。 X H TM Lの場合、 これはボックスツリー構造を含む。
[0161] 1. Zoneの MV C
図 1 9 (b) は、 MVCパラダイムを用いて Zoneの構成の概要を示す。 こ の場合、 Zone及び Facetは文書に関連した入力であるから、 モデル （M) は Zo ne及び Facetを含む。 Canvasと、 文書を画面にレンダリングするためのデータ 構造体は、 ユーザが画面上に見る出力であるから、 ビュー （V) は Canvas及 びデータ構造体に対応する。 Commandは、 文書とその様々な関係に対して制御 操作を実行するので、 コントロール （C) は Canvasに含まれる Go國 andを含む
[0162] し 文書の表現
図 20を用いて、 文書及びその様々な表現の例について以下に説明する。 この例で使用される文書は、 テキストと画像の双方を含む。 テキストは、 X H TM Lを用いて表され、 画像は、 SVGを用いて表される。 図 20は、 文 書のコンポーネント及び対応するォブジェク 卜の関係の MVC表現を詳細に 示す。 この例において、 Document 1 00 1は、 Document 1 00 1を保持する D ocumentContainer 1 002にアタッチされる。 文書は DO Mツリー 1 003 により表現される。 DOMツリーは、 ApexNode 1 004を含む。
[0163] ApexNodeは、 黒丸で表される。 頂点でないノードは、 白丸で表される。 ノ ードを編集するために用いられる Facetは、 三角形で表され、 対応するノード にアタッチされる。 文書がテキストと画像を有するので、 この文書の DOM ツリーは、 X H TM L部分と S VG部分を含む。 ApexNode 1 004は、 X H TM Lサブツリーの最上のノードである。 これは、 文書の X H TM L部分の 物理的な表現のための最上 Paneである XHTMLPane 1 005にァタツチされる。 ApexNode 1 004は、 文書の D O Mツリーの一部である XHTMLZone 1 006に もァタツチされる。
[0164] Node 1 004に対応する Facetも、 XHTMLZone 1 006にアタッチされる。 X HTMLZone 1 006は、 XHTMLPane 1 005にアタッチされる。 XHTMLEditletは 、 文書の論理的な表現である XHTMLGanvas 1 007を生成する。 XHTMLGanvas 1 007は、 XHTMLPane 1 005にァタツチされる。 XHTMLGanvas 1 007は 、 Document 1 00 1の X H TM Lコンポ一ネン卜のための BoxTree 1 009を 生成する。 文書の X H TM L部分を保持し描画するために必要な様々な Go國 a nd 1 008も、 XHTMLGanvas 1 007に追加される。
[0165] 同様に、 文書の SVGサブツリーの ApexNode 1 0 1 0は、 文書の SVGコ ンポ一ネントを表現する Document 1 00 1の D O Mツリーの一部である SVGZo ne 1 0 1 1にアタッチされる。 ApexNode 1 0 1 0は、 文書の SVG部分の物 理的な表現の最上の Paneである SVGPane 1 0 1 3にアタッチされる。 文書の S VG部分の論理的な表現を表す SVGGanvas 1 0 1 2は、 SVGEditletにより生成 され、 SVGPane 1 0 1 3にアタッチされる。 画面上に文書の S V G部分をレン ダリングするためのデータ構造及びコマンドは、 SVGGanvasにァタツチされる 。 例えば、 このデータ構造は、 図示されるように、 円、 線、 長方形などを含 んでもよい。
[0166] 図 20に関連して説明された文書例の表現の一部について、 図 21 (a) に関連して、 前述した MVCパラダイムを用いて更に説明する。 図 21 (a ) は、 文書 1 001の X H TM Lコンポーネントにおける MVの関係を簡略 化して示す。 モデルは、 Document 1 001の X H TM Lコンポーネントのた めの XHTMLZonel 1 01である。 XHTMLZoneのツリーには、 いくつかの Node及 びそれらに対応する Facetが含まれる。 対応する XHTMLZone及び Paneは、 MV Cパラダイムのモデル （M) 部分の一部である。 MVCパラダイムのビュー (V) 部分は、 Document 1 001の X H TM Lコンポーネントの、 対応する X HTMLCanvas 1 1 02及び BoxTreeである。 文書の XHTML部分は、 Canvasと 、 それに含まれる Go國 andを使用して画面に描写される。 キーボードやマウス 入力などのイベントは、 図示されるように、 逆方向へ進む。
[0167] SourcePaneは、 更なる機能、 すなわち、 D O Mの保有者としての役割を有 する。 図 21 (b) は、 図 21 (a) に示した Document"! 001のコンポ一 ネントに対するポキヤブラリコネクションを提供する。 DOMホルダーとし て機能する SourcePane 1 1 03は、 文書のソース D OMツリーを含む。 Gonne ctorTreeは、 GonnectorFactoryにより生成され、 デスティネ一シヨン DOM の保有者としても機能する DestinationPane 1 1 05を生成する。 Destinatio nPane 1 1 05は、 XHTMLDestinationGanvas 1 1 06としてボックスツリーの 形式でレイァゥ卜される。
[0168] M. プラグインサブシステム、 ポキヤブラリコネクション、 及びコネクタの 関係
図 22 (a) - (c) は、 それぞれ、 プラグインサブシステム、 ポキヤブ ラリコネクション、 及び Connectorに関連する更なる詳細を示す。 プラグイン サブシステムは、 文書処理システムに機能を追加又は交換するために用いら れる。 プラグインサブシステムは、 ServiceBroker 1 041を含む。 ServiceB roker 1 041にァタツチされる ZoneFactoryService 1 201は、 文書の一部 に対する Zoneを生成する。 EditletService 1 202も、 ServiceBroker 1 04 1にアタッチされる。 EditletService 1 202は、 Zone中の Nodeに対応する G anvasを生成する。
[0169] ZoneFactoryの例は、 XHTMLZone及び SVGZoneをそれぞれ生成する XHTMLZoneF actory 1 21 1及び SVGZoneFactory 1 21 2である。 文書例に関連して前述 したように、 文書のテキストコンポーネントは、 XHTMLZoneを生成することに より表現されてもよいし、 画像は SVGZoneを用いて表現されてもよい。 Editle tServiceの例は、 XHTMLEditlet 1 221及び SVGEditlet 1 222を含む。
[0170] 図 22 (b) は、 ポキヤブラリコネクションに関連する更なる詳細を示す 。 ポキヤブラリコネクションは、 前述したように、 文書処理システムの重要 な特徴であり、 2つの異なる方法で文書の整合のとれた表現及び表示を可能 とする。 GonnectorFactory303を保持する VGManager302は、 ポキヤブラ リコネクションサブシステムの一部である。 GonnectorFactory303は、 文 書の Connector 304を生成する。 前述したように、 Connectorは、 ソース D OM中のノードを監視し、 2つの表現の間の整合性を維持するために、 デス ティネ一シヨン DOM中のノ一ドを修正する。
[0171] Temp late 31 7は、 いくつかのノードの変換ルールを表す。 ポキヤブラリ コネクション記述子 （VCD) ファイルは、 特定のパス又はルールを満たす 要素又は要素の集合を他の要素に変換するいくつかのルールを表す Template のリストである。 Temp late 31 7及び GommandTemplate 31 8は、 全て VGMana ger302にアタッチされる。 VGManagerは、 V C Dファイル中の全てのセク シヨンを管理するオブジェク トである。 1つの VCDファイルに対して、 1 つの VGManagerォブジヱク 卜が生成される。
[0172] 図 22 (c) は、 Connectorに関連する更なる詳細を提供する。 GonnectorF actory 303 (i ソ一ス文書から Connector ¾：生成する。 ConnectorFactory 3 03は、 Vocabulary, Template, 及び ElementTemplateにアタッチされ、 それ ぞれ、 Vocabu I aryConnector TemplateConnector El ementGonnectorを生成 ずる。
[0173] VGManager 302は、 ConnectorFactory 303を保持する。 Vocabularyを生 成するために、 対応する VCDファイルが読み込まれる。 こうして、 Connect orFactory 303力《生成される。 この GonnectorFactory 303は、 Zoneを生成 する ZoneFactory及び Canvasを生成する Editletに関連する。
[0174] つづいて、 ターゲットポキヤブラリの EditletServiceが、 VGGanvasを生成 する。 VGGanvasも、 ソース D OMツリー又は Zoneにおける ApexNodeの Connect orを生成する。 必要に応じて、 子の Connectorが再帰的に生成される。 Gonnec torTreeは、 V C Dファイル中のテンプレー卜の集合により生成される。
[0175] テンプレートは、 マークアップ言語の要素を他の要素に変換するためのル —ルの集合である。 例えば、 各テンプレートは、 ソース DOMツリー又は Zon eにマッチされる。 適切にマッチした場合には、 頂点 Connectorが生成される 。 例えば、 テンプレート 「A/*/D」 は、 間にどんなノードがあるかに関係なく 、 ノード Aで始まりノード Dで終わる全ての枝に合致する。 同様に、 「〃B」 は、 ルートからの全ての 「B」 ノードに一致する。
[0176] N. GonnectorTreeに関係する VCDファイルの例
特定の文書と関係する処理を説明する例を続ける。 ドキュメントタイ トル のある 「MySampleXML」 というタイ トルの文書が文書処理システムにロードさ れる。 図 23は、 「MySampleXML」 ファイルのための、 VGManager及び Connect orFactoryTreeを用いた V C Dスクリプ卜の例を示す。 スクリプトファイル中 のポキヤブラリセクシヨン、 テンプレートセクションと、 VGManagerにおける 対応するコンポーネントが示される。 タグ 「vcd:vocabulary」 において、 属 性 「match」 は 「sample: rootj 、 「label」 は 「MySampl eXMLj 、 「calト temp latej は 「sample templatej となってしゝる。
[0177] この例では、 Vocabularyは、 「MySampl eXML」 の VGManagerにおいて 「sampl e: root j として頂点要素を含む。 対応する U Iラベルは、 「MySampl eXMLj で ある。 テンプレートセクションにおいて、 タグは 「vcd: templatej であり、 ¾ Hij (i 「sample: templatej でめる。
[0178] O. ファイルがシステムにロードされる方法の詳細な例
図 24— 28は、 文書 「MySampleXML」 のロードについての詳細な記述を示 す。 図 24 (a) に示されるステップ 1では、 文書がストレ一ジ 1 405力、 らロードされる。 DOMServiceは、 D OMツリー及び DocumentManager 1 406 と対 <、する DocumentGontaineM 401を生成する。 DocumentGontaineM 4 01は、 DocumentManager 1 406にアタッチされる。 文書は、 XHTML及 び MySampleXMLのサブツリーを含む。 X H T M Lの ApexNode 1 403は、 タグ rxhtml :htmlj が付された X H T M Lの最上のノードである。 「MySampleXML 」 の ApexNode 1 404は、 タグ 「sample: rootj が付された 「MySampl eXMLj の最上ノードである。
[0179] 図 24 (b) に示されるステップ 2では、 RootPaneが文書の XHTMLZone、 Fa cet、 及び Canvasを生成する。 Panel 407、 XHTMLZone 1 408、 XHTMLCanv as 1 409、 及び BoxTree 1 41 0が、 ApexNode 1 403に対応して生成され る。
[0180] 図 24 (c) に示されるステップ 3では、 XHTMLZoneが知らないタグ 「samp le:root」 を発見し、 XHTMLGanvasの領域から SubPaneを生成する。
[0181] 図 25に示されるステップ 4では、 SubPaneが 「sample: rootj を扱うこと ができ、 適切な Zoneを生成可能な ZoneFactoryを得る。 この ZoneFactoryは、 Z oneFactoryを実行可能な Vocabulary内にある。 それは、 「MySampl eXML」 の Vo cabu I arySect i onの内容を含む。
[0182] 図 26に示されるステップ 5では、 「MySampleXML」 に対応する Vocabulary 力《DefaiHtZone 1 601を生成する。 対応する Editletが生成され、 対応する G anvasを生成するために SubPane 1 501が提供される。 Editletは、 VGGanvas ¾:生成する。 そして、 それは TemplateSection¾rP乎 、。 GonnectorFactoryTree も含まれてし λる。 GonnectorFactoryTreeは、 GonnectorTreeとなる全ての Gonn ector¾r生成する。
[0183] 図 27に示されるステップ 6では、 各 Connectorがデスティネーション DO Mオブジェク トを生成する。 コネクタのうちのいくつかは xpath情報を含んで いる。 xpath情報は、 変更/修正を監視する必要のあるソース DO Mツリーの 部分集合を決定するために使用される 1以上の xpath表現を含む。 [0184] 図 28に示されるステップ 7では、 ポキヤブラリは、 ソース DOMのペイ ンからデスティネ一シヨン D O Mッリ一の Dest i nat i onPaneを作成する。 これ は、 SourcePaneに基づいてなされる。 デスティネーションツリーの ApexNode は、 DestinationPane及び对 j心する Zoneにアタッチされる。 Dest i nat ionPane は、 DestinationGanvasを生成し、 文書をデスティネーションのフォーマット でレンダリングするためのデータ構造及びコマンドを構築する、 自身の Editl etを提供される。
[0185] 図 29 (a) は、 対応するソースノードを持たず、 デスティネーションッ リーにのみ存在するノード上でィベン卜が発生したときのフローを示す。 マ ウスイベント、 キーボードイベントなど、 Canvasが取得したイベントは、 デ スティネーシヨンッリ一を通過して、 E I ementTemp I ateConnectorに伝達され る。 ElementTemplateGonnectorは対応するソースノードを持たないので、 伝 達されたィベントはソースノードに対する編集操作ではない。 ElementTempla teGonnectorは、 伝達され rニイベン卜が GommandTemplateに記述されたコマン ドに合致すれば、 それに対応する Actionを実行する。 合致するコマンドがな ければ、 El ementTemp I ateConnectorは、 伝達されたィベン卜を無視する。
[0186] 図 29 (b) は、 TextOfGonnectorによりソースノードに対応づけられてい るデスティネーションツリーのノード上でィベン卜が発生したときのフロー を示す。 TextOf Connectorは、 ソース D OMツリーの X P a t hで指定された ノードからテキストノードを取得して、 デスティネーション DOMツリーの ノードにマッピングする。 マウスイベント、 キ一ポ一ドイベントなど、 Ganva sが取得したイベントは、 デスティネーションツリーを通過して、 TextOfGonn ectorに伝達される。 TextOf Connectorは、 伝達されたイベントを、 対応する ソースノードの編集コマンドにマッピングし、 Queuel 053に積む。 編集コ マンドは、 Facetを介して実行される DOMの A P Iコールの集合である。 キ ユーに積まれたコマンドが実行されると、 ソースノードが編集される。 ソ一 スノードが編集されると、 ミューテ一シヨンイベントが発行され、 リスナー として登録された TextOfGonnectorにソースノードの変更が通知される。 Text OfGonnectorは、 ソースノードの変更を、 対応するデスティネーションノード に反映させるように、 デスティネーションツリーを再構築する。 このとき、 T extOf Connectorを含むテンプレートに、 「for eachj や 「for loopj などの 制御文が含まれている場合、 GonnectorFactoryがこの制御文を再評価し、 Tex tOfGonnectorを再構築した後、 デスティネーションツリーが再構築される。
[0187] (実施の形態）
実施の形態では、 XM L文書を処理するための定義ファイル （VCD) を デバッグするための機能について説明する。
[0188] 図 30は、 本実施の形態の文書処理装置の構成を示す。 本実施の形態の文 書処理装置 1 00は、 図 1に示した前提技術の文書処理装置 20の構成に加 えて、 デバッグの対象となる VCDファイルと、 その VCDの適用対象とな る XM L文書を取得する取得部 29と、 取得された V CDファイルのデバッ グ環境を提供するデバッガ 70とを更に備える。 デバッガ 70は、 画面表示 咅 157 1、 ソースビュー表示部 72、 〇0ビュ_表示部73、 デステイネ一 シヨンビュー表示部 74、 プロパティビュー表示部 75、 ブレークポイント 設定部 76、 実行制御部 77、 整形部 78、 及びポップアップウィンドウ表 示部 79を含む。
[0189] 図 31は、 デバッガ 70の機能を説明するためのサンプル文書を示す。 こ の XML文書は、 「hw:document」 要素の子要素として複数の 「hw:message」 要素を有しており、 「hw:message」 要素は 「Hel lo Wor Id！」 、 「Hello xml W orld！」 などの文字列をテキストノードとして有している。 この XML文書に は、 処理系として V CDファイル 「Hel loWorld2. xvcd」 が関連付けられてい る。
[0190] 図 32は、 図 31に示した X ML文書に関連付けられた V CDファイルを 示す。 V CDファイル ΓΗβΙ loWorld2. xvcdj によれば、 変数 「body_title」 に 2番目の要素 「hw:message」 のテキストノードが代入され、 それが XHT MLの 「h1」 要素として表示される。 また、 変数 「nodeToShow」 に 3番目の 要素 「hw:message」 が代入され、 その内容が表示される。 [0191] 図 33は、 デバッガが表示するデバッグ画面の例を示す。 デバッグ画面に は、 処理対象となるソース文書の内容を表示するソースビューと、 ソース文 書を処理するための VCDファイルの内容を表示する VCDビューと、 VC Dファイルによりソース文書を変換したデスティネーション文書の内容を表 示するデスティネーションビューと、 変数に代入された値などのプロパティ 情報を表示するプロパティビューと、 テンプレートゃ関数などの呼び出し履 歴を表示する履歴ビューが設けられる。
[0192] 実行制御部 77は、 ュ一ザからの指示にしたがって、 VCDファイルに記 述されたインストラクシヨンを VCュニット 80に実行させる。 画面表示部 7 1は、 実行制御部 77による実行状況を画面に表示する。 ソースビュー表 示部 72は、 ソースビューに現在変換処理の対象になつている行を識別可能 に表示し、 VCDビュー表示部 73は、 VCDビューに現在処理中の行を識 別可能に表示し、 デスティネーションビュー表示部 74は、 デスティネ一シ ヨンビューに変換された行を識別可能に表示し、 プロパティビュー表示部 7 5は、 プロパティビューに V CDファイル内で設定された変数、 プロパティ 、 又はユーザデータの内容を表示する。 図 33の例では、 ソースビューでは 何も選択されておらず、 VCDビューでは 「xvcd:user_data」 要素が選択さ れている。 これは、 VCユニット 80が 「xvcd:user_data」 要素を処理して いる時点で、 XM L文書ではどの要素も変換処理の対象となっていないこと を意味している。
[0193] VCDスクリプトは、 ノードごとの処理を 1ステップとして実行される。
実行制御部 77は、 V C Dスクリプ卜の実行をステップ単位で制御するため に、 ステップイン、 ステップアウト、 ステップオーバ一の 3つの機能を提供 する。
[0194] ステップイン機能は、 「選択されているノードの中」 に実行の流れを進め る。 これから実行する内容に子ノードがない場合には、 兄弟ノードに実行を 進める。 ステップ実行したとき、 VCDビューでは、 グロ一バルなスコープ を持つ要素 （グローバル変数、 ユーザーデータなど） 、 テンプレート要素 （ 「xvcd:vocabulary」 要素や 「xvcd:template」 要素など） の順に選択位置が 移動される。 選択位置の移動順は、 VCDスクリプト内の記述順序に依存し ない。 V CDスクリプト内で上から順番に選択されるのではなく、 グロ一バ ルなスコープを持つ要素が先に選択され、 そのあとでテンプレート要素が選 択される。
[0195] 図 34は、 「html」 要素まで V CDスクリプトの処理を進めた状態を示す 。 「html」 要素が選択されている状態でステップインを実行すると、 「html 」 要素の中に実行の流れが進む。 このときの画面を図 35に示す。 図 35に 示したデバッグ画面では、 デスティネーションビュー内にデスティネ一ショ ン DOMツリーが作成され、 「html」 要素が選択状態になっている。 これは 、 VCユニット 80がデスティネーション DOMツリーに 「html」 要素を作 成したことを意味する。 「html」 要素の中に実行の流れを 1ステップ進めた ので、 「head」 要素が選択されている。
[0196] ステップアウト機能は、 「選択されているノードを呼び出したノード」 ま で実行の流れを進める。 選択されているノードを呼び出したノードがない場 合は、 兄弟ノードに実行を進める。
[0197] 図 36は、 「title」 要素まで VCDスクリプトの処理を進めた状態を示す 。 「title」 要素が選択されている状態でステップアウトを実行すると、 「ti tlej 要素を呼び出した 「head」 要素の終了タグへ実行の流れが進む。 この状 態を図 37に示す。
[0198] ステップオーバー機能は、 「選択されているノードの呼び出しが終わった 直後」 まで実行の流れを進める。 これから実行する内容に子ノードがない場 合には、 兄弟ノードに実行を進みる。
[0199] 図 38は、 「body」 要素まで V CDスクリプトの処理を進めた状態を示す 。 「body」 要素の開始タグが選択されている状態でステップオーバーを実行 すると、 「body」 要素内の処理を全て終えて、 「body」 要素の終了タグまで 実行の流れが進む。 この状態を図 39に示す。
[0200] ユーザが 「開始」 をクリックすると、 実行制御部 77は、 VCDスクリブ トを V Cユニット 8 0に実行させる。 このとき、 ブレークポイントが設定さ れている場合は、 ブレークポイントが設定されている行で処理を一時停止さ せる。 V C Dスクリプトの処理が最後まで実行されると、 文書処理装置 2 0 に制御が移り、 X M L文書に V C Dファイルのスクリブトを適用させた結果 が表示される。 この状態を図 4 0に示す。
[0201 ] ブレークポイント設定部 7 6は、 実行制御部 7 7による V C Dスクリプト の実行を一時停止させるポイントを設定する。 ブレークポイントとは、 V C Dスクリプトの実行を途中で止める 「場所」 を指す。 実行制御部 7 7は、 ブ レークポイントが設定された 「場所」 において、 V C Dスクリプトの実行を 一時停止させる。
[0202] V C Dビュー表示部 7 3は、 V C Dビューにおいて、 ブレークポイントを 設定できる要素を、 設定できない要素とは異なる表示形式で表示する。 これ により、 ユーザはブレークポイントをどこに設定できるかを容易に把握する ことができる。 ユーザがブレークポイントをつけたい行の左端をダブルクリ ックすると、 ブレークポイント設定部 7 6は、 その行にブレークポイントを 設定する。 ブレークポイント設定部 7 6は、 ブレークポイントを設定した位 置にその旨を示すアイコンを表示する。 ブレークポイントは、 一時的に無効 化することができる。 実行制御部 7 7は、 有効なブレークポイントが設定さ れた行で実行を一時停止させる。
[0203] ブレークポイント設定部 7 6は、 ユーザからブレークポイントの一覧の表 示を要求されると、 設定されたブレークポイントの位置を、 V C Dファイル の名称と行番号で表示する。 このとき、 有効か無効かを合わせて表示する。 ブレークポイント設定部 7 6は、 ブレークポイントを設定するために V C D ファイル中の要素の検索を要求されると、 図 4 1に示した検索ダイアログ画 面を提示し、 検索する要素の指定を受け付ける。 ここで、 「xvcd : temp l ate」 などの要素の指定を受け付けると、 ブレークポイント設定部 7 6は、 その要 素を V C Dファイル中で検索し、 その要素の行にブレークポイントを設定す る。 ブレークポイント設定部 7 6は、 ブレークポイントを設定可能な要素の みを図 41に示した検索ダイアログ画面において提示する。 例えば、 「xvcd: xvcdj 要素はブレークポイントを設定できないので、 検索ダイアログ画面に 提示しない。
ブレークポイントは下記の要素ノードと、 テンプレートルール内のリテラ ル結果要素、 テキストノードに設定できる。
instruct i on： beep、 · i instruct i on : ca 11
nstruct ion: ： calト next、 ■ instruct ion: choose
nstruct ion:： co I or-chooser、 ■ instruct ion: command-exists
nstruct ion:： create_document、 ■ instruction:dialog
nstruct ion:： di rectory-chooser、 ■ i nstruct i on： f i I e-chooser nstruct ion:： font-fami ly-chooser ■ instruct ion: for-each
nstruct ion: if、 - instruction: load-document
nstruct ion: load-f ragment ■ instruct ion: message
nstruct ion:： message_box、 ■ instruct ion: post
nstruct ion: save_document、 ■ instruct ion: show-popup
nstruct ion: show_status_message、 ■ instruct ion: temp I ate-chooser nstruct ion:： throw, ■ instruct ion: tree-message
nstruct ion:： try、 · instruct ion: variable
xvcd: act ion. xvcd: apply- imports
xvcd： app I y-temp I ates、 ■ xvcd： app I y-vocabu lar ies
xvcd： attr i bute、 ■ xvcd： cal I -temp I ate
xvcd： choose, ■ xvcd： comb i ne
xvcd:comment ■ xvcd: copy
xvcd : copy-of、 ■ xvcd: copy-select ion
xvcd:delete、 xvcd： document-temp I ate
xvcd:element、 • xvcd:f i 11 er
xvcd: for—each ■ xvcd:get-cl ip
xvcd: if、 · xvcd: insert xvcd: message, ■ xvcd: move
xvcd: namespace, - xvcd： next-match
xvcd: number, ■ xvcd: otherwise
xvcd: param ■ xvcd： process i ng- i nstruct i on
xvcd: property ■ xvcd: resource-text
xvcd: set-attr i bute、 ■ xvcd： set-c I i p
xvcd: set-property - xvcd： set-text
xvcd: set_user_data、 ■ xvcd:spl it
xvcd: start-drag ■ xvcd： sur round-contents
xvcd: template, ■ xvcd: text
xvcd: text_of、 xvcd： unsur round-contents
xvcd: user-data ■ xvcd: value-of
xvcd: var iable ■ xvcd: vocabulary
xvcd: when
[0205] 整形部 78は、 画面表示部 7 1がプロパティビューに表示する変数値など がサブッリーである場合に、 サブッリーの階層構造を反映させた形式に整形 する。 例えば、 図 34に示したデバッグ画面のプロパティビューにおいて、 変数 「nodeToShow」 の値は、 「く hw:message>Hel lo Wor ld!<hw:message Hel lo Wor I d！ <hw： message>He 11 o Wor I d！ </hw： messageX/hw： messageX/hw： message >」 と 1行に表示されているが、 これをダブルクリックすると、 プロパテイビ ユー表示部 75は、 図 42に示すように、 変数の詳細を示すプロパティダイ ァログ画面を提示する。 このとき、 整形部 78は、 変数 「nodeToShow」 の値 であるサブツリーを、 図 42に示すように、 階層構造を認識可能な形式に整 形する。 これにより、 ユーザが容易にサブツリーの階層構造を把握すること ができる。
[0206] ポップアップウィンドウ表示部 79は、 ソースビュー、 VCDビュー、 デ ステイネ一シヨンビュー、 プロパティビュー、 履歴ビューにおいて、 1行が 画面の幅におさまらずにはみ出している行に、 ユーザがマウス力一ソルを合 わせると、 その行の全体を表示するポップアップウィンドウを提示する。 こ のとき、 その行の内容がサブツリーであった場合に、 整形部 7 8は、 サブッ リーを階層構造を反映させた形式に整形する。 これにより、 ユーザは、 画面 の幅におさまらない行を容易に把握することができる上に、 その行がサブッ リーであった場合に、 サブツリーの階層構造を容易に把握することができる
[0207] 以上、 本発明を実施の形態をもとに説明した。 この実施の形態は例示であ り、 それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可 能なこと、 またそうした変形例も本発明の範囲にあることは当業者に理解さ れるところである。
[0208] 実施の形態では、 X M L文書を処理する例について説明したが、 本実施の 形態の文書処理装置 1 0 0は、 他のマークァップ言語、 例えば、 S G M L、 H T M Lなどで記述された文書も同様に処理可能である。
産業上の利用可能性
[0209] 本発明は、 マークアップ言語により記述された文書を処理する文書処理装 置に利用可能である。

Claims

請求の範囲
[1 ] 所定のタグセットで記述された文書を、 別のタグセットで記述された文書 に変換して処理する方法を記述したスクリブトファイルの実行を制御する実 行制御部と、
前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するソースビュー表示部と、
前記スクリブトファイルの実行中に、 前記スクリブトファイルの内容を、 処理中の位置を識別可能に表示するスクリブトファイルビュー表示部と、 前記スクリプトファイルの実行中に、 変換先の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するデスティネーションビュー表示部 と、
前記実行制御部による前記スクリプトファイルの実行を一時的に停止させ るブレークポイントを設定するブレークポイント設定部と、 を備え、 前記ブレークポイント設定部は、 ブレークポイントを設定する要素の検索 要求を受け付け、 前記スクリプトファイルの中から指定された要素を検索し 、 検索された要素にブレークポイントを設定することを特徴とする文書処理 装置。
[2] 前記ブレークポイント設定部は、 検索する要素の指定を受け付けるときに
、 ブレークポイントを設定可能な要素のみを提示することを特徴とする請求 項 1に記載の文書処理装置。
[3] 所定のタグセットで記述された文書を、 別のタグセットで記述された文書 に変換して処理する方法を記述したスクリブトファイルの実行を制御する実 行制御部と、
前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するソースビュー表示部と、
前記スクリブトファイルの実行中に、 前記スクリブトファイルの内容を、 処理中の位置を識別可能に表示するスクリブトファイルビュー表示部と、 前記スクリプトファイルの実行中に、 変換先の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するデスティネーションビュー表示部 と、
前記スクリプトファイル中で設定された変数、 プロパティ、 又はユーザデ ータの内容を表示するプロパティビュー表示部と、
前記変数、 前記プロパティ、 又は前記ユーザデータの値が、 階層構造を有 するデータであった場合、 前記プロパティビュー表示部がそのデータを表示 する際に、 そのデータを階層構造を反映させた形式に整形する整形部と、 を備えることを特徴とする文書処理装置。
[4] 所定のタグセットで記述された文書を、 別のタグセットで記述された文書 に変換して処理する方法を記述したスクリブトファイルの実行を制御する実 行制御部と、
前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するソースビュー表示部と、
前記スクリブトファイルの実行中に、 前記スクリブトファイルの内容を、 処理中の位置を識別可能に表示するスクリブトファイルビュー表示部と、 前記スクリプトファイルの実行中に、 変換先の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するデスティネーションビュー表示部 と、
前記ソースビュー表示部、 前記スクリプトファイルビュー表示部、 又は前 記デスティネーシヨンビュ一表示部が表示した内容のうち、 画面幅におさま らない行をポップアップ表示するポップアップ表示部と、
前記ポップアップ表示部が表示する内容が、 階層構造を有するデータであ つた場合、 そのデータを階層構造を反映させた形式に整形する整形部と、 を備えることを特徴とする文書処理装置。
[5] 所定のタグセットで記述された文書を、 別のタグセットで記述された文書 に変換して処理する方法を記述したスクリブトファイルの実行を制御するス テツプと、
前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するステップと、 前記スクリブトファイルの実行中に、 前記スクリブトファイルの内容を、 処理中の位置を識別可能に表示するステップと、
前記スクリプトファイルの実行中に、 変換先の前記文書の内容を、 処理対 象となっている要素を識別可能に表示するステップと、
前記実行を制御するステップによる前記スクリブトファイルの実行を一時 的に停止させるブレークポイントを設定するステップと、 を備え、
前記ブレークポイントを設定するステップは、 ブレークポイントを設定す る要素の検索要求を受け付け、 前記スクリプトファイルの中から指定された 要素を検索し、 検索された要素にブレークポイントを設定することを特徴と する文書処理方法。
所定のタグセッ卜で記述された文書を、 別のタグセッ卜で記述された文書 に変換して処理する方法を記述したスクリブトファイルの実行を制御する機 能と、
前記スクリプトファイルの実行中に、 変換元の前記文書の内容を、 処理対 象となっている要素を識別可能に表示する機能と、
前記スクリブトファイルの実行中に、 前記スクリブトファイルの内容を、 処理中の位置を識別可能に表示する機能と、
前記スクリプトファイルの実行中に、 変換先の前記文書の内容を、 処理対 象となっている要素を識別可能に表示する機能と、
前記実行を制御する機能による前記スクリプトファイルの実行を一時的に 停止させるブレークポイントを設定する機能と、 をコンピュータに実現させ 前記ブレークポイントを設定する機能は、 ブレークポイントを設定する要 素の検索要求を受け付け、 前記スクリプトファイルの中から指定された要素 を検索し、 検索された要素にブレークポイントを設定することを特徴とする プログラム。
PCT/JP2007/000821 2006-07-31 2007-07-31 Dispositif de traitement de documents et procédé de traitement de documents WO2008015789A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008527657A JPWO2008015789A1 (ja) 2006-07-31 2007-07-31 文書処理装置及び文書処理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006-209321 2006-07-31
JP2006209321 2006-07-31

Publications (1)

Publication Number Publication Date
WO2008015789A1 true WO2008015789A1 (fr) 2008-02-07

Family

ID=38996977

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/000821 WO2008015789A1 (fr) 2006-07-31 2007-07-31 Dispositif de traitement de documents et procédé de traitement de documents

Country Status (2)

Country Link
JP (1) JPWO2008015789A1 (ja)
WO (1) WO2008015789A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110471993A (zh) * 2019-07-05 2019-11-19 武楚荷 一种事件的关联方法、装置以及存储装置
CN116151191A (zh) * 2023-04-18 2023-05-23 武汉精臣智慧标识科技有限公司 一种数据渲染方法、系统、电子设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"<Oxygen/> User Manual", 2006 NEN 2 GATSU, SYNCRO SOFT LTD., 27 September 2007 (2007-09-27), XP003020867, Retrieved from the Internet <URL:http://www.web.archive.org/web/20060221022721> *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110471993A (zh) * 2019-07-05 2019-11-19 武楚荷 一种事件的关联方法、装置以及存储装置
CN116151191A (zh) * 2023-04-18 2023-05-23 武汉精臣智慧标识科技有限公司 一种数据渲染方法、系统、电子设备及存储介质
CN116151191B (zh) * 2023-04-18 2023-06-16 武汉精臣智慧标识科技有限公司 一种数据渲染方法、系统、电子设备及存储介质

Also Published As

Publication number Publication date
JPWO2008015789A1 (ja) 2009-12-17

Similar Documents

Publication Publication Date Title
JP5020075B2 (ja) 文書処理装置
WO2006051905A1 (ja) データ処理装置およびデータ処理方法
WO2007034858A1 (ja) データ管理装置、データ編集装置、データ閲覧装置、データ管理方法、データ編集方法およびデータ閲覧方法
WO2006051870A1 (ja) データ処理装置、文書処理装置及び文書処理方法
WO2006051715A1 (ja) 文書処理装置及び文書処理方法
WO2006051961A1 (ja) データ処理装置およびデータ処理方法
JPWO2006051975A1 (ja) 文書処理装置
WO2006046666A1 (ja) 文書処理装置および文書処理方法
JP4521408B2 (ja) 文書処理装置及び文書処理方法
WO2007105364A1 (ja) 文書処理装置及び文書処理方法
WO2006051960A1 (ja) 文書処理装置及び文書処理方法
WO2006051954A1 (ja) 文書処理装置及び文書処理方法
JPWO2007007529A1 (ja) 文書処理装置および文書処理モジュール
WO2006051904A1 (ja) データ処理装置およびデータ処理方法
WO2007032460A1 (ja) データ処理装置
JPWO2006046668A1 (ja) 文書処理装置および文書処理方法
WO2006051959A1 (ja) 文書処理装置及び文書処理方法
WO2006051712A1 (ja) 文書処理装置及び文書処理方法
WO2006051716A1 (ja) 文書処理装置及び文書処理方法
WO2006051955A1 (ja) サーバ装置及び名前空間発行方法
WO2008015789A1 (fr) Dispositif de traitement de documents et procédé de traitement de documents
JPWO2006051972A1 (ja) データ処理装置、文書処理装置および文書処理方法
WO2006051956A1 (ja) サーバ装置及び検索方法
WO2006051717A1 (ja) 文書処理装置及び文書処理方法
WO2006051868A1 (ja) 文書処理装置及び文書処理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07827781

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2008527657

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07827781

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载