This document is part of the eXtensible Binary Universal Protocol project documentation. Provides description of proposed 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.

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

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.

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

• merge two blocks into one (sibling, parent - child)
• default attribute value - the possibility of omission
• automating the presence of the block - Skipping / linking

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

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.

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.

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.

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.

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.

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.

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.

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

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.

• Proposal 1: Only count of the elements in the list in included. Elements have the the same order as they are listed in. Individual items may be of any type. For this would then be possible to create also:
  • Set: the elements must be different, ignoring the order
  • Multiset: ignoring the order
  • Array: elements must be the same type

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.

• Proposal 2: Only that block is a list is defined. Count of items equals count of subblocks
• Proposal 3: Count of item and links on all items included

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

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.

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:

• scripting language (similar to XSLT)
• including processing attributes, for example, enlarge the image
• preprocesing macros

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.

• Borders of attributes usability - It's possible to consider the attributes as it would be appropriate to bring it as a separate block. For example, the size of the image, to provide way how to link it, should be listed as a separate block?\\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.
• Realization of compound attributes - If we as an attribute called real number, it must be implemented as a sequence of two whole numbers (see UBReal), or as two numbers X-Base, X-Mantis? Or consider the real numbers as a separate block?
• Communication protocol - It will be appropriate to propose RPC communication protocol for accessing documents in a XBUP format style - it will send and parse the block on the server side, perform operations on the block …