About XSD files

General structure of EUCARIS XSD files

Each EUCARIS message is specified in a separate XSD file. The file name is equal to the name of the message in the functional specifications.

Every EUCARIS message is composed of a header part and a body part, both mandatory. The header is the same for all messages. The header is specified in a separate XSD file – EucarisIIHeader.xsd, which is included in every message file. The header xsd file is part of the EUCARIS core.

The body part is unique for each individual message. It consists of a set of elements. Attributes are not used by default, with the exception of XSD specifications that are copied from EU specifications.

The complex types used in the message, are usally specified in the XSD message file itself. Simple type declarations are specified in separate XSD files (this file or these files are included in the message file).

For simple type declarations, two levels are distinguished.

a. Service specific simple types

I.e, the definition of the type is valid for the service the message belongs to, and can be re-used within that service. The change frequency of these types coincides with the change frequency of the service itself, i.e. these types may change if there are functional changes in the service the types belong to.

The service specific simple types are specified in a XSD file that has the name of the service, trailed by the word ‘types’, e.g. VHInfoTypes.xsd.

b. Generic simple types

I.e., the definition of the type can be used generally, in all services. The change frequency of these types is independent of the changes in EUCARIS services or EUCARIS itself, these types may change if the outside world changes.

The generic simple types are specified in the XSD file SimpleTypeDefinitions.xsd. The simple type definitions file is part of the EUCARIS core.

Some examples of generic simple types

1. Types to denote the length of strings (StringOf1Type, StringOf10Type, etc.).
2. Types to denote numeric values and fractional numbers.
3. Date in format CCYYMMDD types (with or without pattern validation on a valid date).
4. UUID type.
5.  Country code lists (UNECE or Vienna codes, ISO 3166-1 alpha-2 codes).

Policy change on simple types

The policy on simple types, outlined above, has been employed by EUCARIS since 2016.

Before that, the policy was different. All type declarations were stored in the SimpleTypeDefinitions.xsd, both the service specific types and the truly generic types. At times, we suffered from the disadvantage of this method, i.e., a service sometimes needs to change, not because anyone actually wants a change, but because the outside world forces a change.

For that reason, it was decided to move to the policy described above. The change is carried out gradually, per service, if there is a functional change to be done on that service. Currently (december 2017) the migration from the ‘old’ to the new policy, is almost completed.

Along with the vehicle signals update (december 2017), a lot of XSD specifications were changed from the old to the new policy. The table below lists the state of affairs after the release of the ‘vehicle signals’ update (december 2017) and CBE (statistics update, march 2018). For the services listed in italic, the XSD files were re-specified in these updates.

Namespace policy

The EUCARIS XSDs contain no target namespace definition by default. Therefore when sending them via SOAP you have to add the explicit empty namespace declaration xmlns=”” on the root message element. A typical EUCARIS SOAP request containing an EUCARIS message has the following structure (VHInfoReqByChassis message as example):