Skip to content

Commit 9d14bc8

Browse files
committed
Release v6.1
2 parents 2b1a5e8 + d4bfde7 commit 9d14bc8

File tree

6 files changed

+98
-18
lines changed

6 files changed

+98
-18
lines changed

CMakeLists.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ if (NOT ASCIIDOCTOR_PDF_EXE)
1111
message(FATAL_ERROR "asciidoctor-pdf is not found")
1212
endif ()
1313

14-
set (VERSION "v6.0")
14+
set (VERSION "v6.1")
1515
set (MAIN_FILE "${PROJECT_SOURCE_DIR}/commsdsl_spec.adoc")
1616

1717
add_custom_target("pdf" ALL

commsdsl_spec.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
1-
= CommsDSL Specification v6.0
1+
= CommsDSL Specification v6.1
22
Alex Robenko
3-
v6.0, 2023-03
3+
v6.1, 2023-06
44
:doctype: article
55
:toc: left
66
:source-highlighter: rouge

fields/bundle.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -54,7 +54,7 @@ of the **<bundle>**, then all the members must be wrapped in
5454
----
5555

5656
[[fields-bundle-reusing-other-bundle]]
57-
==== Reusing Other <bundle&gtp ====
57+
==== Reusing Other <bundle> ====
5858
Like any other field, **<bundle>** supports **reuse** of any other **<bundle>**.
5959
Such reuse copies all the fields from original **<bundle>** in addition
6060
to all the properties. Any new defined member field gets **appended** to the copied ones.

fields/common.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ it is **NOT** allowed for <<fields-enum, &lt;enum&gt; >> field to reuse definiti
7171
[[fields-common-forcing-generation]]
7272
==== Forcing Generation ====
7373
By default the code generator is expected not to generate code for fields that
74-
are not <<intro-references, referenced>> by any other field to reduce amount of
74+
are not <<intro-references, referenced>> by any message or any other field to reduce amount of
7575
generated code. However, there may be cases when a field releated definitions are expected
7676
to find their way into the generated code even the field itself is not referenced
7777
anywhere. To help with such forcing the **forceGen** <<intro-properties, property>>
@@ -363,7 +363,7 @@ the **CommsDSL** provides the following <<intro-properties, properties>>.
363363
The value of the <<intro-properties, properties>> above can be one of the following:
364364

365365
* **any** (default) - Inject the overriding code if available, use the code generated by default if not.
366-
* **replace** - The default code code is incorrect, replace it with the provided one. The code generator is expected
366+
* **replace** - The default code is incorrect, replace it with the provided one. The code generator is expected
367367
to report a failure in case the overriding code is unavailable.
368368
* **extend** - The default code is still incorrect, but the code generator is expected to
369369
produce it (with some minor renaming to avoid names clashing) to allow reuse and extension in the overriding code. The code generator is expected

fields/list.adoc

Lines changed: 9 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -205,6 +205,12 @@ suffix field is supported using **termSuffix** property. Just like with
205205
<<fields-list-count-prefix, countPrefix>>, and <<fields-list-length-prefix, lengthPrefix>>,
206206
the termination suffix can be specified as a child XML node or referenced when
207207
defined externally.
208+
209+
The termination suffix is determined by the _successful_ read attempt before attempting to read the
210+
list element. It means that the termination suffix field needs to fail its read operation if it's not
211+
encountered. In most cases specifying valid value(s) in conjunction with the **failOnInvalid** property
212+
is sufficient.
213+
208214
[source,xml]
209215
----
210216
<?xml version="1.0" encoding="UTF-8"?>
@@ -215,19 +221,19 @@ defined externally.
215221
<int name="Element" type="uint32" />
216222
</element>
217223
<termSuffix>
218-
<int name="TermSuffix" type="uint8" defaultValue="0"/>
224+
<int name="TermSuffix" type="uint8" defaultValidValue="0" failOnInvalid="true" />
219225
</termSuffix>
220226
</list>
221227
222-
<int name="ExternalTermSuffix" type="uint8" />
228+
<int name="ExternalTermSuffix" type="uint8" validRange="[0, 1]" failOnInvalid="true" />
223229
<list name="List2" termSuffix="ExternalTermSuffix">
224230
<int name="Element" type="uint32" />
225231
</list>
226232
</fields>
227233
</schema>
228234
----
229235

230-
**NOTE**, that **count**, **countPrefix**, **lengthPrefix**, and **termSuffix** properties
236+
**NOTE** that **count**, **countPrefix**, **lengthPrefix**, and **termSuffix** properties
231237
are mutually exclusive, i.e. cannot be used together.
232238

233239
[[fields-list-element-length-prefix]]

fields/optional.adoc

Lines changed: 83 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -77,7 +77,7 @@ specified using **defaultMode** <<intro-properties, property>>.
7777
[[fields-optional-existence-conditions]]
7878
==== Existence Condition ====
7979
Many protocols introduce optional fields, and the existence of such fields
80-
depend on the value of some other field. Classic example would be having
80+
depends on the value of some other field. Classic example would be having
8181
some kind of flags field (see <<fields-set, **&lt;set&gt;** >>) where some bit specifies
8282
whether other field that follows exists or not. Such conditions can be expressed
8383
using **cond** <<intro-properties, property>>.
@@ -92,13 +92,13 @@ using **cond** <<intro-properties, property>>.
9292
<optional name="Val1" defaultMode="missing" cond="$Flags.Val1Exists">
9393
<int name="ActVal1" type="uint32" />
9494
</optional>
95-
</fields>
95+
</message>
9696
</schema>
9797
----
9898
**NOTE**, that **cond** property can be used only for **&lt;optional&gt;** field
9999
that is a member of a <<fields-bundle, &lt;bundle&gt; >> or a
100100
<<messages-messages, &lt;message&gt; >>. The **cond** expression
101-
specifies condition when the **&lt;optional&gt;** field exists, and must always
101+
specifies condition when the **&lt;optional&gt;** field exists, and is expected to
102102
reference other **sibling** field. Such reference is always prefixed with `$` character
103103
to indicate that the field is a **sibling** of the **&lt;optional&gt;** and
104104
not some external field.
@@ -129,7 +129,7 @@ For example:
129129
<optional name="F3" defaultMode="exists" cond="$F1 &lt; $F2">
130130
<int name="WrappedF3" type="uint32" />
131131
</optional>
132-
</fields>
132+
</message>
133133
</schema>
134134
----
135135
The `F3` above exists, only if value of **F1** is less than value of **F2**
@@ -146,14 +146,39 @@ Deep (nested) conditions are also expected to be supported by the code generator
146146
<bit name="B0" idx="0" />
147147
<bit name="B1" idx="1" />
148148
</set>
149-
</fitfield>
149+
</bitfield>
150150
<optional name="F2" defaultMode="missing" cond="$F1.Mem2.B0">
151151
<int name="WrappedF2" type="uint32" />
152152
</optional>
153153
<optional name="F3" defaultMode="exists" cond="!$F1.Mem2.B1">
154154
<int name="WrappedF3" type="uint32" />
155155
</optional>
156-
</fields>
156+
</message>
157+
</schema>
158+
----
159+
160+
When referencing the member of another `<optional>` field in the existence condition,
161+
a check that the wrapping `<optional>` field **exists** in addition to the
162+
actual specified condition is automatically implied.
163+
[source,xml]
164+
----
165+
<?xml version="1.0" encoding="UTF-8"?>
166+
<schema ...>
167+
<message name="Msg1" id="1">
168+
<set name="F1">
169+
<bit name="B0" idx="0" />
170+
<bit name="B1" idx="1" />
171+
</set>
172+
<optional name="F2" defaultMode="missing" cond="$F1.B0">
173+
<set name="WrappedF2">
174+
<bit name="B0" idx="0" />
175+
<bit name="B1" idx="1" />
176+
</set>
177+
</optional>
178+
<optional name="F3" defaultMode="exists" cond="!$F2.WrappedF2.B1">
179+
<int name="WrappedF3" type="uint32" />
180+
</optional>
181+
</message>
157182
</schema>
158183
----
159184

@@ -171,7 +196,7 @@ as the reference to a sibling field described above.
171196
<bit name="B0" idx="0" />
172197
<bit name="B1" idx="1" />
173198
</set>
174-
</fitfield>
199+
</bitfield>
175200
</interface>
176201
177202
<message name="Msg1" id="1">
@@ -181,7 +206,7 @@ as the reference to a sibling field described above.
181206
<optional name="F2" defaultMode="exists" cond="!%Flags.Mem2.B1">
182207
<int name="WrappedF2" type="uint32" />
183208
</optional>
184-
</fields>
209+
</message>
185210
</schema>
186211
----
187212
**WARNING**: The **CommsDSL** specification supports multiple interfaces and doesn't impose any restriction
@@ -191,6 +216,54 @@ the referenced field. The code generator may also not impose many restrictions o
191216
Usage of the wrong **&lt;interface&gt;** class with the missing referenced
192217
field in the end application may result in compilation errors.
193218

219+
Since **v6.1** of this specification comparing the size of the collection type fields (
220+
**&lt;data&gt;**, **&lt;string&gt;**, and **&lt;list&gt;**) is also supported. The size check condition is determined
221+
by the usage of the `#` character after the one indicating sibling (`$`) or interface (`%`) reference.
222+
[source,xml]
223+
----
224+
<?xml version="1.0" encoding="UTF-8"?>
225+
<schema ...>
226+
<message name="Msg1" id="1">
227+
<data name="F1">
228+
<lengthPrefix>
229+
<int name="Length" type="uint8" />
230+
</lengthPrefix>
231+
</data>
232+
<optional name="F2" defaultMode="missing" cond="$#F1 != 0">
233+
<int name="ActF1" type="uint32" />
234+
</optional>
235+
</message>
236+
</schema>
237+
----
238+
In the example above the `F2` field exists if `F1` is not empty, i.e. its size is not `0`.
239+
240+
Also since **v6.1** of this specification check whether the previously encountered **&lt;optional&gt;** field
241+
exists is also supporting in another **&lt;optional&gt;** field condition. Such check is determined by the
242+
usage of the `?` character after the one indicating sibling (`$`) or interface (`%`) reference.
243+
244+
[source,xml]
245+
----
246+
<?xml version="1.0" encoding="UTF-8"?>
247+
<schema ...>
248+
<message name="Msg1" id="1">
249+
<set name="F1">
250+
<bit name="B0" idx="0" />
251+
<bit name="B1" idx="1" />
252+
</set>
253+
<optional name="F2" defaultMode="missing" cond="$F1.B0">
254+
<set name="ActF2">
255+
<bit name="B0" idx="0" />
256+
<bit name="B1" idx="1" />
257+
</set>
258+
</optional>
259+
<optional name="F3" defaultMode="exists" cond="!$?F2">
260+
<int name="ActF3" type="uint32" />
261+
</optional>
262+
</fields>
263+
</schema>
264+
----
265+
In the example above `F3` exists when `F2` is missing.
266+
194267
[[fields-optional-multiple-existence-conditions]]
195268
==== Multiple Existence Conditions ====
196269
The **CommsDSL** also allows usage of multiple existence condition statements. However,
@@ -253,7 +326,8 @@ place in the input buffer.
253326
==== Missing On Invalid ====
254327
Similar to <<fields-optional-missing-on-failed-read, missingOnReadFail>>, but with a bit of different
255328
flavour, the property **missingOnInvalid** insures that the **&lt;optional&gt;** field is marked as
256-
"missing" when the held field's value is invalid. If case of recognition the invalid value
329+
"missing" when the held field's value is invalid (applicable to the __refresh__ operation).
330+
In case of recognition of the invalid value
257331
during the __read__ operation, the **&lt;optional&gt;** field must be marked as "missing" and
258332
reading of the following fields must continue from the place in the input buffer as if the __read__
259333
operation of the **&lt;optional&gt;** field didn't take place.

0 commit comments

Comments
 (0)