CommsDSL Specification
  • Introduction
  • Version
  • Schema Definition
  • Multiple Files
  • Namespaces
  • Platforms
  • References
  • Properties
  • Numeric Values
  • Boolean Values
  • Names
  • Protocol Versioning
  • Schema
  • Fields
    • Common Properties of Fields
    • enum Field
    • int Field
    • set Field
    • bitfield Field
    • bundle Field
    • string Field
    • data Field
    • list Field
    • float Field
    • ref Field
    • optional Field
    • variant Field
    • Referencing Values of Other Fields
  • Messages
  • Interfaces
  • Aliases
  • Frames
    • Common Properties of Layers
    • payload Layer
    • id Layer
    • size Layer
    • sync Layer
    • checksum Layer
    • value Layer
    • custom Layer
  • Protocol Versioning Summary
  • Appendix
    • Properties of schema
    • Common Properties of Fields
    • Properties of enum Field
    • Properties of int Field
    • Properties of set Field
    • Properties of bitfield Field
    • Properties of bundle Field
    • Properties of string Field
    • Properties of data Field
    • Properties of list Field
    • Properties of float Field
    • Properties of ref Field
    • Properties of optional Field
    • Properties of variant Field
    • Units
    • Properties of message
    • Properties of interface
    • Properties of alias
    • Properties of frame
    • Common Properties of Layers
    • Properties of checksum Layer
    • Properties of value Layer
    • Properties of custom Layer
Powered by GitBook
On this page

Was this helpful?

Multiple Files

For big protocols it is possible and even recommended to split schema definition into multiple files. The code generator must accept a list of schema files to process and must process them in requested order.

Every subsequently processed schema file must NOT change any properties specified by the first processed schema file. It is allowed to omit any properties that have already been defined. For example:

First processed file:

<?xml version="1.0" encoding="UTF-8"?>
<schema name="MyProtocol" endian="big" version="2">
    ...
</schema>

Second processed file:

<?xml version="1.0" encoding="UTF-8"?>
<schema name="MyProtocol" endian="big">
    ...
</schema>

It must be accepted by the code generator because it does NOT change previously defined name, endian, and version. The second file doesn't mention version at all.

However, the following third file must cause an error due to changing the endian value:

<?xml version="1.0" encoding="UTF-8"?>
<schema name="MyProtocol" endian="little">
    ...
</schema>

Also note, that all the properties have some default value and cannot be defined in second or later processed file while been omitted in the first one.

For example, the first file doesn't specify version number (which defaults to 0)

<?xml version="1.0" encoding="UTF-8"?>
<schema name="MyProtocol" endian="big">
    ...
</schema>

The following second file must cause an error due to an attempt to override version property with different value.

<?xml version="1.0" encoding="UTF-8"?>
<schema name="MyProtocol" version="2">
    ...
</schema>
PreviousSchema DefinitionNextNamespaces

Last updated 5 years ago

Was this helpful?