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.

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, anyone 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.

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:

• Catalog of blocks with versioning, given attribute range and a descriptions of the meaning
• Catalog of groups of blocks with a description, a list of blocks and their versions
• Catalog of documents definitions describing the list of groups
• Description might be available in multiple languages

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 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:

Diagram source file diagram3.dia

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.

• Item names

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.

• Item description

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.

• Comment

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.

• String Identification

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.

• Icons

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.

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

Client Application:

• Retrieve a file and display tree structure
• Retrieve a document and valid type's ranges
• View information about items (blocks)

Web Service:

• User's operations:
  • Browsing a list of defined formats, groups, blocks and attributes and their linking
  • Browsing a list of owners of items
• Item owner's operations (includes user's operations):
  • Editing items
  • Creating and deleting items and subitems
  • Managing links
  • Ownership handover
• Manager operations (operations include the owner of the item):
  • Change of ownership
  • Change of the position of the items

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

Basic schema:

Detailed schema of service:

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:

• Methods to allow full or differential export of the catalog's content.
• Access to perform validation of the document