JSON Schema Interfaces
July 1st, 2009
I recently discussed an extension to JSON Schema called JSON Schema Interfaces (JSI) for defining method signatures as well as property types in a language independent manner. The post provides a library for using JSI as an obtrusive typing mechanism for JavaScript. The JSI typing module is available in a standalone JavaScript library, integrated with Dojo’s class system, or as part of Persevere’s runtime JavaScript environment. From a programming language perspective, I am really exciting about the possibility of using a runtime object model for defining type constructs, perhaps somewhat reminiscent of CLOS-style class construction, but available for JavaScript.
Jackson supports JSON Schema
July 1st, 2009
The Jackson JSON Processor version 1.1.0 has been released which includes generating JSON schemas from Java classes.
JSON Schema in Chromium
April 6th, 2009
Looks like JSON Schema has made its way into chromium . I wonder if it might be time for JSON Schema to go through a standardization body.
JSON Schema Implementations
February 23rd, 2009
Several new JSON Schema implementations have been released, including:
- PHP - Bruno Reis created a PHP based JSON Schema validator .
- Python - Ian Lewis has a Python JSON Schema validator .
- .NET - Json.NET has support for JSON Schema and has a nice demo and source code .
- jQuery - Rob Manson has jQuery plugin for validating JSON based on JSON Schema.
- InputEx - Eric Abouaf added support for form generated based on JSON Schema for InputEx, with a beautiful demonstration .
Interview and JSON Schema Link
November 26th, 2008
Justin Meyer, author of the JavaScript MVC library (a great client-side framework for client-centric applications) recently interviewed me to talk about approaches to web development. I was very honored to see that he blogged about the interview.
Also, Ganesh Prasad recently talked about the importance of JSON Schema in the evolution of service oriented front-end architecture.
New JSONQuery Implementation
November 17th, 2008
Jason Smith recently created a standalone JavaScript implementation of JSONQuery, based on the version I created for Dojo.
Imperative, Functional, and Declarative Programming
November 8th, 2008
Much of the efforts in modern programming language evolution are focused on moving beyond the low level programming paradigm of imperative programming and into the realm of functional and declarative programming. Imperative programming is simplest way to interact with hardware and generally forms the foundation of higher level constructs. However imperative programming is highly error-prone approach to programming and can obstruct optimizations and implementation opportunities that better abstractions provide.
Functional programming focuses on computations and aims to minimize mutating states. Functional programming avoids side-effects and changing data as the basis for operations. Many computations that might rely on changing variables and state information in imperative programming, can be described in terms of mathematical computations in functional programming. Functional programming may rely on imperative steps in the implementations, but these imperative actions are ideally abstracted. For example, lets take a simple loop that finds all the objects in an array with a price property under 10. In imperative programming, this would be:
function bestPrices(inputArray){
var outputArray = [];
for(var i = 0; i < inputArray.length; i++){
if(inputArray[i].price<10){
outputArray.push(inputArray[i]);
}
}
return outputArray;
}
Can you spot the state mutations that we had to induce in this imperative approach? For each loop we had to modify i (increment it) and for each match we had to modify outputArray (push appends a value to it).
Now if we use a more functional approach:
function bestPrices(inputArray){
return Array.filter(inputArray, function(value){
return value.price < 10;
}
}
This code is completely free of side-effects. We simply described the operation in the form of expressions. The underlying implementation hides all the imperative actions necessary to make this work.
Declarative programming is defined as programming in terms of "what" instead of "how". Functional programming can be categorized as a form of declarative programming since we describe "what" computation should take place with expressions, instead of describing how the computation should be performed in a series of steps as in imperative programming. However, the declarative programming concept goes beyond just functional programming.
One of the central aspects of most applications is persisting data. A core service that most applications provide to users is to be able to store information relating to the use of the application. A social networking application is useless if it can’t actually remember anything about you and your friends. The functional paradigm is limited here, it’s methodology stands in complete opposition to the central goal of the application. Quite simply, applications must deal with mutating states and data. Here we can still apply declarative programming concepts, describing what the data is, instead of how it was created or how we modify it. Perhaps the most critical and invaluable benefit of declarative programming is that the representation of "what" the object implicitly dictates"how" the object is modified . With a declarative approach there is no need for describing how we interact with and modify data, because the structure of the data reveals the how without any further instruction.
JSON provides a great example of declarative programming. JavaScript supports numerous imperative techniques, but JSON is a declarative subset, which precisely defines what an object’s state should be without directions on how to get it there. For example, we could use imperative techniques:
var movie = new Object();
movie.title="Transsiberan";
movie["rat" + "ing"] = 1+2;
movie.setHowLong = function(len){
this.length = len.trim();
}
movie.setHowLong("2 hours ");
This representation describes how to build the state of the object, and can be of unbounded complexity, but it is not actually a representation of the final state. Alternately with JSON:
{"title":Transsineran",
"rating":3,
"length:"2 hours"}
The application of the concept of representation implicitly defining the method of modification can be seen here in the simple JavaScript object. The object’s state is observable as a set of properties and we can immediately infer from the presence of these properties how we modify the objects. We can simply set one of the existing properties to modify the state, and the effect of setting a property is obvious. Conversely, when an imperative approach where opaque object methods are used to modify an object’s state, the effects are not inferrable, one has to refer to out-of-band documentation to understand the interaction necessary to cause a state change.
The other central concept of a declarative approach to data is reversibility . If we modify the state of this movie object, there is a clear unambiguous easily computable representation for the new state of the object with a declarative definition. However, this is not true with the imperative definition. With the unbounded complexity possibilities of the imperative representation, it is impossible to always know exactly when step in the directions needs to modified to correspond the state change.
Another example of declarative programming is HTML. HTML represents the state of the layout of the page. The steps for how to get into a particular layout are not described, the layout is a state that is represented by the HTML. HTML provides clear reversibility as well. Layout changes can be clearly and directly mapped to changes in the HTML representation.
Applications themselves are a form of state as well, both at the low level (code is occupies memory in the form of binary data) and at the high level in languages that reify code. JavaScript is an example of an language where code is data. Here as well, we can benefit from code being organized in declarative approach rather than an imperative approach. An application runtime state that is the result of confusing imperative steps is much more difficult to debug than application that has a clear declarative organization.
Furthermore, declarative programming can often allow programmers to work within a "live" interactive environment, where code can be changed on the fly without requiring a restart. Imperative programming often means that the only way to predictably see the effect of a change in imperative code is to restart. We certainly want to be able to move towards faster development techniques that aren’t stuck in windows-style "restart" cycles.
Once again, declarative programming can be built on imperative programming. If strict discipline of rules is applied to imperative steps, the consistency can yield an declarative form in the context of rules. For example, if we said that all class declarations must take the form assigning a constructor function to a variable and then assigning an JSON object to the constructor’s prototype, then within the context of these rules, we can have a reversible representation that still be used even if we change the state of the class (changing method implementations for example).
It is important that these principles be used to direct our continuing evolution of JavaScript. Techniques like pseudo-classes based on the side-effects within constructor function execution are a regression in the evolution away from imperative to declarative. Prototype-based inheritance does a great job of maintaining declarative programming, as the application itself can be continually updated in interactive code. Debugging can be "live", classes can be evolved without requiring environmental restarts.
JSON vs Flash AMF
November 5th, 2008
Jared Jurkiewicz posted an excellent and thorough article debunking the myth that Flash’s AMF is signficantly faster than JSON. JSON is shown to be efficient and performant, and as Jared pointed out, it is not tied to any specific type system. AMF is also a binary format, whereas JSON is a highly open and readable format.
New JSON-RPC Library for PHP
October 27th, 2008
Matthew Morley has posted his PHP library for JSON-RPC 2.0 .
Dojo 1.2 Released
October 27th, 2008
Dojo 1.2 was released a few weeks ago, and I am really excited about this release. Take a look at the release notes to see all the new features added. This release includes a comprehensive set of new JSON features including JSONQuery , JSON Referencing , JSON Schema , and a RESTful JSON client . I am think it is great to see the expanding JSON toolset available in JavaScript libraries.
Next Page »