|Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact|
|Full name||OpenDocument Database Front End Document Format (ODB), Version 1.2. Part of OASIS Open Document Format for Office Applications, Version 1.2 and the equivalent ISO 26300-1:2015.|
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:
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.database". 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.database"; ./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.
|Production phase||Can be used in any production phase as an operational system, rather than as a publication that has a final state.|
|Relationship to other formats|
|Subtype of||ODF_Family, OpenDocument Format (ODF) Family, OASIS and ISO/IEC 26300|
|Used by||ODF_spreadsheet_1_2, OpenDocument Spreadsheet Document Format (ODS), Version 1.2, ISO 26300:2015|
|Used by||Other ODF document categories.|
|Subtype of||ODF_package_1_2, OpenDocument Package Format, ODF 1.2, ISO 26300-3:2015|
|Subtype of||ZIP_6_2_0, ZIP File Format, Version 6.2.0 (PKWARE). Various features of the ZIP File Format are not permitted in ODF.|
|Contains||META-INF/manifest.xml file. This manifest file is mandatory in all ODF packages.|
|Defined via||XML_1_0, XML (Extensible Markup Language) 1.0. A normative RELAX NG schema is part of the specification for ODF 1.2, which includes the specification for database front end documents.|
|LC experience or existing holdings|
|Disclosure||International open standard. Developed and maintained by OASIS Open Document Format for Office Applications (OpenDocument) TC as part of the OpenDocument Format (ODF) 1.2 specification published by OASIS in 2011. Also approved as part of the equivalent ISO/IEC 26300-1:2015 by ISO/IEC JTC1/SC34.|
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 individiduals or organizations they serve.
|Licensing and patents||No concerns. See ODF_Family.|
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:
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.
|Technical protection considerations||Encryption is supported for files within an ODF 1.2 package. In addition, an ODF package file may be encrypted during interchange or as part of DRM controlling distribution.|
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.
|Support for software interfaces (APIs, etc.)||ODF_dbfront_1_2 is a front end to a database structured in some other format. In the long term, support for access to the data itself is likely to be better facilitated by direct access to the source database, perhaps using SQL. The sources that support SQL may be susceptible to use of SIARD for archiving.|
|Data documentation (quality, provenance, etc.)||ODF 1.2 packages have no specific support for rich discipline-specific metadata or codebooks in externally specified schemas. See Self-documentation in Sustainability Factors above.|
||.odb is the extension used for an ODF database front end file.|
|Internet Media Type||application/vnd.oasis.opendocument.database
|Magic numbers||See note.||Magic numbers that apply to ODF document category subtypes incorporate the magic number for ZIP_PK, the string mimetype at position 30, and the MIME subtype string value at position 38.|
|Indicator for profile, level, version, etc.||ASCII: office:version="1.2"
||The four root elements used in the primary files in an ODF package all require an attribute that records the ODF version. This is the signifier that distinguishes ODF 1.2 packages from earlier versions. Documents without this attribute are assumed to be from version 1.1 or earlier.|
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.