[go: up one dir, main page]

WO2007081017A1 - 文書処理装置 - Google Patents

文書処理装置 Download PDF

Info

Publication number
WO2007081017A1
WO2007081017A1 PCT/JP2007/050448 JP2007050448W WO2007081017A1 WO 2007081017 A1 WO2007081017 A1 WO 2007081017A1 JP 2007050448 W JP2007050448 W JP 2007050448W WO 2007081017 A1 WO2007081017 A1 WO 2007081017A1
Authority
WO
WIPO (PCT)
Prior art keywords
document
data
file
database system
structured
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2007/050448
Other languages
English (en)
French (fr)
Inventor
Katsuhiro Matsuka
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
JustSystems Corp
Original Assignee
JustSystems Corp
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 Corp filed Critical JustSystems Corp
Priority to JP2007553980A priority Critical patent/JPWO2007081017A1/ja
Priority to US12/160,709 priority patent/US20100169333A1/en
Publication of WO2007081017A1 publication Critical patent/WO2007081017A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/83—Querying
    • G06F16/835—Query processing

Definitions

  • the present invention relates to a data processing technique, and more particularly to a document processing apparatus that processes a document structured in a markup language, and a data processing system that can use the document processing apparatus.
  • W3C has established XML schemas that serve as system infrastructure such as XHTML, SVG, SOAP, WSDL ⁇ RDF, and X—Query. Promote standardization of XML schemas for practical data such as XML and Government XML!
  • Patent Document 1 Japanese Patent Laid-Open No. 2001-290804
  • This document processing apparatus is a document processing apparatus for processing a document structured in a markup language, and when embedding data held in a database system in the document, a query statement corresponding to the database system is provided.
  • a query generation unit for generating the database system, and a view for generating a view for displaying the result of the query statement in the form of data structured in the markup language. And a generation unit.
  • the query generation unit acquires and presents information indicating the structure of data structured in a markup language and stored in the database system.
  • the specification of data to be embedded in the document may be accepted from within, and a query statement for the received data may be generated.
  • the query generation unit acquires the correspondence relationship from the management server that holds the correspondence relationship of the same kind of data among the data structured in the markup language, and stores the correspondence relationship in the database system.
  • the correspondence may be presented in an identifiable manner.
  • the query generation unit is a query for acquiring data in the form of data structured in the markup language, stored in the database system, structured in the markup language. It may be possible to generate a sentence.
  • the data processing system includes a document processing device that processes a document structured in a markup language, and a database system that holds data usable for the document, and the document processing device is included in the database system.
  • a query generation unit that generates a query statement according to the database system when embedding the stored data in the document, and the database system power data structured by the markup language with the result of the query statement
  • a view generation unit that generates a view for displaying the result when acquired in the format.
  • the data processing system may further include a management server that manages a correspondence relationship between data held in the database system.
  • the database system may be a complex database system of an XML database and a relational database.
  • the document processing method includes a step of generating a query statement corresponding to the database system when embedding data held in the database system. And a step of generating a screen for displaying the result when the query result of the database system is obtained in the form of data structured by the markup language. And
  • 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 to be processed.
  • FIG. 3 is a diagram showing an example of mapping the XML document shown in FIG. 2 to a table described in HTML.
  • FIG. 4 (a) is a diagram showing an example of a definition file for mapping the XML document shown in FIG. 2 to the table shown in FIG.
  • FIG. 4 (b) is a diagram showing an example of a definition file for mapping the XML document shown in FIG. 2 to the table shown in FIG.
  • FIG. 5 is a diagram showing an example of a screen displayed by mapping the XML document described in the grade management vocabulary shown in FIG. 2 to HTML according to the correspondence shown in FIG.
  • FIG. 6 is a diagram showing an example of a graphical user interface presented to the user by the definition file generation unit 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 is a schematic diagram for explaining a definition file generation process in the embodiment.
  • FIG. 12 is a diagram showing a schema file in the present embodiment.
  • FIG. 13 is a diagram showing a source file corresponding to the schema file of FIG.
  • FIG. 14 is a diagram showing definition files generated based on the schema file of FIG. 12 and the source file of FIG.
  • FIG. 15 shows a binding file editing screen.
  • Figure 16 Layout file based on the editing result of the nodding file in Figure 15 It is a figure which shows a collection screen.
  • FIG. 17 is a screen diagram when the destination file based on the edited result in FIG. 16 is displayed.
  • FIG. 18 is a diagram showing another example of a binding file editing screen.
  • FIG. 19 is a diagram showing a layout file editing screen based on the editing result of the nodding file in FIG. 17.
  • FIG. 20 is a screen diagram when the destination file based on the editing result in FIG. 18 is displayed.
  • FIG. 21 is a diagram showing still another example of the binding file editing screen.
  • FIG. 22 is a diagram showing a layout file editing screen based on the editing result of the nodding file in FIG. 21.
  • FIG. 23 is a screen diagram when the destination file based on the editing result in FIG. 22 is displayed.
  • FIG. 24 is a diagram showing still another example of the binding file editing screen.
  • FIG. 25 is a diagram showing a layout file editing screen based on the editing result of the nodding file in FIG. 24.
  • FIG. 26 is a screen diagram when the destination file based on the editing result in FIG. 25 is displayed.
  • FIG. 27 is a schematic diagram for further explaining the definition file generation process.
  • FIG. 28 is a diagram showing a configuration of a data processing system according to the embodiment.
  • FIG. 29 is a diagram showing a process of creating an XMLDB linkage document application.
  • FIG. 30 is a diagram showing a process of using an XMLDB linked document application.
  • FIG. 1 shows the configuration of the document processing apparatus 20 according to the base technology.
  • the document processing apparatus 20 processes a structured document in which data in the document is classified into a plurality of components having a hierarchical structure.
  • an example of processing an XML document as an example of a structured document is used. I ’ll explain it.
  • the document processing apparatus 20 includes a main control unit 22, an editing unit 24, a DOM unit 30, a CSS unit 40, an HTML unit 50, an SVG unit 60, and a VC unit 80 which is an example of a conversion unit.
  • these configurations are the power realized by the CPU, memory, and programs loaded in the memory of any computer.
  • functional blocks realized by their cooperation are depicted. Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.
  • the main control unit 22 provides a framework for loading plug-ins and executing commands.
  • the editing unit 24 provides a framework for editing XML documents.
  • the document display and editing functions in the document processing device 20 are realized by plug-ins, and necessary plug-ins are loaded by the main control unit 22 or the editing unit 24 in accordance with the document type.
  • the main control unit 22 or the editing unit 24 refers to the name space of the XML document to be processed, determines whether the XML document is described by the misplaced library, and displays or displays corresponding to the missing library. Load the editing plug-in to display or edit.
  • the document processing device 20 has a display system and editing system plug-in for each vocabulary (tag set), such as an HTML unit 50 that displays and edits HTML documents and an SVG unit 60 that displays and edits SVG documents.
  • the HTML unit 50 is loaded when editing an HTML document
  • the SVG unit 60 is loaded when editing an S VG document.
  • both HTML unit 50 and SVG unit 60 are loaded.
  • the editing unit 24 accepts an editing instruction event via the user interface, notifies the appropriate plug-in of the event, and re-executes the event (redo) or cancels execution (undo). Control the process.
  • the DOM unit 30 includes a DOM providing unit 32, a DOM generating unit 34, and an output unit 36, and a document object model (Document) defined to provide an access method when an XML document is handled as data.
  • DOM Document object model
  • the DOM provider 32 is a DOM implementation that satisfies the interface defined in the editing unit 24.
  • the DOM generator 34 also generates a DOM tree with XML document capabilities. As will be described later, when XML document power to be processed is mapped to another library by VC unit 80, the source tree corresponding to the mapping source XML document and the destination tree corresponding to the mapping destination XML document Is generated.
  • the output unit 36 outputs the DOM tree as an XML document at the end of editing, for example.
  • the CSS unit 40 includes a CSS analysis unit 42, a CSS providing unit 44, and a rendering unit 46, and provides a display function compliant with CSS.
  • the CSS analysis unit 42 has a function of a parser that analyzes the syntax of CSS.
  • the CSS provider 44 is an implementation of a CSS object and performs CSS cascade processing on the DOM tree.
  • the rendering unit 46 is a CSS rendering engine, and is used to display a document described in a vocabulary such as HTML that is laid out using CSS.
  • the HTML unit 50 displays or edits a document described in HTML.
  • the SVG unit 60 displays or edits documents written in SVG.
  • These display Z editing systems are implemented in the form of plug-ins, each of which displays a document (Canvas) 56, 66, control units (Editlet) 52, 62 for sending and receiving events including editing instructions, and editing units (Zone) 54, 64 for receiving edit commands and editing the DOM.
  • control unit 52 or 62 accepts a DOM tree editing command even when an external force is received
  • the editing unit 54 or 64 changes the DOM tree
  • the display unit 56 or 66 updates the display.
  • MVC Model-View-Controller
  • the display units 56 and 66 are changed to "View”, and the control units 52 and 62 are changed to "Controller”. Parts 54 and 64 and the entity of the DOM correspond to “Model”, respectively.
  • the document processing apparatus 20 of the base technology enables not only editing of an XML document in a tree display format but also editing according to the respective vocabulary.
  • the HTML unit 50 provides a user interface for editing an HTML document in a manner similar to a word processor
  • the SVG unit 60 provides a user interface for editing an SVG document in a manner similar to an image drawing tool.
  • the VC unit 80 includes a mapping unit 82, a definition file acquisition unit 84, and a definition file generation unit 86.
  • the mapping destination Provides a framework for displaying or editing documents with a display editing plug-in that supports the vocabulary. In this base technology, this function is called Vocabulary Connection (VC).
  • the definition file acquisition unit 84 acquires a script file in which the mapping definition is described. This definition file describes the correspondence (connection) between nodes for each node. At this time, whether to edit the element value or attribute value of each node may be specified. Also, an arithmetic expression using the element value or attribute value of the node may be described.
  • the mapping unit 82 refers to the script file acquired by the definition file acquisition unit 84, causes the DOM generation unit 34 to generate a destination tree, and manages the correspondence between the source tree and the destination tree.
  • the definition file generator 86 provides a graphical user interface for the user to generate a definition file.
  • the VC unit 80 monitors the connection between the source tree and the destination tree and receives an editing instruction via the user interface provided by the plug-in responsible for display, the VC unit 80 first applies the corresponding source tree. Change the node to be used. DOM When unit 30 issues a mutation event that the source tree has changed, VC unit 80 receives the mutation event and changes the source tree to synchronize the destination tree with the change in the source tree. Change the destination tree node corresponding to the specified node. A plug-in that displays / edits the destination tree, for example, the HTML unit 50, receives a mutation event indicating that the destination tree has been changed, and updates the display with reference to the changed destination tree. With this configuration, even a document written in a local vocabulary used by a small number of users can be displayed by converting it to another major vocabulary, and the editing environment can be reduced. Provided.
  • the DOM generation unit 34 When the document processing device 20 reads a document to be processed, the DOM generation unit 34 generates a DOM tree for the XML document power. Further, the main control unit 22 or the editing unit 24 refers to the name space to determine the vocabulary describing the document. If a plug-in corresponding to the vocabulary is installed in the document processing apparatus 20, the plug-in is loaded to display / edit the document. If the plug-in linker S is not installed, check whether the mapping definition file exists. If the definition file exists, the definition file acquisition unit 84 acquires the definition file, generates a destination tree according to the definition, and displays and edits the document by the plug-in corresponding to the mapping destination library.
  • the corresponding parts of the document are displayed and edited by plug-ins corresponding to each vocabulary as described later. If the definition file does not exist, the document source or tree structure is displayed and edited on the display screen.
  • FIG. 2 shows an example of an XML document to be processed.
  • This XML document is used to manage student grade data.
  • the component “score” that is the top node of the XML document has a plurality of component “students” provided for each student under the subordinate.
  • the component “student” has an attribute value “name” and child elements “national language”, “mathematics”, “science”, and “society”.
  • the attribute value “name” stores the name of the student.
  • the constituent elements “National language”, “Mathematics”, “Science” and “Society” store the results of national language, mathematics, science and society, respectively.
  • the student's country with the name "A” The grade of the word is “90”, the grade of mathematics is “50”, the grade of science is “75”, and the grade of society is “60”.
  • the vocabulary (tag set) used in this document will be referred to as the “score management vocabulary”.
  • the document processing apparatus 20 of the base technology does not have a plug-in that supports display Z 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 is used.
  • the user interface for creating a definition file by the user himself will be described later.
  • the description will proceed assuming that a definition file has already been prepared.
  • FIG. 3 shows an example of mapping the XML document shown in FIG. 2 to a table described in HTML.
  • the “Student” node in the Grade Management Library is associated with the row (“TR” node) of the table (“TA BLE” node) in HTML, and the attribute value “name” appears in the first column of each row.
  • the element value of the "National Language” node the element value of the "Mathematics” node in the third column, the element value of the "Science” node in the fourth column, and " Associate the element values of the “Society” node.
  • the XML document shown in FIG. 2 can be displayed in an HTML table format.
  • the sixth column specifies the formula for calculating the weighted average of national language, mathematics, science, and society, and displays the average score of the students. In this way, by making it possible to specify an arithmetic expression in the definition file, more flexible display is possible, and user convenience during editing can be improved. Note that the sixth column specifies that editing is not possible, so that only the average score cannot be edited individually. In this way, by making it possible to specify whether or not editing can be performed in the mapping definition, it is possible to prevent erroneous operations by the user.
  • FIGS. 4A and 4B show examples of definition files for mapping the XML document shown in FIG. 2 to the table shown in FIG.
  • This definition file is described in the script language defined for the definition file.
  • the definition file contains command definitions and display templates. The rate is described.
  • “add student” and “delete student” are defined as commands.
  • the operation of deleting the node “student” from the node is associated.
  • headings such as “name” and “national language” are displayed in the first line of the table, and the contents of the node “student” are displayed in the second and subsequent lines.
  • FIG. 5 shows an example of a screen displayed by mapping the XML document described in the grade management vocabulary shown in FIG. 2 to HTML according to the correspondence shown in FIG.
  • Table 90 shows, from the left, each student's name, national language grade, mathematics grade, science grade, social grade, and average score.
  • the user can edit the XML document on this screen. For example, if the value in the second row and third column is changed to “70”, the element value of the source corresponding to this node, that is, the math grade of the student “B” is changed to “70”.
  • the VC unit 80 changes the corresponding part of the destination tree that causes the destination tree to follow the source tree, and updates the display based on the changed destination tree. Therefore, also in the table on the screen, the mathematics score of the student “B” is changed to “70”, and the average score is changed to “55”.
  • the screen shown in FIG. 5 displays the “add student” and “delete student” command menus as defined in the definition file shown in FIGS. 4 (a) and 4 (b). Is displayed.
  • the node “Student” is added or deleted in the source tree.
  • Such a single-structure editing function may be provided to the user in the form of a command.
  • a command for adding or deleting a table row may be associated with an operation for adding or deleting the node “student”.
  • a command is provided to the user to embed other vocabulary. Also good.
  • new student grade data can be added in the form of hole filling.
  • the VC function makes it possible to edit a document described in the grade management vocabulary while using the display Z editing function of the HTML unit 50.
  • FIG. 6 shows an example of a graphical user interface that the definition file generator 86 presents to the user in order for the user to generate a definition file.
  • the XML document of the mapping source is displayed in a tree.
  • the area 92 on the right side of the screen shows the screen layout of the mapping destination XML document.
  • This screen layout can be edited by the HTML unit 50, and the user creates a screen layout for displaying a document in an area 92 on the right side of the screen.
  • mapping source XML document displayed in the area 91 on the left side of the screen into the HTML screen layout 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 “math”, which is a child element of the element “student”, into the first row and third column of Table 90 on the HTML screen, it will be between the “math” node and the “TD” node in the third column.
  • a connection is established.
  • Each node can be designated for editing.
  • An arithmetic expression can also be embedded in the display screen.
  • the definition file generation unit 86 generates a definition file describing the screen layout and the connection between the nodes.
  • FIG. 7 shows another example of the screen layout generated by the definition file generator 86.
  • a table 90 and a pie chart 93 are created on the screen for displaying the XML document described in the grade management vocabulary.
  • This pie chart 93 is described in SVG.
  • the document processing apparatus 20 of the base technology can process a compound document including a plurality of libraries in one XML document, and thus a table described in HTML as in this example. 90 and a pie chart 93 written in SVG can be displayed on one screen.
  • FIG. 8 shows an example of an XML document editing screen by the document processing apparatus 20.
  • one screen is divided into multiple parts, and the XML document to be processed is displayed in different display formats in each area.
  • the document 94 is displayed in the area 94
  • the tree structure of the document is displayed in the area 95
  • the table described in HTML shown in FIG. 5 is displayed in the area 96.
  • Documents can be edited on any of these screens.
  • the source tree is changed and the plug-in and source trees responsible for displaying each screen are displayed. Update the screen to reflect your changes.
  • the display section of the plug-in responsible for displaying each editing screen is registered, and either plug-in or VC unit 80 is registered.
  • the source tree is changed by, all the display units displaying the edit screen receive the issued mutation event and update the screen.
  • the VC unit 80 changes the destination tree following the change of the source tree, and then refers to the changed destination tree.
  • the display unit updates the screen.
  • the source display plug-in and the tree display plug-in directly refer to the source tree without using the destination tree. And display.
  • the source display plug-in and the tree display plug-in update the screen with reference to the changed source tree, and take charge of the screen in area 96! /
  • the HTML unit 50 updates the screen by referring to the changed destination tree following the change of the source tree.
  • the source display and the tree display can also be realized by using the VC function.
  • the source and tree structure is laid out in HTML, and an XML document is pinned on the HTML. And may be displayed by the HTML unit 50.
  • three destination trees are generated: source format, tree format, and tabular format.
  • VC Unit 80 changes the source tree, then changes each of the three destination trees: source format, tree format, and tabular format. Refer to those destination trees and update the three screens.
  • the user can display and edit a document in a format that can be easily visually divided using the table 90 or the like while grasping the hierarchical structure of the document by the source display or the tree display.
  • the ability to divide a screen and display a screen in multiple display formats at the same time may display a screen in a single display format on a single screen, and the display format can be switched by a user instruction.
  • the main control unit 22 receives a display format switching request from the user, and instructs each plug-in to switch the display.
  • FIG. 9 shows another example of an XML document edited by the document processing device 20.
  • the XHTML document is embedded in the “foreignObject” tag of the SVG document, and moreover, the mathematical expression described in MathML is included in the XHTML document.
  • the editing unit 24 refers to the name space and distributes the drawing work to an appropriate display system.
  • the editing unit 24 first causes the SVG unit 60 to draw a rectangle, and then causes the HTML unit 50 to draw an XHTML document.
  • the MathML unit (not shown) is made to draw mathematical expressions. In this way, a compound document including a plurality of vocabularies is appropriately displayed.
  • Figure 10 shows the display results.
  • the displayed menu may be switched according to the position of the cursor (carriage). That is, when the cursor is in the area where the SVG document is displayed, the menu defined by the SVG unit 60 or the command defined in the definition file for mapping the SVG document is displayed.
  • the menu defined by the HTML unit 50 or the command defined in the definition file for mapping the XHTML document is displayed. Thereby, an appropriate user interface can be provided according to the editing position.
  • an appropriate plug-in or mapping definition file corresponding to a certain library is found in the compound document, the part described by the specified library may be displayed in the source display or the tree display. .
  • a tag of another vocabulary may be used.
  • This XML document is not valid, but if it is well-formed (welH rmed), it can be processed as a valid XML document.
  • the tag of another inserted library may be mapped by the definition file. For example, you can use tags such as “important” and “most important” in an XHTML document and highlight the parts enclosed by these tags, or sort them in order of importance. Moyo.
  • the plug-in or VC unit 80 responsible for the edited part changes the source tree. Mutation event listeners can be registered for each node in the source tree. Normally, the plug-in display or VC cut 80 corresponding to the vocabulary to which each node belongs is registered as a listener. Is done. When the source tree is changed, 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 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 a configuration that manages the layout of the screen, for example, a plug-in that is responsible for displaying the top node.
  • the HTML unit 50 first draws a part that it is in charge of and determines the size of the display area. Then, it notifies the configuration that manages the layout of the screen of the size of the display area after the change, and requests a layout update.
  • the configuration that manages the layout of the screen receives the notification and re-lays out the display area for each plug-in. In this way, the display of the edited part is updated appropriately, and the layout of the entire screen is updated.
  • FIG. 11 is a schematic diagram for explaining the definition file generation process in the present embodiment.
  • the data processing apparatus includes an XML document file to be edited (hereinafter referred to as “source file”) and a source file.
  • source file an XML document file to be edited
  • source file Get the schema file that defines the element structure of the file.
  • the schema file here is described according to specifications such as XML—Schema and DTD (Document Type Definition).
  • the definition file as a product is a file for generating a destination file having appropriate display layout information for editing the source file.
  • the destination file can be said to be a file of the destination tree described in the base technology.
  • the data processing device When there is a schema file, the data processing device generates a schema file force binding file.
  • the binding file is the destination Used to edit the display layout in a sill file. If there is no schema file, the data processor extracts the elements and their structure from the source file itself and generates a binding file. In this case, the data processing device extracts elements and their structures by extracting child elements from the root element of the source file by a tree traverse method.
  • the binding file allows you to redefine the rules for source file elements. For example, when generating a binding file from a source file, assume that element A in the source file has four child elements B. At this time, the rule that the number of child elements B that element A can have is up to 4 is described in the binding file. The user can redefine the rules for element A and child element B through the methods provided by the binding file. For example, the number of child elements B that element A can have may be defined as 1-10. Even if the binding of the schema file is generated, it may be possible to redefine the rules for such elements within the scope of the rules defined in the schema file!
  • the binding file also provides rules for elements and functions for defining them.
  • schema information indicating the element structure of the source file is acquired from the schema file.
  • the user can edit the binding file with the data processing apparatus.
  • the user can set the basic display layout of the destination file using the GUI (Graphical User Interface).
  • GUI Graphic User Interface
  • a layout file is generated by applying the display layout information defined in the nodding file to each element of the schema information.
  • the layout file is an HTML file showing the specific display layout of each element included in the schema file.
  • the layout file need not be limited to the type of structure document file that is structured by tags, but should be a file containing display layout information, such as a spreadsheet application or a presentation application.
  • the user can edit the display layout more precisely by editing the layout file itself.
  • the bar The basic setting of the display layout of the destination file is set by the inding file, and the detailed setting is made by the layout file.
  • An XSLT file for determining the data conversion format between the source file and the destination file is generated from the correspondence relationship between the elements shown in the binding file and the display area of the layout file. Finally, based on this XSLT file, a definition file indicating the correspondence between the source file corresponding to the binding file and the destination file corresponding to the layout file is generated.
  • FIG. 12 is a diagram showing a schema file in the present embodiment.
  • the schema file shown here describes the rules regarding the element structure to be followed by the source file shown in FIG. This schema file is described according to the XML-Schema!
  • the data type for the element named “customerList” is defined as “customerListType”.
  • the data type “customerListType” is defined on the next line as including the following four child elements: “listID”, “totalEstimateJ,“ totalNumber ”,“ customer ”in the namespace“ sfa ”.
  • the data type of the “customer” element is “customerType”, and its contents are also defined.
  • the number of “customer” elements is defined as zero or more.
  • Source files must be described according to the rules shown in the schema file. Since the schema file is a file that defines the data type and structure of each element included in the source file, it is easier to understand the rules regarding the structure between elements than the source file itself.
  • FIG. 13 shows a source file corresponding to the schema file of FIG.
  • listID In this source file, “listID”, “totalNumber”, “totalEstimate”, and “cusutomer” are defined as child elements of “customerList”. These elements also contain values. Three “cusutomer” elements are included.
  • FIG. 14 is a diagram showing a definition file generated based on the schema file of FIG. 12 and the source file of FIG. The figure shows a part of the definition file.
  • “rules for converting each element in the sfa file into a destination file in XHTML format are described.
  • the data processing apparatus in this embodiment has an intuitive user interface. This definition file can be generated easily.
  • FIG. 15 is a diagram showing a binding file editing screen.
  • the data processing apparatus displays an image of the binding file generated from the schema file in the predetermined format shown in FIG.
  • the area at the bottom of the figure hereinafter referred to as “property area”
  • each element shown in the schema file is displayed in a tree, and its data type is displayed in an editable manner.
  • the child element can be expanded and displayed by checking the check box attached to the element name. According to such an aspect, even when an enormous number of elements are defined in the schema file, the display target can be narrowed down to only the elements to be edited.
  • the data processing apparatus uniquely sets an ID for each element.
  • the element “listID” has the ID “L1”.
  • the ID is determined by combining the initial “L” of the element name with the serial number “1”.
  • the data processing apparatus uniquely sets a sample value for each element.
  • the riistlDj t element is set to “2005-G30182” t and the sample value.
  • An area for defining the display format of these elements (hereinafter “layout area”) is provided in the upper center of the figure.
  • the user can reflect in the layout file by arranging the ID of each element in the layout area.
  • the relationship between the layout area and the layout file will be described in detail in relation to FIG.
  • the display format is specified so that the element “customer” is displayed in a table format. This designation is reflected in the layout file shown in Figure 16 below.
  • FIG. 16 is a diagram showing a layout file editing screen based on the editing result of the binding file in FIG.
  • the child elements of the element "customer” are displayed in a table format.
  • the schema customer element “customerList / customer / name” This corresponds to the leftmost display area of the table shown in the layout file.
  • the display format at this time reflects the settings in the layout area of FIG.
  • the user can edit the layout file on this editing screen using WYSIWYG (What You See Is What You Get).
  • the display layout of each element shown in the schema file is saved as a layout file.
  • the data processing device generates an XSLT file from the correspondence between the schema file elements and the layout file elements, and further generates the definition file described in the base technology.
  • the user can change the display position of the element by drag and drop on the layout file editing screen.
  • the data processor For editing after the definition file has already been generated, the data processor must reflect the change in the correspondence between the elements in the schema file and the display position of the layout file in the definition file.
  • the data processor monitors the correspondence between the sample values in the layout file and the elements in the schema file. For this reason, even if the position of the element in the layout file is changed, the definition file can be updated according to the position of the sample value.
  • each display element included in the layout file is specified by a sample value. Therefore, when generating an XSLT file, the correspondence is redefined using the sample value in the layout file as a key.
  • FIG. 17 is a screen diagram when the destination file based on the editing result in FIG. 16 is displayed.
  • FIG. 16 shows a screen that displays the destination file. Since there are three “customer” elements in the source file, three “customer” elements are displayed according to the table format shown in FIG. The user can edit the source file data via the screen shown in FIG. This mechanism is the mechanism described as the “Bubbler Connection” in the base technology.
  • FIG. 18 is a diagram showing another example of the binding file editing screen.
  • FIG. 19 is a diagram showing a layout file editing screen based on the editing result of the binding file in FIG.
  • the child elements of the element “customer” are displayed in a list format according to the specification of the display format in FIG.
  • the layout file changes according to the designation of the display format in the binding file.
  • the element “customerList / customer / name” in the schema file corresponds to the top element of each list shown in the layout file.
  • the data processing device generates a definition file in which the correspondence between the elements of the schema file and the elements of the layout file is also explained in the base technology.
  • FIG. 20 is a screen diagram when the destination file based on the editing result in FIG. 19 is displayed.
  • FIG. 21 is a diagram showing still another example of the binding file editing screen.
  • count (N 1) is set by the editing operation from the user as a calculation formula for calculating the value of the element “totalNumber”. Since “N1” is the ID of the element “name”, the value of the element “totalNumber” is the number of the element “name” in the source file.
  • sum (El)” is set as a calculation formula for calculating the value of the element “totalEstimate”. Since “E1” is the ID of the element “estimate”, the value of the element “totalEstimate” is the total value of the values of the element “estimate” in the source file. In this way, on the editing screen of the binding file, each element can be handled in a simple input format by the ID value instead of the long element name.
  • FIG. 22 is a diagram showing a layout file editing screen based on the editing result of the binding file in FIG. Figure 22 is not different from Figure 16.
  • FIG. 23 is a screen diagram when the destination file based on the editing result in FIG. 22 is displayed.
  • FIG. 24 is a diagram showing still another example of the binding file editing screen.
  • the user can set the basic layout in the layout file by arranging IDs in the layout area.
  • the ID of each element is arranged in the layout area as an initial setting.
  • the array at this time may be an array reflecting the element structure in the schema file. For example, elements that have a parent-child or sibling relationship may be arranged so that their display positions are close. Further, when the element names are close, such as “totalNumber”, “Number”, and “subtotalNumber”, these elements may be arranged so that the display positions are close to each other. In this way, it is possible to save labor for layout creation rather than creating an array from the beginning, where the ID array is initialized.
  • FIG. 25 is a diagram showing a layout file editing screen based on the editing result of the binding file in FIG.
  • each element is displayed according to the editing contents of the layout area in FIG.
  • FIG. 26 is a screen diagram when the destination file based on the editing result in FIG. 25 is displayed.
  • FIG. 27 is also a schematic diagram for further explaining the definition file generation process.
  • supplementary information is added to the nodding file by user editing operations on the binding file. For example, defining and redefining rules for elements. Based on this binding file, an XSLT file may be generated instead of the force definition file that generates the definition file. In addition, even if an object for realizing data mapping between the source file and the destination file, such as a Java (registered trademark) object, is generated. Good.
  • FIG. 28 shows a configuration of a data processing system according to the embodiment.
  • the collaborative system power of the document processing device 20 described in the base technology and the database system 70 according to the embodiment Information that has been made into a component by the standardized XML schema and accumulated for many years in the company so far We will explain that this is an environment where it is possible to easily develop applications that can respond to more advanced computerization requirements by freely combining precious data resources. With the advent of this environment, it is possible to make quick and high-quality decisions in business, and the optimal service that meets the needs can be immediately provided even in a personal computing environment in a network environment. Explain that we can evolve into a new infrastructure.
  • the document processing device 20 is designed so that an application can be created by freely combining various types of XML libraries as XML objects, in view of standardization and componentization of information using XML. Yes. It allows you to get a highly integrated application that combines the information you want, as if you had the power to freely combine colors on the palette and draw a picture on the canvas.
  • the database system 70 has a hybrid configuration in which RDB resources and XMLDB resources stored in the database system 70 can be freely accessed from both SQL and X-Query, and can be input / output as data in any format. It has become.
  • the view generation unit analyzes the query result and generates data for displaying the query result semi-automatically therefrom.
  • the difference between the conventional system development and the development by the document processing apparatus 20 according to the present embodiment is that IT appropriately responds to important business changes that are not just the difference in system architecture and development procedure. Provide optimal solutions to themes such as whether to go.
  • the system realized by the document processing device 20 in response to a dynamic change in business structure realizes information integration at the client without forcing a change in the server configuration.
  • System development using the document processing device 20 and the database system 70 is centered on program development that uses the structural information of the XML data itself without building a fixed schema in the DB. This allows developers to simultaneously develop processing programs while evolving information structures. This method shows that it is possible to flexibly respond to various change requests after completion by shortening the development process during initial development.
  • the document processing apparatus 20 is a development method that freely and freely combines multiple XML schemas, the existing high-utility XML schemas can be used and the expansion required by the user can be monitored in a short period of time. It is possible to improve the system repeatedly. As a result, if development can be completed in a short period of time with very little man-hours, it will be repeated by force. By improving the system, we can provide a truly usable system that meets your needs.
  • the extracted information is dynamically combined according to the user's request in the document processing device 20, and the value can be freely converted into an information asset that is optimal for business in a multipurpose manner.
  • the document processing device 20 is an XML handling environment having a simple and powerful mechanism for seamlessly combining a plurality of XML libraries. It has functions to utilize various XML information stored in database system 70 and to integrate information of XML services with different locations on the Internet 'Intranet.
  • the database system 70 is a hybrid type XMLDB. This is an extension of the XML type field type in addition to the traditional relational database field types, and these types are defined in a single table and handled within the same transaction. Has become possible.
  • the RDB type table which has the conventional power, can be read out in the XML format.
  • the vocabulary management server 78 is a server process for managing and sharing semantic relationships between XML tags. You can also manage tags between different XML vocabularies.
  • the library management server 78 maintains the correspondence of the same kind of data among the XML tags attached to the XML type data stored in the database system 70. For example, the correspondence relationship that the attribute “name” of the component “student” of the grade management vocabulary shown in FIG. 2 and the tag “name” of another vocabulary are XML tags for storing “name” is retained. . This correspondence is used in a GUI provided by the query generation unit 74, as will be described later.
  • the query generation unit 74 is a standard GUI for interactively generating query statements for XMLDB and RDB.
  • the query generation unit 74 acquires and presents information indicating the structure of data structured in the markup language held in the database system 70, accepts designation of data to be embedded in the document from the presented data, Generate a query statement for the accepted data.
  • the query generation unit 74 uses the library management server 78.
  • the correspondence relationship between the XML tags is acquired from the database, and when the structure of the XML data held in the database system 70 is presented, the correspondence relationship is presented in an identifiable manner. Thereby, even if the user does not know the meaning of the tag in advance, the meaning relationship of the tag can be understood on the GUI provided by the query generation unit 74.
  • a GUI is provided that allows end users to obtain information without having to examine various XML schemas in XMLDB in advance. This makes it possible to manage and utilize XML data with different schemas without difficulty.
  • the view generation unit 72 analyzes the search result received from the database system 70 and automatically generates a view for display. As described in the base technology, the view generation unit 72 may generate a display view by automatically generating a definition file for displaying XML data acquired from the database system 70.
  • the structure of XML database query results may vary depending on the content of the query. This means that the system can handle only a fixed schema, and the system can make full use of the capabilities of the XML database! /.
  • the document processing apparatus 20 according to the present embodiment can automatically generate a view for an arbitrary schema, so that even if the schema changes in a fluid manner, data can be displayed appropriately. Can do.
  • the query generation unit 74 converts conventional field type data held in the database system 70, i.e., data not structured by the markup language, in the form of data structured by the markup language.
  • a query statement for acquisition can be generated. Therefore, the document processing apparatus 20 can acquire arbitrary data stored in the hybrid database system 70 in XML format according to an arbitrary schema, and can automatically generate a view.
  • the inquiry condition and inquiry result to the database system 70 are connected to the database system 70 by the database plug-in 76.
  • This middleware absorbs the differences in the lower database system 70 and secures the capabilities of the upper application.
  • FIG. 29 shows the creation process of the XMLDB cooperation document application.
  • the XMLDB linkage document application can be created by the document processing device 20.
  • Document processing device 20 can be used to create a bubbly component (HTML unit, SVG unit, etc.)
  • a bubbly component HTML unit, SVG unit, etc.
  • conditional expression is stored as a parameter value of a condition storage type library component pasted on the application.
  • a tag management function can be used as a mechanism for handling information in a more purpose-oriented manner. This makes it possible to create conditional statements with emphasis on the original meaning of information managed by tags without being aware of the differences in tag names between schemas. In addition, sharing such tag management definitions within the company makes it easier for the application design side to design conditions with little consideration.
  • a view generator 72 is prepared as a function for automatically visualizing such output results.
  • a view template can be used as a function for performing a more optimal expression specific to a business or purpose. This makes it possible to display the extracted data in a map format with “creation date” and “creator” as axes. How to express this query result
  • V is stored in the XML application.
  • the XML application generated in this way is registered in the document server, and the user can download and use it when necessary.
  • FIG. 30 shows a process of using the XMLDB linkage document application.
  • the client user activates the document processing device 20 of the client device, and selects the one corresponding to the list operation of the XML application.
  • RDBZXMLDB is accessed using the conditional expression stored in the vocabulary component. Compete in the latest query results If an expression format is specified, it is displayed in that format. If it is set, it is automatically visualized by the view generation unit 72 and displayed in the XML application.
  • the state where the query result is displayed can be saved as a “document” as a snapshot at that time.
  • the saved document is an XML document, and by accumulating in XMLDB, it is possible to realize a cycle of “creating data by reusing existing data”.
  • the expression method of query results stored as a document application can be freely changed on the user side.
  • By registering such changes in the document server again as an XML application it is possible to build a business application that reflects the user's intentions in a bottom-up manner as well as shortening the development period for similar business applications. Is possible.
  • the system realized by the document processing device 20 and the database system 70 is combined with various XML sources that are not limited to information integration at the client to speed up rich user-oriented applications. It is possible to provide It can also provide an environment in which users within the company can use the company's information assets to achieve collaboration that enhances competitiveness.
  • the infrastructure for optimal use of data resources within an enterprise will evolve into an XML application era that provides an infrastructure for users to optimally use information assets and application assets.
  • the present invention can be used for a document processing apparatus that processes a structured document.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Document Processing Apparatus (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　構造化されたデータを適切に処理する技術を提供する。 　文書処理装置２０が処理する文書に、データベースシステム７０に格納されたデータに関する条件式が含まれている場合、クエリ生成部７４は、その条件式からデータベースシステム７０に応じたクエリ文を生成する。データベースプラグイン７６は、生成されたクエリ文をデータベースシステム７０へ送信し、データベースシステム７０からクエリ結果を取得する。ビュー生成部７２は、取得したクエリ結果を表示するためのビューを生成する。文書処理装置２０は、生成されたビューを含む文書の表示画面を表示する。

Description

明 細 書
文書処理装置、文書処理方法、及びデータ処理システム
技術分野
[0001] 本発明は、データ処理技術に関し、特に、マークアップ言語により構造ィ匕された文 書を処理する文書処理装置、及びその文書処理装置を利用可能なデータ処理シス テムに関する。
背景技術
[0002] 近年、企業が扱うさまざまな情報を XMLで標準化する活動が急速に進展してきた 。 W3Cが XHTMLや SVG、 SOAPや WSDLゝ RDFや X— Queryのようなシステム のインフラとなる XMLスキーマを制定し、同時に業界団体と標準化団体が連携して、 XBRLや ebXMLゝ EDIXMLや UBLゝ Open Office XMLや Government XMLなど の実務データの XMLスキーマの標準化を推進して!/、る。
特許文献 1：特開 2001— 290804号公報
発明の開示
発明が解決しょうとする課題
[0003] このように情報の標準化と部品化が加速する一方で、これを効率的に企業価値に 転換するための「活用モデル」の登場が強く求められて！/ヽる。
課題を解決するための手段
[0004] 本発明のある態様は、文書処理装置に関する。この文書処理装置は、マークアップ 言語により構造ィ匕された文書を処理する文書処理装置であって、データベースシス テムに保持されたデータを前記文書に埋め込むときに、前記データベースシステム に応じたクエリ文を生成するクエリ生成部と、前記データベースシステム力 前記タエ リ文の結果を前記マークアップ言語により構造ィ匕されたデータの形式で取得したとき に、その結果を表示するためのビューを生成するビュー生成部と、を備えることを特 徴とする。
[0005] 前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語 により構造化されたデータの構造を示す情報を取得して提示し、提示したデータの 中から前記文書に埋め込むデータの指定を受け付け、受け付けたデータのクエリ文 を生成してもよい。
[0006] 前記クエリ生成部は、マークアップ言語により構造ィ匕されたデータのうち、同種のデ ータの対応関係を保持した管理サーバから、前記対応関係を取得し、前記データべ ースシステムに保持された、前記マークアップ言語により構造ィ匕されたデータの構造 を提示するときに、前記対応関係を識別可能に提示してもよい。
[0007] 前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語 により構造ィ匕されて 、な 、データを、マークアップ言語により構造ィ匕されたデータの 形式で取得するためのクエリ文を生成可能であってもよい。
[0008] 本発明の別の態様は、データ処理システムに関する。このデータ処理システムは、 マークアップ言語により構造化された文書を処理する文書処理装置と、前記文書に 利用可能なデータを保持するデータベースシステムと、を備え、前記文書処理装置 は、前記データベースシステムに保持されたデータを前記文書に埋め込むときに、 前記データベースシステムに応じたクエリ文を生成するクエリ生成部と、前記データ ベースシステム力 前記クエリ文の結果を前記マークアップ言語により構造ィ匕された データの形式で取得したときに、その結果を表示するためのビューを生成するビュー 生成部と、を備えることを特徴とする。
[0009] データ処理システムは、前記データベースシステムに保持されたデータ間の対応 関係を管理する管理サーバを更に備えてもよい。前記データベースシステムは、 XM Lデータベース及びリレーショナルデータベースの複合型データベースシステムであ つてもよい。
[0010] 本発明の更に別の態様は、文書処理方法に関する。この文書処理方法は、マーク アップ言語により構造化された文書を処理する文書処理装置力 データベースシス テムに保持されたデータを前記文書に埋め込むときに、前記データベースシステム に応じたクエリ文を生成するステップと、前記データベースシステム力 前記クエリ文 の結果を前記マークアップ言語により構造ィ匕されたデータの形式で取得したときに、 その結果を表示するための画面を生成するステップと、を備えることを特徴とする。
[0011] なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムな どの間で変換したものもまた、本発明の態様として有効である。
発明の効果
[0012] 本発明によれば、構造化されたデータを適切に処理する技術を提供することができ る。
図面の簡単な説明
[0013] [図 1]前提技術に係る文書処理装置の構成を示す図である。
[図 2]処理対象となる XML文書の例を示す図である。
[図 3]図 2に示した XML文書を HTMLで記述された表にマッピングする例を示す図 である。
[図 4(a)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイ ルの例を示す図である。
[図 4(b)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイ ルの例を示す図である。
[図 5]図 2に示した成績管理ボキヤブラリで記述された XML文書を、図 3に示した対 応により HTMLにマッピングして表示した画面の例を示す図である。
[図 6]ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示 するグラフィカルユーザインターフェースの例を示す図である。
[図 7]定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
[図 8]文書処理装置による XML文書の編集画面の一例を示す図である。
[図 9]文書処理装置により編集される XML文書の他の例を示す図である。
[図 10]図 9に示した文書を表示した画面の例を示す図である。
[図 11]本実施例における定義ファイル生成過程を説明するための模式図である。
[図 12]本実施例におけるスキーマファイルを示す図である。
[図 13]図 12のスキーマファイルに対応するソースファイルを示す図である。
[図 14]図 12のスキーマファイルと図 13のソースファイルに基づ!/、て生成される定義フ アイルを示す図である。
[図 15]バインディングファイルの編集画面を示す図である。
[図 16]図 15におけるノインデイングファイルの編集結果に基づくレイアウトファイル編 集画面を示す図である。
[図 17]図 16における編集結果に基づいたデスティネーションファイルを表示させたと きの画面図である。
[図 18]バインディングファイルの編集画面の別例を示す図である。
[図 19]図 17におけるノインデイングファイルの編集結果に基づくレイアウトファイル編 集画面を示す図である。
[図 20]図 18における編集結果に基づいたデスティネーションファイルを表示させたと きの画面図である。
[図 21]バインディングファイルの編集画面の更に別例を示す図である。
[図 22]図 21におけるノインデイングファイルの編集結果に基づくレイアウトファイル編 集画面を示す図である。
[図 23]図 22における編集結果に基づいたデスティネーションファイルを表示させたと きの画面図である。
[図 24]バインディングファイルの編集画面の更に別例を示す図である。
[図 25]図 24におけるノインデイングファイルの編集結果に基づくレイアウトファイル編 集画面を示す図である。
[図 26]図 25における編集結果に基づいたデスティネーションファイルを表示させたと きの画面図である。
[図 27]定義ファイル生成過程を更に説明するための模式図である。
[図 28]実施の形態に係るデータ処理システムの構成を示す図である。
[図 29]XMLDB連携ドキュメントアプリケーションの作成過程を示す図である。
[図 30]XMLDB連携ドキュメントアプリケーションの利用過程を示す図である。
符号の説明
20 文書処理装置、 22 主制御ユニット、 24 編集ユニット、 30 DOMユニット、 3 2 DOM提供部、 34 DOM生成部、 36 出力部、 40 CSSュ-ッ K 42 CSS解 析部、 44 CSS提供部、 46 レンダリング部、 50 HTMLユニット、 52, 62 制御部 、 54, 64 編集部、 56, 66 表示部、 60 SVGユニット、 70 データベースシステム 、 72 ビュー生成部、 74 クエリ生成部、 76 データベースプラグイン、 78 ボキヤブ ラリ管理サーバ、 80 VCユニット、 82 マッピング部、 84 定義ファイル取得部、 86 定義ファイル生成部。
発明を実施するための最良の形態
[0015] (前提技術）
図 1は、前提技術に係る文書処理装置 20の構成を示す。文書処理装置 20は、文 書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理 するが、本前提技術では構造化文書の一例として XML文書を処理する例にっ ヽて 説明する。文書処理装置 20は、主制御ユニット 22、編集ユニット 24、 DOMユニット 3 0、 CSSユニット 40、 HTMLユニット 50、 SVGユニット 60、及び変換部の一例である VCユニット 80を備える。これらの構成は、ハードウェアコンポーネントでいえば、任意 のコンピュータの CPU、メモリ、メモリにロードされたプログラムなどによって実現され る力 ここではそれらの連携によって実現される機能ブロックを描いている。したがつ て、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合 せによっていろいろな形で実現できることは、当業者には理解されるところである。
[0016] 主制御ユニット 22は、プラグインのロードや、コマンド実行のフレームワークを提供 する。編集ユニット 24は、 XML文書を編集するためのフレームワークを提供する。文 書処理装置 20における文書の表示及び編集機能は、プラグインにより実現されてお り、文書の種別に応じて必要なプラグインが主制御ユニット 22又は編集ユニット 24に よりロードされる。主制御ユニット 22又は編集ユニット 24は、処理対象となる XML文 書の名前空間を参照して、 XML文書が 、ずれのボキヤブラリにより記述されて 、る かを判別し、そのボキヤブラリに対応した表示又は編集用のプラグインをロードして表 示や編集を実行させる。例えば、文書処理装置 20には、 HTML文書の表示及び編 集を行う HTMLユニット 50、 SVG文書の表示及び編集を行う SVGユニット 60など、 ボキヤブラリ（タグセット)ごとに表示系及び編集系がプラグインとして実装されており、 HTML文書を編集するときは HTMLユニット 50が、 S VG文書を編集するときは S V Gユニット 60が、それぞれロードされる。後述するように、 HTMLと SVGの双方の構 成要素を含む複合文書が処理対象となって ヽる場合は、 HTMLユニット 50と SVG ユニット 60の双方がロードされる。 [0017] このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後 力 適宜機能を追加又は削除することができるので、プログラムを格納するハードデ イスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行 時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体 としても、プラグインの形で新たなボキヤブラリに対応することが可能なので開発が容 易となり、ユーザとしても、プラグインの追カ卩により容易かつ低コストにて機能を追カロ することができる。
[0018] 編集ユニット 24は、ユーザインターフェースを介してユーザ力も編集指示のイベント を受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実 行 (リドウ）又は実行の取消（アンドゥ）などの処理を制御する。
[0019] DOMユニット 30は、 DOM提供部 32、 DOM生成部 34、及び出力部 36を含み、 X ML文書をデータとして扱うときのアクセス方法を提供するために定められた文書ォ ブジェクトモデル（Document Object Model: DOM)に準拠した機能を実現する。 DO M提供部 32は、編集ユニット 24に定義されているインタフェースを満たす DOMの実 装である。 DOM生成部 34は、 XML文書力も DOMツリーを生成する。後述するよう に、処理対象となる XML文書力 VCユニット 80により他のボキヤブラリにマッピング される場合は、マッピング元の XML文書に対応するソースツリーと、マッピング先の X ML文書に対応するデスティネーションツリーが生成される。出力部 36は、例えば編 集終了時に、 DOMツリーを XML文書として出力する。
[0020] CSSユニット 40は、 CSS解析部 42、 CSS提供部 44、及びレンダリング部 46を含 み、 CSSに準拠した表示機能を提供する。 CSS解析部 42は、 CSSの構文を解析す るバーサの機能を有する。 CSS提供部 44は、 CSSオブジェクトの実装であり、 DOM ツリーに対して CSSのカスケード処理を行う。レンダリング部 46は、 CSSのレンダリン グエンジンであり、 CSSを用いてレイアウトされる HTMLなどのボキヤブラリで記述さ れた文書の表示に用いられる。
[0021] HTMLユニット 50は、 HTMLにより記述された文書を表示又は編集する。 SVGュ ニット 60は、 SVGにより記述された文書を表示又は編集する。これらの表示 Z編集 系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部（Canvas) 56、 66、編集指示を含むイベントを送受信する制御部（Editlet) 52、 62、編集コマン ドを受けて DOMに対して編集を行う編集部 (Zone) 54、 64を備える。制御部 52又は 62が外部力も DOMツリーの編集コマンドを受け付けると、編集部 54又は 64が DO Mツリーを変更し、表示部 56又は 66が表示を更新する。これらは、 MVC (Model-Vi ew-Controller)と呼ばれるフレームワークに類似する構成をとつており、概ね、表示部 56及び 66が「View」に、制御部 52及び 62が「Controller」に、編集部 54及び 64と D OMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置 20では、 XML文書をツリー表示形式で編集するだけでなく、それぞれのボキヤブラリに応じた 編集を可能とする。例えば、 HTMLユニット 50は、 HTML文書をワードプロセッサに 類似した方式で編集するためのユーザインターフェースを提供し、 SVGユニット 60は 、 SVG文書を画像描画ツールに類似した方式で編集するためのユーザインターフエ ースを提供する。
[0022] VCユニット 80は、マッピング部 82、定義ファイル取得部 84、及び定義ファイル生 成部 86を含み、あるボキヤブラリにより記述された文書を、他のボキヤブラリにマツピ ングすることにより、マッピング先のボキヤブラリに対応した表示編集用プラグインで文 書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機 能を、ボキヤブラリコネクション（Vocabulary Connection: VC)と呼ぶ。定義ファイル取 得部 84は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファ ィルは、ノードごとに、ノード間の対応 (コネクション)を記述する。このとき、各ノードの 要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を 用いた演算式を記述してもよい。これらの機能については、後で詳述する。マツピン グ部 82は、定義ファイル取得部 84が取得したスクリプトファイルを参照して、 DOM生 成部 34にデスティネーションツリーを生成させ、ソースツリーとデスティネーションッリ 一の対応関係を管理する。定義ファイル生成部 86は、ユーザが定義ファイルを生成 するためのグラフィカルユーザインターフェースを提供する。
[0023] VCユニット 80は、ソースツリーとデスティネーションツリーの間のコネクションを監視 し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザ 力も編集指示を受け付けると、まずソースツリーの該当するノードを変更する。 DOM ユニット 30が、ソースツリーが変更された旨のミューテーシヨンイベントを発行すると、 VCユニット 80は、そのミューテーシヨンイベントを受けて、ソースツリーの変更にデス ティネーシヨンツリーを同期させるベぐ変更されたノードに対応するデスティネーショ ンツリーのノードを変更する。デスティネーションツリーを表示/編集するプラグイン、 例えば HTMLユニット 50は、デスティネーションツリーが変更された旨のミューテー シヨンイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新 する。このような構成により、少数のユーザにより利用されるローカルなボキヤブラリに より記述された文書であっても、他のメジャーなボキヤブラリに変換することで、文書を 表示することができるとともに、編集環境が提供される。
[0024] 文書処理装置 20により文書を表示又は編集する動作について説明する。文書処 理装置 20が処理対象となる文書を読み込むと、 DOM生成部 34が、その XML文書 力も DOMツリーを生成する。また、主制御ユニット 22又は編集ユニット 24は、名前空 間を参照して文書を記述しているボキヤブラリを判別する。そのボキヤブラリに対応し たプラグインが文書処理装置 20にインストールされて 、る場合は、そのプラグインを ロードして、文書を表示/編集させる。プラグインカ Sインストールされていない場合は 、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する 場合、定義ファイル取得部 84が定義ファイルを取得し、その定義に従って、デスティ ネーシヨンツリーが生成され、マッピング先のボキヤブラリに対応するプラグインにより 文書が表示 Z編集される。複数のボキヤブラリを含む複合文書である場合は、後述 するように、それぞれのボキヤブラリに対応したプラグインにより、文書の該当箇所が それぞれ表示 Z編集される。定義ファイルが存在しない場合は、文書のソース又はッ リー構造を表示し、その表示画面にぉ 、て編集が行われる。
[0025] 図 2は、処理対象となる XML文書の例を示す。この XML文書は、生徒の成績デー タを管理するために用いられる。 XML文書のトップノードである構成要素「成績」は、 配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、 属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」 は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞ れ、国語、数学、理科、社会の成績を格納する。例えば、名前カ^ A」である生徒の国 語の成績は「90」、数学の成績は「50」、理科の成績は「75」、社会の成績は「60」で ある。以下、この文書で使用されているボキヤブラリ（タグセット）を、「成績管理ボキヤ ブラリ」と呼ぶ。
[0026] 本前提技術の文書処理装置 20は、成績管理ボキヤブラリの表示 Z編集に対応し たプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示 するためには、前述した VC機能が用いられる。すなわち、成績管理ボキヤブラリを、 プラグインが用意された別のボキヤブラリ、例えば、 HTMLや SVGなどにマッピング するための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成す るためのユーザインターフェースについては後述することにして、ここでは、既に定義 ファイルが用意されているとして説明を進める。
[0027] 図 3は、図 2に示した XML文書を HTMLで記述された表にマッピングする例を示 す。図 3の例では、成績管理ボキヤブラリの「生徒」ノードを、 HTMLにおける表（「TA BLE」ノード)の行（「TR」ノード）に対応づけ、各行の第 1列には属性値「名前」を、第 2 列には「国語」ノードの要素値を、第 3列には「数学」ノードの要素値を、第 4列には「 理科」ノードの要素値を、第 5列には「社会」ノードの要素値を、それぞれ対応付ける 。これにより、図 2に示した XML文書を、 HTMLの表形式で表示することができる。 また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザ が HTMLによる表示画面上で、 HTMLユニット 50の編集機能により、これらの値を 編集することができる。第 6列には、国語、数学、理科、社会の成績の加重平均を算 出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定 義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集 時のユーザの利便性を向上させることができる。なお、第 6列は、編集不可であること が指定されており、平均点のみを個別に編集することができないようにしている。この ように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの 誤操作を防ぐことができる。
[0028] 図 4 (a)及び図 4 (b)は、図 2に示した XML文書を図 3に示した表にマッピングする ための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義された スクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプ レートが記述されている。図 4 (a) (b)の例では、コマンドとして、「生徒の追加」と「生 徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作 と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テン プレートとして、表の第 1行に「名前」、「国語」などの見出しが表示され、第 2行以降 に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を 表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し 、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生 徒」の内容を表示する行のうち、第 6列には、「(src:国語 + src:数学 + src:理科 + src: 社会） div 4」という計算式が記述されており、生徒の成績の平均が表示されることを 意味する。
[0029] 図 5は、図 2に示した成績管理ボキヤブラリで記述された XML文書を、図 3に示した 対応により HTMLにマッピングして表示した画面の例を示す。表 90の各行には、左 から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平 均点が表示されている。ユーザは、この画面上で、 XML文書を編集することができる 。たとえば、第 2行第 3列の値を「70」に変更すると、このノードに対応するソースッリ 一の要素値、すなわち、生徒「B」の数学の成績が「70」に変更される。このとき、 VC ユニット 80は、デスティネーションツリーをソースツリーに追従させるベぐデスティネ ーシヨンツリーの該当箇所を変更し、 HTMLユニット 50力 変更されたデスティネー シヨンツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「 B」の数学の成績が「70」に変更され、更に、平均点が「55」に変更される。
[0030] 図 5に示した画面には、図 4 (a) (b)に示した定義ファイルに定義されたように、「生 徒の追加」及び「生徒の削除」のコマンドカ -ユーに表示される。ユーザがこれらの コマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。 このように、本前提技術の文書処理装置 20では、階層構造の末端の構成要素の要 素値を編集するのみではなぐ階層構造を編集することも可能である。このようなッリ 一構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表 の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応 づけられてもよい。また、他のボキヤブラリを埋め込むコマンドがユーザに提供されて もよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データ を追加することもできる。以上のように、 VC機能により、 HTMLユニット 50の表示 Z 編集機能を利用しつつ、成績管理ボキヤブラリで記述された文書を編集することが可 能となる。
[0031] 図 6は、ユーザが定義ファイルを生成するために、定義ファイル生成部 86がユーザ に提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域 91には、 マッピング元の XML文書がツリー表示されている。画面右側の領域 92には、マツピ ング先の XML文書の画面レイアウトが示されている。この画面レイアウトは、 HTML ユニット 50により編集可能となっており、ユーザは、画面右側の領域 92において、文 書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポイン ティングデバイスにより、画面左側の領域 91に表示されたマッピング元の XML文書 のノードを、画面右側の領域 92に表示された HTMLによる画面レイアウト中へドラッ グ&ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとの コネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、 HTML画 面の表 90の第 1行第 3列にドロップすると、「数学」ノードと、 3列目の「TD」ノードの間 にコネクションが張られる。各ノードには、編集の可否が指定できるようになつている。 また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定 義ファイル生成部 86は、画面レイアウトとノード間のコネクションを記述した定義フアイ ルを生成する。
[0032] XHTML, MathML、 SVGなどの主要なボキヤブラリに対応したビューヮゃエディ タは既に開発されて 、るが、図 2に示した文書のようなオリジナルなボキヤブラリで記 述された文書に対応したビューヮゃエディタを開発するのは現実的でな 、。しかし、 上記のように、他のボキヤブラリにマッピングするための定義ファイルを作成すれば、 ビューヮゃエディタを開発しなくても、 VC機能を利用して、オリジナルなボキヤブラリ で記述された文書を表示 ·編集することができる。
[0033] 図 7は、定義ファイル生成部 86により生成された画面レイアウトの他の例を示す。図 7の例では、成績管理ボキヤブラリで記述された XML文書を表示するための画面に 、表 90と、円グラフ 93が作成されている。この円グラフ 93は、 SVGにより記述される。 後述するように、本前提技術の文書処理装置 20は、一つの XML文書内に複数のボ キヤブラリを含む複合文書を処理することができるので、この例のように、 HTMLで記 述された表 90と、 SVGで記述された円グラフ 93とを、一つの画面上に表示すること ができる。
[0034] 図 8は、文書処理装置 20による XML文書の編集画面の一例を示す。図 8の例で は、一つの画面が複数に分割されており、それぞれの領域において、処理対象とな る XML文書を異なる複数の表示形式により表示している。領域 94には、文書のソー スが表示されており、領域 95には、文書のツリー構造が表示されており、領域 96に は、図 5に示した HTMLにより記述された表が表示されている。これらのいずれの画 面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行 うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインカ、ソー スツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通 知するミューテーシヨンイベントのリスナーとして、それぞれの編集画面の表示を担当 するプラグインの表示部を登録しておき、いずれかのプラグイン又は VCユニット 80に よりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行さ れたミューテーシヨンイベントを受け取って画面を更新する。このとき、プラグインが V C機能により表示を行っている場合は、 VCユニット 80がソースツリーの変更に追従し てデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照 してプラグインの表示部が画面を更新する。
[0035] 例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は 、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用 いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において 編集が行われると、ソース表示用プラグインとツリー表示用プラグインは、変更された ソースツリーを参照して画面を更新し、領域 96の画面を担当して!/、る HTMLユニット 50は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して 画面を更新する。
[0036] ソース表示及びツリー表示は、 VC機能を利用して実現することもできる。すなわち 、ソース、ツリー構造を HTMLによりレイアウトし、その HTMLに XML文書をマツピン グして、 HTMLユニット 50により表示してもよい。この場合、ソース形式、ツリー形式、 表形式の 3つのデスティネーションツリーが生成されることになる。いずれかの画面に おいて編集が行われると、 VCユニット 80は、ソースツリーを変更した後、ソース形式、 ツリー形式、表形式の 3つのデスティネーションツリーをそれぞれ変更し、 HTMLュ ニット 50は、それらのデスティネーションツリーを参照して、 3つの画面を更新する。
[0037] このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザ の利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示 により文書の階層構造を把握しつつ、表 90などを用いて視覚的に分力りやすい形式 で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数 の表示形式による画面を同時に表示した力 一つの画面に一つの表示形式による画 面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主 制御ユニット 22が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに 指示して表示を切り替える。
[0038] 図 9は、文書処理装置 20により編集される XML文書の他の例を示す。図 9に示し た XML文書では、 SVG文書の「foreignObject」タグの中に XHTML文書が埋め込 まれており、さら〖こ、 XHTML文書の中に MathMLで記述された数式が入っている 。このような場合、編集ユニット 24が、名前空間を参照して、適切な表示系に描画作 業を振り分ける。図 9の例では、編集ユニット 24は、まず、 SVGユニット 60に四角形 を描画させ、つづいて、 HTMLユニット 50に XHTML文書を描画させる。さらに、図 示しない MathMLユニットに、数式を描画させる。こうして、複数のボキヤブラリを包 含する複合文書が適切に表示される。表示結果を図 10に示す。
[0039] 文書編集中、カーソル (キャリッジ）の位置に応じて、表示されるメニューを切り替え てもよい。すなわち、カーソルが、 SVG文書が表示された領域内に存在するときは、 SVGユニット 60が提供するメニュー、又は SVG文書をマッピングするための定義フ アイルに定義されたコマンドを表示し、カーソルが、 XHTML文書が表示された領域 内に存在するときは、 HTMLユニット 50が提供するメニュー、又は XHTML文書を マッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編 集位置に応じて適切なユーザインターフェースを提供することができる。 [0040] 複合文書にお!、て、あるボキヤブラリに対応する適切なプラグイン又はマッピング定 義ファイルがな力つた場合は、そのボキヤブラリにより記述された部分は、ソース表示 又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を 開くとき、埋め込まれた文書を表示するアプリケーション力 Sインストールされて 、な 、と 、その内容を表示することができな力つた力 本前提技術では、表示用のアプリケー シヨンが存在しなくても、テキストデータにより構成された XML文書をソース表示又は ツリー表示することにより内容を把握することができる。これは、テキストベースである XMLなどの文書ならではの特徴と 、える。
[0041] データがテキストベースで記述されることの他の利点として、例えば、複合文書中の 、あるボキヤブラリにより記述される部分において、同一文書内の他のボキヤブラリで 記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、 S VGなどの図に埋め込まれた文字列も検索対象とすることができる。
[0042] あるボキヤブラリにより記述された文書内に、他のボキヤブラリのタグを用いてもよい 。この XML文書は、妥当（valid)ではないが、整形式 (welH rmed)であれば、有効な XML文書として処理可能である。この場合、挿入された他のボキヤブラリのタグは、 定義ファイルによりマッピングされてもよい。例えば、 XHTML文書中に、「重要」、「 最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよ 、し、 重要度の順にソートして表示してもよ 、。
[0043] 図 10に示した編集画面において、ユーザにより文書が編集されると、編集された部 分を担当するプラグイン又は VCユニット 80がソースツリーを変更する。ソースツリー には、ノードごとにミューテーシヨンイベントのリスナーを登録できるようになっており、 通常は、各ノードが属するボキヤブラリに対応したプラグインの表示部又は VCュ-ッ ト 80がリスナーとして登録される。 DOM提供部 32は、ソースツリーが変更されると、 変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリス ナ一へミューテーシヨンイベントを発行する。例えば、図 9に示した文書において、く html >ノードの下位のノードが変更された場合、く html >ノードにリスナーとして登 録された HTMLユニット 50にミューテーシヨンイベントが通知されるとともに、その上 位のく svg>ノードにリスナーとして登録された SVGユニット 60にもミューテーシヨン イベントが通知される。このとき、 HTMLユニット 50は、変更されたソースツリーを参 照して表示を更新する。 SVGユニット 60は、自身のボキヤブラリに属するノードが変 更されて!/、な!/、ので、ミューテーシヨンイベントを無視してもよ！/、。
[0044] 編集の内容によっては、 HTMLユニット 50による表示の更新に伴って、全体のレイ アウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば 最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイ アウトが更新される。例えば、 HTMLユニット 50による表示領域が以前より大きくなつ た場合、 HTMLユニット 50は、まず自身の担当する部分を描画して、表示領域の大 きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の 大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、 通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部 分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
[0045] つづ!/、て、後述する実施の形態にお!、て、データベースシステムから取得したデー タを表示する画面を自動生成する機能の詳細にっ 、て説明する。ここで説明するデ ータ処理装置は、データを表示するための定義ファイルを自動生成して、データを表 示する画面を生成する。まず、図 11において本実施例における定義ファイル生成過 程を概観したあと、図 12以降において表示態様を中心として説明する。
[0046] 図 11は、本実施例における定義ファイル生成過程を説明するための模式図である データ処理装置は、編集対象となる XML文書ファイル (以下、「ソースファイル」とよ ぶ）と、ソースファイルの要素構造を定義するスキーマファイルを取得する。ここでいう スキーマファイルとは、 XML— Schema、 DTD (Document Type Definition)などの 仕様にしたがって記述される。生成物としての定義ファイルは、このソースファイルを 編集するために適切な表示レイアウト情報をもつデスティネーションファイルを生成す るためのファイルである。デスティネーションファイルは、前提技術で説明したデスティ ネーシヨンツリーをファイル化したものであるといえる。
[0047] データ処理装置は、スキーマファイルがあるときには、スキーマファイル力 バイン ディングファイル（Binding File)を生成する。バインディングファイルは、デスティネー シヨンファイルにおける表示レイアウトを編集するために使用される。スキーマファイル がなければ、データ処理装置はソースファイル本体から要素とその構造を抽出してバ インディングファイルを生成する。この場合、データ処理装置は、ソースファイルのル ート要素からツリートラバース (tree traverse)方式によって子要素を抽出することによ り、要素とその構造を抽出する。
更に、バインディングファイルによって、ソースファイルの要素に関する規則を再定 義可能である。たとえば、ソースファイルカゝらバインディングファイルを生成する場合 において、ソースファイル中の要素 Aは、子要素 Bを 4つ持っているとする。このとき、 バインディングファイルには、要素 Aの持ち得る子要素 Bの数は 4個までであるという 規則が一応記載される。ユーザはバインディングファイルが提供するメソッドを介して 、この要素 Aと子要素 Bに関する規則を再定義できる。たとえば、要素 Aが持ち得る 子要素 Bの数は、 1〜10までとして定義してもよい。スキーマファイル力もバインディ ングファイルが生成される場合であっても、スキーマファイルにお 、て定義されて!、る 規則の範囲内において、このような要素に関する規則を再定義できてもよい。
このようにバインディングファイルは、要素に関する規則と、それを定義するための 機能も提供する。
なお、以下においては、スキーマファイルからソースファイルの要素構造を示すスキ 一マ情報を取得するものとして説明する。
ユーザは、データ処理装置にてバインディングファイルを編集可能である。バイン ディングファイルに対して、ユーザはデスティネーションファイルの基本的な表示レイ アウトを GUI (Graphical User Interface)により設定できる。こうして、ノインディングフ アイルで定義された表示レイアウト情報をスキーマ情報の各要素に適用することによ りレイアウトファイルが生成される。レイアウトファイルは、スキーマファイルに含まれて いた各要素の具体的な表示レイアウトを示す HTMLファイルである。なお、レイアウト ファイルは、タグによって構造ィ匕されるタイプの構造ィ匕文書ファイルに限られる必要は なぐ表計算アプリケーションやプレゼンテーション用アプリケーションのように表示レ ィアウト情報を含むファイルであればょ 、。ユーザはレイアウトファイルそのものを編 集することにより、表示レイアウトを更に精緻に編集できる。本実施例においては、バ インディングファイルによって、デスティネーションファイルの表示レイアウトの基本設 定を行 、、レイアウトファイルによってその詳細設定を行う。
[0049] バインディングファイルに示されて!/、た要素とレイアウトファイルの表示領域との対 応関係から、ソースファイルとデスティネーションファイル間のデータ変換形式を定め るための XSLTファイルが生成される。最後に、この XSLTファイルに基づいて、バイ ンデイングファイルに対応するソースファイルと、レイアウトファイルに対応するデステ イネーシヨンファイルの対応関係を示す定義ファイルが生成される。
以下、ユーザインタフェースを中心としてこれらの処理の流れを説明する。
[0050] 図 12、本実施例におけるスキーマファイルを示す図である。
ここに示すスキーマファイルは、後述の図 13に示すソースファイルがしたがうべき要 素構造に関する規則を記述している。また、このスキーマファイルは、 XML— Sche maと!、う仕様にしたがって記述されて 、る。
同図においては、たとえば、上から 3行目において、「customerList」という名前の要 素に関し、そのデータ型は「customerListType」であるとして定義されている。「custom erListType」というデータ型は、次行において、「sfa」という名前空間にて「listID」、「to talEstimateJ、「totalNumber」、「customer」と 、う 4つの子要素を含むとして定義され ている。更に、「customer」要素のデータ型は「customerType」であり、その内容も定 義されている。また、「customer」要素の個数は 0個以上として定義されている。
ソースファイルは、スキーマファイルに示される規則にしたがって記述されなければ ならな 、。スキーマファイルはソースファイルに含まれる各要素のデータ型や構造を 規定するファイルであるから、ソースファイルそのものよりも要素間の構造に関するル ールを理解しやすい。
[0051] 図 13は、図 12のスキーマファイルに対応するソースファイルを示す図である。
このソースファイルにおいては、 「customerList」の子要素として、 「listID」、 「totalNu mber」、 「totalEstimate」および「cusutomer」が定義されている。また、これらの要素に は値が含まれている。「cusutomer」要素は、 3つ含まれている。
[0052] 図 14は、図 12のスキーマファイルと図 13のソースファイルに基づいて生成される定 義ファイルを示す図である。 同図は定義ファイルの一部を示している。ここに示す定義ファイルにおいては、「sfa ィルにおける各要素を XHTML形式のデスティネーションファイルに変換するための ルールが記述されている。本実施例におけるデータ処理装置は、直感的なユーザィ ンタフェースにてこの定義ファイルを簡易に生成できる。
[0053] 図 15は、バインディングファイルの編集画面を示す図である。
データ処理装置は、スキーマファイルから生成したバインディングファイルを同図に 示す所定形式にて画像表示させる。同図下部の領域 (以下、「プロパティ領域」）には 、スキーマファイルに示されていた各要素がツリー表示されるとともに、そのデータ型 なども編集可能に表示される。プロパティ領域において、要素名に付されたチェック ボックスにチェックを入れることによってその子要素を展開表示させることができる。こ のような態様によれば、スキーマファイルに膨大な数の要素が定義されているときで あっても、編集対象となる要素だけに表示対象を絞ることができる。
[0054] データ処理装置は、各要素に対して一意に IDを設定する。たとえば、「listID」という 要素には「L1」という IDが設定されている。 IDは、要素名の頭文字の「L」と通し番号 の「1」をあわせることにより決定されている。また、データ処理装置は、各要素に対し て一意にサンプル値を設定する。 riistlDj t 、う要素には「2005-G30182」 t 、うサン プル値が設定されている。同図中央上部には、これらの要素の表示形式を定義する ための領域 (以下、「レイアウト領域」）が設けられている。ユーザはレイアウト領域に おいて、各要素の IDを配列することにより、レイアウトファイルに反映させることができ る。レイアウト領域とレイアウトファイルの関係については図 24以降に関連して詳述す る。なお、図 15のプロパティ領域中段において、要素「customer」をテーブル形式で 表示させるように表示形式が指定されている。この指定が、次の図 16に示すレイァゥ トファイルに反映される。
[0055] 図 16は、図 15におけるバインディングファイルの編集結果に基づくレイアウトフアイ ル編集画面を示す図である。
図 15における指定にしたがって、要素「customer」の子要素はテーブル形式で表 示されている。たとえば、スキーマフアイノレの要素「customerList/customer/name」は 、レイアウトファイルに示されるテーブルのもっとも左の表示領域に対応している。また
、このときの表示形式は、図 15のレイアウト領域における設定が反映される。ユーザ は、この編集画面においてレイアウトファイルをいわゆる WYSIWYG (What You See Is What You Get)にて編集できる。
[0056] こうして、スキーマファイルに示される各要素の表示レイアウトがレイアウトファイルと して保存される。データ処理装置は、このようなスキーマファイルの要素とレイアウトフ アイルの要素の対応関係から XSLTファイルを生成し、更に、前提技術で説明した定 義ファイルを生成する。
[0057] ユーザは、レイアウトファイルの編集画面において、要素の表示位置をドラッグアン ドドロップによって変更できる。すでに定義ファイルが生成された後の編集であれば、 データ処理装置は、スキーマファイルの要素とレイアウトファイルの表示位置の対応 関係の変化を定義ファイルに反映させなければならない。データ処理装置は、レイァ ゥトファイルにおけるサンプル値とスキーマファイルの要素との対応関係を監視してい る。このため、レイアウトファイルにおける要素の位置が変更されても、サンプル値の 位置に応じて定義ファイルを更新できる。ここでレイアウトファイルに含まれる各表示 要素は、サンプル値によって特定される。そのため、 XSLTファイルを生成するときに は、レイアウトファイルにおけるサンプル値をキーとして、対応関係が再定義される。
[0058] 図 17は、図 16における編集結果に基づいたデスティネーションファイルを表示させ たときの画面図である。
ソースファイルから定義ファイルにしたがってデスティネーションファイルが生成され る。図 16は、このデスティネーションファイルを表示させた画面である。ソースファイル の要素「customer」は 3つあったので、図 16のテーブル形式にしたがって 3つの「cust omer」要素が表示されている。ユーザは、図 17の画面を介してソースファイルのデー タを編集できる。この仕組みは、前提技術でボキヤブラリコネクションとして説明した仕 組みである。
[0059] 図 18は、バインディングファイルの編集画面の別例を示す図である。
同図のプロパティ領域中段においては、要素「customer」をリスト形式で表示させる ように指定されている点が図 15と異なる。 [0060] 図 19は、図 18におけるバインディングファイルの編集結果に基づくレイアウトフアイ ル編集画面を示す図である。
図 18における表示形式の指定にしたがって、要素「customer」の子要素はリスト形 式で表示されている。このように、バインディングファイルにおける表示形式の指定に したがって、レイアウトファイルも変化する。
同図の場合、スキーマファイルの要素「customerList/customer/name」は、レイァゥ トファイルに示される各リストの先頭要素に対応している。データ処理装置は、このよう なスキーマファイルの要素とレイアウトファイルの要素の対応関係力も前提技術で説 明した定義ファイルを生成する。
[0061] 図 20は、図 19における編集結果に基づいたデスティネーションファイルを表示させ たときの画面図である。
ソースファイルの要素「customer」は 3つあったので図 18のリスト形式にしたがって 3 つの要素「customer」の内容がリスト表示されている。ユーザは、図 20の画面を介して ソースファイルを編集できる。
[0062] 図 21は、バインディングファイルの編集画面の更に別例を示す図である。
同図にお 、ては、要素「totalNumber」の値を算出するための計算式として「count(N 1)」がユーザからの編集操作により設定されて 、る。「N1」はすなわち要素「name」の I Dであるから、要素「totalNumber」の値は、ソースファイルにおける要素「name」の数 である。また、要素「totalEstimate」の値を算出するための計算式として「sum(El)」が 設定されて 、る。「E1」はすなわち要素「estimate」の IDであるから、要素「totalEstimat e」の値は、ソースファイルにおける要素「estimate」の値の合計値である。このように、 バインディングファイルの編集画面においては、長い要素名ではなく ID値によって各 要素をシンプルな入力形式にて取り扱うことができる。
[0063] 図 22は、図 21におけるバインディングファイルの編集結果に基づくレイアウトフアイ ル編集画面を示す図である。図 22は図 16とかわるところはない。
[0064] 図 23は、図 22における編集結果に基づいたデスティネーションファイルを表示させ たときの画面図である。
rtotalNumberJという項目には「3」、すなわち、ソースファイルにおける要素「name」 の数が表示されている。同様に、「totalEstimate」という項目には「8000」、すなわち、 ソースファイルにおける要素「estimate」の値を合計値（1000 + 3500 + 3500 = 800 0)が表示されている。
[0065] 図 24は、バインディングファイルの編集画面の更に別例を示す図である。
ここでは、図 12に示したスキーマファイルとは別のスキーマファイルを例にとって説 明する。
同図に示すように、ユーザは、レイアウト領域において IDを配列することにより、レイ アウトファイルにおける基本的なレイアウトを設定できる。バインディングファイルが表 示されるとき、レイアウト領域には、各要素の IDが初期設定として配列される。このと きの配列は、スキーマファイルにおける要素構造を反映した配列であってもよい。たと えば、親子、あるいは、兄弟の関係にある要素同士は、表示位置が近くなるように配 列されてもよい。また、「totalNumber」、「Number」、「subtotalNumber」のように、要素 名が近いときには、これらの要素同士は、表示位置が近くなるように配列されてもよい 。このように IDの配列を初期設定する、最初から配列を作成するよりも、レイアウト作 成の省力化を図ることができる。
[0066] 図 25は、図 24におけるバインディングファイルの編集結果に基づくレイアウトフアイ ル編集画面を示す図である。
レイアウトファイルにおいては、図 24のレイアウト領域の編集内容にしたがって各要 素が表示されている。
[0067] 図 26は、図 25における編集結果に基づいたデスティネーションファイルを表示させ たときの画面図である。
[0068] 図 27も、定義ファイル生成過程を更に説明するための模式図である。
同図について付言すると、バインディングファイルに対するユーザの編集操作によ つて、ノインディングファイルに補完的な情報が付加される。たとえば、要素に関する 規則の定義や再定義などである。このバインディングファイルをもとにして、定義ファ ィルが生成される力 定義ファイルの代わりに、 XSLTファイルが生成されてもよい。 そのほかにも、ソースファイルとデスティネーションファイル間のデータマッピングを実 現するためのオブジェクト、たとえば、 Java (登録商標）のオブジェクトが生成されても よい。
[0069] (実施の形態）
図 28は、実施の形態に係るデータ処理システムの構成を示す。本実施の形態では 、前提技術で説明した文書処理装置 20と、実施の形態に係るデータベースシステム 70の連携システム力 標準化された XMLスキーマによって部品化された情報や、こ れまで企業内で長年蓄積されてきた貴重なデータ資源を自由自在に組み合わせて 、より高度な情報化要求に答えられるアプリケーションを簡単に開発できる環境であ ることを解説する。そして、この環境の登場によって、ビジネスにおける迅速で品質の 高い意志決定を行うことを可能にし、また、ネットワーク環境における個人のコンビュ 一ティング環境においても、ニーズにあった最適なサービスが即座に提供されうる新 たなインフラへと進化できることを解説する。
[0070] 文書処理装置 20は、 XMLによる情報の標準化 ·部品化を見据えて、様々な形式 の XMLボキヤブラリを XMLオブジェクトとして自由に無制限に組み合わせてアプリケ ーシヨンを作成することができるように設計されている。それは、あた力もパレットの上 で色を自由に組み合わせキャンバスに自在に絵を描くかのように、目的の情報を組 み合わせた高度に統合されたアプリケーションを手に入れることができる。
[0071] このような環境においては、情報を格納するシステムにも高い能力が求められる。 X ML形式の情報に対する高いコンピューティングの要求はもとより、従来から RDBに 蓄えられたデータ資源も透過的に取り扱い、様々なデータを複合的に取り扱う要求 が高まってくる。本実施の形態のデータベースシステム 70は、その内部に蓄積された RDB資源と XMLDB資源を SQLと X— Queryの双方から自由にアクセスし、いずれ の形式のデータとしても入出力可能なハイブリッドな構成となっている。
[0072] 従来の企業情報システムが、基幹系を中心に発展し、処理結果を提供するスタイ ルが中心であつたのに対して、文書処理装置 20を使ったエンタープライズアプリケー シヨンは、情報統合とアプリケーション統合を実現する。アプリケーションの利用者が、 情報を自らの意図で処理し、意志決定し、ビジネスを成功に導くシステムとなる。
[0073] データベースへの問 、合わせに SQL文や X— Query文を直接プログラミングする 必要はな 、。クエリ生成部がデータベースシステムへの問!、合わせを GUIで支援す る。また、ボキヤブラリ管理サーバのボキヤブラリ辞書と連動しているので、氾濫する X MLスキーマや XMLスキーマの異なる XMLデータ間を、無理なく活用していくことが 可會 になる。
[0074] システムがいくら自由なデータ処理能力を提供しても、それを簡単にかつ効果的な GUIとして表現できる仕組みが必要である。ビュー生成部は、クエリ結果を解析し、そ こから半自動的にクエリ結果を表示するためのデータを生成する。
[0075] 従来のシステム開発と、本実施の形態の文書処理装置 20による開発の違いは、シ ステムアーキテクチャや開発手順が異なるだけではなぐビジネスの重要な変化に対 して ITが適切に応えてゆけるかといったテーマに対して最適な解決を提供する。ダイ ナミックな事業構造の変化に対して、文書処理装置 20により実現されるシステムは、 サーバの構成変更を強いることなくクライアントにおける情報統合を実現する。さらに
、 Webサービスを組み合わせ、ユーザ指向のリッチなアプリケーションをスピーディに 提供することが可能になる。
[0076] これまでの RDBをベースとした情報システムの構築は、データベーススキーマの変 更による開発工数の増加を防ぐために、小規模なプロトタイピングを行って力もデー タベーススキーマの設計、ミドルウェアの開発、 GUIの開発の手順で進められてきた 。設計環境や開発ツールが進化した今日においても、この手順に変わりはない。この 従来方法は、各フェーズの作業を確定することで修正のリスクを低減させるが、全体 の行程を短縮させることは困難であった。
[0077] 文書処理装置 20とデータベースシステム 70を利用したシステム開発では、 DBに 固定的なスキーマを構築せずに、 XMLデータそのものがもつ構造情報を利用したプ ログラム開発が中心である。これにより開発者は情報構造を進化させながら処理プロ グラムを同時開発していくことができる。この方法は初期開発時の開発工程を短縮す るば力りでなぐ完成後の様々な変更要求にも柔軟に対応できることを示している。
[0078] 文書処理装置 20は、複数の XMLスキーマを自由に、かつ無制限に組み合わせる 開発方法なので、すでにある実用性の高い XMLスキーマを利用しつつ、ユーザが 必要とする拡張をカ卩えて短期間に繰り返しシステムの改善を図ることができる。これに より、短期間に非常に少ない工数で開発を終えることができるば力りでなぐ繰り返さ れる改善によってニーズにあった本当に使えるシステムを提供することができる。
[0079] クライアント側からはシングルインターフェイスでデータベースシステム 70の堅牢さ に守られた企業内のあらゆるデータ資源を柔軟に扱うことが可能となり、システムの構 成や維持がきわめて簡便になる。
[0080] 取り出した情報は、文書処理装置 20でユーザの要求に応じてダイナミックに組み 合わせられ、マルチパーパスに自在に業務に最適な情報資産へと価値転換すること ができる。
[0081] 文書処理装置 20は、複数の XMLボキヤブラリをシームレスに複合するためのシン プルかつ強力な仕組みを持った XMLのハンドリング環境である。データベースシス テム 70に格納されている多様な XML情報を活用したり、インターネット 'イントラネット 上の配置先の異なる XMLサービスの情報を統合できる機能を持っている。
[0082] データベースシステム 70は、ハイブリッド型の XMLDBである。これは、従来からあ るリレーショナルデータベースのフィールドタイプに加えて「XML型」のフィールドタイ プを拡張し、これらの型を 1つのテーブル中に混在させて定義し、同一のトランザクシ ヨン内で扱うことができるようになつている。また、従来力もある RDB型のテーブルも X ML形式として読み出すこともできる変 能も備えている。
[0083] ボキヤブラリ管理サーバ 78は、 XMLタグ間の意味関係を管理 '共有するためのサ ーバプロセスである。異なる XMLボキヤブラリ間のタグも管理することができる。ボキ ャブラリ管理サーノ 78は、データベースシステム 70に格納された XML型のデータに 付された XMLタグのうち、同種のデータの対応関係を保持する。例えば、図 2に示し た成績管理ボキヤブラリの構成要素「生徒」の属性「名前」や、別のボキヤブラリのタグ 「name」などが、「名前」を格納する XMLタグであるという対応関係を保持する。この 対応関係は、後述するように、クエリ生成部 74が提供する GUIにおいて利用される。
[0084] クエリ生成部 74は、 XMLDBおよび RDBに対するクエリ文を対話的に生成するた めの標準的な GUIである。クエリ生成部 74は、データベースシステム 70に保持され た、マークアップ言語により構造化されたデータの構造を示す情報を取得して提示し 、提示したデータの中から文書に埋め込むデータの指定を受け付け、受け付けたデ 一タのクエリ文を生成する。このとき、クエリ生成部 74は、ボキヤブラリ管理サーバ 78 から XMLタグ間の対応関係を取得し、データベースシステム 70に保持された、 XM Lデータの構造を提示するときに、対応関係を識別可能に提示する。これにより、ュ 一ザがタグの意味を事前に把握して 、なくても、クエリ生成部 74が提供する GUI上 でタグの意味関係を把握することができる。このように、ボキヤブラリ管理サーバ 78と 連携することで、エンドユーザが XMLDB内にある様々な XMLスキーマを事前に調 ベることなぐ情報を入手することができるような GUIを提供する。これにより、スキー マの異なる XMLデータを無理なく管理し、活用していくことが可能になる。
[0085] ビュー生成部 72は、データベースシステム 70から受け取った検索結果を解析し表 示用のビューを自動生成する。ビュー生成部 72は、前提技術で説明したように、デ ータベースシステム 70から取得した XMLデータを表示するための定義ファイルを自 動生成することにより、表示用のビューを生成してもよい。 XMLデータベースのクエリ 結果の構造はクエリの内容によって変化する場合がある。これは、固定的なスキーマ しか扱えな 、システムでは、 XMLデータベースの能力を十分に生かせな!/、ことを意 味する。それに対し、本実施の形態の文書処理装置 20では、任意のスキーマに対し てビューを自動生成することができるので、スキーマが流動的に変化する場合であつ ても、適切にデータを表示することができる。クエリ生成部 74は、データベースシステ ム 70に保持された、従来のフィールドタイプのデータ、すなわちマークアップ言語に より構造ィ匕されていないデータを、マークアップ言語により構造化されたデータの形 式で取得するためのクエリ文を生成可能である。したがって、文書処理装置 20は、ハ イブリツド型のデータベースシステム 70に格納された任意のデータを、任意のスキー マにしたがって XML形式で取得し、自動的にビューを生成することができる。
[0086] データベースシステム 70への問い合わせ条件と問い合わせ結果は、データベース プラグイン 76により、データベースシステム 70と接続される。このミドルウェアによって 下位のデータベースシステム 70の差異を吸収し、上位のアプリケーションのケーパピ リティを確保する。
[0087] 図 29は、 XMLDB連携ドキュメントアプリケーションの作成過程を示す。 XMLDB 連携ドキュメントアプリケーションは、文書処理装置 20により作成することができる。文 書処理装置 20でボキヤブラリコンポーネント（HTMLユニットや SVGユニットなど）や ビューテンプレートを利用して目的のアプリケーションのひな形を作成する流れの中 で、 XMLDBZRDB接続が可能な条件記憶型ボキヤブラリコンポーネントを貼り付け ることで、 DBに蓄積したデータソースを利用可能なアプリケーションを構築することが できる。
[0088] 目的に応じてレガシーシステムに蓄積されているデータソースを抽出する手法 (ノウ ハウ）を、クエリ生成部 74の GUIを利用することで、 RDBZXMLDBの違いも含めた DBシステムの差違を意識することなく指定することが可能となる。
[0089] また、生成された条件式はアプリケーションに貼り付けられた条件記憶型ボキヤブラ リコンポーネントのパラメータ値として記憶される。
[0090] また、より目的指向で情報を扱うための仕組みとして、タグ管理機能を利用すること ができる。これによりスキーマ毎のタグ名の違いを意識することなぐタグで管理され ている情報本来の意味に重点を置いた条件文の作成ができる。また、このようなタグ 管理の定義を企業内で共有することで、アプリケーションを設計する側にとっても、考 慮漏れの少ない条件を設計することが容易となる。
[0091] DBアクセスの結果得られるクエリ結果中のスキーマは、呼び出し側のクエリ文ゃ検 索結果によってスキーマは動的に変更されうる。そのような出力結果を自動的に視覚 化する機能としてビュー生成部 72が用意されている。
[0092] また、業務や目的に特ィ匕した、より最適な表現を行うための機能として、ビューテン プレートを利用することができる。これにより、抽出したデータを「作成日」と「作成者」 を軸にした、マップ形式で表示することも可能となる。このクエリ結果の表現方法につ
Vヽても XMLアプリケーションに記憶される。
[0093] こうして生成された XMLアプリケーションは文書サーバへ登録され、ユーザが必要 な時にダウンロードして利用することができる仕組みになっている。
[0094] 図 30は、 XMLDB連携ドキュメントアプリケーションの利用過程を示す。クライアント ユーザはクライアント装置の文書処理装置 20を起動し、 XMLアプリケーションの一 覧力 業務に応じたものを選択する。
[0095] XMLアプリケーションが起動すると、ボキヤブラリコンポーネントに記憶されている 条件式で RDBZXMLDBにアクセスを行う。得られた最新のクエリ結果にあら力じめ 表現形式が指定されて!ヽる場合はその形式で、設定されて!ヽな ヽ場合はビュー生成 部 72によって自動的に視覚化され、 XMLアプリケーション内に表示される。
[0096] クエリ結果を表示した状態は、その時点でのスナップショットとして「ドキュメント」保 存することができる。もちろん保存したドキュメントは XML文書であり、 XMLDBに蓄 積することで、「既存データを再利用したデータ作成」のサイクルを実現することがで きる。
[0097] ドキュメントアプリケーションとして記憶して 、る条件式ゃクエリ結果の表現方法は、 利用者側でも自由に変更することができる。このように変更をカ卩えたものを再び XML アプリケーションとして文書サーバへ登録することにより、同種の業務アプリケーション の開発工期短縮だけでなぐ利用者側の意図をボトムアップ的に反映した業務アプリ ケーシヨンの構築が可能となる。
[0098] ダイナミックな事業構造の変化に対して、文書処理装置 20とデータベースシステム 70により実現されるシステムは、クライアントにおける情報統合だけではなぐさまざま な XMLソースと組み合わせ、ユーザ指向のリッチなアプリケーションをスピーディに 提供することが可能になる。そして、企業内のユーザが社内の情報資産を活用し、競 争力を高めるコラボレーションを実現する環境も提供することができる。データ資源を 企業内で最適に利用するためのインフラは、情報資産とアプリケーション資産をユー ザが最適に活用するインフラを提供する XMLアプリケーション時代へ進化する。
[0099] 以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それ らの各構成要素や各処理プロセスの組合せに 、ろ 、ろな変形例が可能なこと、また そうした変形例も本発明の範囲にあることは当業者に理解されるところである。
産業上の利用可能性
[0100] 本発明は、構造化された文書を処理する文書処理装置に利用可能である。

Claims

請求の範囲
[1] マークアップ言語により構造化された文書を処理する文書処理装置であって、 データベースシステムに保持されたデータを前記文書に埋め込むときに、前記デ ータベースシステムに応じたクエリ文を生成するクエリ生成部と、
前記データベースシステム力 前記クエリ文の結果を前記マークアップ言語により 構造ィ匕されたデータの形式で取得したときに、その結果を表示するための画面を生 成するビュー生成部と、
を備えることを特徴とする文書処理装置。
[2] 前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語 により構造化されたデータの構造を示す情報を取得して提示し、提示したデータの 中から前記文書に埋め込むデータの指定を受け付け、受け付けたデータのクエリ文 を生成することを特徴とする請求項 1に記載の文書処理装置。
[3] 前記クエリ生成部は、マークアップ言語により構造ィ匕されたデータのうち、同種のデ ータの対応関係を保持した管理サーバから、前記対応関係を取得し、前記データべ ースシステムに保持された、前記マークアップ言語により構造ィ匕されたデータの構造 を提示するときに、前記対応関係を識別可能に提示することを特徴とする請求項 1又 は 2に記載の文書処理装置。
[4] 前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語 により構造ィ匕されて 、な 、データを、マークアップ言語により構造ィ匕されたデータの 形式で取得するためのクエリ文を生成可能であることを特徴とする請求項 1から 3の いずれかに記載の文書処理装置。
[5] マークアップ言語により構造化された文書を処理する文書処理装置と、
前記文書に利用可能なデータを保持するデータベースシステムと、を備え、 前記文書処理装置は、
前記データベースシステムに保持されたデータを前記文書に埋め込むときに、前 記データベースシステムに応じたクエリ文を生成するクエリ生成部と、
前記データベースシステム力 前記クエリ文の結果を前記マークアップ言語により 構造ィ匕されたデータの形式で取得したときに、その結果を表示するためのビューを生 成するビュー生成部と、を備えることを特徴とするデータ処理システム。
[6] 前記データベースシステムに保持されたデータ間の対応関係を管理する管理サー バを更に備えることを特徴とする請求項 5に記載のデータ処理システム。
[7] 前記データベースシステムは、 XMLデータベース及びリレーショナルデータベース の複合型データベースシステムであることを特徴とする請求項 5又は 6に記載のデー タ処理システム。
[8] マークアップ言語により構造化された文書を処理する文書処理装置が、データべ ースシステムに保持されたデータを前記文書に埋め込むときに、前記データベース システムに応じたクエリ文を生成するステップと、
前記データベースシステム力 前記クエリ文の結果を前記マークアップ言語により 構造ィ匕されたデータの形式で取得したときに、その結果を表示するための画面を生 成するステップと、
を備えることを特徴とする文書処理方法。
[9] コンピュータを、
マークアップ言語により構造化された文書を処理する文書処理装置力 S、データべ ースシステムに保持されたデータを前記文書に埋め込むときに、前記データベース システムに応じたクエリ文を生成する手段、
前記データベースシステム力 前記クエリ文の結果を前記マークアップ言語により 構造ィ匕されたデータの形式で取得したときに、その結果を表示するための画面を生 成する手段、
として機能させることを特徴とするプログラム。
PCT/JP2007/050448 2006-01-13 2007-01-15 文書処理装置 Ceased WO2007081017A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007553980A JPWO2007081017A1 (ja) 2006-01-13 2007-01-15 文書処理装置
US12/160,709 US20100169333A1 (en) 2006-01-13 2007-01-15 Document processor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006006773 2006-01-13
JP2006-006773 2006-01-13

Publications (1)

Publication Number Publication Date
WO2007081017A1 true WO2007081017A1 (ja) 2007-07-19

Family

ID=38256418

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/050448 Ceased WO2007081017A1 (ja) 2006-01-13 2007-01-15 文書処理装置

Country Status (3)

Country Link
US (1) US20100169333A1 (ja)
JP (1) JPWO2007081017A1 (ja)
WO (1) WO2007081017A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012063451A1 (ja) * 2010-11-09 2012-05-18 日本電気株式会社 情報処理装置
CN107248112A (zh) * 2017-06-08 2017-10-13 深圳易嘉恩科技有限公司 基于xbrl的财务云审单和记账规则公式设计器

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8407238B2 (en) * 2009-10-28 2013-03-26 Yahoo! Inc. System and methods for enabling arbitrary developer code consumption of web-based data
US8621376B2 (en) * 2009-10-28 2013-12-31 Yahoo! Inc. Developer interface and associated methods for system for querying and consuming web-based data
US20110137923A1 (en) * 2009-12-09 2011-06-09 Evtext, Inc. Xbrl data mapping builder
US9747265B2 (en) * 2011-03-25 2017-08-29 Management Systems Resources, Inc. Dynamically generating a plurality of interfaces using structured control files
US8972240B2 (en) * 2011-05-19 2015-03-03 Microsoft Corporation User-modifiable word lattice display for editing documents and search queries
US20180365273A1 (en) * 2015-12-08 2018-12-20 Nec Corporation Document processing apparatus, method and storage medium

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6721727B2 (en) * 1999-12-02 2004-04-13 International Business Machines Corporation XML documents stored as column data
US20020116371A1 (en) * 1999-12-06 2002-08-22 David Dodds System and method for the storage, indexing and retrieval of XML documents using relation databases
US8914807B2 (en) * 2001-09-28 2014-12-16 International Business Machines Corporation Method, system, and program for generating a program capable of invoking a flow of operations
US8924408B2 (en) * 2001-09-28 2014-12-30 International Business Machines Corporation Automatic generation of database invocation mechanism for external web services
KR100484138B1 (ko) * 2002-05-08 2005-04-18 삼성전자주식회사 관계형 데이터베이스에서 정규 경로식 질의를 처리하는ｘｍｌ 인덱싱 방법과 자료구조
US7457810B2 (en) * 2002-05-10 2008-11-25 International Business Machines Corporation Querying markup language data sources using a relational query processor
US7366735B2 (en) * 2004-04-09 2008-04-29 Oracle International Corporation Efficient extraction of XML content stored in a LOB
US7523131B2 (en) * 2005-02-10 2009-04-21 Oracle International Corporation Techniques for efficiently storing and querying in a relational database, XML documents conforming to schemas that contain cyclic constructs

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KASAHARA Y.: "XML Server eXcelon Nyumon Dai 1 Kai XML o Riyoshita Web Application ga Kantan ni Jitsugen eXcelon no Gaiyo to Kensaku Apuri no Kaihatsu", DB MAGAZINE, vol. 10, no. 2, 1 June 2000 (2000-06-01), pages 214 - 220, XP003016450 *
NAGASE M. ET AL.: "XML Database eno Callback Kansu no Jisso to Tekiyo (Implementation and application of the callback function mechanism to XML Database", DATABASE TO WEB JOHO SYSTEM NI KANSURU SYMPOSIUM RONBUNSHU, vol. 2003, no. 18, 26 November 2003 (2003-11-26), pages 109 - 116, XP003016452 *
YOSHIKAWA K.: "XML Tool Kit Oracle XML Developer's Kit for Java Oracle", JAVA WORLD, vol. 4, no. 9, 1 September 2000 (2000-09-01), pages 181 - 185, XP003016451 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012063451A1 (ja) * 2010-11-09 2012-05-18 日本電気株式会社 情報処理装置
JP5761200B2 (ja) * 2010-11-09 2015-08-12 日本電気株式会社 情報処理装置
CN107248112A (zh) * 2017-06-08 2017-10-13 深圳易嘉恩科技有限公司 基于xbrl的财务云审单和记账规则公式设计器

Also Published As

Publication number Publication date
US20100169333A1 (en) 2010-07-01
JPWO2007081017A1 (ja) 2009-06-11

Similar Documents

Publication Publication Date Title
JP2008234370A (ja) 文書処理装置及び文書処理方法
JPWO2006085455A1 (ja) 文書処理装置および文書処理方法
WO2007081017A1 (ja) 文書処理装置
JPWO2007105364A1 (ja) 文書処理装置及び文書処理方法
JPWO2006051954A1 (ja) 文書処理装置及び文書処理方法
JPWO2006137563A1 (ja) データ処理装置及びデータ処理方法
JPWO2005098661A1 (ja) 文書処理装置及び文書処理方法
JP2008097215A (ja) データ処理装置
JPWO2006137562A1 (ja) 文書処理装置及び文書処理方法
JPWO2005098658A1 (ja) 文書処理装置及び文書処理方法
JPWO2005098660A1 (ja) 文書処理装置及び文書処理方法
JPWO2006051869A1 (ja) 文書処理装置及び文書処理方法
JP4566196B2 (ja) 文書処理方法および装置
JPWO2007052680A1 (ja) 文書処理装置及び文書処理方法
JP4627530B2 (ja) 文書処理方法および装置
JPWO2006051974A1 (ja) 文書処理装置および文書処理方法
JPWO2005098662A1 (ja) 文書処理装置及び文書処理方法
JPWO2006051955A1 (ja) サーバ装置及び名前空間発行方法
WO2006051712A1 (ja) 文書処理装置及び文書処理方法
JP4417384B2 (ja) 文書処理装置および文書処理方法
CN101203848A (zh) 文档处理装置和文档处理方法
JPWO2006051956A1 (ja) サーバ装置及び検索方法
JP2008257277A (ja) 文書処理装置、方法、及びプログラム
JP2007183849A (ja) 文書処理装置
JP4719743B2 (ja) グラフ処理装置

Legal Events

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

Ref document number: 2007553980

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 12160709

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07706782

Country of ref document: EP

Kind code of ref document: A1