Grammar generation for simple datatypes

Abstract

A method may include receiving an extensible markup language schema definition (XSD) including a first element having a first simple datatype and a second element having a second simple datatype different from the first simple datatype. A grammar may be generated based on the XSD. The grammar may be associated with encoding and decoding an extensible markup language (XML) document based on the XSD to and from efficient XML interchange (EXI) streams. The grammar may be associated with the first simple datatype and with the second simple datatype.

Description

FIELD

The embodiments discussed herein are related to grammar generation for simple datatypes.

BACKGROUND

Extensible markup language (XML) is a markup language that defines a set of rules for encoding documents in a plain-text format that is both human-readable and machine-readable. One version of XML is defined in the XML 1.0 Specification produced by the World Wide Web Consortium (W3C) and dated Nov. 26, 2008, which is incorporated herein by reference in its entirety. The XML 1.0 Specification defines an XML document as a text that is well-formed and valid.

An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by the XML 1.0 Specification itself. These constraints are generally expressed using some combination of rules governing the order of elements, boolean predicates associated with the content, data types governing the content of elements and attributes, and more specialized rules such as uniqueness and referential integrity constraints.

The process of checking to see if an XML document conforms to an XML schema is called validation, which is separate from XML's concept of syntactic well-formedness. All XML documents may be well-formed, but an XML document may be checked for validity, where the XML document is checked for conformance with its associated schema.

Although the plain-text, human-readable aspect of XML documents may be beneficial in many situations, this human-readable aspect may also lead to XML documents that are large in size and therefore incompatible with devices with limited memory or storage capacity. Efforts to reduce the size of XML documents have often eliminated this plain-text, human-readable aspect in favor of more compact documents.

Efficient XML interchange (EXI) is a binary XML format in which XML documents are encoded in a binary data format rather than plain text. In general, using an EXI format reduces the size and verbosity of XML documents, and may reduce the time and effort expended to parse XML documents. A formal definition of EXI is described in the EXI Format 1.0 Specification produced by the W3C and dated Feb. 11, 2014, which is incorporated herein by reference in its entirety. An XML document may be encoded in an EXI format as an EXI stream. Additionally, the EXI stream may be decoded to form an XML document similar to or the same as the original XML document.

An XML document or set of XML documents may include an associated XML schema definition (XSD). The XSD may generally describe the XML schema associated with an XML document.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced.

SUMMARY

According to an aspect of an embodiment, a method may include receiving an extensible markup language schema definition (XSD) including a first element having a first simple datatype and a second element having a second simple datatype different from the first simple datatype. A grammar may be generated based on the XSD. The grammar may be associated with encoding and decoding an extensible markup language (XML) document based on the XSD to and from efficient XML interchange (EXI) streams. The grammar may be associated with the first simple datatype and with the second simple datatype.

The object and advantages of the embodiments will be realized and achieved at least by the elements, features, and combinations particularly pointed out in the claims.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 is a block diagram of an example efficient extensible markup language interchange (EXI) processing system;

FIG. 2 is a flowchart of an example process of generating full-fledged EXI grammars from an extensible markup language schema definition (XSD);

FIG. 3 illustrates a portion of an example XSD; and

FIG. 4 illustrates a portion of an example extensible markup language (XML) document based on the XSD of FIG. 3.

DESCRIPTION OF EMBODIMENTS

Prior to encoding an XML document into an EXI stream or decoding an EXI stream into an XML document, the document's associated XSD may be normalized into grammars. The grammars are rules that may be used to predict specific sequences of the XML document. An algorithm to generate the grammars for an XSD is included in the EXI Format 1.0 Specification. As used herein the algorithm included in the EXI Format 1.0 Specification is referred to herein as the standard grammar algorithm.

Embodiments of the present invention will be explained with reference to the accompanying drawings.

FIG. 1 is a block diagram of an example extensible markup language interchange (EXI) processing system 100. The EXI processing system 100 includes a normalization device 104. The normalization device 104 may be configured to receive an extensible markup language schema definition (XSD) 102 and to output a normalization 106. The normalization 106 of the XSD may be used, for example, in encoding and/or decoding an EXI document.

The normalization device 104 may include one or more embodiments of a grammar-generating algorithm as disclosed herein. In some embodiments, the normalization 106 may include a single grammar for use with multiple simple datatypes as disclosed herein.

The normalization 106 may be communicated to an encoder/decoder 108. An example encoder/decoder 108 is included in the OpenEXI project hosted at SourceForge.net. The source code and documentation of the OpenEXI project as of Jul. 28, 2014 are incorporated herein by reference in their entirety. The encoder/decoder 108 may be configured to receive an extensible markup language (XML) document 110 and to encode the XML document 110 as an EXI stream 112. Alternately or additionally, the EXI stream 112 may also be received by the encoder/decoder 108 and decoded as the XML document 110. An original XML document 110 and the XML document 110 generated by the encoder/decoder 108 may include substantially identical XML data. However, certain types of human-readable information, such as whitespace, comments, and/or processing instructions, may not be preserved by the encoder/decoder 108 depending on associated preservation settings of the encoder/decoder 108.

The normalization device 104 may include a processor 103a and memory 105a. The encoder/decoder 108 may include a processor 103b and memory 105b. The memory 105a and the memory 105b may include non-transitory computer-readable media. Instructions such as programming code executable by the processor 103a and the processor 103b may be encoded in the memory 105a and the memory 105b, respectively. When the instructions are executed by the processor 103a and/or the processor 103b, the normalization device 104 and/or the encoder/decoder 108 may perform operations related to and/or including the processes described herein.

The normalization device 104 and/or the encoder/decoder 108 may be employed in an embedded device and/or a device with limited memory capacity. Examples of embedded devices and/or devices with limited memory capacity include, but are not limited to, sensors, microcontrollers, and appliances, such as energy management controllers, automobile microcontrollers, smart meters, or the like.

FIG. 2 is a flowchart of an example process 200 of generating full-fledged EXI grammars 210 from an XSD 202. In some embodiments, the process 200 may be performed by the normalization device 104 of FIG. 1.

The process 200 may begin with the XSD 202. A set of EXI proto-grammars 206 may be generated from the XSD 202 at block 204. One or more of the embodiments described herein may occur at block 204.

In some embodiments, proto-grammar generation 204 may correspond to section 8.5.4.1 of the EXI Format 1.0 Specification without the current version of section 8.5.4.1.3.1. In some embodiments, section 8.5.4.1.3.1 may be replaced with one or more of the embodiments described herein.

Syntax described in the current version of section 8.5.4.1.3.1 of the EXI Format 1.0 Specification includes the following:

• • Type_i,0:
    • CH [schema-typed value] Type_i,1
  • Type_i,1:
    • EEwhere CH may represent a character event, EE may represent an end element event, and i may represent each value between 0 and n, where n may be the number of simple datatypes. Thus, using the syntax described in the current version, a different grammar may conventionally be used for each simple datatype.

As described herein, in some embodiments, a single grammar may be used for multiple different simple datatypes. Using a single grammar for multiple different simple datatypes may promote a compact set of grammars. For example, a single grammar may be used for all simple datatypes in an XML document. More compact sets of grammars may employ relatively fewer resources to store and/or communicate, and thus may lend themselves to deployment in low-memory devices such as sensors and microcontrollers.

By way of example, the foregoing portion of the current version of section 8.5.4.1.3.1 may be replaced with the following:

• • Type₀:
    • CH [schema-typed value] Type₁
  • Type₁:
    • EEwhere i from the current version may be omitted.

In some instances, the EXI proto-grammars 206 may be augmented at block 208, forming the full-fledged EXI grammars 210. Augmenting the EXI proto-grammar 206 may include inserting additional attributes, properties, or the like.

FIG. 3 illustrates a portion of an example XSD 300. The XSD 300 may include elements 302a-302e (collectively “elements 302”) that each has a simple datatype 304a-304e (collectively “simple datatypes 304”). The simple datatypes 304 may be defined by an EXI specification, an XML schema specification, and/or may be user-defined. The simple datatypes 304 may be associated with one or more acceptable formats and/or values for characters associated with corresponding elements 302.

FIG. 4 illustrates a portion of an example extensible markup language (XML) document 400 based on the XSD 300 of FIG. 3. The XML document 400 includes start elements 402a-402e (collectively “start elements 402”), each followed by characters 404a-404e (collectively “characters 404”), and end elements 406a-406e (collectively “end elements 406”).

In the EXI Format 1.0 Standard, each of the characters 404 is encoded according to a particular grammar associated with the corresponding simple datatypes 304. Thus, conventionally, a different grammar may be used for each different simple datatype in the XSD. For example, an XSD may include 45 built-in simple datatypes, as well as additional user-defined simple datatypes.

For each simple datatype grammar used in an EXI stream, the following first state and second state may be created.

First State:

<Grammar>
<Productions>
<CharactersTyped/>
<Grammar>1</Grammar>
</Productions>
</Grammar>

Second State:

<Grammar>
<Productions>
<EndElement/>
</Productions>
</Grammar>

Each grammar definition may use a number of bytes. By way of example, the above first state and second state may occupy 143 bytes. If a different grammar is used for each simple datatype, the total bytes occupied by the definition of all grammars may be given by the following formula:total size=(x+α)(y+n)where x represents the number of bytes to define the grammar, α represents the number of bytes used for identifying simple datatypes, y represents the number of built-in simple datatypes, and n represents the number of user-defined simple datatypes. Where x is 143 and y is 45, the grammar definitions may take up at least 6435 bytes of space.

However, in embodiments where a single grammar is used for multiple simple datatypes, the simple datatype grammar definitions may take up less space. For example, where 143 bytes are used to define a grammar, the simple datatype grammar definitions may take up 143 bytes of space if a single simple datatype grammar is used for each of the simple datatypes.

In some embodiments, a single grammar to be used for multiple different simple datatypes may be selected based on a simple datatype of the XML schema. For example, the grammar may be selected based on a first simple datatype encountered during proto-grammar generation. Alternately, a grammar may be selected independent of the XML schema. For example, a single grammar may be preselected and used for multiple simple datatypes irrespective of the simple datatypes of the XML schema.

In some embodiments, an XML document such as the XML document 400 of FIG. 4 may be encoded as an EXI stream. The XML document may be based on an XSD such as the XSD 300 of FIG. 3. An associated normalization may include a single grammar for multiple different simple datatypes and potentially all simple datatypes. For example, with combined reference to FIG. 3 and FIG. 4, a single grammar may be employed to encode a sensor element 302a characters 404a having a string simple datatype 304a, a begin element 302b characters 404b having a dateTime simple datatype 304b, a precipitation element 302c characters 404c having a short simple datatype 304c, and so on. Thus, “Oak St Creek Rd SW,” “2003-02-17T14:17:03,” “137,” “22.22,” and “PT4H12M” of the characters 404 may be encoded according to a single grammar.

In some embodiments, encoding the XML document 400 as the EXI stream may further include adding event type identifiers to a stack. Each of the event type identifiers may be associated with an element and its associated characters. For example, an event type identifier represented by the bit sequence “001” may be associated with the sensor element 302a and may be added to a stack of event types such that the “001” event type identifier is associated with the encoded characters of the EXI stream that represent “Oak St Creek Rd SW” characters 404a. An event type identifier represented by the bit sequence “010” may be associated with the begin element 302b and may be added to the stack such that the “010” event type identifier is associated with the encoded characters that represent “2003-02-17T14:17:03” characters 404b. Additional event type identifiers, such as additional bit sequences, may be associated with the other elements 302 and the encoded characters representing their associated characters 404.

In some embodiments, the event type identifiers may be pulled from the stack, or decoded, as the EXI stream is decoded. Optionally, the event type identifiers may be decoded in an order reversed from the order the event type identifiers were added to the stack. The event type identifiers may be used to identify and/or call codecs for use in interpreting the encoded characters associated with the event type identifiers. For example, a decoder may pull the bit sequence “010” from the stack and call a codec for interpreting the encoded dateTime characters “2003-02-17T14:17:03,” which were encoded according to the grammar used for all simple datatypes. The decoder may then pull the bit sequence “001” from the stack and may call a codec for interpreting encoded string characters “Oak St Creek Rd SW,” which were encoded according to the grammar used for all simple datatypes.

The embodiments described herein may include the use of a special-purpose or general-purpose computer including various computer hardware or software modules, as discussed in greater detail below.

Embodiments described herein may be implemented using computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general-purpose or special-purpose computer. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and which may be accessed by a general-purpose or special-purpose computer. Combinations of the above may also be included within the scope of computer-readable media.

Computer-executable instructions may include, for example, instructions and data which cause a general-purpose computer, special-purpose computer, or special-purpose processing device (e.g., one or more processors) to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

As used herein, the terms “module” or “component” may refer to specific hardware implementations configured to perform the operations of the module or component and/or software objects or software routines that may be stored on and/or executed by general-purpose hardware (e.g., computer-readable media, processing devices, etc.) of the computing system. In some embodiments, the different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). While some of the system and methods described herein are generally described as being implemented in software (stored on and/or executed by general-purpose hardware), specific hardware implementations or a combination of software and specific hardware implementations are also possible and contemplated. In this description, a “computing entity” may be any computing system as previously defined herein, or any module or combination of modulates running on a computing system.

All examples and conditional language recited herein are intended for pedagogical objects to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Although embodiments of the present inventions have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.

Claims

1. A method comprising: receiving an extensible markup language schema definition (XSD) including a first element having a first simple datatype and a second element having a second simple datatype different from the first simple datatype;generating a grammar based on the XSD, the grammar associated with encoding and decoding an extensible markup language (XML) document based on the XSD to and from efficient XML interchange (EXI) streams, the grammar being associated with the first simple datatype and with the second simple datatype based on the first simple datatype and the second simple datatype both being simple datatypes, the grammar being associated with the first simple datatype and with the second simple datatype using fewer resources than having separate grammars for each of the first simple datatype and the second simple datatype;generating a normalization associated with the XSD, the normalization including the grammar;receiving the XML document based on the XSD, the XML document including: first characters associated with the first element and the first simple datatype; andsecond characters associated with the second element and the second simple datatype; andencoding the XML document as an EXI stream, including: encoding the first characters according to the grammar of the normalization in which the grammar of the normalization is associated with all simple datatypes of the XSD;adding a first event type identifier to a stack of the EXI stream such that the first event type identifier is associated with the encoded first characters; andencoding the second characters according to the grammar.

2. The method of claim 1, wherein the grammar is further generated based on the first simple datatype.

3. The method of claim 1, wherein the grammar is independent of the first simple datatype and the second simple datatype.

4. The method of claim 1, wherein: the XSD further includes a third element having a third simple datatype different from the first simple datatype and different from the third simple datatype; andthe grammar is further associated with the third simple datatype.

5. The method of claim 1, wherein the grammar is the only grammar associated with any simple datatype of the XSD.

6. The method of claim 1, wherein the first event type identifier is associated with the first element and with the first simple datatype.

7. The method of claim 6, further comprising adding a second event type identifier to the stack such that the second event type identifier is associated with the encoded second characters, wherein the second event type identifier is associated with the second element and with the second simple datatype.

8. The method of claim 1, wherein: the XSD further includes a third element having a third simple datatype different from the first simple datatype and different from the second simple datatype;the XML document further includes third characters associated with the third element and the third simple datatype; andencoding the XML document as the EXI stream further includes encoding the third characters according to the grammar.

9. The method of claim 8, further comprising: adding a first event type identifier to a stack of the EXI stream such that the first event type identifier is associated with the encoded first characters, wherein the first event type identifier is associated with the first element and with the first simple datatype;adding a second event type identifier to the stack such that the second event type identifier is associated with the encoded second characters, wherein the second event type identifier is associated with the second element and with the second simple datatype; andadding a third event type identifier to the stack such that the third event type identifier is associated with the encoded third characters, wherein the third event type identifier is associated with the third element and with the third simple datatype.