Documentation‎ > ‎MIS‎ > ‎


White paper on JSON extension* beyond JSONP, Jonas Almeida, June 11, 2008
Summary - An extension* of the cross-browser JSON data exchange format is proposed by allowing not only the specification of the name of the callback function (JSONP) but also two additional Parameters with code to be run a) on the data retrieved, and b) after data retrieval closes.

* JSONPP: parameterized JSON with padding

JavaScript Object Notation (JSON) is a particularly convenient way to format content delivered by S3DB data services, the others being XML, XML/RDF, N3/RDF, tabular text and HTML tables. In this white paper the popular JSONP (JSON with padding) variant, where the URL call also specifies the name of the function encapsulating the data, is further extended to support a functional programming style. The proosition will be illustrated with an applcation to the s3db data service.

Input Arguments to get an answer (ans):
  • JSON - the only input argument is source URL: ans = JSON_call(SRC){}.
  • JSONP - source URL and name of the function processing JSON data are provided: JSON_call(SRC,JSONP) --> ans = JSONP (SRC) {}.
  • JSONPP - source URL, name of the function processing JSON data, a string for evaluation after JSON data is retrieved, and another for evaluation after the retrieval is closed are provided: JSON_call(SRC,JSONP,JSONPP,ONLOAD) --> ans = JASONP(SRC){eval(JSONPP(ans));eval(ONLOAD)}.

The rationale for JSONP is clear enough in its original proposition. The same rationale can be further extended by noting that the functional programming style that suits JS so well would benefit if not just the name of the function but also what happens next could be specified in the JSON call. The robustness of JS for web programming relies on its unusual disregard for the succession of commands in the code. Instead of trying to tame the execution of the code with setTimeout or by using IE's defer attribute.
Here's how this extension of JSON could work and how it is supported by S3DB:
function s3db_jsonpp_call (src,next_eval) {
     call = "call_"+Math.random().toString().replace(/\./g,"");//alert("787");
     var headID = document.getElementsByTagName("head")[0];
     var script = document.createElement('script'); = call;
     script.type = 'text/javascript';
     // using padded, parameterized JSON
     script.src = src ;//;
     headID.appendChild(script); // retrieve answer
function remove_element_by_id (id) {
    var e = document.getElementById(id);
    return false}

function s3db_jsonpp (ans,jsonpp) {
    return ans}

An example of a call to S3DB webservices using JSONPP would be something like:
var s3q=s3db.url + "/S3QL.php?key = " + s3db.key + "&query=<S3QL><select>*</select><from>collections</from><where><project_id>" + Pid.match(/\d+/g) + "</project_id></where></S3QL>"; // defining the SRC with a RESTfull call that passes S3QL query
s3db_jsonpp_call(s3q,"do_something_with_list_of_Projects(ans)")); // note that ans is only available after retrieving it from rhe data source.

Why not also onload?

Why not do something more familiar than additional arguments to the JSON callback function such as passing code that will be evaluated after that function is done with getting the data. This would correspond to the familiar onload event method. Indeed why not: this is supported by the S3DB services (just add a + "&onload=..." to the URL call) and you see this feature used above to remove the script from the document HEAD after it was executed. However, the critical advantage of the JSONPP parameter is that something can be done with the loaded data, ans in the example above, right after it has been acquired, without having to worry about taming the javascript flow at a later stage in the code execution. The onload evaluation on the contrary, takes place after the JSON call is closed and is most useful for cleaning the DOM and other objects of unecessary bits that will not be used anymore. 


Further parameterization of JSON calls may help to deal with javascript workflows. In the JSONPP approach described here, the code passed as the third input argument of the JSON call (JSONPP in the code above) has direct access to the data retrieved which produces the sort of insularity of individual procedures that makes the functional programming approach to javascript a convenient design for service oriented web applications.
Any comments / suggestions / or downright dismissals of the proposed design are appreciated, particularly if they come with examples of better performing solutions. Evaluating code returned by the service invoked opens new opportunities for server side tampering so clearly JASONPP is designed for trusted distributed resources providing both data and analysis services. Having trust and distribution in the description of the same infrastructure is of course not a trivial requirement.

Jonas Almeida,
Jun 12, 2008, 6:55 AM