Well in this case, JSON schema doesn&#x27;t specify any more fundamental types other than &quot;number&quot;. On the receiving end of a wire or network contract, how do we pick a storage type for &quot;number&quot;? We can&#x27;t because the constraints of the type are undefined. Ergo JSON schema isn&#x27;t a strong schema language. <i>Be explicit</i> is really important when defining contracts.<p>Type this in your address bar for an illustration:<p><pre><code>    javascript:alert(1.0000000000000000000000000000001);
</code></pre>
So where can we go here. Yep:<p><pre><code>   { number: &quot;1.0000000000000000000000000000001&quot; }
</code></pre>
which means we then break the encapsulation boundary of the metadata. Then we have a wire contract that says &quot;this is a string&quot; and a separate semantic contract that says &quot;this is a decimal&quot;.<p>XML:<p><pre><code>   &lt;number&gt;1.0000000000000000000000000000001&lt;&#x2F;number&gt;
</code></pre>
Schema:<p><pre><code>   &lt;xs:element name=&quot;number&quot; type=&quot;xs:decimal&quot;&#x2F;&gt;
</code></pre>
This is just one example. We can also serialize and deserialize complex self-relational composite types transparently at both ends of the channel.<p>This is a real world problem we encounter in the financial sector every day.