2.4. Data types and arrays

Data types

In AFD 2.0, data types and format restrictions are separated. As a result, AFD 2.0 only has seven native data types: integer, decimal, string, date, time, timestamp and boolean. The inclusion of boolean instead of ADNLOG implements a much-anticipated wish from the industry. In terms of format, time and date are adapted to the applicable standards within XML and JSON: date is written as CCYY-MM-DD (with dashes) within AFD 2.0, time as hh: mm: ss (with colon).

*Note that the date format changed between AFD 1.0 and AFD 2.0. AFD 2.0 follows the common format CCYY-MM-DD (as does XML) instead of the CCYYMMDD-format used in 1.0.
The time format changed from hhmm (AFD 1.0) to hh:mm:ss in AFD 2.0.
Both XPath/XQuery/XSLT and JSON Schema support functions on durations, dates and times.

¹ Note that JSON considers the date format a subset of the string data type. From JSON Schema 7.0 on, specific date formats can be validated of type CCYY-MM-DD.
² Note that JSON considers the time format a subset of the string data type. From JSON Schema 7.0 on, specific time formats can be validated of type hh:mm:ss.
³ Note that JSON considers the timestamp format a subset of the string data type. From JSON Schema 7.0 on, specific datetime formats can be validated of type yyyy-mm-ddThh:mm:ss[.sss]Z.

The data catalog of AFD 2.0 defines the data type of an attribute but does not limit the string-length or number of decimals. If a supplier wants to apply extra restrictions, he can add these in AFD-definitions. It is easy to set up these restrictions through AOS.

In AFD 2.0 Online you can find the data type of each attribute. More documentation on the use of SIVI AFS is available in chapter Where to find elements of SIVI AFS.

Arrays

Another innovation is the addition of arrays. By reducing the number of entities in AFD 2.0, entities increasingly occur repeatedly in a message or function. With the newly introduced support from JSON, a syntax has been chosen that intrinsically supports arrays, as opposed to XML. Therefore, all entities in AFD 2.0 are arrays by default, even if only one instance is defined within the message. Building on this development, and also regarding eliminating redundancy in the data catalog, some attributes are also used as array. Example attributes are coverageAreaCode (_GEBIED) and companyTypeSpecification (_SBISPCC): a coverage can apply to multiple areas (codelist ADNDKG) and a company can have multiple company types from the corresponding codelist (ADNABS). In XML, arrays will be represented as an xs:list.

Attributes used as an array always contain an array of one specific data type or codelist. In the data catalog this is indicated by square brackets; coverageAreaCode is of type [ADNDKG] for example. The following is a (non-exhaustive) list of attributes used as Array, and their respective attributes in AFD 1.0.

Examples of attributes used as Array

Example message using Array

{
	...
	"party" : [ {
		"entityType": "company",
		"companyTypeSpecification": ["1006", "1007"],
		"ceaCode": "1234567",
		...
	} ],
	...
}

Note: array attributes that have only one value within the message are still written as array (in JSON with square brackets). In the example above that would be "companyTypeSpecification": ["1006"].