Idea No. 12: Make SON, SON-Schema and SON-Template Standard
The web has used markup and markdown languages since forever. But what if we can use mark, just "mark", instead? Better yet, just like how HTML and XML are made standard, why not make Simple Object Notation (SON) and its variants standard for the web as well? Perhaps with the intent to replace markup and markdown in the near future.
Let's look at mark, for example. It translates markup like HTML to its JSON-like syntax. Unrecognized "tags" can be translated as objects. Thus, you can have a document that contains both HTML and POJO declarations following the same syntax.
It all begins with JSON. By extracting its best traits, let's remove "JavaScript" in its name and just call the syntax SON for Simple Object Notation. Then, just like what we did for XML, let's also standardize SON-Schema (like XSD) and SON-Template (like XSLT).
From these specifications, we can then create flavors like HTML-SON, EDI-SON, ACORD-SON, HR-SON, etc., which can be used by parsing/processing engines to apply flavor specific rules.
Why do we even need this? The simplification can reduce data storage compared to markup encoded data. For example, picking up from mark,
As can be evidenced by JSON's popularity, SON is automatically developer-friendly. We already have SDKs, APIs, libraries and packages that support JSON. Compatibility with SON can be natural and may in fact be already in place. Data and semantics can use the same language. Browsers that natively render SON instead of converting to HTML, for example, can gain performance benefits. Any app, website or page using SON can easily be web service-ready. As if in an instant, the web is everyone's NoSQL-friendly data source.
SON can become the developer's standard language for expressing and representing data and semantics. SON can become the standard language for data storage and data exchange. In effect, SON can become the standard language of the web.
Let's look at mark, for example. It translates markup like HTML to its JSON-like syntax. Unrecognized "tags" can be translated as objects. Thus, you can have a document that contains both HTML and POJO declarations following the same syntax.
It all begins with JSON. By extracting its best traits, let's remove "JavaScript" in its name and just call the syntax SON for Simple Object Notation. Then, just like what we did for XML, let's also standardize SON-Schema (like XSD) and SON-Template (like XSLT).
From these specifications, we can then create flavors like HTML-SON, EDI-SON, ACORD-SON, HR-SON, etc., which can be used by parsing/processing engines to apply flavor specific rules.
Why do we even need this? The simplification can reduce data storage compared to markup encoded data. For example, picking up from mark,
<p>Test</p> to {p 'Test'} saves 1 character; <div>Test</div> to {div 'Test'} saves 3 characters. For a single tag, it may seem small, but when accumulated in a page, that can save a lot!As can be evidenced by JSON's popularity, SON is automatically developer-friendly. We already have SDKs, APIs, libraries and packages that support JSON. Compatibility with SON can be natural and may in fact be already in place. Data and semantics can use the same language. Browsers that natively render SON instead of converting to HTML, for example, can gain performance benefits. Any app, website or page using SON can easily be web service-ready. As if in an instant, the web is everyone's NoSQL-friendly data source.
SON can become the developer's standard language for expressing and representing data and semantics. SON can become the standard language for data storage and data exchange. In effect, SON can become the standard language of the web.
Comments
Post a Comment