OpenDocument's feed | Diigo Group

Universal Interoperability Framework for OpenDocument

Thu, 27 Sep 2007 23:46:14 -0000

Comments:

The OpenDocument Foundation "Universal Interoperability Framework" Proposal has not been submitted to the OASIS ODF TC as of this bookmarking. But this version is complete except for a closing summation.
posted by garyedwards

Highlights and Sticky Notes:

SUMMARY: The OpenDocument Foundation proposes that the OASIS Office TC begin now to create an interoperability framework for inclusion in OpenDocument v. 1.2. This document, one of a series of planned proposals, proposes first steps towards a comprehensive interoperability framework and OpenDocument conformance requirements. This proposal is designed to bring ODF v. 1.2 into compliance with current ISO Interoperability Requirements.

Tags: cdf interop interoperability iso odef odf opendocument

Posted by: garyedwards

Compound Document Formats (CDF)

Mon, 06 Aug 2007 01:13:04 -0000

Comments:

heh heh heh. You where asking about that universal file format? drool away amigo! drool away posted by garyedwards

Tags: odef odf officeopenxml ooxml opendocument xhtml

Posted by: garyedwards

We've Been Had!

Fri, 20 Jul 2007 01:49:29 -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
The "Backwards Compatibility" issue is all the rage at ISO, with the September vote on MS OOXML just a month away.

Microsoft and Sun (We've Been Had!) are arguing that ISO should approve MS OOXML (Microsoft OfficeOpenXML) because OOXML offers a backwards compatibility with the legacy of existing billions of binary documents.

This oft sighted history of Microsoft's reprehensible business practices is worth citing once again before the nations of the world go down that treacherous path towards ratifying Microsoft's proprietary systems and products as international standards.

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

Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da

Fri, 13 Jul 2007 13:56:15 -0000

Comments:

Great article series from eWeek. A must read. But it all comes down to interoperability across two stack models: The Microsoft Vista Stack, and an alternative Open Stack model that does not yet exist!

Incompatible formats become a nightmare for the kind of integration any kind of SOA implementation depends on, let alone the Web 2.0 AJAX MashUps this article focuses on.

I wonder why eWEEK didn't include the Joe Wilcox Micrsoft Watch Article, "Obla De OBA Da". Joe hit hard on the connection between OOXML and the Vista Stack. He missed the implications this will have on MS SOA solutions. Open Source SOA solutions will be locked out of the Vista Stack. And with 98% or more of existing desktop business processes bound to MSOffice, the transition of these business processes to the Vista Stack will no doubt have a dramatic impact on the marketplace. Before the year is out, we'll see Redmond let loose with a torrent of MS SOA solutions. The only reason they've held back is that they need to first have all the Vista Stack pieces in place.

I don't think Microsoft is being held back by OOXML approval at ISO either. ISO approval might have made a difference in Europe in 2006, but even there, the EU IDABC has dropped the ISO requirement. For sure ISO approval means nothing in the US, as California and Massachusetts have demonstrated.

All that matters to State CIO's is that they can migrate exisiting docuemnts and business processes to XML. The only question is, "Which XML? OOXML, ODF or XHTML+".

The high fidelity conversion ratio and non disruptive OOXML plugin for MSOffice has certainly provided OOXML with the edge in this process.

Because of ODF vendor in fighting in Massachusetts, and the subsequent failure of ODF, the hapless file format arrived in California and other states with a hardened reprutation as "great file format, but impossible to implement".

The next question people have to start askign is what impact will OOXML and the Vista Stack have on SOA? Will open source and non Micrsoft vendor SOA solutions be locked out of the Vista STack?

Of course. If ever there was a no brainer this is it. Microsoft is goign to eXtend their desktop monopoly to servers, devices and the web using the highly proprietary Vista STack to lock in business process customers for years to come.

~ge~
posted by garyedwards

Highlights and Sticky Notes:

To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.

OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.

The binding model for OOXML is "Smart Documents", and it is proprietary!

Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.

Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.

Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.

I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.

Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.

One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.

This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and document pages. And who better to apply specific ontologies and metadata information than the actual knowledge workers themselves?

Can the authors and workgroup experts beat the famed Google algorithms? Of course. Given the right tools, end users will be able to do this.

The thing is, the "right tools" for MSOffice bound business processes is going to be based on binary Smart Document widgets and components! Google will not be able to touch this layer of advanced metadata strucuturing!

Up till now Google has fought the W3C Semantic Web proposals for RDF XML/RDF and RDFa. With good reason. Google obviously has figured out that much of their value will disipate if the world moves to highly structured metadata rich documents with advanced data binding methods. No need for those precious algorithms.

So the Vista Stack model that is now emerging is actually a two prong strategy. On the one hand Microsoft is extending their desktop monopoly to take over the entire business stack, as Joe so abley points out. On the other hand, this is an assault on the open Internet, with OOXML-Smart Docs rapidly positioning to replace unstructured HTML as the premier transport of a potent information and data package. posted by garyedwards

Microsoft seeks to create sales pull along the vertical stack between the desktop and server.

The vertical stack is actually desktop - server - device - web based. The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.

Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement. One of the primary failings of ODF is that it is not able to be fully implemented in this converged space. OOXML on the other hand was created exactly for this purpose!

So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets. OOXML differs in that it is tightly bound to the Vista Stack.

So where is an Open Stack model to turn to?

Good question, and one that will come to haunt us for years to come. Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.

OOXML is unfi as a UFF becuase it is application - platform and vendor bound.

For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.

XHTML (XHTML CSS3 RDF) is looking very good. The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML . Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML ?

I think so. But we can't be sure until the da Vinci proves this conclusively.

One thign to keep in mind though. The internal plugins have already shown that it is possible to do multiple file formats. OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.

So why not try it with XHTML , or ODEF (the eXtended version of ODF enhanced for true universal interoperability)?
posted by garyedwards

Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.

This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be. ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.

The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice, does not fully support and implement the Conformance Clause.

The only foreign elements supported by OpenOffice are paragraphs and text spans. Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!

This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.

Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci. KOffice ODF and Googel Docs ODF are all different ODF implementations. Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.

It's also true that OOXML has optional implementation areas. With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.

With OOXML, the entire Vista Stack - Win32 dependency layer is "optional". No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies. This includes the legacy Win32 API dependencies (like VML, EMF, EMF ), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.

MSOffice 2007 is extremely unique as an application in that it's able to import legacy documents and preserve their Win32 dependencies. Yet, if you were to re create those same documents "natively" in MSOffice 2007, the dependencies would all be Vista Stack types.

Here's a kicker. If you attach an MSOffice legacy binary to an eMail, and send that eMail to any Exchange/SharePoint Hub application (like OWL), the attachment will automatically be converted to MS OOXML - complete with Vista Stack dependencies! Unl,ike MSOffic e2007, the E/S Hub does not offer that dual backwards compatibiltiy model.

Because of this dual model, MSOffice is one of the most unique applications Microsoft has ever put on the market. The traditionnal MS application only proivedes for one way backwards compatibility. You can read in a legacy document, but are unable to effectively wirte out to the legacy binary format. MSOffice 2007 steps soff the forced upgrade treadmill, and offers a dual mode two way form of backwards compatibiltiy. It' will be tricky for end users to avoid the upgrade trap of writing new documents and thinking they can be inserted into a MSOffic ebound workgroup tha tincludes legacy MSOffice versions. But it can be done.

The traditional forced march upgrade treadmill strategy has been moved to the Exchange/SharePoint Hub. This is also where next generation line of business integration apps will be written - replacing the desktop platform as everything is migrated to Microsoft's XML.
posted by garyedwards

Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML.

True, but a tricky statement given that the proprietary OOXML implementation is "optional". It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".

In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.

Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!

It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.

So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat. For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true. For all practical concerns, that's enough. For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.

posted by garyedwards

Microsoft got there first to protect Office.

No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport!

Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET.

The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place.

The Vista Stack looks like this:

..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub

..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End

The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents.

The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps.

The productivity gains that can be had through this migration to the E/S Hub are extraordinary.

A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service)

These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital". For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model. This will no doubt change with the emerging dominance of E/S Hub solutions.

The desktop stuff also was very brittle, requiring constant adminsistration, training and hand holding.

Within weeks of Agent Achieve coming out, Outlook desktops were being replaced over night. Although AA was a broker owner system (not individual), there was a sudden rush by independent agents to work where AA systems were available. That wave pushed ever more brokerages towards AA.

As this second wave set in, the desktop applications began to offer their own E/S Hub alternatives. Within 9 months the entire desktop productivity market had been replaced by E/S Hub based applications. It went quick.

This is a prelude to the SOA onslaught soon to come out of Redmond. Once the Vista Stack is in place, and open source SOA components effectively locked out, Microsoft SOA will sweep the business sector.

Without OOXML high fidelity compatibilty, and Smart Documents capability, open source SOA inititives will fall by the way side. Microsoft will successfully leverage their desktop MSOffice bound monoploy over business processes into a proprietary killer SOA solution. The only thing that might stop them is if open source providers wake up and understand that OOXML-Smart Documents is the whole ball game. And that there is no comparable ODF alternative ready to challenge the looming juggernaut.

posted by garyedwards

By adapting XML

The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!

In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems.

Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business.

Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.

Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value.

When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone!

The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level.

Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Dockett Management System away from approving OOXML.

The odd thing for us was understanding why Microsoft wasn't trumpeting their SOA slam dunk in real estate? posted by garyedwards

Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit.

Okay, now Joe has the Micrsoft SOA bull by the horns. Why doesn't he wrestle the monster down?
posted by garyedwards

Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.

Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.

What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.

Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
posted by garyedwards

I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path.

Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.

The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality. Which, for the sake of brevity we can call the lead Win32 API dependencies.

One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.

Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration. As long as the complete Win32 API was available (Windows MSOffice VBA run times), this platform was great for workgroups. The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.

The Internet offers everyone a new way of integrating data, content and streaming media. Web applications are capable of loosly coupled serving and consuming of other application services. Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.

On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.

Into this SOA mash Microsoft will push with a sweeping integrated stack model. Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.

posted by garyedwards

Tags: odef odf officeopenxml ooxml opendocument vista-stack

Posted by: garyedwards

2. WordprocessingML Reference Material - OOXML-Wiki

Wed, 11 Jul 2007 01:01:00 -0000

Comments:

I promise that within a few minutes of reading this OOXML Wiki you will be wondering if this is in fact an ODF Wiki! This is incredible.

Fast forward to the section called, "Interoperability between ODF and OOXML", and enjoy. They cite the problem and make an interop recommendation for each entry. And what a recommendation it is. Speaks volumes.

There is definately something going on in Europe. The EU IDABC has rejected ODF, OOXML, OASIS, Ecma and ISO! And are now trying to write their own highly interoperable XML file format, ODEF. an effort we will fully support with our da Vinci plugin for MSOffice.

Well, not only will we support ODEF, we'll write it for them if they really want to cut to the chase and get the kind of vendor independent interoperability the world hungers for.

The British Standards Institute (BSi) is responsible for the massive research that went into this OOXML Wiki. They have hunted down and defined the interoperability problem areas between ODF and OOXML. Surprise surprise. They be many.

The interesting part is that the BSi researchers have found massive, indeed overwhelming fault with OOXML! Yet, instead of recommending that Ecma make the needed changes to OOXML, they instead recommend that ISO ODF make the changes!

Not OASIS ODF! Not Ecma OOXML.

ISO ODf!

The difference is all the difference in the world. Sun does not control ISO ODF the way they control OASIS ODF. And at ISO, all the binding of ODF to OpenOffice/StarOffice that accounts for the zero interoperability of ODF applications can be broken as needed.

This is indeed good stuff.

You can't read this research without thinking that the BSi is going to advise the British ISO NB contingent to vote against OOXML. But they aren't about to let ODF sit idle either. The only way they see to fix interoperability between OOXML and ODF is to identify the problems in OOXML, and FIX ODF to accomodate those problems!

Not OOXML. Yet all the fault they identify lies with OOXML.

Amazing.

Clearly the BSi recognizes that OOXML is a plugin bound to the MSOffice application series. Changing OOXML would require changes at the application level - changes in MSOffice.

Changing the application layer for 95% of all workgroup - workflow bound business processes would be a disaster. So they correctly see that the way forward is to change ODF, and tell Sun to do whatever it takes to adapt the OpenOffice/StarOffice applications that bind ODF. At less than 2% marketshare, this approach sound reasonable to me. But i'm not Sun. And i don't have a 2004 controlled interoperability-patent-market allocation-sweet sweet hardware deal with Microsoft either.

We've been working for more than a year on a set of ODF Interoperability Enhancements that would greatly benefit anyone working the converter - plugin - transformation interop sector. These proposals have been met with vicious vehemence at OASIS ODF - see the recent List Enhancement Proposal donnybrook as an example. So much so that we see no use in further proposals or our continued participation. And that after near five years of work on OASIS ODF.

We fully believe that our insistence on interoperability enhancements to ODF that would improve interop with Microsoft documents and applications is the reason why OASIS booted the OpenDocument Foundation. Pushing for interop with existing file formats and application is that bad. Opposing Sun is worth the wrath of big vendor toady OASIS.

But i have to wonder, how do these BSi guys know this? Obviously they have figured out that the only way to get true interoperability is to neutralize the big vendors influence and control of the standards process. Same as with the EU IDABC.

Must be something in the water. Drink up world. You actually can get everything you want. Including perfect interoperability.

~ge~
posted by garyedwards

Highlights and Sticky Notes:

It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following features:

It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: image can be positioned absolutely within a frame

Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

Include support for this feature in ISO ODF is another way of saying to hell with Ecma, OASIS and the big vendors driving the ODF-OOXML bus, Micrsoft and Sun. This is delicious beyond belief. It's also the only way the world is going to get the interoperability they are demanding. The big vendors must be neutralized. The file formats must be completely independent of applications, platforms and the control of big vendors who routinely make exclussionary interoperabilty deals with each other whenever and wherever profitable. posted by garyedwards

Tags: odef odf officeopenxml ooxml open-document-exchange-format opendocument

Posted by: garyedwards

EU-IDABC ODEF Workshop 2007 in Berlin - Documentation - presentations

Sat, 09 Jun 2007 11:41:55 -0000

Comments:

ODF officially died on February 28, 2007, at the Advanced eGovernment Conference in Berlin. Hellow ODEF
posted by garyedwards

Highlights and Sticky Notes:

IDABC ODEF Workshop 2007 in Berlin

As information exchange in and with public administrations is very often bound to documents, editing, archiving and exchange possibilities for documents are crucial for the optimum function of administrations, both in terms of practicality and cost.

Initiatives such as the PEGSCO Recommendations on Open Document Formats published by the IDABC Management Committee, demonstrate public administrations preference for "open" document exchange and storage formats that are subject to formal standardisation via international standardisation procedures.

The primary objectives of the Berlin event, held at the German Federal Ministry of the Interior (BMI), were to:

compile further input from Member State public administrations on their experiences and strategies on ODEF
gather industry viewpoints on the initiatives relating to ODEF standardization and information on future standardisation developments
provide a platform for exchange between stakeholders in public administrations and main industry players

The program of the workshop included, among other:

ODEF Strategies: Examples from European Administration
Practical Experiences with the implementation of ODEF
Report on ODEF-Standardisation activities
4 parallel sessions with participants
A panel discussion with stakeholders

Tags: california davinci interop iso massachusetts oasis odef odf ooxml opendocument politics xml

Posted by: garyedwards