JP2006163820A - Data converter - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To obtain a data converter for realizing the reduction of the memory usage and a high speed data conversion processing by direct access to data. <P>SOLUTION: The data converter comprises a pre-conversion data structure pattern designation storage part 101 for storing pre-conversion data structure pattern designation including a structure pattern, which expresses the structure of pre-conversion data as the combination of basic structure patterns, and a tag structure, which expresses the parent relation of a tag of the pre-conversion data; a reading processing performing part 105 for determining the number of dimensions of data storage arrays to store the terminal element data value of the pre-conversion data, based on the structure pattern and the tag structure, and generating a processing to store the data value of a terminal element in the data storage arrays; a conversion instruction storage part 103 for storing a conversion instruction where a conversion rule to convert the pre-conversion data is described; and a conversion processing execution part 106 for processing the data value of the terminal element of the pre-conversion data, which is stored in the data storage arrays, in response to the conversion instruction and outputting the value as the post-conversion data. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a data conversion apparatus for structured documents.

  With the development of information systems, there is an increasing demand for exchanging and sharing data held in various information systems between companies and organizations within the company. In recent years, XML (extensible Markup Language) established by W3C (World Wide Web Consortium) has been actively used as one of the standard formats of data used to satisfy such requirements. XML is structured to represent data as a text file. The sender's system converts the data having the data structure inside the system into an XML document and sends it, and the receiver's system receives the received XML document. Is converted into a data structure inside the system.

Examples of general data operation API (Application Programming Interface) for XML documents include DOM (Document Object Model) and SAX (Simple API for XML). The DOM converts the entire read XML document into a tree structure (DOM tree) and develops it on the memory. As a result, random access to data becomes possible, and there is an advantage that it is easy to create a data operation program that performs complicated processing. However, DOM has the disadvantages of low processing speed and large memory usage.
On the other hand, SAX reads XML documents in order from the top and sequentially processes the tags and text that appear in the XML document, and has the advantage of high processing speed and low memory usage. However, due to the sequential processing, there is a disadvantage that random access to data cannot be performed and it is difficult to create a data operation program for performing complicated processing.

In addition, a technique for speeding up the data conversion processing of a structured document using these standard APIs and reducing the memory usage has been proposed.
For example, in the conventional structured document conversion method described in Patent Document 1, a structured document to be converted is divided into a key element that is a target of data processing and a non-key element that is not a target of data processing. The contents of the key elements are stored in a structured document in one element in the CSV (Comma Separated Value) format.

Japanese Patent Laying-Open No. 2003-203667 (FIG. 1, pages 5 to 18)

  However, as long as standard APIs such as DOM and SAX are used for reading an XML document, the speed of the reading process is limited by those APIs, and further improvement in the processing speed cannot be realized. Here, reasons for limiting the speed of the reading process are 1) over-spec of standard API, 2) data access performance of DOM, and 3) sequentiality of SAX.

  1) will be described. Standard APIs such as DOM and SAX have many internal variables and processing functions in order to be able to handle all inputs assumed in the XML specification. Further, in the DOM reading process, it is common to perform processes such as index generation for data access in the subsequent stage. However, when viewed from individual conversion target data and conversion processing programs, it is rare that all functions of the standard API are required. For this reason, unnecessary information is held as internal data, which is often over-specification. That is, instead of realizing generalization, the data structure is not necessarily optimal for each target data and data conversion program, and there is a problem that memory efficiency and speed performance are sacrificed.

  Next, 2) will be described. Data access via DOM is basically a search for a tree structure. That is, in order to obtain the data held in the end element, for example, it is necessary to search from the route corresponding to the outermost element of the XML by the depth-first search until a leaf corresponding to the target end element is found. is there. When such processing is performed, there is a problem that the amount of memory used generally increases and processing time is required.

  Next, 3) will be described. SAX is an API that performs sequential processing, and the data manipulation program is not provided with the structure of the entire input data, but is provided only with information about the XML tag that is the processing target at that time. Therefore, for example, when handling an XML document having a repetitive structure in which the same tag appears repeatedly, it is necessary to describe a process for managing the structure of the XML document each time, and there is a problem that the cost of creating a program is high. is there.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a data conversion apparatus that enables direct access to data, and that can reduce memory usage and realize high-speed data conversion processing. And

  The data conversion apparatus according to the present invention stores a pre-conversion data structure pattern specification including a structure pattern expressing the structure of pre-conversion data as a combination of basic structure patterns and a tag structure representing a parent-child relationship of tags of pre-conversion data. Based on the pre-conversion data structure pattern specification storage unit and the pre-conversion data structure pattern specification, the number of dimensions of the data storage array for storing the end element data value of the pre-conversion data is determined, and the end element data value is stored as data. Data based on the pre-conversion data structure pattern specification, the read processing execution unit stored in the array for conversion, the conversion instruction storage unit storing the conversion instruction describing the conversion rules for converting the pre-conversion data into a different data structure A conversion process that processes the data value of the end element of the pre-conversion data stored in the storage array according to the conversion command and outputs it as post-conversion data. Parts are those equipped with.

  According to the present invention, the structure of the pre-conversion data is expressed by a combination of basic structure patterns, and the end element data values are stored in the data storage array according to the structure pattern. It is possible to obtain a data conversion apparatus that can directly access the data value to be processed, and can reduce the memory usage and realize high-speed data conversion.

Hereinafter, various embodiments of the present invention will be described.
Embodiment 1 FIG.
FIG. 1 is a block diagram showing a configuration of a data conversion apparatus 100 according to Embodiment 1 of the present invention. As shown in the figure, the data conversion apparatus 100 includes a pre-conversion data structure pattern designation storage unit 101, a read processing generation unit (read processing execution unit) 102, a conversion instruction storage unit 103, and a conversion processing generation unit (conversion processing execution unit). 104, a read process execution unit 105, and a conversion process execution unit 106. The read processing generation unit 102, the conversion processing generation unit 104, the read processing execution unit 105, and the conversion processing execution unit 106 are obtained by conveniently dividing the processor of the data conversion apparatus 100 according to a program module that controls the operation of the processor. It is.
The pre-conversion data structure pattern designation storage unit 101 and the conversion command storage unit 103 are included in the memory of the data conversion device 100 or an external storage device connected to the data conversion device 100.

Next, the operation will be described.
FIG. 2 is a diagram illustrating an example (DATA1) of XML data before conversion according to the first embodiment. FIG. 3 is a diagram illustrating post-conversion data (DATA2) of the pre-conversion XML data shown in FIG. 2 according to the first embodiment. Hereinafter, a case where DATA1 is converted to DATA2 will be described as an example.

First, the pre-conversion data structure pattern designation stored in the pre-conversion data structure pattern designation storage unit 101 will be described.
The pre-conversion data structure pattern designation describes the structure pattern and tag structure of pre-conversion data.
The tag structure represents a parent-child relationship of tags of pre-conversion data.
The structure pattern represents the structure of the data before conversion as a combination of basic structure patterns. There are two basic structure patterns: a series type (Sequence type, hereinafter referred to as S type) and a repetitive type (Repetition type, hereinafter referred to as R type).
FIG. 4 is a diagram illustrating an example of XML data having an S-type structure pattern. As shown in the figure, the child elements of <Date> are a series of different elements such as <Year> element, <Month> element, and <Day> element.
FIG. 5 is a diagram showing an example of XML data having an R-type structure pattern. As shown in the figure, a child element of <registrant> has a structure in which the same element called <name> element repeats. It has become.

  Arbitrary XML data cannot be expressed only by a combination of S type and R type, but XML data such as a form that is widely used in practice can be generally expressed by a combination of these. For example, as a standard of XML data used in many practical systems for electronic commerce, there is a CII standard-based XML / EDI mapping rule established by the Japan Information Processing Development Corporation Electronic Commerce Promotion Center. FIG. 6 is a diagram showing an example of XML data compliant with this rule. As shown in the figure, in this XML data example, only <JPMGRP> exists as a child element of the highest tag <CII-MSG>. That is, this can be expressed as an S-type with one sequence. There are two child elements of <JPPMGRP>, <JPPMGH> and <JPTRM>, and the series can be expressed by two S types. The child elements of <JPMGH> are a series of <JPC03>, <JPC04>, and the like, which can also be expressed in the S type. <JPC03>, <JPC04>, etc. are terminal elements having no child elements. The child element of <JPTRM> is a series such as <JP27001>, <JP27002>, <JPM>, etc., and is S-type. Of these, the <JPM> element has a repeating <JPMR> element. Therefore, <JPM> is R type. <JPMR> is an S type having a series of <JP27104>, <JP27105>, and <JP27106> as child elements. As described above, this XML data can be expressed only by a combination of the S type and the R type, and has a structure pattern called an SSRS type.

  Here, the structure pattern of the pre-conversion data DATA1 shown in FIG. 2 will be described. Since the child element of the <DATA1> element is a series of <month>, <day>, and <reservation>, it is expressed in S type. The child element of the <reservation> element is a repetition of the <person name> element and is R-type. Further, the child element of the <person name> element is a series of <last name> element and <name> element, and is S-type. Therefore, DATA1 has a structure pattern called SRS type.

FIG. 7 is a diagram illustrating an example in which the data structure pattern specification before conversion of DATA1 is described in XML. As shown in the figure, the pattern attribute of the <Input> tag indicates that the data structure pattern before conversion is the SRS type. In addition, the <person name> element is repeated in the repeat attribute.
As the contents of the <Input> element, a tag structure of pre-conversion data is described. Here, elements described as empty elements such as <month />, <day />, <surname />, and <first name /> are end elements having actual data values in the pre-conversion data. Although FIG. 7 shows an example of description in XML, equivalent information may be described in other formats such as CSV.

Next, an array for storing data will be described. In the S-type and R-type basic structure patterns, the structure of the terminal element can be associated with a one-dimensional array in which the element values are arranged in the element appearance order. For example, the XML data of the S-type structure pattern shown in FIG. 4 can be associated with the one-dimensional array data [i] shown in FIG. Here, the subscript i of the array has a one-to-one correspondence with each element in the S-type structure pattern, and if the subscript of the first element is 1, it has the same value as the appearance order of the elements. Similarly, an R-type structure pattern can be associated with a one-dimensional array.
A case of a structural pattern expressed by a combination of S type and R type will be described. For example, DATA2 shown in FIG. 3 is XML data having an RS type structure pattern, but the two-dimensional array data [i] [j] shown in FIG. 9 is associated with the value of the terminal element of DATA2. Can do. The first subscript i of the array corresponds to the i-th element appearing in the R-type structure pattern, and the second subscript j of the array is the S-type in the i-th element of the R-type structure pattern. This corresponds to the jth element of the structure pattern. When expanding to N combinations of S-type and R-type, the value of the end element can be expressed in association with the N-dimensional array. Therefore, a multidimensional array having a dimension equal to the number of combinations of S type and R type can be used as the data storage array.

  If the structure of the pre-conversion data is fixed length, that is, if the number of series and repetitions within each basic structure pattern is fixed, a multidimensional array can be implemented as a one-dimensional array using a subscript correspondence table. . In addition, a known method for efficiently implementing a multidimensional array such as a list structure for the variable part and a one-dimensional array for the fixed part can be applied.

Next, the operation of the read processing generation unit 102 when the pre-conversion data shown in FIG. 2 and the pre-conversion data structure pattern designation shown in FIG. 7 are input will be described.
The reading process generation unit 102 reads the pre-conversion data and generates a processing program for storing the data value of the end element in the data storage array. The processing contents of the program will be described below.
As described above, in general, an N-dimensional array can be used as an array for storing data with respect to a structure pattern expressed by a combination of S-type and R-type. When the pre-conversion data structure pattern designation shown in FIG. 7 is input, since the pre-conversion data structure pattern is designated as SRS type, the read processing generation unit 102 uses the three-dimensional array data [x] [ y] [z] is used. As for the size of the array, a predetermined upper limit value may be used, or may be determined while ensuring a size actually required for reading data.

  First, a correspondence table of terminal elements and array element names is created based on the tag structure of pre-conversion data specified by the pre-conversion data structure pattern. At this time, the terminal element is expressed by a path including all element names from the highest tag (hereinafter referred to as a root tag) to the terminal element. For example, in FIG. 2, the root tag is <DATA1>, the path for the end element <month /> is / DATA1 / month, and the path for the end element <last name> is / DATA1 / reservation / person name / last name.

FIG. 10 is a flowchart of processing for creating a correspondence table between terminal elements and array element names.
First, variables are initialized (step ST1). The variable to be initialized is d representing the dimension of the three-dimensional array data [x] [y] [z], the path for holding the path, and each dimension of the three-dimensional array data [x] [y] [z]. Index [i] (i = 1, 2, 3). As initial values, 0 is set for d, an empty character string is set for path, and 1 is set for index [i].

Next, one tag of pre-conversion data is read (step ST2). When the pre-conversion data structure pattern designation shown in FIG. 7 is input, since the first tag of the tag structure of the pre-conversion data is <DATA1>, <DATA1> is first read. The read process generation unit 102 performs a process according to the type of the read tag (step ST3). Since <DATA1> is a start tag, the process proceeds to step ST4, and a tag name (in this case, a character string “/ DATA1”) is added to the end of the variable path. Since the initial value of the variable path is an empty character string, the variable path is updated to “/ DATA1”.
Next, the reading process generation unit 102 determines whether or not the tag is a repeated tag (step ST5). Since <DATA1> is not a repeating tag, the process proceeds to step ST7, the value of d is incremented by 1 and updated to 1, and the process returns to step ST2 to read the next tag.

Since the tag <month /> to be read next is an empty element tag, the process proceeds to step ST11, the tag name “/ month” is added to the end of the variable path, and the variable path is set to “/ DATA1 / month”. Furthermore, the array data [index [1]] [index [2]] [index [3]] is added. Here, since index [1], index [2], and index [3] are all 1, data [index [1]] [index [2]] [index [3]] is data [1] [1] [ 1]. Therefore, a pair of “path” / DATA1 / month ”and array element name data [1] [1] [1] is added to the correspondence table.
Next, it is determined whether or not the value of index [d] is a numerical value (step ST12). Since the value of index [1] is 1 and a numerical value, it is increased by 1 to 2 (step ST13), and the process returns to step ST2 to read the next tag.

The tag <day /> to be read next is an empty element tag, and the read processing generation unit 102 operates in the same manner as in the case of the tag <month />. That is, a pair of “path” / DATA1 / day ”and array element name data [2] [1] [1] is added to the correspondence table. Also, the value of index [1] is incremented by 1 and updated to 3, and the process returns to step ST2 to read the next tag.
Since the tag <reserved> to be read next is a start tag, the path is first updated to “/ DATA1 / reserved”. Since <reservation> is not a repetitive tag, the value of d is increased by 1 to 2, and then the process returns to step ST2.

The tag <person name> to be read next is a start tag. First, the path is updated to "/ DATA1 / reservation / person name". Next, since <person name> is a repeating tag, the value of index [2] is set to the letter “i” (step ST6). Finally, after increasing the value of d by 1 to 3, the process returns to step ST2.
The next tag <last name /> to be read is an empty element tag, and a pair of path "/ DATA1 / reservation / person name / surname" and array element name data [3] [i] [1] is added to the correspondence table. . Also, the index [3] value is incremented by 1 and updated to 2. Similarly, for the next tag <name />, a pair of “path” / DATA1 / reservation / person name / name ”and array element name data [3] [i] [2] is added to the correspondence table.

Since the tag </ personal name> to be read next is an end tag, the process proceeds to step ST8, where the tag name and slash at the end are removed from the value of path and updated to "/ DATA1 / reservation". Also, the value of index [3] is decreased by 1 and updated to 1 (step ST9). Also, the value of d is decreased by 1 and updated to 2 (step ST10). Thereafter, the process returns to step ST2.
Since the tag </ reserved> to be read next is an end tag, similarly, the path is updated to “/ DATA1”, the value of index [2] is decreased by 1, and d is updated to 1.
The next tag </ DATA1> is also an end tag, and similarly, the path is updated to "" (empty character string) and d is updated to 0. The read process generation unit 102 completes the process because there is no tag that can be read next. The correspondence table is generated by the above operation. FIG. 11 is a diagram showing a correspondence table between the path of the end element generated by the above-described process and the array element name.

Next, a process of substituting the value of the end element of the read pre-conversion data into the data storage array is performed. FIG. 12 shows a flowchart of this process.
First, variables are initialized (step ST121). The variable to be initialized is a path for holding a path, and an empty character string is set.
Next, one tag or element content (data value) of the pre-conversion data is read (step ST122).
Next, processing according to the type of the read tag or data value is performed (step ST123). When the start tag is read, “/ tag name” is added to the end of the path (step ST124), and the process returns to step ST122 to read the next tag or data value. When the end tag is read, “tag name” and “/” are removed from the end of the path (step ST125). When the data value is read, the array element name corresponding to the path of the element is obtained from the correspondence table (step ST126), and the data value is assigned to the corresponding array element (step ST128). If there is no array element name corresponding to the correspondence table, the process returns to step ST122.
Through the above processing, the value of the terminal element of the pre-conversion data is substituted into the data storage array.

  The read processing generation unit 102 generates a processing program for reading the pre-conversion data as described above and storing the data value of the end element in the data storage array. Since the contents other than the contents of the correspondence table are typical and static, the processing program may be stored in a template in advance.

  Next, the conversion command stored in the conversion command storage unit 103 will be described. FIG. 13 is a diagram showing a conversion command for converting the pre-conversion data shown in FIG. 2 into the post-conversion data shown in FIG. As shown in the figure, the tag structure of the converted data is described as the contents of the <Output> element. The value of the end element is specified by the path for the pre-conversion data. For example, it is specified by path / DATA1 / month and / DATA1 / day that the value of the <month> element and the <day> element of the pre-conversion data is used as the value of the <date> element. Further, the <reserved item> element is repeated by the repeat attribute of the <Output> tag. Although FIG. 13 shows an example of description in XML, equivalent information may be described in other formats such as CSV.

Next, the operation of the conversion processing generation unit 104 when the pre-conversion data shown in FIG. 2, the pre-conversion data structure pattern designation shown in FIG. 7, and the conversion command shown in FIG. 13 are input will be described.
The conversion processing generation unit 104 generates a processing program that reads an array for storing data and generates converted data. Hereinafter, processing contents of the conversion processing program will be described.
First, when the pre-conversion data structure pattern is given from the pre-conversion data structure pattern designation storage unit 101, the end element path of the pre-conversion data shown in FIG. 11 is obtained by the process shown in FIG. Create a correspondence table between and array element names.
Next, the conversion instruction is read from the conversion instruction storage unit 103, and the part other than the path for the pre-conversion data representing the value of the end element is simply output as a character string. The value is output by variable reference.
FIG. 14 is a diagram illustrating an example of a part of a program generated by the conversion processing generation unit 104. FIG. 14 is a description in Java (registered trademark), but other programming languages such as C ++ may be used.

The read process program and the conversion process program generated by the read process generation unit 102 and the conversion process generation unit 104 may be created in advance as a function library, for example.
The read process execution unit 105 reads the pre-conversion data by calling a read process function. The conversion processing execution unit 106 performs conversion of the pre-conversion data by calling a conversion processing function. For example, when the read processing execution unit 105 executes the read processing program generated as described above, the pre-conversion data shown in FIG. 2 is stored in the array data [x] [y] [z].
FIG. 15 is a diagram illustrating values of the array elements after the read process execution unit 105 executes the read process program.
Next, the conversion processing execution unit 106 executes the conversion processing program shown in FIG. 13, thereby generating post-conversion data shown in FIG.

  As described above, according to the first embodiment, based on the pre-conversion data structure pattern designation, the read processing generation unit 102 generates a processing program for storing the pre-conversion data in the data storage array, and the conversion processing generation The unit 104 generates a processing program for generating post-conversion data based on the conversion command and the pre-conversion data structure pattern. As a result, it is possible to realize a conversion process that directly accesses the data value held by the terminal element using the data structure that is optimal for the conversion target data and the conversion process, and it is possible to automatically create a program for the reading process and the conversion process. In addition, since conversion processing can be performed by assigning data to array elements and referring to array elements when executing conversion processing, there is no need to access a storage area of a DOM tree or a DOM tree as in the case of using DOM. There is an effect that data conversion can be performed at high speed by reducing the memory usage.

Embodiment 2. FIG.
FIG. 16 is a block diagram showing the configuration of the data conversion apparatus 200 according to the second embodiment. The same reference numerals as those in FIG. 1 represent the same components.
In the second embodiment, the data conversion apparatus 200 does not include the pre-conversion data structure pattern designation storage unit 101 but includes a structure pattern determination unit 201.

Next, the operation will be described.
The structure pattern discriminating unit 201 analyzes the pre-conversion data and generates a pre-conversion data structure pattern designation. Hereinafter, as an example of the operation for generating the pre-conversion data structure pattern designation shown in FIG. 7 from the pre-conversion data shown in FIG. 2, a method using DOM will be described.

  By using the DOM API, the tree structure (DOM tree) shown in FIG. 17 can be obtained from the pre-conversion data shown in FIG. Since this process is realized by a known DOM tree generation program (DOM parser) such as Xerces, description thereof is omitted. In FIG. 17, the nodes of the tree indicated by squares with rounded corners correspond to the elements of the XML document and are called element nodes. On the other hand, the node of the tree indicated by the square corresponds to the value of the end element and is called a character string node. In addition, a node corresponding to the root of the DOM tree (here, “DATA1” element) is referred to as a root node.

FIG. 18 is a flowchart of the structure pattern analysis process by the structure pattern determination unit 201.
First, the structure pattern determination unit 201 calls a process with the root node “DATA1” as an argument (step ST181). As shown in FIG. 17, the node “DATA1” given as an argument has element nodes as child nodes (step ST182 and step ST183). Further, since the tag names of all the child nodes are different (step ST184), the process is recursively called with each child node as an argument (step ST185). Then, the return value of the process for the child node is set as a list, and the list with the symbol “S” added to the head is set as the return value (step ST186).

When the argument node is a call with “month”, there is no element node in the child node (step ST182). Therefore, the symbol “S” is returned as a return value (step ST190). The same applies to the case where the argument node is “day”, and the symbol “S” is returned as a return value.
On the other hand, when the argument node is “reserved”, the child node has two element nodes (step ST182 and step ST183), but the tag names are the same (step ST184). Therefore, the process is recursively called with only one child node as an argument (step ST187). Then, a return value for the child node is used as a list, and a list with the symbol “R” added to the head is returned as a return value (step ST188).

  In the case of a call with an argument node of “person name”, the child node has an element node (step ST182, step ST183), and the tag names are all different (step ST184). Therefore, the process is recursively called with each child node as an argument (step ST185). When the argument node is a call with “last name”, there is no element node in the child node (step ST182, step ST183). Therefore, the symbol “S” is returned as a return value (step ST190). The same applies when the argument node is “name”.

  As a result of calling the processing with the root node as an argument by the above processing, a list composed of symbols S and R shown in FIG. 19 is obtained. Since the S type is a series of different tag names, even if the S types are nested and continuous, they can be regarded as one S type as a whole. Therefore, the structure shown in FIG. 2 is obtained by performing flattening to remove all parentheses from the list shown in FIG. 19 and reducing the continuous symbol S to one S, thereby obtaining the structure pattern SRS of the pre-conversion data shown in FIG.

Next, as an example of processing for analyzing the tag structure of pre-conversion data, a method using the DOM tree shown in FIG.
FIG. 20 is a flowchart of tag structure analysis processing by the structure pattern determination unit 201.
First, the structure pattern determination unit 201 calls a process with the root node “DATA1” as an argument (step ST201). The node “DATA1” given by the argument has an element node as a child node (step ST202, step ST203). Further, since the tag names of all child nodes are different (step ST204), this process is recursively called with each child node as an argument (step ST205). A character string concatenating the return values of the processes for the child nodes is generated (step ST206), and the character string “<DATA1>” is added to the beginning and the character string “</ DATA1>” is added to the end to obtain a return value ( Step ST207).

When the argument node is called “month”, there is no element node in the child node. Therefore, the character string “<month />” is returned as a return value (step ST211). Similarly, when the argument node is “day”, the character string “<day />” is returned as a return value.
On the other hand, when the argument node is “reserved”, the child node has two element nodes (step ST202 and step ST203), but the tag names are the same (step ST204). Therefore, the process is recursively called with only one child node as an argument (step ST208). A character string in which “<reservation>” is added to the beginning of the return value for the child node and “</ reservation>” is added to the end is used as the return value (step ST209). In addition, it is recorded that “reservation” is a repetitive element.

In the case of a call with an argument node of “person name”, the child node has an element node and all have different tag names. Therefore, the process is recursively called with each child node as an argument (step ST205). A character string in which “<person name>” is added to the beginning of the return value for the child node and “</ person name>” is added to the end is used as the return value (step ST207). When the argument node is a call with “last name”, the child node has no element node. Therefore, the character string “<last name />” is returned as a return value (step ST211). The same applies when the argument node is “name”.
Through the above processing, the character string shown in FIG. 21 is obtained as a result of calling the processing of FIG. 20 with the root node as an argument.

  The structure pattern determination unit 201 generates a pre-conversion data structure pattern designation shown in FIG. 7 from the results of the structure pattern analysis process and the tag structure analysis process. In the second embodiment, DOM is used for the structure pattern analysis process and the tag structure analysis process. However, other APIs such as SAX may be used.

  The data conversion apparatus 200 performs pre-conversion data read processing and conversion processing using the pre-conversion data structure pattern designation generated by the structure pattern determination unit 201. Since the reading process and the conversion process are the same as those in the first embodiment, description thereof is omitted.

  As described above, according to the second embodiment, the structure pattern discriminating unit 201 analyzes the pre-conversion data and automatically generates the pre-conversion data structure pattern designation, so that the pre-conversion data is manually analyzed. Thus, there is an effect that it is not necessary to generate the structure pattern designation.

Embodiment 3 FIG.
FIG. 22 is a block diagram showing the configuration of the data conversion apparatus 300 according to the third embodiment. The same reference numerals as those in FIG. 1 or 16 represent the same components. In the third embodiment, the data conversion apparatus 300 includes a pre-conversion data schema storage unit 301.

Next, the operation will be described.
The pre-conversion data schema storage unit 301 stores a schema description for defining the structure of pre-conversion data. FIG. 23 is a diagram illustrating an example of a schema description for the pre-conversion data illustrated in FIG. This schema description is called DTD (Document Type Definition), is defined by W3C (World Wide Web Consortium), which is a standardization organization, and is most commonly used as a schema description of an XML document.
In the figure, a description that starts with “<! ELEMENT” and ends with “>”, such as “<! ELEMENT DATA1 (month, day, reservation)>” is called an element type declaration. The part “DATA1” is called an element name, and the part “(month, day, reservation)” is called a content model. The content model defines that the element “DATA1” has three child elements “month”, “day”, and “reservation”, that is, a nested tag structure. “*” Specified after “person name” means that the “person name” element appears any number of times. The contents of the elements “month”, “day”, “last name”, and “first name” are defined as a character string by “(#PCDATA)”. That is, these are end elements that do not have child elements. Further, “<! DOCTYPE DATA1” in the start line defines that the start element is “DATA1”.

The structure pattern determination unit 201 refers to the schema description of the pre-conversion data in the pre-conversion data schema storage unit 301 and generates a pre-conversion data structure pattern designation.
Hereinafter, an example of generating the pre-conversion data structure pattern designation of FIG. 7 based on the schema description shown in FIG. 23 will be described. Processing is roughly divided into a process of generating a DOM tree representing the tag structure of pre-conversion data from the schema description and a process of generating the pre-conversion data structure pattern specification by analyzing the obtained DOM tree.
FIG. 24 is a flowchart of the former process. Further, the latter process is the same as that of the second embodiment, and the description thereof is omitted. Note that the example shown in FIG. 24 includes only processing for the DTD content model, and does not include processing for other content models. However, it is easy to add them, and since only the necessary processing is described from the schema description of FIG. 23 to the description of the generation processing of the pre-conversion data structure pattern specification of FIG.

First, since the structure pattern discriminating unit 201 knows that the start element is “DATA1” from the schema description, it generates a node having the tag name “DATA1” as a root node. Then, the DOM tree generation process shown in FIG. 24 is called with the root node as an argument (step ST241).
Next, since the tag name of the node given by the argument is “DATA1”, the corresponding element type declaration is referred from the schema description, and “(month, day, reservation)” is acquired as the content model (step ST242). ).
Next, processing is performed on the “month” of the content model. Since “month” is an element, a node whose tag name is “month” is newly generated and registered as a child node of the root node (step ST243 to step ST245). Next, the process of FIG. 24 is recursively called with the newly generated node as an argument (step ST246).

  When the process is called with the node having the tag name “month” as an argument, “(#PCDATA)” is acquired as the content model of the element “month” from the element type declaration for “month” in the schema description. Since this is not an element but a character string, steps ST245 to 246 are not performed (step ST244).

Next, a new node is also generated for the “day” of the content model, and the process of FIG. 24 is recursively called. The calling process for the node “day” is the same as that for the node “month”.
Next, a new node is generated for the “reservation” of the content model and registered as a child node of the root node, and the process of FIG. 24 is recursively called with the generated node as an argument.

  When the process is called with a node having the tag name “reserved” as an argument, “(person name *)” is obtained as the content model of the element “reserved” from the element type declaration for “reserved” in the schema description. Since “person name” is an element, a new node is generated and registered as a child node of the node “reservation”, and the process of FIG. 24 is recursively called with the generated node as an argument. Thereafter, the DOM tree shown in FIG. 25 is finally obtained by repeating the process recursively in the same manner. When the DOM tree is obtained, the pre-conversion data structure pattern designation of FIG. 7 is generated by the same processing as in the second embodiment shown in FIGS.

In the above description, an example using DTD as the schema description has been described, but other schema description methods such as an XML schema defined by the W3C may be used.
The data conversion apparatus 300 performs pre-conversion data reading processing and conversion processing using the pre-conversion data structure pattern designation generated by the structure pattern determination unit 201. Since the reading process and the conversion process are the same as those in the first embodiment, description thereof is omitted.

  As described above, according to the third embodiment, the structure pattern determination unit 201 automatically generates the pre-conversion data structure pattern designation from the schema description stored in the pre-conversion data schema storage unit 301. There is an effect that it is not necessary to manually analyze the schema description and generate a structure pattern specification. In addition, there is an effect that even when there is no actual sample of pre-conversion data and only the schema description is given, the reading process and the conversion process can be generated.

Embodiment 4 FIG.
FIG. 26 is a block diagram showing a configuration of a data conversion apparatus 400 according to the fourth embodiment. The same reference numerals as those in FIG. 1 represent the same components. In the fourth embodiment, the data conversion apparatus 400 includes a conversion command generation unit 401, a post-conversion data schema storage unit 402, and a terminal element conversion command storage unit 403.

Next, the operation will be described.
The terminal element conversion command storage unit 403 stores terminal element conversion commands. The terminal element conversion command is a correspondence table between a tag name of the terminal element of the converted data and a path indicating the pre-conversion data used as the value of the terminal element. FIG. 27 is a diagram illustrating an example of a terminal element conversion command. For example, the end element “date” of the converted data means that a value specified by the paths “/ DATA1 / month” and “/ DATA1 / day” with respect to the data before conversion is used.

  The post-conversion data schema storage unit 402 stores a schema representing the structure information of post-conversion data. FIG. 28 is a diagram illustrating an example in which a schema of converted data is described by the DTD described in the third embodiment.

  The conversion command generation unit 401 generates a conversion command based on the end element conversion command and the converted data schema. Since the process of the conversion instruction generation unit 401 is performed prior to the generation of the conversion process by the conversion process generation unit 104, it may be realized using, for example, DOM. The basic processing flow is to generate a DOM tree from DTD, output the element name from the root (root node) of the DOM tree corresponding to the start element, tracing the tree with depth priority, and convert as shown in FIG. Generate instructions.

  Hereinafter, the terminal element conversion instruction shown in FIG. 27 and the converted data schema shown in FIG. 28 will be described as examples with reference to FIG. First, a node of the DOM tree for the start element “DATA2” is generated (FIG. 29 “DATA2”). This becomes the root node. Next, referring to the element type declaration for the element “DATA2”, since the child element is “reserved item”, the node of the DOM tree for “reserved item” is generated as a child node of the root node as shown in the figure. . Since “reserved item” is designated as a repeated element, the element name “reserved item” is recorded as the value of the repeat attribute of the root node. Similarly, nodes for “date” and “name” are generated as child nodes of “reservation item”. The “date” element is a terminal element having no child elements. From the terminal element conversion command of FIG. 27, the path for the pre-conversion data for the “date” element is “/ DATA1 / month / DATA1 / day”, so a node having this character string as a value is generated and the “date” element Register as a child node of the node for. The same processing is performed for the “name” element, and finally the DOM tree shown in FIG. 29 is obtained.

The conversion command generation unit 401 converts the generated DOM tree into an XML character string. As a specific conversion process, as described above, the element name and the value of the terminal element held in each node may be sequentially output while tracing the tree from the root node with depth priority. Alternatively, a processing system in which an LS Serializer interface for writing a DOM tree as an XML character string, which is defined in DOM Level 3 Load and Save, which is a DOM standard API defined in W3C, may be used. In any method, there is a known process for converting a DOM tree into an equivalent XML character string. In the above description, an example using DTD as the schema description has been described, but other schema description methods such as an XML schema defined by the W3C may be used.
The conversion processing generation unit 104 generates a conversion processing program using the conversion instruction generated by the conversion instruction generation unit 401. Since the contents of the conversion processing program and the reading process are the same as those in the first embodiment, description thereof is omitted. The pre-conversion data structure pattern designation may be generated by the structure pattern determination unit 201 as in the second or third embodiment.

As described above, according to the fourth embodiment, the terminal element conversion instruction is stored in the terminal element conversion instruction storage unit 403, and the structure information schema of the converted data is described in the converted data schema storage unit 402. Since the conversion command generation unit 401 generates a conversion command based on the terminal element conversion command and the post-conversion data schema, when the structure of the post-conversion data is given by the schema, only the correspondence relationship of the terminal element is obtained. By defining, conversion processing can be performed, and there is an effect that it is not necessary to manually create a specific conversion instruction from the schema.
Further, by changing the schema, it is possible to obtain an effect that the structure of the converted data can be arbitrarily changed while maintaining the correspondence of the end elements.

Embodiment 5. FIG.
FIG. 30 is a block diagram showing a configuration of a data conversion apparatus 500 according to the fifth embodiment. The same reference numerals as those in FIG. 1 represent the same components.
In the fifth embodiment, the data conversion apparatus 500 includes a process selection unit 501, a process storage unit 502, a process generation activation unit 503, and a structure pattern / conversion command storage unit 504.

Next, the operation will be described.
The structure pattern / conversion command storage unit 504 stores the pre-conversion data structure pattern specification stored in the pre-conversion data structure pattern specification storage unit 101 according to the first embodiment and the conversion command stored in the conversion command storage unit 103. A plurality of sets (hereinafter referred to as read / conversion designation) are stored. An example is shown in FIG. In the read / conversion specification, a combination of a pre-conversion data structure pattern specification and a conversion instruction is described in a child element <RULE> of the element <TRANS>. The read / conversion specification shown in FIG. 31 includes two <RULE> elements. The first <RULE> element includes the pre-conversion data structure pattern specification shown in FIG. 7 and the conversion instruction shown in FIG. A set is described.

The process generation activation unit 503 reads the read / conversion specification from the structure pattern / conversion instruction storage unit 504, supplies the pre-conversion data structure pattern specification during the read / conversion specification to the read process generation unit 102, and converts the conversion instruction into a conversion process. This is supplied to the generation unit 104.
The read process generation unit 102 generates a read process program by the same operation as in the first embodiment, and returns the generated read process program to the process generation start unit 503.
Also, the conversion processing generation unit 104 generates a conversion processing program by the same operation as that of the first embodiment, and returns the generated conversion processing program to the processing generation start unit 503.
The process generation start unit 503 assigns a set of the read process program and the conversion process program to the read / conversion specification and outputs the read / converted program to the process storage unit 502.
At this time, the read processing program for the pre-conversion data structure pattern specification included in the first <RULE> element in the read / conversion specification shown in FIG. 31 is stored in a file named parser1, and the conversion processing program for the conversion command is executed. It is assumed that the file is stored in a file named “translator1”. In addition, the read processing program for the pre-conversion data structure pattern specification included in the second <RULE> element of FIG. 31 is stored in a file named parser2, and the conversion processing program for the conversion instruction is stored in a file named translator2. Suppose. In this case, as shown in FIG. 32, the process generation activation unit 503 designates the file name in which the generated process program is stored with the parser attribute and the translator attribute of the <RULE> element, and outputs them to the process storage unit 502 To do.
The process storage unit 502 stores a read / conversion specification to which a file name is added by the process generation activation unit 503, a read process program, and a file of the conversion process program.

The processing selection unit 501 acquires a processing program corresponding to the input pre-conversion data structure pattern designation from the processing storage unit 502 when performing the conversion processing of the pre-conversion data. For example, when the pre-conversion data structure pattern specification shown in FIG. 7 is input, it can be seen from the read / conversion specification shown in FIG. 32 that the read processing program is held as parser1 and the conversion processing program is held as a file called translator1. Therefore, the process selection unit 501 reads the processing programs stored in these files and supplies them to the process execution unit 105 and the conversion process execution unit 106.
The pre-conversion data structure pattern designation input to the process selection unit 501 may be supplied from the pre-conversion data structure pattern designation storage unit 101 as in the first embodiment, or may be the second embodiment or the second embodiment. 3 may be generated by the structure pattern determination unit 201.

  As described above, according to the fifth embodiment, the structure pattern / conversion instruction storage unit 504 holds the structure pattern of the pre-conversion data, the tag structure, and the conversion instruction as a set, and the process generation activation unit 503 performs the read process. The reading processing program and the conversion processing program generated by the generation unit 102 and the conversion processing generation unit 104 are output as a set, the processing storage unit 502 stores the reading processing program and the conversion processing program, and the processing selection unit 501 Since the read processing program and conversion processing program corresponding to the pre-conversion data structure pattern specification are selected, by preparing multiple read / conversion specifications in advance, for pre-conversion data with different structure patterns The conversion process can be executed by dynamically selecting a process according to the pre-conversion data.

It is a block diagram which shows the structure of the data converter by Embodiment 1 of this invention. It is a figure which shows the example of the XML data before conversion by Embodiment 1 of this invention. It is a figure which shows the data after conversion of the XML data before conversion shown in FIG. 2 by Embodiment 1 of this invention. It is a figure which shows an example of the XML data with an S type structure pattern by Embodiment 1 of this invention. It is a figure which shows an example of the XML data with an R type structure pattern by Embodiment 1 of this invention. It is a figure which shows the example of the XML data based on this rule by Embodiment 1 of this invention. It is a figure which shows the example which described the data structure pattern designation | designated before conversion by XML by Embodiment 1 of this invention. It is a figure which shows the example of the data storage arrangement | sequence by Embodiment 1 of this invention. It is a figure which shows the example of the data storage arrangement | sequence by Embodiment 1 of this invention. It is a flowchart of the creation process of the correspondence table of the end element and the array element name according to the first embodiment of the present invention. It is a figure which shows the example of the corresponding | compatible table of the path | route of an end element, and an array element name by Embodiment 1 of this invention. It is a flowchart of the process by which the value of the terminal element of the data before conversion is substituted to an array by Embodiment 1 of this invention. It is a figure which shows the example of the conversion command by Embodiment 1 of this invention. It is a figure which shows the example of the program produced | generated by the conversion process production | generation part by Embodiment 1 of this invention. It is a figure which shows the example of the value of the array element after performing the reading process program in the reading process execution part by Embodiment 1 of this invention. It is a block diagram which shows the structure of the data converter by Embodiment 2 of this invention. It is a figure which shows the example of the DOM tree produced | generated based on the data before conversion by Embodiment 2 of this invention. It is a flowchart of the structure pattern analysis process by the structure pattern discrimination | determination part by Embodiment 2 of this invention. It is a figure which shows the example of the list | wrist obtained by the structure pattern analysis process by Embodiment 2 of this invention. It is a flowchart of the tag structure analysis process by the structure pattern discrimination | determination part by Embodiment 2 of this invention. It is a figure which shows the example of the list | wrist obtained by the tag structure analysis process by Embodiment 2 of this invention. It is a block diagram which shows the structure of the data converter by Embodiment 3 of this invention. It is a figure which shows the example of the schema description with respect to the data before conversion by Embodiment 3 of this invention. It is a flowchart of the process which produces | generates the DOM tree showing the tag structure of the data before conversion from the schema description by Embodiment 3 of this invention. It is a figure which shows the example of the DOM tree obtained by the process which produces | generates the DOM tree showing the tag structure of the data before conversion from schema description by Embodiment 3 of this invention. It is a block diagram which shows the structure of the data converter by Embodiment 4 of this invention. It is a figure which shows an example of the terminal element conversion command by Embodiment 4 of this invention. It is a figure which shows the example which described the schema of the data after conversion by DTD by Embodiment 4 of this invention. It is a figure explaining the conversion command production | generation process by Embodiment 4 of this invention. It is a block diagram which shows the structure of the data converter by Embodiment 5 of this invention. It is a figure which shows the example of the read / conversion designation | designated memorize | stored in the structure pattern and conversion command memory | storage part by Embodiment 5 of this invention. It is a figure which shows the example of the read / conversion designation | designated by which the processing program file name was described as an attribute by Embodiment 5 of this invention.

Explanation of symbols

  100, 200, 300, 400, 500 Data conversion device, 101 Pre-conversion data structure pattern designation storage unit, 102 Read processing generation unit (read processing execution unit), 103 Conversion instruction storage unit, 104 Conversion processing generation unit (Conversion processing execution) Part), 105 reading process execution part, 106 conversion process execution part, 201 structure pattern determination part, 301 pre-conversion data schema storage part, 401 conversion instruction generation part, 402 post-conversion data schema storage part, 403 terminal element conversion instruction storage part , 501 Process selection unit, 502 Process storage unit, 503 Process generation start unit, 504 Structure pattern / conversion command storage unit.

Claims (5)

A data conversion device for converting a structured document into a different data structure,
Pre-conversion data structure pattern specification storage unit for storing a pre-conversion data structure pattern specification including a structure pattern expressing the structure of pre-conversion data as a combination of basic structure patterns and a tag structure representing a parent-child relationship of the tags of the pre-conversion data When,
Based on the pre-conversion data structure pattern specification, the number of dimensions of the data storage array for storing the terminal element data value of the pre-conversion data is determined, and the data value of the terminal element is read into the data storage array A process execution unit;
A conversion instruction storage unit for storing a conversion instruction describing a conversion rule for converting the pre-conversion data into the different data structure;
Based on the pre-conversion data structure pattern specification, a conversion processing execution unit that processes the data value of the terminal element of the pre-conversion data stored in the data storage array according to the conversion command and outputs the data as post-conversion data Data converter.   2. The data conversion apparatus according to claim 1, further comprising a structure pattern discriminating unit that analyzes the pre-conversion data and generates a pre-conversion data structure pattern designation.   3. The data conversion apparatus according to claim 2, wherein the structure pattern determination unit generates a pre-conversion data structure pattern designation based on the schema information of the pre-conversion data. A terminal element conversion instruction storage unit that stores the correspondence of terminal elements between pre-conversion data and post-conversion data;
A post-conversion data schema storage unit that stores schema information of the post-conversion data;
The conversion command generation unit that generates a conversion command based on the correspondence relationship between the terminal elements and the schema information of the converted data is provided. Data converter. Based on the pre-conversion data structure pattern specification, the number of dimensions of the data storage array for storing the end element data value of the pre-conversion data is determined, and the read process for storing the end element data value in the data storage array A load generation unit for generating a program;
A conversion processing program for processing the data value of the terminal element of the pre-conversion data stored in the data storage array according to the conversion command based on the pre-conversion data structure pattern specification and outputting as the post-conversion data A conversion processing generation unit to generate,
A structure pattern / conversion instruction storage unit for storing a plurality of combinations of the pre-conversion data structure pattern designation and the conversion instruction;
The pre-conversion data structure pattern designation is acquired from the structure pattern / conversion command storage unit and supplied to the read processing generation unit, the conversion command is acquired and supplied to the conversion processing generation unit, and the read processing generation is performed. A process of adding the read processing program acquired from the conversion unit and the conversion processing program acquired from the conversion generation unit to the combination of the pre-conversion data structure pattern specification and conversion command acquired from the structure pattern / conversion command storage unit and outputting the combination Generation starter;
A process storage unit for storing an output result of the process generation start unit;
With reference to the processing storage unit, the reading processing program and the conversion processing program corresponding to the pre-conversion data structure pattern specification specified during the conversion processing are acquired from the processing storage unit, and the reading processing execution unit and the conversion processing execution unit respectively A process selection unit to supply,
The read processing execution unit and the conversion processing execution unit execute the read processing program and the conversion processing program supplied from the processing selection unit, respectively. The data converter described.

Images