[XBUP] XBUP - Extensible Binary Universal Protocol

ยป Concepts

Concept: Central Catalog

The basic concept of the catalog is to provide place where to store basic declarations and related data. It should be used mainly to provide storage for set of properly defined and stable declarations. Catalog can also be used as a local service to provide cached access for XBUP editor and other local applications.

It should be also possible to have separated data declarations, which can be included in document itself or provided by other data sources, like for example via HTTP / using URL to fixed file or RPC service.

Requested Characteristics

The catalog is subject to the following requirements:

Catalog Structure

Catalog shall be application build on top of database and have a tree hierarchy representing ownership structure, probably similar to internet domain names. In each tree node, there can be declarations and definitions stored with separate data for each protocol level. It should be possible to store all catalog data as a single file which can be then downloaded or to provide access to selected subset of data using RPC interface.

The structure of the catalog:

The aim is to also allow use catalog as a storage for various additional data as a sort of extensions.

For each type of format, group and block specifications, their definition parameters can link to other specifications using internal id or path of nodes with sequence index called XBIndex.

The following ER Diagram shows the chosen variant scheme:

Diagram 1

Diagram source file diagram1.dia

Catalog should also allow to store transformations and other conversions as they will be introduced on level 2.

Other considered variant might be the following structure:

Catalog ERD diagram

Diagram source file diagram3.dia

Catalog Extensions

In addition to the basic catalog there is a set of considered extensions to be included in catalog. This is intended for additional meta information about items, as well as description and documentation.

Name extension adds the text names to the individual catalog items, 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.

Similarly, the description 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.

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

This extension is considered for unique string identification codes used for catalog items. It's similar to names extension, but there will be only one unique value per node, probably using English language.

Another extension is to provide a catalog data for graphic representation of individual catalog's items using icons. Use of several possible resolutions of the bitmap, language-dependent icons or also vector formats will be considered later.

Use Cases

Web service will be used for the following cases (Use Cases):

Client Application:

Web Service:

Catalog Web Service

It should be possible to provide access to catalog via web pages.

Basic schema:

Schema 1

Detailed schema of service:

Schema 2

Catalog Interface

It is expected that the catalog will only expand and the specifications 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 prototype version thou.

To communicate with the catalog it will be necessary to design an interface (remote method invocation), because the internal database is not likely to have fixed structure. Interface should provide wide set of methods including: