Linked by Thom Holwerda on Fri 25th Jan 2008 21:31 UTC, submitted by WillM
Microsoft "For years, the poster child of the anti-open source movement was Microsoft, with its proprietary software model. In recent years, however, the company has changed its views, starting an open source software lab to work on interoperability issues. It's even become a purveyor of its own open source-approved licenses. What do these efforts mean? For Sam Ramji, Microsoft's director of open source technology strategy, they indicate the company is 'open' for business."
Thread beginning with comment 298007
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Interoperability issues
by Jemm on Sun 27th Jan 2008 20:26 UTC in reply to "RE[2]: Interoperability issues"
Jemm
Member since:
2005-07-25

That's nice. Why couldn't Microsoft have simply sat on the Oasis committee to ensure their obviously deep seated concerns over ODF were addressed in the standard


From: http://openxmlcommunity.org/openxmlmyths.aspx

"Why didn't Microsoft simply work with the original ODF people to help build their specification?

There are at least four good reasons why this was not a valid option:

1. ODF started out and was largely completed as an XML format specifically supporting OpenOffice with a tight scope around that product.
2. It was not until 2005 that the ODF specification was offered up as a general XML office document format and consequently renamed to ODF.
3. No opportunity existed for Microsoft to actually participate in this full process given both the original scope and the six months between the re-naming of the spec to ODF and its subsequent approval by OASIS as a standard.
4. The scope of the ODF specification never included even the basic requirements that Microsoft required to support a fully open format and nor did the OASIS technical committee want to include these requirements. They include:
* Spreadsheet formulas
* Tables in presentations
* Accessibility features
* Custom-defined schema support
* Custom metadata"


That link has many other myths explained, too.

I think ODF is good as a general format for exchanging information between products, a bit like RTF is for formatted text. Before ODF could work well with the Microsoft Office, it would have to be expanded to be as large as Open XML is now. Microsoft didn't make the spec that large just for the kicks.

I don't consider Open XML to be pretty as far as its XML is considered, but much better than previous binary formats. It is not a replacement for ODF, but it doesn't aim to be one, either (different goals).

I'm also curious to see, how all the implementors of the ODF aim to keep the format compatible between products in the future. Each new feature in the office suite will need modifications to the standard.

Will IBM's offering and OpenOffice be compatible after, say, next two versions? How about all the rest supporters? Or will the ODF-standard be revised and approved first and then implemented by each vendor? How can they compete with features if specs are done together? Or will it be like it is now with web browsers and HTML where someone is always behind (like IE is playing catchup now)?

Reply Parent Score: 1

TemporalBeing Member since:
2007-08-22


I think ODF is good as a general format for exchanging information between products, a bit like RTF is for formatted text. Before ODF could work well with the Microsoft Office, it would have to be expanded to be as large as Open XML is now. Microsoft didn't make the spec that large just for the kicks.


OpenXML (OOXML) is that long because Microsoft just did a dump of their memory information to XML, just like their older binary formats were dumps to a binary file.

OpenXML does not need to be anywhere near as long as it is if it were truly focused around file formats as opposed to internal program notations. The sad fact is Microsoft is focused around "internal program notations" as a file format - thus OOXML and 6000+ pages of incomplete documentation.

I don't consider Open XML to be pretty as far as its XML is considered, but much better than previous binary formats. It is not a replacement for ODF, but it doesn't aim to be one, either (different goals).


I'll agree that OOXML is not trying to meet the same goals as ODF. While ODF aims to be a file format, OOXML just aims to be an XML version of the older binary memory dumps that Microsoft did for a file format previously. Their (Microsoft's) goal was simple - make it as length and incomprehensible as possible so that no one else could adequately implement it in such a manner as to actually be comparable to MS Office.

I'm also curious to see, how all the implementors of the ODF aim to keep the format compatible between products in the future. Each new feature in the office suite will need modifications to the standard.


It's in the ODF standard already, and you can already see how this functions by looking between ODF 1.0 and ODF 1.1. It's left to XML name spacing, and works beautifully. So it's no a problem for ODF at all.

Will IBM's offering and OpenOffice be compatible after, say, next two versions? How about all the rest supporters? Or will the ODF-standard be revised and approved first and then implemented by each vendor? How can they compete with features if specs are done together? Or will it be like it is now with web browsers and HTML where someone is always behind (like IE is playing catchup now)?


This is no different than how will two browsers compare to supporting current and future web standards. Or how any image program does with supporting image file formats. Or any number of similar things.

Fact is, people will support it, implement, and then add new features that don't break the implementation so that others can also be successful at reading the same file even if they don't support the extras. I'm thinking of doing such an extension to OpenOffice and perhaps another Open Source ODF office suite to try to add some functionality to ODF myself. If it gains support, it'll likely be pushed to the OASIS committee for consideration as part of ODF proper.

All the implementors have to do is implement the standard honestly and in such a way that any expanded functionality does not break the implementation.

Microsoft, however, likely has no plans of doing that with OOXML - they already implement a number of things in Office 2007 that break its against the spec. So even if you implement the spec as written (all 6000+ pages of it) you still won't be compatible with MS Office.

Comparatively, implement the 700+ (749?) pages of ODF and you'll be compatible with all ODF implementations. ;-)

Reply Parent Score: 1

RE[5]: Interoperability issues
by Jemm on Tue 29th Jan 2008 07:15 in reply to "RE[4]: Interoperability issues"
Jemm Member since:
2005-07-25

The sad fact is Microsoft is focused around "internal program notations" as a file format - thus OOXML and 6000+ pages of incomplete documentation.


Yes, more or less it can be called memory dumb or data that's serialized into XML. People also often forget that the 6000+ pages includes documentation for three products + common parts like packaging, DrawingML etc. That makes less than 2000 pages/product, which sounds quite realistic for that complex products. When line-spacing is halved, there are even less pages ;)

Also, if you leave some "maybe nobody needs these" -parts out, like say spreadsheet formulas (10 pages in original ODF spec vs. 384 pages in openxml spec), then you of course save many extra pages ;)

I think it is better that there is extra information available than too little. Btw for those complaining the documentation is incomplete; now the obscure "AutoSpaceLikeWord95" etc parts are fully documented (but deprecated as they will be phased out):

"Compatibility Settings - AutoSpaceLikeWord95

There has also been a lot of interest in the Compatibility Settings that include the famous “AutoSpaceLikeWord95” or “truncateFontHeightsLikeWP6”. Ecma worked to provide in this batch the full information necessary to implement all compatibility settings without any dependency on any product. This documentation is provided for the completeness of the spec, but these features should not be used when creating new documents. I’ll discuss the compatibility settings in more detail in my next post."

http://blogs.msdn.com/brian_jones/archive/2007/12/21/500-national-b...

Fact is, people will support it, implement, and then add new features that don't break the implementation so that others can also be successful at reading the same file even if they don't support the extras.


Ok, I had always thought that ODF aims for full fidelity between products, but if the goal is just to be able to open the same document on different products, then it is easier to achieve. One can't really trust that the document will look exactly the same on all products, but I guess that's what PDF is for.

Even Microsoft will be able to add that level of support for ODF to Office easily (ODF was standardized too late for Office 2007 of which development had already started after O2003).

I'm quite sure Microsoft will officially support importing and exporting of ODF in the next version of their Office as ODF really isn't that big a threat to them technically. Microsoft is more worried that governments etc will choose ODF only because it is ISO (and OOXML is not).

Microsoft, however, likely has no plans of doing that with OOXML - they already implement a number of things in Office 2007 that break its against the spec. So even if you implement the spec as written (all 6000+ pages of it) you still won't be compatible with MS Office.


Sure they will update the Office to support the standard once it gets finalized after comments and updates. With patches and translators current products and Open XML documents can be moved to support the finalized spec, just like .doc files are converted now.

Open XML doesn't require to support all the features in the spec before you can create 100% compatible files. If 100% transferability can't be expected from the ODF, why it should be always expected from OOXML?

Full specs are for those that really want to support all the possible features or some segment specific to their needs. If I wanted to make a tool that reads/writes simple MS Office documents, it wouldn't be much harder than it would be for ODF.

So, one can ignore parts of the Open XML specs that they don't need and still make compatible documents. Just like in ODF the vendor specific extras can be ignored as long as the baseline requirements are met.

Comparatively, implement the 700+ (749?) pages of ODF and you'll be compatible with all ODF implementations. ;-)


As it just turned out in this thread, ODF won't be 100% transferable between products - just the lowest common denominator due to vendor-specific extras.

Also, one still needs to learn and implement completely the referenced standard formats, like SVG and build support for them from the start, since they are extended (see my another post). Already made third-party components won't help, unless sources are available.

After this thread I'm even more convinced it is better there are two formats as they really are for different needs. Combining them would be much bigger mess than asking other party which format they prefer (ooxml, odf, pdf, xps).

I just wish there wasn't so much FUD and hatred between the camps ;) If some co-operation required me to send ODF-documents, I'd just download some translator for the Office - no problem.

Reply Parent Score: 1