WO2008003310A1 - Verfahren zur kompression einer datensequenz eines elektronischen dokuments - Google Patents

Verfahren zur kompression einer datensequenz eines elektronischen dokuments Download PDF

Info

Publication number
WO2008003310A1
WO2008003310A1 PCT/DE2007/001205 DE2007001205W WO2008003310A1 WO 2008003310 A1 WO2008003310 A1 WO 2008003310A1 DE 2007001205 W DE2007001205 W DE 2007001205W WO 2008003310 A1 WO2008003310 A1 WO 2008003310A1
Authority
WO
WIPO (PCT)
Prior art keywords
sequence
data sequence
data
compressed
constants
Prior art date
Application number
PCT/DE2007/001205
Other languages
English (en)
French (fr)
Inventor
Stefan BÖTTCHER
Rita Steinmetz
Original Assignee
Universität Paderborn
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Universität Paderborn filed Critical Universität Paderborn
Priority to DE112007001386T priority Critical patent/DE112007001386A5/de
Publication of WO2008003310A1 publication Critical patent/WO2008003310A1/de

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction

Definitions

  • the technical field of the invention is the transmission, storage and evaluation of digital data, in particular in the operation of computer networks.
  • the invention relates to a compression of a data sequence of an electronic
  • Document in particular an XML document, by means of a structure definition to the data sequence, in particular a DTD, which comprises at least one substructure of the data sequence at least one declaration comprising unary operators or unary and binary operators of a syntax tree representing the substructure, including at least one unary Kleene-
  • the invention further relates to compressed data or files generated by such a method.
  • the invention also relates to methods for decompressing and evaluating requests for such compressed data or files.
  • XML Extendable Mark-up Language
  • a document contains constants such as text components and structure data.
  • the structure information contained in the XML file is an advantage of XML since it contains semantic information and navigation aids.
  • the contained structure information inflates the document in comparison to the contained text values and path specification to constants such as text values, especially XPath requests often require to navigate through similar or even similar structures several times.
  • Fig. 1a illustrates an XML document. This has textual data as constants, e.g. "John Smith.” It has structural data in the form of tags such as ⁇ author> or ⁇ name>, and the tags also serve as startup icons or as terminal icons such as the startup symbol ⁇ name> or the terminal symbol ⁇ / name>.
  • Amount of data and determined by the complexity of their processing determines the lifetime of the batteries and the maximum runtime of the devices without external power supply.
  • Fig. 1b illustrates to the XML document of Fig. 1a a DTD which defines elements of structure data of the XML document. Categorized DTD
  • Document data in at least the three categories: elements, attributes and entities / entities. These categories are optional.
  • the XML document of Fig. 1a and the DTD of Fig. 1b contain no attributes.
  • FIG. 3a represents an XML document and FIG. 3b represents a DTD corresponding to it, in which the attributes "order number" and "rush" are provided.
  • SAX Simple Application Programming Interface for XML
  • SAX parsers are available that continuously read document data as a sequential data stream.
  • a SAX parser may represent the sequence of events:
  • Blocks such as length or number of characters generated and saved.
  • a path query to constants, only one block and not the entire compressed XML document must be decompressed.
  • the path request is translated into such a signature, which serves by matching the identification of the block with the corresponding signature.
  • the disadvantages are the translation and
  • a DAG (directed acyclic graph) is a representation of the Data structure of an XML document that builds on such a sequence of events (SAX data stream) generated with a SAX parser. DAGs provide elements of a SAX data stream with indices. For compression, repetitive data sequences of the SAX data stream can be replaced by pointers to such indices. This creates, for example, the following DAG data stream from the sequence of events obtained above by SAX parsing with the pointers "pointer (6)" and "pointer (8)":
  • the invention has for its object to remove the redundancies mentioned, thereby enabling a smaller data size. It also allows for a lean index on the data so that path requests (e.g., in the form of XPath for XML data or query languages based thereon) can be efficiently answered. Since the method can also compute a partial output for a partial input such as part of an XML document, the method is not limited to XML data that fits completely in main memory, but can be e.g. also be applied to very long data streams. The object of the invention is to provide an alternative to the prior art with such advantages.
  • the invention improves a method for compressing a data sequence of an electronic document, in particular an XML document, by means of a structure definition to the data sequence, in particular a DTD, which comprises at least a substructure of the data sequence at least one declaration, the unary operators or unary and binary Operators of a parse tree representing the substructure, including at least one unary Kleene operator, having as argument the number of possible repeats of the substructure in the data sequence, the data sequence comprising:
  • Structure information of the data sequence in particular tags, which start and terminal symbols to the constants and to the substructures of the Comprise data sequence of at least some of the constants and the structure information.
  • the improvement is the one generation a) from the data sequence of a first Komprimatsequenz, the values of the
  • the invention provides a method for compressing a data sequence of an electronic document, in particular a partially compressed XML document, by means of a structure definition to the data sequence, in particular a DTD, an XML schema, a Relax NG compact or a Relax NG
  • Schemas wherein the structure definition defines at least a substructure of the data sequence and comprises the data sequence:
  • generations a) and b) are different data processing, they may alternate in carrying out inventive methods to to generate a data stream in which respective parts of the first and second compressed sequences alternate with each other.
  • the data sequence is e.g. an indexed sequence as shown at the beginning, such as the sequence of DAG events.
  • the representatives of the values of the constants may be indices of a trie.
  • the compression method according to the invention further has features of at least one of claims 2 to 8.
  • the invention also relates to a compressed data sequence of an electronic document obtained by a method according to the invention and computer files with such compressed data sequences.
  • the invention also relates to the decompression of a compressed according to the invention data sequence, characterized by
  • the transformed data sequence is transformed back to the
  • Path expression requested constant in the compressed sequence by summing up the products.
  • An optional sequential step is the decompression of a portion of the compressed sequence that in the data sequence of the substructure with a through the
  • Path expression requested constant corresponds, according to a method of the invention.
  • a method is also possible wherein the calculated position is that of a pointer in the compressed sequence, characterized by decompressing a portion of the compressed sequence to which the pointer points.
  • the invention also includes a computer program product implementing one or more of the methods of the invention.
  • the invention thus shows a structure-oriented index, i. an index that provides efficient access to the structural information without the need to decompress the compressed XML data stream.
  • the goal of the indexing technique is to use the structural information given by the element declarations to determine the index positions of specific textual values.
  • a basic idea of our structure-conserving compression method is thus that the structural information that is redundant due to the given DTD, to minimize.
  • a basic idea of our index access to the compressed XML data is to calculate the size of all XML document subtrees, and to use these computed subtree sizes to determine how much of the compressed XML stream can be skipped an element which eg is specified by an XPath request.
  • a compressed XML document is referred to in the following cXML document.
  • Fig. 1a exemplifies XML data
  • Fig. 1 b exemplifies a DTD associated with the data of Fig. 1a;
  • Fig. 2 generally illustrates syntax trees from the element declarations of
  • DTD of Figure 1 b is dar
  • Fig. 3a exemplifies XML data containing attributes
  • Fig. 3b exemplifies a DTD associated with the data of Fig. 3b;
  • Fig. 4 concretely illustrates the syntax trees of the element declarations of
  • FIG. 5 schematically illustrates generation of grammar rules employed in the invention
  • FIG. 7 schematically shows a method according to the invention for data decompression
  • FIG. 8 schematically shows a method according to the invention for evaluating path expressions on data compressed according to the invention
  • FIG. 9 schematically shows bundles of the data streams of data processing schematized in FIGS. 5 to 8.
  • FIG. 9 schematically shows bundles of the data streams of data processing schematized in FIGS. 5 to 8.
  • Sequence operator ',' With the aid of a sequence operator, an order of the child nodes is defined.
  • ' The choice operator specifies an alternative or exclusive selection from a set of possible child elements.
  • Kleene-Operator '*' It's a repeat operator that works for a lot of
  • Children elements can set the number of possible repetitions and can also specify a minimum and / or maximum number of repetitions.
  • Options operator '?' It determines for a child node that this is optional, ie it may occur either 0 times or 1 time.
  • the Kleene operator '+' shown in FIG. 4 is the Kleene operator of a subtree of an element declaration
  • any right-hand side of an element declaration can be considered a regular expression consisting of 0 or more child elements or the #PCDATA expression or the EMPTY expression using the operators Sequence (,), Choice, (
  • the (+) operator can be expressed by the sequence and the Kleene operator, ie (E) + is replaced by (E, (E *)).
  • the (?) Operator may be replaced by the choice Operator and the EMPTY expression, ie we replace (E?) With (E
  • the DTD shown in Figure 1 b contains element declarations, not attributes.
  • One of the element declarations of an element E1 of the DTD shown in FIG. 1b has the
  • a parser which compares the structure-defining information of the DTD with an associated, ie valid XML document, are implemented with operator types schemes for the structure-defining information of the types of nodes described below for determining the order and number of child nodes.
  • the element declaration of the DTD is parsed in step S1 and converted into a binary syntax tree in step S2 as shown generally in FIG. 2 for the XML document of FIG. 1a and from the DTD of FIG. 1b is.
  • Fig. 4 illustrates the syntax trees for the XML document of Fig. 3a and the DTD of Fig. 3b, respectively.
  • the structure-defining information is compared with a valid XML document. It is determined during parsing that much of the information in the structure portion of the XML data is redundant since it is already specified by the DTD. Specifically, the following operators are already defined by each element declaration: The names of all child elements, whether it is PCDATA
  • Figs. 2 and 4 are nodes to which operators are assigned, represented by the symbols of the corresponding operators given above.
  • I.ElementDeclaration (Name) A node of this type is created for each element defined by an element declaration. Each element declaration node has exactly one successor node, which is the
  • Root node of the subtree that represents the right side of the element declaration.
  • the name of the defined element of the element declaration is set as a parameter.
  • Child element A node of this type is created for each occurrence of an element in the right side of an element declaration. The name of this
  • Elements is set as a parameter.
  • a father-child relationship is set between the declared element and the child element.
  • the child element node has no successors.
  • PCDATA The PCDATA node is used when the right side of an element declaration contains the string variable '#PCDATA'.
  • the PCDATA node has no parameters and no successors.
  • the PCDATA operator assigned to it determines for an element that it contains a text node and not an element child node.
  • Sequence A node of this type is generated for each sequence operator ',' which appears in the right side of an element declaration.
  • a sequence node has no parameters.
  • Each sequence node has two descendants, which represent the two arguments of the sequence operator in the element declaration.
  • Choice A node of this type becomes '
  • a choice node has none Parameter.
  • Each choice node has two descendants that represent the two arguments of the choice operator in the element declaration.
  • the choice operator determines an alternative or exclusive selection from a set of possible child elements.
  • Kleene A node of this type is generated for every Kleene operator '*' that appears in the right side of an element declaration.
  • a Kleene node has no parameters. Every Kleene node has exactly one successor, which represents the argument of this Kleene operator in the element declaration.
  • EMPTY A node of this type is generated for each occurrence of string 1 EMTPY 'in an element declaration of the DTD.
  • Element declaration of the DTD sets an element-attribute relationship between the declared element and the attribute.
  • the DTD of Fig. 2b shows a definition ⁇ ! ATTLIST order ...>.
  • the set of start-terminal symbols for each node is calculated except for the root node of each element declaration syntax tree.
  • These sets of start-terminal symbols allow a parser, which is used to compress or process path expressions, to decide which grammatical rule to apply during parsing.
  • the set of start-terminal symbols is calculated according to the following relationships for the data and structures shown in FIGS. 1a, 1b and 2:
  • STS (sequence (a, b)): STS (a), if EMPTY i STS (a)
  • STS (sequence (a, b)): STS (a) u STS (b), if EMPTY e STS (a)
  • STS (Choice (a, b)): STS1 u STS2
  • STS1: STS (a)
  • STS2: STS (b)
  • STS (Kleene (a)): ⁇ EMPTY ⁇ u STS (a)
  • the set of start-terminal symbols of two sibling nodes that are successors of a choice node are always disjoint, so that the currently considered node of the input XML document always decides which alternative has been chosen.
  • Element Declaration Node the defined element as a parameter, and whenever a child element node appears as a successor of a node p, the grammar rule generated for P contains a child element call of the element element node of the element declaration syntax tree.
  • Element Declaration (E1) ⁇ »Kleene (NO, ⁇ E2 ⁇ ).
  • Kleene (NO, ⁇ E2 ⁇ ) - »sequence (N1, ⁇ E2 ⁇ ).
  • the extended grammar rule can be interpreted as follows: Consume a start tag of the element E1 from the input, dump nothing into the compressed XML file, and then continue with the application of the
  • each grammatical rule becomes a Kleene operator having a node ID Ni and a set S of start terminal symbols as parameters
  • Child element calls in a grammar rule result in a call to the grammar rule for the element passed as a parameter.
  • the example explains the application of the grammar rules for data compression according to the process scheme of FIG. 6.
  • the illustrated scheme has the following sequence of process steps: the above-mentioned step S3 of generating grammar rules, a step S4 of reading in a SAX event, a step S5 of applying the grammar rules to the SAX event, a step S6 of generating a compressed output
  • steps S4 to S6 loop through, so that the SAX events are processed sequentially.
  • the DTDs shown in Figures 1b and 3b contain five different operators: '?', ' * ', '+', ',' And,
  • ' are binary operators.
  • the DTD according to the above attribute grammar is needed only for the following three operator types in addition to the given structure-defining information from the present XML document of Fig. 1a, the original structure of that XML document from the
  • XML document shown in Fig. 1a and the DTD shown in Fig. 1b together contain the following information:
  • the paper has the title “XML Compression” and an author named “John Smith” who can be contacted via mailbox "0815" (second alternative) and has no email address.
  • the paper contains 2 chapters with the respective titles and
  • the second chapter contains no text (EMPTY), but instead contains two sub-chapters with the respective titles and contents. These subchapters, like the first chapter of the paper, contain no further chapters (as expressed by the number 0 in chapters).
  • step S5 With the above-explained additional information of the operators of the DTD shown in Fig. 1b and the constants of the XML document shown in Fig. 1a, this information is compressed by step S5 as follows:
  • PCDATA calls in step S5 associate each text constant with their respective ID, which is output in the output stream in step S6 ID.
  • a getlDfort function determines the ID of a given text constant, and if the text constant occurs for the first time, a new ID for the text constant is generated, and the pair
  • EMPTYO ⁇ > ⁇ ID: getlDfor (EMPTY) ⁇ , [] / [ID].
  • the trie assigns the ID, 00 'of the constants
  • step S5 the constants are assigned to ID as follows: Trie: 0815 (02) A (algorithms (07) pproach (06)) EMTPY (11) ln ((order to compress ...
  • the above cXML document 001012021103204050061120708009100 is divided into two parts: the above constant stream - 0001020304050607080910 and a document index stream with the structure information - 12112011200
  • This structure information represents the syntax tree, also called Kleene Size Tree, shown in FIG. 2 and contains the following content:
  • step S6 The constant stream and the document index stream are generated in step S6 according to the following two specifications:
  • the structure definition is identified by one of the three operator types (alternative, repetition or option)
  • the situation determined in the XML document that is the present alternative, the number of repetitions or whether an option has been selected in the present XML document, is included in the document - Index current written.
  • Example 3 Compression with removal of redundancies in the XML data
  • a DAG is constructed from the SAX event stream of the XML data of FIG. 3a as described in connection with FIGS. 3a and 3b and the publication by Koch et. al. was shown.
  • Incoming SAX events of the type startDocument, character, endElement, and endDocument that belong to a first occurring subtree are passed directly and unchanged as a DAG event to a second preprocess to remove redundancies based on the given schema information.
  • Incoming SAX events of type startElement that belong to a first-occurring subtree are split into a startEiement event and multiple attribute events.
  • an event startElement customer, attList
  • Incoming SAX events that belong to a recurring subtree are not forwarded at all. Only for the root of each repeated sub-tree W of a first occurring sub-tree E, where W is not part of a more comprehensive repeated sub-tree, a DAG event is generated and forwarded.
  • This DAG event contains a reference to the preceding DAG event startElement of the root element of the first occurring subtree. This reference is implemented as a relative distance backward reference, shown in the input DAG shown as pointer pointer (6) or pointer (8).
  • Example 2 the compression is essentially the same as in Example 2. Unlike Example 2, however, the DAG events are consumed.
  • a DAG event is a reference to a previous DAG event
  • a reference is made in the message as follows: If there is an entry in the document index stream for the preceding DAG event, a reference to that entry will be made is set, otherwise in the constant stream a reference is made to the position representing the first entry in the constant stream for this DAG event. Since each node n can be uniquely identified by the text node t reachable by a first-child path and the distance from t to n, a reference in the constant stream consists of the two-tuple (distance to node t, position of node t in the constant current).
  • the document index stream and the constant stream are calculated as follows from a set of given syntax trees and a DAG or SAX event stream.
  • the operations for traversing the syntax trees are:
  • Number of child nodes // Determines the number of child nodes of node n of a syntax tree generated from the structure definitions.
  • N.kindnode (i) // Returns the ith child node of node n in a syntax tree generated from the structure definitions
  • a source code example for the compression is as follows:
  • Event e readNextEventDomDAGStrom (); if (e is a pointer) ⁇ addPointer (e. id ()); deleteNextEventsDomDAGStromC);
  • Event e readNextEventVotnDAGStromO; if (e is a pointer) ⁇ addPointer (e. id ()); deleteNextEventsDomDAGStromO; ⁇ else ⁇ // e is startElement
  • ⁇ pos DocumentIndexStrom. write (i), IndexStore.add (e.id (), pos);
  • Event e readNextEventDomDAGStrom (); if (e is a pointer) ⁇ addPointer (e. id ()); deleteDown eventDomDAG stream (); ⁇ else ⁇ // e is startElement
  • Child element name ⁇ comp (elementDeclaration (n. Label O)); ⁇
  • Event e readNext ⁇ reportVomDAGStromO; deleteNextEventVomDAGStrom (); if (e is a pointer) addPointer (e. id ()); else ⁇ // e is attribute (id, name, value) constant store. add (e.id (), UNKNOWN); path.push (e.id ()); // put nodes on the stack write constant (e .value (] path.popO; ⁇
  • Event e readNextEventDomDAGStrom I write constant (e.label ()) ; ⁇
  • Table 1 below shows in the middle column the sequence of tokens of the document index stream from the DAG indicated at the beginning of FIGS. 3a and 3b and operators or nodes in the right column.
  • FIGS Depending on the operator, tokens may be repetitions, alternatives, or the presence of optional values.
  • a token is provided as a pointer to the six lines above the preceding token of the table. This represents the two consecutive similar table entries from this previous token and its successor.
  • Table 2 below shows in the middle column the sequence of constants of the constant current from the DAG given at the beginning of Figures 3a and 3b.
  • a token is a pointer to the eight lines above the preceding constant and its subsequent one Constants that correspond to the same element declaration are included in FIG. 3b and represent these constants.
  • the line entries are categorized, depending on whether they are pointers or not (ie, constants).
  • the corresponding event ID of the DAG events of type start event or attribute type is stored in main memory within a given window for the location of each token in the stream. If a reference V to a DAG event D is read as the next event instead of a DAG event of type start event or of type attribute, then it is first checked whether Current an entry E exists that represents D. If there is an entry E representing D in the document index stream, a reference to E is inserted in the document index stream for V. If there is no entry E representing D in the document index stream, V is represented by a reference in the constant stream representing the first constant stored in constant constant for D.
  • Kleene Size Tree This Kleene-Size-Tree is structured as follows: always if one
  • Kleene operator K1 appears within another Kleene operator K2, so K2 is contained in the subtree with the root K1.
  • Table 1 shows, the following is stored for each Kleene node in the Kleene size tree: How many index positions can be skipped in the cXML data stream if the subtree that has the Kleene node as its root, to answer the
  • Kleene size tree To use the Kleene size tree to access paths in the cXML stream, we need to know the following two things for each node of the Kleene-Size tree: the number of descendants and the position of the descendants in the index stream. In other words, we have to cross the Kleene Size Tree. Since the compression results of all other node types are fixed sizes, we can determine all relative positions using the Kleene Size Tree and Table 3.
  • the compresses also allow the evaluation of XPath requests on the compressed XML data stream.
  • XPath query to be evaluated can not contain any backward axes, as in Example 5 for the evaluation of XPath requests, an adaptation of the procedure from P.M. Tolani and J.R. Hartisa, "XGRIND: A Query / Request-friendly XML Compressor", In Proc. ICDE 2002, pages 225-234. IEEE Computer Society, 2002.
  • This approach optimizes the evaluation of XPath queries on XML documents, and in particular on XML data streams, so that the entire document (or stream) must be read only once.
  • the buffer size needed to temporarily cache elements depends on the use of filters.
  • the schema information of the DTD is used to reduce the computation time to decide the satisfiability of filters, and parts of the
  • Decompression of a compressed generated according to Example 3 occurs by reversing the order of phases executed for compression by: 1. decompression into a DAG event stream
  • the set of grammatical rules - interchanging the roles of input and output streams - is also used for decompression according to the process scheme of FIG. 7, with a step S3 of reading the grammar rules into a step S7, in which the syntax corresponding to the compression Trees are traversed.
  • a step S8 of the application of the grammar rules with tokens of the document required for decompression Index stream and the constant stream are consumed in a step S8 of generating a decompressed output
  • the root node of the referenced subtree is determined based on the reference position and the level information, and a reference to the DAG event of that root node is generated in the DAG event stream ,
  • a source code example for decompression is as follows:
  • decomp root node
  • // call for decompression stack path // path from the root of the XML document to
  • Root of the subtree is the element that is // removed from the stack end in the // root path level.
  • Child element name ⁇ decomp (elementDeclaration (n. Label ())); ⁇ Attribute!
  • P CDATA ⁇ x constant current. read (); if (x is a pointer) createPointer (x); No, DAG. character (x); ⁇
  • the original SAX input stream is calculated from the DAG event stream.
  • all endElement and character events are forwarded directly to the SAX stream.
  • the SAX events of type startElement are composed of a DAG event of type startElement and the subsequent DAG events of type attribute - without the respective IDs.
  • all events including ID are buffered in main memory.
  • the referenced DAG event is jumped back and the events of the subtree starting with this event are output.
  • An implementation may also be implemented in another language, such as in Java using a SAX parser and JavaCC attribute grammar. Then an extended rule set for compression and a second reverse implementation for decompression should be generated.
  • Example 5 Evaluate XML path requests using the set of grammar rules on the compressed data
  • the process scheme has the following steps:
  • the steps S11 to S14 are looped through to find the information sought.
  • the syntax trees are also run through to evaluate path expressions, and the next token of the document index stream is read, if necessary.
  • a DAG event stream is not generated, but only the structure of the XML data in main memory is partially reconstructed by decompression.
  • not all constants of an XML subtree are reconstructed. Only when the evaluation of the path expression on the partial XML structure index shows that a constant is needed to evaluate a filter or to output the result does the relative position of that constant in the compressed message (more precisely in the corresponding packet of the constant stream ).
  • a first element of a corresponding syntax tree E1 schematized as in FIG. 2 has 10 E3 or E4 child nodes and the second element E1 5 E3 or E4 child node. Since the syntax tree generated for E1 contains only a Kleene operator, the Kleene size tree contains 1 node for every occurrence of a node E1 in the XML input document. Therefore, the Kleene Size Tree contains the following size information:
  • E11size IDsize + 10 * (choice_size + IDsize)
  • E12size IDsize + 5 * (choice_size + IDsize)
  • the document index stream and the structure definition are usually much smaller than the actual structure portion of the XML data, so that the XML structure index can be built faster, which promises a faster evaluation of the path requests.
  • queries or queries that can be completely answered on the XML structure index - ie do not require any access to the constant stream - can be many times faster than on the original XML data get answered.
  • requests are, for example, count requests on the structure, for example according to the number of orders for an XML document shown in FIG. 3a.
  • the relative position can be calculated by traversing the syntax
  • Our method is not limited to compressing only fixed size XML documents.
  • the method is even capable of compressing contiguous (quasi-infinite) XML data streams, since not all the document needs to be known before compression can begin, i. the extended grammar rules can be used to fly-compress.
  • our method is not limited to non-recursive DTDs, i. all ideas can be applied even if e.g. the element declaration of E1 is changed to the following recursive element declaration: ⁇ ! ELEMENT E1 (E2, (E1
  • Calculation and path evaluation are equally applicable to recursive DTDs and XML data streams.
  • XML stream 1 in Fig. 9 we obtain three different types of output streams of a Compressed 7: the second Comprimatsequenz 5 and first Komprimatsequenz the constants and IDs 6 and a conventionally compressed XML data stream 4 with all the rest for the reconstruction of XML data sequence required values.
  • these three data streams are bundled into a stream 7 on the sender side.
  • a grammar rule generator 3 consumes a DTD 2 and an XML data stream 1 according to the operation illustrated in Example 1 to output the compact 7.
  • the decompressed data stream 8 with be schematized in Fig. 7 schematized method V1. With the method V2 schematized in FIG. 8, path requests can be executed and specifically requested data output in a stream 9, possibly also via a decompression of sub-trees V3 as decompressed stream 10.
  • Input for the method are the default structure-defining information of the document as well as the XML data, e.g. in the form of a SAX event stream.
  • the procedure starts the compression immediately after receiving the first SAX
  • Output of the compression method are two data streams, the document index stream and the constant stream.
  • the document index stream along with the structure defining information, e.g.
  • the DTD is a complete index on the structure of the original XML data and can therefore be used for a quick evaluation of path queries.
  • the constant stream contains finely-granulated
  • Both streams may contain references to previous locations in the stream that allow redundant subtrees to be stored only once (and even compressed only once).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Document Processing Apparatus (AREA)

Abstract

Kompression einer Datensequenz eines elektronischen Dokuments, insbesondere eines teilweise komprimierten XML-Dokumentes, mit Hilfe einer Strukturdefinition zu der Datensequenz, insbesondere einer DTD, eines XML Schemas, einer Relax NG compact oder eines Relax NG Schemas, wobei die Strukturdefinition wenigstens eine Teilstruktur der Datensequenz festlegt und die Datensequenz umfaßt: - Werte von Konstanten, insbesondere Textdaten, zur Darstellung von Information des Dokuments und - Strukturinformationen der Datensequenz, insbesondere Tags, welche Start- und Terminalsymbole zu den Konstanten und zu den Teilstrukturen der Datensequenz aus wenigstens einigen der Konstanten und der Strukturinformationen umfassen, darunter Strukturinformationen, die Teilen der Strukturdefinition entsprechen, gekennzeichnet durch eine Erzeugung a) aus der Datensequenz einer ersten Komprimatsequenz, die die Werte der Konstanten der Datensequenz oder Repräsentanten dieser Werte, insbesondere Indices dieser Werte, umfaßt, und b) aus der Datensequenz einer zweiten Komprimatsequenz durch Entfernung aus der Datensequenz der Werte der Konstanten und aller Strukturinformationen, die Teilen der Strukturdefinition entsprechen.

Description

VERFAHREN ZUR KOMPRESSION EINER DATENSEQUENZ EINES ELEKTRONISCHEN DOKUMENTS
TECHNISCHES GEBIET DER ERFINDUNG
Das technische Gebiet der Erfindung ist die Übertragung, Speicherung und Auswertung von digitalen Daten, insbesondere beim Betrieb von Computernetzwerken.
Die Erfindung betrifft eine Kompression einer Datensequenz eines elektronischen
Dokuments, insbesondere eines XML-Dokuments, mit Hilfe einer Strukturdefinition zu der Datensequenz, insbesondere einer DTD, welche zu wenigstens einer Teilstruktur der Datensequenz wenigstens eine Deklaration umfaßt, die unäre Operatoren oder unäre und binäre Operatoren eines Syntaxbaumes, der die Teilstruktur repräsentiert, umfaßt, darunter wenigstens einen unären Kleene-
Operator, der als Argument die Anzahl möglicher Wiederholungen der Teilstruktur in der Datensequenz hat, wobei die Datensequenz umfaßt:
- Werte von Konstanten, insbesondere Textdaten, zur Darstellung von Information des Dokuments und - Strukturinformationen der Datensequenz, insbesondere Tags, welche
Start- und Terminalsymbole zu den Konstanten und zu den Teilstrukturen der Datensequenz aus wenigstens einigen der Konstanten und der Strukturinformationen umfassen. Die Erfindung betrifft weiterhin komprimierte Daten oder Dateien, die nach einem solchen Verfahren erzeugt sind. Die Erfindung betrifft auch Verfahren zur Dekompression und zur Auswertung von Anfragen auf solchen komprimierten Daten oder Dateien.
HINTERGRUND DER ERFINDUNG
XML (Extendable Mark-up Language) ist ein weit verbreiteter Standard zum
Datenaustausch, der die Erkennung und das Auffinden von Konstanten in einem Dokument über Tags erleichtert. Im XML-Datenformat enthält ein Dokument Konstanten wie Textbestandteile und Strukturdaten. Auf der einen Seite stellt die in der XML-Datei enthaltene Strukturinformation einen Vorteil von XML dar, da sie semantische Informationen und Navigationshilfen enthält. Auf der anderen Seite bläht jedoch die enthaltene Strukturinformation das Dokument im Vergleich zu den enthaltenen Textwerten auf und Pfadangabe zu Konstanten wie Textwerten, speziell XPath-Anfragen erfordern es oft, mehrfach durch ähnliche oder sogar gleiche Strukturen zu navigieren.
Fig. 1a stellt ein XML-Dokument dar. Dieses hat Textdaten als Konstanten wie z.B. „John Smith". Es hat dazu Strukturdaten in Form von Tags wie <author> oder <name>. Die Tags dienen auch als Startsymbole oder als Terminalsymbole wie das Startsymbol <name> oder das Terminalsymbol </name> .
Bei der Übertragung, Speicherung und Auswertung von solchen digitalen Daten in technischen Systemen wie Computernetzwerken, Computerdatenspeichern oder Computersystemen ist die Leistungsfähigkeit der Systeme durch die Menge und die Bearbeitungsgeschwindigkeit der Datenmengen begrenzt. Diese Begrenzungen bestimmen zudem die Arbeitsgeschwindigkeit und den Bedarf an Hardwareressourcen bei solchen Systemen. Die Kompression von Datenmengen ermöglicht so, auch kleinere tragbare Geräte wie Pocket-PCs mit Leistungsfähigkeiten zu versehen, die sonst nur mit größeren Hardwarekomponenten möglich wären. Zudem wird der Energieverbrauch durch die
Menge der Datenmengen und durch die Komplexität ihrer Bearbeitung mitbestimmt. Speziell beim Einsatz mobiler batteriegetriebener Geräte bestimmt der Energieverbrauch die Lebenszeit der Akkumulatoren und die maximale Laufzeiten der Geräte ohne externe Stromversorgung.
Zur Kompression von Datenmengen allgemein ist aus der Veröffentlichung von E. Fredkin: „Trie Memory Communications of the ACM"; 3(9): 490-499, Sept. 1960 bekannt, Textwerte in einem Trie zu hashen. Dieses Verfahren wird für die Konstanten angewandt und erlaubt es, jede Konstante nur einmal zu indizieren bzw. in ein Komprimat zu schreiben. Es werden gleiche IDs für jedes Vorkommen derselben Konstante zu verwendet. Während der Kompression eines Datenstroms wird jeder gefundene Textwert des Eingabestroms durch eine eindeutige ID ersetzt, so daß jede Textwert-ID im komprimierten Datenstrom von konstanter Größe ist. Die direkte Anwendung einer solchen Kompression beispielsweise auf ein XML- Dokument würde eine vollständige Dekompression des Dokuments erzwingen, bevor dieses zur Bearbeitung, Auswertung oder Datensuche verfügbar wird. Die Bearbeitungseffizienz leidet darunter.
Um die Bearbeitungseffizienz für strukturierte Daten, insbesondere für XML- Dokumente zu erhöhen, können Strukturdefinitionen genutzt werden. Eine Strukturdefinition für XML-Dokumente ist als DTD (document type definition) bekannt. Die Fig. 1b stellt zu dem XML-Dokument der Fig. 1a eine DTD dar, die Elemente von Strukturdaten des XML-Dokuments definiert. DTD kategorisiert
Dokumentdaten wenigstens in den drei Kategorien: Elemente, Attribute und Einheiten/Entitäten. Dabei sind diese Kategorien optional. So enthalten das XML- Dokument der Fig. 1a und die DTD der Fig. 1 b keine Attribute. Hingegen stellt die Fig. 3a ein XML-Dokument und die Fig. 3b eine ihm entsprechende DTD dar, bei denen die Attribute "bestellnr" und "eilt" vorgesehen sind.
SAX (simple application programming interface for XML) ist ein Standard, der der Analyse von XML-Dokumenten auf ihre Strukturdaten dient. Dazu stehen SAX- Parser zur Verfügung, die Dokumentdaten kontinuierlich als sequentiellen Datenstrom lesen. So kann aus dem XML-Dokument der Fig. 3a ein SAX-Parser die Folge von Ereignissen darstellen:
startDocument startElement („shop") startElement („bestellung", „bestellnr="4711"") startElement („künde") startElement („name") character („Meier") endE1ement („name") startElement („strasse") character („Waldweg") endElement („strasse") startElement („ort") character („Paderborn") endElement („ort") endElement („künde") startElement ( „ teil " ) character („PC") endElement („teil") startElement („teil") character ( „Drucker" ) endElement („teil") -A-
endEletnent („bestellung") startElement („bestellung", „bestellnr="0815", eilt="ja"")
StartElement („künde") startElement („name") character („Schmidt") endE1ement („name" ) startElement („telefon") character („0815") endElement („telefon") startElement („strasse") character („Waldweg") endElement („strasse") startElement („ort") character („Paderborn") endElement („ort") endE1ement („künde" ) startElement („dienstleistung") character („Installation") endElement („dienstleistung") startElement („teil") character („PC") endElement („teil") startElement („teil") character („Drucker" ) endElement („teil") endElement („bestellung") endE1ement („ shop" ) endDocument
Die Veröffentlichung von Wilfred Ng, Wai-Yeung Lam, Peter T. Wodd, Mark
Levene, "XCQ: A queriable XML compression System"; Knoel Inf Syst (2006); DOI 10.1007/s10115-006-0012-z zeigt einen Weg, um auf komprimierten Daten noch Pfadanfragen zu Konstanten erlauben. Dabei wird ein SAX-Parser und eine DTD eingesetzt, um ein XML-Dokument in Datenblöcke zerlegt zu komprimieren. Zu jedem Block wird eine Signatur aus charakteristischen Werten für die Daten des
Blockes wie Länge oder Anzahl der Zeichen erzeugt und gespeichert. Für eine Pfadanfrage zu Konstanten muß nur ein Block und nicht das ganze Komprimat des XML-Dokuments dekomprimiert werden. Dazu wird die Pfadanfrage in eine solche Signatur übersetzt, die durch Abgleich der Identifizierung des Blockes mit der entsprechenden Signatur dient. Nachteilig sind dabei die Übersetzungs- und
Signaturzwänge.
Eine XML-Kompression mit DAGs wurde gezeigt in Koch et. al., VLDB 2003. Dies ist ein anderer Ansatz, um auf den komprimierten Daten noch Pfadanfragen zu Konstanten erlauben. Ein DAG (directed acyclic graph) ist eine Darstellung der Datenstruktur eines XML-Dokuments, der auf einer solchen mit einem SAX-Parser erzeugten Folge von Ereignissen (SAX-Datenstrom) aufbaut. DAGs versehen Elemente eines SAX-Datenstroms mit Indices. Zur Kompression können dabei sich wiederholende Datenfolgen des SAX-Datenstroms durch Zeiger auf solche Indices ersetzt werden. Dadurch wird beispielsweise aus der oben durch SAX-Parsen erhaltenden Folge von Ereignissen folgender DAG-Datenstrom mit den Zeigern "pointer(6)" und "pointer(8)" erstellt:
startDocument startElement (1, „shop") startElement (2, „bestellung") attribute(3, „bestellnr", „4711") startElement (4, „künde") startElement (5 , „name") character („Meier") endElement ( „name" ) startElement (6, „strasse") character („Waldweg") endElement („strasse") startElement (7, „ort") character ( „ Paderborn" ) endElement ( „ort" ) endElement („künde") startElement (8, „teil") character („PC") endElement („teil") startElement (9, „teil") character („Drucker") endElement („teil") endElement („bestellung") startElement (10, „bestellung") attribute(ll, „bestellnr", „0815") attribute(12, „eilt", „ja") startElement (13, „künde") startElement (14, „name") character („Schmidt") endE1ement („name" ) startElement (15, „telefon") character („0815") endElement („telefon") pointer (6) endElement („künde") startElement (16, „dienstleistung") character („Installation") endElement („dienstleistung") pointer (8) endElement („bestellung") endElement („shop") endDocument Zum Stand der Technik gehören damit Verfahren zur Kompression von XML-Daten mit Hilfe gegebener externer Struktur-definierender Information.
Unbekannt sind Verfahren, die XML-Daten komprimieren, indem sowohl Redundanzen, die innerhalb der XML-Daten auftreten (z.B. mehrfach auftretende
Teilbäume), als auch Redundanzen, die aufgrund der Schema-Informationen auftreten, entfernt werden.
AUFGABE UND ZUSAMMENFASSUNG DER ERFINDUNG
Der Erfindung liegt die Aufgabe zugrunde, die genannten Redundanzen zu entfernen und dadurch eine geringere Datengröße zu ermöglichen. Sie ermöglicht gleichzeitig ein schlanker Index auf den Daten, so daß Pfadanfragen (z.B. in Form von XPath für XML-Daten oder darauf basierender Anfragesprachen) effizient beantwortet werden können. Da das Verfahren auch für einen partiellen Input wie einen Teil eines XML-Dokuments einen partiellen Output berechnen kann, ist das Verfahren nicht auf solche XML-Daten beschränkt, die komplett in den Hauptspeicher passen, sondern kann z.B. auch auf sehr lange Datenströme angewandt werden. Aufgabe der Erfindung ist es, eine Alternative zum Stand der Technik mit solchen Vorteilen zu bieten.
Die Erfindung verbessert ein Verfahren zur Kompression einer Datensequenz eines elektronischen Dokuments, insbesondere eines XML-Dokuments, mit Hilfe einer Strukturdefinition zu der Datensequenz, insbesondere einer DTD, welche zu wenigstens einer Teilstruktur der Datensequenz wenigstens eine Deklaration umfaßt, die unäre Operatoren oder unäre und binäre Operatoren eines Syntaxbaumes, der die Teilstruktur repräsentiert, umfaßt, darunter wenigstens einen unären Kleene-Operator, der als Argument die Anzahl möglicher Wiederholungen der Teilstruktur in der Datensequenz hat, wobei die Datensequenz umfaßt:
- Werte von Konstanten, insbesondere Textdaten, zur Darstellung von Information des Dokuments und
- Strukturinformationen der Datensequenz, insbesondere Tags, welche Start- und Terminalsymbole zu den Konstanten und zu den Teilstrukturen der Datensequenz aus wenigstens einigen der Konstanten und der Strukturinformationen umfassen.
Die Verbesserung ist die eine Erzeugung a) aus der Datensequenz einer ersten Komprimatsequenz, die die Werte der
Konstanten der Datensequenz oder Repräsentanten dieser Werte, insbesondere Indices dieser Werte, umfaßt, und b) aus der Datensequenz und der Strukturdefinition einer zweiten Komprimatsequenz, die von der Strukturdefinition Werte der Argumente der Operatoren oder Repräsentanten dieser Werte umfaßt.
Allgemein bietet die Erfindung ein Verfahren zur Kompression einer Datensequenz eines elektronischen Dokuments, insbesondere eines teilweise komprimierten XML- Dokumentes, mit Hilfe einer Strukturdefinition zu der Datensequenz, insbesondere einer DTD, eines XML Schemas, einer Relax NG compact oder eines Relax NG
Schemas, wobei die Strukturdefinition wenigstens eine Teilstruktur der Datensequenz festlegt und die Datensequenz umfaßt:
Werte von Konstanten, insbesondere Textdaten, zur Darstellung von Information des Dokuments und - Strukturinformationen der Datensequenz, insbesondere Tags, welche Start- und Terminalsymbole zu den Konstanten und zu den Teilstrukturen der Datensequenz aus wenigstens einigen der Konstanten und der Strukturinformationen umfassen, darunter Strukturinformationen, die Teilen der Strukturdefinition entsprechen, gekennzeichnet durch eine Erzeugung a) aus der Datensequenz einer ersten Komprimatsequenz, die die Werte der Konstanten der Datensequenz oder Repräsentanten dieser Werte, insbesondere Indices dieser Werte, umfaßt, und b) aus der Datensequenz einer zweiten Komprimatsequenz durch Entfernung aus der Datensequenz der Werte der Konstanten und aller Strukturinformationen, die Teilen der Strukturdefinition entsprechen.
Obgleich die obigen Erzeugungen a) und b) unterschiedliche Datenbearbeitungen sind, können sie bei Ausführung erfindungsgemäßer Verfahren abwechseln, um einen Datenstrom zu erzeugen, in dem jeweils Teile der ersten und zweiten Komprimatsequenzen einander abwechseln bzw. aufeinander folgen.
Einen Schritt der Berechnung der Mengen der Start- und Terminalsymbole für jede Teilstruktur kann der Navigation in Datenströmen bei Dekompressionen oder
Pfadanfragen dienen.
Die Datensequenz ist z.B. eine wie eingangs gezeigte indizierte Sequenz wie die Folge von DAG Ereignissen.
Unter Anwendung konventioneller Verfahren des Hashens der Werte der Konstanten, der insbesondere gleiche lndices für gleiche Werte vorsieht, können die Repräsentanten der Werte der Konstanten lndices eines Tries sein.
Vorteilhaft hat das erfindungsgemäße Kompressionsverfahren weiterhin Merkmale von wenigstens einem der Ansprüche 2 bis 8.
Die Erfindung betrifft auch eine komprimierte Datensequenz eines elektronischen Dokuments, erhalten durch ein erfindungsgemäßes Verfahren und Computerdateien mit solchen komprimierten Datensequenzen.
Die Erfindung betrifft auch die Dekompression einer erfindungsgemäß komprimierten Datensequenz, gekennzeichnet durch
Rekonstruktion einer Folge von Strukturinformationen der Datensequenz aus der zweiten Komprimatsequenz und der Strukturdefinition,
Ergänzung der Folge von Strukturinformationen zu der Datensequenz durch Einsetzen der Werte der Konstanten aus der ersten Komprimatsequenz in diese Folge entsprechend der Strukturdefinition.
Dabei wird ggf. die transformierte Datensequenz rücktransformiert zu der
Datensequenz durch Ersetzen der Zeiger durch die der Teilstruktur der transformierten Datensequenz, auf welche die Zeiger verweisen. Die Auswertung eines Pfadausdrucks, insbesondere einer XPath-Anfrage für eine XML-Datensequenz, auf der komprimierten Datensequenz kennzeichnet sich durch Bildung der Produkte der Werte der Argumente der Kleene-Operatoren der vorhergehenden Syntaxbäume mit — einer konstanten Länge der übrigen Werte der Argumente in der zweiten Komprimatsequenz oder mit der Summe einer konstanten Länge der übrigen Werte der Argumente und einer konstanten Länge der übrigen Werte der Konstanten bzw. der eingeführten Konstanten der dritten Komprimatsequenz, - Berechnung der Position zu einer Teilstruktur mit einer durch den
Pfadausdruck angefragten Konstante in der komprimierten Sequenz durch Aufsummierung der Produkte.
Ein optionaler Folgeschritt ist die Dekompression eines Teils der komprimierten Sequenz, der in der Datensequenz der Teilstruktur mit einer durch den
Pfadausdruck angefragten Konstante entspricht, nach einem Verfahren der Erfindung.
Bei der Auswertung eines Pfadausdrucks ist auch ein Verfahren möglich, wobei die berechnete Position jene eines Zeigers in der komprimierten Sequenz ist, gekennzeichnet durch Dekompression eines Teils der komprimierten Sequenz, auf den der Zeiger verweist.
Die Erfindung umfaßt auch ein Computerprogrammprodukt, das eines oder mehrere der Verfahren der Erfindung implementiert.
Die Erfindung zeigt somit einen Struktur-orientierten Index, d.h. einen Index, welcher einen effizienten Zugriff auf die strukturellen Informationen bietet, ohne daß hierfür eine Dekompression des komprimierten XML-Datenstroms notwendig ist.
Das Ziel der Indizierungstechnik ist, die Strukturinformationen, die durch die Elementdeklarationen gegeben sind, zu nutzen, um die Index-Positionen bestimmter Textwerte zu ermitteln.
Eine grundlegende Idee unseres Struktur-erhaltenden Kompressionsverfahrens ist damit, die Strukturinformationen, die aufgrund der gegebenen DTD redundant sind, zu minimieren. In anderen Worten: Wir nutzen die durch die DTD gegebenen Strukturinformationen, um entsprechende redundante Strukturinformationen des XML-Dokuments zu eliminieren, wodurch wir die komprimierten cXML-Daten erzeugen.
Eine grundlegende Idee unseres Index-Zugriffs auf die komprimierten XML-Daten ist es, die Größe aller XML-Dokument-Teilbäume zu berechnen, und diese berechneten Teilbaumgrößen zu nutzen, um zu bestimmen, wie viel des komprimierten XML-Datenstroms übersprungen werden kann, um ein Element, welches z.B. durch eine XPath-Anfrage spezifiziert wird, zu erreichen.
Verschiedene weitere Aspekte der Erfindung werden nachfolgend beispielhaft unter Bezugnahme auch die Figuren veranschaulicht. Ein komprimiertes XML-Dokument wird dabei im folgenden cXML-Dokument genannt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Fig. 1a stellt beispielhaft XML-Daten dar;
Fig. 1 b stellt beispielhaft eine zu den Daten der Fig. 1a gehörende DTD dar;
Fig. 2 stellt allgemein Syntax-Bäume aus den Elementdeklarationen der
DTD aus Fig. 1 b dar;
Fig. 3a stellt beispielhaft XML-Daten dar, welche Attribute enthalten;
Fig. 3b stellt beispielhaft eine zu den Daten der Fig. 3b gehörende DTD dar;
Fig. 4 stellt konkret die Syntax-Bäume der Elementdeklarationen der
DTD aus Fig. 3b dar; Fig. 5 schematisiert eine bei der Erfindung angewandte Erzeugung von Grammatikregeln;
Fig. 6 schematisiert ein erfindungsgemäßes Verfahren zur Datenkompression;
Fig. 7 schematisiert ein erfindungsgemäßes Verfahren zur Datendekompression;
Fig. 8 schematisiert ein erfindungsgemäßes Verfahren zur Auswertung von Pfadausdrücken auf nach der Erfindung komprimierten Daten dar;
Fig. 9 schematisiert Bündelungen der Datenströme von in den Figuren 5 bis 8 schematisierten Datenverarbeitungen.
Beispiel 1 : Erzeugung von Grammatikregeln
Vergleicht man die DTD der Fig. 1b mit dem XML-Dokument der Fig. 1a, so stellt man fest, daß eine Menge von Strukturinformationen des XML-Dokuments schon aufgrund der DTD bekannt sind. Zum Beispiel wissen wir aufgrund der DTD, daß das erste Element jedes validen Dokumentes der <paper>-Tag ist.
Um diesen Umstand für Datenkompressionen zu nutzen werden, aus den Elementdeklarationen der DTD nach dem in Fig. 5 schematisierten Verfahren
Grammatikregeln erzeugt. Das Verfahren besteht aus der folgenden Abfolge von Schritten:
51 , Parsen der Deklarationen der DTD
52, Bestimmung von Syntaxbaumstrukturen und von Mengen von Start- und Terminalsymbolen aus der DTD
53, Erzeugen von Grammatikregeln Hierzu werden nachfolgend zunächst die angewandten Grundlagen der Deklarationen der DTD, der Syntaxbäume, der Bestimmung der Mengen von Start- und Terminalsymbolen und der Erzeugung von Grammatikregeln erklärt.
Elementdeklarationen
Folgende Operatoren werden durch die Elementdeklarationen der DTDs der Figuren 1 b und 3b verwendet:
Sequenz-Operator ', ': Mit Hilfe eines Sequenz-Operators wird eine Ordnung der Kindknoten festgelegt.
Choice-Operator '|': Der Choice-Operator legt eine Alternative bzw. exklusive Auswahl aus einer Menge von möglichen Kindelementen fest.
Kleene-Operator '*': Er ist Wiederholungs-Operator, der für eine Menge von
Kindelementen die Anzahl von möglichen Wiederholungen festgelegt und auch eine Mindest- und/oder Maximal-Anzahl von Wiederholungen festgelegen kann.
Options-Operator '?': Er legt für einen Kindknoten fest, daß dieser optional ist, also entweder 0-mal oder 1-mal vorkommen darf.
Der in Fig. 4 dargestellte Kleene Operator ,+' ist der Kleene Operator eines Teilbaums einer Elementdeklaration
Ein ANY-Operator ist ausgeschlossen aus der DTD, da er nicht erlaubt, die benötigten Typinformationen abzuleiten.
Im Allgemeinen, kann jede rechte Seite einer Elementdeklaration als ein regulärer Ausdruck angesehen werden, der aus 0 oder mehr Kindelementen oder dem #PCDATA-Ausdruck oder dem EMPTY-Ausdruck unter Verwendung der Operatoren Sequenz (,), Choice, (|) oder Kleene (*) besteht. Der (+)-Operator kann durch den Sequenz- und den Kleene-Operator ausgedrückt werden, d.h. (E)+ wird ersetzt durch (E,(E*)). Entsprechend kann der (?)-Operator durch den Choice- Operator und den EMPTY-Ausdruck ausgedrückt werden, d.h. wir ersetzen (E?) durch (E|EMTPY).
Die in Fig. 1 b dargestellte DTD enthält Elementdeklarationen, keine Attribute. Eine der Elementdeklaration eines Elements E1 der in Fig. 1 b dargestellten DTD hat die
Form
< !ELEMENT E1 ( E2 , ( E3|E4 ) )* > und definiert, daß jedes Element E1 eine beliebige Anzahl von Sequenzen enthält, wobei jede Sequenz aus einem Kindelement E2 besteht, gefolgt von entweder einem Element E3 oder einem Element E4. Wir nennen (E2, (E3|E4)* die rechte
Seite der Elementdeklaration. Die rechte Seite wendet den Kleene-Operator '*' an auf den Sequenz-Operator ',', wobei dieser selbst auf das Kindelement E2 von E1 und auf den Choice-Operator (|) angewandt wird. Dieser wieder wird auf die Kindelemente E3 und E4 von E1 angewandt.
Eine weitere Elementdeklaration des Elements E2 der in Fig. 1 b dargestellten DTD hat die Form
< !ELEMENT E2 ( #PCDATA ) > und definiert, daß das Element E2 nur zu dem Kindereiemet PCDATA als Endknoten verzweigt. In diesem Fall enthält die rechte Seite der Elementdeklaration nur den Ausdruck #PCDATA.
Eine Erweiterung unseres Verfahrens um Attribute ist in derselben Weise möglich und durch die Figuren 3a, 3b und 4 veranschaulicht. Syntaxbäume
Mit einem Parser, der die Struktur-definierenden Informationen der DTD mit einem zugehörigen, d.h. validen XML-Dokument vergleicht, werden mit Operatorentypen Schemata zur strukturdefinierenden Information der unten beschriebenen Knotenarten zur Festlegung von Ordnung und Anzahl der Kindknoten umgesetzt. Im Verfahrensschema der Fig. 5 werden dazu in Schritt S1 die Elementdeklaration der DTD geparst und in Schritt S2 in einen binären Syntaxbaum umgewandelt wie er in Fig. 2 allgemein für das XML-Dokument der Fig. 1a und aus der DTD der Fig. 1b dargestellt ist. Die Fig. 4 stellt entsprechend die Syntaxbäume für das XML- Dokument der Fig. 3a und aus der DTD der Fig. 3b dar. Es werden die Struktur-definierenden Informationen mit einem validen XML- Dokument verglichen. Es wird während des Parsens festgestellt, daß viele Informationen im Strukur-Anteil der XML-Daten redundant sind, da sie bereits durch die DTD festgelegt sind. Konkret sind durch jede Elementdeklaration bereits folgende Operatoren festgelegt: Die Namen aller Kind-Elemente, ob es PCDATA-
Elemente gibt, und welche Sequenz-Operatoren in einer Elementdeklaration enthalten sind.
In den Figs. 2 und 4 sind Knoten, denen Operatoren zugeordnet sind, mit den Symbolen der entsprechenden oben angegebenen Operatoren dargestellt.
In den Syntaxbäumen der Figuren 2 bzw. 4 gibt es die folgenden Knotentypen: I .EIementdeklaration(Name): Ein Knoten dieses Typs wird für jedes Element, welches durch eine Elementdeklaration definiert wird, erzeugt. Jeder Elementdeklarationsknoten hat genau einen Nachfolger-Knoten, welcher der
Wurzelknoten desjenigen Teilbaums ist, der die rechte Seite der Elementdeklaration repräsentiert. Der Name des definierten Elements der Elementdeklaration wird als Parameter festgelegt.
2. Kindelement(Name): Ein Knoten dieses Typs wird für jedes Auftreten eines Elements in der rechten Seite einer Elementdeklaration erzeugt. Der Name dieses
Elements wird als Parameter festgelegt. Eine Vater-Kind-Beziehung wird zwischen dem deklarierten Element und dem Kind-Element festgelegt. Der Kindelement- Knoten hat keine Nachfolger.
3. PCDATA: Der PCDATA-Knoten wird benutzt, wenn die rechte Seite einer Elementdeklaration die Zeichenkettenvariable '#PCDATA' enthält. Der PCDATA- Knoten hat keine Parameter und keine Nachfolger. Der ihm zugeordnete PCDATA- Operator legt für ein Element fest, daß es einen Text-Knoten und keinen Element- Kindknoten enthält.
4. Sequenz: Ein Knoten dieses Typs wird für jeden Sequenz-Operator ', ' erzeugt, der in der rechten Seite einer Elementdeklaration auftritt. Ein Sequenz-Knoten hat keine Parameter. Jeder Sequenz-Knoten hat zwei Nachfolger, der die beiden Argumente des Sequenz-Operators in der Elementdeklaration repräsentiert.
5. Choice: Ein Knoten dieses Typs wird für jeden Choice-Operator '|' erzeugt, der in der rechten Seite einer Elementdeklaration auftritt. Ein Choice-Knoten hat keine Parameter. Jeder Choice-Knoten hat zwei Nachfolger, der die beiden Argumente des Choice-Operators in der Elementdeklaration repräsentiert. Der Choice-Operator legt eine Alternative bzw. exklusive Auswahl aus einer Menge von möglichen Kindelementen fest. 6. Kleene: Ein Knoten dieses Typs wird für jeden Kleene-Operator '*' erzeugt, der in der rechten Seite einer Elementdeklaration auftritt. Ein Kleene-Knoten hat keine Parameter. Jeder Kleene-Knoten hat genau einen Nachfolger, welcher das Argument dieses Kleene-Operators in der Elementdeklaration repräsentiert. 7. EMPTY: Ein Knoten dieses Typs wird für jedes Vorkommen der Zeichenkette 1EMTPY' in einer Elementdeklaration der DTD erzeugt. Knoten dieses Typen haben weder Parameter noch Nachfolger im Syntaxbaum. Ihm zugeordnet ist ein Options-Operator ?', der für einen Kindknoten festgelegt, daß dieser optional ist, also entweder 0-mal oder 1-mal vorkommen darf. Dies kann ein Options-Operator auch für einen von dem Kindknoten abhängenden Teilbaum festlegen. 8. Attribut: Mit dem Auftreten eines Attributs im Definitionsbereich einer
Elementdeklaration der DTD wird eine Element-Attribut-Beziehung zwischen dem deklarierten Element und dem Attribut festgelegt. Zum Beispiel zeigt die DTD der Fig. 2b eine Definition <!ATTLIST bestellung...>.
Jede Elementdeklaration entspricht bei Umsetzung in den entsprechenden
Syntaxbaum genau einem der oben beschriebenen Typen.
Bestimmen der Menge der Start-Terminal-Symbole
Zur Verarbeitung der Elementdeklarationen wird die Menge der Start-Terminal- Symbole für jeden Knoten bis auf den Wurzelknoten jedes Elementdeklarations- Syntaxbaums berechnet. Diese Mengen der Start-Terminal-Symbole erlauben einem Parser, welcher zur Kompression oder zur Verarbeitung von Pfad- Ausdrücken benutzt wird, während des Parsens zu entscheiden, welche Grammatikregel angewandt werden muß. Die Menge der Start-Terminal-Symbole wird nach folgenden Beziehungen berechnet für die in den Figuren 1a, 1 b und 2 gezeigten Daten und Strukturen:
STS(Kindelement(Name)) := { Name } STS(PCDATA) := { PCDATA } STS(EMTPY) := { EMPTY }
STS(Sequenz(a,b)) := STS(a), if EMPTY i STS(a)
STS(Sequenz(a,b)) := STS(a) u STS(b) , if EMPTY e STS(a)
STS(Choice(a,b)) := STS1 u STS2 where STS1 :=STS(a) and STS2:=STS(b) STS(Kleene(a)) := { EMPTY } u STS(a)
Im vorliegenden Beispiel ist die Menge der Start-Terminal-Symbole zweier Geschwisterknoten, die Nachfolger eines Choice-Knotens sind, immer disjunkt, so daß der aktuell betrachtete Knoten des XML-Eingabedokuments immer entscheidet, welche Alternative gewählt wurde.
Umschreiben von Elementdeklarations-Syntaxbäumen in eine Menge von Grammatikregeln
Für jeden Knoten i, der in einem Elementdeklarations-Syntaxbaum erscheint (ausgenommen PCDAT A-Knoten und Kindelement-Knoten), erzeugen wir eine eindeutige Knoten-ID, Ni, und die jeweilige Grammatikregel. Da für die in den Figuren 1a, 1b und 2 gezeigten Daten und Strukturen 7 verschiedene Knotentypen für Elementdeklarations-Syntaxbäume existieren, erhalten wir 7 verschiedene Typen von Grammatikregeln, also je eine für jeden Elementdeklarations- Knotentypen. Um die für verschiedene Knoten gleichen Typs generierten Regeln zu unterscheiden, parametrisieren wir die Regeln mit den Knoten-IDs, Ni, die jedem Knoten eines Elementdeklarations-Syntaxbaums zugeordnet sind. Ein weiterer Parameter, der in den meisten Regeln erscheint (d.h. in den Regeln, die für Knoten der Typen Sequenz, Choice oder Kleene erzeugt wurden) ist die Menge der Start- Terminal-Symbole des jeweiligen Knotens. Schließlich enthalten die Regeln für
Elementdeklarations-Knoten das definierte Element als Parameter, und immer wenn ein Kindlelement-Knoten als Nachfolger eines Knotens p erscheint, enthält die Grammatikregel, welche für P erzeugt wurde, einen Kindelement-Aufruf des Kindelement-Knotens des Elementdeklarations-Syntaxbaums.
Zum Beispiel wird die folgende Menge von Grammatikregeln für den in Fig. 2 dargestellten Syntaxbaum erzeugt: Elementdeklaration( E1 ) ■» Kleene( NO, {E2} ) . Kleene( NO, {E2} ) -» Sequenz( N1 , {E2} ).
Sequenz( N1 , {E2} ) •» Kindelement( E2 ) , Choice( N2, {E3.E4} ) . Choice( N2, {E3.E4} ) ■» Kindelement( E3 ) . Choice( N2, {E3,E4} ) ■* Kindelement( E4 ) .
Erzeugung von Grammatikregeln einer Attribut-Grammatik
Hinzufügen gewisser Attribute erweitert der Menge von Grammatikregeln zu einer Attribut-Grammatik, die zur Kompression genutzt wird. Wir nutzen die DCG- Regelnotation von Prolog, um die Implementierung der Attribut-Grammatikregeln zu beschrieben, und wir benutzen die Notation [lnput]/[Output] um zu beschreiben, daß Input aus der XML-Eingabedatei oder dem XML-Eingabestrom gelesen bzw. konsumiert wird, und Output in einen komprimierten cXML-Ausgabestrom geschrieben wird. Geschweifte Klammern, {...}, drücken in den DCG-Regeln Bedingungen aus, die erfüllt sein müssen, damit eine Regel angewandt werden kann. Auf weiche Art eine Regel erweitert wird, hängt vom jeweiligen Knotentyp ab, der durch die Regel repräsentiert wird.
Die Regel Elementdeklaration( E1 ) -> Sequenz( N1 , {E2} ). wird erweitert zu
Elementdeklaration( E1 ) -» [E1] / [ ] , Sequenz( N1 , {E2} ).
Die leeren Klammern, [], geben an, daß nichts in die Ausgabe geschrieben wird.
Daher kann die erweiterte Grammatikregel wie folgt interpretiert werden: Konsumiere einen Start-Tag des Elements E1 vom Input, gebe nichts in die komprimierte XML-Datei aus und fahre anschließend fort mit der Anwendung der
Sequenz-Grammatikregel für den Knoten mit der ID Nl
Im Allgemeinen wird jede Grammatikregel Elementdeklaration( E ) -> rechte Seite . erweitert zu Elementdeklaration( E ) -> [E] / [ ] .rechte Seite. Grammatikregeln für Sequenz-Knotentypen werden nicht erweitert, d.h. sie bleiben wie bisher bestehen:
Sequenz( N1 , {E2} ) -» Kindelement( E2 ) , Choice( N2, {E3.E4} ). oder im allgemeinen Fall: Sequenz( Ni, S ) -> rechte Seite.
Grammatikregeln für Choice-Knotentypen werden um eine Bedingung bzgl. der gewählten Alternative und um die Ausgabe der gewählten Alternative erweitert. So wird die Grammatikregel Choice( N2, {E3, E4} ) -^ Kindelement( E3 ) .
Choice( N2, {E3, E4} ) -» Kindelement( E4 ) . umgeschrieben zu:
Choice( N2, {E3, E4 } ) -» { next tag e {E3} } , [ ] / [1] , Kindelement( E3 ) .
Choice( N2, {E4, E4} ) -» { next tag £ {E3} } , [ ] / [2] , Kindelement( E4 ) .
In dieser erweiterten Regel drückt die Ausgabe [1] (bzw. [2]) aus, daß die erste
(bzw. zweite) der durch die DTD gegebenen Alternativen ausgewählt wurde. Diese
Information wird in den Ausgabestrom geschrieben, um später das XML-Dokument aus dem cXML-Datenstrom rekonstruieren zu können.
Im Allgemeinen kann der Choice-Operator nicht nur Elemente kombinieren, sondern auch Ausdrücke. Somit wird jedes Paar von Grammatikregeln, welches eine Knoten-ID Ni und zwei Mengen von Start-Terminal-Symbolen STS1 und STS2 als Parameter erhält:
Choice(Ni, (STS1uSTS2) ) -» rechte Seite 1.
Choice(Ni, (STS1uSTS2) ) -» rechte Seite 2. ersetzt durch das folgende Paar von Grammatikregeln
Choice(Ni, (STS1uSTS2) ) -» { next tag e STS1 }[ ] / [ 1 ], rechte Seite 1.
Choice(Ni, (STS1uSTS2) ) -» { next tag e STS1 }[ ] / [ 2 ], rechte Seite 2.
Schließlich werden die Grammatikregeln für Kleene-Knotentypen ersetzt durch eine Menge von erweiterten Grammatikregeln, die den Beginn und das Ende der Argumente des Kleene-Operators im cXML-Strom codieren. In unserem Beispiel wird die Grammatikregel
Kleene( NO, {E2} ) -> Sequenz( N1 , {E2} ).
ersetzt durch die folgenden Grammatikregeln:
Kleene( NO, {E2} ) -» [ ] / ['('] , repeat( NO, {E2} ) . repeat( NO, {E2} ) -» { next tage{E2} }, Sequenz( N1 ,{E2} ), repeat( N0,{E2} ) . repeat( NO, {E2} ) -> { next tag g{E2} } , [ ] / [')*']•
Die Klammern, also '(',')*', werden für jeden Kleene-Operator in die Ausgabe geschrieben, um sicherzustellen, daß eine eindeutige Dekompression erreicht werden kann.
Im allgemeinen Fall wird jede Grammatikregel für einen Kleene-Operator, welche eine Knoten-ID Ni und eine Menge S von Start-Terminal-Symbolen als Parameter hat
Kleene( Ni, S ) -> rechte Seite .
durch die folgenden Grammatikregeln ersetzt
Kleene( Ni, S ) -> [ ] / ['('] , repeat( Ni, S ) . repeat( Ni, S ) -> { next tag e S } , rechte Seite , repeat( Ni, S ). repeat( Ni, S ) -» { next tag «. S } , [ ] / [')*']■
Während der Anwendung der Kleene-Grammatikregeln, zählen wir, wie oft der Teilbaum, welcher durch die rechte Seite der Grammatikregel beschrieben wird, wiederholt wurde, also wie oft die erste repeat-Grammatikregel ausgeführt wurde.
Die Anzahl an Wiederholungen wird für die Indizierung, d.h. für die Übersetzung von XML-Pfadanfragen in Index-Positionen in der cXML-Datei bzw. im cXML-Strom benutzt. Kindelement-Aufrufe in einer Grammatikregel führen zu einem Aufruf der Grammatikregel für das als Parameter übergebene Element. Kindelement( E ) -> Elementdeklaration( E ).
Beispiel 2: Kompression mit Hilfe der Grammatikregeln
Das Beispiel erklärt die Anwendung der Grammatikregeln zur Datenkompression nach dem Verfahrensschema der Fig. 6.
Das gezeigte Schema hat die folgende Abfolge von Verfahrensschritten: den oben genannten Schritt S3 des Erzeugens von Grammatikregeln einen Schritt S4 des Einlesens eines SAX-Ereignisses, einen Schritt S5 der Anwendung der Grammatikregeln auf das SAX-Ereignis einen Schritt S6 der Erzeugung einer Komprimierten Ausgabe
Dabei werden die Schritte S4 bis S6 schleifenartig durchlaufen, so daß die SAX- Ereignisse nacheinander verarbeitet werden.
Die DTDs, die in Fig. 1b und 3b zu sehen sind, enthalten fünf verschiedene Operatoren: '?', '*', '+', ',' und ,|\ wobei ,?', ,*' und ,+' unäre Operatoren und „' und ,|' binäre Operatoren sind. Für diese Operatoren wird im Schritt S5 für eine verlustfreie Kompression der Strukturinformation der DTD nach der obigen Attributgrammatik nur für folgende drei Operatorentypen zusätzlich zu der gegebenen Strukturdefinierenden Informationen aus dem vorliegenden XML-Dokument der Fig. 1a benötigt, um die ursprüngliche Struktur dieses XML-Dokumentes aus dem
Komprimat rekonstruieren zu können:
'*', '+': Die Anzahl Wiederholungen des Inhalts dieser unären Operatoren, d.h. für jede Stelle des XML-Dokumentes, an der es laut Strukturdefinition Wiederholungen geben darf, muß die Anzahl der Wiederholungen codiert werden.
'?': Ob der Inhalt dieses unären Operators vorhanden ist oder nicht (d.h., es wird entweder EMPTY für den leeren Inhalt, oder der Inhalt selbst gespeichert. D.h. für jede Stelle des XML-Dokumentes, an der es laut Strukturdefinition Optionen gibt, muß codiert werden, ob das optionale Element (bzw. Attribut) in den XML-Daten vorkommt oder nicht. - '|': Welche der beiden Alternativen wurde gewählt: Entweder eine 1 für die erste oder eine 2 für die zweite Alternative. D.h. Für jede Stelle des XML- Dokumentes, an der es laut Strukturdefinition Alternativen gibt, muß die gewählte Alternative codiert werden.
Für den '.'-Operator wird keine zusätzliche Information gespeichert.
Das in Fig. 1a gezeigte XML-Dokument und die in Fig. 1b gezeigte DTD enthalten zusammen die folgende Information:
Das Paper hat den Titel "XML Compression" und einen Autor mit Namen "John Smith" der via Postfach "0815" (zweite Alternative) kontaktiert werden kann und keine Email-Adresse hat. Das Paper enthält 2 Kapitel mit den jeweiligen Titeln und
Inhalten. Das zweite Kapitel enthält keinen Text (EMPTY), enthält stattdessen aber zwei Unterkapitel mit den jeweiligen Titeln und Inhalten. Diese Unterkapitel enthalten ebenso wie das erste Kapitel des Papers keine weiteren Kapitel (wie durch die Anzahl 0 an Kapiteln ausgedrückt).
Mit der oben erklärten Zusatzinformation der Operatoren der in Fig. 1 b gezeigten DTD und die Konstanten des in Fig. 1a gezeigten XML-Dokuments werden diese Informationen durch Schritt S5 komprimiert wie folgt dargestellt:
XML Compression, 1 , John Smith, 2, 0815, EMPTY, Whenever XML ..., 2,
Introduction, In this paper..., 0, Approach, EMPTY, 2, Algorithms, In order to compress..., 0, Performance, Our tests have shown...,0
Eine Kompression der Konstanten wird auf dieses Komprimat wie folgt angewandt.
Die Kompression von Konstanten des in Fig. 1a dargestellten XML-Dokuments geschieht über einen Trie entsprechend der Veröffentlichung von E. Fredkin: „Trie Memory Communications of the ACM"; 3(9): 490-499, Sept. 1960. Dabei werden Konstanten durch IDs repräsentiert. Das Verfahren erlaubt es, jede Konstante nur einmal zu indizieren bzw. in das Komprimat zu schreiben. Es werden gleiche IDs für jedes Vorkommen derselben Konstante zu verwendet. Während der Kompression eines XML-Datenstroms wird jeder gefundene Textwert des Eingabestroms durch eine eindeutige ID ersetzt, so daß jede Textwert-ID im komprimierten Datenstrom von konstanter Größe ist.
PCDATA-Aufrufe in Schritt S5 ordnen jeder Textkonstante ihre jeweiligen ID zu, die in Schritt S6 ID in den Ausgabestrom ausgegeben wird. Eine Funktion getlDfor(...) bestimmt die ID einer gegebenen Textkonstante, und falls die Textkonstante zum ersten Mal auftritt, wird eine neue ID für die Textkonstante generiert, und das Paar
(ID, Konstante) in den Konstanten-Datenstrom geschrieben. Bei einer gegebenen Funktion getlDfor(...) ist die PCDAT A-Grammatikregel also wie folgt implementiert: PCDATA( ) ■» [ Constant ] / [ ] , { ID := getlDfor( Constant ) } , [] / [ID].
Da der EMPTY-Operator einer Textkonstante der Länge 0 entspricht, wird dieser entsprechend wie der PCDAT A-Operator behandelt. Der Unterschied besteht darin, daß der EMPTY-Operator keinen Input konsumiert. EMPTYO ■> {ID := getlDfor(EMPTY) }, [] / [ID].
Für das in Fig. 1a gezeigte Dokument ordnet der Trie die ID ,00' der Konstanten
,XML Compression', die ID ,10' der Konstanten ,Our tests have shown...' und die ID ,11' der Konstanten EMPTY zu.
Mit dem Trie erfolgt in Schritt S5 eine Zuordnung der Konstanten zu ID wie folgt: Trie: 0815(02)A(lgorithms(07)pproach(06))EMTPY(11 )ln(( order to compress...
(08)this paper...(05))troduction(04))John Smith(01)Our tests have shown... (10) Performance(09)Whenever XML...(03)XML Compression(OO) Mit dieser Zuordnung wird in Schritt S6 aus dem obigen Komprimat des in Fig. 1a gezeigten Dokuments die folgende komprimierte Datenfolge bzw. cXML-Dokument:
001012021103204050061120708009100
In Kombination mit der DTD und dem Trie werden dieselben Informationen erhalten wie das XML-Dokument aus Fig. 1a hat.
Sogar bei diesem kleinen Beispiel erhalten wir eine Kompression von 40% (236 Bytes für cXML und Trie im Vergleich zu 486 Bytes für das ursprüngliche XML-
Dokument).
Lediglich die IDs der Konstanten (ohne Zusatzinformation der Operatoren oder EMPTY-Einträge), d.h.
0001020304050607080910
repräsentieren alle Konstanten des XML-Dokuments der Fig. 1a.
Da wir die Strukturinformationen, wie beispielsweise die Information, daß nur ein
Author existiert, benötigen, um XPath-Anfragen zu beantworten, wird das obige cXML-Dokument 001012021103204050061120708009100 in zwei Teile aufgeteilt: den obigen Konstantenstrom - 0001020304050607080910 und einen Dokument-Index-Strom mit der Strukturinformation - 12112011200
Diese Strukturinformation repräsentiert den in Fig. 2 dargestellten Syntaxbaum, auch Kleene-Size-Tree genannt und enthält den folgenden Inhalt:
(1 (2,EMPTY),2(0,EMPTY,2(0,0)))
Dies bedeutet, daß ein Author existiert mit POB (Alternative 2) und einer nicht vorhandenen Email-Adresse. Das Paper enthält 2 Kapitel, wobei das erste keine weiteren Unterkapitel enthält und daß zweite keinen Text, dafür aber 2 Unterkapitel enthält. Diese beiden Unterkapitel enthalten selbst keine weiteren Unterkapitel. Hierbei ist zu beachten, daß statt des EMPTYs auch wieder lediglich eine speichereffizientere ID (11 ) gespeichert wird.
Der Konstantenstrom und der Dokument-Index-Strom werden in Schritt S6 nach den beiden folgenden Vorgaben erzeugt:
1 ) Wann immer in der XML-Datei eine Stelle erreicht ist, an der laut Strukturdefinition eine Alternative, Wiederholung oder Option zulässig ist, was in der
Strukturdefinition durch einen der drei Operatortypen (Alternative, Wiederholung oder Option) gekennzeichnet ist, wird die im XML-Dokument ermittelte Situation, also die vorliegende Alternative, die vorliegende Anzahl von Wiederholungen oder ob eine Option im vorliegenden XML-Dokument gewählt wurde, in den Dokument- Index-Strom geschrieben.
2) Wann immer beim Parsen des XML-Dokumentes und dem Abgleich mit den Syntax-Bäumen eine Konstante gelesen wird (im Falle des in Fig. 3a gezeigten Dokuments kann dies auch ein Attribut-Wert sein), so wird diese Konstante in den Konstanten-Strom geschrieben.
Zudem wird im Konstanten-Strom eine Menge von Konstanten in Paketen zusammengefasst und mit einem konventionellen Kompressionsverfahren komprimiert, welches 1. Verweise innerhalb eines Paketes erlaubt,
2. mindestens einen Verweis aus dem Dokument-Index-Strom auf den Beginn jedes Pakets erlaubt
3. die Eingabe-Reihenfolge der Konstanten erhält. Beispiel 3: Kompression mit Entfernung von Redundanzen in den XML-Daten
Es zunächst werden gemeinsame Teilbäume in den XML-Daten der Fig. 3a identifiziert und die daraus resultierenden internen Redundanzen entfernt. Insgesamt wird durch das Entfernen mehrfach vorkommender Teilbäume in einer ersten Vorbearbeitung aus dem SAX-Ereignis-Strom der XML-Daten der Fig. 3a ein DAG aufgebaut wie es eingangs in Verbindung mit Figs. 3a und 3b und der Veröffentlichung von Koch et. al. gezeigt wurde.
Dazu wird die XML-Datei oder der eingehende SAX-Ereignis-Strom auf SAX-
Ereignisse untersucht, die mehrfach vorkommende Teilbäume repräsentieren. Das Verfahren unterscheidet, ob ein Teilbaum zum ersten Mal oder wiederholt vorkommt.
Eingehende SAX-Ereignisse vom Typ startDocument, character, endElement und endDocument, die zu einem das erste Mal vorkommenden Teilbaum gehören, werden direkt und unverändert als DAG-Ereignis an eine zweite Vorbearbeitung zum Entfernen von Redundanzen aufgrund der gegebenen Schema-Informationen weitergeleitet.
Eingehende SAX-Ereignisse vom Typ startElement, die zu einem das erste Mal vorkommenden Teilbaum gehören, werden aufgesplittet in ein startEiement- Ereignis und mehrere attribute-Ereignisse. Aus dem XML-Dokument der Fig. 3a wird so ein Ereignis startElement(kunde, attList), wobei die Attribut-Liste attList aus dem Attribut ,name="Meier" besteht, aufgesplittet in:
startElement(kunde) attribute(name, Meier)
Eingehende SAX-Ereignisse, die zu einem wiederholt vorkommenden Teilbaum gehören, werden überhaupt nicht weitergeleitet. Lediglich für die Wurzel jedes wiederholt auftretenden Teilbaumes W eines erstmalig auftretenden Teilbaumes E, wobei W nicht Teil eines umfassenderen wiederholt auftretenden Teilbaumes ist, wird ein DAG-Ereignis erzeugt und weitergeleitet. Dieses DAG-Ereignis enthält einen Verweis auf das vorangegangene DAG-Ereignis startElement des Wurzelelementes des erstmalig auftretenden Teilbaumes. Dieser Verweis wird als Rückwärtsverweis mit relativer Entfernung implementiert, der im Eingangs gezeigten DAG als Zeiger pointer (6) oder pointer (8) dargestellt ist.
Die Kompression geschieht im übrigen im wesentlichen wie im Beispiel 2. Anders als im Beispiel 2 wird jedoch die DAG-Ereignisse konsumiert.
Dazu wird, wenn ein DAG-Ereignis ein Verweis auf ein vorangehendes DAG- Ereignis ist, im Komprimat wie folgt ein Verweis gesetzt: Wenn es für das vorangehende DAG-Ereignis einen Eintrag im Dokument-Index-Strom gibt, wird ein Verweis auf diesen Eintrag gesetzt, sonst wird im Konstanten-Strom ein Verweis auf die Stelle gesetzt, die den ersten Eintrag im Konstantenstrom zu diesem DAG- Ereignis repräsentiert. Da jeder Knoten n eindeutig durch denjenigen Textknoten t, der durch einen First-Child-Pfad erreichbar ist, und den Abstand von t zu n identifiziert werden kann, besteht ein Verweis im Konstantstrom aus dem Zweiertupel (Abstand zu Knoten t, Position von Knoten t im Konstantenstrom). Hat ein Knoten mindestens ein Attribut, so ist dieser genauso durch das Zweiertupel (Abstand zum Attribut=1 , Position des Attributwertes im Konstantenstrom) identifiziert. Da der Abstand normalerweise recht gering ist, die Abstandsangabe also sehr kleine Zahlen enthält, erhält man so eine besser komprimierte Speicherweise als bei den sonst üblichen Verfahren, bei denen 2-Tupel(Position, Länge) gespeichert werden.
Konkret wird also der Dokument-Index-Strom und der Konstanten-Strom wie folgt aus einer Menge von gegebenen Syntax-Bäumen und einem DAG- oder SAX- Ereignis-Strom berechnet.
Hierzu benötigen wir zunächst einmal die Menge der Start-Terminal-Symbole (kurz STS) für jeden Knoten bis auf den Wurzelknoten jedes Elementdeklarations-
Syntaxbaums. Diese Mengen werden wie oben beschrieben berechnet.
Begonnen wird mit demjenigen Syntax-Baum, der der Elementdeklaration der im XML-Dokument festgelegten Wurzel entspricht. Entsprechend des Operator-Typs des aktuell gelesenen Knotens im Syntax-Baum werden der Eingabestrom und die Syntax-Bäume durchlaufen.
Wir unterscheiden 1. Operationen zum Durchqueren der Syntax-Bäume der Strukturdefinitionen und zum anderen Operationen auf dem DAG-Strom.
Die Operationen zum Durchqueren der Syntax-Bäume sind:
• n.anzahlKindknoten() //Ermittelt die Anzahl der Kindknoten des Knotens n eines aus den Strukturdefinitionen erzeugten Syntaxbaums.
• n.kindknoten(i) //Liefert den i-ten Kindknoten des Knotens n in einem aus den Strukturdefinitionen erzeugten Syntaxbaum
Die Operationen auf dem DAG-Ereignis-Strom sind:
• leseNächstesEreignisVomDAGStrom //liest nächstes Ereignis vom DAG- Strom (löscht dieses aber nicht, d.h. nochmaliges Lesen desselben Ereignisse ist möglich) • löscheNächstesEreignisVomDAGStrom //löscht nächstes Ereignis vom DAG-
Strom
Ein Quellcodebeispiel für die Kompression ist wie folgt:
comp (Wurzelknoten) ; // Aufruf zur Kompression des ganzen Dokuments
Stack pfad; //Pfad von der Wurzel zum aktuellen Element public void addPointer (ID eID) { pos = IndexStore.get (eID) ; if (pos ! =null) //Setze Verweis im Dokument-Index-Strom DokumentIndexStrom. addPointer (pos) ; eise //Setze Verweis im Konstanten-Strom KonstantenStrom. addPointer (KonstantenStore. get (eID) ) ;
} public void schreibeKonstante (Text t) { pos = KonstantenStrom. write (t) ,- Stack pfadKopie = pfad. clone () ; level = 0;
//Ersetze alle UNKNOWNS durch pos + Abstand zu //diesem Knoten while (KonstantenStore. get (pfadKopie . top () ) ==UNKNOWN) {
KonstantenStore . set
(pfadKopie .pop ( ) , Pointer (level , pos) ) ; level++ ; }
public void comp (Knoten n)
{ case (n ist vom Typ) {
Elementdeklaration{ Ereignis e = leseNächstesEreignisVomDAGStromO ; löscheNächstesEreignisVomDAGStrom ( ) ; if(e ist Pointer) addPointer (e . id ()); eise { // e ist startElement
Konstantenstore . add (e . id ( ) , UNKNOWN) ; pfad.push (e. id() ) ; //Knoten auf den Stack legen for(int i = 0 ,- i < n. anzahlKindknoten ( ) ) ,- i++) comp (n. kindknoten (i) ) ; //Konsummiere endElement löscheNächstesEreignisVomDAGStrom ( ) ; pfad.popO; //Knoten vom Stack löschen
Sequenz { for(int i = 0 ,- i < n. anzahlKindknoten ()); i++) comp (n. kindknoten (i) ) ;
Alternative{
Ereignis e = leseNächstesEreignisVomDAGStrom( ) ; if(e ist Pointer) { addPointer (e . id ( ) ) ; löscheNächstesEreignisVomDAGStromC ) ;
} else{ // e ist startElement for(int i = 0; i < n. anzahlKindknoten ()); i++) {
Knoten k = n. kindknoten (i) ; Set sts = k.startTerminalSymboleO ; if (sts. enthält (e.label 0 ) ) { pos = DokumentIndexStrom. write (i) ; IndexStore.add(e . id() , pos); comp (k) ; return;
}
}
Wiederholung{
Ereignis e = leseNächstesEreignisVotnDAGStromO ; if(e ist Pointer) { addPointer (e . id ( ) ) ; löscheNächstesEreignisVomDAGStromO ; } else{ // e ist startElement
Set sts = n.startTerminalSymboled int i = 0 ; while (sts. enthält (e. label ())){ i = i + 1; comp (n . kindknoten (O));
} pos = DokumentIndexStrom. write (i) , IndexStore.add(e. id() , pos);
}
Option{
Ereignis e = leseNächstesEreignisVomDAGStrom( ) ; if(e ist Pointer) { addPointer (e . id ( ) ) ; löscheNäehstesEreignisVomDAGStrom ( ) ; } else{ // e ist startElement
Set sts = n. startTerminalSymbole () ,- //Option liegt vor if (sts. enthält (e. label () )){ pos=DokumentIndexStrom.write (1) ; comp (n . kindknoten (O));
} eise //Option liegt nicht vor pos=DokumentIndexStrom.write (0) ;
IndexStore . add (e . id () , pos);
}
Kind-Element-Name{ comp (elementDeklaration (n. label O)); }
Attribut! Ereignis e = leseNächstesΞreignisVomDAGStromO ; löscheNächstesEreignisVomDAGStrom ( ) ; if(e ist Pointer) addPointer (e. id ()); eise { // e ist attribute (id,name, value) Konstantenstore . add (e . id ( ) , UNKNOWN) ; pfad.push(e.id() ) ; //Knoten auf den Stack legen schreibeKonstante (e .value ( ] pfad.popO ; }
PCDATA{
//lese character-Ereignis
Ereignis e = leseNächstesEreignisVomDAGStrom I schreibeKonstante (e . label ( ) ) ; }
Die nachfolgende Tabelle 1 zeigt in der mittleren Spalte die Folge von Tokens des Dokument-Index-Stroms aus dem eingangs zu den Figuren 3a und 3b angegebenen DAG dar und in der rechten Spalte Operatoren bzw. Knoten dar. Wie die Strukturinformationen in Beispiel 2 geben die Tokens je nach Operator Wiederholungen, Alternativenauswahl oder Gegenwart optionaler Werte an. Im vorliegenden Beispiel ist ein Token als Zeiger bzw. Rückwärtsverweis zum sechs Zeilen oberhalb vorhergehenden Token der Tabelle vorgesehen. Dieser repräsentiert die beiden aufeinander folgenden gleichartigen Tabelleneinträge von diesem vorhergehenden Token und seinem Nachfolger.
Die nachfolgende Tabelle 2 zeigt in der mittleren Spalte die Folge von Konstanten des Konstantenstroms aus dem eingangs zu den Figuren 3a und 3b angegebenen DAG dar. Im vorliegenden Beispiel ist ein Token als Zeiger bzw. Rückwärtsverweis zu der acht Zeilen oberhalb vorhergehenden Konstanten und der ihr nachfolgenden Konstanten, die zur gleichen Elementdeklaration künde der Fig. 3b gehören und repräsentiert diese Konstanten.
In der linken Spalte von Tabelle 1 bzw. 2 werden die Zeileneinträge kategorisiert, je nachdem, ob es sich um Rückwärtsverweise (Pointer) handelt oder nicht (d.h. um Konstanten).
Tabelle 1
Figure imgf000032_0001
Tabelle 2
Figure imgf000032_0002
Sowohl für den Dokument-Index-Strom als auch für den Konstanten-Strom wird im Hauptspeicher innerhalb eines gegebenen Fensters für die Position jedes Tokens im Strom die entsprechende Ereignis-ID des DAG-Ereignisse vom Typ startEreignis oder vom Typ attribute gespeichert. Wird als nächstes Ereignis statt eines DAG- Ereignisse vom Typ startEreignis bzw. vom Typ attribute ein Verweis V auf ein DAG-Ereignis D gelesen, so wird zunächst geprüft, ob zu D im Dokument-Index- Strom ein Eintrag E existiert, der D repräsentiert. Existiert ein D repräsentierender Eintrag E im Dokument-Index-Strom, so wird im Dokument-Index-Strom für V ein Verweis auf E eingefügt. Existiert kein D repräsentierender Eintrag E im Dokument- Index-Strom, so wird V durch einen Verweis im Konstanten-Strom repräsentiert, der die erste im Konstanten-Komprimat für D gespeicherte Konstante repräsentiert.
Immer wenn im DAG-Strom ein Verweis auf ein DAG-Ereignis D gelesen wird, entfällt die erneute Abarbeitung der Kindknoten von D komplett.
Eigenschaften eines Komprimats nach den Beispielen 1 bis 3
Für die Operatoren Sequenz, Choice, PCDATA, EMPTY und Kindelement, kann die relative Position der gesuchten Daten im Strom eindeutig bestimmt werden. Nur für den Kleene-Operator (*) kann die Anzahl von Wiederholungen variieren.
Da alle Textwerte, die durch PCDATA-Knoten beschrieben werden durch deren jeweilige IDs ersetzt werden, benötigen diese lediglich IDsize an Platz im cXML- Strom. Die Größe für jeden Choice-Knoten ist sogar geringer und hängt von der maximalen Anzahl an Alternativen ab, die durch den Choice-Operator geboten werden, z.B. ist 1 Bit ausreichend, wenn nur eine binäre Auswahl in der DTD vorkommt. Hierbei ist insbesondere zu beachten, daß die Knotentypen
Elementdeklaration, Sequenz und Kindelement gar keinen Platz für Strukturinformationen im cXML-Datenstrom konsumieren.
Die einzige Größeninformation, die übertragen werden muß, ist die für den Kleene- Operator, da die Größeninformation aller anderen Operatoren (Sequenz, Choice,
PCDATA, EMTPY, Elementdeklaration und Kindelement) konstant ist. Die jeweiligen konstanten Größen sind in Tabelle 3 zusammengefasst. Tabelle 3 Größe der verschiedenen Elementdeklarations-Operatoren
Figure imgf000034_0001
Während der Komprimierung des Eingabestroms wird bei jeder Anwendung einer PCDAT A-Grammatikregel, einer EMPTY-Grammatikregel oder einer erweiterten
Grammatikregel entsprechend Beispiel 1 die Größe jedes Teilbaumes aufsummiert.
Immer wenn die Größe eines Teilbaumes mit einer Wurzel vom Knotentyp Kleene berechnet wird, wird diese Information in den so genannten Kleene-Size-Tree geschrieben. Dieser Kleene-Size-Tree ist wie folgt aufgebaut: immer wenn ein
Kleene-Operator K1 innerhalb eines anderen Kleene-Operators K2 erscheint, so ist K2 im Teilbaum mit der Wurzel K1 enthalten. Wie das Beispiel in Tabelle 1 zeigt, wird das folgende für jeden Kleene-Knoten im Kleene-Size-Tree gespeichert: Wie viele Index-Positionen können im cXML-Datenstrom übersprungen werden, wenn der Teilbaum, der als Wurzel den Kleene-Knoten hat, zur Beantwortung der
Anfrage nicht benötigt wird. Die Knoten des Kleene-Size-Trees werden in einen weiteren Strom, den so genannten Index-Strom geschrieben.
Um den Kleene-Size-Tree dazu zu nutzen, auf Pfade im cXML-Strom zuzugreifen, müssen wir die folgenden zwei Dinge für jeden Knoten des Kleene-Size-Trees wissen: die Anzahl der Nachfolger und die Position der Nachfolger im Index-Strom. Mit anderen Worten, wir müssen den Kleene-Size-Tree durchqueren. Da die Kompressionsresultate aller anderen Knotentypen feste Größen haben, können wir alle relativen Positionen mit Hilfe des Kleene-Size-Trees und mit Hilfe von Tabelle 3 bestimmen.
Es ist von Vorteil, den Keene-Size-Tree zur Berechnung der Positionen zu benutzen, wenn wir dafür im Gegenzug Teile der XML-Daten überspringen können. Die Komprimate ermöglichen zudem die Auswertung von XPath-Anfragen auf dem komprimierten XML-Datenstrom.
Falls eine XPath-Anfrage Rückwärtsachsen enthält, so kann der bekannte Algorithmus aus Neel Sundaresan, Reshad Moussa: "Algorithms and programming modeis for efficient representation of XML for Internet applications", WWW 2001 , angewandt werden, um diese XPath-Anfrage in eine äquivalente Anfrage ohne Rückwärtsachsen umzuschreiben.
Wenn die auszuwertende XPath-Anfrage keine Rückwärtsachsen enthalten kann wie in Beispiel 5 für die Auswertung von XPath-Anfragen eine Anpassung des Verfahrens aus P.M. Tolani und J. R. Hartisa, "XGRIND: A Query bzw. Anfrage- friendly XML compressor", In Proc. ICDE 2002, pages 225-234. IEEE Computer Society, 2002 verwendet werden. Dieser Ansatz optimiert die Auswertung von XPath-Anfragen auf XML-Dokumenten und insbesondere auf XML-Datenströmen, so daß das gesamte Dokument (bzw. der Strom) nur einmal gelesen werden muß. Die Puffergröße, die benötigt wird, um Elemente temporär zwischenzuspeichern hängt von der Verwendung von Filtern ab. Des Weiteren werden die Schemainformationen der DTD ausgenutzt, um die Berechnungszeit zur Entscheidung der Erfüllbarkeit von Filtern zu reduzieren, und um Teile des
Dokumentes zu identifizieren, die übersprungen werden können, da sie keine zur Beantwortung der Abfrage notwendigen Informationen enthalten. Dieses Überspringen von Teilen des Dokumentes (bzw. des Stroms) entspricht der direkten Adressierung der bekannten Position des nächsten Elements, wie es oben beschrieben wurde. Der Unterschied jedoch besteht darin, daß wir in diesem Fall einen komprimierten XML-Datenstrom vorliegen haben, d.h. um den von P.M. Tolani und J. R. Hartisa vorgestellten Ansatz anwenden zu können, müssen die Kind- und Nachfolger-Geschwister-Achsen in relative Positionen im cXML-Strom übersetzt werden.
Welcher Teil des Dokuments (bzw. des Stroms) übersprungen werden kann, d.h. die konkrete relative Position im Dokument (bzw. im Strom) kann berechnet werden, durch die Kombinierung der Größeninformationen im Kleene-Size-Tree und der Informationen der Elementdeklarations-Syntaxbäume. Beispiel 4: Dekompression
Eine Dekompression eines nach Beispiel 3 erzeugten Komprimats erfolgt mit Umkehrung der Reihenfolge von zur Kompression ausgeführten Phasen durch: 1. Dekompression in einen DAG-Ereignis-Strom
2. Dekompression des DAG-Ereignis-Stroms in einen SAX-Ereignissetrom
Zur Dekompression wird die Menge der Grammatikregeln - unter Vertauschen der Rollen des Eingabe- und des Ausgabestroms - auch zur Dekompression nach dem Verfahrensschema der Fig. 7 genutzt, mit einem Schritt S3 des Einlesens der Grammatikregeln einem Schritt S7, in dem entsprechend zur Kompression die Syntax-Bäume durchlaufen werden. Begonnen wird wieder mit demjenigen Syntax-Baum, der der Elementdeklaration der im XML-Dokument festgelegten Wurzel entspricht, - entsprechend des Operator-Typs des aktuell gelesenen Knotens im Syntax-Baum einem Schritt S8 der Anwendung der Grammatikregeln, wobei zur Dekompression benötigte Token des Dokument-Index-Stroms und des Konstanten- Stroms konsumiert werden einem Schritt S8 der Erzeugung einer dekomprimierten Ausgabe
Wann immer im Dokument-Index-Strom oder im Konstanten-Strom ein Verweis gelesen wird, so wird der Wurzelknoten des verwiesenen Teilbaums anhand der Verweisposition sowie der Levelinformation ermittelt und entsprechend im DAG- Ereignis-Strom ein Verweis auf das DAG-Ereignis dieses Wurzelknotens erzeugt.
Ein Quellcodebeispiel für die Dekompression ist wie folgt:
decomp (Wurzelknoten) ; // Aufruf zur Dekompression Stack pfad; //Pfad von der Wurzel des XML-Dokuments zum
//aktuellen Element public erzeugePointer (Pointer x) { level = 0; if(x. level () != null) level = x. level (),-
//Wurzel des Teilbaum ist das Element, welches im //Wurzel-Pfad level Ebenen vom Stack-Ende entfernt ist DAG .pointer (pfad . get (level ) ) ; } public void decomp (Knoten n) case (n ist vom Typ) {
Elementdeklaration{ ID id = eindeutigelD () ; pfad.push(id) ; //Knoten auf den Stack legen
//Schreibe Start-Tag DAG. startElement (id, n. label () ) ; for(int i = 0; i < n. anzahlKindknoten ()); i++) decomp (n . kindknoten ( i ) ) ;
//Schreibe End-Tag DAG. endElement (n. label ()); pfad.popO; //Knoten vom Stack löschen
}
Sequenz { for(int i = 0; i < n.anzahlKindknoten () ) ; i++) decomp (n. kindknoten (i) ) ;
}
Alternative{ x = DokumentIndexStrom. read (); if (x ist Pointer) erzeugePointer (x) ; eise decomp (kindknoten (x) );
} Wiederholung! x = DokumentlndexStrom. read (); if (x ist Pointer) erzeugePointer (x) ; eise for(int i = 0; i< x,- i++) { decomp (n . kindknoten (O)); }
}
Option{ x = DokumentlndexStrom. read (); if (x ist Pointer) erzeugePointer (x) ; eise if (x==l) { decomp (n. kindknoten (0) ) ;
}
Kind-Element-Name{ decomp (elementDeklaration (n. label () ) ) ; } Attribut!
ID id = eindeutigelD () ; pfad.push(id) ; //Knoten auf den Stack legen x = KonstantenStrom. read (); if (x ist Pointer) erzeugePointer (x) ; eise DAG.attribute (id, n.label(), x) ; pfad.popO; //Knoten vom Stack löschen
}
P CDATA { x = Konstantenstrom . read ( ) ; if (x ist Pointer) erzeugePointer (x) ; eise DAG . character (x) ; }
}
Dann wird aus dem DAG-Ereignis-Strom der ursprüngliche SAX-Eingabestrom berechnet. Hierzu werden alle endElement und character-Ereignisse direkt an den SAX-Strom weitergeleitet. Die SAX-Ereignisse vom Typ startElement werden aus einem DAG-Ereignis vom Typ startElement und den darauffolgenden DAG- Ereignisse vom Typ attribute - ohne die jeweiligen IDs - zusammengesetzt. Gleichzeitig werden alle Ereignisse inklusive ID im Hauptspeicher zwischengespeichert. Sobald ein pointer-Ereignis gelesen wird, so wird zu dem verwiesenen DAG-Ereignis zurückgesprungen und die Ereignisse des mit diesem Ereignis startenden Teilbaums ausgegeben.
Eine Implementierung kann auch in einer anderen Sprache umgesetzt werden, wie z.B. in Java unter Verwendung eines SAX-Parsers und der Attribut-Grammatik von JavaCC. Dann sollte eine erweiterte Regelmenge zur Kompression und eine zweite umgekehrte Implementierung zur Dekompression erzeugt werden.
Beispiel 5 Auswerten von XML-Pfadanfragen mit Hilfe der Menge von Grammatikregeln auf den komprimierten Daten
Um Daten im Strom zu finden, die einem bestimmten Pfad, welcher durch einen XPath-Ausdruck gegeben ist, entsprechen, benutzen wir nach dem
Verfahrensschema der Fig. 8 den Kleene-Size-Tree um die Position der Information zu berechnen, nach der gesucht wird. Das Verfahrensschema hat die folgenden Schritte:
- S3, Einlesen der Grammatikregeln - S10, Einlesen der Pfadanfrage
- S1 1 , Berechnung der Position zu einer Teilstruktur mit einer durch den Pfadausdruck angefragten Konstante in der komprimierten Sequenz durch
Aufsummierung der Produkte
- S12, Ermittlung der Konstanten der Teilstruktur und der Strukturinformationen zu der Teilstruktur
- S13, Rekonstruktion der Teilstruktur - S14, Ausgabe des Wertes der angefragten Konstante.
Zur Ausgabe mehrerer Werte werden die Schritte S11 bis S14 schleifenartig durchlaufen.
Dabei werden die Schritte S11 bis S14 schleifenartig bis zum Auffinden der gesuchten Information durchlaufen.
Analog zur Dekompression werden auch zur Auswertung von Pfadausdrücken die Syntax-Bäume durchlaufen und jeweils bei Bedarf wird das nächste Token des Dokument-Index-Stroms gelesen. Im Gegensatz zur Dekompression wird jedoch nicht ein DAG-Ereignis-Strom erzeugt, sondern lediglich die Struktur der XML- Daten im Hauptspeicher partiell durch Dekompression rekonstruiert. Auch werden beim Parsen eines PCDATA- oder eines Attribut-Knotens nicht alle Konstanten eines XML-Teilbaums rekonstruiert. Lediglich, wenn die Auswertung des Pfadausdrucks auf dem partiellen XML-Struktur-Index ergibt, daß eine Konstante zur Auswertung eines Filters oder zur Ausgabe des Resultats benötigt wird, so wird die relative Position dieser Konstante im Komprimat (genauer im entsprechenden Paket des Konstanten-Stroms) ermittelt.
Für das nach Beispiel 2 aus dem XML-Eingabedokument der Fig. 1a komprimierte cXML-Dokument fragt eine XPath-Anfrage /E1 [2]# nach dem vollständigen Teilbaum unter dem zweiten Element E1 des Eingabestroms. Im vorliegenden Beispiel hat ein erstes Element eines entsprechenden, wie in Fig. 2 schematisierten Syntaxbaums E1 10 E3 oder E4 Kindknoten und das zweite Element E1 5 E3 oder E4 Kindknoten. Da der für E1 generierte Syntaxbaum nur einen Kleene-Operator enthält, existiert im Kleene-Size-Tree 1 Knoten für jedes Vorkommen eines Knotens E1 im XML-Eingabedokument. Daher enthält der Kleene-Size-Tree folgende Größeninformation:
10*(choice_size+IDsize) und
5*(choice_size+IDsize).
Sind diese Kleene-Größen bekannt, so kann man die Größen der komprimierten
Repräsentation der ersten beiden Elemente E1 wie folgt berechnen:
E11size = IDsize + 10* (choice_size + IDsize) und
E12size = IDsize + 5* (choice_size + IDsize)
Dies berücksichtigt außerdem noch die Größe der ID des in E2 enthaltenen Textwertes. Insgesamt können also bei Auswertung der Query bzw. Anfrage /E1[2]# die ersten E11size Bytes des cXML-Stroms übersprungen werden, und es müssen dann die nächsten E12size Bytes des cXML-Stroms gelesen und dekomprimiert werden. Da wir wissen, daß das Ergebnisfragment der DTD-Deklaration für E1 entspricht, wissen wir, welche Grammatikregeln zur Dekompression angewandt werden müssen, in diesem Fall also die Grammatikregeln für E1. Das Dekompressionsverfahren ist in Beispiel 4 veranschaulicht.
Je nach Pfadausdruck können große Teile des Konstanten-Stroms übersprungen werden. Des Weiteren sind der Dokument-Index-Strom und die Strukturdefinition in der Regel um vieles kleiner als der eigentliche Struktur-Anteil der XML-Daten, so daß der XML-Struktur-Index schneller aufgebaut werden kann, was eine schnellere Auswertung der Pfadanfragen verspricht.
Insbesondere Anfragen bzw. Queries, die komplett auf dem XML-Struktur-Index beantwortet werden können - also keinerlei Zugriff auf den Konstanten-Strom fordern - können um ein Vielfaches schneller als auf den originalen XML-Daten beantwortet werden. Beispiele für solche Anfragen sind z.B. count-Anfragen auf der Struktur, zum Beispiel nach der Anzahl der Bestellungen für ein in Fig. 3a dargestelltes XML-Dokument.
Die relative Position kann berechnet werden, indem beim Durchqueren der Syntax-
Bäume der letzte Verweis auf den Beginn eines Paketes gespeichert wird, und von dort an die Anzahl der PCDATA-Knoten mitgezählt wird. Zur Ermittlung der konkreten Konstanten zu der aktuellen Position muß dann das Paket des Konstanten-Stroms, auf das verwiesen wird, bis zu dieser Position rekonstruiert werden. Dazu wird ein virtueller Positionszeiger auf den Beginn des verwiesenen
Pakets gesetzt. Wird als Eintrag ein Konstanten-Wert gelesen, so wird der Positionszeiger um eins erhöht. Wird statt eines Konstantenwerts ein Verweis gelesen, so merken wir uns die aktuelle Position und kehren zum Eintrag, auf den verwiesen wird, zurück und zählen von dort aus den Positionszeiger weiter. Sobald im XML-Struktur-Index der Teilbaum, dessen Wurzel durch den Pointer bestehend aus Level-Information und Konstanten-Position bestimmt ist, abgearbeitet ist, kehren wir wieder zum gespeicherten aktuellen Knoten zurück und zählen von dort den Positionszeiger weiter, bis der Positionszeiger der ermittelten relativen Position im Paket entspricht. An dieser Position findet sich dann der benötigte Wert, anhand dessen der Filter ausgewertet werden kann, bzw. der dann ausgegeben werden kann.
Beispiel 6: Arbeiten mit herkömmlichen DTDs
Bis jetzt haben wir angenommen, daß jede rechte Seite einer Elementdeklaration solch eine Menge von Start-Terminal-Symbolen nutzt, die eindeutig bestimmt, welche Grammatikregel als nächstes angewandt werden muß. Wenn die rechte Seite einer Elementdeklaration jedoch nicht diese Eigenschaft hat, so kann man die rechte Seite dieser Elementdeklaration umschreiben in eine äquivalente Elementdeklaration, die dieser Bedingung genügt. Dies ist immer möglich, da die rechte Seite einer Elementdeklaration einem regulären Ausdruck entspricht, und jeder reguläre Ausdruck kann in einen regulären Ausdruck mit der gewünschten Eigenschaft umgeschrieben werden (durch Generierung eines NFA und DFA für diesen). Eine an dieser Stelle nicht näher ausgeführte Komplexitätsanalyse zeigt, daß die Kompression selbst in Polynomzeit ist, so lange die Elementdeklarationen die gewünschte Eigenschaft besitzen. Der einzige exponentielle Teil dieses Verfahrens ist das Umschreiben einer Elementdeklaration ohne diese Eigenschaft in eine äquivalente mit der gewünschten Eigenschaft. Hierbei ist jedoch zu beachten, daß die Anzahl der Elementdeklarationen durch diesen Schritt nicht verändert wird.
Beispiel 7: Indizierung und Pfad-Berechnung für XML-Datenströme und rekursive DTDs
Unser Verfahren ist nicht darauf beschränkt, nur XML-Dokumente einer festen Größe zu komprimieren. Das Verfahren ist sogar in der Lage, fortlaufende (quasi unendliche) XML-Datenströme zu komprimieren, da nicht das gesamte Dokument bekannt sein muß, bevor die Kompression beginnen kann, d.h. die erweiterten Grammatikregeln können dazu verwendet werden, fliegend zu komprimieren.
Außerdem ist unser Verfahren nicht auf nicht-rekursive DTDs beschränkt, d.h. alle Ideen können auch dann angewandt werden, wenn z.B. die Elementdeklaration von E1 in die folgende rekursive Elementdeklaration geändert wird: < !ELEMENT E1 ( E2 , ( E1|E4 ) )* > Unser Ansatz ist also auch auf rekursive DTDs anwendbar. Auch die Index-
Berechnung und die Pfad-Auswertung sind entsprechend auf rekursive DTDs und XML-Datenströme anwendbar.
Bündeln der Datenströme
Betrachten wir in Fig. 9 einen XML-Strom 1, so erhalten wir drei verschieden Arten von Ausgabeströmen eines Komprimats 7: die zweite Komprimatsequenz 5 sowie erste Komprimatsequenz der Konstanten und IDs 6 und einen herkömmlich komprimierten XML-Datenstrom 4 mit allen übrigen zur Rekonstruktion der XML- Datensequenz benötigten Werten. In einer praktischem Implementierung werden diese drei Datenströme auf Seiten des Senders zu einem Strom 7 gebündelt. Ein Grammatikregelgenerator 3 konsumiert nach der in Beispiel 1 veranschaulichten Funktionsweise eine DTD 2 und einen XML-Datenstrom 1 , um das Komprimat 7 auszugeben. Auf der Empfängerseite kann der dekomprimierte Datenstrom 8 mit dem in Fig. 7 schematisierten Verfahren V1 wieder hergestellt werden. Mit dem in Fig. 8 schematisierten Verfahren V2 können Pfadanfragen ausgeführt und gezielt angefragte Daten in einem Strom 9 ausgegeben, gegebenenfalls über eine Dekompression von Teilbäumen V3 auch als dekomprimierter Strom 10.
Vorteile
Eingabe für das Verfahren sind die vorgegebene Struktur-definierende Information des Dokumentes sowie die XML-Daten, z.B. in Form eines SAX-Ereignis-Stroms. Das Verfahren beginnt die Kompression sofort nach Erhalt der ersten SAX-
Ereignisse, es muß also nicht warten, bis alle SAX-Ereignisse ausgeführt sind oder die ganze XML-Datei in den Hauptspeicher geladen ist. Daher ist es auch für sehr große (oder sogar unendlich große) Sequenzen von XML-Daten und damit auch für XML-Datenströme geeignet.
Ausgabe des Kompressionsverfahrens sind zwei Datenströme, der Dokument- Index-Strom und der Konstanten-Strom. Der Dokument-Index-Strom ist gemeinsam mit der Struktur-definierende Information, z.B. der DTD ein vollständiger Index auf der Struktur der Original-XML-Daten und kann daher für eine schnelle Auswertung von Pfadanfragen genutzt werden. Der Konstanten-Strom enthält fein-granulierte
Pakete der XML-Nutzdaten (also Text-Werte und Attribut-Werte) sowie spärliche Verweise auf diese Pakete, so daß eine partielle Dekompression ermöglicht wird, und damit auch die Auswertung von Pfadanfragen, ohne daß alle Konstanten- Pakete dieses Stromes komplett entpackt werden müssen.
Beide Ströme können Verweise auf vorangehende Stellen im Strom enthalten, die ermöglichen, redundante Teilbäume nur einmal zu speichern (und auch nur einmal zu komprimieren).
Das Verfahren teilt sich im Wesentlichen in 2 Phasen auf:
1. Entfernen von Redundanzen innerhalb der XML-Daten
2. Entfernen von Redundanzen aufgrund der gegebenen Schema-Informationen Da jede dieser Phasen auch für partiellen Input einen korrekten partiellen Output berechnet, finden diese Phasen verzahnt statt, der Output der ersten Phase wird direkt als Input in die zweite Phase geleitet, so daß diese nicht auf die Beendigung der ersten Phase warten muß.
Zur Veranschaulichung wurde externer Struktur-definierende Information in Form von DTD gezeigt. Fachleute werden jedoch erkennen, daß die Erfindung allgemein mit jeder geeigneten Struktur-definierende Information ausführbar ist wie XML Schema oder RelaxNG.

Claims

PATENTANSPRÜCHE
1. Verfahren zur Kompression einer Datensequenz eines elektronischen Dokuments, insbesondere eines teilweise komprimierten XML-Dokumentes, mit Hilfe einer Strukturdefinition zu der Datensequenz, insbesondere einer DTD, eines
XML Schemas oder eines Relax NG Schemas, wobei die Strukturdefinition wenigstens eine Teilstruktur der Datensequenz festlegt und die Datensequenz umfaßt:
Werte von Konstanten, insbesondere Textdaten, zur Darstellung von Information des Dokuments und
Strukturinformationen der Datensequenz, insbesondere Tags, welche Start- und Terminalsymbole zu den Konstanten und zu den Teilstrukturen der Datensequenz aus wenigstens einigen der Konstanten und der Strukturinformationen umfassen, darunter Strukturinformationen, die Teilen der Strukturdefinition entsprechen, gekennzeichnet durch eine Erzeugung a) aus der Datensequenz einer ersten Komprimatsequenz, die die Werte der Konstanten der Datensequenz oder Repräsentanten dieser Werte, insbesondere Indices dieser Werte, umfaßt, und b) aus der Datensequenz einer zweiten Komprimatsequenz durch Entfernung aus der Datensequenz der Werte der Konstanten und aller Strukturinformationen, die Teilen der Strukturdefinition entsprechen.
2. Verfahren nach Anspruch 1 , wobei das elektronische Dokument als DAG oder mit einer parametrisierten oder unparametrisierten Grammatik vorliegt.
3. Verfahren nach Anspruch 1 , wobei die Strukturdefinition als XML-Schema, in Relax NG compact oder Relax NG vorliegt.
4. Verfahren nach Anspruch 2, wobei die Strukturdefinition als DTD, XML-
Schema, in Relax NG compact oder Relax NG vorliegt.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Strukturdefinition zu wenigstens einer Teilstruktur der Datensequenz wenigstens eine Deklaration umfaßt, die unäre Operatoren oder unäre und binäre Operatoren eines Syntaxbaumes, der die Teilstruktur repräsentiert, umfaßt, darunter wenigstens einen unären Kleene-Operator, der als Argument die Anzahl möglicher Wiederholungen der Teilstruktur in der Datensequenz hat, wobei die zweite Komprimatsequenz aus der Datensequenz und der Strukturdefinition mit Werten der Argumente der Operatoren von der Strukturdefinition oder Repräsentanten dieser Werte erzeugt wird.
6. Verfahren nach Anspruch 5, wobei die Operatoren der Strukturdefinition aus der Gruppe gewählt sind, die besteht aus einem Operator zur Anordnung von Strukturen oder Teilstrukturen, insbesondere in einer Sequenz einem Operator zur Auswahl von Strukturen oder Teilstrukturen - einem Operator, der die Option eines Vorkommens von Strukturen oder
Teilstrukturen beschreibt.
7. Verfahren nach einem der vorgehenden Ansprüche, wobei eine dritte Komprimatsequenz geschrieben und ausgegeben wird mit einer Sequenz, in der Abschnitte der ersten und zweiten Komprimatsequenzen aufeinander folgen, entsprechend der Abfolge in der Datensequenz der Konstanten und Start- oder Terminalsymbole der Strukturinformationen, die einer Deklarationen Strukturdefinition zugeordnet sind.
8. Verfahren nach einem der vorgehenden Ansprüche, wobei Operatoren der
Strukturdefinition aus der Gruppe gewählt sind, die besteht aus dem Kleene-Operator, einem Operator, der als Argument die Ordnung von Kindknoten des Syntaxbaumes hat, - einem Operator, der als Argument eine Auswahl eines Kindelements des
Syntaxbaums hat, einem Operator, der als Argument die Option eines Vorkommens eines Kindelements des Syntaxbaums hat.
9. Verfahren nach Anspruch 8, gekennzeichnet durch einen Schritt, in welchem die Datensequenz mit Hilfe der Strukturdefinition transformiert wird durch Entfernung aller Operatoren, die als Argument die Ordnung von Kindknoten des Syntaxbaumes haben, und/oder durch Ersetzen aller Operatoren, die als Argument die Option eines Vorkommens eines Kindelements des Syntaxbaums haben, indem jeder dieser Operatoren ersetzt wird durch, das Kindelement des Syntaxbaums, wenn der Wert des Arguments für das Vorkommen des Kindelements steht bzw. einen Wert einer Konstante, die als Leerwert eingeführt wird, wobei die Erzeugung der zweiten Komprimatsequenz nach diesem Schritt ausgeführt wird.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß die Konstante, die als Leerwert eingeführt wird, und jeweils eine ID für die übrigen Konstanten in die dritte Komprimatsequenz geschrieben wird.
11. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß die Konstante, die als Leerwert eingeführt wird, in die erste oder zweite Komprimatsequenz geschrieben wird.
12. Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch einen Schritt der Berechnung der Mengen der Start- und Terminalsymbole für jede Teilstruktur.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Datensequenz eine indizierte Sequenz, insbesondere eine Folge von DAG Ereignissen, ist.
14. Verfahren nach Anspruch 13, gekennzeichnet durch einen Schritt, in welchem die Datensequenz wenigstens teilweise transformiert wird durch Ersetzen einer Teilstruktur, die sich in der Datensequenz mit gleichen Werten der in Konstanten, die in der Teilstruktur enthalten sind, wiederholt, durch Zeiger auf eine ihr entsprechende vorhergehende Teilstruktur in der Datensequenz, wobei die Erzeugung der ersten und zweiten Komprimatsequenzen nach diesem Schritt ausgeführt wird und der Zeiger oder ein Repräsentant des Zeigers in die zweite Komprimatsequenz geschrieben wird.
15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Repräsentanten der Werte der Konstanten Indices eines Tries sind, der gleiche Indices für gleiche Werte vorsieht, wobei das Verfahren einen Schritt des Hashens der Werte der Konstanten umfaßt.
16. Komprimierte Datensequenz eines elektronischen Dokuments, erhalten durch ein Verfahren nach einem der vorhergehenden Ansprüche.
17. Computerdatei, gekennzeichnet durch eine komprimierte Datensequenz nach Anspruch 16.
18. Verfahren zur Dekompression einer komprimierten Datensequenz nach Anspruch 16, gekennzeichnet durch
Erzeugung einer Folge von Strukturinformationen der Datensequenz aus der zweiten Komprimatsequenz durch Anwendung der Werte der Argumente auf die Strukturdefinition oder die transformierte Strukturdefinition,
Ergänzung der Folge von Strukturinformationen zu der Datensequenz oder der transformierten Datensequenz durch Einsetzen der Werte der Konstanten aus der ersten Komprimatsequenz in diese Folge entsprechend der Strukturdefinition oder der transformierten Strukturdefinition.
19. Verfahren nach Anspruch 18, wobei die transformierte Datensequenz rücktransformiert wird zu der Datensequenz durch Ersetzen der Zeiger durch die der Teilstruktur der transformierten Datensequenz, auf welche die Zeiger verweisen.
20. Verfahren zur Auswertung eines Pfadausdrucks, insbesondere einer XPath- Anfrage für eine XML-Datensequenz, auf einer komprimierten Datensequenz nach Anspruch 16, gekennzeichnet durch Bildung der Produkte aus je einem Wert der Argumente der Kleene- Operatoren der vorhergehenden Syntaxbäume mit der konstanten Länge des jeweiligen durch den Kleene-Operator repräsentierten Syntaxbaumes,
Addition der Größe übrigen Werte der Argumente in der zweiten Komprimatsequenz und der Größe der optionalen Teilbäume, soweit diese vorhanden sind,
Berechnung der Position zu einer Teilstruktur mit einer durch den Pfadausdruck angefragten Konstante in der komprimierten Sequenz durch Aufsummierung der Produkte und zusätzlich addierten Größen.
21. Verfahren nach Anspruch 20, gekennzeichnet durch Dekompression eines Teils der komprimierten Sequenz, der in der Datensequenz der Teilstruktur mit einer durch den Pfadausdruck angefragten Konstante entspricht, nach einem Verfahren nach einem der Anspruch 18 oder 19.
22. Verfahren nach Anspruch 20, wobei die berechnete Position jene des Zeigers in der komprimierten Sequenz ist, gekennzeichnet durch Dekompression eines Teils der komprimierten Sequenz, auf den der Zeiger verweist.
23. Computerprogrammprodukt, das eines oder mehrere der Verfahren implementiert, das/die gewählt ist/sind aus der Gruppe der Verfahren der Ansprüche 1 bis 15 und 18 bis 22.
PCT/DE2007/001205 2006-07-07 2007-07-09 Verfahren zur kompression einer datensequenz eines elektronischen dokuments WO2008003310A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE112007001386T DE112007001386A5 (de) 2006-07-07 2007-07-09 Verfahren zur Kompression einer Datensequenz eines elektronischen Dokuments

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102006031805 2006-07-07
DE102006031805.6 2006-07-07
DE102007031431.2 2007-07-05
DE102007031431 2007-07-05

Publications (1)

Publication Number Publication Date
WO2008003310A1 true WO2008003310A1 (de) 2008-01-10

Family

ID=38565606

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2007/001205 WO2008003310A1 (de) 2006-07-07 2007-07-09 Verfahren zur kompression einer datensequenz eines elektronischen dokuments

Country Status (2)

Country Link
DE (1) DE112007001386A5 (de)
WO (1) WO2008003310A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1376388A2 (de) * 2002-06-21 2004-01-02 Microsoft Corporation Verfahren und System zur Kodierung eines Markierungssprachedokumentes
US6681221B1 (en) * 2000-10-18 2004-01-20 Docent, Inc. Method and system for achieving directed acyclic graph (DAG) representations of data in XML
US20040013307A1 (en) * 2000-09-06 2004-01-22 Cedric Thienot Method for compressing/decompressing structure documents

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040013307A1 (en) * 2000-09-06 2004-01-22 Cedric Thienot Method for compressing/decompressing structure documents
US6681221B1 (en) * 2000-10-18 2004-01-20 Docent, Inc. Method and system for achieving directed acyclic graph (DAG) representations of data in XML
EP1376388A2 (de) * 2002-06-21 2004-01-02 Microsoft Corporation Verfahren und System zur Kodierung eines Markierungssprachedokumentes

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
BUNEMAN P ET AL: "Path Queries on Compressed XML", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, 12 September 2003 (2003-09-12), pages 1 - 12, XP002320151 *
DONGWON LEE ET AL: "CPI: constraints-preserving inlining algorithm for mapping XML DTD to relational schema", DATA & KNOWLEDGE ENGINEERING ELSEVIER NETHERLANDS, vol. 39, no. 1, October 2001 (2001-10-01), pages 3 - 25, XP002456705, ISSN: 0169-023X *
FREDKIN E: "TRIE MEMORY", COMMUNICATIONS OF THE ASSOCIATION FOR COMPUTING MACHINERY, ACM, NEW YORK, NY, US, vol. 3, no. 9, August 1960 (1960-08-01), pages 490 - 499, XP002271883, ISSN: 0001-0782 *
GIORGIO BUSATTO ET AL: "Efficient Memory Representation of XML Documents", DATABASE PROGRAMMING LANGUAGES LECTURE NOTES IN COMPUTER SCIENCE;;LNCS, SPRINGER-VERLAG, BE, vol. 3774, 2005, pages 199 - 216, XP019026285, ISBN: 3-540-30951-9 *
LEVENE M ET AL: "XML STRUCTURE COMPRESSION", INTERNATIONAL WORLD WIDE WEB CONFERENCE, XX, XX, 2003, pages 1 - 14, XP009048149 *
SHINAGAWA N ET AL: "Constructing XML views over binary data", DATABASE ENGINEERING AND APPLICATIONS SYMPOSIUM, 2004. IDEAS '04. PROCEEDINGS. INTERNATIONAL COIMBRA, PORTUGAL JULY 7-9, 2004, PISCATAWAY, NJ, USA,IEEE, 7 July 2004 (2004-07-07), pages 470 - 474, XP010713987, ISBN: 0-7695-2168-1 *
SUNDARESAN N ET AL: "Algorithms and programming models for efficient representation of XML for Internet applications", COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 39, no. 5, 5 August 2002 (2002-08-05), pages 681 - 697, XP004369439, ISSN: 1389-1286 *

Also Published As

Publication number Publication date
DE112007001386A5 (de) 2009-03-19

Similar Documents

Publication Publication Date Title
DE60213760T2 (de) Verfahren zur kompression und dekompression eines strukturierten dokuments
EP1522028B9 (de) Verfahren und vorrichtungen zum kodieren/dekodieren von strukturierten dokumenten, insbesondere von xml-dokumenten
DE10301362B4 (de) Blockdatenkompressionssystem, bestehend aus einer Kompressionseinrichtung und einer Dekompressionseinrichtung, und Verfahren zur schnellen Blockdatenkompression mit Multi-Byte-Suche
DE60107964T2 (de) Vorrichtung zur kodierung und dekodierung von strukturierten dokumenten
DE69532775T2 (de) Verfahren zur Datenkomprimierung und -Dekomprimierung und zugehöriges Datenkomprimierungs- und Dekomprimierungsgerät
DE69916661T2 (de) Codebuchkonstruktion für entropiekodierung von variabler zu variabler länge
Bruggemann-Klein et al. Regular tree and regular hedge languages over unranked alphabets
EP1766982B1 (de) Verfahren zum codieren eines xml-dokuments, sowie verfahren zum decodieren, verfahren zum codieren und decodieren, codiervorrichtung, decodiervorrichtung und vorrichtung zum codieren und decodieren
WO2007075690A2 (en) A compressed schema representation object and method for metadata processing
US7500184B2 (en) Determining an acceptance status during document parsing
DE60225785T2 (de) Verfahren zur codierung und decodierung eines pfades in der baumstruktur eines strukturierten dokuments
EP1561281B1 (de) Verfahren zur erzeugung eines bitstroms aus einem indizierungsbaum
Levene et al. XML Structure Compression.
WO2016110356A1 (de) Verfahren zur integration einer semantischen datenverarbeitung
US20060184874A1 (en) System and method for displaying an acceptance status
WO2008003310A1 (de) Verfahren zur kompression einer datensequenz eines elektronischen dokuments
US20060212799A1 (en) Method and system for compiling schema
Böttcher et al. XML index compression by DTD subtraction.
DE19653133C2 (de) System und Verfahren zur pre-entropischen Codierung
Müldner et al. Annotated trees and their applications to XML compression
EP2264626A1 (de) Verfahren und Vorrichtung zum speichereffizienten Suchen mindestens eines Anfragedatenelementes
Böttcher et al. Compressing XML data streams with DAG+ BSBC
Böttcher et al. Using XML Schema Subtraction to Compress Electronic Payment Messages
Leighton Two new approaches for compressing XML
Tollefson Importing and Creating Data

Legal Events

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

Ref document number: 07785603

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 1120070013869

Country of ref document: DE

NENP Non-entry into the national phase

Ref country code: RU

REF Corresponds to

Ref document number: 112007001386

Country of ref document: DE

Date of ref document: 20090319

Kind code of ref document: P

122 Ep: pct application non-entry in european phase

Ref document number: 07785603

Country of ref document: EP

Kind code of ref document: A1