JSON: Born for MultiValue
At a fundamental level, moving information between disparate systems is easy. With a pathway (i.e. a network cable or wireless connection) and a method (i.e. a TCP/IP network connection or even a drop file interface), the only other thing needed is some form of a protocol for structuring the information in transit.
There are a variety of different options for structuring information in transit. On the simple end of things one could create a delimited stream of characters like a MultiValue record with attribute, value, and subvalue delimiters. The advantage to this approach is that it's easy. We, the MultiValue People, know delimited information inside and out. However, this may be a disadvantage for the receiver of the information as they may not share our fondness for delimited fields.
On the more complex side of the equation, we could certainly use something like XML for transmitting structured information. While XML is excellent for representing complex data structures and is well received throughout the wide world of technology, one can't help but feel that XML is the new COBOL. While it's perfectly capable of doing a job, it's verbose to a fault… sort of like the step-uncle who can't stop telling the family of his medical maladies during Thanksgiving dinner.
In the middle of these two options we find something of a sweet spot with Javascript Object Notation, better known as JSON (pronounced JAY-sahn). Using a notation derived from the object syntax of the Javascript programming language, JSON is a lightweight data format that is easy for humans to write and for machines to parse and generate. Like XML, JSON can handle nested data structures with ease and is well received throughout the technology community at large. Yet unlike XML, JSON uses simple characters in representing complex data structures instead of nesting a bunch of start and end tags. This brevity alone allows a JSON message or data structure to be represented with a smaller total character count than XML, thus reducing the bandwidth needed to transmit the message and improving the overall efficiency of the transmission.
To encode something using the JSON format, one must first understand that JSON builds structures with only three types of information:
- Scalars (single values)
- Arrays (lists of values)
- Objects (name: value pairs)
If these first two remind you of an attribute and a MultiValued list, then we're definitely on the same page. However, JSON can represent more than simple attributes and values to allow arrays and objects to include other arrays and objects to an almost unlimited depth.
Let's take a closer look at each of these, shall we?
A scalar is a simple element, like a number, date, time, or a string. Numeric values do not need to be quoted (using double quotes), but everything else should be quoted, as in:
21.25 "06/01/2012" "15:23:55" "Hello World!"
Multiple scalars can be combined into an array by listing multiple items with a comma between each and surrounding the entire list with brackets, like this:
[21.25,"06/01/2012","15:23:55","Hello World!"]
Note how an array may contain disparate types of information, not unlike a MultiValue record. In fact, each item in the array may itself be a scalar, array, or object. By nesting arrays and objects inside of each other, structures of any depth or complexity can be represented very easily with JSON. For example, here's a JSON representation of a simple record with two attributes where the second attribute is a MultiValued list:
["My Company",["Bob","Sally","Waldo","Karen"]]
So where's Waldo? I'm betting you easily found him in the third MultiValue of the second attribute.
JSON may also describe an object, where a comma-delimited series of "name":"value" pairs are wrapped in braces, like this:
{"company":"Precision Solutions, Inc.","address":"630 15th Ave, #100"}
If that all looks a little weird, just think of the names (i.e. "company", "address") as dictionary names and the values as the corresponding attribute values. Of course, each value can be a scalar, an array, or an object where the arrays and objects can contain more nested scalars, arrays, and objects.
While the field names do not need to be quoted, it's usually a good idea to quote them anyway to avoid conflicts for the consumer of the information. For example, certain keywords in Javascript are perfectly suitable field names when quoted (i.e. "new"), but may cause problems for a data consumer if quotes are omitted.
"What about associated multivalues," you ask? "How might these be represented in JSON?"
To illustrate, let's say that we have a record with a multivalued product number and a corresponding multivalued field for quantity and another for price, maybe something like this:
001 TV]RADIO]LAPTOP 002 1]2]4 003 72999]399]56994
In JSON, we have a several options to represent this. First, we could create arrays for each of the multivalued attributes and then combine those into another array, like this:
[["TV","RADIO","LAPTOP"],[1,2,4],[72999,399,56994]]
While this is a very compact way of representing the information, it may not be the best approach, as it's more difficult to see associations between fields. Perhaps a better approach might be to create objects for each association and then wrap those objects in an array, like this:
[{"product":"TV","quantity":1,"price":72999},{"product":"RADIO","quantity":2,"price":399},{"product":"LAPTOP", "quantity":4,"price":56994}]
While using objects creates a bigger JSON string, it clarifies that the information is an array (using []) of objects (using {}), where each object has three fields (product, quantity, and price) with corresponding values for each. As associations get larger and more complex — perhaps even using subvalues — JSON objects like this can be a very useful way to represent a complex data structure.
Okay, so now that you know how to build JSON, you're probably wondering… what's the big deal, especially considering that few — if any — MultiValue platforms natively support it?
The big deal is that while the MultiValue community at large may be slow at adopting JSON, the rest of the world is not. JSON is well supported in dozens of contemporary languages, thus opening a door for us to trade our MultiValue information with an ever-widening audience. Getting information out of MultiValue in JSON format is easy; deep multidimensional JSON structures can be constructed in MultiValue using nothing more complicated than simple string concatenation. Getting information INTO our MultiValue systems using JSON is a bit more involved, but certainly a far cry from impossible. Furthermore, as vendors offer increased support for JSON, using JSON to import information into our MultiValue systems will only get easier.
I've contended for years that for MultiValue to continue to grow and thrive we have to get our technology more involved in the global technology community as well as incorporate global technology into our own. Stated another way, we need to better support people and programs connecting to our systems, and we need to be actively working to connect to theirs.
The future will not be driven by those maintaining islands of superior technology but rather by those who encourage cooperation amongst diverse information producers and consumers, regardless of the technology. It is with this in mind that JSON provides a brilliant foundation for a bright, bright, cooperative future.
Featured:
SalesForce and MultiValue Webinar Downloads
