XBUP - Extensible Binary Universal Protocol

» Concepts » Issues

Issue: Proposed Characteristics

This document is part of the eXtensible Binary Universal Protocol project documentation. Provides description of proposed characteristics.

Considered Characteristics

At higher levels there should be further extensions declared, which should provide a new useful characteristics for protocol. It has not yet been decided on what specific level or if even should them be included in the project.

Document Structure

The following properties are involved in the internal structure of the Protocol. Most of them are listed in the draft of the levels.

Order of Blocks

In the case of equivalent blocks it may be possible to reorder.

It is appropriate to allow insertion of additional optional blocks both before and after essential blocks. Yet interlacing of these blocks might not be too appropriate. The range of allowed orders of blocks will be be probably reconsidered.

Condensation of the Document

The aim here is to achieve a reduction in the size of the output format using some of the following techniques:

These operations should not result in restrictions on other characteristics such as scalability. Will be probably reconsidered.

Block Type Recognizing

This feature should allow the identification of the type / meaning / characteristics of the block without any knowledge of the complete specifications. For example, in the case of block transformation it could be useful to recognize that the block can be obtained only after the application of transformation. These characteristics could also have a relation with inheritance and the meaning of extended blocks.

Document Processing

These properties are not directly concerned by protocol specification to a specific level, but rather a way of working with a document from the outside.

Document's Merging

Merging is meant here as parallel processing of multiple files with the same structure of the contents which have some type of connection. It occurs in a situation where a pair of files share the same tree and particular blocks bear the information which is equivalent to one set of the combined blocks.

For example, the multimedia containers. One solution is to place audio and video data, or other streams, such as subtitles, in separate files and then player when playing have to process them all as needed. This makes it possible to attach subtitles to video files without having to change their content and, therefore potential corruption of their checksums and other properties. Other extreme case is the merging of all those streams in a single interlaced file. Both extremes, as well as their combinations make sense. Similarly, it is appropriate to expect cases where, for example, video stream will be divided into the picture and sound part and sent using multiple streams simultaneously, or as linked sequence more disparate videos in a row.

An example of that is more relevant to current XBUP protocol, is the catalog. Basic catalog, in the current scenario, contains only permitted range of groups, blocks, and the number of attributes. For example, if we want this information to expand of the text description of the blocks and attributes, you can use either an external file or information incorporated directly into the catalog. In this case it appears to be the first option more preferable since it allows to change the language used and not force the download of the language, if it is not explicitly requested.

The main consideration, which is concerned with is the definition distribution of the document on the basic (level 1) and other single files, which may, for example, introduce the text descriptions in the same tree in different languages, or icons, or types of attributes and inheritance. These separate files will contain the same tree, and the problem is mainly in the processing of more such documents, or problems with their inconsistencies and so on.

Document's Comparision

In the case of comparing the two documents problems with the order blocks may appear and the use of different compression and transformation. For this reason, it would be appropriate to propose the canonical form of the document (similar to the XML). The second thing is to design a format for storing the differences of two documents, with the possibility of its applications.

At a later stage it would also be appropriate to define more precisely isomorfisms and equivalent block expressions, as well as the degree of similarity for various essential blocks.

Canonical Form of a Document

Like in the case of XML, there will need to create a so-called normal form, the form in which it is possible to compare the documents to conformity. The foundation can not be uncompressed form, because compression also reflects a certain feature. Probably there will be also a system of multiple levels.

Difference Algorithms

Generally, you can always compare the data files due to their binary form. However, as is the case with text files, the comparison considers the structure of the command-line, there will be proposed algorithms to compare the two documents appropriate to format XBUP, considering the block structure of the document. Possibly also an application which will be able create a file of the differences, which will also allow to apply such data to obtain new version of the file from old one. Data blocks will be compared to the conventional methods for binary formats.

Grammars

It will be appropriate to establish a basic protocol grammar. Perhaps it is possible to distinguish grammar under different levels of detail and in accordance with the established protocol. Most detailed is a complete system for controlling the order of bit sequences. It should verify the basic validity at that level.

Other option is the system of parser transition. That describes in what sequence it is possible to pull, or send items matching the format structure.

Full Binary Grammar

The aim of this grammar is to provide way how to validate the document, for each level.(or at least lower levels)

Other Blocks

Example: addressing multiple blocks

Data types of the constant lengths

It seems to be possible to specify the protocol at constant data types levels, such as Boolean, Int32, Int64, which would be implemented as a data block.

Moreover, it is appropriate to consider factors such as such which are used in relational databases - the normal form and probably also features of the classes in object programming, such as inheritance, composition.

The nature of the protocol is more than appropriate to provide way ho to get all elements indexed. This is certainly exacerbated by the clarity and force programmers to learn additional names and sequence of numbers that correspond to those names. Therefore it will be the best to hide these indexes at the application level.

List:

Basic block for the construction of any general list of items.

Elements with higher index than the number of items might store additional information about the list meaning. The problem with infinite lists. The problem with spare lists.

Catalog Architecture

Catalog can be organized in a single tree, or there may be independent tree for each declaration type.

Scripting Language

Scripts for manipulations and conversions. It should be possible especially possible to use the language as the equivalent XSLT to transform the document into another format.

Choosing Paradigm

Maybe the next level: Full support of the ProgJazy language and service modules. That should allow autoconfiguration and automatic implementation kompatiblity.

Autoconfiguration - the loading and processing of modules of single groups of blocks and their communication with the application program and transfers of the result using a defined interface and the required format

Probably the highest level: Providing the logical communication between the two unknown communication entities.

The full description of communication is to be sent first, and its likely to start introducing of logic functions and mathematical formulas, then the definition of language, eventually communication interface for sound and image.

Considerations of programming interpretations:

As like other formats, it's possible to interpret a date as a prescription program. For example, in the image: Decompress and print. It can be considered as:

Formal Arguments

The aim of course is to ensure that the data are as abstract as possible. For example, a image is either bitmap of perpendicular light emitted within the specified standard frequencies of electromagnetic radiation, or characteristic of surfaces reflection. Each has its own sense (RGB, CMYK). Classical bitmap actually have some form of compression, which says that the continuous flat map is divided into discrete, or different continuous area (square, rectangle, triangle, hexagon, penetrating circles) that have shown just one color (sampling). Then usually followed by further compression (eg LZW, JPEG), etc.

Other Characteristics

Proposal 1: Use attributes only as managing links
Each value should own its own block, and attributes would only link to it, or even no, if for the type of block was distinguished on what attribute type is relevant here.

Page Source