XBUP - Extensible Binary Universal Protocol

Concept: Catalog of Specifications

This document is part of the eXtensible Binary Universal Protocol project documentation. Provides description of catalog architecture and how to use it.

Introduction

The basic proposal of the catalog is designed as a tree hierarchy with defined owners. These constitute the basic skeleton for each protocol specification, over which the additional extensions are defined, particularly human interface. In the first phase there will be entity relational model of the catalog proposed, then the server-client type communication will be defined and finally particular extensions and recommendations for their implementation will be defined.

Catalog Realization

The catalog is divided into several levels, which correspond to each level of the protocol. Test version of the catalog will be implemented over relational database, therefore it will be used for the design of ERD model. That will be extended by the specifications of each class and interface design, which will be later accessible by client applications.

You can read about the description of the specific implementation of the catalog, if you can look at relevant parts of the catalog service documentation.

Requested Characteristics

The catalog is subject to the following requirements:

• Extensibility - The possibility of storing all the specifications including other not yet defined. The possibility of adding additional specification in the catalog and also additional properties. Similarly, anybody should be allowed to add own specifications to the catalog, if requested.
• Version Control - To allow multiple versions of specifications to ensure compatibility
• Relations between the specifications - allow various types of relationship like for example parent-child, etc.
• Reusability - To allow the use attribute specifications for other blocks, or blocks from other groups.
• Community - To allow editing of selected specifications by more people, like the WIKI. The possibility of adding translations in different languages, expansion of the specifications of other owners, links to individual specifications available from independent public sources.
• Mirroring - The ability to create catalog mirrors, with the possibility of automatic updates from a central source.

For maintenance purposes it should be possible to mark individual movable parts with four letters shortcuts.

Catalog Basis

The necessary basic part of the catalog are components which provides support for different levels of the catalog. The aim is to enable the external definition of specifications independent on the operating system and application that process the file. It consists of the list of definitions of documents specifications, where items are the same type or the type of definition of the group. Catalog can be interpreted as a single file, and download it as it or it's possible to access the required subsection using communication protocol.

Level 1

For each type of format specifications, and group, and block, it is necessary provide links which allows to combine them, so that they be used as the document specification. In addition, there is a need for appropriate way of addressing individual items.

• Addressing using index - In this case individual specifications would be assigned to unique ID. Not suitable.
• Addressing using multiple independent trees - The original concept expect the introduction of the types of attributes to the first level. It appeared to be appropriate to the organization of the attributes than it had different tree specification than blocks, and therefore the initial proposal expected that a single tree of categories for each type of items. In the case of specification items, however, these trees greatly overlap semantically.
• Addressing using single tree - An appropriate simplification proved the possibility of creating a single tree for categories for all three types of items.

The following ER Diagram shows the chosen variant scheme:

Diagram source file diagram1.dia

It is therefore about ITEM and BIND parts.

Level 2

Level 2 introduces the types of attributes for the simple attributes, and also for the sequences of attributes.

The primary argument for the organization of the attributes types as a tree of should be some form of inheritance. This would allow certain properties of the item, even without explicit knowledge about it.

This catalog should be able to express the following characteristics:

• Inheritance of attribute properties - The type hierarchy should reflect inheritance of the attributes characteristics.
• Declaration of attribute groups - For higher level of the protocol, it should be possible to realize the definition of a sequence of attributes for the expression of certain properties.

The following ER diagram shows the chosen variant scheme:

Diagram source file diagram2.dia

Added parts are named as TYPE and ATTR.

Level 3

Level 3 introduced possibility of block transformations into the catalog. Transformability is will be probably defined for all 4 types of specification items, but it is still subject to other considerations. It is supposed on of the following possible solutions for next proposal:

Diagram source file diagram3.dia

Added part is named as TRAN.

Other Considered Extensions

There is among the others an extension considered to be included, it is called REV and designed for the inclusion of revisions into the specifications.

Catalog Extensions

In addition to the basic catalog there can be defined various extensions as needed. This is primarily for information about owner of each item, as well as its description and documentation.

Textual Names

NAME extension adds the text names to the individual blocks, with the possibility of multilingual names. Name will be used for various human interfaces for a better understanding of the block data meaning. The will most likely given certain restrictions on the block names, or there may be used more simultaneous names with different kinds of restrictions and with possible conversions between them. There will be restrictions, for example like the prohibition of the spaces, or restrictions on case sensitiveness or exclusion of special characters and similar cases.

More relevant information can be found in the chapter about human interfaces.

Textual Descriptions

Similarly, the DESC extension is designed for short text description of the block meaning, which unlike the name is not given such strong restrictions. However, only one sentence is allowed maximum.

Textual Comments

Third similar extension COMM is used for writing extensive comments on the specification. Use of HTML, or WIKI formatting should be considered later.

Graphical Icons

Another option is to create a catalog for graphic representation of individual items through catalog of icons or other symbols. Usa of several possible resolutions of the bitmap, dependence on language and, where appropriate, vector formats will be considered later.

Catalog Interface

It is expected that the catalog will only expand and the specifications it will not be removed. Therefore it is recommended to thoroughly examine each specification before placing it in the catalog. This does not of course apply for the test version. However, the principle should allow to create copies of the catalog as mirror images, or as a local copy on computers without worrying about getting items obsolete.

To communicate with the catalog it will be necessary to design an interface (remote function calls), because the internal database is not likely to have fixed structure. The possible use cases follows.

Catalog Image Acquirement

This interface provides a complete image of all data in the catalog. For these purposes, yet regular access to the database should be sufficient.

Local Copy Actualization

Especially when we want to create a local copy of the catalog for processing on own computer, all data including all the information about the format / group / block will be downloaded. However, the descriptions are usually focused on a single language.

Reading for Validation-only Purposes

In case we need to do basic validation only, there is basic specification. Information from extensions might be read later to make complete local copy.