Document Wars's feed | Diigo Group

The future of XML

Fri, 07 Mar 2008 23:52:30 -0000

Highlights and Sticky Notes:

Of course, the most important conversion isn't from OpenDoc to OOXML or vice versa: it's a down conversion from either OpenDoc or OOXML to XHTML. The HTML exporters in OpenOffice and Microsoft Office are uniformly atrocious. Look for third-party developers to pick up the slack. Most important, look for individual corporate developers and webmasters to begin publishing custom templates for their sites. This will enable regular folks to write in Microsoft Word as they're accustomed to doing and then upload their musings straight into the local content-management system. Editing and reviewing tools can be built right in. Because machines generate all the markup (the humans see the GUI interface they're used to), well-formedness will be a freebie. The majority of the Web won't be well-formed by the end of 2008, but a larger percentage will be than today.

Tags: odf ooxml xhtml xml

Posted by: garyedwards

Open XML trumps ODF in document format fight, consulting firm says

Sun, 20 Jan 2008 23:53:38 -0000

Highlights and Sticky Notes:

The OpenDocument Format (ODF) remains "more of an anti-Microsoft political statement than an objective technology selection" by users, according to a report released Monday by analysts at Burton Group, who recommend that companies adopt Microsoft Corp.'s Office Open XML document format whether or not it is approved as an ISO standard next month.

Tags: burtongorup cdf css odf okelly ooxml w3c xhtml

Posted by: garyedwards

Standard or Not, OOXML Has a Lot Going for It | Redmond Developer News - Desmond

Sun, 20 Jan 2008 23:53:38 -0000

Highlights and Sticky Notes:

Ultimately, O'Kelly said it best in his report: "The relative success of ODF and OOXML, in any case, will be determined more by its utility and which community effectively exploits W3C standards than it will by one or the other more effectively navigating through ISO standards procedures."

Tags: burtongroup cdf css desmond odf okelly ooxml opendocument w3c xhtml

Posted by: garyedwards

CIO Wakeup Call: Burton Group ODF/OOXML report | The CIO Weblog

Sun, 20 Jan 2008 23:53:37 -0000

Highlights and Sticky Notes:

Although most of the ruckus over the paper has focused on the prediction that OOXML will beat out ODF, the more intriguing and meaningful conclusion is in fact that the World Wide Web Consortium (W3C) model, built on open and broadly accepted web standards already in broad use, will in fact "...be more influential and pervasive than ODF and OOXML." This implicit acknowledgment that the SaaS delivery model will dominate productivity and document storage applications is less supportive of Microsoft's approaches than many of the documents detractors care to acknowledge and suggests the entire debate is essentially a sideshow.

CIOs who are truly concerned with data preservation and open standards need to take a hard look at Microsoft's historical business practices and the remaining questions hanging over OOXML and ask themselves if it's worth making such a major transition to a format that is fraught with the same potential for vendor (rather than consumer) control in the future. SaaS options, it's worth noting, hardly escape this issue, so regardless of the very real potential that SaaS will eclipse any of the stand-alone office applications that are currently involved in this debate, it's still going to be necessary to pick a format for long-term, corporate control of vital data and documents.

Tags: burtongorup cdf cio css ny odf okelly ooxml w3c xhtml

Posted by: garyedwards

Burton Group Responds to Ars Technica's Angry ODF/OOXML Rebuttal

Sun, 20 Jan 2008 23:53:37 -0000

Highlights and Sticky Notes:

Five days ago Ars Technica issued its view of the Burton Group ODF/OOXML report and made it clear that they disagreed with its findings, going with the headline, "Analyst group slams ODF, downplays Microsoft ISO abuses."

We've had some questions from Burton Group clients and others about the article, so I thought it would be worthwhile to go through where we agree, where we disagree, where Ars Technica mischaracterizes what we said, and where it's wrong.

Tags: burtongroup cdf css odf okelly ooxml w3c xhtml

Posted by: garyedwards

Bluster keeps the ODF / OOXML debate afloat | BetaNews

Sun, 20 Jan 2008 23:53:37 -0000

Highlights and Sticky Notes:

the Group went one step further, if only that far: It advised clients to steer clear of the whole format superiority debate, in order to avoid getting dragged down into what could be called "Office politics."

"ODF is insufficient for complex real-world enterprise requirements, and it is indirectly controlled by Sun Microsystems, despite also being an ISO standard," the Burton Group's Guy Creese and Peter O'Kelly wrote. "It's possible that IBM, Novell, and other vendors may be able to put ODF on a more customer-oriented trajectory in the future and more completely integrate it with the W3C content model, but for now ODF should be seen as more of an anti-Microsoft political statement than an objective technology selection."

Tags: burtongroup cdf css ibm iso microsoft odf okelly ooxml opendocument openxml sun w3c xhtml

Posted by: garyedwards

Brian Jones: Open XML Formats : Mapping documents in the binary format (.doc; .xls; .ppt) to the Open XML format

Sun, 20 Jan 2008 23:53:37 -0000

Comments:

Well well well. We knew that IBM had access to the secret binary blueprints back in 2006. Now we know that Sun ALSO had access!

And why is this important? In June of 2006, Massachusetts CIO Louis Gutierrez asked the OpenDocument Foundation's da Vinci Group to work with IBM on developing the da Vinci ODF plug-in clone of Microsoft's OOXML Compatibility Pack plug-in. When we met with IBM they were insistent that the only way OASIS ODF could establish sufficient compatibility with MSOffice and the billions of binary documents would be to have the secret blueprints open.

Even after we explained to IBM that da Vinci uses the same internal conversion process that the OOXML plug-in used to convert binaries, IBM continued to insist that opening up the secret binaries was a primary objective of the OASIS ODF community.

For sure this was important to IBM and Sun, but the secret binaries were of no use to us. da Vinci didn't need them. What da Vinci needed instead was a subset of ODF designed for the conversion of those billions of binary documents! A need opposed by Sun.

Sun of course would spend the next year developing their own ODF plug-in for MSOffice. But here's the thing: it turns out that Sun had complete access to the secret binary blueprints dating back to 2006!!!!!!

So even though IBM and Sun have had access to the blueprints since 2006, they have been unable to provide effective conversions to ODF!

This validates a point the da Vinci group has been trying to make since June of 2006: the problem of perfecting a high fidelity conversion between the billions of binaries and ODF has nothing to do with access to the secret binary blueprints. The real issue is that ODF was NOT designed for the conversion of those binary documents.

It is true that one could eXtend ODF to achieve the needed compatibility. But one has to be very careful before taking this route. The Sun - ODF covenant not to sue specifically exempts eXtensions to ODF not involving Sun! Meaning, if the interoperable subset of ODF was designed and implemented without Sun-OASIS participation and approval, the covenant not to sue does not apply. Developers beware! You cannot safely eXtend ODF without Sun's permission.

Here is the relevant text from Sun's covenant: "Sun irrevocably covenants that, subject solely to the reciprocity requirement described below, it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates to the point of incurring an obligation, as defined by the rules of OASIS, to grant (or commit to grant) patent licenses or make equivalent non-assertion covenants."

The obscurity of intent is masked in clever legalese. Which means, bring your legal team if you want to eXtend ODF, and prepare to argue.

My point is that this covenant could have been written clear and direct to say that Sun will not sue anyone for any reason related to ODF. But they didn't do that.

People will of course wonder why ODF is so bad that it might a as well be ZERO interop? The answer to this question is complicated, but a good place to start is to observe that, just as OOXML is an XML encoded dump of MSOffice in-memory-binary-representation, ODF is an XML encoded dump of OpenOffice/StarOffice in-memory-binary-representation.

The interop problem truly kicks in at the level of specifying this encoding. The Ecma and OASIS technical committees are responsible for fully specifying the OOXML and ODF. This means a complete syntax and semantic description needed to properly implement the specs. ODF and OOXML share one very big fault; the presentation-layout layer (or styles) is not fully specified! We have the syntax but not the semantics describing how layout works. This is particularly problematic in that both ODF and OOXML are application specific dumps. While they each do a good job separating content from presentation, neither fully specifies the presentation layer. Nor is the presentation layer portable in the sense that a CDF XHTML + CSS separation is portable.

And it is the presentation layer that binds the formats to their originating applications. MSOffice has one way of implementing basic document structures like lists, fields, tables, sections and page dynamics, and, OpenOffice has another. That these application differences are embodied in the formats creates an enormous interoperability problem. Applications can exchange content, but break when trying to interpret another applications presentation-layout layer. Especially when that presentation layer is under specified!

There were three aspects of ODF 1.0 that were under specified: numbered lists, formulas, and styles (presentation-layout). ODF 1.2 attempts to fix the formula problem, but does nothing for styles. The numbered lists "interop" problem was not fixed, but exacerbated.

So even though the binary blueprints were released two years ago to Sun and IBM, we have yet to see any improvement in conversion fidelity able to crack the lock MSOffice workgroup-workflow business processes have in the marketplace. Writing a subset of ODF enabling us to achieve that high fidelity conversion has a legal cloud hanging over the process. And all of these concerns are shadowed by the fact that neither OOXML or ODF have fully specified their presentation layers!

No wonder the W3C's formats are attracting so much attention.

~ge~
posted by garyedwards

Highlights and Sticky Notes:

The second issue we had feedback on was an interest in the mapping from the binary formats into the Open XML formats. The thought here was that the most effective way to help people with this was to create an open source translation project to allow binary documents (.doc; .xls; .ppt) to be translated into Open XML. So we proposed the creation of a new open source project that would map a document written using the legacy binary formats to the Open XML formats. TC45 liked this suggestion, and here was the TC45 response to the national body comments:

We believe that Interoperability between applications conforming to DIS 29500 is established at the Office Open XML-to- Office Open XML file construct level only.

And here i was betting that the blueprints to the secret binaries would be released the weekend before the September 2nd, 2007 ISO vote on OOXML! Looks like Microsoft saved the move for when they really had to use it; jus tweeks before the February ISO Ballot Resolution Meetings set to resolve the Sept 2nd issues.

The truth is that years of reverse engineering have depleted the value of keeping the binary blueprints secret. It's true that interoperability with MSOffice in the past was near entirely dependent on understanding the secret binaries. Today however, with the rapid emergence of the Exchange/SharePoint juggernaught, interop with MSOffice is no longer the core issue. Now we have to compete with E/S, and it is the E/S interfaces, protocols and document API's and dependencies tha tmust be reverse engineered.

The E/S juggernaught is now surging to 70% or more of the market. These near monopoly levels of market penetration is game changing. One must reverse engineer or license the .NET libraries to crack the interop problem. And this time it's not just MSOffice. Today one must crack into the MS Stack whose core is tha tof MSOffice <> E/S.

So why not release the secret binary blueprints? If that's the cost of getting the application, platform and vendor specific OOXML through ISO, then it's a small price to pay for your own international standard.
posted by garyedwards

Tags: burtongroup cdf css ibm iso microsoft odf okelly ooxml opendocument openxml sun w3c xhtml

Posted by: garyedwards

CDI WICD 2.0

Sun, 20 Jan 2008 23:53:37 -0000

Highlights and Sticky Notes:

This document defines a generic language-independent processing model for combining arbitrary document formats.

The Compound Document Framework is language-independent. While it is clearly meant to serve as the basis for integrating W3C's family of XML formats within its Interaction Domain (e.g., MathML, SMIL, SVG, VoiceXML, XForms, XHTML, XSL) with each other, together with CSS and the DOM; it can also be used to integrate non-W3C formats with W3C formats or integrate non-W3C formats with other non-W3C formats.

1.1. Conformance

Everying in this specification is normative except for diagrams, examples, notes and sections marked non-normative.

The key words must, must not, required, shall, shall not, should, should not, recommended, may and optional in this document are to be interpreted as described in RFC 2119 [RFC2119].

This specification defines the following classes of products:

conforming implementation: A user agent that implements all interfaces described in this specification and follows all must-, required- and shall-level of critera in this specification.
conforming document: A document that follows all must-, required- and shall-level of critera in this specification that apply to document authors.
conforming authoring tool: One that produces conforming documents.

Tags: cdf css svg w3c wicd xforms xhtml

Posted by: garyedwards

Independent study advises IT planners to go OOXML | All about Microsoft | ZDNet.com

Sun, 20 Jan 2008 23:53:36 -0000

Highlights and Sticky Notes:

“ODF represents laudable design and standards work. It’s a clean and useful design, but it’s appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn’t a requirement. Overall, ODF addresses only a subset of what most organizations do with productivity applications today.”

The report continues:

“ODF is insufficient for complex real-world enterprise requirements, and it is indirectly controlled by Sun Microsystems, despite also being an ISO standard. It’s possible that IBM, Novell, and other vendors may be able to put ODF on a more customer-oriented trajectory in the future and more completely integrate it with the W3C content model, but for now ODF should be seen as more of an anti-Microsoft political statement than an objective technology selection.”

Mary Jo takes on the recently released Burton Group Report comparing OOXML and ODF. Peter O'Kelly, one of the Burton Group authors, once famously said, "ODF is a great format if you live in an alternative universe where MSOffice doesn't exist!"

This observation speaks to the core problem facing ODF and those who seek to implement the ODF standard: ODF was not designed for the conversion of MSOffice documents. Nor was ODF designed to work with MSOffice applications.

Another way of saying this is to state that ODF was not designed to be interoperable with MSOffice documents, applications and bound processes. The truth is that ODF was designed for OpenOffice/StarOffice. It is an application specific format.

Both OOXML and ODF do a good job of separating content from presentation (style). The problem is that the presentation - layout layers of both ODF and OOXML remains bound to specific applications producing it. While the content layers are entirely portable and can be exchanged without information loss, the presentation layers can not.

Microsoft makes no bones about the application specific design and purpose of OOXML. It's stated right in the Ecma 376 charter that OOXML was designed to be compatible with MSOffice and the billions of binary documents in MSOffice specific binary formats. The situation however is much more confusing with ODF.

ODF is often promoted as being application, platform and vendor independent. After five years of development though, the OASIS ODF TC has been unable to strip ODF of it's OpenOffice/StarOffice specific aspects. ODF 1.0 - ISO 26300 had three areas that were under specified; meaning these areas were described in syntax only, and lacked the full semantics demanded by interoperable implementations. Only OpenOffice and StarOffice code base applications are able to exchange documents with an acceptable fidelity.

The three under specified areas of ODF are: Lists (numbered), Formulas, and Layout - Presentation (styles).

ODF v 1.2 will deal with the formula problem, but this version is still in committee - perhaps years away from ISO approval. The List model in ODF 1.2 further aggravates the existing interop problems. And the presentation-layout problem is not dealt with at all. Meaning, we can expect the ODF Interop problems to continue far into the future.

There is a solution, but not what people think.

Most observers think that it's possible to harmonize ODF and OOXML. This is wishful thinking. Since both ODF and OOXML are application bound at the presentation layer, the only way to harmonize them would be to harmonize the applications themselves. Meaning; alter how the applications implement basic document structures such as lists, tables, sections, fields and page dynamics so that the implementation models are similar. This would involve serious compromise of what each application provider considers to be innovative feature sets.

Efforts to harmonize at the application layer will not work. The vendors, Sun and Microsoft, are unlikely to compromise on their innovative differentials. And there is no hope of changing the application specific formats unless and until the application providers consent.

The solution that will work is that of relying on converters. While everyone wants MSOffice to implement ODF, this is structurally impossible unless a subset of ODF is designed for this purpose. And the OASIS ODF TC has already rejected six different subset proposals designed for compatibility with MSOffice and the conversion of billions of MS binary documents.

It's also impossible to convert from one application specific format into another without significant information loss. Maybe if Microsoft and Sun were to completely specify the presentation - layout layers this problem could be lessened. But that's unlikely to happen.

So what to do?

Convert to a generic format designed for universal interoperability!

The W3C's CDF was designed for universal interop. It is totally application independent, building on combining basic document structures within the XHTML - CSS - XForms - SVG framework. CSS in particular is an extremely portable presentation layer!

Given that the large application vendors are unlikely to compromise, the W3C's CDF may be the only solution possible. The idea being to convert MSOffice documents (binary and OOXML) to CDF, and, similarly convert OpenOffice/StarOffice ODF documents to that same CDF profile.

At this higher level of Web ready CDF, there is universal interoperability. But the solution does put incredible pressure on the conversion layers.

This approach looks very similar to the SOA model where XML connectors are routinely used to wire together legacy systems. A common XML schema is used as the conversion layer connecting many black box information systems, with each connector having to be written and implemented. From the common schema, the legacy systems can be wired into emerging Web information systems, creating a fairly good information flow. Interoperability between systems might not be perfect (it depends on the quality of the individual converters – connectors), but it is usually far beyond the zero interop of previous generations!

What i'm suggesting is that document interoperability can be achieved following a similar route to that of SOA. The legacy applications can be wired together using an advanced conversion layer connecting the applications to a common XML configuration. The W3C's CDF has the flexibility and reach to capture the richness of our desktop productivity legacy. The SOA approach allows us to continue to leverage that desktop application value without having to rip out and replace. Which is costly and disruptive to existing business processes.

~ge~
posted by garyedwards

Tags: burtongorup cdf css garyedwards maryjo odf okelly ooxml w3c xhtml

Posted by: garyedwards

Redmond Developer News | The Coming OOXML Showdown

Fri, 11 Jan 2008 20:29:20 -0000

Highlights and Sticky Notes:

Forget about the Super Tuesday presidential primaries. The biggest election in February could be the long-awaited vote to approve Microsoft Office Open XML (OOXML) as an industry standard under the International Organization for Standardization (ISO).

You want to get a rise out of a group of developers? Tell them you see no difference between Open Document Format (ODF) and OOXML, since both simply map the features and functions of their respective, underlying Office application suites, OpenOffice and Microsoft Office.

Yeah, I can feel the hate mail already.

Tags: burtongroup cdf desmond odf okelly ooxml opendocument xhtml

Posted by: garyedwards

Collaboration and Content Strategies Blog: Free Report on ODF/OOXML Available

Fri, 11 Jan 2008 20:29:20 -0000

Highlights and Sticky Notes:

The overall document summary:

Industry debate about the relative merits of OpenDocument Format (ODF) and Ecma 376 Office Open XML (OOXML) highlights the significance of the productivity application market shift from binary and proprietary file formats to vendor- and product-independent Extensible Markup Language (XML) models. The competitive stakes are huge, and the related political posturing is sometimes perplexing. In this overview, Research Directors Guy Creese and Peter O’Kelly introduce ODF, OOXML, and related World Wide Web Consortium (W3C) standards, and project their implications for future productivity applications.

Tags: burtongroup cdf desmond odf okelly ooxml opendocument xhtml

Posted by: garyedwards

(WO/1995/013585) COMPOUND DOCUMENT FRAMEWORK

Fri, 11 Jan 2008 18:44:38 -0000

Highlights and Sticky Notes:

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.

Tags: cdf css xhtml

Posted by: garyedwards

How Does Compound Document Framework Benefit Us? - Axistive.com - Assistive Technology News Website - How Does Compound Document Framework Benefit Us? - Assistive Technologies and Assistive Devices for people with a disability

Fri, 11 Jan 2008 18:44:38 -0000

Highlights and Sticky Notes:

How does Compound Document Framework Work?

The Compound Document framework introduces concepts that are implemented by a number of new classes. The Compound Document framework implements a new, and more versatile, type of document and defines several new classes to support and manage this compound document, therefore its design is in this format document, command and selection, data, storage. The class structure of the Compound Document framework builds on the structure laid down by the Basic Document framework. Therefore, this section introduces only the classes new to the Compound Document framework.

Tags: cdf css xhtml

Posted by: garyedwards

» Why XHTML and CSS? | UK Web Hosting | Linux Windows Server Tutorials | PHP MySQL Service

Fri, 11 Jan 2008 18:44:38 -0000

Highlights and Sticky Notes:

Title: Why XHTML and CSS?

Simply put, XHTML and CSS has an indefinate bond together, they work together perfectly and they shape everything for the prospect of the future Internet.

Tags: css design xhtml

Posted by: garyedwards

Continuing Intermittent Incoherency » The W3C Cannot Save Us

Fri, 11 Jan 2008 18:43:05 -0000

Highlights and Sticky Notes:

It signals the effective end of the CSS WG as we (don’t) know it. Rebuilding credibility in the WG is going to be much, much harder now that Mozilla’s representative has effectively given up on the closed-door process. The working group’s secret cabal style of operation is imploding. It was inevitable, but the timing is still a surprise.

But why was it inevitable? And should we take Andy’s suggestion seriously and expect a re-chartered WG to do better? After thinking about it for a while, I think the answer is that we can’t expect any standards body to do what is being asked of the CSS WG; namely to invent the future by committee.

Alex Russel of Dojo fame is calling for a break from the W3C Standards work, and a return to browser led innovation. His reasoning is that the W3C committees are unable to keep up with the innovative needs of Web Developers. W3C Standards are holging us back.

So, do we listen to Alex and trade standards based interoperability for vendor based "innovation"? I think not. There is an error in Alex's logic i think.

The error is in mot fully recognizing the power and influence vendors have at the W3C. It's not that the W3C lags. It's that the vendors who sponsor much of the W3C standards work desire to hold back standards in order to provide for marketplace innovation differentials. Teh sad truth is that vendors have learned how to work both open standards and open source communities to protect their applications.
posted by garyedwards

Tags: cdf css html5 mozilla w3c xforms xhtml xml

Posted by: garyedwards

Whither OpenDocument Format? Say Hello To a Truly Universal File Format - CDF!

Fri, 28 Dec 2007 09:17:25 -0000

Highlights and Sticky Notes:

Filtering vs. Standards

Corel's policy is to focus on what its customers want rather than get overly involved in any one document format, Larock explained. WordPerfect uses Corel's proprietary document format but makes that code available.

"We have filters built in to translate into more than 65 different file formats, including OOXML and ODF," he said. "That list included some legacy WordPerfect, AMIPro, PDF, multiple MS Word earlier formats and numerous graphic file formats."

Maintaining filters for legacy document formats is important. People have lots of older files in archive that they still want to access, said Larock.

Up for Grabs

The evolution of text on the Internet along with the use of Web 2.0 applications is starting to have an impact. It is becoming a contest between a desktop presence and a Web-based format, according to Larock. He compared the situation to the transition from analog to digital formats in the telephone industry.

Another big endorsement for the W3C's CDF as the universal file format! posted by garyedwards

Tags: cdf corel odf ooxml opendocument w3c xhtml

Posted by: garyedwards

LinuxWorld | Game over for OpenDocument?

Wed, 12 Dec 2007 01:56:55 -0000

Comments:

Wow, what a story! Slashdotted twice:

http://ask.slashdot.org/comments.pl?sid=258073&threshold=1&commentsort=0&mode=thread&pid=20064251#20153479 posted by garyedwards

Tags: cdf compounddocument odef odf officeopenxml ooxml opendocument xhtml

Posted by: garyedwards

Does ODF Have a Future?

Wed, 12 Dec 2007 01:56:55 -0000

Comments:

This section of the Slashdot discussion of the LinuxWorld "Game Over" article concerns itself with RTF and Microsoft.

ACME 376 "decodes" and converts MS RTF to XML encoded RTF.

The full da Vinci process follows this chain:

imbr<>MS RTF<>ACME 376<>InfoSet = output target file format

MS RTF is the internal structuring stage that all in-memory-binary-representation are sent through with any conversion. Including the conversion of imbr to OOXML

The OOXML plugin process looks like this:

imbr<>MS RTF<>OOXML

The da Vinci ODF process looks like this:

imbr<>MS RTF<>ACME<>InfoSet<>ODF

The da Vinci CDF process outputs to CDF instead of ODF
The reason we need to output to something other than ODF is that the OASIS ODF TC has no interest in provisioning the ODF specification with much needed iX "interoperability eXtensions". the iX eXtensions were designed to accomodate the high fidelity "round trip" conversion of existing MS documents to ODF while establishing a high level of interoperability with existing MS applications and workgroup processes.
posted by garyedwards

Tags: acme cdf davinci odef odf officeopenxml ooxml opendocument xhtml

Posted by: garyedwards

Serious Accessibility Issues with OOXML! Adaptive Technology Resource Centre Analysis of OOXML Show Stoppers

Wed, 12 Dec 2007 01:56:55 -0000

Comments:

Whoa, another must read analysis of OOXML. This one is provided by the University of Toronto, with a focus on "accessibility" issues. Not surprisingly, OOXML fails on nearly all counts.

The authors recommend that we go back to work on improving ODF and the accessibility of ODF ready applications. posted by garyedwards

Tags: ecma376 iso odef odf officeopenxml ooxml opendocument xhtml

Posted by: garyedwards

We've Been Had!

Wed, 12 Dec 2007 01:56:55 -0000

Comments:

Yeah. I said this! And i still think ODF has what it takes to become a universal file format. But only if the "interoperability enhancment" proposals are made part of the specification. You can't talk your way to universal interop. It has to go into the spec!

OBTW, for you idiots who think i support OOXML as a standard? You're idiots. I support the quest for a universal file format that is totally application, platform and vendor independent. The requirements, demands and criticisms we make of OOXML should be applied to every file format up for universal file format consideration. Including ODF. Including XHTML+ (XHTML, CSS3, RDF). Including the EU IDABC "ODEF".

The one area where i differ from most universal interoperability seekers is that i fully believe the big vendors have left open a loop hole we can exploit. The plugin architecture is fully able to convert a big vendors application to produce our beloved but elusive universal file format.

This is important because the big vendors control "interoperability" by contolling the big vendor standards consortia, and, the major applications. It's a double edged sword.

The ubiquitous plugin architecture enables universal interop seekers to exploit the applications any way we want. What's missing is a truly open "universal" standards process that is outside the reach of big vendors.

Personally i like the recent GPL3 process as a model on which to base emerging universal standards work. Somehow the big vendors must be neutralized. Otherwise, we;ll never see the universal inteop the world so desires.

idiots,
~ge~

posted by garyedwards

Highlights and Sticky Notes:

There is nothing open about MOOXML, and it should have never made it to consideration as an international standard.

But one has to ask, what is up with Sun? The John Bosak comment is just as much cause for concern as the fact that the nations of the world would dare consider OOXML as an international standard. All i can say is that we've been had. Sun and Microsoft have worked us royally, and only now, at the last moment, does the fog of confusion clear and we can see it all.

Tags: iso odef odf ooxml openwave xhtml xml

Posted by: garyedwards