OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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]