1. Field of the Invention
The present invention relates to methods and systems for constructing XML query, more particularly, to methods and systems for constructing XML query to schema variable XML documents.
2. Description of the Related Art
XML (eXtensible Markup Language) has been widely adopted in many domains to store and exchange data. In some domains, for example, the CDA (Clinical Document Architecture) for the healthcare industry or the XBRL (extensible Business Reporting Language) for the financial industry, the variable schema, which is a set of XML documents that share a similar but not an identical XML schema, is a common feature that makes it difficult for users to consume data in XML documents.
In order to construct a correct XQuery/XPath to extract data from these XML documents, users must completely understand each schema and how each data element in each schema relates to other elements, that is, the relationship of XML elements in a same XML document tree and the relationship of different XML trees, which usually takes too much effort or in some extreme circumstances (e.g., when there are too many schemas) may be impossible for users.
MDA (Model-Driven-Approach) modeling methods are used in many fields in order to use unified syntax to express and exchange complex data in a flexible manner. Using this methodology, by defining and modeling semantics, vocabularies, data structures and data at levels of meta model, model (schema) and instance respectively, different users can make extension/derivation from basic schemas according to their different requirements, so that various data express and exchange requirements can be satisfied under different circumstances.
FIG. 1 shows an XML modeling architecture which follows the MDA methodology 1000. The top level of the architecture is a Meta Model layer 1010, which includes the definitions of syntax and semantics of modeling notations, a Model level 1020 is defined according to the Meta model, which includes a terminology model 1021 defining common vocabularies and terms of specific domain, and a schema model 1022 defining common data structures of how to organize the common vocabularies and terms. At the lowest level, Data 1030, i.e., Instance layer, is provided under the Model level 1020.
FIG. 2 describes the hierarchical MDA modeling methodology shown in FIG. 1 using the XBRL as an example. As shown in FIG. 2, in the XBRL specification defined by the XBRL international organization, a Meta model is defined, including notations that can be used by financial reports to tag reporting items. For example, the ‘substitutionGroup’ attribute of each reporting item in a financial report should be tagged as either “item” or “tuple”. Based on the meta model, regulators such as the SEC (Securities Exchange Commission) have defined some basic schemas and terms, e.g., vocabularies of reporting items. For instance, the SEC has defined the reporting item “Revenue” to be used in financial reports, and “Revenue” elements can be represented in income statements. Companies can extend these basic schemas by themselves to customize their own reporting templates. For example, if Company A has a definition in its schema extension, “Income”-“Revenue”, then in the income statement of Company A, element “revenue” should be represented as sub node of element “income”. If Company B has a definition in its schema extension “Accrued Income”-“Revenue”, then this indicates that element “Revenue” is sub node of element “Accrued Income” in the income statement of Company B. Each company can also have specific data facts according to the extended schemas, e.g., specific data of reporting items defined in these schemas. For example, the value of the reporting item “Revenue” in the financial report of company A is “1,000,000 USD”, the value of the item “Revenue” in the report of company B is “1,500,000 USD”.
FIG. 3 describes the hierarchical MDA modeling architecture shown in FIG. 1 using the CDA as another example. As shown in FIG. 3, the CDA international organization has defined the syntax and semantics of notations that can be used by electronic clinical documents, e.g., a clinical document include data for specific elements such as “Entity”, “Observation”, “Symptom”, “Body Structure”, etc. Based on the above syntax, a standard organization, SNOMED (Systematized Nomenclature of Medicine) has further defined some common terms, i.e., vocabularies of clinical data. For example, SNOMED has defined terms, such as “Shadow” for “Observation” and “Chest” for “Body Structure”. Based on such common syntax and terms, hospitals and equipment manufacturers can create extensions on the basic schema to obtain their own CDA document schemas. For example, hospital A can define a nested structure like “Entity”-“observation”-“body”-“symptom” and hospital B can define a nested structure like “Entity”-“body structure”-“symptom”. Hospital A can produce data facts like “Tom”-“SNOMED CT”-“Chest”-“Shadow”, indicating “a shadow of Tom's chest observed with SNOMED CT”, which corresponds to the above schema: “Entity”-“observation”-“body”-“symptom”; and hospital B may produce data facts like “Lee”-“Chest”-“Shadow”, indicating a shadow of Lee's chest, which corresponds to the above schema “Entity”-“body structure”-“symptom”.
Users can query data in above XML documents. As shown in FIG. 2, financial data consumer (e.g., bank or investor) may want to know “the revenue changing trends of companies A and B in the past three years.” Similarly, as shown in FIG. 3, a clinic data consumer (e.g., doctors or medicine makers) may want to know “the list of patients with shadow in chest.” However, under existing techniques in the prior art, it is difficult to formulate queries because even though XML documents share a common syntax and vocabulary model, they can still be based on different schemas or data structures. When constructing an XML query for a document, even though there is a common vocabulary model that covers all elements involved in the queries, users still need to know the specific schema of each instance document. Data consumers have to understand each extended schema in order to correctly the XQuery/XPath thereby imposing a heavy burden on users.
An XQuery/XPath is a known query language in the prior art. XPath is a language for selecting nodes from XML documents. XQuery is a query language (with some programming language features) designed to query on XML data sets.
Referring to FIG. 2, even though the financial report of companies A and B share the common vocabularies for income statements (e.g., “Revenue”), they have different data structure to organize these same elements because of their own schema extensions. When querying the “Revenue” of companies A and B, the specific schema structures have to be understood by a user, i.e., in the extended schema defined by company A, element “Revenue” is the child node of element “Income”, and in the extended schema defined by company B, element “Revenue” the child node of element “Accrued Income”. It is necessary for users to get above information to construct a correct XPath/XQuery.
Referring to FIG. 3, although sharing the common syntax defined by CDA and the vocabularies defined by SNOMED, it is still possible for hospitals to extend the basic schema to obtain customized schemas that are suitable to their own business requirements. Examples include different customized schema like “Entity”-“observation”-“body”-“symptom” and “Entity”-“body structure”-“symptom”. When answering questions like “patients with shadow in chest”, information about detail structures of each different schema is required. For example, with respect to patient “Tom”, the element “Shadow” is sub node of element “Chest”, which is sub node of element “Observation”, which in turn is the sub node of root element “Tom”. As to patient “Lee”, the element “Shadow” is sub node of element “Chest”, which in turn is the sub node of root element “Lee”. Accordingly, if there are a number of extended schemas, users need to know the specific structures of each schema in order to construct queries even if those schemas share the common syntax and vocabularies, i.e., the basic schema. This is an unnecessary burden to users.
FIG. 4 shows a set of shared vocabularies, including “element 1” to “element 5”. These elements are referred by the extended schemas shown in FIGS. 5a and 5b, but they are organized in element trees with different structure in the extended schemas respectively. Comparing the different schemas shown in FIG. 5a and FIG. 5b, it can be seen that information of specific element nesting paths is required even though the same elements are queried. Therefore, in the prior art, when querying on XML documents with these extended schemas, for example, when querying elements 3, 4 and 5, paths to the elements being queried in the corresponding XML documents are first determined before constructing queries according to those paths. As mentioned before, this approach has a significant drawback because users have to know the specific structures of each schema.
Another existing approach in the prior art is a schema-less query by wildcard. However, wildcard queries can lose the relationship between elements being queried, and therefore is limited to queries for a single element. In the case where multiple elements are involved and the relationship therebetween has to be considered, wildcard queries cannot return desired results.
FIG. 6 shows the above shortcoming of wildcard query. A simple XML schema is shown on the top of FIG. 6, where “element—1” (sub node) and “element—2” (sub node) are located under “element_a” (root node).
An XML document is provided in FIG. 6:
<element_a>  <element_1>1-1</element_1>  <element_2>1-2</element_2></element_a><element_a>  <element_1>2-1</element_1>  <element_2>2-2</element_2></element_a>
The above XML segment has two data facts for “element_a”, each of which includes two data facts “1-1”, “1-2” and “2-1”, “2-2” for “element—1” and “element—2” respectively. Assume a user want to get all of data facts of “element—1” and “element—2”. When making a wildcard query (that is, a schema-less query), the user inputs query “\\element—1” and “\\element—2”, and gets query results shown at the bottom of FIG. 6. Although data facts “1-1”, “1-2”, “2-1”, and “2-2” are returned, the fact that the data facts “1-1”, “1-2” should be joint and data facts “2-1”, “2-2” should be joint are lost. In fact, what user really expects is the table shown in the middle of FIG. 6, wherein data facts “1-1”, “1-2” and data facts “2-1”, “2-2” are associated with each other respectively.
Therefore, existing approaches do not support how to make a query of data in schema variable XML documents even users do not have any knowledge about the data structures of specific XML schema, while the relationship between the elements are maintained in the returned query results.