[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] OpenDocument TC Meeting Minutes 2005-08-8
Hi all, I've uploaded a new version of the proposal: http://www.oasis-open.org/apps/org/workgroup/office/download.php/14134/05-06-03-proposal00050 The following has been changed. - The paramater name substition attribute and the auto increment element are now contained in the driver settings as suggested in item 1 of the list below. - There is now a specification for an exclude filter contained as suggested in item 2 of the list blow. Actually, two new elements have been added: <db:table-include-filter> and <db:table-exclude-filter>. Their content is a sequence of <db:table-filter-pattern> elements. - As suggested in item 3 of the list below, default values for columns are now specified using the office:value-type and and office:value attributes defined in the OpenDocument specification itself. For this purpose, the db:default-value attribuet has been replaced witha <db:default-value> element that has the office:value-type and office:value attributes. - The <db:table> element has been renamed to <db:table-presentation> as suggested in item 5 of the blow list. - The "nullable-unknown" value has been removed from the db:is-nullable attribute as suggested in item 7 below. - The <db:table-definition> element now has the name attributes specified in section 3.6. This has not been suggested so far, but Farnk Schönheit noticed that table definitions did not have a name during a rework of the proposal. Since item 4 did not require a change, the only which is left over from the list below is item 6. Best regards Michael Michael Brauer wrote: > Hi all, > > I've asked Frank Schönheit for a clarification of the open issues regarding > the database front end proposal > > Best regards > > Michael > > Lars Oppermann wrote: > >>Database Proposal >>----------------- >>1. Seperation of Driver/App-Settings should be kept. Driver parameters >>are relating directly to the way the datasource is accessed. Application >>parameters relate to how the data recieved from the driver is to be >>handled by the application > > > The following should be moved from "Application Connection Settings" to > "Driver Settings": > - Parameter Name Substitution > - Auto Increment (including its attributes) > > >>2. An exclude-pattern should be added to the table-filter. It should be >>evaluated after the include-pattern is processed and be applied to the >>result of the include-filter. >> >>3. db:default (default for column) >>should only be evaluated by the application, not by the driver. Should >>reuse value and valuetype fields. > > > Reusing the value/type attributes specified in section 6.7.1 is possible. > They specify more than what is needed, in particular, in the database > context there's no use for "currency", but can express everything what is > needed. > > >>4. String values for char-encoding >>needs to be clarified > > > The assumption made throughout the document is that the > only layer doing an encoding/decoding is the driver. The > db:character-set sriver setting specifies how a driver should translate > strings when passing from/to a non-unicode capable backend. This should > be applied to string default values, too. > > >>5. a better name for db:table is needed, since it is not a real table >>definition which it implies. > > > I'd prefer "table-presentation", to indicate that it describes how > the application presents the table/data to the user. "Table view" could > be confused with server-side views, and thus should be avoided. > > >>6. datatype mapping should be optional. defaults should be provided by >>the driver > > > The SQL data type specifies, if you want, a "type > class", while the internal data type (completely) specifies the real > data type. > > For example, MySQL has the following internal types which all have the > same SQL type (integer): "integer", "int", "mediumint", optionally > combined with "unsigned", and independently optionally combined with > "auto_increment". That is, "int unsigned auto_increment" is one of > 12(!) possible data types which all have the same SQL type "integer". > > If a mapping from either the SQL or the internal type or vice versa would be > specified within the driver settings, then the columns definition would, > whenever possible, only specify one of the two types. > > - Specifying the internal data type only would not be interchangeable between > different backends and would require an analysis of the driver settings to > actually get the SQL type. For this reason, specifying only the internal > data type seems not to be reasonable. > > - Specifying the SQL data type only allows interchangeability (in fact, > if a db:schema-definition would be applied to a backend different from > the one for which it was created, the backend-specific internal data > type would have to be ignored, anyway). But because there could be much > more internal data types than there are SQL data types, the default mapping > in the driver would only work in very few cases. This means that in most > situations, both data types have to be specified, and that the > default mapping specified in the driver settings has not much benefits. > > > >>7. since db:is-nullable is an optional attribute, the nullable-unknown >>value should be removed, since this is what is imlied by the attribute >>not being specified. >> > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Michael Brauer Phone: +49 40 23646 500 Technical Architect Software Engineering Fax: +49 40 23646 550 StarOffice Development Sun Microsystems GmbH Sachsenfeld 4 D-20097 Hamburg, Germany e-mail: michael.brauer@sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]