JP2009059215A - Structured document processor, and structured document processing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technique enabling to deal with a plurality of kinds of formats of XML documents, by one application, and further to provide a technique for dealing efficiently with a binary XML of document described by encoding in response to a data format. <P>SOLUTION: The XML document is analyzed by either of a text XML parser 105 or a binary XML parser 106, in response to the format of the XML document. A format corresponding application 111 receives a request for acquiring an element described in the XML document, according to an assigned format. The format corresponding application 111 outputs the element to a requesting side, when the analyzed format is consistent with the assigned format, and outputs the element after converted into the assigned format, to the request source, when the analyzed format is not consistent with the assigned format. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a technique for processing a structured document.

  Currently, XML (Extensible Markup Language: http://www.w3.org/TR/2004/REC-xml-20040204/) is used as a format of various data handled on a computer. XML has a feature that it does not depend on a computer or an operating system. This facilitates communication between different types of computers and devices on the network, and is particularly widespread as communication data on the network.

  Recently, various devices other than personal computers and servers such as mobile phones, copiers, and digital cameras have been networked. For this reason, these devices are increasingly handling XML.

  Under such circumstances, the processing speed and efficiency of XML become a big problem. Since the XML format is not a format that prioritizes the improvement of the processing speed, it takes time for the analysis process. Moreover, since the description has redundancy, the data size becomes large. These problems become a serious problem in small devices with a slow processing speed and a small memory resource. Further, even if a device having many resources such as a server is used, when processing a very large number of XML documents, the XML analysis time is a big problem.

  Therefore, a format that is semantically equivalent to the XML format and capable of more efficient processing has been used. Such a format is generally called “binary XML”. On the other hand, XML in a text format according to the XML specification is referred to as “text XML” in this specification.

  There are several binary XML format specifications. Many formats attempt to reduce size and increase processing efficiency by eliminating redundancy and performing encoding according to the data type.

  Eliminating redundancy means omitting end tag names or replacing character strings such as frequently appearing element names, attribute names, and attribute values with integers. Since the end tag must have the same name as the start tag described immediately before, the name of the end tag can be omitted. For example, in an XHTML document containing many images, the character string “img” frequently appears. The document size is reduced by replacing these frequent character strings with integers as small as possible.

  Encoding according to the data type is to change the encoding method for element contents, attribute values, etc., according to the type (integer, float, date, etc.). For example, in text XML, even if “12345” in the element <x> 12345 </ x> represents the integer 12345, it is described as a character string “12345” in the document. Therefore, when the character encoding of the document is UTF-8, the data is 0x30, 0x31, 0x32, 0x33, 0x45.

  Thus, since the format described in the XML document is different from the format to be handled inside the computer, the format must be converted when the XML document is read and processed inside the computer. For example, when an integer is handled with 4 bytes of big endian inside a structured document processing apparatus, the integer 12345 becomes a byte string of 0x00, 0x00, 0x30, and 0x2E. This type of conversion takes a lot of time, especially for floating point numbers.

  On the other hand, in binary XML, integers and floating point values are described in the same format as the format handled inside the computer. For this reason, it is not necessary to convert the format, and processing can be performed at higher speed.

  As an example of performing redundancy removal by indexing and encoding according to the data type, Fast Infoset (ITU-T Rec. X.891 | ISO / IEC24824-1) can be given.

  When handling binary XML, it is usual to use an analyzer dedicated to binary XML data (hereinafter referred to as a binary XML parser). Further, the interface of the binary XML parser is often the same as that of the text XML parser. This is because by arranging the interfaces, it is possible to correspond to the binary XML parser without modifying the application that uses the text XML parser. As a binary XML parser having the same interface as the text XML parser, Sun Microsystems Inc. There is a parser for Fast Infoset Project.

Patent Document 1 describes that data conversion is performed so that data can be processed by either a system using XML data or a system using legacy file data.
Fast Infoset Project (https: ///fi.dev.java.net/) JP 2004-318420 A

  However, the binary XML parser having the same interface as the text XML parser has a drawback that it cannot take advantage of the binary XML format that performs encoding according to the data type.

  This is because, in the text XML parser interface, all data is transferred as a character string type, so if the interface is the same, only character string type data can be handled. For this reason, even if there is IEEE 754 format floating point data in the binary XML document, the binary XML parser converts it to a character string type and passes it, and further, the application converts it back to the IEEE 754 format. .

  If the interface of the binary XML parser is different from that of the text XML parser, the binary XML parser application cannot handle the text XML parser. That is, a problem that the text XML document cannot be handled occurs.

  The present invention has been made in view of the above problems, and an object of the present invention is to provide a technique for making it possible to handle XML documents of a plurality of formats in one application.

  It is another object of the present invention to provide a technique for efficiently handling a binary XML document described in an encoding according to a data type.

  In order to achieve the object of the present invention, for example, a structured document processing apparatus of the present invention comprises the following arrangement.

That is, a structured document processing apparatus for processing a structured document,
An acquisition means for acquiring the format of the structured document;
Analysis means for analyzing the structured document by an analysis method according to the format acquired by the acquisition means;
Means for receiving a request for acquiring an element described in the structured document in a specified type;
Determining means for determining whether or not the type analyzed by the analyzing means for the element matches the specified type;
When the determination means determines that they match, the element is output to the request source. When the determination means determines that they do not match, the element type is converted to the specified type. And an output means for outputting the element to the request source.

  In order to achieve the object of the present invention, for example, the structured document processing method of the present invention comprises the following arrangement.

That is, a structured document processing method performed by a structured document processing apparatus that processes a structured document,
An acquisition process for acquiring the format of the structured document;
In the analysis method according to the format acquired in the acquisition step, an analysis step of analyzing the structured document;
Receiving a request for acquiring an element described in the structured document in a specified type;
A determination step for determining whether or not the type analyzed in the analysis step for the element matches the designated type;
If it is determined in the determination step that the elements match, the element is output to the request source. If it is determined in the determination step that the elements do not match, the element type is converted to the specified type. And an output step for outputting the element to the request source.

  According to the configuration of the present invention, it is possible to handle XML documents of a plurality of formats in one application.

  Furthermore, it is possible to efficiently handle a binary XML document described in an encoding according to the data type.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[First Embodiment]
FIG. 1 is a block diagram illustrating a hardware configuration example of a computer applicable to the structured document processing apparatus according to the present embodiment. Note that the configuration of the apparatus applicable to the structured document processing apparatus according to the present embodiment is not limited to the configuration illustrated in FIG. 1, and various modifications can be considered by those skilled in the art. Further, the structured document processing apparatus according to the present embodiment is not limited to being realized by a single apparatus, and the structured document processing apparatus according to the present embodiment is realized by a cooperative operation by a plurality of apparatuses. You may let them. In this case, a plurality of devices are connected via a network such as a LAN.

  In FIG. 1, a CPU 101 controls the entire computer 100 using programs and data stored in a ROM 102 and a RAM 103, and executes each process described later as what the computer 100 performs.

  The ROM 102 stores setting data of the computer 100, a boot program, data of parameters that do not need to be changed, and the like.

  The RAM 103 has an area for temporarily storing programs and data loaded from the storage device 104, data received from the outside via the network interface 150, and the like. Furthermore, the RAM 103 also has a work area used when the CPU 101 executes various processes.

  The storage device 104 is a large-capacity information storage device represented by a hard disk drive device. The storage device 104 stores an OS (operating system) and programs and data for causing the CPU 101 to execute each process described later that is executed by the computer 100. The storage device 104 stores data of an XML document as a structured document to be processed later, as a file. Programs and data stored in the storage device 104 are appropriately loaded into the RAM 103 under the control of the CPU 101 and are processed by the CPU 101.

  Below, each software preserve | saved at the memory | storage device 104 is demonstrated.

  When the text XML parser 105 receives an analysis request for a text-format XML document (hereinafter referred to as a text XML document), the text XML parser 105 performs an analysis process on the XML document and returns the result.

  When the binary XML parser 106 receives an analysis request for an XML document in a binary format (hereinafter referred to as a binary XML document), the binary XML parser 106 performs an analysis process on the XML document and returns the result.

  When the data type conversion unit 107 designates three types, the data type before conversion, the data type after conversion, and the conversion target data, the data type conversion unit 107 converts the type of the conversion target data into the type after conversion and returns it.

  The format discrimination unit 108 discriminates the format of given data.

  The common XML parser 109 implements analysis processing of text XML documents and binary XML documents by using the text XML parser 105 and the binary XML parser 106 properly.

  The legacy application 110 performs processing using an API (Application Programming Interface) of the text XML parser 105.

  The type corresponding application 111 performs processing using the API of the common XML parser 109. The legacy application 110 and the type-compatible application 111 both function as services that process XML documents received from the network.

  The processing realized by each software described as being stored in the storage device 104 will be described later.

  The network interface 150 is for connecting the computer 100 to a LAN, the Internet, or the like, and the computer 100 can perform data communication with an external device via the network interface 150.

  A bus 112 connects the above-described units.

  FIG. 2 is a diagram illustrating a configuration example of a network to which the computer 100 is applied.

  As shown in FIG. 2, a computer 100 is connected to a network 201 as a server. The network 201 is configured by a LAN, the Internet, or the like. Reference numerals 202 and 203 denote client terminals, which are connected to the network 201.

  Here, it is assumed that the client terminal 202 generates a binary XML document and transmits the generated binary XML document to the computer 100. On the other hand, the client terminal 203 generates a text XML document and transmits the generated text XML document to the computer 100.

  Next, the API of the text XML parser 105 will be described with reference to FIG. FIG. 3 is a diagram illustrating an example of the API of the text XML parser 105.

  “SetDocument” is a function for opening an XML document to be analyzed.

  “Read” is a function for reading one node from the beginning of the XML document to be analyzed. Here, a node is a unit that constitutes an XML document, and includes a start tag (StartElement), an end tag (EndElement), an element content (Content), and the like.

  “GetNodeType” is a function for returning the type (node type) of the currently referenced node, and returns a value such as “StartElement” or “EndElement”.

  “GetName” is a function for returning the name of the currently referenced node. In other words, if the currently referenced node is a start tag, the tag name of the start tag is returned.

  “GetValue” is a function for returning the value of the currently referenced node. That is, when the currently referenced node is “Content”, the content of the element is returned. Since all text XML documents are described in a text format, the return value of “GetValue” is also a string type.

  “Close” is a function for ending the analysis processing and releasing the reserved memory resources.

  Next, the API of the binary XML parser 106 will be described with reference to FIG. FIG. 4 is a diagram illustrating an example of the API of the binary XML parser 106.

  The functions “SetDocument”, “Read”, “GetNodeType”, “GetName”, and “Close” are the same as those shown in FIG. 3, and the description thereof is also as described above. That is, these functions play the same role as the API of the same name in the text XML parser 105. However, the function for obtaining the value of the node is greatly different between the text XML parser 105 and the binary XML parser 106.

  “GetValueType” is a function for returning the value type of the currently referenced node. For example, if the value of the currently referenced node is described as an integer value in the binary XML document, “int” is returned, and if it is described as a floating point number, “double” is returned.

  “GetStringValue” is a function for acquiring the value of the currently referenced character string type node.

  “GetIntValue” is a function for obtaining the value of the currently referenced integer type node.

  “GetDoubleValue” is a function for acquiring the value of the currently referenced floating-point node.

  That is, the API of the binary XML parser 106 returns the value of the currently referenced node in the type described in the XML document.

  Next, the API of the common XML parser 109 will be described with reference to FIG. FIG. 5 is a diagram illustrating an example of the API of the common XML parser 109.

  The functions “SetDocument”, “Read”, “GetNodeType”, “GetName”, and “Close” are the same as those shown in FIG. 3, and the description thereof is also as described above. That is, these functions play the same role as the API of the same name of the text XML parser 105 and the binary XML parser 106.

  “GetValueAsString” is a function that acquires the value of the currently referenced node as a character string.

  “GetValueAsInt” is a function that acquires the value of the currently referenced node as an integer.

  “GetValueAsDouble” is a function that acquires the value of the currently referenced node as a floating-point number type.

  Next, the operation of the computer 100 when processing an XML document having the configuration illustrated in FIG. 6 will be described. FIG. 6 is a diagram illustrating a configuration example of an XML document as a processing target by the computer 100. The XML document having the configuration shown in FIG. 6 is personal information data for storing a person's name (name) and height (height).

  What is surrounded by “<” and “>” represents a start tag. In FIG. 6, reference numerals 602, 603, and 606 correspond to start tags.

  “</>” Represents an end tag. In FIG. 6, reference numerals 605, 608, and 609 correspond to end tags.

  The content portions 604 and 607 of the element start with a symbol such as S or F, followed by the actual value. The leading “S” in the content portion 604 indicates that the subsequent value is a character string written in UTF-8. “F” indicates that the subsequent value is written in a 4-byte floating-point format in the IEEE754 format.

  The IEEE 754 format is the same format as the floating point type handled by the application. The head portion in the XML document, that is, the portion indicated by 601 is called a magic number, and the format of the XML document can be recognized by looking at several bytes near the head of the XML document. In the present embodiment, “0x01, 0x02, 0x03” is used as the magic number 601 to indicate that the XML document is a binary XML document.

  Next, processing performed by the computer 100 after loading the XML document data shown in FIG. 6 from the storage device 104 to the RAM 103 will be described with reference to FIG. FIG. 8 is a flowchart of processing performed by the CPU 101 executing the program of the type correspondence application 111. In such processing, the name and height are acquired as a character string and an integer, respectively, from the XML document shown in FIG. 6, that is, personal information data.

  First, in step S802, the function “SetDocument” is executed to open the XML document shown in FIG. Note that when the processing in step S802 is performed, processing according to the flowchart shown in FIG. 9 is started. The flowchart of FIG. 9 will be described later.

  In step S803, in order to confirm that the first start tag is “person”, the function “Read” is executed, and the function “GetNodeType” and the function “ Execute "GetName". Then, the function “Read” is executed until the return value of the function “GetNodeType” is the start tag and the return value of the function “GetName” is “person”.

  In step S804, the function “Read” is executed, and the function “GetNodeType” and the function “GetName” are executed on the current reference position advanced by the execution. Then, the function “Read” is executed until the return value of the function “GetNodeType” becomes the name tag and the return value of the function “GetName” becomes “name”.

  In step S805, the function “GetValueAsString” is executed to acquire the contents of the name tag (element), that is, “Alice” as a character string. Details of the processing in step S805 will be described later with reference to FIG.

  In step S806, the function “Read” is executed, and the function “GetNodeType” and the function “GetName” are executed on the current reference position advanced by the execution. Then, the function “Read” is executed until the return value of the function “GetNodeType” is the height tag and the return value of the function “GetName” is “height”.

  In step S807, the function “GetValueAsDouble” is executed to acquire the content of the height tag (element), that is, “160.5” as a value in the floating-point format. Details of the processing in step S807 will be described later with reference to FIG.

  In step S808, the function “Close” is executed to release memory resources and the like for the RAM 103.

  Next, processing that is started when the processing in step S802 is executed will be described below with reference to FIG. 9 showing a flowchart of the processing. The process according to the flowchart of FIG. 9 is a process performed by the CPU 101 executing the program of the common XML parser 109.

  In step S902, the format discrimination unit 108 is executed to cause the format discrimination unit 108 to acquire the magic number (601 in FIG. 6) in the XML document opened in step S802. Then, the common XML parser 109 acquires the magic number acquired by the format determination unit 108. Then, the format of the XML document is determined using the acquired magic number. That is, it is determined whether the XML document is a text XML document or a binary XML document.

  In this determination, if the magic number starts with the character string “<?”, It is determined that the magic number is a text XML document. If the magic number starts with the character string “0x01, 0x02, 0x03”, binary XML is used. It is determined as a document. In the case of the XML document shown in FIG. 6, it is determined as a binary XML document.

  However, the method for determining the format of the XML document is not limited to this, and various methods are conceivable. For example, the format may be determined by referring to the information in the Content-Type field of the HTTP header, or the format of the XML document may be determined by referring to the extension of the XML document.

  If it is determined as a text XML document as a result of the determination process in step S902, the process proceeds to step S904 via step S903. On the other hand, if it is determined that the document is a binary XML document, the process proceeds to step S905 via step S903.

  In step S <b> 904, the common XML parser 109 calls the function “SetDocument” of the text XML parser 105 and passes the XML document to the text XML parser 105. This causes the text XML parser 105 to analyze this XML document.

  On the other hand, in step S 905, the common XML parser 109 calls the function “SetDocument” of the binary XML parser 106 and passes the XML document to the binary XML parser 106. This causes the binary XML parser 106 to analyze this XML document.

  Both the text XML parser 105 and the binary XML parser 106 perform analysis processing on elements described in the XML document (in the structured document). That is, an analysis process according to the format of the XML document is realized.

  The functions “Read”, “GetNodeType”, “GetName”, and “Close” of the common XML parser 109 are wrappers that simply call the functions of the same names of the text XML parser 105 and the binary XML parser 106 and pass the return values as they are. .

  Next, details of the processing in steps S805 and S807 will be described with reference to FIG. FIG. 10 is a flowchart showing details of the processing in steps S805 and S807.

  First, in step S1002, it is determined which of the text XML parser 105 and the binary XML parser 106 is performing analysis processing as a result of the determination processing in step S902. If it is determined that the text XML parser 105 is currently performing analysis processing, the process advances to step S1008. On the other hand, if the binary XML parser 106 is currently performing analysis processing, the process advances to step S1003. In the case of the XML document shown in FIG. 6, since the analysis processing is performed on the XML document using the binary XML parser 106, the process proceeds to step S1003.

  The processing after step S1003 will be described separately for the case where it is performed in step S805 and the case where it is performed in step S807.

  First, the case where the process after step S1003 is performed in step S805 will be described.

  In step S1003, the function “GetValueType” is executed to obtain a result analyzed by the binary XML parser 106. In step S805, since the function “GetValueAsString” is executed, the binary XML parser 106 acquires the type of the name tag. In the case of the XML document shown in FIG. 6, the string type is acquired. Therefore, in step S1003, this string type is acquired as “type information”.

  Next, in step S1004, the result of analysis by the binary XML parser 106 is acquired by executing the function “GetStringValue”. In step S805, since the function “GetValueAsString” is executed, the binary XML parser 106 acquires the contents of the name tag. In the case of the XML document shown in FIG. 6, the character string “Alice” is acquired. Therefore, in step S1004, this character string “Alice” is acquired.

  Next, in step S1005, it is determined whether the data type requested (accepted) requested by the function executed in step S805 matches the type acquired in step S1003. As a result of the determination, if they match, the process proceeds to step S1007. In the case of the XML document shown in FIG. 6, since the data type requested by the function executed in step S805 is the string type, and the type acquired in step S1003 is also the string type, it is determined that they match. In this case, in step S1007, the data (character string) acquired in step S1004 is output to the request source (type-compatible application 111).

  On the other hand, if the result of determination in step S1005 is that they do not match, the process proceeds to step S1006. In step S1006, the data type acquired in step S1004 is converted into the data type required by the function executed in step S805. Thereafter, in step S1007, the data whose type has been converted in step S1006 is output to the request source.

  Next, the case where the process after step S1003 is performed in step S807 will be described.

  In step S1003, the function “GetValueType” is executed to obtain a result analyzed by the binary XML parser 106. In step S807, since the function “GetValueAsDouble” is executed, the binary XML parser 106 acquires the type of the height tag, and in the case of the XML document shown in FIG. 6, acquires the double type. Accordingly, in step S1003, this double type is acquired as “type information”.

  Next, in step S1004, the result of analysis by the binary XML parser 106 is acquired by executing the function “GetStringValue”. In step S807, since the function “GetValueAsDouble” is executed, the binary XML parser 106 acquires the content of the height tag. In the case of the XML document shown in FIG. 6, the real value “160.5” is acquired. . Accordingly, in step S1004, the real value “160.5” is acquired.

  In step S1005, it is determined whether the data type requested by the function executed in step S807 (requested type) matches the type acquired in step S1003. As a result of the determination, if they match, the process proceeds to step S1007. In the case of the XML document shown in FIG. 6, since the data type requested by the function executed in step S807 is a double type, and the type acquired in step S1003 is also a double type, it is determined that they match. In this case, in step S1007, the data (real value) acquired in step S1004 is output to the request source (type-compatible application 111).

  On the other hand, if the result of determination in step S1005 is that they do not match, the process proceeds to step S1006. In step S1006, the data type acquired in step S1004 is converted into the data type required by the function executed in step S807. Thereafter, in step S1007, the data whose type has been converted in step S1006 is output to the request source.

  Next, the operation of the computer 100 when the XML document having the configuration shown in FIG. 7 is set as the processing target instead of the XML document shown in FIG. 6 will be described. FIG. 7 is a diagram illustrating a configuration example of an XML document as a processing target by the computer 100. The XML document having the configuration shown in FIG. 7 is personal information data in which the same contents as the XML document shown in FIG. 6 are described, whereas the XML document shown in FIG. 6 is a binary XML document. The XML document shown in FIG. 7 is a text XML document.

  A tag 701 indicates that the XML document is in a text format.

  Tags 702, 703, 705, 706, 708, and 709 correspond to the tags 602, 603, 605, 606, 608, and 609 in FIG.

  704 and 705 are a character string indicating a person's name and a real value indicating height, respectively, and are substantially the same as 604 and 607 in FIG.

  When processing the XML document shown in FIG. 7 according to the flowcharts shown in FIGS. 8 to 10 when the XML document shown in FIG. 7 is to be processed, the following points are different from those described with reference to FIGS. .

  In step S902, the format discrimination unit 108 is executed to cause the format discrimination unit 108 to acquire the magic number (701 in FIG. 7) in the XML document opened in step S802. Then, the common XML parser 109 acquires the magic number acquired by the format determination unit 108. Then, the format of the XML document is determined using the acquired magic number. That is, it is determined whether the XML document is a text XML document or a binary XML document. In the case of the XML document shown in FIG. 7, it is determined as a text XML document. Therefore, the process proceeds to step S904 via step S903. In step S904, the common XML parser 109 calls the function “SetDocument” of the text XML parser 105 and passes the XML document to the text XML parser 105. This causes the text XML parser 105 to analyze this XML document.

  First, in step S1002, it is determined which of the text XML parser 105 and the binary XML parser 106 is performing analysis processing as a result of the determination processing in step S902. In the case of the XML document shown in FIG. 7, since the text XML parser 105 is used to perform analysis processing on this XML document, the processing proceeds to step S1008.

  The processing after step S1008 will be described separately for the case where it is performed in step S805 and the case where it is performed in step S807.

  First, the case where the process after step S1008 is performed in step S805 will be described.

  In step S1008, the function “GetValue” is executed to obtain the result of analysis by the text XML parser 105. In step S805, since the function “GetValueAsString” is executed, the text XML parser 105 acquires the contents of the name tag. In the case of the XML document shown in FIG. 7, the character string “Bob” is acquired. Therefore, in step S1008, this character string “Alice” is acquired.

  In step S1009, it is determined whether the data type requested by the function executed in step S805 (requested type) is a string type (character string type) or not specified. If the result of this determination is string or no designation, the process advances to step S1007. In the case of the XML document shown in FIG. 7, since the data type requested by the function executed in step S805 is the string type, the process advances to step S1007. In step S1007, the data (character string) acquired in step S1008 is output to the request source (type-compatible application 111).

  On the other hand, if the result of determination in step S1009 is not string type or no designation, processing proceeds to step S1010. In step S1010, the same processing as in step S1006 is performed. Thereafter, in step S1007, the data whose type has been converted in step S1010 is output to the request source.

  Next, the case where the process after step S1008 is performed in step S807 will be described.

  In step S1008, the function “GetValue” is executed to obtain the result of analysis by the text XML parser 105. In step S807, since the function “GetValueAsDouble” is executed, the text XML parser 105 acquires the contents of the height tag. In the case of the XML document shown in FIG. 7, the character string “175.3” is acquired. . Therefore, in step S1008, this character string “175.3” is acquired.

  In step S1009, it is determined whether the data type requested by the function executed in step S807 (requested type) is a string type (character string type) or not specified. If the result of this determination is string or no designation, the process advances to step S1007. On the other hand, if the result of determination in step S1009 is neither string type nor designation, the process proceeds to step S1010.

  In the case of the XML document shown in FIG. 7, the type of data requested by the function executed in step S807 is a double type (floating point type), which is neither a string type nor an unspecified type. Therefore, in this case, the process proceeds to step S1010.

  In step S1010, the data type acquired in step S1008 is converted into the data type required by the function executed in step S807. As a result, a floating point value of 175.3 in the IEEE 754 format can be acquired.

  Thereafter, in step S1007, the data whose type has been converted in step S1010 is output to the request source.

  Next, the operation of the legacy application 110 will be described. Since the legacy application 110 was originally not intended for binary XML documents, it is created using the API of the text XML parser 105. When the legacy application 110 handles personal information data, the processing performed by the computer 100 follows the flowchart shown in FIG.

  FIG. 11 is a flowchart of processing performed by the computer 100 when the legacy application 110 handles personal information data.

  Step S1102 to step S1104, step S1106, and step S1108 are the same as step S802 to step S804, step S806, and step S808 shown in FIG. 8, respectively. Hereinafter, processing in steps S1105 and S1107 will be described.

  In steps S1105 and S1107, the values of all nodes are acquired using the function “GetValue”. Details of the processing in steps S1105 and S1107 are according to the flowchart shown in FIG.

  In this case, since the text XML parser 105 is used, the processing proceeds from step S1002 to step S1008.

  In step S1008, the function “GetValue” is executed to obtain the result of analysis by the text XML parser 105. In step S1105, the character string “Alice” is obtained in the case of the XML document shown in FIG. Therefore, in step S1008, this character string “Alice” is acquired.

  Next, since the data type requested by the function executed in step S1105 (requested type) is the string type, the process proceeds to step S1007 via step S1009. In step S1007, the data (character string) acquired in step S1008 is output to the request source (type-compatible application 111).

  In step S1008, the function “GetValue” is executed to obtain the result of analysis by the text XML parser 105. In step S1107, the character string “160.5” is obtained in the case of the XML document shown in FIG. To get. Accordingly, in step S1008, this character string “160.5” is acquired.

  Next, since the data type requested by the function executed in step S1107 (requested type) is a double type (floating point type) and not a string type, the process proceeds to step S1010 via step S1009.

  In step S1010, the data type acquired in step S1008 is converted to the data type required by the function executed in step S1107. As a result, a floating point value of 160.5 in the IEEE754 format can be acquired.

  Thereafter, in step S1007, the floating point value 160.5 is output to the request source.

  In this way, legacy application 110 can obtain values from a binary XML document.

  When a text XML document is passed to the legacy application 110, the common XML parser 109 does not perform special processing and behaves as a simple wrapper of the text XML parser 105, so that a value can be acquired normally. .

  As described above, according to the present embodiment, the common XML parser 109 provides a function for correctly acquiring values in a combination of two types of applications and two types of XML documents, that is, in all four cases. can do.

  Further, when the type-compatible application 111 handles a binary XML document, value type conversion is not performed in the middle, so that high-speed processing without waste is possible. As a result, an application using an XML document supports high-speed processing using a binary XML document and can handle a text XML document.

  In addition, a binary XML document can be handled by an application created for a text XML document.

[Second Embodiment]
FIG. 12 is a block diagram showing a hardware configuration of a computer 1200 applicable to the structured document processing apparatus according to this embodiment. 12, the same components as those shown in FIG. 1 are denoted by the same reference numerals, and the description thereof is omitted. That is, the configuration shown in FIG. 12 is configured such that a Fast Infoset parser 1206 is stored in the storage device 104 instead of the binary XML parser 106 shown in FIG.

  A Fast Infoset parser 1206 is a parser that analyzes an XML document in a Fast Infoset format, which is one of binary XML formats.

  In this embodiment, an example of an XML document to be processed by the type correspondence application 111 is shown in FIGS. FIG. 14 is a diagram showing a configuration example of a text XML document, and FIG. 13 is a diagram showing a configuration example when the XML document shown in FIG. 14 is expressed in the Fast Infoset format.

  In FIG. 13, “E000” indicated by reference numeral 1301 is a magic number, which indicates that the XML document is in the Fast Infoset format.

  Next, “0001” indicated by 1302 is the version of Fast Infoset, which is 1 in this example.

  Next, “00” indicated by 1303 indicates the existence of optional data, and “00” means that there is no data.

  “3C00” indicated by the next 1304 has many meanings because it has a meaning for each bit, but it mainly means that the next node is an element. In addition, information such as presence / absence of attribute, existence of namespace name, number of bytes of element name, and the like are included.

  Next, “61” indicated by 1305 is an element name “a” encoded by UTF-8.

  The next two bytes “9C1A” shown by 1306 have many meanings as well, but mainly the next node is the content of the element, and the value is a floating-point type. In addition, information such as the number of bytes is also included.

  Next, “C2ED4000” indicated by 1307 is a floating-point value of −118.625 encoded in the IEEE754 format.

  “FF” shown at the last 1308 represents the end of the element, and the next F represents the end of the document. That is, the XML document shown in FIG. 13 has almost the same meaning as the text XML document shown in FIG. In addition to the meaning of the document, the order in which the nodes appear is the same.

  Here, when the type corresponding application 111 acquires the value of the a element shown in FIG. 13, the common XML parser 109 performs processing according to the flowchart shown in FIG. 15.

  FIG. 15 is a flowchart of processing performed by the computer 1200 when the type-corresponding application 111 acquires the value of the a element shown in FIG.

  First, in step S1502, the function “SetDocument” is executed to open the XML document shown in FIG. When the process in step S1502 is performed, the process according to the flowchart shown in FIG. 9 is started in the same manner as in the first embodiment. In the process according to the flowchart of FIG. 9, the format determination process determines whether or not the Fast Infoset format is used, and this determines whether or not “E000” is described as the magic number. To do. If “E000” is described as the magic number, the Fast Infoset parser 1206 is used. If not described, the text XML parser 105 is used.

  In step S1503, the function “Read” is executed, and the function “GetNodeType” and the function “GetName” are executed on the current reference position advanced by the execution. Then, the function “Read” is executed until the return value of the function “GetNodeType” is the start tag and the return value of the function “GetName” is “a”. Similarly to the text XML format in the Fast Infoset format, first, a byte sequence indicating the start of an element and a byte sequence indicating the name of the element appear, so the first node is a start tag a.

  In step S1504, the function “GetValueAsDouble” is executed to acquire the content of the a tag (element), that is, “−118.625” as a real value. Details of the processing in step S1504 are according to the flowchart shown in FIG.

  That is, since the Fast Infoset parser 1206 is used, first, in step S1003, data type information is received from the Fast Infoset parser 1206. The Fast Infoset parser 1206 determines that the value of this data is a floating-point number based on the portion “9C1A” indicated by 1306 in FIG. 13, and therefore returns a double type as type information. In step S1004, a value of that type, that is, “−118.625” is acquired.

  In step S1005, it is determined whether the data type requested by the function executed in step S1504 (requested type) matches the type acquired in step S1003. As a result of the determination, if they match, the process proceeds to step S1007. In the case of the XML document shown in FIG. 13, since the data type requested by the function executed in step S1504 is a double type, and the type acquired in step S1003 is also a double type, it is determined that they match. In this case, in step S1007, the data (real value) acquired in step S1004 is output to the request source (type-compatible application 111).

  As a result, data can be passed to the application without performing unnecessary conversion.

  Even if the text XML document shown in FIG. 14 is a processing target, the processing may be performed in the same manner as in the first embodiment.

  As described above, it is possible to realize a structured document processing apparatus that can handle both an XML document in the conventional text XML format and a Fast Infoset format document and that can perform processing without performing unnecessary data type conversion.

  Here, as the computers 100 and 1200, communication devices that can use XML documents, such as mobile phones and copiers, can be used.

[Other Embodiments]
Needless to say, the object of the present invention can be achieved as follows. That is, a recording medium (or storage medium) in which a program code of software that realizes the functions of the above-described embodiments is recorded is supplied to the system or apparatus. Needless to say, such a storage medium is a computer-readable storage medium. Then, the computer (or CPU or MPU) of the system or apparatus reads and executes the program code stored in the recording medium. In this case, the program code itself read from the recording medium realizes the functions of the above-described embodiment, and the recording medium on which the program code is recorded constitutes the present invention.

  Further, by executing the program code read by the computer, an operating system (OS) or the like running on the computer performs part or all of the actual processing based on the instruction of the program code. Needless to say, the process includes the case where the functions of the above-described embodiments are realized.

  Furthermore, it is assumed that the program code read from the recording medium is written in a memory provided in a function expansion card inserted into the computer or a function expansion unit connected to the computer. After that, based on the instruction of the program code, the CPU included in the function expansion card or function expansion unit performs part or all of the actual processing, and the function of the above-described embodiment is realized by the processing. Needless to say.

  When the present invention is applied to the recording medium, program code corresponding to the flowchart described above is stored in the recording medium.

It is a block diagram which shows the hardware structural example of the computer applicable to the structured document processing apparatus concerning the 1st Embodiment of this invention. 1 is a diagram illustrating a configuration example of a network to which a computer 100 is applied. It is a figure which shows an example of API of the text XML parser 105. FIG. 3 is a diagram illustrating an example of an API of a binary XML parser 106. FIG. 3 is a diagram illustrating an example of an API of a common XML parser 109. FIG. 2 is a diagram illustrating a configuration example of an XML document to be processed by the computer 100. FIG. 2 is a diagram illustrating a configuration example of an XML document to be processed by the computer 100. FIG. 4 is a flowchart of processing performed when the CPU 101 executes a program of the type correspondence application 111. It is a flowchart of the process started when the process in step S802 is performed. It is a flowchart which shows the detail of the process in step S805, S807. 10 is a flowchart of processing performed by the computer 100 when the legacy application 110 handles personal information data. It is a block diagram which shows the hardware constitutions of the computer 1200 applicable to the structured document processing apparatus concerning the 2nd Embodiment of this invention. FIG. 15 is a diagram illustrating a configuration example in a case where the XML document illustrated in FIG. 14 is expressed in a Fast Infoset format. It is a figure which shows the structural example of a text XML document. 14 is a flowchart of processing performed by a computer 1200 when a type-corresponding application 111 acquires the value of an a element illustrated in FIG. 13.

Claims (6)

A structured document processing apparatus for processing a structured document,
An acquisition means for acquiring the format of the structured document;
Analysis means for analyzing the structured document by an analysis method according to the format acquired by the acquisition means;
Means for receiving a request for acquiring an element described in the structured document in a specified type;
Determining means for determining whether or not the type analyzed by the analyzing means for the element matches the specified type;
When the determination means determines that they match, the element is output to the request source. When the determination means determines that they do not match, the element type is converted to the specified type. A structured document processing apparatus, comprising: an output unit that outputs the element to the request source. The analysis means is composed of a binary XML parser and a text XML parser,
If the format acquired by the acquisition unit is binary XML, the structured document is analyzed by the binary XML parser,
The structured document processing apparatus according to claim 1, wherein when the format acquired by the acquiring unit is text XML, the structured document is analyzed by the text XML parser. The analysis means includes a Fast Infoset parser and a text XML parser.
When the format acquired by the acquisition unit is a Fast Infoset format, the structured document is analyzed by the Fast Infoset parser,
The structured document processing apparatus according to claim 1, wherein when the format acquired by the acquiring unit is text XML, the structured document is analyzed by the text XML parser. A structured document processing method performed by a structured document processing apparatus for processing a structured document,
An acquisition process for acquiring the format of the structured document;
In the analysis method according to the format acquired in the acquisition step, an analysis step of analyzing the structured document;
Receiving a request to acquire an element described in the structured document with a specified type;
A determination step of determining whether or not the type analyzed in the analysis step for the element matches the designated type;
If it is determined in the determination step that the elements match, the element is output to the request source. If it is determined in the determination step that the elements do not match, the element type is converted to the specified type A structured document processing method comprising: an output step of outputting the element to the request source.   A program for causing a computer to execute the structured document processing method according to claim 4.   A computer-readable storage medium storing the program according to claim 5.

Images