« FT: e-Recruitment Triple-Threat | Main | Windows Mobile 6 "A Mess" »

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83452f49169e200e54f9124c78834

Listed below are links to weblogs that reference Gary's History of ODF Development:

Comments

dario

please, give me a break, stop your rethoric and just *DO* things ( disclaimer: i'm a computer and office software user and "true open standards" fan, and i support ODF ).

When you were spreading all around the world the "binary key" myth, i sent you an email and asked you where do you have a concrete proove of what you were saying (why? because i feared that this binary key thing could backfire ), and you answered me:

google for gary edwards and you will find the binary key prove ( !!??? )

Conclusion: you are a dishonest person and i don't trust your words. More: you are a dangerous person to open standards ( Microsoft is smilling and thanking you all this anti-ODF blah blah ... )

Make me a favor: get a life.

dario

Gary Edwards

Hi dario,

Thanks for responding. The “binary key” is not a myth. When Microsoft released the first beta of MSOffice 2003, it included the earliest instances of what we now know as MS-OOXML; wordprocessingML and spreadsheetML.

With these early instantiations of XML, Microsoft separated the content from the presentation (or what ODf would call styles).

The thing is, the content package could be opened in a text editor and the markup examined, but the presentation package could not. This is where the ”binary key” reference applies. Only Microsoft applications were able to open the presentation package. They were said to have had the ”binary key”.

Microsoft had a very rational explanation for the situation. They argued that their XML was useful to enterprise publication, content and archive management systems in that the content was fully accessible, and these systems would apply their own presentation anyway. This argument is actually very accurate. When documents are re purposed, or content objects reused, the content remains unchanged as higher level applications apply their own presentation templates. Separation becomes very useful wherever reports and searches of large document libraries is important to particular business processes.

The same arguments are made for ODf's separation of content and styles. Maybe even more so. Document processing experts have this view of the world where each application represents a specific processing purpose. Preserving content is one thing. Replacing the presentation aspects of a document another. They fully expect and anticipate that each application in a processing chain will implement their own presentation.

This is why the publics expectations for a PDF quality preservation of a documents presentation isn't recognized by ODf document processing experts as an achievable objective. If each application is expected to NEED to change a document re purposing or document object reuse, as determined by a particular processing business requirement, then you design the file format to meet those expectations and needs. Which they did.

The publics expectation of PDF presentation quality comes a bit after the fact. Capice?

Getting back to the binary key”. Contrary to popular opinion, i didn't coin the term ”binary key”. The Valoris Group did.

As i'm sure your well aware, the Valoris Group conducted the three year study for the EU-IDABC concerning the construct of a highly interoperable information infrastructure for the future. They focused on XML, SOA, and the emerging Web Platform, and the best way of making the transiton. They also created the fictional ”Open Document” as a means of describing how their vision of this highly interoperable – SOA -SaaS – web ready world would work.

When the Valoris Group saw Microsoft's first run at XML, they wanted both the content and the presentation markup packages accessible. They wanted the ”binary key” removed. Which, actually did happen. By the time MSOffice 2003 was released, both packages were open and accessible. End of controversy.

The odd thing is that the web was subsequently scrubbed of any Microsoft defense of this application lock. That's too bad, because those arguments are very relevant to today's very difficult interoperability discussions.

The traditions of file formats are that they are bound to specific applications. The first run at XML, whether you see it from the Microsoft view point or the ODf viewpoint, recognized that content could easily be separated from specific applications. But presentation could not.

This is as true today as it was back in 2002 -2003. The presentation aspects of a document are very much dependent and bound to the internal in-memory-binary-representation layout model of any particular application. Hence, converting content is easy. But converting presentation always entails a loss of fidelity due to application specific layout differentials.

In Massachusetts it was proven that anywhere MSOffice workgroups dominated a particular business process, the round trip fidelity presentation issues were an impossible problem for ODf. End users responsible for critical day to day business processes demand near PDF presentation quality.

What we did in Massachusetts was try to figure out what changes could be made to ODf to meet these MSOffice bound requirements. For the most part this means identifying those application specific presentation or layout differentials between OpenOffice – ODf and MSOffice binary / xml.

It turns out we could solve the problem with the use of five generic elements for the structural elements of lists, tables, fields, sections and page dynamics. We had two approaches.

The first approach was called ODf iX, and consisted simply of adding the five generics to ODf. The second approach however was far more elegant and ingenious. This involved using the then new metadata RDF/XML approach.

In August of 2006, with ODf hanging by a thread in Massachusetts, California and the EU-IDABC, we actually got our metadata model approved as part of the ODf Metadata SC requirements. It turns out this wasn't enough to save ODf in those governments, but we thought the concept worthy enough to pursue long after the ODf collapse that followed the October 4th, 2006 resignation of CIO Louis Gutierrez.

The metadata approach was based on the concept that all presentation is just metadata for particular content objects. We thought that the only way we could reconcile the publics PDF expectations with the model pursued by document processing experts would be to shift the binding burden of presentation from application specific packaging to a content object metadata model. It seemed to us that the RDF – RDFa properties model would be ideal for this transition. We also believed that this approach was critical to solving the feature set differential problems between lightweight web platform applications, and heavy office suite legacy applications. And, the model had a gradualism aspect to it that might actually work in a world where interoperability problems between legacy applications and emerging web platform oriented applications were certain to clash.

Anyway. Needless to say, by April of 2007 it was very clear that we would never get our ODf iX or metadata changes through OASIS. End of story. Time to move on.

Public awareness of the presentation issue perhaps began with the infamous binary key discussion. It continues however because the issues of application – file format dependencies have yet to be resolved.

Hope this helps,
~ge~

Hey buddy can you spare me a garage?

The comments to this entry are closed.


Sam Hiser

Categories

OFF-WHITEPAPERS

ARTICLES


www.flickr.com
This is a Flickr badge showing public photos from swhiser. Make your own badge here.


Locations of visitors to this page


Google
Search PlexNex

  

View Sam Hiser's profile on LinkedIn

Powered by TypePad