CUSTOM FIELDS SPECIFICATION Version: 0.1 Date: 22-12-2004 Note: text between brackets are additional comments, not part of the specification. 1. ACRONYMS Here are some acronyms that will be used in the specification. BZ: Bugzilla CF: Custom field CFT: Custom field type OO: Object-oriented 2. INTRODUCTION This document serves as a specification for the CF implementation in BZ. It will be firstly worked in a rather abstract view and later will be speciailized up to the implementation details. Since this specification works with both data and metadata (and considerers interactions between both) some care must be taken on abstraction levels. As a general aid, UML notation will be used when it helps clearing concepts. Since data and metadata must be accounted for, a few special extension will be used in diagrams. [Paulo: more on this is needed otherwise it will be totally incomprehensible!] 3. CUSTOM FIELD TYPES Before working on custom fields themselves we must define some basic concepts which serve as building blocks for custom fields. On such basic concept is the CFT. A CFT is, in essence, a value "Domain". [Paulo: For those not very familiar with the naming, a domain is basically a set of finite or infinite values. For example, an "integer" is a finite domain with values between [-2^-31,2^31-1]. A "string" is an infinite domain with all possible text combinations.] CFTs can be intuitively divided into two subclasses: primitive types and custom types. Primitive types are domains directly supported by both the programming language and undelying permanent storage. There are 5 primitive types: integers, strings, reals, enumerations and booleans. [Paulo: Note that there is no direct support for multi-valued types since multi-valued types are best represented by groups of boolean values. Although this approach using domains might seem a little bit abstract I find we can end up with an implementation similar to Sean's for primite types. I find, however, that working this way will allow a more generic implementation allowing more complex data-types.] On the custom types "tree", one special custom type can be defined which is a custom type build by grouping other types. The multi-valued data type would be a subclass of this one. Figure 1 defines the CFT hierarchy and Figure 2 defines the composition of the Group Type and the Multivalued Type.