ZBNF-Binary

Topic:.ZBNF_syntaxBin.

pStyle=std tableStyle=stdTable

Written by Hartmut Schorrig, www.vishia.org. Latest edition 2011-01-11

Topic:.ZBNF_syntaxBin..

pStyle=std tableStyle=stdTable

Binary data can be described in the programming language C with struct{...} in headerfiles. This is usual. But the struct-description is only simple for fix data struct. If the assignment of data depends on content in other data (cmd in header etc) then the description with struct-constructs needs some additional explanation, which are non-formalistic.

The ZBNF-description for binary data should support

• exact formalistic description manual used,

• Conversion of binary data to a XML-representation,

• Read binary data into a Java-program or other program if the parser would be available for other languages.

The possibility of generating binary data from XML or inside a Java-program is not considered yet, but it seems able to do too.

Topic:.ZBNF_syntaxBin..

pStyle=std tableStyle=stdTable

component::= syntax.

The definition of a binary-component as sequence of bytes should be the same as normal ZBNF.

component::= <@ ...

The <@ is the basic expression to refer to binary data.

component::= <@SIZE=16> ...

This is a binary component with a fix size. Such components can be translated to a C-language struct-construct.

component::= ... <@8+2?name1>

That expression describes, that a integer-value is found inside the component at byte-position 8, 2 bytes long, in big-endian, with the name name1. The name is the semanitic-meaning respectively the variable name in a C-language struct.

component::= ... <@8%2?name1>

Same, but in little endian. It is possible to describe a mix of little and big-endian data, though it doesn't might suitable.

component::= ... <@8+4:float?name2>

It means, that the data at this position is in float format. The float-format might be the standard-float-format of the most processors. Abbreviations should be explained manually or a special format name should be created and used. - Adequate type names can be noted instead float.

component::= ... <@6+2[15..12]?name3>

It means the bits 15..12 at the integer representation in the bytes 6 and 7, big-endian. To note a single bit write <@6+2[11]?name4>

component::= <@HEADSIZE=8> <@0+2:SIZE?nrofBytes> <@2+4?....> ...

This component is a byte-sequence with a variable size. The syntax describes the header of the bytes only. The header has the given size. This next element is positioned at bytes 0 and 1 in big endian in this header and have the name nrofBytes, as explained above. The special part is the type SIZE. It means, it is the size of the byte-sequence of this component.

component::= <@HEADSIZE=...> <@4+2[15..12]:SIZE?nrofBytes> <@2+4?....> ...

The size of the component may defined in some bits only too. In this case the size is in range 0..15 because there are only 4 bits for that. The SIZE describes the size in bytes of the byte sequence inclusive header. For other presentation of byte-data-size other special types should be defined ...todo later. For example it may be necessary to describe the size exclusive header bytes, or the size in words.

superiorComp::= ... <component:> <otherComp> <otherCompText> <:component>

This syntax describes a superior component, which contains a binary component. Because the <component> is a binary one, the superiorComp is binary too.

The notation :> suggests, that the <component:> contains the head data only. It requests, that <@HEADSIZE=...> is declared there, just as a <@...:SIZE...>-element should be defined there.

The notation <:component> marks the end of the byte sequence. The content between them are the payload of the header. The <:component> doesn't build extra byte-data, but it marks the length of the byte stream, which is established in the SIZE-element of the header. The definition of a size in a header and a payload is usual for byte-sequences or byte-streams.

The superiorComp may contain text-bytes in its payload. The text-bytes (ASCII-character) are described with the known ZBNF-syntax for textual representation.

superiorComp::= ... <component?semantic:> <otherComp> <otherCompText?text> <:semantic>

It is able to define another semantic as the syntax identifier, like usual in the ZBNF. In this case the end-tag should contain the semantic-identifier.

Topic:.ZBNF_syntaxBin..

pStyle=std tableStyle=stdTable

In an XML-representation after parsing any data of this example-syntax may be presented in form of

<semantic @nrofBytes="254" @name1="345" @name2="3.145678" @name3="5">
  <otherComp itsElements="value">...</otherComp>
  <text itsAttrComp="value" >
    <textCompIntern>...
    </textCompIntern>
  </text>
</semantic>

Topic:.ZBNF_syntaxBin..

pStyle=std tableStyle=stdTable

The conversion of a XML-representation back to the binary data should start on the top-level syntax-component. It should detect the proper component with the given semantic. The syntax isn't contained in the XML-tree, only the semantic. Therefore a back transformation is not easy to do. Possibly a Xschema-notation may helpfull. Xschema describes the formal syntax of a XML-tree in form of admissible arrangements. The Xschema-definition should name the component-identifier (syntax name). Then a back-transformation may be able to do.