Group items matching

in title, tags, annotations or url

Well, if that's IBM's plan they're going to need more than ODF, that's for sure - and that brings us to the announcement I've been wondering about: IBM favors ODF as a file format because it is "truly open" and technically elegant, Heintzman said. But IBM will support Open XML, which is the current document format in Office 2007, in its Lotus collaboration and portal products. IBM already supports older versions of Office. I feel a Pamela Jones moment coming on .... there it is, as plain as day for the world to see, Doug Heintzman breaks through all IBM's doublespeak and hypocrisy and admits it. I don't know about "Beyond Office" as a plan, I think the real game here is "Beyond ODF"

# re: Office Open XML final draft!!! @ Wednesday, October 11, 2006 1:46 PM The past incarnations of DrawingML have been chaotic. It would be interesting, out of curiosity, to get an accurate history of what changed over time, perhaps to better understand what is supported in what. Here is my take, I am pretty sure I got at least 50% of it wrong :-) - pre-Windows 95 era, Word, Excel and Powerpoint use their own vector drawing layer used to draw shapes, pictures, diagrams, art and charts. Powerpoint, acquired by Microsoft in 1987, has by far the advanced drawing layer (bi-linear gradients, opacity, ...), codenamed Escher (in reference of the famous mathematician). - In Office 95, it is decided to reuse the Powerpoint vector graphics layer in Word and Excel. Migration begins. - Migration ends with Office 97 where both Word, Excel and Powerpoint use the same vector graphics layer, publicly known as MSO (mso97.dll) - In Office 2000, it's all craze about internet and Word tries to export WYSIWYG html. For that end, mark up extensions must be added to account for the MSO drawing layer. Hence the VML (Vector Markup language). Excel and Powerpoint don't support it. Internet Explorer natively supports VML (Internet Explorer's Direct animation vector drawing layer dismissed for performance reasons). - In Office XP, VML migration ends and both Word, Excel and Powerpoint support VML whenever a document is saved as a "Single web page archive" (.mhtml extension). - In Office 2003, nothing changes. - In Office 12, MSO gets rewritten with backwards compatibility in mind. The vector drawing layer uses more sophisticated drawing functionalities which makes it easier to draw themed, 3D realistic  objects. Technically, the differences are akin to the differences between GDI and GDI+. This new shared library is known as E2O and the corresponding mark up language is known as Drawing ML (Ecma TC45 specs). - In Office 14, ??? perhaps the drawing layer is rewritten, again, to 1) use WPF 2) to allow plugins, hence enabling much more sophisticated do-it-yourself scenarios. Use cases : custom charts ; BI analysis tools. Stephane Rodriguez

Blogosphere has been full of speculations about when and if ever Microsoft will support ISO/IEC 29500 format in MS Office. Some people believe and wish that OpenOffice.org with ISO/IEC 29500 support will be released earlier then MS Office. But don't get fooled, the first application conforming to ISO/IEC 29500 is out, it is neither MS Office nor OpenOffice.org, it is coming from Free Software Foundation and you can see screenshots here.

We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents.

here was strong consensus among Member State administrations on the necessity to use ODEF on "openness" being the basic criteria of ODEF and resulting requirements towards industry players / consequences for public administrations There is a general dissatisfaction with the perspective of having competing standards; One format for one purpose: Administrations should be able to standardize (internally) on a minimal set of formats; No incomplete implementations, no proprietary extensions; Products should support all relevant standards and standards used should be supported by multiple products; Conformance testing and document validation possibilities are needed -> in order to facilitate mapping / conversion; Handle the legacy / safeguard accessibility

This seems to me to be a turning point for the creation of global standards. Microsoft was invited to be part of the original ODF Technical Committee in OASIS, and chose to stand aside. That committee tried to do its best to make the standard work well with Office, but was naturally limited in that endeavor by Microsoft's unwillingness to cooperate. This, of course, made it easier for Microsoft to later claim a need for OOXML to be adopted as a standard, in order to "better serve its customers." The refusal by an incumbent to participate in an open standards process is certainly its right, but it is hardly conduct that should be rewarded by a global standards body charged with watching out for the best interests of all.

As far as I can tell in the Massachusetts poster-child case, ODF has simply come to mean whatever OpenOffice.org does

Hi Gary,I am a technology journalist with Asia's ONLY Linux-focused magazine, LINUX For You. I am working on a story revolving the recent development of Microsoft supporting ODF Format. I want to understand the equation of the whole development, would you please help me understand: Q1. What do you think drove Microsoft to support the ODF format?

With ISO/IEC having standardized Open Document Format (ODF) 1.0 and considering standardizing Ecma Office Open XML (Open XML), there is a lot of public discussion about document formats and whether the world should begin to focus on only one format or continue to see multiple formats developed and used over time. Microsoft believes that users should be able to choose among formats and pick the one that best meets their needs. We also believe in encouraging the continued evolution of computing and data formats. And we support the ratification of Open XML in ISO/IEC. There are several reasons for these views:

By Marbux posted Jun 19, 2007 - 3:16 PM Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy." I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not. I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification.

Summary of the Invention It is an. object of the present invention to provide a document processing system in which object-oriented frameworks are utilized to implement particular document processing techniques, including an object-oriented compound document system. These and other objects of the present invention are realized by a document framework which supports at the system level a variety of compound document processing functions. The framework provides system level support of collaboration, linking, eternal undo, and content based retrieval. These and other objects are carried out by system level support of document changes, annotation through model and linking, anchors, model hierarchies, enhanced copy and pasting, command objects, and a generic retrieval framework.

The decision to go with CDF has left some industry commentators scratching their heads, with arstechnica.com’s Ryan Paul noting that the decision is curious as CDF doesn't support “the full range of functionality required for office compatibility”. Paul does add, however, that the formats broad use of formats such as XHTML and SVG does give it a compelling edge.

Sorry Shish, you're wrong about ODF 1.2 Try ODF 1.5 or ODF 2.0, maybe. The metadata requirements for ODF 1.2 actually did include two way lossless translation capability. Unfortunately these features did not survive the final cut, and were not included in the April 2007 submission. You might also want to check the February 23, 2007 metadata proposal from Florian Reuter. That also would have delivered the goods and perhaps put ODF that grand convergence category of usefulness across desktops, servers, devices and web systems currently the exclusive domains of MS-OOXML and CDF+. Florian had devised a means of using metadata to describe the presentation aspects of content and structural objects. Very revolutionary. And based on the simple notion that bold, font, margins etc. are simply metadata about content and style objects. Where the train came off the track had to do with the concept of an XML ID means of linking metadata to content. Not that there was anything wrong with this mechanism. It's actually quite clever. What went wrong was that Sun insisted that only those elements approved and supported by OpenOffice would be allowed to make use of XML ID metadata. For independent developers, this is a serious constraint. Because of this constraint, the metatdata sub committee started off with six elements supported by OOo that metadata could be appied to. IBM then came in and asked for eleven more elements having to do with charts and graphs. The OpenOffice crew decided they could support this, so in they went. Then an interesting question was posed, "How are independent developers supposed to submit elements for metadata consideration?"

Sorry Shish, you're wrong about ODF 1.2 Try ODF 1.5 or ODF 2.0, maybe. The metadata requirements for ODF 1.2 actually did include two way lossless translation capability. Unfortunately these features did not survive the final cut, and were not included in the April 2007 submission. You might also want to check the February 23, 2007 metadata proposal from Florian Reuter. That also would have delivered the goods and perhaps put ODF that grand convergence category of usefulness across desktops, servers, devices and web systems currently the exclusive domains of MS-OOXML and CDF+. Florian had devised a means of using metadata to describe the presentation aspects of content and structural objects. Very revolutionary. And based on the simple notion that bold, font, margins etc. are simply metadata about content and style objects. Where the train came off the track had to do with the concept of an XML ID means of linking metadata to content. Not that there was anything wrong with this mechanism. It's actually quite clever. What went wrong was that Sun insisted that only those elements approved and supported by OpenOffice would be allowed to make use of XML ID metadata. For independent developers, this is a serious constraint. Because of this constraint, the metatdata sub committee started off with six elements supported by OOo that metadata could be appied to. IBM then came in and asked for eleven more elements having to do with charts and graphs. The OpenOffice crew decided they could support this, so in they went. Then an interesting question was posed, "How are independent developers supposed to submit elements for metadata consideration?"

Oh, my. Both IBM and Sun voted for the proposal that broke the Foundation's plugin that was going to add full-fidelity native ODF file support to Microsoft Office. So it's sounding to me like at least two of the TC members who voted for the Sun/KOffice proposal didn't check in with the ECIS lawyer before they broke interoperability with Microsoft Office. Do you think Microsoft won't use this evidence in the DG Competition antitrust proceeding, Michael? Let's see, you guys are prosecuting Microsoft for not supporting ODF in Microsoft Office while you block Microsoft Office from supporting ODF. Yeah, I think DG Competition is going to hear about this one from Microsoft. They'll probably hear about what you said about compatibility being a trade off too. Oh, yeah. Microsoft's lawyers are going to love this. Look at the ECIS public statement about interoperability's importance.

Regarding section 1.5 itself: The Open Office TC decided to use the term MAY rather than MUST (or will) at the mentioned location, because it wanted to ensure that the OpenDocument specification can be used by as many implementations as possible. This means that the format should also be usable by applications that only support a very small subset of the specification, as long as the information that these applications store can be represented using the OpenDocument format. A requirement that all foreign elements and attributes must be preserved actually would mean that some applications may not use the format, although the format itself would be suitable. Therefor, we leave it up to the implementations, which elements and attributes of the specification they support, and whether they preserve foreign element and attributes. Some more information about this can be found in appendix D of the specification.