That said, it goes on to acknowledge that “there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects.
So, South Africa was watching closely the failed effort in Massachusetts to implement ODF? And now they are determined to make it work?
Good thing they left themselves a “pragmatic” out; “there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects.”
Massachusetts spent a full year on an ODF implementation Pilot Study only to come to the inescapable conclusion that they couldn't implement ODF without a high fidelity "round trip" capable ODF plug-in for MSOffice. In May of 2006, Pilot Study in hand, Massachusetts issued their now infamous RFi, "the Request for Information" concerning the feasibility of an ODF plug-in clone of the MS-OOXML Compatibility Pack plug-in for MSOffice applications.
At the time there was much gnashing of teeth and grinding of knuckles in the ODf Community, but the facts were clear. The lead dog hauling the ODf legislative mandate sleigh could not make it without ODf interoperability with MSOffice. Meaning, the rip out and replace of MSOffice was no longer an option. For Massachusetts to successfully implement ODf, there had to be a high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications.
Although ODf was not designed to meet these requirements, the challenge could not have been any more clear. Changes in ODf would have to be made.
So what happened?
Over a year later, a few days after Sun delivered their proprietary ODF plug-in for MSOffice, Massachusetts announced that both ODF and MS-OOXML would be recognized as implementable standards. (Good one Sun. Thanks a pant load.)
Recent legislative hearings in Texas concerning a bill that would mandate ODF as the only document standard, revealed something very surprising. There was direct testimony that out of the entire Commonwealth of Massachusetts, only 24 desktops had successfully transitioned to ODF. Whoops. Good thing they had the Sun ODf plug-in :)
With Exchange/SharePoint developer hubs going down everywhere, automagically converting binary documents to MS-OOXML, and the MS-OOXML Compatibility Pack plug-in effectively enabling workgroup conversions to MS-OOXML, things do not look good for the future pragmatic implementation of ODF in Massachusetts. Or anywhere else for that matter.
The needed changes to ODf emphasizing the need to meet the Massachusetts defined market requirements of high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications, were not made by the OASIS ODf TC.
So i wonder just how closely South Africa has been watching Massachusetts?
Not that it's difficult to figure out. In Massachusetts it all came down to the sprawl of MSOffice bound workgroups where business process document exchange required this difficult "high fidelity round trip" conversion. Not only does the ODF plug-in have to perfect a consistently high fidelity conversion to ODF of these active documents, but the documents had to be "round trip" ready in terms of application use.
Round tripping is a killer for ODf, with or without the inclusion of MSOffice desktops in any workflow – document processing chain. The specification was designed to protect content during extensive document exchange and processing chain use, but not presentation!
During an effective document exchange, many applications must be interoperable at the file format level. For ODF this is limited to "content", with the assumption that each application will apply their own "presentation". Sometimes this is jokingly called the "let a thousand presentations bloom but don't touch my data" approach. It's very consistent with the way document processing experts view the world.
The "let a thousand presentations bloom" approach is not however consistent with public expectations for ODF.
The public expects PDF quality of interop between applications, where both content and presentation is preserved throughout the document exchange process - unless and until the owners of the document make changes.
This dilemma brings us back to that age old problem of interactive (as opposed to PDF static) document exchanges being totally tied to specific applications - right down to the version level.
What we found in Massachusetts is that the ODf implementation barrier was due to MSOffice bound workgroups and business processes. And it wasn't just the year long Pilot Study screaming this. They gave us 150 test documents representative of critical business processes where uncompromising fidelity had to be maintained. And yes, the documents were filled with our favorite structural conversion problems of lists, tables, fields, sections and page dynamics. These problems in turn can be attributed directly to the structural implementation differences between MSOffice and OpenOffice.
Let's take this issue to a higher level. The ODF barrier itself had two problem points which we've expresses as the critical market requirements for a high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications.
The first was that it's impossible to fully capture MSOffice feature sets and specific structural implementation models in ODF. The ODf container is simply not designed for the high fidelity conversion of MS binary or xml documents, which directly reflect the MS application specific implementation model of basic structures.
Our solution was the ODF iX "interoperability enhancements" comprised of five generic elements for the structural basics of lists, tables, fields, sections and page dynamics. These extensions were critical to any ODF plug-in effort needing to establish the high level of MSOffice compatibility - interoperability demanded by Massachusetts workgroups wanting to transition to ODF.
I wonder if the South African workgroups are different? Maybe they avoided the past ten years of MSOffice's dominance as a developer platform? If that's the case, they can move directly to Linux desktops running OpenOffice ODf. There would be no barrier similar to what stopped Massachusetts, California, and the EU-IDABC.
The ODF iX eXtensions were not acceptable to the OASIS ODF TC.
The second problem point has to do with ODF Interoperability in general. To be blunt, there is none. Except at the application specific - version specific level of document exchange. And this is not what the public expected from ODF.
To fix ODF Interoperability, there has to be some level of compliance and conformance requirements. Today, ODf compliance is optional. Nor are there any test suite requirements, let alone anything as strict and demanding as the W3C's "CDR" for W3C Compound Document Formats.
Every ODF application has their own way of implementing ODF. There are no guarantees of interop, or even basic interop requirements.
Still, OpenOffice 2.3 workgroups can exchange documents effectively with other OOo 2.3 workgroups. Just don't try to exchange those same documents with a Lotus Symphony desktop because Symphony is based on a proprietary fork of OpenOffice 1.1.4.
The effect of this is that a Lotus Symphony desktop (ODF 1.0) can't join a OpenOffice 2.3 workgroup (which implements ODF 1.2) without seriously disrupting the workflow.
Now imagine the situation in Massachusetts where they expected OpenOffice ODF 1.0 desktops to be joining ODF 1.0 plug-in enabled MSOffice workgroups! Or how about Linux – OpenOffice desktops joining existing MSOffice directed workgroups?
To compete against MS Server side systems, Linux server systems must either figure out how to interoperate with the MSOffice – Outlook bound workgroups, or, replace those desktops. Massachusetts sent out a clear message; the disruptive cost of rip out and replace was far beyond the price they were willing to pay for much desired freedom to choose, freedom to innovate, and the sovereignty over their information future that could have been theirs. And Massachusetts understood, perhaps better than anyone, the value of complete sovereignty. They couldn't bear the disruptive cost though.
Compound the matter with the reality that today, there are few if any ODF 1.0 - ISO 26300 applications, at any measure of compliance. Near all have moved to some level of ODF 1.2.
Compound that problem further by understanding that ODF 1.2, as currently written, will not pass ISO certification. In May of 2006, ISO Directorate issued a statement that ODF will not be exempt from ISO Interoperability Requirements. The good news is that MS-OOXML also fails to comply. But where does that leave the world?
Confusion, continuing ODf implementation – interoperability difficulties, and the absence of a clear winner in the universal file format stakes will leave the marketplace with only one option: the system default provided by the MS Stack of MS-OOXML ready applications with insidiously proprietary smart tags, XAML, WFP, TFS, and other stack specific collections of dependencies.
This is the interoperability thicket that South Africa so boldly charges into. If the OASIS ODF TC, and the ODF community of applications do not get there act together soon, odds are that South Africa will find themselves in the same predicament as Massachusetts. All dressed up in ODf with nowhere to go but MS-OOXML.
People have accused us of overstating the ODF interoperability problems. The lord of the garage gestapo and his minions insists that these problems can be fixed. Let's hope they are right. Let's hope that South Africa can pull off the implementation of ODF on something more than 24 desktops. And let's hope that this time, the ODf community comes out of the blogosphere and shows up for this important implementation battle instead putting the entire burden on SA as they did in Massachusetts.
A few more failures like Massachusetts and Microsoft is going to be wondering why they ever went through the problems of submitting their proprietary xml to ISO to begin with. Unless and until ODF can successfully challenge MS-OOXML as a real world "implementable" alternative, we're going to find ourselves stuck in the MS Stack for years to come. ISO approval or not.
~ge~
.
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.
Page Comments
So,
South Africa was watching closely the failed effort in Massachusetts
to implement ODF? And now they are determined to make it work?
Good
thing they left themselves a “pragmatic” out; “there are
standards which we are obliged to adopt for pragmatic reasons which
do not necessarily fully conform to being open in all
respects.”
Massachusetts
spent a full year on an ODF implementation Pilot Study only to come
to the inescapable conclusion that they couldn't implement ODF
without a high fidelity "round trip" capable ODF plug-in
for MSOffice. In May of 2006, Pilot Study in hand,
Massachusetts issued their now infamous RFi, "the Request for
Information" concerning the feasibility of an ODF plug-in clone
of the MS-OOXML Compatibility Pack plug-in for MSOffice applications.
At the
time there was much gnashing of teeth and grinding of knuckles in the
ODf Community, but the facts were clear. The lead dog hauling the
ODf legislative mandate sleigh could not make it without ODf
interoperability with MSOffice. Meaning, the rip out and replace of
MSOffice was no longer an option. For Massachusetts to successfully
implement ODf, there had to be a high level of ODf compatibility with
existing MS documents, and ODf application interoperability with
existing MS applications.
Although
ODf was not designed to meet these requirements, the challenge could
not have been any more clear. Changes in ODf would have to be made.
So
what happened?
Over a year later, a few days after Sun
delivered their proprietary ODF plug-in for MSOffice, Massachusetts
announced that both ODF and MS-OOXML would be recognized as
implementable standards. (Good one Sun. Thanks a pant load.)
Recent legislative hearings in Texas concerning a bill that
would mandate ODF as the only document standard, revealed something
very surprising. There was direct testimony that out of the
entire Commonwealth of Massachusetts, only 24 desktops had
successfully transitioned to ODF. Whoops. Good thing they had the
Sun ODf plug-in :)
With Exchange/SharePoint developer
hubs going down everywhere, automagically converting binary
documents to MS-OOXML, and the MS-OOXML Compatibility Pack
plug-in effectively enabling workgroup conversions to MS-OOXML,
things do not look good for the future pragmatic
implementation of
ODF in Massachusetts. Or anywhere else for that matter.
The
needed changes to ODf emphasizing the need to meet the Massachusetts
defined market requirements of high level of ODf compatibility with
existing MS documents, and ODf application interoperability with
existing MS applications, were not made by the OASIS ODf TC.
So
i wonder just how closely South Africa has been watching
Massachusetts?
Not
that it's difficult to figure out. In Massachusetts it all came
down to the sprawl of MSOffice bound workgroups where business
process document
exchange
required this difficult "high fidelity round trip"
conversion. Not only does the ODF plug-in have to perfect a
consistently high fidelity conversion to ODF of these active
documents, but the documents had to be "round trip" ready
in terms of application use.
Round tripping is a killer for
ODf, with or without the inclusion of MSOffice desktops in any
workflow – document processing chain. The specification was
designed to protect content
during extensive document exchange and processing chain use, but not presentation!
During
an effective document exchange, many applications must be
interoperable at the file format level. For ODF this is limited
to "content",
with the assumption that each application will apply their own "presentation".
Sometimes this is jokingly called the "let
a thousand presentations bloom but don't touch my data"
approach. It's very consistent with the way document processing
experts view the world.
The "let
a thousand
presentations bloom"
approach is not however consistent with public expectations for ODF.
The public expects PDF quality of interop between
applications, where both content and presentation is preserved
throughout the document exchange process - unless and until the
owners of the document make changes.
This dilemma
brings us back to that age old problem of interactive (as opposed to
PDF static) document exchanges being totally tied to specific
applications - right down to the version level.
What
we found in Massachusetts is that the ODf implementation barrier was
due to MSOffice bound workgroups and business processes. And it
wasn't just the year long Pilot Study screaming this. They gave us
150 test documents representative of critical business processes
where uncompromising fidelity had to be maintained. And yes, the
documents were filled with our favorite structural conversion
problems of lists, tables, fields, sections and page dynamics. These
problems in turn can be attributed directly to the structural
implementation differences between MSOffice and OpenOffice.
Let's
take this issue to a higher level. The ODF barrier itself had two
problem points which we've expresses as the critical market
requirements for a high level of ODf compatibility
with existing MS documents, and ODf application interoperability with existing MS
applications.
The
first was that it's impossible to fully capture MSOffice feature sets
and specific structural implementation models in ODF. The ODf
container is simply not designed for the high fidelity conversion of
MS binary or xml documents, which directly reflect the MS application
specific implementation model of basic structures.
Our
solution was the ODF iX "interoperability enhancements"
comprised of five generic elements for the structural basics of
lists, tables, fields, sections and page dynamics. These
extensions were critical to any ODF plug-in effort needing to
establish the high level of MSOffice compatibility - interoperability
demanded by Massachusetts workgroups wanting to transition to ODF.
I
wonder if the South African workgroups are different? Maybe they
avoided the past ten years of MSOffice's dominance as a developer
platform? If that's the case, they can move directly to Linux
desktops running OpenOffice ODf. There would be no barrier similar
to what stopped Massachusetts, California, and the EU-IDABC.
The
ODF iX eXtensions were not acceptable to the OASIS ODF TC.
The
second problem point has to do with ODF Interoperability in general.
To be blunt, there is none. Except at the application specific
- version specific level of document exchange. And this is not
what the public expected from ODF.
To fix ODF
Interoperability, there has to be some level of compliance and
conformance requirements. Today, ODf compliance is optional.
Nor are there any test suite requirements, let alone anything as
strict and demanding as the W3C's "CDR" for W3C Compound
Document Formats.
Every ODF application has their own way of
implementing ODF. There are no guarantees of interop, or even
basic interop requirements.
Still, OpenOffice 2.3
workgroups can exchange documents effectively with other OOo 2.3
workgroups. Just don't try to exchange those same documents
with a Lotus Symphony desktop because Symphony is based on a
proprietary fork of OpenOffice 1.1.4.
The effect of
this is that a Lotus Symphony desktop (ODF 1.0) can't join a
OpenOffice 2.3 workgroup (which implements ODF 1.2) without seriously
disrupting the workflow.
Now imagine the situation in
Massachusetts where they expected OpenOffice ODF 1.0 desktops to be
joining ODF 1.0 plug-in enabled MSOffice workgroups! Or how
about Linux – OpenOffice desktops joining existing MSOffice
directed workgroups?
To
compete against MS Server side systems, Linux server systems must
either figure out how to interoperate with the MSOffice – Outlook
bound workgroups, or, replace those desktops. Massachusetts sent
out a clear message; the disruptive cost of rip out and replace was
far beyond the price they were willing to pay for much desired
freedom to choose, freedom to innovate, and the sovereignty over
their information future that could have been theirs. And
Massachusetts understood, perhaps better than anyone, the value of
complete sovereignty. They couldn't bear the disruptive cost though.
Compound
the matter with the reality that today, there are few if any ODF 1.0
- ISO 26300 applications, at any measure of compliance. Near
all have moved to some level of ODF 1.2.
Compound that
problem further by understanding that ODF 1.2, as currently written,
will not pass ISO certification. In May of 2006, ISO
Directorate issued a statement that ODF will not be exempt from ISO
Interoperability Requirements. The good news is that MS-OOXML also
fails to comply. But where does that leave the world?
Confusion,
continuing ODf implementation – interoperability difficulties, and
the absence of a clear winner in the universal file format stakes
will leave the marketplace with only one option: the system default
provided by the MS Stack of MS-OOXML ready applications with
insidiously proprietary smart tags, XAML, WFP, TFS, and other stack
specific collections of dependencies.
This is the
interoperability thicket that South Africa so boldly charges into.
If the OASIS ODF TC, and the ODF community of applications do not get
there act together soon, odds are that South Africa will find
themselves in the same predicament as Massachusetts. All
dressed up in ODf with nowhere to go but MS-OOXML.
People have
accused us of overstating the ODF interoperability problems. The lord
of the garage gestapo and his minions insists that these
problems can be fixed. Let's hope they are right. Let's hope
that South Africa can pull off the implementation of ODF on something
more than 24 desktops. And let's hope that this time, the ODf
community comes out of the blogosphere and shows up for this
important implementation battle instead putting the entire burden on
SA as they did in Massachusetts.
A few
more failures like Massachusetts and Microsoft is going to be
wondering why they ever went through the problems of submitting their
proprietary xml to ISO to begin with. Unless and until ODF can
successfully challenge MS-OOXML as a real world "implementable"
alternative, we're going to find ourselves stuck in the MS Stack for
years to come. ISO approval or not.
~ge~
.
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.