Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

BaSyx / Documentation / VAB / JSON Serialization

< BaSyx ‎ | Documentation ‎ | VAB
Revision as of 05:24, 27 August 2019 by Frank.schnicke.iese.fraunhofer.de (Talk | contribs) (Explanation of JSON serialization)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
See also HTTP/REST Mapping TCP Mapping

JSON Serialization

Both the TCP and the HTTP mapping use a json serialization for objects send over the VAB. In the following, this json serialization is explained.

Requirements

There are multiple requirements on the JSON serialization:


Type Representation

The following types are taken as is from the JSON type scheme:

  • string
  • number (integer or double)
  • object (i.e. map)
  • boolean
  • null

Additionally, these types are introduced:

  • ordered lists
  • unordered sets
  • functions

Since the type information of the Asset Administration Shell (AAS) are explicitly represented in the meta-model, the JSON serialization of the AAS does not explicitely sa

Unordered Sets vs. Ordered Lists

Since JSON natively supports only JSON arrays, a distinction between unordered sets and ordered lists has to be introduced. There are multiple ways this type information is represented. The reason for this stems from the compatibility to the Details of the Asset Administration Shell JSON serialization.

If the JSON array contains objects, these objects are enriched with an index if the JSON array is representing an ordered list. E.g. [ {"a": 1, "index": 0}, {"a": 10, "index": 1} ] represents an ordered list of objects.

However, this does only work when the JSON array contains objects. In the case of it containing simple types (e.g. strings), the type information has to be added differently. This is done by introducing a map in parallel to the object to be described called _basyxTypes. This map contains the type information. E.g. {"_basyxTypes" : {"values": "list"}, "values": [1,2,3]} denotes that the JSON array values is representing an ordered list. The two values allowed are:

  • list
  • set

This solution does only work when an object containing a collection is requested. In the case of directly requesting a collection, there is no map to attach and remove the type information. Thus, requesting a collection on its own has to be handled differently. This edge case can not happen in the C#-SDK and as consequence can be handled in an incompatible way to the JSON serialization. For this, the keyword _basyxValue is introduced and _basyxType is used similarly as described above. For example, { "_basyxValue": [1,2,3], "_basyxType": "list" } is decoded to an ordered list of [1, 2, 3].


Functions

Functions are most commonly not serializable. Exception of this are Java functions, that can be represented by their byte code. However, there still needs to be an indication that a value is representing a function. This is done by passing this information in the _basyxFunctionType key. The allowed values are:

  • lambda
  • operation

Back to the top