This file is the Zhulebino document. It describes requirements for an extended format for the specification of ReDIF. The basic idea is that there should be a language code-named "zhuleb" that will describe an instance of ReDIF in a structural and syntax-independent way. The current template syntax and a future xml-based syntax can then be used as different syntactic manifestations of ReDIF. In addition, different user groups of ReDIF may define their own extension to a common set

At a meeting in Moscow on 21 and 22 June we have not been able to fully specify zhuleb. However we have come up with a list of requirements for that language. These are listed in the following in a separate file.

The record types in zhuleb will be object-oriented. For each instance of a record type (paper person book etc) there will be a parent class defined at the cross-authority level. For each record type each authority may create a single child class that will introduce further element names and make the requirements on existing elements more stringent.

In the existing template syntax the parent class will be read after the ReDIF- statement in the Template-Type field. The child class will be read from the Handle attributes. Ivan bemoans this approach.

For each record type one or more grandparent classes may be introduced. These are used to communicate with external metadata formats. The zhuleb file at the cross-authority level will link elements of parent-class record types with elements of the grandfather class. For example suppose that the grandfather class is "Dublin_Core". Then zhuleb will have the capability to encode that in each record of the "paper" parent class of ReDIF the author-name field value will be the "dc.creator" value of the corresponding record in the "Dublin_Core" record class.

There will be one cross-authority zhuleb file. Each authority may write its own zhuleb file which will extend the cross-authority statements.

Each record of each record type will have a handle. zhuleb will fix syntax requirements for handles. Individual fields in certain record types will require values that are valid handles of records. zhuleb will describe this relational structure between records.

Zhuleb will allow for hierarchical handles. That means that the full handle of a record can be used in the handle of another record. For example the handle of a paper contains the handle of the series that it belongs to. Zhuleb will specify this handle structure.

Zhuleb will be able to restrict the syntax of field values. Parsing software will ignore any field value that does not have a valid syntax.

Given the two preceding requirements it is difficult to write zhuleb without the explicit use of a language like perl or java. Ivan will investigate how to make zhuleb as language independent as possible.

Zhuleb will specify if a field is required or not and if it is repeatable. If the parent class requires an element the child class will require it. If the parent class does not require an element the child class may require it. If the parent class declares an element to be non-repeatable, the child class will inherent this requirement. If the parent class declares an element to be repeatable, the child class may make it non-repeatable.

Zhuleb will be able to associate a descriptive string with each attribute that it defines. Therefore a zhuleb file can be a reasonably self-explanatory description of a metadata format.

Unknown field names will lead to an error in all templates for all classes.

Zhuleb statements will be used to define the format of ReDIF data. We will call ReDIF any data whose structure can be described by a sequence of zhuleb statement.

The parsing of ReDIF data will use syntax specific software first. The data that has been read will then be parsed by a ReDIF parser encoded in zhuleb.

We gratefully acknowledge the hospitality of Zhenya Stupina that provided for the congenial atmosphere that made the original draft of this document possible.