[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Re: OpenDocument format for databases
David, David Faure wrote: > Indeed the presence of db-java-classpath in the standard is problematic. > > Michael, can you add this item to the "Proposals under discussion" in the wiki? Sure. If have discussed this with Frank, and we actually believe it would be best to remove the entire attribute, because it is application if not even system specific. Instead, and application setting should be used. Michael > > On Tuesday 24 June 2008, you wrote: >> Hello, again. >> As you can see below I am referring to (very old) Frank's post. In 2005 we've >> worked on adding connection-data related elements to ODF 1.2 and the effect >> was very positive to me. >> At the time I criticized inclusion of java-dependent elements in the database >> parts of the ODF specs, that is now at the 1.2 draft 7 stage. >> >> Please take a look: >> >> Frank Schönheit - Sun Microsystems Germany said the following, On 2005-06-29 >> 16:30: >>> For instance, the java-driver-class is a driver-setting (which to me >>> also seemed to be a misunderstanding in [1]): The component which serves >>> “jdbc:” URLs (basically translating JDBC interfaces to OOo's API), uses >>> this setting to determine the Java class to load. For all other URI >>> schemes, and thus all other external database types, the attribute is >>> completely useless. Thus, it probably should have been in a >>> <driver-settings> or <connection-data> tag, or something like this .... >> Unfortunately in the draft there is mention of the java classpath (it was not >> there in draft 5). >> >> I'd like to also point out that there are many kinds of drivers with different >> APIs implemented in C, C++, Python, Ruby... and different sets of properties. >> If we wanted to include all of them, we'd get OOXML-like parts of ODF, >> designed to be usable for single vendor. >> >> My proposal is still to remove db-java-classpath from the standard. >> This element is implementation specific. Just like kde-driver or qt-driver - >> both (my examples) may have specific attributes - but we do not propose them >> for the standard. >> >> On the other hand, there is also no mention of ODBC driver settings, so I >> cannot see symmetry with JDBC. If we claim ODBC can be added by the >> implementors of ODF as extension, I believe the same can be said for JDBC. >> >> I am afraid otherwise there will be no single strong point against adding >> references to another implementation/vendor specific API like MS ADO drivers. >> >> Long ago I have mentioned the issue here >> http://www.kexi-project.org/wiki/wikiview/index.php%40OpenDocumentForDatabases.html >> >> -- >> regards / pozdrawiam, Jaroslaw Staniek >> Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on >> Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi) >> KDE Libraries for MS Windows (http://windows.kde.org) >> >> > > > -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]