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

[Lars D. Noodén]

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.

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

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.

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.

>  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.

> 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.

There are four specifications in play, in order of market relevance:

+ ODF aka ISO/IEC 26300
+ UOF
+ MOOX
+ Ecma 376

> nor is there any ODF equivalent of Sharepoint Server.

That IMHO is a Very Good Thing (tm).

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 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.

> 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.

-Lars

Lars Noodén
 	Ensure access to your data in the future
 	http://opendocumentfellowship.org/about_us/contribute