# JSON Schemas with Semantic Annotations Supporting Data Translation
## 5 Translating JSON Schema to XML Schema
### Algorithm  
To support the translation of JSON Schemas, with the proposed semantic annotations and complement data values, to XML Schemas, the algorithm presented in Listing 5 is used. For developing the algorithm, JSON schema characteristics were reviewed and resumed in the following assumptions, which should not limit the implementation in most applications:  
1. There are no empty JSON objects, and they always contain JSON properties, which translates into an XSD complex type element with child elements of itself;
2. Any JSON property that does not have a \"type\" keyword or of which the property is not an object is considered a new XSD element. All keywords on this property are attributes of the XSD element. Based on these assumptions, we developed an algorithm for translating JSON Schemas to XML Schemas. The pseudo-code of the algorithm is shown in Listing 5. The algorithm receives an annotated JSON Schema and the data type compatibility mapping shown in Table 1 as input and generates an annotated XML Schema as output. First, an empty XML-Schema 1.1 document with all required prefixes (\"xs\", \"vc\", \"sawsdl\", and \"a3 st\") is created. Then, the function \(schemaMaker()\) recursively traverses the input JSON Schema and incrementally extends the output XML Schema. If the current JSON Schema node processed by \(schemaMaker()\) is of the type object, then a JSON Schema object declaration is recursively translated to an XML-Schema element containing a complex type. Otherwise, the current node is a data-carrying leaf-node and the output is generated based on the mapping table. In particular, JSON Schema objects are translated as follows:  
Based on Assumption 1, whenever a processed node is of type object, a new XML Schema element with the same name as the processed JSON node is created. Then, an anonymous XML Schema \(complexType\) element is appended as a child node of the new element. This can be seen from line 10 to line 20. In a next step, an XML Schema \(ALL\) \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **JSON Schema** & & **XML Schema** \\ \hline \(\bullet\) & String & \(\bullet\) & **String** \\ \hline \multirow{4}{*}{integer} & & \(\bullet\) & Integer \\  & & \(\bullet\) & Byte \\  & & \(\bullet\) & **Long** \\  & & \(\bullet\) & Short \\ \hline \multirow{4}{*}{number} & & \(\bullet\) & Float \\  & & \(\bullet\) & Decimal \\  & & \(\bullet\) & **Double** \\ \hline \multirow{2}{*}{boolean} & & \(\bullet\) & **Boolean** \\ \hline \multirow{2}{*}{\(\bullet\)} & & \multirow{2}{*}{Array} & \multirow{2}{*}{\(\bullet\)} & **maxOccurs = “Unbounded”** \\ \hline \multirow{2}{*}{\(\bullet\)} & & & **xs:complexType, xs:all** \\ \hline \hline \end{tabular}
\end{table} 
Table 1: JSON Schema to XML Schema data type compatibility rules. element is nested into the newly created complex type. \(ALL\) (rather than \(SEQUENCE\) or \(CHOICE\)) is used due to JSON Schemas' lack of validation of the order of elements within an object. If the currently processed JSON node is not required in a JSON Schema, a min-occurs property with the value \"0\" is added to the created XML-Schema Element. Note that JSON Schema and XML Schema follow different strategies for expressing required values. In XML Schema, the property is expressed using the min-occurs property of the element itself. In JSON Schema, the required properties are defined at the object level using an array of required properties within the current object. Therefore, the helper array \(requiredArrayNew\) is used for book-keeping purposes. Finally, all of the properties of the currently processed node are traversed recursively. In all detail, data-carrying leaf-nodes are translated as follows:  
Based on assumption 2, whenever a property does not have its type defined as an object, or even a \"type\" keyword, it is assumed to be a new XSD element and proceeds to create it (lines 22 to 49).