This page shows an implementation of a reduced structure key-value data representation that maps variables to values. Due to the fact that the structure is kept at a minimum, it has been used for very many projects (see Usage Scenarios) that need interoperability between POST data, persistent data storage on a Second Life or OpenSim grid, and even minimal configuration files stored in notecards.

The language maps keys to values and separates them with a ampersand & sign. The syntax is as follows:

key_1=value_1&key_2=value_2...

Contrasted with StAX XML or JSON, the structure is minimalistic such that data structures can be conveniently passed over communication channels or stored in the object's description without too much overhead. Perhaps the most notable project using key-value data is the PrimFS™ and PrimDrive™ in-world creation of a functional hard-drive.

The StAX XML parser is created by Wizardry and Steamworks and the only built-in data representation in LSL is JSON. However, LSL's implementation of JSON supports only the top-level of a JSON string, such that if we compare a simple key-value pair in key-value data representation:

a=b

and its equivalent in JSON:

{ "a" : "b" }

we can observe that JSON has a much more superfluous structure than key-value data - in fact, even if JSON supports nested objects, the functions from the LSL API are only able to read the top-level elements.

The difference of structure overhead would under most circumstances not be a problem, however LSL is fairly restricted by limits and in-world objects are only able to store up to 255 bytes of data in their description. Thus in LSL's and Second Life's context, key-value data is much more useful (as well as being more readable) than JSON.

By choosing the ampersand (&) separator sign and the equal (=) sign we can avoid clashes with variable names and be compatible with other query-based applications. The syntax is interchangeable with query strings in URLs and can be easily be used to exchange data with scripts on web-servers. As an illustration, suppose some data is stored in an object's description:

sourceid=navclient&gfns=1&q=mcdonalds

we can change that object description with:

llSetObjectDesc(wasKeyValue("q", "cocacola", llGetObjectDesc()));

and then we can perform a Google query:

llHTTPRequest("http://www.google.com/search?" + llGetObjectDesc(), [], "");

that will redirect to the Coca-Cola website.

This example is perhaps best coupled with a menu selector such as the pretty menu system, for example, allowing avatars to choose from buttons labeled after large brands.

Any projects that need a highly compatible way of data representation can use key-value data. Most of Wizardry and Steamworks' creations in Second Life use key-value data, some of the notable projects being:

• Used as the main data representation format for PrimFS™ and PrimDrive™ - and a personal teleport based on it called jump.
• As part of a Global Health project, focusing on traveler's safety, we had to create a simple to grasp and a flexible system in order to temporarily store exposures, remove them once medicine is consumed and eventually pass the process through a website. The pharmaceutics project is part of that system and uses these functions rigorously.
• Used also in the creation of a poseball system in order to account for poseballs and pass data conveniently, thereby eliminating the need to scan for them.
• Used to make books by storing the page number.
• Used as part of the Corrade bot to pass data to and from the scripted agent.

Most major languages most likely dispose of a library to process key-value data. For instance, for Node.JS one can use the qs NPM package by Jordan Harband.