[odf-discuss] What is actually necessary and found only in OpenXML?

[marbux]

My apologies for not getting back to you on this, Lars. I have been spending
too much time on other matters.

On 5/28/07, Lars D. Noodén <lars at umich.edu> wrote:
>
> On Fri, 25 May 2007, marbux wrote:
> [snip]
> > In terms of market demand, Microsoft is experiencing rather incredible
> > uptake
>
> From what I gather, it has been unprecedently low, even counting the flop
> that MSO 2003 became.  Incredible demand. :)
>
> > of its apps built atop the Sharepoint and Exchange server XML hubs,
> > to an extent that the Wall Street Journal last month referred to
> Sharepoint
> > as a "sleeper" that Microsoft had embedded in its business software,
>
> Unfortunately it appears that Sharepoint adds nothing more than vendor
> lock-in.  I've tried to encourage the OOo vs MSO reviews to look into the
> matter.  It's not getting the attention it deserves, and I suspect MS
> would prefer to keep it that way.


I both agree and disagree depending on particular points in your discussion.

Yes, Sharepoint is a vendor lock-in tool. But I see more critical issues
afoot in the Microsoft "line of business" strategy.

First, from the standpoint of Microsoft's former Upgrade Treadmill business
plan for Office itself, the free download Office 2007 Compatibility Packs
for Office XP and 2003 are equivalent to giving away Office for free. Office
itself is no longer the sole lock-in point. Microsoft is migrating its
primary lock-in point up the stack to its Sharepoint and Exchange Server XML
hubs. This responds to the commodification of the client-side office suite
market well under way and the reality that Microsoft has been forced to
disclose much of MOOXML in Ecma 376.

Second, Microsoft innovation in the office suite itself is nearly at a
standstill. Office 2007 brings only two major new features to the party,
MOOXML and a face-lift. Microsoft has transferred most of its Office
development budget to the new line of business apps on the other side of the
XML hubs from  Office.

That situation suggests that Microsoft  is migrating its office productivity
business from the client side to the server side, particularly in the areas
of collaboration and integration within an SOA that is already bound to
Microsoft processes. Sharepoint and Exchange servers are the bridge being
used for the migration. Over the mid-term, Office itself will function more
as an In-box for the server side than as a complete client-side solution.

Whether Microsoft will eventually abandon Office entirely remains to be
seen. But my strong suspicion is that if Microsoft saw any future in
client-side office suites, it would have begun building a new one years ago
rather than sticking with its incredibly brittle page layout engines in the
three major components that are presently only loosely integrated for
largely historical reasons.

In other words, I believe Microsoft sees the client-side office suites as
obsolete dinosaurs. But caveat that I may be projecting my own beliefs here
somewhat. In my view, client-side office suites have been obsolete since
networking became ubiquitous. The client-side office suites were designed
for the lowest common denominator of the personal computer "sneaker net"
era. Their basic architecture was premised on the stand-alone personal
computer, not on a networked environment.

Third, the Microsoft line of business apps built atop the XML hubs do in
fact offer pretty respectable gains in worker productivity. We may
reasonably fault the lock-in aspects, but Microsoft is offering customers
something in exchange that we currently can not offer because of, e.g., the
lack of an ODF XML hub, interop rats' nests in ODF and implementations,  the
lack of a common language for embedded scripts, and the lack of normative
ODF tags for advanced business processes such as document assembly, document
routing within a business process, etc, and perhaps most importantly, an
inability to interoperate without lossiness with the Microsoft office
productitivty stack, a barrier that blocks ODF apps from being integrated
within business processes already locked in to Microsoft applications.

Fourth, the substitutability of software goods is no better than the quality
of the interoperability between them within the given use case being
examined. This factor has been largely ignored by the ODF community since
day 1. ODF is in many ways a technically excellent specification, but the
reality of Microsoft's monopoly market share has been ignored throughout
ODF's development except for the conformance section's foreign elements and
attributes discussion, which is presently toothless.

There are two major use cases left unaddressed by the current crop of
interoperability conversion tools: [i] migration to ODF apps within the
context of Microsoft-bound business processes with high fidelity migration
requirements; and [ii] integration of ODF apps on an ongoing basis within
such business processes. The TC has simply ignored such practical concerns,
in effect conceding the enterprise and government markets to Microsoft but
for the costly "rip out and replace" migration scenario.

Fifth, from maintaining the Fellowship Precedent page, it is clear to me
that ODF is winning many government adoption decisions, but few government
programs are actually implementing ODF except for those with very low data
retention requirements such as educational programs. So in many respects,
the ODF adoption decisions tend to be "here is what we want" announcements
rather than "here is what we are doing" announcements.

In other words, government is saying they want to escape vendor lock-in
formats, but is waiting to see if the vendors will provide a practical means
for them to achieve it. See e.g., IDABC requirements here, <
http://www.openforumeurope.org/index.php?option=com_content&task=view&id=937&Itemid=1>.
Thus far, the answer from the ODF vendors has been "no." The use cases
mentioned above remain unaddressed except by the TC adding even further MS
interop barriers to the ODF specification.

Sixth, I suspect the situation is no different in the enterprise market,
although I do not have data in that regard.

Seventh, my comment about market uptake was addressed to Sharepoint's market
share rather than to Office 2007's. According to the Wall Street Journal
article, Sharepoint has achieved a 65 per cent market share already and the
major Microsoft competitors were caught napping in that regard. They have no
equivalent product. I think if you look only at Office 2007 uptake, you miss
a major factor, the free Office 2007 Compatibility Packs for MOOXML for two
prior versions of Windows Office, soon to be available for the last Mac
version as well. As users of those prior versions begin receiving MOOXML
documents from others, they will install the Compatibibility Packs or
upgrade to Office 2007. Then they are one download away from the free
version of Sharepoint Server, and from there onto the paid version.

From my perspective, Microsoft does not need to achieve large market
penetration with Office 2007 for its strategy to succeed. It is market
penetration of MOOXML across 4 versions of Office that counts, which of
course is why Microsoft is giving away the Compatibility Packs. When users
begin receiving MOOXML documents with Sharepoint Server tags included, The
driver for the Sharepoint/line of business strategy is there.

From my perspective, following the anti-DRM backlash that Palladium
> sparked, MS started to obfuscate Palladium by spreading out the DRM
> components, Sharepoint being one.  People tend not to see how these
> components fit together, and as they are not in the media


I see DRM as a fairly minor component of the line of business strategy,
although the new media server add-on for Sharepoint is certainly a
component.

Going to Sharepoint probably means that you will in practice not be able
> to exchange any documents with people running non-MS software or even
> older versions of MS software.


Older than Office XP, yes. For that version and newer there are the Office
2007 MOOXML Compatibility Packs.


Those few suckered into a Sharepoint version of MSO appear to get suckered
> into a whole new world of incompatibility and vendor lock-in.  Sharepoint
> is IMHO what MS is trying to get into the market, the former is less
> important strategically.  It brings with it a slew of labor intensive
> boondoggles that will quickly through any data center into crisis
> managmenent mode and thus on MS treadmill.


I don't think it is going to be only a few. And to my knowledge no one is
out there spreading the warning that network administrators need to roll out
group policies that limit Office users to read-only MOOXML.

>  noting that IBM and other competitors were caught napping. <
> >
> http://online.wsj.com/article/SB117737738757279866.html?mod=todays_us_marketplace
> >.
>
> The article is subscriber-only so I can't comment on the content.  And if
> it it contains a warning for MS customers regarding the problems of
> Sharepoint, it is effectively censored.


No, no vendor lock-in warnings there that I recall, although I no longer
have access to the article's full text myself. I should have saved it to
disk. :-(


> So I think it fair to say that as to MOOXML, not EOOXML, there are
> features
> > that are "already widely needed asap by most public administrations (or
> that
> > would actually be very useful and utilized as soon as it is available)
> but
> > is missing in ODF." ODF has neither the needed markup
>
> The important item there is to drive home the point MOOX and Ecma 376 are
> *not* the same thing.


And that there is no reference editor for Ecma 376.


There are four specifications in play, in order of market relevance:
>
> + ODF aka ISO/IEC 26300
> + UOF
> + MOOX
> + Ecma 376


I agree with Ecma 376 ranking last but think in terms of market relevance, a
good argument could be made for ranking MOOX first for the reasons discussed
above. For ODF to be ranked first, in my view it would require that the ODF
app <> Microsoft stack interop barrier in the high-fidelity use case
scenarios be broken. Otherwise ODF is effectively limited to users with far
lower fidelity interop requirements. That is the low-hanging fruit ODF has
been picking so far; but the low-hanging fruit won't last long. We need a
ladder to the higher-hanging fruit or Microsoft gets to pick all of it.

> nor is there any ODF equivalent of Sharepoint Server.
>
> That IMHO is a Very Good Thing (tm).


I disagree, although I do agree as to the vendor lock-in aspects of
Sharepoint/MOOXML. ODF desperately needs an XML hub to bridge from the
client-side ODF apps to server-side business process apps. WebDAV ain't good
enough. :-)

Much of the squawking for Ecma 376 and MOOX centers around
> "interoperability" with legacy documents.  There are several great flaws
> with that claim.
>
> First, only leaving the documents in the original format, unchanged
> guarantees no loss of data.  Conversion to whichever format Sharepoint DRM
> requires risks loss or corruption and entails great investment of staff
> time.  Period.
>
> Second, and probably most importantly, to use the legacy documents, the
> applications need nothing more or less than the full availability of the
> specifications.  Noise about other formats or specifications is irrelevant
> in that question, regardless of which orific it originates from.  And, if
> I recall correctly, MS is defying the courts by not providing the specs as
> demanded.


I suggest reexamining your position from the standpoint of the use cases
discussed above and the reality that complete  disclosure of the
specification for the binary formats is unlikely to happen soon, if ever.
Microsoft's success in dragging out the similar disclosures required by the
European and U.S. antitrust  orders is a clear message that in Microsoft's
view it takes far more than a government order to make it disclose
information it wishes not to disclose.

I think the argument is very strong that Microsoft is not entitled to an
International Standard that stresses the importance of compatibility with
the binary formats but does not disclose their specifications. But the ISO
battle is only a sideshow unless we can penetrate the high-fidelity
interoperability barrier to give the market what it requires, a non-lossy
escape route from vendor lock-in formats.

My assessment is that the likelihood that an interoperability  solution will
emerge from the OASIS Office TC is vanishingly small, at least without
strong external pressure being applied. Sun is very determined to maintain
its monopoly position in ODF applications and manipulates its leverage as
the owner of the monopoly products and the features they support to maintain
control of the TC.

> ... I believe we can no longer in good faith push the either/or issue.
>
> I respectfully, but vehemently disagree.  While the ODF path is not all
> roses, I can't see any positive outcome possible for spending time on
> either MOOX or Ecma 376.  That would simply delay much needed progress in
> the domain of productivity applications.


I agree as to Ecma 376. But absent an MS applications interoperability
capability in ODF, I have ethical and practical issues with pushing ODF as
*the* interoperability solution. I think harmonization of MOOXML (not Ecma
376), with ODF providing the common functionality is the ethical and
practical way forward for the ODF advocates, along the guidelines of the
points raised by IDABC linked above.

I strongly suspect that those who voted for creating yet another MS
interoperability breakpoint to the ODF specification have scant
comprehension of the damage they inflicted on the ODF advocates' ability to
push OASIS ODF as *the* interoperability solution. They played right into
Microsoft's hands, giving Microsoft all the ammunition it needs to prove
that some standardization organization other than OASIS will have to be used
to meet its own development requirements.

> All relevant specifications have major problems.
>
> This is true, but the scale of the problems is something to take into
> consideration.  ODF is much further along and the problems with MOXX or
> Ecma 376 seem insurmountable.  The latter two exist largely to waste
> developer cycles while the M$ lobby machine rolls on.


I think your view is too simplistic. MOOXML is way out in front of ODF in
terms of compatibility with those billions of binaries Microsoft likes to
talk about. It is also years out in front in terms of interoperability
within high fidelity business processes, even ignoring the backward
compatibility with the binaries. And we have far more need to be
interoperable with Microsoft's software than Microsoft has for its software
to be interoperable with ODF apps, until we break the high fidelity
interoperability barrier. Microsoft already has the its user base ocked in.
If we offer them no escape route, Microsoft wins.

And thus far, the TC has functioned to deny users that escape route. The TC
is far more the servant of its participating developers than it is the
servant of users' requirements in the relevant markets.

True, ODF is farther along in terms of the numbers of developers supporting
it. But Microsoft has the critical overwhelming lead in numbers of users of
its software, so ODF's developer advantage is largely negated.

I think it a hopeful sign that IBM is stirring and has made some of the
right noises more recently, such as coming out for convergence of MOOXML and
ODF, proposing an Interoperability Subcommittee on the TC, and pushing for
the harmonization of UOF and ODF. But whether IBM is willing to stand up to
and counterbalance Sun's mismanagement of the TC remains to be seen.

In the meantime, with an unmistakable vote against compatibility with MS
Office recorded in the TC minutes, I think the convergence/harmonization
theme is the only defensible position for the ODF advocates to take. If we
do not distance ourselves from the TC's actions by that or some other
effective means, Microsoft *will* ram the lists amendment vote squarely down
our throats.

We can not longer defensibly paint the situation as a black hat/white hat
disagreement. We walk into a trap set by the TC action if we do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20070602/cb94c854/attachment-0001.html