Describing the database

need differentiation beetween

connection-data
driver-settings
application-(level-)settings

Should be generic enough to later on perhaps cover connection to a single table (not only the whole DB)

also

query data (an SQL string, basically, to allow for invalid statements)
container of queries/forms/reports? Kexis does not seem to need this, but Base does

<connection-data>

describes a database type, and common settings (host, port) for how to connect to the data, and perhaps to some extent how to interpret this data

Kexi: need driver-name to point to the driver to use?

Base: need some abstract "database-type" (Base doesn't know "driver names") to internally match it to connection URL

Could Kexi also work with some abstract "database-type" and internally map it to a driver name?

Need to care for: Do we have enough connection settings which are self-contained enough to fully describe a database connection? For instance, if 98% of all connections need additional driver-level settings to really connect to the database (because without those additional settings, they would not have enough information), then fine-grained connection data would not make sense. In this case, we should resort to a concept like URI - basically a string which describes the connection, but is not further specified.

At the moment, I think this is not necessary, but we need to keep an eye on this.

As a fallback, we in every case need some generic mechanis. For instance, there are Base connections which cannot be described with "host/port/whatever" concrete settings: in reality, all connections which are based on ODBC, JDBC, and ADO fall into this category, since the application can by no means split the user-provided connection string into "host", "port" and so on. Thus Base needs a URI fallback.

Also, Kexi might in future have connections which cannot be described in terms of "host/port/whatever" (for instance the planned Kexi ODBC driver will probably be affected), so Kexi needs a fallback, too.

The fallback must probably be some generic string, no matter whether we call it URI or not :)

<driver-settings>

highly driver-dependent settings which do not describe how to connect to or interpret the data, but customize the specific driver used to access the database.

In my understanding, "first-row-is-header" would be a driver setting, since defines how a certain driver should interpret certain aspects of the database.

<application-settings>

Are there really (enough) settings which are generic enough to be shared between different applications, and thus worth standardizing? For instance, I would consider Base's "table-filter" and "table-type-filter" to be an application-level setting.

Other information

Other application-level settings in Base are on a per-object basis. For instance, the "db-filter-statement" attribute of a <db:table> element simply describes which filter the user (most recently) applied to the data view of the table, similar for the other attributes at the same element, and db:query attributes.

Where do we put those? They're not necessary for the connection, so they don't fit into <application-settings>. However I think they are part of the "potential feature intersection" of all applications supporting this format.

See also next chapter's "Design UI settings", especially the discussion on settings.xml vs. content.xml. In some sense, the settings are also application-level settings.

Issues/questions/catchwords

events - OASIS-OD already specifies a format for events bound somewhere. Naturally, Base could live with this format - could Kexi, too?
continuous forms
Design UI (such as position of table windows in a query design, or a relation layout) - where to be stored? Base currently uses a settings.xml, which in opposite to the content.xml content is not part of the original file format proposal. Should it be? The settings of the other applications (Zoom, Cursor position, and the like) are also not part of the spec.

Step 1 TODO

connection data can/should be split up into three different entities. For the third category (application-settings), it's not even clear if they should become part of the spec.
clarify connection-data fallbacks. I prefer URI, since it's a rather common concept for pointing to a unspecified resource
get rid of references to "package" in the spec, and use some more abstract descriptions
split up table information, which currently are a mix of different-level settings (cp. "Type Name" from DDL with "Visibility" from Application), into different entities, too
clarify if there are items in the current proposal which in real are highly specific application settings, and thus do not belong into the spec. Similar to what other OOo applications do in their settings.xml.

Future tasks

Following is what I propose to be a future task, addressed when above parts are done, in either the same or a later revision of the spec

definition of forms/reports

Form models are currently highly application-specific. Also, I am not sure how well formats currently used (Qt Designer) really fit - they seem to inherently contain concepts which, speaking strictly, are part of a specific application ("slots" etc.)

Also, for reports, I currently doubt that a language intended to describe dialogs (like Qt's UI description XML format) can really cover everything needed for report definition.

styles

Things such as application-wide or document-wide defaults for certain classes of objects (in text documents: e.g. paragraphs; in database documents: e.g. forms or controls) conceptually are "styles" in the other OASIS OpenDocument document types. We should point out functionality where usage of styles does make sense for databases, and define them appropriately.

Open Document For Databases