Linked by Thom Holwerda on Thu 6th Aug 2009 22:04 UTC
Microsoft Just when you thought the world couldn't get any crazier, something happens that makes you move your expectations of the world up a few nothces. We already have to deal with the browser ballot, but that's not the only ballot Microsoft will deliver. Hold on to your panties, as Microsoft will also offer a file format ballot in Microsoft Office 2010. On a happier note, Microsoft makes a whole load of promises to the EU about opening up technologies and file formats.
Thread beginning with comment 377605
To view parent comment, click here.
To read all comments associated with this story, please click here.
PlatformAgnostic
Member since:
2006-01-02

Currently-released forms of ODF simply do not support a number of things which are needed for Office features that already exist. There would be quite a big loss of functionality in the formulas space (as we have seen already) and in the change-tracking space (which we haven't seen yet).

Reply Parent Score: 1

lemur2 Member since:
2007-02-17

Currently-released forms of ODF simply do not support a number of things which are needed for Office features that already exist. There would be quite a big loss of functionality in the formulas space (as we have seen already) and in the change-tracking space (which we haven't seen yet).


The Office features are supported even at ODF 1.0 to the extent that several other independant Office suites are perfectly able to inetroperate.

How is it that only Microsoft's implementation of ODF 1.0 is not able to inetroperate?

There are at least two plugins for ODF, not written by Microsoft, that do an tremendously better job than Microsoft's own ODF 1.0 implementation.

BTW, most ODF-compliant products now implement OpenFormula, which is compatible with (but far more detailed than) the ODF 1.0 specification for formulas, and which is up for approval as part of ODF 1.2.

http://en.wikipedia.org/wiki/OpenFormula

If Microsoft were were in the process of implementing an ODF 1.0 capability for Office (which they were), and OpenFormula was already complete at the time (which it was), and Microsoft were sitting on the ODF committee (which they were) and fully aware of OpenFormula (which they were) ... then why would Microsoft go off and implement something totally incompatible with OpenFormula when they KNEW this was going to be fully specified in ODF 1.2?

Hmmm?

So much for Microsoft and "interoperabilty".

Reply Parent Score: 5

lemur2 Member since:
2007-02-17

There would be quite a big loss of functionality in the formulas space


The ODF "formulas namespace" is a good deal more capable and more correct than the MS Office formulas namespace.

http://en.wikipedia.org/wiki/OpenFormula#OpenFormula_attributes
Key attributes of the OpenFormula specification and development process, many of which are unique to OpenFormula as a recalculated formula format, are:

Developed by many different implementors. OpenFormula is being developed by representatives from many different implementors, working together, including OpenOffice.org and Sun StarOffice (Eike Rathke), KDE KOffice (David Faure and Tomas Mecir), Gnumeric (Dr. Andreas J. Guelzow and Jody Goldberg), IBM/Lotus 1-2-3 (Rob Weir), and wikiCalc (Dan Bricklin, co-creator of the spreadsheet).
Developed with experienced users. Many experienced users (such as Tom Metcalf, a scientist specializing in the astrophysics of the Sun) take part. The group includes several mathematicians, both users and developers.
Open development. The discussions of the group, and weekly drafts, are available to the public.
Fully open standard The specification meets all widely-accepted definitions of being an "open standard", including those by Bruce Perens and the European Union. For example, (1) both open source software and proprietary software can implement it, and (2) the work is based on consensus, not domination by any single supplier.
Implementors are already implementing it. Implementors have already made changes to their applications due to the work of this body, such as changing how they handle signed values in MOD, the association of exponentiation, and even implementing new functions to conform to the draft standard.
Focused development. The subcommittee is a large group focused specifically on spreadsheet formulas, and nothing else.
Not rushed. OpenFormula is based on specification work that was first released on 2005-02-26, as well as a large body of research into different applications.
Future-proofed format The syntax has been carefully designed to work indefinitely into the future. For example, it allows an arbitrary number of columns, while also allowing arbitrary names of values.
Embedded test cases. OpenFormula includes a large number of test cases, ones that test and demonstrate the specification including "edge cases" that people often forget. More importantly, they are specially formatted so they can be automatically extracted and placed in a test spreadsheet to test applications. Rob Weir reports that, "This gives us a self-testing specification, a great labor savings, as well as a demonstration of the innovative things you can do with ODF (OpenDocument format)."
Rigorous definitions The test cases (noted previously) help it be far more rigorous. In addition, OpenFormula defines the types for each function (as prototypes of each function). Function definitions are examined deeply, e.g., YEARFRAC() has subtle behavior in the leap years, which were carefully examined and defined.
Doesn't mandate mistakes. The specification is carefully written to not require certain bugs, just because someone has a bug. For example, Excel incorrectly believes that 1900 was a leap year, and at least draft version 1.3 of the Excel specification claims that compatible applications must make the same mistake, and requires that applications cannot be more capable than Excel by supporting dates before 1900. By comparing many different independent implementations, the OpenFormula group can often detect when an application makes a mistake, and ensure that applications are not overly restricted.
Innovations from many sources. OpenFormula covers the functions of Excel and OpenOffice.org, plus important functions not found in either one but instead found in other spreadsheet applications, such as Gnumeric and KSpread. For example, the specification includes the functions DECIMAL and BASE, which are much better ways to handle different bases than the old BIN2DEC (etc.) functions. It also includes bit operations like BITAND. These sources include Excel, OpenOffice.org Calc, Sun StarOffice Calc, KDE KOffice Kspread, GNOME Gnumeric, IBM/Lotus 1-2-3, Corel Word Perfect Suite Quattro Pro, wikiCalc, and DocumentToGo's SheetToGo. The subcommittee argues that by including the innovations from around the world of many different independent applications, they produce a better result that is far more inclusive.
Room for innovation by anyone. Application-specific "namespaces" are defined for functions. This allows spreadsheet applications to add new functions, without interfering with current standard functions, future standard functions, or functions defined by other applications. As a result, different applications can add new functions without interfering with others; once a consensus arises about the new function, it can be standardized. The namespace is based on the Internet's naming service (reversed domain names), so ORG.OPENOFFICE.STYLE would be an OpenOffice.org-unique function.
Internationalization. The specification does not assume that everyone uses "." as the decimal point, and indeed does not constrain user interfaces at all. Named expressions can have names in local character sets.
Subset support. Applications can implement a subset or superset. To prevent user confusion, various "groups" are defined so that users can request specific sets of capabilities.


Edited 2009-08-07 04:09 UTC

Reply Parent Score: 1

segedunum Member since:
2005-07-06

Currently-released forms of ODF simply do not support a number of things which are needed for Office features that already exist.

Then you add them. Seriously, ODF has had provision to add vendor or application specific extensions for ages. Either that or you can add it to the format specification. Throwing your arms up in the air is not a valid excuse, and in all honesty it's best to just keep your mouth shut, avoid spreading misinformation and concentrate on your own format if that's what you really want.

There would be quite a big loss of functionality in the formulas space (as we have seen already) and in the change-tracking space (which we haven't seen yet).

Absolute bollocks. I can't believe how often the supposed 'formula' issue has been discussed and debunked totally. I got tired of reading this MS oriented bullshit many years ago, and it doesn't seem to have subsided no matter how wrong it has been shown to be.

Reply Parent Score: 3

bert64 Member since:
2007-04-23

Currently-released forms of ODF simply do not support a number of things which are needed for Office features that already exist. There would be quite a big loss of functionality in the formulas space (as we have seen already) and in the change-tracking space (which we haven't seen yet).


Currently released forms of ODF support everything required by the companies who participated in the process...
MS were invited to participate, but refused and tried to completely ignore the process... The fact that the resulting spec doesn't support things in the way they want is hardly surprising.

In terms of formulas, the ODF spec as of version 1.1 does not specify how they should be stored, however all of the ODF supporting applications with the exception of MS (including the ms-sponsored plugins) managed to support the same interim syntax while waiting for the final spec in ODF 1.2. The fact that MS went and did something completely different shows arrogance, contempt for the idea of open formats, utter contempt for their customers and an obviously underhanded attempt to discredit the ODF format.

Reply Parent Score: 2