Note that if the "network" property is not defined, the following properties must also be defined:
serverInputPort: The port for the communication Client => Server (used by the Client to set the parameters)
serverOutputPort: The port for the communication Server => Client (used by the Server to send events on widgets and error reports)
serverInputSize: The size of the port for the communication Client => Server
serverOutputSize: The size of the port for the communication Server => Client
Optional properties
"env.<key>": set a path value by using the content of an environment variable,that can be used as a replacement pattern in any File or URL values after this definition in the properties file. More than one environment path can be defined in the properties File. For example, if we have env.tutu=TUTU and if we have after this line: graphics=${env.tutu}/graphics.xml. This property definition will be equivalent to: graphics=<content of the TUTU environment variable>/graphics.xml
respectParentChildren: check if the parent-children relationships specified in the standard (and defined in the meta-definition) are checked when opening or editing Definition Files
debug: true to show debug informations on the command line
"debugLog": contains the path of a File which will contain the DEBUG and all logger content for the Server or the Client
bigEndian: true if communication is in Big Endian format (default = true)
warnForUndefAttrs: true if a warning must be issued when parsing XML Definition Files with unfounded defined attributes (default = true)
checkFR180Range: specify if the Server should check that angles are in the [-180, 180[ range. If this property is set to true, the Server will set the angle 0 and post an exception if the Definition File has an angle which is outside this range
"protocol": the name of the built-in protocol used for communication, which can be:
"udp" for UDP protocol (default)
"tcp" for TCP/IP protocol
or the key of an additional protocol given by the protocol Provider (see Built-in protocols for those which are provided by default)
"network": defines a Network XML file defining the channels to open for the UA <=> CDS communication. It allows to define more than one Channel of communication between UA and CDS, each with specific properties
server.windows: The XML configuration File for the Windows definition, and the Layers List. If this File is defined, the graphic definition (including the Layers) will be set with the content of this File). Warning: This File will be used only if the windowManager property is set to windows. See also the window Management article
"loggerSize": the number of lines for the events logger
"logMaximumLines": the maximum number of lines for the logger. If this value is set, the logger will only present the last logMaximumLines lines
extensions: The jar file containing the specific extensions to the standard (for widgets and rendering)
"compactOutputBuffers": The property name to specify that it is allowed to compact the content of an output Buffer if several blocks are to be sent for several Layers of the same Buffer. This can for example allow to send only one Buffer containing all the A661_NOTE_LAYER_IS_ACTIVE and A661_NOTE_LAYER_IS_INACTIVE for all the Layers managed by a Channel if the cockpit configuration is changed
Strict / Loose ARINC 661 Schema
The ARINC 661 supplement 6 enforce the use of an XML Schema for the XML Definition File.The ARINC 661 supplement 6 enforce the use of an XML Schema for the XML Definition File. Prior to supplement 6, the ARINC 661 standard did only define a DTD, but J661 already used a Schema which was a little more loose the the standard supplement 6 schema. Note that the DTD which was defined before in the standard was even more loose than the "loose" schema.
Differences between the loose schema and the strict schema:
The Library version is optional
Accept several widgets with the same name. Note that the Server, Client and Editor will however still rename the widgets internally such as not having more than one widget with one specified name
Extensions may have no child "model" element, which allows to use extensions which have no parameter at all
The rules for elements name are more lenient and accept any character
All the widgets and extensions attributes are defined in the Binary Definition Files, but some of the attributes might not be defined in the XML Definition File. The warnForUndefAttrs attribute allows to emit a warning if one of the attributes defined for a widget or extension is not found in the XML Definition File.
Setting specific properties for extensions
By default only properties which are defined for the Client or Server are taken into account. However it is possible to define specific properties for J661 extensions. See See extensions manifest properties for more informations on how to define these properties.
See also
Configuration properties format: This articles present the two formats that can be used to set the Server or Client configuration properties
Server configuration properties: The Server configuration properties allows to specify the configuration of the Server at start
Client configuration properties: The Client configuration properties allows to specify the configuration of the Client at start