- Athena Data Dictionary (28nov00 - SW CERN) Athena Data Dictionary Craig E. Tull HCG/NERSC/LBNL Software CERN November 28, 2000

- Athena Data Dictionary (28nov00 - SW CERN) Outline What is a Data Dictionary? Where is a Data Dictionary? How is the DD Used? Athena Dictionary Language Code Generation Object Introspection Current Status Architecture Milestones People: ATeam, ARC, LAPP (Alain Bazan, Philippe Ghez, Thierry Leflour, Sophie Tissot)

- Athena Data Dictionary (28nov00 - SW CERN) What is a Data Dictionary? Object Description residing a) in memory, b) in ascii file, c) within binary file Introspection, Reflection, Run-Time Typing —objects in program memory with the ability to describe themselves in a programmatic way Code Generation —process of generating code for performing a specific task from a description/input file Self-Describing External Data Representation —external data representations (eg. file formats, on-wire data formats) which contain metadata which describes the data payload, etc.

- Athena Data Dictionary (28nov00 - SW CERN) Where is a Data Dictionary? The term data dictionary connotes a certain technical implementation which we do not (necessarily) advocate. IE. This term implies a central dictionary containing the information about those objects being described. Certainly, this is one possible implementation However, it is also possible (perhaps even desirable) that the information resides internal to the object (for example).

- Athena Data Dictionary (28nov00 - SW CERN) How is the DD Used? Data Tools Integration —Analysis tools, browsing tools Interactive Data Queries/Manipulation —Value display/manipulation Automatic/Semiautomatic Persistency —Generic converters for specific domains Schema Evolution (Version-Safe Persistency) Multi-Language Support —Inter-language data exchange & invocation Component Independence & Robustness —Insulation from on-going modifications Certainly others

- Athena Data Dictionary (28nov00 - SW CERN) Athena Dictionary Language C++ (headers) —Familiar, but complex and language specific DDL - Data Definition Language —Proprietary, no parser IDL - Interface Definition Language —Simple (too?) ISL - Interface Specification Language —Immature Java ODL - Object Definition Language —Virtually unused XML - Extensible Markup Language Other Languages / Home Grown Solution

- Athena Data Dictionary (28nov00 - SW CERN) Athena Dictionary Language Requirements: —One language for all ADL purposes Would like to work with Gaudi —Simple/familiar (subset) for typical Physicist —Freely available & supported parser front end should be real parser of full language —Good medium to long term prospects —Does not lock implementation/programming language choice (language independence) Multiple language bindings —Architecture/Platform independence —Extensible (subset) for future ADL evolution

- Athena Data Dictionary (28nov00 - SW CERN) Code Generation Code generation tools can be used to —eliminate tedious and error-prone rote programming, ease migration between technologies, generate templates & skeletons Std. 2-tier design  robustness & functionality —Single Compiler Front End (CFE) - AST —Multiple Compiler Back Ends (CBE) - Emitters Schema evolution should not require significant re- writes of user-written code using generated code.

- Athena Data Dictionary (28nov00 - SW CERN) Object Introspection also sometimes called "metadata" the ability of a class or instance to tell other parts of a program what it *has* or what it *does* at runtime some languages have rich notions of introspection —Smalltalk, Python, Java —XML (self-describing) allows sophisticated manipulation of objects without a-priori knowledge of object's class permits development of generic tools —object browsers, converters, data member accessors / mutators, method invocation (?), scripting interface —general & robust, but not as performant

- Athena Data Dictionary (28nov00 - SW CERN) Current Status Discussions within ATeam, others (ARC, LAPP) ongoing Starting the process of —defining scope —collecting requirements —writing use cases see LAPP use case  —evaluating languages —evaluating tools eg CFEs Writing white paper (Dec.) Need input, feedback, & coordination —eg DB, graphics

- Athena Data Dictionary (28nov00 - SW CERN) Implementation Strategy Because the Data Dictionary can be used for a wide variety of purposes, a strategic choice must be made for the implementation plan. The choice can be stated as: —Do we first implement only a single DD function (such as binding to a particular persistency service) as fully as possible? —Or do we first implement multiple DD functions (eg. multiple persistency services, multi- language support, binding to multiple general tools, etc) but with each one minimally functional? 1 er Option will provide most immediate user productivity, buy-in, & feedback —must not limit ADL or tools by choice

- Athena Data Dictionary (28nov00 - SW CERN) Architecture Milestones December 2000 —Data Dictionary strategy in place. A requirements document should be available, evaluations of possible technologies should have taken place and a strategy should be in place for a detailed design and implementation. ADL Language should be chosen April 2001 —Data Dictionary prototype ADL Language choice should be frozen September 2001 —Data Dictionary deployed