JP2001344267A - XML document query language processor - Google Patents

Abstract

(57) [Summary] [Problem] To provide an XML document query language processing device capable of improving the flexibility and sophistication of the processing operation of the description content without changing the existing query language for XML documents as much as possible. I do. SOLUTION: An inquiry means 1 for making an inquiry about document data described in an XML document type, a conversion means 4 for analyzing the inquiry and converting it into an internal format, and a content of the inquiry based on the converted internal format And an external function storage means 6 for storing external functions for performing processing which is described in a general-purpose programming language and which cannot be processed by the description content processing of an inquiry language. The query means 1 defines an external function by associating processing contents described in a general-purpose programming language with processing contents described in an XML language in order to perform processing according to a program described in an external function. Executing means 5 calls the external function when the external function is specified in the query. To execute the processing described in the general-purpose programming language.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to an improved XML document query language processing device.

[0002]

2. Description of the Related Art In recent years, with the explosive spread of the Internet, the construction and utilization of various document databases has been rapidly advanced. In particular, the use of structured documents described in the XML language format is expected to become more and more active because the document data is constructed in a hierarchical structure using human-understandable tags.

[0003] In XML, a document type (DTD) is defined, and a document database is constructed based on this document type.

[0004] For example, it is assumed that a document of a newspaper article is described in an XML language, and this document type is given by a DTD described below.

<DTD given to database> <! ELEMENT document article +> <! ELEMENT article (posting date, headline, text)> <! ELEMENT text Paragraph +> <! ELEMENT Posted date #PCDATA> <! ELEMENT heading #PCDATA> <! ELEMENT paragraph #PCDATA> This DTD means the following.

[0006] The database stores a plurality of newspaper articles, each of which is composed of three items, "posting date", "headline", and "text", and the text is composed of one or more paragraphs. That means.

An example in which a newspaper article document given by the DTD is described in a text document using the XML language is shown below. It is assumed that these text data are stored in a database. These text data include this XM
Inquiry language targeting L language, for example, XML-
An inquiry can be made using QL and XQL, and a target document can be extracted from the database.

[0008]

However, these query languages for XML are excellent in the operation function for the document structure, but the operations related to the processing of the description contents are extremely limited, and the description contents are flexible. Cannot be processed.

[0009] Therefore, in addition to e-commerce, XM
Today, the use of L-structured documents is expected to become more and more active, and it is essential to further enhance the description processing function.

At this time, if the program of the query language itself for XML is completely rewritten, the query language loses flexibility, which is not preferable.

SUMMARY OF THE INVENTION The present invention has been made in view of the above circumstances, and has as its object the flexibility and the flexibility of the operation of processing description contents without changing the existing query language for XML as much as possible. XML that can be advanced
A document query language processing device is provided.

[0012]

An XML document according to claim 1, wherein:
The document query language processing apparatus includes: a query unit that makes a query about document data described in an XML document type; a conversion unit that analyzes the query and converts the query into an internal format; Execution means for executing the contents of the inquiry and outputting the document data based on the inquiry, and an external function for performing processing which is described in a general-purpose programming language and which cannot be processed by the processing of the description contents of the inquiry language are stored. External function storage means, wherein the inquiry means corresponds to the processing content described in the XML language in order to cause the processing content to be performed according to the program described in the external function. External function definition means for defining an external function, and When the number is specified, the executing means and executes the written in the general-purpose programming language processing by calling the external function.

According to a second aspect of the present invention, in the XML document query language processing apparatus, the execution means is an XSLT language processing apparatus.

According to a third aspect of the present invention, in the XML document query language processing apparatus, the external function is a function that is described in the general-purpose programming language and corresponds to a summary generating unit that generates a summary from a document. .

According to a fourth aspect of the present invention, in the XML document query language processing apparatus, the external function determines a similarity between the headline item of the document and the similarity, and extracts a document of a paragraph related to the headline of the document. It is a function corresponding to the means.

According to a fifth aspect of the present invention, in the XML document query language processing apparatus, the external function is a function corresponding to a document character extracting means for extracting a first line from a document body.

[0017]

DESCRIPTION OF THE PREFERRED EMBODIMENTS In FIG. 1, reference numeral 1 denotes an input / output interface as an inquiry means, 2 denotes a database, and 3 denotes an inquiry processing system. It is assumed that a large number of XML documents such as newspaper articles are stored in the database 2 according to the XML language.

As the input / output interface, an extended form of XML-QL is used as inquiry means for inquiring document data described in XML document type.

The query processing system 3 analyzes the query and converts it into an internal format. The query processing system 3 executes the content of the query based on the converted internal format and outputs the XML document data stored in the database 2. And execution means 5 for performing the operation. In order to use an existing means for the conversion means 4, an XSLT language processing device is used here.

The query processing system 3 is composed of an external function storage means 6 and a stub means 7 which are described in a general-purpose programming language and store external functions for performing processing which cannot be performed by processing the description contents of the query language. Can be communicated via The external function (also referred to as a description processing function or a user-defined function) is described in, for example, JAVA (registered trademark) as a general-purpose programming language.

For example, when the document is an article, the external function may have a function of automatically generating a summary of the article, or may have a function of automatically generating a summary of the article. It may have a similarity extraction function for extracting a document, or may have a document character extraction function for extracting the first line from the text of the document.

The input / output interface 1 associates processing contents described in a general-purpose programming language with processing contents described in an XML language so as to perform processing in accordance with a program described as an external function. There is an external function definition means for defining.

Here, it is assumed that an inquiry is made using an external function having a document character extracting function for extracting the first line from the body of the document.

The inquiry is described, for example, as follows. In this description, "function string head (content st
r) defined-by "" is the definition of the external function. When the query is executed based on this definition, the conversion means 4 converts the query into an internal format, and the execution means 5 executes the query.

When an external function is specified in the inquiry, the execution means 5 accesses the external function storage means 6 through the stub means 7, calls the external function specified by the inquiry, and uses the external function to convert the XML document into an XML document. Process.

In this example, an external function for extracting the first line from the body of the article is specified, and the execution means 5 performs an operation for extracting the first line from the body of each article by using the processing function of the external function. Output as an XML document.

According to the present invention, processing that cannot be performed by the description processing of the existing query language can be implemented as an external function, so that advanced processing contents can be implemented without changing the existing query language itself as much as possible. Can be added flexibly.

The details will be described below based on a paper. Structured document operation description method based on document structure conversion rules and description processing functions Abstract In recent years, with the explosive spread of the Internet, the demand for the construction of XML and other structured document databases and their advanced use has increased. I have. In the process description for the structured document database, it is necessary to target both the process for the document structure given by the hierarchical structure of tags and the process for the description content given by the character string text.

Several query languages have been proposed for XML. Many of these have relatively powerful operation functions for document structures, but provide only very limited functions for description processing.

In the future, in order to respond to the demand for advanced use of structured documents, it is considered that the description content processing function must be further expanded.

In particular, in order to efficiently obtain desired information from a large number of documents, functions such as narrowing down document elements based on semantic similarity, ranking, abstracting, and topic extraction are required. 1. Introduction In recent years, the construction and utilization of various document databases has been rapidly advanced. In particular, with the explosive spread of the Internet, there has been an increasing demand for the construction and advanced use of structured document databases such as XML.

In the process description for the structured document database, it is necessary to cover both the process for the document structure given by the hierarchical structure of tags and the process for the description content given by the character string text.

Various query languages have been proposed as basic processing description languages for structured document databases.

[0034] XML-QL and XQL are typical examples of query languages for XML. Also, Lorel, UnQL, StruQL, and YAT, query languages for semi-structured data
L also assumes that XML structured documents are one of the applications.

In any of these query languages,
In some sense, functions related to both document structure processing and description content processing are provided.

In particular, XML-QL and a semi-structured data query language have a relatively powerful operation system for a document structure.
However, in contrast to this, the description content processing provides only a very limited function such as selecting a document element having a partial character string that matches a specified word or pattern.

It is expected that the use of structured documents, including electronic commerce, will become more active in the future. In order to meet the needs of various users, more advanced use of structured documents is required. As one direction, further expansion of the description processing function is an important issue.

In particular, in order to efficiently obtain target information from a large number of structured documents, document elements are narrowed down and ranked based on the degree of semantic similarity to a given keyword group, and document elements are summarized. It is considered very important to integrate functions such as word extraction and topic extraction into the framework of document structure operation as described above.

For example, when considering a query for a newspaper article database given as an XML structured document group, in addition to document structure operations such as extracting the publication date and headline of the relevant article and reconstructing it into an appropriate list, Therefore, it is required to be able to measure the similarity between the content of the article and the inquiry, and to process a request that involves the processing of the description content such as attaching an abstract as necessary.

Here, it should be noted that the method of calculating the similarity and the method of creating the abstract depend on the type of the target document or document element. For example, words that appear in a specific document element such as a headline are often weighted more heavily than words included in other document elements.

Various methods have been proposed for automatic summary generation, topic extraction, and the like. Therefore, it is desirable that the details of specific description processing such as derivation of similarity and creation of an abstract have expandability that allows a user to externally provide a content that meets the purpose as needed.

In this research, in order to respond to such a request, a document structure operation function of a query language for a structured document and a higher-level description content processing function such as similarity search and summary generation are integrated. We propose a simplified document operation description method.

This operation description realizes the above-mentioned integration by combining a document structure conversion rule group given in a format conforming to XML-QL and a description processing function with an XML structured document as an operation target.

This description processing function can be additionally defined by the user according to the purpose. In addition, the procedure for converting the XML structured document operation given in this operation description into the XSLT-based document operation under certain restrictions is shown. Therefore, this operation description processing system can be implemented on the XSLT processing system within the range of input that satisfies the restrictions here.

In the following, Section 2 shows an example of a structured document operation requiring integration of the document structure operation and the processing of higher-order description contents. Next, Section 3 outlines XML-QL, and Section 4 details the operation description method. Section 5 describes the conversion method from this operation description method to XSLT description. Section 6 refers to related research, and Section 7 summarizes and discusses future work. 2. Example of structured document operation This section shows an example of a structured document operation that requires both the capabilities of description content processing and document structure operation. Section 4 describes this operation description method using Example 1 in this section. In the following, the document element name of "identifier" or its document element is described as <identifier> as necessary. The attribute names are also described in the same manner.

Example 1 X constructed as an article database of articles of a newspaper
Consider an ML document. Each article shall include the publication date, headline, and text, and the DTD of the document shall be given below.

<!-DTD of input document-><! ELEMENT document article +><! ELEMENT article (posting date, headline, text)><! ELEMENT text paragraph +><! ELEMENT posting date #PCDATA>< ! ELEMENT Heading #PCDATA><! ELEMENT Paragraph #PCDATA> Readers are interested in a case, extract n articles that match their interest from this document by date of publication, Suppose you want to get a summary of the content. This is realized by the following operation, for example. 1. Extract <Articles> from <Documents> and group them by <Post Date>. 2. For each group, the similarity of each <article> to the keyword group indicating the content of interest given by the reader is examined, and the top n results of the ranking result are selected. 3. For each of the selected <articles>, a <headline> is extracted, and a document element serving as an abstract is generated from the <body>.

In this example, 1 is one of the typical examples of the document structure operation. Reference numeral 2 selects a document element based on the degree of similarity for each of the <article> sets classified according to <posting date>. In 3, the document structure is reconstructed for each <article> of the result and the automatic summary generation of the <body> is performed. There are various methods for summarization, but here <
Consider a method of extracting a certain amount of paragraphs and sentences having a high degree of similarity to heading>. This can be considered to be the same processing as 2 if document elements such as paragraphs and sentences as extraction units are introduced. <Paragraph> is used as a specific extraction unit. The document obtained as a result of this operation is the following DTD
Shall be followed.

<!-DTD of output document-><! ELEMENT document daily +><! ELEMENT daily article +><! ELEMENT article (headline, body)><! ELEMENT body paragraph +><! ELEMENT Heading #PCDATA><! ELEMENT Paragraph #PCDATA> Example 2 There is a structured document that contains a survey of product share in a certain field and articles on the comparison and evaluation of those products. The article is paragraphed and this document is subject to the following DTD:

<!-DTD of input document-><! ELEMENT document (share table, evaluation article) +><! ELEMENT share table Product information +><! ELEMENT product information (product name, share)><! ELEMENT Evaluation Article Paragraph +><! ELEMENT Product Name #PCDATA><! ELEMENT Share #PCDATA><! ELEMENT Paragraph #PCDATA> Consider the situation where you want to extract the "parts". Here, the “part” indicates a “topic unit” composed of a plurality of paragraphs, which is not explicitly given as a document element. As in text tiling, the boundaries of topic units are given by the boundaries of paragraphs that are valleys that are equal to or greater than a certain depth in the transition graph of similarity between consecutive paragraphs. This request is fulfilled, for example, by the following processing, and the resulting document conforms to the DTD shown below. 1. For <evaluation article>, extract <paragraph> columns that form a topic unit according to the transition condition of similarity between <paragraphs>
This is summarized as a new document element <topic unit>. 2. From the <Share Table>, <Products> with <Share> of 30% or more
Product name> is extracted, and a character string including <product name> as a character string is selected from the column of <topic unit> obtained in 1.

<!-DTD of output document-><! ELEMENT document product +><! ELEMENT product (product name, article)><! ELEMENT article topic unit +><! ELEMENT topic unit paragraph +><! ELEMENT ELEMENT product name #PCDATA><! ELEMENT paragraph #PCDATA> Here, in Example 1, 2 processing is performed on <daily> obtained by grouping of 1, and in Example 2, it is generated by restructuring by 1. 2 is performed for the <topic unit> to be executed. As described above, it is necessary to perform a plurality of processes on the same portion in a superimposed manner. Such a processing result is regarded as an intermediate result, and further processing is called multi-step processing. 3. XML-QL The operation description method proposed in this paper uses XML-Q as the basic syntax.
L based. This is to enhance the affinity with the conventional query language and make the description highly readable. In this section, XM necessary to understand the operation description method in section 4
The function of L-QL is explained. 3.1 Query XMl-QL is a query language for XML documents, and its basic syntax is as follows.

[0052] For example, 1 in Example 1 in the previous section is described as follows. The output is a <document> containing the <daily> column.

[0053] where clause Specify the query conditions, and for the document element that matches the pattern expression in the target document or document element,
Bind variables if necessary. A pattern expression is a sequence of document elements starting from the root, and variable binding is performed for all matching combinations. Note that the attribute of the document element can be similarly targeted, but the description is omitted in this document.

Pattern expression <a><b></> element # as $ x </>
Assigns <b>, a child element of <a>, to variable $ x.
Also, the pattern expression <a><b></> content # as $ x </>
><b> $ x </></>, which is a child element of <a><b
Assign the entire contents of> to $ x. Pattern expression <a><$x><
/> $ i </> assigns the document element name of any child element of <a> to the tag variable $ x, and $ i is the subscript number indicating the occurrence position
Assign (0,1, ...).

For the structure specification, a subset of the path regular expression can be used. <a | b> is <a> or <b>, <ab> is <
Matches <b>, which is a child element of a>.

* And + respectively indicate 0 or more times and 1 or more times of the immediately preceding path name, and ＄ matches any document element. Note that the order in which document elements appear in the pattern expression is
Does not specify the order of appearance in the target document element. In the example at the beginning, in the first where clause, the inside of <document> is bound to $ x, and in the second where clause, each <article> in $ x is converted to $ a, and the <post date> To $ d. construct clause where
This section specifies the output configuration for each combination of variables that match the pattern expression of the section, and is described in the form of a document element or a character string containing the variable. The query result is a sequence of document elements generated by expanding the variables of this description.

In the construct section, where-construct
Clauses can be nested. In this case, the outer where
After fixing the value of the variable that matches in the clause,
The construct clause is processed.

The document element to be generated can be given its <ID> attribute by a Skolem function, and document elements having the same <ID> are aggregated into one document element entity. The Skolem function has one-to-one correspondence between its argument and its return value. By using this, grouping can be realized. In the first example, only one <document> containing the processing result of the subquery is generated. In the subquery, <article> ($ a)
Is generated as a <daily> column. Each <
Daily> is the skolem function DateID () in the construct clause
Gives <ID> generated from the value $ d of <Posting date>. For this reason, [daily] generated from the same [posting date] are combined into one. As a result, <article> is grouped into <daily> by <post date>. order-by clause This section specifies the output order of the document elements. The output is sorted in ascending order for the specified key value, and in descending order when descending is specified. In the example at the beginning, the output <daily> document elements are sorted in chronological order according to the value of the variable $ d and output. 3.2 Function Definition The following syntax allows a user to define a function as needed.

Function function name (argument list) where to construct query end The query result in the function definition is treated as the return value of the function call. For this reason, functions that can be defined in XML-QL are limited to those that can be expressed as queries. 4. Proposed Description Method 4.1 Document Structure Conversion Rule In this operation description method, an operation including a description content processing function for a structured document is described based on a document structure conversion rule. The document structure conversion rule (hereinafter, conversion rule) indicates a conversion method for a substructure that matches the pattern. Although the use of the rule-oriented description is originally independent of integrating the document structure operation function and the higher-level description content processing function, it has the following advantages. 1. It becomes easier to describe the conversion operation for the substructure that appears commonly in various documents in a more concise manner. For example, to implement a process that replaces a certain document element embedded in various document structures with another document element, XML-QL uses different query descriptions depending on the upper-level document structure. Need to be described so as to preserve the higher-level structure. This adds complexity to the description. In addition, if the upper-level document structure cannot be limited to some extent in advance, the description itself may be difficult. 2. There is a possibility that rule-oriented processing methods such as XSLT will be widely spread in the future, but they are highly consistent with them. For example, there are already some structured document description systems based on rule-oriented frameworks such as YATL and XQL. Also,
In this paper, Section 5 shows how to convert to XSLT. 3. For example, an ordinary query description in XML-QL etc. can be regarded as a conversion rule consisting of a single conversion rule that satisfies certain conditions. In this sense, it is a natural extension of the conventional query description. I have.

The description of each conversion rule is based on XML-QL in consideration of readability and compatibility with existing query languages. The basic syntax of the conversion rule is as follows.

[0061] In a document operation, a scene appears in which the length of a document element sequence generated as an output is limited according to the ranking result, such as only the top n items. To cope with this, this operation description introduces the first clause and the rank-by to top clauses. By this specification, the output generated in the construct clause is limited to the number of evaluation results of the output number calculation formula.

The first clause outputs a specified number of document elements from the top in the order of output generation, or from the end if from to bottom is specified. At this time, if there is an order-by clause, it operates on the sort result.

The rank-by to top clauses perform ranking based on the evaluation result of the order evaluation criterion formula, and output only those whose rank is within the evaluation result of the output number calculation formula in the order of generation. This has a similar effect to using the order-by and first clauses, but does not affect the physical location of the output. Also, since there is no physical sorting, descending and
It has no from ~ bottom modifier. 4.3 Description example and application procedure The conversion rules corresponding to the document operations described in Example 1 in Section 2 are shown below. The three conversion rules correspond to operations 1 to 3 in Example 1.
Respectively.

In XML-QL, the starting point of pattern matching is always the root document element, but this operation description makes a different interpretation. To correspond to item 1 in the previous section, the target of pattern matching is not limited to the root document element, but is a more limited partial document as shown in the application procedure below. The specific application procedure of the conversion rule is shown below.

// Conversion rule 1: Equivalent to grouping in example 1.1 rule where <document></> content # as $ x construct <document> where <article><date> $ d </></> element # as $ a in $ x order-by $ d construct # <Daily ID = DateID ($ d)> $ a </></> // Conversion rule 2: Equivalent to filtering in Example 1.2 rule where <Daily></> content # as $ x construct <daily> where <article></> element # as $ a in $ x order-by $ a.sim # cosine (keywords) first 5 construct # $ a </> / / Conversion rule 3: Equivalent to summarization in example 1.3 rule where <article><headline></> element # as $ h <body></> element # as $ b construct <article> $ h <body> where <Paragraph></> element # as $ p in $ b rank-by sim # cosine ($ h, $ b) top 3 construct $ p </></> Note that “keywords” is in Gothic here But,
In fact, italics are used.

[0066] 0. The conversion rule is applied in multiple stages as follows, with the root document element as the initial state to be collated. 1. The pattern matching between the document element to be matched and the conversion rule is performed. If a conversion rule that matches the where clause is found in the conversion rule group, it is applied, and if there is another candidate for matching, the next matching object is processed. The portion of the output document that matches the match is replaced by the output of the construct clause. If more than one conversion rule matches, the one defined above takes precedence.

On the other hand, when there is no suitable conversion rule and the current collation target has child elements, the same processing is sequentially performed with the child elements as collation targets in the output order. In this repetition, recursion downward is prioritized, and after the processing is completed, the subsequent sibling document element is set as a collation target. The above is repeated until the end of the document is reached.

In Example 1, <document> is the first collation target. Since this is processed by the conversion rule 1, recursion to the child element does not occur. In addition, from all <articles> matched by the subquery, columns of [daily] grouped by publication date are generated in the same manner as in the example in section 3, and the <document> having these as children is used to generate the original <document>> Is replaced. Due to the structure of the original document, only one <document> is generated. The document obtained at the end of this process complies with the DTD of the output document described in Section 2. Thus, the operation 1 of Example 1 is completed. 2. Subsequently, the operations of the second and subsequent steps of Example 1 are performed, but the above-described procedure alone cannot shift to that processing. In order to realize such multi-step processing, the matching target specifier `` # ''
Is introduced. If the output document includes the matching specifier at the time when the pattern matching of the entire document is completed, the change processing is further continued. In this case, the document elements designated as collation targets in the construct clause are sequentially treated as collation targets, and are similarly processed recursively. The evaluation order of the items to be collated follows the order of appearance in the document.

In the case of the example, since <daily> is specified as the collation target, all the article columns constituted by this are 2
It is a candidate for the collation target in the pass. This conforms to Conversion Rule 2 which corresponds to 2 in Example 1. It is assumed that a keyword group specified by the user is embedded in “keywords” (displayed in italics) as a character string. sim # cosine () is a description content processing function. This is the method of $ a, or <article>, as described in section 4.3, and returns the similarity of the argument with the keyword group. At this time, a method of measuring the similarity unique to <article> such as increasing the weight of the word included in [heading] is performed. By utilizing this, the similarity between each <article> and the keyword group is obtained, and the top n of the ranking result based on the similarity is output. In addition, each <
Since the article> is specified as the collation target, the processing is performed to the end of the document, and is then treated as the collation target in the output document. 3. Further, in the third pass, pattern matching is performed on <article> in the same manner as in 2, and the processing of conversion rule 3 is applied. As a result, the processing of 3 in Example 1 is applied. Here, the similarity to <heading> is given to all <paragraphs> in the article as the similarity of <paragraph>, and only the top three <paragraphs> are left as summary results according to the ranking result. Here, sim # cosine () which is a description processing function is used. As described in section 4.3, this is a general-purpose function for measuring similarity, not a method specific to a certain document element. Therefore, conversion rule 2
Unlike that of No, no special similarity measure is performed. Since the conversion rule does not specify the collation target, the process is completed when all the processes are completed. 4.3 Description processing function It was stated that only functions that can be defined in XML-QL can be described as queries. For this reason, a function that performs flexible processing cannot be described. Further, it is impossible to comprehensively provide the functions required for the description content processing by expanding the built-in functions. Therefore, in this operation description method, a description processing function can be defined as an external program using a language such as Java.

In general, the DTD according to the target document has a fluctuation within the range assumed by the conversion rule. For example, it can easily be assumed that even for document elements having the same name, the description format of the content and the method of extracting the feature amount differ for each DTD, and the tag names and the like to be determined are different. In order to absorb such diversity, the definitions of the description processing functions are given for each DTD (Fig. 2). As a result, the implementation method of the description content processing is abstracted and can be used in the same manner.

Also, as exemplified by sim # cosine (),
Even within the same DTD, it is assumed that the processing for the description content differs depending on the type of document element. That is, even if the function name is the same, there is a case where each document element has polymorphism. In addition, the extraction method of "important phrases" may be different between <author list> in which the first person's name is the main author and <paragraph> in the text. From this point, it is possible to define a function in the form of `` document element name.method name () '' as a method specific to a certain document element and use it in the form of `` document element variable.method name () ''. I do. The syntax of the description processing function is as follows.

Function data type function name (argument list) define-by "URI including function implementation" function data type document element name. Method name (argument list) define-by "URI including function implementation" argument list :: = Data type Argument name [, Data type Argument name] * Specify the data type in the description processing function definition. Valid data types for function arguments and return values are number (number), string (string), element (document element), and content.
s (element content). Here, the contents type is equivalent to a character string permitted as the content of the document element, and the text (#P
A sequence of (CDATA) and document elements is allowed. Other data types can be considered as columns with one element, in that sense contents
Types can always receive values of other types.

For example, the definition of sim_cosine () is given as follows. The former implementation is cosine and the latter implementation is sim.

Function number sim # cosine (contents x, contents y) define-by "http: // fqdn / path / common / vecspace # cosine" function number article.sim \ #cosine (ocntents x) define-by "http : // fqdn / path / dtd1 / article # sim "5. Conversion to XSLT description This section describes the conversion of this operation description to XSLT description. This makes it possible to construct a prototype system for this operation description processing system using the existing XSLT transformation system. 5.1 XSLT XSLT is an XSL (XML style sheet language) being developed by W3C.
This is a conversion language used in this example, and is rule-oriented similarly to this operation description method. An XSLT description is called an XSLT style sheet. The XSLT stylesheet is described as an XML document and mainly consists of the following templates and extension function definitions.

In the following, the following conversion rule will be described as an example. This means that <item> in <document> is replaced by <number>
Sort in order.

[0076] The template corresponding to the above operation description is as follows.

[0077] 5.1.1 Template The XSLT stylesheet is composed of multiple templates. This corresponds to the conversion rule of this operation description method.

Xsl: template Defines a template and has the following basic structure.

[0079] <Xsl: template><match> attribute is the first in the conversion rule
It corresponds to the condition description in the where clause, and selects the application target. <!-Processing-> contains XSLT equivalent to other sections.
Document elements defined in, for example, <xsl: v
ariable> and <xsl: for-each>.
These are interpreted by the XSLT processor. For other document elements, variables and the like are expanded, and the result is output as a literal. Each node selected by <match> is treated as current. The inside of the template is applied to this current, replacing the current with the result. Here, a node corresponds to a document element, attribute, text, or the like in a document, and its parent-child relationship, affiliation relationship, and the like are represented by a parent-child relationship in a tree.

<Match> describes a path expression called a location path. For the location path, select the terminal node excluding [] described below. The main notations needed to convert the example in verse four are: (1) ``. '' Selects the node itself, and (2) `` .. '' selects the parent node. (3) a / b is a child of <a><b
>, (4) a / @ b is <b> which is the attribute of <a>, (5) is <a> that satisfies condition x, and (6) a / node () is all of <a> Select child nodes of The condition X can also describe a location path, and a plurality of conditions can be combined by and, or.

Xs: variable Constrains a variable. <Name
> Specify the variable name with the attribute, and specify the value with the <expr> attribute or the description contents. This can be used as a value to describe the attribute and is referenced by prefixing the variable name with "$".

Xsl: for-each A nested query is implemented using this. This applies each node selected by the location path specified by the <select> attribute to its description contents. Corresponds to nested where clauses.

Xsl: sort This can be given as a child element of <xsl: for-each>, and its output is sorted by the sort key specified by the <select> attribute. Also, by specifying a plurality of them, sorting in dictionary order can be performed. orde
It directly corresponds to the r-by clause, and the rank-by clause is also realized using this.

Xsl: copy-of <select> Copies the node selected by the attribute location path.

In the template example at the beginning, for the input <document>, a <document> is created as an output, and the inside thereof is generated by <xsl: for-each>. Inside this, all <items> having <number> as a child are copied by <xsl: copy-of>. Also, the results are sorted by variable $ n or <number>. As a result, processing equivalent to the conversion rule is described.

Since the variables $ d and $ i are not actually used and $ n can be directly expanded, the above template can be simplified as follows.

[0087] xsl: if <xsl: if> and <x
sl: choose> can be used. In particular, <xsl: if> replaces <test
> The description content is applied only when the conditional expression described in the attribute is true. 5.1.2 Extended function This corresponds to the definition of a user function.

Xsl: functions This declares a function and does not become a child of another element. The <ns> attribute specifies the name of the namespace to which the function belongs. If there is a <code> attribute, use the implementation specified by the URI with <ns> as its prefix, and <xsl: func if not provided
The implementation is given in the description of <tions>. In XSLT, 4.
Since the function name cannot be used with a different name from the implementation as shown in Section 3, the implementation name must be unique. Example: The implementation of the program used as func () is http: //
When included in fqdn / classpath / classname, it is described as follows. Here, the namespace global is `` http: // f
It is assumed to be defined as qdn / classpath ''.

[0089] 5.2 Conversion method to XSLT 5.2.1 Processing mechanism When converting from the conversion rules to the style sheet, it is first clarified how to use the XSLT processing system. Although the proposed description method realizes multi-step processing by specifying the matching target, XSLT does not directly support this.
Therefore, in order to perform multi-stage processing, it is necessary to apply the style sheet a plurality of times. That is, the XSLT processing system must be called multiple times from a higher-level module. Since the number of times of application is document-dependent and cannot be determined in advance, it is necessary for a higher-level module to determine at the time of document operation that application of a style sheet is no longer necessary. Therefore, when a template that requires further application of the style sheet is applied, this is notified to the upper module using the extension function NOTIFY (). As a result, if there is no notification by the end of the application of the style sheet, the upper module can end assuming that all processes have been completed. 5.2.2 Conversion to Template Next, the main points when converting individual conversion rules to templates will be described. Here, only conversion rules that satisfy the following conditions are targeted.

It is assumed that there is no description using a subset of regular path expressions according to XML-QL. This is because XSLT cannot handle them directly.

It is assumed that there is no nesting of sub-blocks and document elements for which <ID> is specified by the Skolem function. 1. Basic conversion where, order-by, con in conversion rules
The basic structure of a struct clause is converted into a document element as described in 5.1. Here, in XSLT, the previous <xsl: templ
ate><match> attribute and <xsl: for-each><select>
Although the terminal node at the end of the location path such as the attribute is the starting point, in the proposed description method, the document structure specified by the where clause is specified by the node to be matched or the specification by in.
This must be taken into account when translating structural conditions. 2. Matching target specifier The document element for which this is specified is always subjected to pattern matching. For this reason, the NOTIFY ()
Need to be called. 3． first clause The corresponding process is realized as a two-stage process using NOTIFY (). In the first execution pass <
xsl: sort> to generate a sequence of results, and in the next pass, output only the specified number at the beginning. 4. rank-by to top clause This is the same as the first clause, but in order to preserve the final output order, save the position as follows and perform a two-step process. <Xsl: s in the first pass
ort> generates a result in the order specified by the rank-by clause. At this time, a position in the original document is added to each element. In the next pass, extract the specified number of records at the beginning. Further, a final result is generated using <xsl: sort> again according to the added original position information. 5. Skolem function The return value of the Skolem function has a one-to-one correspondence with the argument value. That is, the uniqueness of <ID> given by this is equal to the uniqueness of the set of argument values.
Therefore, the grouping realized by this transforms to the next procedure. First, <ID> by Skolem function
Selects only the first one of the same document elements. This is realized by determining the consistency of a set of values using <xsl: if>. Then, a description for extracting a result corresponding to the grouping result therein is made. This is <xsl: for-
By using each>, it is only necessary to generate a necessary structure for all objects to which the same <ID> is assigned. By the above,
A grouping result is obtained for each value of the Skolem function. 5.2.3 Generation of Style Sheet Using the above-described template generation method, a style sheet is generated according to the execution path. 1. Correspondence table for name conversion Prepare unique aliases for each of the specified collation targets. This is used in order to limit the pattern matching target in the following to the document element designated as the matching target. 2. First-pass style sheet For all conversion rules, replace the name of the document element specified as the matching target in the construct clause with an alias according to the correspondence table. Convert this to a template and use it as a style sheet.
This makes it possible to apply the template only to the collation target in the next pass and thereafter. 3. Stylesheets after the second pass Remove any conversion rules that do not match any document element specified for collation. For the remaining ones, the document element name designated as the collation target and the one appearing in the condition part are replaced in accordance with the correspondence table, and the template converted therefrom is used as a style sheet. As a result, only the document element designated as the collation target in the previous pass becomes the target of application of the template. In addition, since the portion where the output is not specified as the collation target is not replaced, the original name is automatically returned by applying the template. Therefore, the template is not excessively applied to the processed document element. 4. Style sheet at the end Because the above is output with the name replaced, if there is no matching template, it ends with an alias. To solve this problem, apply the style sheet that performs the reverse replacement according to the correspondence table when the application of style sheet 3 is completed. 5.3 Conversion example A part of the result of converting the conversion rules into the XSLT description according to the above rules is shown below. Templates 1 to 3 correspond to conversion rules 1 to 3, respectively.

Here, template 1 is a template generated from conversion rule 1. The grouping by this Skolem function is converted to <xsl: if> and below. Conversion rules 2 and 3 are
2, 4 and 3, 5 have been converted. In particular, conversion rule 2
The first clause of template 4 is
The by to top clauses are implemented in Template 5.

Of these, template 1 is used as a style sheet for the first pass, and the rest is used as a style sheet for the second and subsequent passes. 5.2 for the first pass style sheet
Other templates generated according to the method of section are included, but are not actually used, so the description is omitted.

Note that the document element name specified as the collation target is `
Adds the ending of `. This ending is removed after all processing is completed. <!-Template 1-><xsl: template match = "document"><document><xsl: for-each match = "article"><xsl: variable name = "d" expr = "post date" / ><xsl: sort select = "post date"/><!-Grouping by Skolem function: Apply only to the first <article> of each <post date>-><xsl: if test = "count (from- preceding-siblings () [Date = $ d]) = 0 "><!-#<daily>-><xsl: variable name = DMY" expr = "NOTIFY ()"/><daily- Matching target><xsl: for-each select = "../ Article [Posted date = $ d]"><xsl: copy-of select = "."/></ Xsl: for-each></ By day -Collation target></ xsl: if></ xsl: for-each></document></ xsl: template> Extensible XML query language X ² QL and its processing system 1. Introduction Recently, construction of various document databases In particular, with the remarkable spread of the Internet, there has been an increasing demand for the construction of XML and other structured document databases and the advancement of their use.
Various query languages have been proposed as basic processing description languages for structured document databases.

Representative examples of query languages for XML include XML-QL and XQL. Also, Lorel, UnQL, St
Some query languages for semi-structured data such as ruQL, YATL, etc., assume that XML structured documents are one of the applications. Many of these have high query description capabilities with high-level declarative descriptions, especially XML-QL
Some semi-structured data query languages provide relatively powerful reconstruction capabilities for document structures. But diversification,
It cannot be said that sufficient functions are always provided as follows in response to complicated document processing requirements.

In the process description for the structured document database, it is necessary to handle both the process for the document structure given by the hierarchical structure of tags and the process for the description content given by the character string text. In the aforementioned query language, relatively powerful structural operations can be described declaratively. On the other hand, only very limited functions are provided for the description content processing. For example, processing that goes into the content of the description, such as selecting a document element that includes a partial character string that matches a specified phrase or pattern, is not performed. In particular, in order to efficiently obtain the desired information from a large number of structured documents, more detailed processing, such as narrowing down document elements based on the degree of semantic similarity with a given keyword group, Description processing functions such as ranking, document element summarization and topic extraction are important. Also,
There are also application processes that are difficult to describe declaratively for structural operations. In such a case, a more detailed and specific description ability is required. On the other hand, these functions are not necessarily general-purpose, and generally depend on the characteristics of the document element to which the processing is applied and the purpose of the query. For example, a particular document element such as a heading contains more important words than other document elements. Therefore, a process of giving a large weight to a word appearing in a heading may be performed. Also, in the description content processing method, various methods have been proposed for automatic summary generation, topic extraction, and the like.

Therefore, it is not realistic to provide those functions comprehensively. In order to solve this problem, it is necessary to allow the query language to have flexible extensibility so that the user can introduce necessary processing functions according to the purpose. In this research, in order to solve such problems, in addition to the document structure operation function of the query language for structured documents, the extensible XML query language X ² QL, which enables the integrated use of the extensible description content processing function, was developed. suggest. X ² QL is XM
This is a query language extended based on L-QL, and the extensibility of the description processing function is given by a user-defined function. By introducing functions as needed, the user can externalize processes that are difficult to declaratively describe as queries and use them as extended functions through function calls. As a result, in addition to the original document structure operation function of XML-QL, higher-order description processing functions such as similarity search and summary generation can be used. This paper also describes a method for transforming an X ² QL query into a document operation based on XSLT under certain restrictions and implementing a processing system. Also,
The implementation is actually performed using this.

In the dissertation, the basic concept of an XML processing system using document structure conversion rules and description contents processing functions has been described. In this research, we focus on the extension of the latter, and conduct a more in-depth study including implementation.

In the following, first, in Section 2, an example of an inquiry to a structured document realized by using both the document structure operation and the higher-level description contents processing will be described. Next, Section 3 outlines XML-QL, and Section 4 details X2QL. Section 5 describes how to convert X2QL queries into XSLT descriptions. 2. Example of Query for Structured Document This section shows an example of a structured document query that requires a function of description content processing in addition to document structure operations. Section 4 describes X2QL using the example of this section. In the following, a document element name of "identifier" or its document element is described by <identifier> as necessary. In addition, attributes are similarly described. Example 1 Consider an XML document organized as a newspaper article database. Each article has a publication date,
The DTD of the document, including the headline and body, shall be given below.

<!-DTD of input document-><! ELEMENT document article +><! ELEMENT article (posting date, headline, text)><! ELEMENT text paragraph +><! ELEMENT posting date #PCDATA>< ! ELEMENT Heading #PCDATA><! ELEMENT Paragraph #PCDATA> For such an XML document, separate articles by publication date,
Add a summary to each article. To achieve this, <
A document structure operation called grouping by publication date> and a description content process called summary generation are required. Example 2 Assume the XML document from Example 1. Suppose your reader is interested in an incident and you want to extract from this document the top N articles that match your interest. This is the selection of articles based on the interests of the reader, and in this case, it is necessary to judge the match with the interests or to process the description contents for measuring the criteria. 3. XML-QL The query language X ² QL proposed in this paper is based on XML-QL, one of the typical query languages for XML. This section describes the XML required to understand the following
Describe the function of -QL. 3.1 XML-QL query XML-QL is a query language for XML documents, and its basic syntax is given below.

[0101] For example, in Example 1 in the previous section, omitting the addition of a summary would be written as follows: Output contains <daily> column <document>
Where <daily> has the same value <post date><article>
In the column.

Where <document></> content # as $ x construct <document> where <article><postdate> $ d </></> element \ #as $ a in $ x order-by $ d construct <Daily ID = DateID ($ d) Publication date = $ d> $ a </></> where clause Specify the document structure to be satisfied as query conditions and the conditions to be satisfied. This clause specifies the binding. A variable is bound to a document element, document element content, document element name, attribute name, or attribute value, and a predicate related to it describes the conditions that must be satisfied by that value. In particular, element # as $ x and content # in the pattern expression
as $ x binds the variable $ x with the contents of the immediately preceding document element and the document element with its tags removed. Note that this variable binding is performed for all matching combinations.

In the description example at the beginning, in the first where clause, <
The inside of document> is bound to $ x, each <article> in $ x is bound to $ a in the second where clause, and $ d is bound to the content of <post date>. construct clause This clause specifies the structure of the output generated from each combination of variables bound in the pattern expression of the where clause. The query result is a sequence of document elements obtained by expanding the variables of this description. where ~ cons in the construct clause
You can nest truct clauses.

The attribute <ID> of the document element to be generated is
The argument and the return value can be given by a Skolem function that has a one-to-one correspondence. At this time, document elements sharing a parent and having the same <ID> are aggregated into one document element entity. Grouping is realized using this.

In the example at the beginning, only one <document> containing the processing result of the subquery is generated. In the subquery, a <daily> column containing <article> ($ a) is generated. They are given an attribute <posting date> whose value is $ d which is the content of the element <posting date>. Also, <article> is grouped into <daily> by the skolem function <DateID ()>. order-by clause This clause specifies the output order of document elements.
Output descending for the specified key value, descending
If is specified, it is sorted in reverse order. In the example at the beginning, the output <daily> document elements are sorted in chronological order according to the value of the variable $ d and output. 3.2 Function definition The following syntax allows the user to define a function as needed. The query result in the function definition is the return value.

Function Function name (argument list) where-construct Query end Extensible XML Query Language X ² QL X2QL inquiry is described by syntax which is based on XML-QL. In addition, a user-defined function provided as an external program can be used during the inquiry, thereby making it possible to cope with a process that requires high function expandability. Section 4.1 describes the X ² QL query, and section 4.2 describes the user-defined function. Also,
A description example is given in section 4.3. 4.1 X ² QL query X ² QL was based on XML-QL in consideration of readability and compatibility with existing query languages. The extended basic syntax is shown below.

[0107] Of these, the where, order-by, and construct clauses are the same as in XML-QL. However, a user-defined function described later can be used as appropriate.

Rank-by to top clause This is a clause for designating a variable group bound by a where clause based on the rank of the ranking criteria expression of the element. In some query languages that extend existing SQL, etc., the number of output elements can be specified in combination with the sort specification. However, since the appearance order of document elements is significant in a document, the output order cannot be easily changed for the purpose of selection based on ranking. Therefore, it is necessary to strictly distinguish between the two specifications.

In X2QL, rank-by to top clauses are introduced to give designation of selection conditions by ranking. rank-b
Select only the number of choices given in the top clause at most from the top of the results sorted in descending order according to the ranking criterion expression in the y clause and pass them to the construct clause. On the other hand, order-by
Clause is c according to the output order standard expression, similar to that of XML-QL.
Sort output by onstruct clause. 4.2 User-defined functions Although the functions that can be defined in XML-QL are only those that can be described as queries, this cannot describe functions that perform flexible and detailed processing. In addition, since the functions required for advanced document processing are diverse, it is impossible to provide comprehensive functions by expanding the built-in functions. Therefore, in X ² QL, these problems are solved by providing a user-defined function as an external program in a general-purpose programming language such as Java.

The user-defined functions are divided into general functions applicable to unspecified objects and methods limitedly applied to document elements having specific document element names. This is meaningful in an object-oriented context by considering the type of a document element as a class and the actual document element as an instance. In particular, if the same purpose is used, but the specific processing method depends on the type of document element, etc., it is possible to give a kind of polymorphism by giving the processing as each method. .

For example, consider Example 1 in Section 2. Here, a user-defined function for generating a summary of <article> is defined. At that time, it is conceivable to give a unique implementation utilizing the characteristics of <article> such that a word included in <headline> is regarded as an important word and a summary is generated. Such a mechanism is particularly expected to work effectively in queries where an unspecified type of document element is bound to a specific variable. In Example 2, the keywords given by the user and <
By defining and using a function that calculates the degree of similarity with Article>, ranking processing becomes possible. Although various methods of calculating the similarity have been proposed, a method suitable for the purpose of the user can be used by the approach of this research. The definition syntax of the user-defined function is as follows. The method is used in the query in the format of "document element variable. Method name (argument list)".

Function data type function name (argument list) defined-by "URI including function implementation" function data type document element name.method name (argument list) defined-by "URI including function implementation" argument list :: = Data type Argument name [, Data type Argument name] * In the definition of the user-defined function, the type is explicitly given. Valid types for function arguments and return values are number, str
ing (character string), element (document element), and content (element content). Where the element and content types are ele
Corresponds to the type of the variable bound by ment # as and content # as. In particular, content # as takes as its value a column consisting of text (#PCDATA) and a document element. Since other types can be regarded as a sequence consisting of a single element, the content type can always receive values of other types.

The user-defined function required in the above example is defined as a summary generation method abstract () and a similarity calculation function sim.
If it is realized as #cosine (), the definition is given as follows, for example. The former shall return <summary> as a return value.

Function element article.abstract () defined-by "http: //fqdn/path/pkg.article#abstract" function number sim # cosine (content y) defined-by "http: // fqdn / path / common in .vecspace # cosine "Java mapping, Number in each of the mold package for X ² QL, String, Element, is treated as a class that implements the Content interface. These internal implementations are Java standard Double, String and W3C DOM.
Node, NodeList of the given. When a method is called, the document element itself is automatically added as an argument as an implicit first argument. That is, the implementation of the first method in Java is given in the following format. Identifier in implementation such as class name and method name is Ja
They are associated according to the naming rules of va. The document element name of self is checked by the query processing system before calling the method.

// Class that can be obtained from http: // fqdn / path / package pkg; class Article [Element abstract (Element self) [...]] 4.3 Query description example A description example of the query is shown below. In query description example 1, as in the example in section 3, in the output <document>, the <daily> column, which is the result of grouping all <articles> that matched the subquery by publication date, in chronological order. Generated. <Posting date> is added as the attribute. Also, in the output <article> is the method ab of <article>
<Summary> generated by stract () is added.

In query description example 2, the similarity calculation function sim
By using #cosine (), we narrow down by ranking and rank. This is achieved by rank-by to top sections. Here, the order of appearance in the input document is stored. 5. Conversion to XSLT description We used the approach of converting X ² QL contact the XSLT described, was performed a partial implementation on existing XSLT processors. Implementation was possible in a short time by using the existing processing system. Below, we first outline XSLT and describe the transformation and processing methods adopted in the implementation. 5.1 XSLT XSLT is an XSL (XML style sheet language) being developed by W3C.
It is a conversion language used in. The description is given by a plurality of conversion rules called templates, and is applied to a substructure that meets the conditions. This XSLT description is called a style sheet. The style sheet itself is also an XML document rooted at <xsl: stylesheet>, and is mainly composed of multiple templates given by the following description.

In the following, the following X2QL inquiry will be described as an example. This extracts [items] in <document>,
Sort in the order of <number>.

[0118] The template corresponding to the above operation description is as follows.

[0119] 5.1.1 Template The style sheet is composed of a plurality of templates, and the processing content is specified by the following description elements.

A location path XML document is a document element,
It is treated as tree-structured data with attributes, text (#PCDATA), etc. as nodes. In contrast, each process
Applied to individual nodes in the context node list selected by a path expression called a location path. In particular, the current application target is called a context node. The location path is described in a notation described below. When it is a relative path, it is evaluated starting from the context node.

The main notations required to convert the examples in this document are as follows. (1) ``. '' Is the node itself,
(2) ".." selects the parent node. (3) a / b is <b> which is a child of <a>, (4) a / @ b is <b> which is an attribute of <a>, and (5) a [x] is a condition <a> that satisfies x is (6) a / nod
e () selects all child nodes of <a>. Condition x is also described by a location path and a predicate.
Can be combined with and, or. Note that these are abbreviated notations, and in practice more detailed designation is possible, but the description is omitted here.

Xsl: template <xsl: template> defines a template and has the following basic structure.

[0123] The context node list is selected by this <match> attribute, and the processing for the context node is described in the above <!-Processing->. This is performed using the following document elements defined by XSLT, and is interpreted and processed by the XSLT processor. Document elements other than those specified in XSLT are output by expanding variables if necessary. This processing result is inserted at the current output position in the output document.

Xs: variable A variable is bound. <Nam
Specify the variable name in the e> attribute, and specify the value in the <select> attribute or the description. Also, refer to the value with `
This is done by adding `$ ''. This can also be used as a value that describes the attribute.

Xsl: for-each Binding of a plurality of variables and nested queries are realized using this. In particular, it corresponds to the where clause of a nested query. This applies the content of the description to the context node list selected by the location path specified by the <select> attribute.

Xsl: sort This can be given only as the first child element of <xsl: for-each>. Prior to the processing of the context node list, the specification of the <select> attribute is used as a key to Sort nodes. When a plurality of items are specified, sorting in dictionary order is performed. The order-by clause and the rank-by clause are implemented using this.

Xsl: copy-of <select> Copies the node selected by the attribute location path.

Xsl: if In XSLT, <xsl: if> and <xsl: choose> can be used to perform conditional branching. Especially <
xsl: if> is applied only when the conditional expression described in the <test> attribute is true.

In the example of the template at the beginning, for the input <document>, a <document> is created as an output, and the inside is generated by <xsl: for-each>. In this inside, all <numbers> under <items> are selected, and <items> to which they belong are copied in the order of the sorted result by <xsl: copy-of>. As a result, a process equivalent to the X ² QL query is described. The reason why <number> is processed before <item> in the first example is to enable the context node list to generate all of the output.

Here, the variable $ i can expand the part referring to the value into the location path, and the variables $ d and $ n are not used, so that the binding can be omitted. If only one <number> exists in <item>, an equivalent sort target node list can be selected only by selecting <item><xsl:for-each>. As described above, the above template can be simplified as follows.

[0131] 5.1.2 Extended functions In XSLT, extended functions can be used, and function calls having a specific namespace defined by the user as a prefix are treated as these extensions. However, the implementation / use method depends on the processing system, and if the extended function cannot be used, the processing system issues an error. The availability is fu
It can be determined by the nction-available () function. In the XSLT processor LotusXSL by IBM alphaworks used for the test implementation in this study, the Java implementation of the extension function is given by the following format <lxslt: component>.

[0132] Example: Suppose the definition of an extension function that uses the MyHead class implemented in the head namespace is given below. here
The read function is a method of MyHead that returns a specified number of characters from the beginning of the passed string.

[0133] An example of using this to extract the first 10 characters of a document is shown below.

[0134] 5.2 Overview of conversion and its application procedure The query processing system was implemented by converting an X2QL query into an XSLT stylesheet. This conversion requires the application of multiple style sheets depending on the description of the query. XSLT does not have a mechanism to apply style sheets multiple times, so a control program that implements this is required. The overall processing flow including this will be described below.

In the conversion of the query, only queries satisfying the following conditions are assumed.

It is assumed that the merging process or the like over a plurality of documents is not performed.

A regular path expression that specifies a closure including a specific document element name in accordance with XML-QL shall not be included. This is because XSLT cannot handle them directly.・ Document elements for which <ID> is specified by sub-blocks (where-construct clauses enclosed by '[',] '), which are used for outer joins, etc., and by the Skolem function,
Assume that they are not nested. 5.3 Conversion to Template First, for a query that does not include rank-by and order-by clauses, a method of converting individual descriptions of X2QL queries into descriptions in XSLT as described in Section 5.1 will be described. In this case, the processing is completed by applying the style sheet once. 5.3.1 Basic transformation The basic structure of the where and construct clauses and the binding of each variable are XSL
Corresponds to the basic description of T. The variables make use of all those used in X ² QL, plus some auxiliary variables. Variable binding is done by [xsl: variable].

In general, a plurality of variables are used in an X ² QL query. These variables are sequentially bound using <xsl: for-each>. The order of binding variables is construct
Determined by the order in which the output is constructed, as specified in the clause. This is because the description of the template represents the output structure. Regarding variables related to the configuration of the same node, the variable used for the Skolem function is given the highest priority, followed by the variable used for the sorting criterion and the others. If the same priority is given by this, the binding order in the query is used.

When a variable is bound, the specification of the structure pattern in the X ² QL query is converted into a description by a location path, which is specified relative to a context node or a path starting with a bound variable. Give in. In particular, if there is a document element that is a common ancestor, the closest common ancestor is bound to a variable and used for specifying a location path. This eliminates the need to derive a relative path that traces back to the appropriate ancestor, and facilitates conversion to a location path.

<!-Given query-> where <article><postdate> $ a </><headline> $ b </></> ... <!-Bind <article> Changed query to-> where <article> $ x </>, <post date> $ a </><headline> $ b </> in $ x ... <!-Changed query Template derived from-><xsl: template match = "article"><xsl: variable name = "x" select = "."/><Xsl: for-each select "Post date"><xsl: variable name = "a" select = "."/><!-Current is <post date> but not restricted-><xsl: for-each select "$ x / heading"><xsl: variable name = " b "select =" $ x / headline "/> ... </ xsl: for-each></ xsl: for-each></ xsl: template> In addition, by changing the context node list, Expressions whose evaluation values change are bound to variables when evaluation becomes possible. For example, the case where the position () built-in function for giving the position of the context node in the context node list is used is applicable. 5.3.2 Grouping by Skolem function The return value of the Skolem function has a one-to-one correspondence with the argument value. That is, the uniqueness of <ID> given by this is
Equal to the uniqueness of the argument value pair. Therefore, the description of the grouping is converted next.

First, only the first one of the document elements having the same <ID> by the Skolem function is selected. That is, in the context node list, the same <ID
Select a node that does not have a node given>. This is realized by <xsl: if> as in the following conversion example. Then, a result corresponding to the grouping result is extracted in the inside. Here, all nodes to which the same <ID> is assigned may be selected, and a necessary structure may be generated from each node. As described above, a grouping result is obtained for each value of the Skolem function.

[0142] 5.4 Mapping of User-Defined Function X2QL specifies a type in a user-defined function and defines a mapping to an implementation language. On the other hand, in XSLT,
Since the mapping method and the provision of the extension function are implementation-dependent, it is necessary to perform conversion in consideration of this point. In this implementation, the XSLT processor used LotusXSL, which can implement extension functions using Java.

The conversion / association of the user-defined function is performed before the query is converted into the style sheet, and the description of the function call in the style sheet is generated according to the association. These processing system-dependent functions are implemented as adapter modules.

First, the LotusXSL adapter module automatically generates a LotusXSL stub by referring to the definition of the function defined by the user-defined function in X ² QL.
This is a type of assumptions LotusXSL, performs conversion of the type used for user-defined function of X ² QL, a class group of relay. The method has a signature that replaces the argument types of each user-defined function according to the Java mapping in LotusXSL. In the internal implementation, each argument is converted into a type according to the Java mapping in X ² QL described in section 4.2, and the method of the class created in accordance with the conversion is called. The return value is converted in the opposite direction. At this time, a unique class loader is used to acquire the implementation class via the network. In addition, Java's reflection API is used to resolve information on classes and their methods at runtime.

Function element article.abstract () defined-by "http: //fqdn/path/pkg.article#abstract" // Java stub: here // class path file: // localhost / x2ql / article / / / Class name pkg.Article pacage pkg; class Article [Node abstract (Node self) [if (! LotusXSL # Adaptor.testElement (self, "article")) throw ...; // Get class ClassLoader ldr = X2qlClassLoader .getClassLoader ("http: // fqdn / path /"); Class cls = ldr ("article"); // Get method Class [] sig = new Class [1]; sig [0] = Element.getClass (); Method mth = cls.getMethod ("pkg.abstract", sig); // Method call Object [] args = new Object [1]; args [0] = LotusXSL # Adaptor.toElement (self); // Return Value Element rc = mth.involke (); return LotusXSL # Adaptor.toNode (rc);]] <!-Function definition in LotusXSL. Namespace is x2ql-article = "file: // x2ql / article /"-><lxslt: component prefix = "x2ql-article" functions = "abstract"><lxslt: script lang = "javaclass" src = "pkg .Article "/></ lxslt: component> 5.5 rank-by, order-by clause In general, processing a query that includes rank-by and order-by clauses requires applying a style sheet multiple times. .
As X ² QL query example using the XSLT description of Section 5.1, it is easy to determine the relationship between document elements and their sort key to be output, all one context node of the output document element to be sorted If it can be generated from a list,
Although it is possible to perform optimizations so that they can be processed simultaneously by a single style sheet, only the basic conversion method will be described here.

First, when only an order-by clause is included, it is realized by the following two-stage processing. -All outputs are generated with the evaluation result of the output order standard expression added. -Sort the output according to the evaluated reference value and remove the information added for work. On the other hand, when a rank-by clause is included, the following three steps are required.・ All outputs are generated in the form of adding the evaluation result of the ranking criteria formula. At the same time, if order-by is specified, the evaluation result of the output order standard expression is added, otherwise, the position information in the original document is added as the output order standard value.・ Sort the output according to the criteria for ranking, and limit the output to the required number. -The output is sorted again according to the reference value of the output order, and information added for work is removed. In the middle of the processing, a work document element is used. Here, a conversion result of a query including only the next rank-by clause is exemplified.

[0147] First, <x2qlorder> that contains the document element generated by the construct clause is generated, and the evaluation result of the reference expression and the original position information are added as its attributes. Furthermore, <x2ql: sort> is configured to make these elements. They are,
Used in style sheets applied to the second and third rounds,
Removed in the last applied style sheet.

[0148] Next, <x2ql: order> is selected as a context node list and sorted by <xsl: sort>. And <xsl:
Using if>, the required number is output according to the appearance position in the sorting result.

[0149] Finally, sort in the same way, the context node,
That is, the added information is removed by outputting only the child element of <x2ql: order>.

[0150]

[0151]

According to the present invention, it is possible to improve the flexibility and sophistication of the processing operation of the description contents without changing the existing query language for XML documents as much as possible.

[Brief description of the drawings]

FIG. 1 is a conceptual diagram of an XML document query language processing device of the present invention.

FIG. 2 is a diagram for explaining a relationship between an external function and a DTD.

FIG. 3 is a diagram illustrating a flow of an implementation process using XSLT.

FIG. 4 is a diagram illustrating a procedure for calling a method.

[Explanation of symbols]

 1 inquiry means 4 conversion means 5 execution means 6 external function storage means

Claims (5)

[Claims] 1. Inquiry means for inquiring about document data described in an XML document type, conversion means for analyzing the inquiry and converting it to an internal format, and content of the inquiry based on the converted internal format And an external function storage means for storing the external function for performing a process which is described in a general-purpose programming language and which cannot be performed by the description content processing of the query language. The inquiry means associates the processing content described in the general-purpose programming language with the processing content described in the XML language so as to perform processing according to a program described in the external function, and associates the external function with the processing content. External function defining means for defining, and when the external function is specified in the inquiry, the Means XML document query language processing apparatus characterized by performing a process in which the written in a general-purpose programming language by calls the external function. 2. The XML document query language processing device according to claim 1, wherein said execution means is an XSLT language processing device. 3. The XML document query language processing apparatus according to claim 1, wherein the external function is a function described in the general-purpose programming language and corresponding to a summary generating unit that generates a summary from a document. . 4. The apparatus according to claim 1, wherein the external function is a function corresponding to a similarity extracting unit that determines a headline item of the document and a degree of similarity and extracts a paragraph related to the headline of the document. 2. The XML document query language processing device according to 1. 5. The XML document query language processing apparatus according to claim 1, wherein said external function is a document character extracting means for extracting a first line from a text of the document.