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

Difference between revisions of "BaSyx / Documentation / VAB / JSON Serialization"

(Explanation of JSON serialization)
 
(Removes references to Set support)
 
(One intermediate revision by the same user not shown)
Line 3: Line 3:
 
| [[BaSyx_/_Documentation_/_VAB_/_HTTP_Mapping | HTTP/REST Mapping]]
 
| [[BaSyx_/_Documentation_/_VAB_/_HTTP_Mapping | HTTP/REST Mapping]]
 
| [[BaSyx_/_Documentation_/_VAB_/_TCP_Mapping | TCP Mapping]]
 
| [[BaSyx_/_Documentation_/_VAB_/_TCP_Mapping | TCP Mapping]]
 +
| [[BaSyx_/_Documentation_/_VAB_/_Exceptions | Exceptions]]
 
|}
 
|}
 
= JSON Serialization =
 
= JSON Serialization =
Line 23: Line 24:
 
Additionally, these types are introduced:
 
Additionally, these types are introduced:
 
*ordered lists
 
*ordered lists
*unordered sets
 
 
*functions
 
*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 ===

Latest revision as of 07:54, 7 August 2020

See also HTTP/REST Mapping TCP Mapping Exceptions

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
  • functions

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

Copyright © Eclipse Foundation, Inc. All Rights Reserved.