JSON data validation

A JavaScript Object Notation (JSON) data validation method may include generating a description schema for defining JSON data using one or more JSON constructs. The method may further include converting the description schema to an Extensible Markup Language (XML) schema. The method may also include converting the JSON data to XML data, and validating the JSON data based on the XML Schema and the XML data.

FIELD

The embodiments discussed herein relate to JavaScript Object Notation (JSON) data validation.

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 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, mandatory, and referential integrity constraints. The process of checking an XML document to determine if the XML document conforms to an XML schema 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 XML document is checked for conformance with its associated schema.

Although the plain-text human-readable aspect of XML documents may be beneficial for different applications and purposes, 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 therefore often eliminated this plain-text human-readable aspect in favor of more compact binary representations.

JSON is a lightweight data interchange format for structuring data for transmission (e.g., between a server and a web application). JSON may be growing in popularity in part because it is considered to be easy to read and write for humans. JSON is a text format independent of any language but uses conventions that may be considered to be familiar with the languages descended from C, such as C, C++, C#, Java, JavaScript, Perl, Python, and others. JSON may be considered a data exchange language in part because of the overlap of conventions with languages descended from C.

SUMMARY

According to an aspect of an embodiment, a JSON data validation method may include generating a description schema for defining JSON data using one or more JSON constructs. The method may further include converting the description schema to an XML schema. The method may also include converting the JSON data to XML data, and validating the JSON data based on the XML Schema and the XML data.

DESCRIPTION OF EMBODIMENTS

The embodiments discussed herein are related to validating JSON data. More specifically, various embodiments relate to a schema for validating JSON data (e.g., the structure of JSON data) in an efficient manner. In some embodiments, JSON data (e.g., a JSON file) may be converted to XML data (e.g., an XML file). Further, in various embodiments, a description schema (also referred to herein as a “JSchema”) representing the JSON data may be generated. Further, the JSchema, which may be used to define JSON data using JSON constructs, may be used to generate XML schema. Stated another way, the JSchema may define JSON data structures and/or datatypes, and may be used to generate an XML schema. The XML schema may be used to validate the JSON data. Various embodiments disclosed herein may reduce a memory footprint of a system (e.g., a memory-constraint systems, such as microcontrollers) configured for XML and/or JSON validation.

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

FIG. 1shows an example flow100that may be used to validate JSON data, arranged in accordance with at least one embodiment described herein. In some embodiments, flow100may be configured to illustrate a process to validate JSON data. In these and other embodiments, a portion of the flow100may be an example of an operation of a validation system900, as described below with reference toFIG. 9.

Flow100may begin at block102. At block102, a description schema102may be generated. As noted above, “description schema” may also be referred to herein as “JSchema.” For example, JSchema102may describe/represent JSON104. For example, JSON104may include JSON data, such as one or more JSON files, and JSchema102may define one or more data structures and/or one or more datatypes for JSON104.

At block106, JSchema102may be converted to an XML schema112. According to some embodiments, JSchema102may be loaded into a JSOM, which may be converted to XML schema112. In some embodiments, JSchema102may be converted to XML schema112according to one or more of methods500,600,700, and800, as described with reference toFIGS. 5A-8E.

At block108, JSON104may be converted to XML110. JSON to XML conversion is known in the art, and any suitable process and/or device for converting JSON to XML may be used at block108.

At block114, JSON104may be validated based on XML110and XML schema112to generate a validation result116. For example, one or more XML schema processors may receive XML110and XML Schema112to determine whether JSON104is valid or invalid.

Modifications, additions, or omissions may be made to the flow100without departing from the scope of the present disclosure. For example, the operations of flow100may be implemented in differing order. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the disclosed embodiments. In short, flow100is merely one example of data flow for validating JSON data and the present disclosure is not limited to such.

FIG. 2Aillustrates an example JSON data (e.g., JSON files202A-202C) and an example JSchema204. JSchema204includes an “object,” which includes a “sequence.” The sequence of JSchema204includes three properties, “firstName”, “lastName”, and “country”, wherein each property is a string. Further, the “country” property is an optional property, and the “firstName” and “lastName” properties are required properties.

JSON file202A defines the “firstName”, “lastName”, and “country” properties and, therefore, JSON file202A is valid according to JSchema204. JSON file202B defines the “firstName” and “lastName” properties and, therefore, JSON file202B is valid according to JSchema204. JSON file202C defines the “firstName” and “country” properties, but does not define the required “lastName” property and, therefore, JSON file202C is invalid according to JSchema204.

FIG. 3Adepicts an example JSchema300. JSchema300includes an “object”, which includes a “sequence” having two properties, “state”, and “zip code.” The state property and the zip code property are strings. Further, the “zip code” property of JSchema300is an optional property, and the “state” property of JSchema300is a required property.

Each JSchema may include an object definition (e.g., “object” of JSchema300is an object definition). Further, each object definition may include either a sequence definition or a choice definition (e.g., “sequence” of JSchema300is a sequence definition). Moreover, each sequence definition or choice definition of a JSchema may include no particles, one particle, or a plurality of particles. (e.g., JSchema300includes particles302and304). Each particle may include a Boolean property (e.g., an “IsOptional” property) to depict an optional property (e.g., “zip code” of JSchema300is an optional property (e.g., as indicated by *)). Each particle may be either a named definition, a sequence definition or a choice definition. Each named definition of a JSchema may include a name (e.g., a JSON tuple name) and a definition. For example, “state” of particle302is a name, and “string” of particle302is a definition. Further, “zip code” of particle304is a name, and “string” of particle of304is a definition.

FIG. 3Bdepicts an example JSchema310. JSchema310includes an “object”, which includes a “sequence” having two properties, “state”, and “zip code.” The “state” property of JSchema310is a string and the “zip code” property of JSchema310is a number. Each of the “state” property and the “zip code” property is a required property (e.g., due to the lack of an optional property indicator (e.g., “*”)).

A definition may include either an object definition, a string definition, or a number definition. For example, as depicted in JSchema310ofFIG. 3B, the “state” property includes a string definition and the “zip code” property includes a number definition.

According to various embodiments, a JSchema may be loaded into a JSOM, the JSOM may be converted to XML schema, and a JSON may be validated via the XML schema. For example,FIGS. 4A and 4Bdepict an example JSchema402, an example JSOM404, and an example XML schema406. JSchema402includes an object, which includes a sequence. The sequence of JSchema402includes three properties, “firstName”, “lastName”, and “country”, wherein each property is a string. The “country” property is an optional property, and the “firstName” and “lastName” properties are required properties.

JSchema402may be loaded into a JSOM to generate JSOM404. JSOM404includes an object definition420and a sequence definition422. JSOM404further includes a NamedDefinition424, which defines the “firstName” property, a NamedDefinition428, which defines the “lastName” property, and a NamedDefinition432, which defines the “country” property. JSOM404also includes StringDefinition426, StringDefinition430, and StringDefinition434.

Further, as described in more detail below with reference toFIGS. 5A-8E, a JSOM may be converted to XML Schema, which may also be referred to as “XSD.” In the example illustrated inFIGS. 4A and 4B, JSOM404is converted to XML Schema406.

FIG. 5Ashows an example flow diagram of a method500of converting JSchema data to an XML Schema, arranged in accordance with at least one embodiment described herein. In some examples, method500may be performed for each definition in the JSON data. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

In some embodiments, method500may be performed by a system such as validation system900ofFIG. 9. For instance, processing device920ofFIG. 9may be configured to execute computer instructions stored on memory930to perform functions and operations as represented by one or more of the blocks of method500.

Method500may begin at block502. At block502, an XML schema preamble for the JSchema data may be generated, and method500may proceed to block504. In some embodiments, the XML schema preamble may be generated based on an input (e.g., one or more definitions). For example, as illustrated inFIG. 5B, an XML schema preamble510may be generated.

At block504, a definition may be processed, and method may proceed to block506. In some embodiments, a definition may be processed according to a method600described below with reference toFIG. 6A. For example, a “process definition” function may be called and the function may receive an input including one or more definitions.

At block506, an XML schema postamble for the JSON data may be generated. For example, as illustrated inFIG. 5C, an XML schema postamble520may be generated.

Modifications, additions, or omissions may be made to method500without departing from the scope of the present disclosure. For example, the operations of method500may be implemented in differing order. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the disclosed embodiment

FIG. 6Ashows an example flow diagram of a method600of processing a JSON data definition, arranged in accordance with at least one embodiment described herein. In some examples, method600may be performed for each definition in the JSON data. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

In some embodiments, method600may be performed by a system such as validation system900ofFIG. 9. For instance, processing device920ofFIG. 9may be configured to execute computer instructions stored on memory930to perform functions and operations as represented by one or more of the blocks of method600.

Method600may begin at block602. At block602, a definition type may be identified. For example, upon receipt of a definition as an input, a definition type may be identified as an object, a string, or a number. If the definition type is as an object definition, method600may proceed to block604. If the definition type is a string definition, method600may proceed to block612. If the definition type is a number definition, method600may proceed to block614.

At block604, an object definition preamble may be generated, and method600may proceed to block606. In some embodiments, the object definition preamble may be generated based on the object definition. For example, an XML object definition preamble650is illustrated inFIG. 6B.

At block606, a content model of the object definition may be received. For example, a content model of an object may be a sequence definition or a choice definition.

At block608, a particle of the object may be processed, and method600may proceed to block610. In some embodiments, the particle may be processed based on the content model. More specifically, a function for processing a particle may be called, and the function may receive the content model of the object (e.g., a sequence definition or a choice definition) as an input. In some embodiments, a particle may be processed according to method700described below with reference toFIG. 7A.

At block610, an object definition postamble may be generated. For example, an object definition postamble652is illustrated inFIG. 6C.

At block612, the string definition may be defined. For example, XML code defining the string definition may be generated. As a more specific example, XML schema654defining a string definition is illustrated inFIG. 6D.

At block614, the number definition may be defined. For example, XML code defining the number definition may be generated. As a more specific example, XML schema656defining a number definition is illustrated inFIG. 6E.

Modifications, additions, or omissions may be made to method600without departing from the scope of the present disclosure. For example, the operations of method600may be implemented in differing order. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the disclosed embodiment

FIG. 7Ashows an example flow diagram of a method700of processing a JSON data particle, arranged in accordance with at least one embodiment described herein. In some examples, method700may be performed for each particle of JSON data. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

In some embodiments, method700may be performed by a system such as validation system900ofFIG. 9. For instance, processing device920ofFIG. 9may be configured to execute computer instructions stored on memory930to perform functions and operations as represented by one or more of the blocks of method700.

Method700may begin at block702. At block702, a particle type of an object may be identified. For example, upon receipt of a particle as an input, a particle type may be identified as either a sequence definition, a choice definition, or a named definition. If the particle type is either a sequence definition or a choice definition, method700may proceed to block704. If the particle type is a named definition, method700may proceed to block708. In some embodiments, a particle may include an occurrence condition, which may identify the particle as either an optional particle or a required particle.

At block704, a variable, which defines whether or not the particle is optional may be set, and method700may proceed to block706. For example, an “isOptional” variable may be set to “true” if the particle is optional, otherwise the “isOptional” variable may be set to “false.”

At block706, a group may processed. More specifically, in some embodiments, a function for processing a group may be called, and the function may receive a variable (e.g., “isOptional” variable) and a definition (e.g., a sequence definition or a choice definition) as an input. In some embodiments, a particle may be processed according to method800described below with reference toFIG. 8A.

At block708, the named definition may be defined and method700may proceed to block710. For example, XML code defining the named definition may be generated. As a more specific example, XML schema750defining the named definition is illustrated inFIG. 7B.

At block710, XML code to define a complex type may be generated, and method700may proceed to block712. For example, XML schema752to define the complex type is illustrated inFIG. 7C.

At block712, a definition of the named definition may be processed, and method may proceed to block714. For example, a “process definition” function may be called, and the function may receive the inner definition (e.g., the definition of the named definition) as an input. In some embodiments, a definition may be processed according to method600described below with reference toFIG. 6A.

At block714, XML code including one or more end tags may be generated. For example, XML schema754including a plurality of end tags is illustrated inFIG. 7D.

Modifications, additions, or omissions may be made to method700without departing from the scope of the present disclosure. For example, the operations of method700may be implemented in differing order. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the disclosed embodiment.

FIG. 8Ashows an example flow diagram of a method800of processing a JSON data group, arranged in accordance with at least one embodiment described herein. A “group” may include particles and may include a sequence or a choice. In some examples, method800may be performed for each group in the JSON data. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

In some embodiments, method800may be performed by a system such as validation system900ofFIG. 9. For instance, processing device920ofFIG. 9may be configured to execute computer instructions stored on memory930to perform functions and operations as represented by one or more of the blocks of method800.

Method800may begin at block802. At block802, a group type may be identified. For example, upon receipt of a group as an input, a group type may be identified as either a sequence definition or a choice definition. If the group type is a sequence definition, method800may proceed to block804. If the group type is a choice definition, method800may proceed to block814. In some embodiments, a Boolean variable (e.g., an “isOptional” variable) may also be received as an input, wherein the Boolean variable may define whether or not a particle is optional.

At block804, a particle of the group for the sequence definition may be defined as optional or required, and method800may proceed to block806. For example, XML code for defining whether or not a particle is optional may be generated. As a more specific example, XML schema850defining whether or not a particle is optional is illustrated inFIG. 8B.

At block806, a variable for identifying particles in a particle list may be set, a variable identifying the number of particles in the list may be set, and method800may proceed to block810. For example, a “ParticleList” variable may identify a list of particles in a sequence definition and a variable “N” may identify a number of particles in “ParticleList.”

At block810, a value of variable N may be determined. If the variable N is greater than 0, method800may proceed to block808. If variable N is equal to 0, method800may proceed to block812.

At block808, an Nth particle of the particle list (“ParticleList”) may be processed, the variable N may be reduced by 1, and method800may return to block810. For example, the Nth particle may be process according to method700described below with reference toFIG. 7.

At block812, XML code including one or more end tags may be generated. For example, XML schema852including an end tag is illustrated inFIG. 8C.

At block814, a particle of the group for the choice definition may be defined as optional or required, and method800may proceed to block816. For example, XML code for defining whether or not a particle is optional may be generated. As a more specific example, XML schema854defining whether or not a particle is optional is illustrated inFIG. 8D.

At block816, a variable for identifying particles in a particle list may be set, a variable identifying the number of particles in the list may be set, and method800may proceed to block820. For example, a “ParticleList” variable may identify a list of particles in a choice definition and a variable “M” may identify a number of particles in “ParticleList.”

At block820, a value of variable M may be determined. If the variable M is greater than zero, method800may proceed to block818. If variable M is equal to zero, method800may proceed to block822.

At block818, an Mth particle of the particle list (“ParticleList”) may be processed, the variable M may be reduced by 1, and method800may return to block820. For example, the Mth particle may be process according to method700described below with reference toFIG. 7.

At block822, XML code including one or more end tags may be generated. For example, XML schema856including an end tag is illustrated inFIG. 8E.

Modifications, additions, or omissions may be made to method800without departing from the scope of the present disclosure. For example, the operations of method800may be implemented in differing order. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the disclosed embodiment.

FIG. 9is a block diagram of the example validation system900, arranged in accordance with at least one embodiment described herein. In some embodiments, validation system900may include a processor-based computing device. For example, validation system900may include a tablet computer, a laptop computer, a desktop computer, mainframe, or any other processor-based computing device. In some embodiments, validation system900may include a special-purpose processor-based computing device configured to execute one or more blocks of methods500,600,700,800described above with reference toFIGS. 5A-8Ewhen executed by processing device920.

Validation system900may include a processor910, a processing device920, and a memory930. The various components of validation system900may be communicatively coupled to one another via a bus940.

Processing device920may include an arithmetic logic unit, a microprocessor, a general-purpose controller, or some other processor array to perform computations and provide electronic display signals to a display device. Processing device920processes data signals and may include various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. AlthoughFIG. 9includes a single processing device920, multiple processing devices920may be included. Other processors, operating systems, sensors, displays, and physical configurations are possible.

In one embodiment, validation system900may include code and routines configured to perform or control performance of one or more blocks of methods500,600,700,800described above with reference toFIGS. 5A-8Ewhen executed by the processing device920.

Memory930may store instructions and/or data that may be executed by processing device920. The instructions and/or data may include code for performing the techniques described herein. In some embodiments, the instructions may include instructions and data which cause processing device920to perform a certain function or group of functions.

In some embodiments, memory930may include a 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 processing device920that may be programmed to execute the computer-executable instructions stored on the computer-readable media. 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 non-transitory 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 the processing device920. Memory930may be a tangible or non-transitory computer-readable medium storing executable instructions which may be accessed and executed by processing device920. Combinations of the above may also be included within the scope of computer-readable media. Memory930may store, for example, JSchemas, XML Schemas, XML data, JSON data, validation results, JSOMs, or any other data disclosed herein (e.g. any data related to validation of JSON data).

Optionally, in some embodiments, memory930may store any other data to provide its functionality. For example, memory930may store one or more libraries of standard functions or custom functions. In some embodiments, processor910may include code and routines stored on memory930and executed by the processing device920.

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 validation system900. In some embodiments, the different components and modules described herein may be implemented as objects or processes that execute on a 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 validation system900), specific hardware implementations or a combination of software and specific hardware implementations are also possible and contemplated. In this description, a “computing entity” may include any computing system as defined herein, or any module or combination of modules running on a computing system such as system900.