Home
Gary Edwards's Library tagged → View Popular
ODF and OOXML must converge!! AFNOR, the French Standards Body, announces proposals for revisable office document formats
-
AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.
-
Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years.
Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.
Denmark: OOXML vote won't affect public sector. ODF is too costly! | InfoWorld
-
Lebech said Denmark considers OOXML an open standard, regardless whether it is approved by the ISO. "It would be impossible
for us to use only ISO standards if we want to fulfill the goal of creating interoperability in the government sector," he
said.
The Danish Parliament also mandated that public agencies consider the cost of using open formats. One of the main reasons
OOXML was included is because Denmark is heavily dependent on document management systems that are integrated with Microsoft's
Office products, Lebech said.
Denmark also found that requiring agencies to only use ODF would have been too expensive, mostly because of the cost of converting
documents into ODF, Lebech said.
"We wouldn't have been able to only support ODF," Lebech said. "It wouldn't have been cost neutral."
ODF infighting could help Microsoft's OOXML - zdnet Mary Jo
-
Hey, great comments!
- garyedwards on 2007-10-29
-
As a result of the latest infighting, is Microsoft now all-but-guaranteed that OOXML will sail through the ISO standardization vote in Feburary 2008 because ODF — and its backers — will be in disarray? This has nothing to do with the outcome of the Ballot Resolution Meeting.
-
But we also oppose adoption of ODF 1.2 as an ISO standard in the form we expect it to emerge from OASIS.
- 1 more annotations...
In Office SP2, Microsoft manages to reduce interoperability | TalkBack on ZDNet
<b>ODF is important. So What Went Wrong?</b>
Response to Jeremy Allison:
Having participated in a number of government
pilot studies, I must say that you are right;
government officials do care about ODF. They
really want it to work. But they also had
expectations that ODF simply wasn't designed
for.
What they expected ODF to be was an open
technology based on highly-structured XML
markup that was application, platform, and
vendor-independent, backward compatible,
universally interoperable, and importantly, Web
ready.
That is not ODF nor is it OOXML. In fact, the
closest thing we have for meeting these
expectations is an ajax-webkit style
HTML+ (HTML5, CSS4, SVG/Canvas, JS
jQuery, etc.). ODF is highly structured, but it
is not application-independent. .....
Document Interoperability Initiative Demonstrates Momentum and Results: Industry collaboration leads to new interoperability solutions that deliver customer choice by improving how documents work across platforms.
Through the Document Interoperability Initiative (DII) global forums, technology leaders have been working together to promote interoperability between different document format implementations to provide greater value and choice to customers, and the events — including one held in Belgium this week — are yielding practical results.
Interoperability solutions announced today translate Open XML documents to a Web page (HTML) allowing readability on Web-friendly browsers such as Firefox, improve translations between different formats through optimized templates, and enable features that provide greater choice for customers and opportunities for independent software developers as they create and use business applications built on Java that manipulate business documents. At the DII events, discussions were also held about developing document test libraries and schema validators, and vendors had the opportunity to test their implementations of document formats in a lab environment to identify potential issues to be addressed.
Microsoft OOXML viewers, translators, SDK to help interop with Firefox and OpenOffice?
On Dec 3, Microsoft officially announced the availability of its Open XML Document Viewer, Open XML/ODF Translators Version 2.5 and the Apache POI Java SDKfor OpenXML.
OOXML is defective by design: Microsoft latest bullshit : native support of ODF in Office 2007
Stephane is right on target. This is a must read for anyone trying to understand ISO approval of OOXML, and the sudden change of mind at Microsoft to support ODF!
-
Hi Jesper,
OpenOffice.org has an internal layout engine with an implementation model very different from that of the MSOffice editors. The differentials of internal representation of basic document structures is very problematic to roundtrip conversion processes. ODF is an XML encoding of the OpenOffice internal representation, sometimes called the "binary dump" or in-memory-binary-representation. OOXML is similarly an XML encoding of the MSOffice internal representation.
The layout engine differences (internal representation) results in serious incompatibilities at level of file format "presentation" layers. While it's easy to exchange "content", "presentation" is impossibly application specific.
Given enough time, one would hope that the entire presentation layer of OpenOffice-ODF could be fully described in terms of both syntax and semantics. After five years and a half years of work, ODF has not made much progress in this area. Once the presentation semantics are fully documented, the plan was to then "neutralize" the application specific aspects with more generic representations.
If you go back to January 2003, you'll find in the eMail archives of the OASIS ODF TC some remarkable discussions concerning proposals to throw out the OpenOffice XML submission, and start from scratch with an entirely application independent specification. This was suggested by Phil Boutros (Stellent), and supported by Corel, Boeing, ArborText, and SpeedLegal (Jason Harrop). In the end however, Sun prevailed with the promise that the obviously application specific aspects of ODF would be fully documented and neutralized. Sadly this has yet to happen. Worse, the OASIS routine of highjacking W3C namespaces further confuses things since these application specific implementations are similarly undocumented.
IMHO i believe there is a solution to this mess. But it's not going to be what most expect; the harmonizing of ODF and OOXML. That isn't going to work - ever! For harmonization to work, one would have to harmonize OpenOffice and MSOffice by rebuilding the aging layout engines. And that isn't going to happen.
A more reasonable approach would be to target an application independent format that is entirely neutral. The truth is that you can not ask an established application (layout engine and feature set) to implement another applications internal representation model. What you can do though is target a neutral format that is flexible and generic at the document structure level.
My favorite "neutral" format is the WebKit document model. The primary reason is that it's "web-ready". Who in their right minds would today target any document format not "web-ready"? Yet that's what we did with ODF.
I fully believe it is possible to set up round trip conversions from both OpenOffice and MSOffice to the advanced but highly interoperable WebKit flow document model. Don't even try to re invent the layout engines of legacy applications. Set as your target a neutral, application independent format that is Web-ready" and useful across the widest span of devices, desktop, and web application and service systems. Then never look back.
I hope you will consider joining marbux and i over at the Diigo "Future of the Web" group. Your contributions would be much appreciated. Besides, all my blogging is there :)
One last point; i did get your eMail concerning RelaxNG. But it took some time. I had lost my openstack.us domain for some 90 days. When i finally got it reinstated, a ton of eMails showed up. My apologies. But you are absolutely right in your assesment. I have asked Florian and Marbux to confirm this and perhaps explain how this came to be. The issue is once again that of Sun highjacking namespaces and committing two applications specific crimes in the process. The first fault is that the implementation of the digital signature standard is limited to exactly what OpenOffice chooses to implement. The second fault is that the OpenOffice limited implementation is nowhere documented!
The highjacking of namespaces really came to head in the metadata subcommittee where the OpenDocument Foundation had successfully inserted into the requirements document a model for using RDF to describe in a very neutral and generic way all of the problematic presentation aspects. Meaning, we believed that format and styling information is simply object metadata. We really thoguht we could neutralize the application specific problems of ODF using a metadata approach. Sun however had different ideas. They ended up convincing IBM and Patrick Durusau to limit the use of XML ID to only those elements approved and implemented in OpenOffice. Once this monstrous example of application specific crap was approved by the OASIS TC, i quit ODf.
Hope all is well,
~ge~ - garyedwards on 2008-06-25
-
I wanted to post a quick reaction to the latest Microsoft bullshit announcement, in which they reportedly plan to "add native support for ODF 1.1". The way they put is very succinct, intentionally probably, and it opens the door for wild guesses.
First of all, Microsoft is a huge Office licensing monopoly. It's so big it even surpasses Windows in sales. Any decline in Office licensing would be dramatic for Microsoft's future. With that alone, you know that any announcement from Microsoft that they are willing to interoperate with other people's software, namely applications, should be taken with a grain of salt.
Here is how, with the release of Office 2007, Microsoft intends to keep their monopoly in Office licensing :
OOXML is defective by design: Follow up on Microsoft latest bullshit announcement
Stephane Rodriquez sums it up: Microsoft has won ...
"Future of OOXML? There are two answers. Frankly, who freaking cares the paper? This paper will ALWAYS be at odds with the actual Office implementation. We have a good example for the time being, but it has always been the case. What about the actual file format then? It will be the subject of reverse engineering from implementers whose only recourse is to catch up all the undocumented stuff. Make no mistake though, now it's about applications, not documents anymore."
"Conclusion : if you are still in the OOXML conspiracy game, about time to move on guys. "
-
Microsoft has won. They wanted the ISO timestamp. They got it. They needed it since governments (and the EU) want such thing for documents now.
IDABC - EU: Microsoft's ODF-support draws mixed reactions
This is nonsense. Whether an organizations standardizes on ODF or OOXML, the "interoperability" they seek will still be based on every desktop running the same application. Neither format enables the interchange of documents between different applications - even if those applications properly implement the format standard. Anyone can prove this for themselves. Simply shuttle a few OpenOffice ODF documents between Symphony, Novell Office and Google Docs. Then weep. At least with MSOffice-OOXMLyou can exchange documents between different versions of MSOffice. Even though OpenOffice, Symphony and Novell Office are based on the same code base, interop might as well be zero.
Besides; what end users really want from a modern desktop office suite is collaborative editing of web ready documents. This discussion is so last century - 1995!
-
Greve told the BBC that genuine adoption of ODF would give consumers more choice. "People will no longer need to use Microsoft Office in order to interoperate. People could switch to GNU/Linux and choose OpenOffice or other applications that support ODF, like Lotus Symphony or Google Docs."
The Fall of Microsoft Office
More confusion about the MS announcement of native support for ODF, with delayed support for whatever ISO finally determines to be ISO 29500; "OOXML". Damn but these guys are all twisted up about this. The truth is, ISO National Bodies traded their vote in favor of OOXML for MSOffice support for ODF and Microsoft's joining the OASIS ODF TC. It's not complicated. MS wants ISO approval of OOXML because it established MSOffice as a "standards" editor. The rest of this kurfufull is all about anti trust concerns and Microsoft's need to put htose concerns to bed before the world figures out that they are leveraging the MS desktop monopoly into an MS Web monopoly. ISO approval of OOXML is the final piece of very complex puzzle.
The harmonization of OOXML-ODF is impossible. MS knows this. So why not join OASIS ODF TC if it means putting aside the anti trust claims from ISO NB's and getting that all important standardization of OOXML? Both ODF and OOXML are both XML encodings of entirely application specific binary formats. There is no possible to way to reconcile the file formats without also reconciling the applications! Incuding feature sets and layout engines!!!! Impossible!!
The real game is the transition from client/server to the emerging client/Web-Stack/server model. MS is the "client" in client/server. No way were they about to give that up without a plan to control the transition of MSOffice documents to the emerging client/Web-Stack/server model. They sought to fully control the formats, protocols and API's of this new model. ISO handed it to them.
The thing to watch is the MSOffice SDK where one can find a very cool OOXML <> XAML converter. XAML is totally proprietary, but "web ready". Meaning, MSOffice is a "web ready" application. It's just that the web readiness is 100% MS .NET-Silverlight.
The great transition to client/Web-Stack/server is now on. Thanks to ISO. All this ODF stuff is just background noise designed to quiet the anti trust crowd. Despicable, but well done.
~ge~
-
On the same day that the state of New York published a report supporting open formats for electronic documents, mighty Microsoft (Nasdaq: MSFT) said that it would support the open-source ODF format in Office 2007. Redmond's own Open Office XML specification may be heading for the great Recycle Bin in the sky, never to come back.
-
Add Sticky Note
- UH? When is this going to happen? How is it that OpenOffice, Google Docs and Zoho enter an existing MSOffice business workgroup? Where are the conversions of scripts, macros, OLE, security settings, data and media bindings? That's right. They are no where to be found. Which means that these application interlopers have no means of entering an existing MSOffice anchored workgroup, workflow or business process.
- on 2008-05-29
- UH? When is this going to happen? How is it that OpenOffice, Google Docs and Zoho enter an existing MSOffice business workgroup? Where are the conversions of scripts, macros, OLE, security settings, data and media bindings? That's right. They are no where to be found. Which means that these application interlopers have no means of entering an existing MSOffice anchored workgroup, workflow or business process.
- 1 more annotations...
Office 2007 won't support ISO's OOXML - SD Times On The Web
Microsoft to support PDF, ODF 1.1 and ISO OOXML in MSOffice 14. The company will also join the OASIS ODF TC and working group for ISO PDF.
-
In a surprise move, the company also announced that it intends to participate in the OASIS ODF working group and the corresponding ISO/IEC Joint Technical Committee 1 Subcommittee 34 working groups for ODF, as well as the ISO Technical Committee 171 working group for PDF, said Doug Mahugh, senior product manager for Microsoft Office.
He added that Microsoft would also introduce an API to allow developers to plug their own converters for formats, such as ODF, into Office to make it the default conversion path. ODF 1.1 was chosen over the ISO-standard ODF 1.0 as a practical decision based upon interoperability with existing implementations, Mahugh explained. -
Add Sticky Note“Customers that are expecting true document fidelity from XML-based, ISO-standard document formats will continue to be disappointed,” said Michael Silver, a Gartner Research vice president. Silver observed that the most compatible formats to use today are Microsoft’s legacy binaries, and he believes that Microsoft will be unlikely to convince customers to move to OOXML in the foreseeable future.
- The real work of ISO JTCS-34 is that of coming up with a standardized presentation model for OOXML and ODF. This is the only way they will ever get the interop fidelity end users expect from standardized formats. CSS and XSL:FO are primary candidates for building a highly portable "presentation" model. - on 2008-05-21
ConsortiumInfo.org - Standards to the People! (Updated Twice)
Strange demands from Andy Updegrove: "I call on Ecma to withdraw OOXML from ISO and keep control of it themselves. We need it for legacy documents...."
Why would anyone want Ecma to take back control of MSOffice-OOXML from ISO? The best circumstance would be for OASIS to turn OpenOffice-ODF over to the same ISO JTC-S1, where they can finally begin the difficult (if not impossible) harmonization process. Let me add on other thing; the place for ISO to begin harmonization is "presentation". We desperately need a standardized presentation model useful to MSOffice-OOXML, OpenOffice-ODF, XHTML and HTML. I suggest they start with CSS 3, and work back into ODF - OOXML. But that's just me :)
-
I call on Ecma to withdraw OOXML from ISO and keep control of it themselves. We need it for legacy documents.
Griffin Brown Weblog - ODF validation for the cognoscenti
Rob Weir gets royally spanked. And so does the notion that ODF is somehow "interoperable". Big Time.
-
Just when it seemed like nobody was interested in the ODF conformance smoke test posted a few days ago, IBM's Rob Weir weighs in with a lengthy piece in response.
OOXML: The next step - Interop at the International Standards legal level | Marbux - Weir - Ian [odf-discuss]
Marbux at his best! Here he responds to Rob Weir's ODF v 1.2 arguments with a legal dissertation on International Standards, ISO, the WTO, and the key issue of interoperability and what it must mean. Excellent!
-
Both ODF and OOXML are only one WTO Dispute Resolution Process complaint
away from losing their international standard, national technical
regulation, and government procurement specification status. They do not
meet the minimum requirements of international law. Both are unnecessary
obstacles to international trade; neither specify a uniform and
substitutable product. That does not sound like a sound business plan to me.
So I return to my question posed in an earlier post: Will ODF v. 1.2 under
your leadership attempt to "clearly and unambiguously specify that
conformance requirements essential to achieve the interoperability" and will
the standards-based interoperability between *different* IT systems be
"demonstrable," as required by JTC 1 Directives?
That is not a complicated question and it requires no deep dive into
international law to answer. International law requires what the quoted JTC
1 Directives require in this regard, but for purposes of the point under
discussion we need go no further than the Directives' plain language.
One either adheres to the rules or one forfeits the moral high ground to
complain when others ignore the rules. Where does Rob Weir stand on
complying with the rules?
OOXML and ODF: The next step | [odf-discuss] Marbux Responds!
Excellent legal argument by the legendary marbux concerning OOXML and ODF itneroperability. Covers ISO Interop Requirements and the demands of International Trade Agreements. Key to this thread is ODF v 1.2 and what must be done to bring ODF into legal compliance with International demands.
-
The issue we were discussing -- and what I believe the ODEF conference was
very much concerned with -- was whether ODF plus vendor-specific extensions
will be classified as conformant ODF. The market requirement is for
"Exchange Formats" and document-level interoperability.
I could repose my question as whether ODF v. 1.2 will "clearly and
unambiguously specify interoperability requirements essential to achieve the
interoperability," as required by JTC 1 Directives. As you noted in an
earlier post in this thread, you can't do interoperability if you use vendor
extensions.
> I see a standard as providing a shared vocabulary for buyers and sellers
> to express their requirements.
You are in error. This is a matter controlled by law rather than by personal
opinion. Standards are all about the substitutability of goods, weights, and
measures. A standard specifies all characteristics of a product, weight, or
measure in mandatory terms so there is uniformity. Standards are the
antithesis of product differentiation. Their very purpose is to eliminate
product differentiation.
OOXML OPS and the GPL: A disappointing surprise from the SFLC | Gray Matter
Scott B comment on the OOXML OPS and GPL controversy. Great comments from Bruce Perens also.
-
I view the spec as confusing, obtuse, error-ridden, x86-centric, incomplete, and redundant. Microsoft sat on the board of ODF for _years_ without offering any help on the minor items ODF didn't provide that they wanted. Now that governments start pressing for permanent standards on document storage, MS throws out this half-baked item and expects a reward for good behavior. Maybe somebody on the board of directors at our company likes it, but the technical folks having to add more work are less than happy about this beast.
If they had to go with XML, couldn't they at least have allowed standard XML with attributes and the like instead of x86 specific, binary incompatible, past-version deprecating, standard-avoiding, crash on normal XML.. ... mess... that they have offered for consumption? Oh.. but wait, I'm sure the BRM fixed that in the week given. I'm sure the pretty version will show up any day now.
OOXML and ISO: The Process Challenge - A Predictable Path | Matusow's Blog
Scott B responds to Matusow blathering with a list of ISO changes that should be made given the OOXML fiasco, but won't.
-
Where can we expect challenges?
OOXML: MSOffice Open XML - Where The Rubber Meets The Road | Matusow's Blog
Perhaps the single best comment i've ever read concerning OOXML and the value of standards. Very concise and too the point. Thanks you Scott B!
-
There can be no doubt that OOXML, as a standard, has severe flaws. It is incomplete, platform specific, application specific, full of contradictions, fails to adhere to existing standards, untestable, and presents a moving target for any IT worker. There is not an organization in existence, including Microsoft, that promises to actually implement the full standard. Much of this is due to the fact the final version doesn't actually exist on paper yet, but a large fraction is also do to the patchwork nature of the product.
The reason governments and companies wanted a 'office apps' standard in the first place was to release an avalanche of data from aging applications. OOXML shows every appearance of being created to prevent this escape, not enable it. The immaturity of the standard means that it remains a gamble to see if older documents will remain readable or not. The lack of testing means there is no way to determine what docs actually adhere to it or not. The ignoring of existing standards guarantees compatibility problems. All of these factors are handy for the owner of the biggest share of existing documents, as it forces users to continue to use only _their_ application or risk danger from every other quarter.
Microsoft's Great Besmirching | Linux Journal
Glyn Moody provides a summary of the destruction of ISO
-
Of course, all companies try to bend the rules in the their favour, and it would be unfair to pick on Microsoft for doing the same. But what has happened over the last year and a half goes so far beyond the accepted rough and tumble of the standards game that cumulatively it can only be considered as an all-out attack on the machinery of standards-making. Consider the evidence.
Knowledge Ecology International - KEI Statement on OOXML vote by ISO
-
This is the Statement of KEI Director James Love on the ISO's vote on OOXML as a standard for document formats:
7:30 Am, March 31, 2008
"It appears as if OOXML will be approved by the ISO. If so, we are disappointed. Microsoft's control over document formats has destroyed competition on the desktop, and the fight over OOXL is really a fight over the future of competition and innovation.
Selected Tags
Related Tags
Sponsored Links
Top Contributors
Groups interested in ISO
Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »
Join Diigo
The plan has four parts:
"Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."
"Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."
"Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."
Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."
- garyedwards on 2007-09-25