The embodiments discussed herein are related to Efficient XML Interchange (EXI) schema documents.
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 grammatical 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. One example schema language in widespread use is the XML Schema Definition (XSD) language as defined in the XSD 1.1 Specification produced by the W3C and dated Apr. 5, 2012, which is incorporated herein by reference in its entirety.
The process of checking to see if an XML document conforms to an XSD document is called validation, which is separate from XML's core concept of syntactic well-formedness. All XML documents are defined as being well-formed, but an XML document is on check for validity where the XML processor is “validating,” in which case the document is checked for conformance with its associated XSD document. An XML document is only considered valid if it satisfies the requirements of the XSD document with which it has been associated.
Although the plain-text human-readable aspect of XML and XSD documents may be beneficial in many situations, this human-readable aspect may also lead to XML and XSD documents that are large in size and therefore incompatible with devices with limited memory or storage capacity. Efforts to reduce the size of XML and XSD documents have therefore often eliminated this plain-text human-readable aspect in favor of more compact binary representations.
EXI is a Binary XML format. EXI is one of the most prominent binary XML efforts to encode XML documents in a binary data format rather than plain text. In general, using a binary XML format reduces the size and verbosity of XML documents, and may reduce the cost in terms of time and effort involved in parsing XML documents. EXI is formally defined in the EXI Format 1.0 Specification produced by the W3C and dated Mar. 10, 2011, which is incorporated herein by reference in its entirety. An XML document may be encoded in an EXI format as a separate EXI document. An XSD document may also be encoded as a separate EXI schema document.
When an XSD document is encoded as an EXI schema document, the EXI schema document generally includes various encoded data fields that are employed in validation tasks. Unfortunately, however, the inclusion of these various encoded data fields may cause the size of the EXI schema document to remain relatively large in size. This relatively large size may be problematic where the EXI schema document is transferred to an EXI processor that is employed in a device with limited memory or storage capacity.
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.
According to an aspect of an embodiment, a method of reducing the size of a simpleType element in an EXI schema document may include modifying each simpleType element in an XSD document by eliminating one or more facets from each simpleType element. The method may also include encoding the XSD document into an EXI schema document by transforming each modified simpleType element in the XSD document from an XSD simpleType element with start and end tags to an encoded EXI simpleType element expressed as a sequence of bits.
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.
Example embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
Some embodiments described herein may include methods of reducing the size of a simpleType element in an EXI schema document. For example, some embodiments described herein may include a method of reducing the size of a simpleType element in an EXI schema document where the EXI schema document is targeted for non-validation tasks. Because validation tasks employ validation-specific data fields of a simpleType element, where an EXI schema document is targeted for a non-validation task, the size of the simpleType element in the EXI schema document may be reduced by eliminating these validation-specific data fields.
As used herein, the term “document” refers to any electronic document, stream, or file. Therefore, as used herein, the phrase “EXI schema document” is synonymous with “EXI schema stream” or “EXI schema file.”
Embodiments of the present invention will be explained with reference to the accompanying drawings.
For example, a comparison of the example EXI schema simpleType datatype 200 and the prior art EXI schema simpleType datatype 300 reveals that various facets may be eliminated from each simpleType element in an XSD document. Then, when the XSD document is encoded into an EXI schema document, the prior elimination of these facets may result in a reduction in the size of each simpleType element in the encoded EXI schema document. The encoded EXI schema document may then be utilized in any task other than XML validation. Examples of non-validation tasks include, but are not limited to, encoding an XML document into an EXI document, decoding an XML document from an EXI document, encoding an XML document into a Comma-Separated Values (CSV) document, a flat file document, or a JavaScript Object Notation (JSON) document; and decoding an XML document from a CSV document, a flat file document, or a JSON document.
As suggested by a comparison of the example EXI schema simpleType datatype 200 and the prior art EXI schema simpleType datatype 300, the eliminated facets may include length, minLength, maxLength, pattern, maxInclusive, maxExclusive, minExclusive, totalDigits, and fractionDigits for all varieties of simpleType elements. In addition, the eliminated facets may further include minInclusive for each simpleType element other than integer atomic variety simpleType elements that are a bounded integer. Moreover, the eliminated facets may further include whitespace for each simpleType element other than string atomic variety simpleType elements.
Instead of outright elimination of a particular facet, the facet may instead be reduced in size and combined with other facets in a composite auxiliary field, thereby maintaining at least a portion of the facet value while still furthering the goal of an overall reduction in the size of the corresponding simpleType element.
For example, the example layout 400 includes a 2-bit variety field for all simpleType element varieties, including list, union, and atomic varieties. Where the simpleType element is any atomic variety, the example layout 400 further includes a 1-bit enumeration presence field and a 5-bit ancestry identifier field. Where the simpleType element is a boolean atomic variety, the example layout 400 further includes a 1-bit pattern presence field. Where the simpleType element is a string atomic variety, the example layout 400 further includes a 2-bit whitespace field and an 8-bit restricted characters field. Where the simpleType element is an integer atomic variety, the example layout 400 further includes an 8-bit integer width field and a 16-bit minInclusive pointer field. It is understood that the specific number of bits in each field in the example layout 400 in other embodiments may differ from the number shown in
The method 500 may begin at block 502, in which each simpleType element in an XSD document is identified. For example, the EXI schema encoder 102 may parse through the XSD document 106 to identify each simpleType element in the XSD document 106.
In optional block 504, each simpleType element of the XSD document is modified by eliminating one or more facets from each simpleType element in the XSD document. For example, the EXI schema encoder 102 may eliminate one or more facets from each simpleType element in the XSD document 106. As noted above, in at least some example embodiments, these eliminated facets may include validation-specific facets from each simpleType element, such as those listed above.
In block 506, each modified simpleType element in the XSD document is transformed from an XSD simpleType element to an encoded EXI simpleType element. For example, the EXI schema encoder 102 may transform each modified simpleType element with start and end tags in the XSD document 106 to an encoded EXI simpleType element expressed as a sequence of bits in the encoded EXI schema document 108.
In optional block 550, one or more fields of each simpleType element in the XSD document are encoded into a single fixed-length auxiliary field in the encoded EXI simpleType element. For example, the EXI schema encoder 102 may encode one or more fields of each simpleType element in the XSD document 106 into a single fixed-length auxiliary field in the corresponding encoded EXI simpleType element in the encoded EXI schema document 108. The fixed-length auxiliary field may be the SIMPLE_TYPE_AUX field with the example layout 400 of
The method 550 may begin at block 552, in which the variety value of the simpleType element is stored. For example, the EXI schema encoder 102 may store the variety value of a simpleType element of the XSD document 106 in the 2-bit variety field of the example layout 400 in the EXI schema document 108.
In decision block 554, it is determined whether the simpleType element is a union, list, or atomic variety. If the simpleType element is a union or list variety (“Union or List” at decision block 504), then the method 550 is complete. If the simpleType element is an atomic variety (“Atomic” at decision block 504), then the method 550 proceeds to block 556. For example, the EXI schema encoder 102 may examine the variety of the simpleType element of the XSD document 106 to determine whether the simpleType element is a union, list, or atomic variety.
In block 556, an enumeration presence value and an ancestry identifier value of the simpleType element are stored. For example, the EXI schema encoder 102 may store the enumeration presence value of the simpleType element in the 1-bit enumeration presence field and the ancestry identifier value simpleType element in the 5-bit ancestry identifier field of the example layout 400 in the EXI schema document 108.
In decision block 558, it is determined whether the simpleType element is a boolean atomic variety. For example, the EXI schema encoder 102 may examine the variety of the simpleType element of the XSD document 106 to determine whether the simpleType element is a boolean atomic variety. If so (“Yes” at decision block 558), then the method 550 proceeds to block 560 where a pattern presence value is stored. For example, the EXI schema encoder 102 may store the pattern presence value of the simpleType element in the 1-bit pattern presence field of the example layout 400 in the EXI schema document 108. If not (“No” at decision block 558), then the method 550 proceeds to decision block 562.
In decision block 562, it is determined whether the simpleType element is a string atomic variety. For example, the EXI schema encoder 102 may examine the variety of the simpleType element of the XSD document 106 to determine whether the simpleType element is a string atomic variety. If so (“Yes” at decision block 562), then the method 550 proceeds to block 564 where a whitespace value and a restricted characters value are stored. For example, the EXI schema encoder 102 may store the whitespace value of the simpleType element in the 2-bit whitespace field and the restricted characters value of the simpleType element in the 8-bit restricted characters field of the example layout 400 in the EXI schema document 108. If not (“No” at decision block 562), then the method 550 proceeds to decision block 566.
In decision block 566, it is determined whether the simpleType element is an integer atomic variety. For example, the EXI schema encoder 102 may examine the variety of the simpleType element of the XSD document 106 to determine whether the simpleType element is an integer atomic variety. If so (“Yes” at decision block 566), then the method 550 proceeds to block 568 where an integer width value and a mininclusive pointer value are stored. For example, the EXI schema encoder 102 may store the integer width value of the simpleType element in the 8-bit integer width field and the mininclusive pointer value of the simpleType element in the 16-bit restricted characters field of the example layout 400 in the EXI schema document 108. 4. If not (“No” at decision block 566), then the method 550 is complete.
As illustrated in
Therefore, the embodiments disclosed herein include methods of reducing the size of a simpleType element in an EXI schema document where the EXI schema document is targeted for non-validation tasks. Because validation tasks employ validation-specific data fields of a simpleType element, where an EXI schema document is targeted for a non-validation task, the size of the simpleType element in the EXI schema document may be reduced by eliminating these validation-specific data fields. Thus, the embodiment disclosed herein allow for more efficient exchange of schema information which may be especially beneficial in devices with limited memory or storage capacity.
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 RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage 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 comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device 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 term “module” or “component” may refer to software objects or routines that execute on the computing system. 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 the system and methods described herein are preferably implemented in software, implementations in hardware or a combination of software and hardware 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.
Number | Name | Date | Kind |
---|---|---|---|
7111076 | Abjanic et al. | Sep 2006 | B2 |
7143346 | Dunne et al. | Nov 2006 | B2 |
7581177 | Mollicone et al. | Aug 2009 | B1 |
7587667 | Scardina et al. | Sep 2009 | B2 |
7603654 | Kharitidi et al. | Oct 2009 | B2 |
7886223 | Shetty et al. | Feb 2011 | B2 |
7933928 | Chandrasekar et al. | Apr 2011 | B2 |
7992081 | Medi et al. | Aug 2011 | B2 |
8156213 | Deng et al. | Apr 2012 | B1 |
8185565 | Ishizaki | May 2012 | B2 |
8191040 | Hejlsberg et al. | May 2012 | B2 |
8250062 | Zhang et al. | Aug 2012 | B2 |
8250465 | Uchida | Aug 2012 | B2 |
8606806 | Baras et al. | Dec 2013 | B2 |
8713426 | Idicula et al. | Apr 2014 | B2 |
8943481 | Gharavy et al. | Jan 2015 | B2 |
20030046317 | Cseri et al. | Mar 2003 | A1 |
20050091346 | Krishnaswami et al. | Apr 2005 | A1 |
20050132276 | Panditharadhya et al. | Jun 2005 | A1 |
20060059169 | Armishev | Mar 2006 | A1 |
20060085489 | Tomic et al. | Apr 2006 | A1 |
20060182138 | Kamiya | Aug 2006 | A1 |
20060184547 | Kamiya | Aug 2006 | A1 |
20060184562 | Kamiya | Aug 2006 | A1 |
20060184873 | Kamiya | Aug 2006 | A1 |
20060184874 | Kimiya | Aug 2006 | A1 |
20060212799 | Kamiya | Sep 2006 | A1 |
20060212800 | Kamiya | Sep 2006 | A1 |
20060218161 | Zhang et al. | Sep 2006 | A1 |
20070005786 | Kumar et al. | Jan 2007 | A1 |
20070061706 | Cupala et al. | Mar 2007 | A1 |
20070136221 | Sweeney et al. | Jun 2007 | A1 |
20070143664 | Fang et al. | Jun 2007 | A1 |
20070162479 | Begun et al. | Jul 2007 | A1 |
20080017722 | Snyder et al. | Jan 2008 | A1 |
20080104579 | Hartmann | May 2008 | A1 |
20080120351 | Khaladkar et al. | May 2008 | A1 |
20080183736 | Westerinen et al. | Jul 2008 | A1 |
20080306971 | Martinez Smith et al. | Dec 2008 | A1 |
20090132569 | Tamiya | May 2009 | A1 |
20090150412 | Idicula et al. | Jun 2009 | A1 |
20090198722 | Hanson et al. | Aug 2009 | A1 |
20090210783 | Bellessort | Aug 2009 | A1 |
20090271695 | Ruellan et al. | Oct 2009 | A1 |
20090287625 | Fablet et al. | Nov 2009 | A1 |
20100010995 | Fablet et al. | Jan 2010 | A1 |
20100058169 | Demant et al. | Mar 2010 | A1 |
20100058170 | Demant et al. | Mar 2010 | A1 |
20100083101 | Denoual et al. | Apr 2010 | A1 |
20100153837 | Bellessort et al. | Jun 2010 | A1 |
20100318370 | Bhattacharyya et al. | Dec 2010 | A1 |
20110010614 | Fablet et al. | Jan 2011 | A1 |
20110153531 | Ishizaki | Jun 2011 | A1 |
20120124017 | Heuer et al. | May 2012 | A1 |
20120134287 | Turunen et al. | May 2012 | A1 |
20120150828 | Fablet et al. | Jun 2012 | A1 |
20120159306 | Sharma et al. | Jun 2012 | A1 |
20120233573 | Sullivan et al. | Sep 2012 | A1 |
20120254725 | Doi | Oct 2012 | A1 |
20130018924 | Connor et al. | Jan 2013 | A1 |
20130069806 | Oh et al. | Mar 2013 | A1 |
20130103721 | Doi et al. | Apr 2013 | A1 |
20130104033 | Doi et al. | Apr 2013 | A1 |
20130339526 | Ruellan et al. | Dec 2013 | A1 |
20140026029 | Kamiya | Jan 2014 | A1 |
20140026030 | Kamiya | Jan 2014 | A1 |
20140070966 | Fablet et al. | Mar 2014 | A1 |
20140281912 | Doi | Sep 2014 | A1 |
20140297692 | Doi | Oct 2014 | A1 |
Entry |
---|
World Wide Web Consortium. Extensible Markup Language (XML) 1.0 (Fifth Edition), ed. Tim Bray et al. W3C Recommendation Nov. 26, 2008. http://www.w3.org/TR/xml/. |
World Wide Web Consortium. Efficient XML Interchange (EXI) Format 1.0, ed. John Schneider et al. W3C Recommendation Mar. 10, 2011. http://www.w3.org/TR/exi/. |
World Wide Web Consortium. W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures, ed. Henry S. Thompson et al. W3C Recommendation Apr. 5, 2012. http://www.w3.org/TR/xmlschema11-1/. |
World Wide Web Consortium. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, ed. David Peterson et al. W3C Recommendation Apr. 5, 2012. http://www.w3.org/TR/xmlschema11-2/. |
World Wide Web Consortium. Efficient XML Interchange (EXI) Profile, ed. Youenn Fablet et al. W3C Working Draft. Apr. 10, 2012. http://www.w3.org/TR/exi-profile/. |
Number | Date | Country | |
---|---|---|---|
20140026029 A1 | Jan 2014 | US |