Sustainability of Digital Formats: Planning for Library of Congress Collections

The OpenDocument Database Front End Document Format (ODB), Version 1.2 (given the short name ODF_dbfront_1_2 here) is a format for editable documents that are front ends to databases, which may be local or remote, stored as a file or accessed through a database server. It is one of several subtypes in the ODF family for particular content categories. This description relates to part 1 of the ODF 1.2 specification as published by OASIS and the equivalent ISO/IEC 26300-1:2015 specification. The standard specifies markup for database front ends. Such database objects may be embedded into ODF documents of other categories. The standard also allows for free-standing database front end documents with the file extension .odb.

The primary ODF markup used for database front ends is specified in the db: namespace, with the <office:database> element as a container for a database front end. This <office:database> element may contain the following elements in the db: namespace:

• <db:data-source>, which contains elements that define whether the database is in a file or accessible via a database server and how to make a connection.
• <db:forms>
• <db:queries>
• <db:reports>
• <db:schema-definition>
• <db:table-representation>

The data may be stored in the document, or retrieved by reference to another source. According to the Frugal Computer Guy, "LibreOffice Base is a front end database manager that can be used to create forms and reports from a variety of databases including MySql as well as others. LibreOffice Base can be used to create small embedded databases when used with Java-based HSQLDB as its storage engine (The LibreOfice Base default database). This makes LibreOffice Base appear as if it were a database manager and the database, but it is not. LibreOffice Base is just the front end allowing us to tie into the actual database." According to LibreOffice Base Handbook: Accessing external databases, external databases supported by that software include: dBase, MySQL, Oracle (using JDBC), PostgreSQL, and other databases accessible using ODBC and JDBC query processors. The external databases supported by any application that supports ODF_dbfront_1_2 will be application-dependent.

The ODF specification covers two physical forms for ODF documents, a flat form as a single XML file and a package form based on the ZIP_6_2_0 format. This description focuses on the more commonly used ZIP-based package format for ODF database front end files, given the .odb file extension.

An ODF package can be recognized as a database front end document in several ways. Externally, there is the .odb file extension. The primary internal indication is that the mandatory file named mimetype will contain the string "application/vnd.oasis.opendocument.base". An additional way to recognize an ODF database front end document is that the <office:body> element, a child of the root <office:document-content> element in content.xml has the child element <office:database>.

See Notes in ODF Family for more information about the flat XML-only variant of ODF files. For a flat ODF database front end file, the root <office:document> element has an office:mimetype attribute with the value indicated above.

For details of the ZIP-based package for ODF_dbfront_1_2, see ODF_package_1_2. The typical files for a minimal database front end document include: mimetype (one-line file containing only the string "application/vnd.oasis.opendocument.base"; ./META-INF/manifest.xml (package manifest); content.xml (database front end content); styles.xml (display formatting). The package specification defines the form for the package manifest, and options for digital signatures, encryption, etc.

Specifications from OASIS: Open Document Format for Office Applications (OpenDocument) Version 1.2. Specification for ODF 1.2 database front end documents are found primarily in Chapter 12 (Database Front-end Document Content) and section 7.6 (Database Fields) of Part 1 of the specification. Since visual interfaces for databases are likely to be based on tables, chapter 9 is also relevant. The technical specification is part of a normative RNG schema for primary component files for ODF documents..

The identical specification is published as ISO/IEC 26300-1:2015, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.2 Part 1: OpenDocument Schema.

The ODF 1.2 specification is divided into three parts, with the bulk of the markup specification in Part 1: OpenDocument Schema. The package specification is in Part 3: Packages.

See ODF_Family for a listing of namespaces that can be incorporated into any ODF 1.1 or ODF 1.2 document and links to associated specifications.

The compilers of this resource have found no specific evidence of widespread adoption of this category of ODF file. It is likely used primarily by individuals or organizations that have chosen to use an ODF-based office suite of software, such as Libre Office. Comments welcome.

Database applications will usually be chosen for features, functionality, or compatibility/familiarity -- and not for the underlying format. For example, Battle of the Office Suites: Microsoft Office and LibreOffice Compared points out that "LibreOffice is compatible with a lot more systems, including Windows, OS X, and Linux," while Microsoft Access is limited to Windows. The same article states, "Base has fantastic integration with MySQL, PostgreSQL, and Thunderbird, whereas Access integrates better with Outlook and Paradox."

See ODF-Family for more detail on adoption of ODF in general, and particularly for mandates or recommendations for ODF when exchanging editable documents among government agencies and the individuals or organizations they serve.

The structure and text of an ODB file are represented in XML and hence viewable without special tools, although XML-aware tools that can show the element hierarchy make viewing and interpretation more convenient. The most commonly used parts, elements, and attributes have recognizable names. Simple documents can be interpreted with very basic tools. However, interpreting the semantics of some elements and the correspondence of some elements and attributes to database terminology or functionality will require not only understanding of the schema and the specification text, but familiarity with the associated terminology and functionality.

As for other members of the ODF 1.2 family, ODF_dbfront_1_2 has support for metadata based on RDF (W3C's Resource Description Framework). As well as using RDF for metadata for the document package as a whole, RDF can be attached to elements within the document's content.

Pre-defined metadata elements for the document as a whole, stored in an <office:meta> element include:

• From the Dublin core namespace, using the dc: prefix: Title, Creator (of most recent modification), Description, Subject, Date (last modified), Language
• From the ODF specification, using the meta: prefix: Generator (creating software application), Keywords, Initial Creator, Creation Date and Time, Modification Date and Time, Print Date and Time, Document Template, Document Statistics (word count, page count, etc.),

The pre-defined elements are all optional and repeatable. However, applications are not required to update multiple occurrences in a specific way to reflect modifications to a document.

Also supported in ODF 1.2 is an XML structure for user-defined metadata, based on triplets of name, data type, and value.

Depends on features used. An ODF_dbfront_1_2 database front end often relies on externally stored data or SQL access to a remote database.

Since ODF_dbfront_1_2 is a front end to a database structured in some other format or by an independent application, the available data types are controlled by that format or application. For example, numeric data types supported by the HSQLDB engine (integrated into Libre Office as the default for embedded databases) are: Tiny integer, Small integer, Integer, Big integer; Decimal and Numeric (both with accuracy to 50 decimal places); Real; and Double precision.

This category of ODF document was introduced in ODF 1.2. See ODF_family for more on the history ODF in general.

ODF 1.3 was approved as an OASIS Committee Specification in December 2020, according to a December 4, 2020 announcement. This followed several periods of public review in 2019 and 2020. The next stage in the multi-step OASIS process is to gather three "statements of use", written statements that a party has successfully used or implemented the specification. See Approval of an OASIS Standard.

The specification for ODF 1.3 has been re-organized into four Parts. Part 1 is a brief introduction; Part 2 is the Packages specification; Part 3 defines the OpenDocument Schema, which includes specifications for the ODF content subtypes, including the database front end namespace; and Part 4 defines the Recalculated Formula (OpenFormula) Format. The database front end specification is in clause 12 of ODF 1.3, Part 3. According to the change log in Appendix G of ODF 1.3, Part 3, there were no changes in database front end markup from ODF 1.2. Comments welcome.