OpenDocument's feed | Diigo Group

SharePoint: A Legal Killer App | ABA Journal - Law News Now

Tue, 17 Jun 2008 18:29:48 -0000

Highlights and Sticky Notes:

even a solo lawyer can use SharePoint for less than $50 per month. Microsoft has continued to refine the tool, and it might be time to put SharePoint on your technology to-do list.

SharePoint is a software platform used for hosting customizable websites where multiple users can share documents and work on projects

The key to SharePoint is something called “Web parts,” small software applets or controls that provide a set of functions, like a task list or a discussion board.

Web parts then act as controls that interact with other programs and pull information from a variety of sources, including law office programs, databases and websites, all without the user needing to know anything about the underlying programming.

The result is a personalized portal page where you and everyone else given access can find, see and manage all of the relevant information for your project in a familiar, easy-to-learn Web format.

web-parts = applets that pull information from an external program or source [on the office server or on the web] and deploy the information on the "SharePoint" website in boxes built into the overall page posted by mhedayat

Click on a link and you open a document or read an e-mail without moving from program to program. And with a few quick clicks you can move your list of documents around the page or change fonts and colors without affecting anyone else’s experience

Tags: application collaboration e2.0 law2.0 lawyers microsoft sharepoint web-based

Posted by: mhedayat

Microsoft Expands List of Formats Supported in Microsoft Office: Move enhances customer choice and interoperability with Microsoft’s flagship productivity suite.

Mon, 02 Jun 2008 06:32:18 -0000

Highlights and Sticky Notes:

REDMOND, Wash. — May 21, 2008 — Microsoft Corp. is offering customers greater choice and more flexibility among document formats, as well as creating additional opportunities for developer and competitors, by expanding the range of document formats supported in its flagship Office productivity suite.

With the release of Microsoft Office 2007 Service Pack 2 (SP2) scheduled for the first half of 2009, the list will grow to include support for XML Paper Specification (XPS), Portable Document Format (PDF) 1.5, PDF/A and Open Document Format (ODF) v1.1.

It will also allow customers to set ODF as the default file format for Office 2007. To also provide ODF support for users of earlier versions of Microsoft Office (Office XP and Office 2003), Microsoft will continue to collaborate with the open source community in the ongoing development of the Open XML-ODF translator project on SourceForge.net.

The wookie here is the lack of native ODF support in older versions of MS Office, together with the earlier-announced intent to develop a new special API for other vendors to add native file suport via MS Office plug-ins. As part of its previous effort to backport OOXML support to earlier versions of Office and to port it to Office for the Mac, Microsoft engineers internally added OOXML support using the Office 2003 native file support to the Office 2003 native file support plug-in APIs, ripped it out of Office 2003 for Office 2007, wrapped it as a module with the same interface as the older APIs, then back and cross ported the module to the earlier versions and Office for the Mac. The new APIs for use by competitors must of necessity be integrated with the existing module. Anytime Microsoft needs to issue a bug fix for OOXML in the earlier versions, it would seem that the most efficient manner for Micriosoft to do so would be a patch for all versions that support OOXML. A patch that adds ODF support for the other Office versions would seem to be a fairly trivial task that could be rolled out with the patches that bring the older versions up to date with the final version of ISO/IEC OOXML In my view, the only conceivable reason for the new APIs is to limit the Office functionality available to competitors who write plug-ins for Office. posted by marbux
Another key point in the silver lining here is that Microsoft will add native support for ODF to Microsoft Office 2007 SP2 "and beyond". However support for ODF in previous versions of Microsoft Office will not be native but through the CleverAge Converter on SourceForge. It will in other words be XSLT-based translation of ODF to/from OOXML with the known issues with translation such as bad quality and performance. http://idippedut.dk/post/2008/05/Document-translation-sucks-(When-Rob-is-right2c-hes-right).aspx posted by jlundstocholm

“Microsoft’s support for ODF in Office is a great step that enables customers to work with the document format that best meets their needs, and it enables interoperability in the marketplace,” said Roger Levy, senior vice president and general manager of Open Platform Solutions for Novell Inc. “Novell is proud to be an industry leader in cross-platform document interoperability through our work in the Document Interoperability Initiative, the Interop Vendor Alliance and with our direct collaboration with Microsoft in our Interoperability Lab. We look forward to continuing this work for the benefit of customers across the IT spectrum.”

Tags: microsoft msoffice 14 msoffice 2007 odf pdf xps

Posted by: jlundstocholm

Microsoft Office for 91 percent off! | Computerworld Blogs

Wed, 28 May 2008 17:50:11 -0000

Highlights and Sticky Notes:

The New York Times' Bits tech blog is reporting that anyone with a .edu e-mail address, whether they are a current student or not, can buy Microsoft Office Ultimate for $60, or 91% off until May 16.

1) The Web site to purchase Office Ultimate at a discount is called "The Ultimate Steal."

2) Microsoft's senior VP in charge of Office Chris Capossela confirmed to the Times that anyone with a .edu e-mail address is eligible for the discount. Most colleges and universities grant their alumni graduates .edu e-mail addresses.

I ordered just before it was supposed to end the first time at the end of April. I had not problem except that it took forever for the DVD to arrive. I was never asked to show any other proof of enrollment except giving them my .edu address. I also downloaded the exe and had no problems with it (got the DVD just in case though).

Tags: microsoft office pricing

Posted by: marbux

BetaNews | Microsoft's Matusow and Mahugh on Office's move to open format support

Tue, 27 May 2008 07:08:59 -0000

Highlights and Sticky Notes:

One of the most intriguing parts of today's development, especially for open source developers and ODF proponents, concerns Microsoft's upcoming release of its API's for document format plug-ins for the forthcoming "Office 14:"

A second scenario is, perhaps there's a format that we have not implemented or supported in Office, but for whatever reason, a particular organization wants to support that format. They can write their own support and integrate it into Office, so that it's very seamless; and from the user experience point of view, it just looks like yet another format Office supports.

But will developers be able to set compatibility modes so that functionality in MS Office that can not be saved to another document format is not available? If not, there can be no ireliable nterchange of documents between different IT systems without loss of fidelity. posted by marbux

The APIs, BetaNews learned, will be released under the auspices of the interoperability initiatives the company launched in February. Those apply to documentation and information (note, not programs) that Microsoft says it will freely release to developers without them having to obtain a license; and those initiatives apply to Microsoft's "high-volume software" -- and certainly Office qualifies as that. A careful read of these initiatives' wording would indicate that Microsoft leaves itself no option for using intellectual property leverage against anyone who should make a format plug-in for Office 14 -- even a "better Open XML than Open XML," since that's no longer Microsoft's property either.

Tags: compatibility mode mahugh microsoft native file support apis

Posted by: marbux

BetaNews | Microsoft's Matusow and Mahugh on Office's move to open format support

Tue, 27 May 2008 07:01:19 -0000

Highlights and Sticky Notes:

DOUG MAHUGH, program manager for ISO 29500-based products, Microsoft: One thing to be very clear about here is this: When we say, "support for ODF in [Office] SP2," we intend to write very compliant ODF documents when you save a document. However, it's not a given that everything you can do in the Office UI is savable under ODF. As you're alluding to, there are things -- SmartArt, conditional formatting, things like that -- that we have in Office and that are popular features, where there is no way to save those in ODF, currently.

The way we're approaching that, I can share a little bit with you: We're not throttling the UI, as you describe, where certain things are disabled. Rather, at the time you save, we're telling you, "Hey, you're saving in this other format; some information in this document may be lost." That sort of thing. And let me tell you why we made the decision to do it in that particular way: There are situations where some of that functionality may be very useful to the user, even though it can't be serialized out to the format that they're saving in.

One might suppose that the new API discussed on the following page will similarly not allow developers to set a compatability mode in Office apps. Note that the existing APIs do allow that, so one might suspect that disabling the ability to set a compatibility mode is one of the reasons for the new API. posted by marbux

The engineering decisions that were made in the original creation of ODF represent the engineering pathway and the innovations that were happening in the OpenOffice space. The engineering decisions and development pathway for Open XML represents that which was happening in [Microsoft] Office, and the feature sets are not in parity. In fact, there's a superset of features within the Microsoft Office set, but there are certainly features that are exclusive to OpenOffice that do not get covered in Microsoft Office.

We really hope to see ODF move to JTC 1 / SC 34 maintenance

Tags: compatibility mode mahugh matusow microsoft native file support apis odf

Posted by: marbux

Doug Mahugh : Office support for document format standards

Fri, 23 May 2008 06:27:18 -0000

Highlights and Sticky Notes:

Hi, Jesper. according to another article I found later, the new APIs (I assume it should be plural rather than singlular) will allow addition of formats other than ODF, so I apparently got that part wrong. On the Sharepoint example, I wasn't sufficiently clear and apologize. Assume you create a document in MS Office that invokes Sharepoint functionality, then you save it as ODF and ship it off to a co-worker using OOo. The OOo user wants to send it back to you for further processing. But if saving to ODF in Office wipes the Sharepoint metadata, you've got data loss on the outbound trip. The path you suggest would work at least in theory (I haven't heard any reports yet of the documentation on the Sharepoint APIs) if Sharepoint were used as an intermediary hub. But the Sharepoiint document may not be accessible to the co-worker, e.g., because of page security settings. I anticipate that there would be many cases where only one end of the trip has access to the hub, so there's a need to keep the path open that bypasses the hub and for it to be non-lossy. There is an article on BetaNews by Scott Fulton that interviews a couple of the Softies. They said that there will be lots of Office functionality that won't be able to be saved in ODF, that they're not planning a compatability mode that would block use of features that can't be saved to ODF, and that they're not planning to go beyond the features specified in ODF 1.1. So if they carry through on what they said, the outbound trip to ODF implementations will be lossy. I think the real problem with the Sharepoint specs and other documentation Microsoft is releasing is that it isn't in a standard where a technical committee could say yea or nay on whether it is suffiiciently specific and where the specs can be made vendor-neutral. In other words, that Micrsooft is in control of the specifiation rather than a standards body. Microsoft got away so far with creating a de facto standard for the line of business functionality that the OOXML spec says is one of the two major justifications for Microsoft having its own personal internatinal standard. But the OOXML spec doesn't specify the functionality offered to justify it. Same situation as with the justification based on the need for compatibility with legacy documents but no specification of the binary formats in OOXML. (IBTW, I'm not an ODF fan and I'm not coming from that direction. I have issues with standards that don't place everyone on an equal competitive footing.) posted by marbux
Hi, Jesper. according to another article I found later, the new APIs (I assume it should be plural rather than singlular) will allow addition of formats other than ODF, so I apparently got that part wrong. On the Sharepoint example, I wasn't sufficiently clear and apologize. Assume you create a document in MS Office that invokes Sharepoint functionality, then you save it as ODF and ship it off to a co-worker using OOo. The OOo user wants to send it back to you for further processing. But if saving to ODF in Office wipes the Sharepoint metadata, you've got data loss on the outbound trip. The path you suggest would work at least in theory (I haven't heard any reports yet of the documentation on the Sharepoint APIs) if Sharepoint were used as an intermediary hub. But the Sharepoiint document may not be accessible to the co-worker, e.g., because of page security settings. I anticipate that there would be many cases where only one end of the trip has access to the hub, so there's a need to keep the path open that bypasses the hub and for it to be non-lossy. There is an article on BetaNews by Scott Fulton that interviews a couple of the Softies. They said that there will be lots of Office functionality that won't be able to be saved in ODF, that they're not planning a compatability mode that would block use of features that can't be saved to ODF, and that they're not planning to go beyond the features specified in ODF 1.1. So if they carry through on what they said, the outbound trip to ODF implementations will be lossy. I think the real problem with the Sharepoint specs and other documentation Microsoft is releasing is that it isn't in a standard where a technical committee could say yea or nay on whether it is suffiiciently specific and where the specs can be made vendor-neutral. In other words, that Micrsooft is in control of the specifiation rather than a standards body. Microsoft got away so far with creating a de facto standard for the line of business functionality that the OOXML spec says is one of the two major justifications for Microsoft having its own personal internatinal standard. But the OOXML spec doesn't specify the functionality offered to justify it. Same situation as with the justification based on the need for compatibility with legacy documents but no specification of the binary formats in OOXML. (IBTW, I'm not an ODF fan and I'm not coming from that direction. I have issues with standards that don't place everyone on an equal competitive footing.) posted by marbux

If you're an Office 2007 user, the image above probably looks pretty familiar. But look close, and you'll see some Save-As options you've not seen before here: OpenDocument, and (unless you have the existing add-in) PDF & XPS.

This is a screen shot of a pre-release copy of SP2 (Service Pack 2) for the 2007 Microsoft Office System, showing the new document format standards that we'll be supporting starting with SP2.

There is new information today about the planned release of v2.0 of the ODF translator on the ODF translator team blog. The SourceForge translator projects will continue to move forward, and Microsoft will continue to be an active participant in these projects.

Third-party translators. We anticipate that some developers may want to take over the default ODF load and save paths, so that they can plug in their own translators for ODF, and we'll be providing an API in SP2 that enables this scenario. This means that if a developer disagrees with the details of our approach and would like to implement ODF for Office in a different way, they're free to do so and can set it up such that when a user opens an ODT attached to an email or from their desktop, it will be loaded through their ODF code path.

The Third-party translators discussion of the forthcoming new API suggests that it is for ODF only, and thereby implicitly that it will not be a tool for accessing the full functionaolity of MS Word, i.e., that only the functionality specified in ODF 1.1 will be available. E.g., no control of Sharepoint functionality or manipulation of the Microsoft cloud through the API from OpenOffice.org via ODF. . posted by marbux
The Microsoft cloud depends heavily on OOXML, and that is likely not going to change. Are you saying that you'd prefer a plug-in mechanism in SharePoint as well? I believe the protocols used by SharePoint are included in the specs now provided. Won't that do (apart from the non-commercial usage of the specs) posted by jlundstocholm

Tags: interop microsoft odf strategy

Posted by: jlundstocholm

Alliance Calls on Microsoft to Act on Its Commitment to Implement Support for ODF

Fri, 23 May 2008 04:02:58 -0000

Highlights and Sticky Notes:

The ODF Alliance today greeted with scepticism Microsoft's announcement of its intention to include support for the OpenDocument Format in the first half of 2009.

Tags: interop microsoft msoffice odf odf alliance

Posted by: marbux

Microsoft Embraces ODF, At Last [on Simon Phipps, SunMink]

Fri, 23 May 2008 02:42:45 -0000

Highlights and Sticky Notes:

Of course, I might also reflect on the fact they are finally doing exactly what Stephe Walli said they ought to do to kill ODF. But for now, it's huge, warm congratulations on giving your customers the freedom to leave and the confidence to stay - and a small British mutter of "about bloody time".

If one reads the linked piece from 2005 by former Microsoft exec Stephen Walli, , one may only scratch one's head over Phipps' "small British mutter of 'about bloody time.'" It seems to read as an endorsement of Microsoft killing ODF. posted by marbux

Tags: antitrust microsoft odf sun

Posted by: marbux

OpenOffice.org business manager John McCresh on ODF support in MS Office

Fri, 23 May 2008 02:22:22 -0000

Highlights and Sticky Notes:

There was a certain inevitability that Microsoft would be forced to bow to market pressures and announce its acceptance of ODF. However, Microsoft’s traditional approach to standards has been characterised as Embrace, Extend, Extinguish - i.e. attempt to claim ownership and take control of a standard through abuse of its near monopoly position.

Proponents of ODF need to defend against this by setting up independent testing for software conformance with the standard. The testing needs to be accessible not just to the Suns and IBMs of this world - but also the KOffices.

While proponents of ODF are celebrating that a victory has been won, it is more likely that the real battle is only just beginning.

One might reasonably wonder how one would go about building further tools to test for conformance with a standard that has almost no mandatory conformance requirements other than validation against the schema after all foreign elements and attributes (application-specific extensions) are removed. The validation tool specified pre-existed ODF. Methinks that the world verges on learning that ODF is a standard in name only and that ODF interoperability is a complete and utter myth no more accurate than the corresponding myth of OOXML interoperability that was thoroughly debunked long before OOXML became an international standard. posted by marbux

Tags: interop microsoft msoffice odf

Posted by: marbux

Rapid - Press Releases - EUROPA

Thu, 22 May 2008 22:42:24 -0000

Highlights and Sticky Notes:

The European Commission has taken note of Microsoft's announcement on 21^st May concerning supporting ODF in Office. The Commission would welcome any step that Microsoft took towards genuine interoperability, more consumer choice and less vendor lock-in. In its ongoing antitrust investigation concerning interoperability with Microsoft Office (see MEMO/08/19), the Commission will investigate whether the announced support of ODF (OpenDocument format) in Office leads to better interoperability and allows consumers to process and exchange their documents with the software product of their choice.

Tags: antitrust microsoft odf

Posted by: marbux

Microsoft Expands List of Formats Supported in Microsoft Office: Move enhances customer choice and interoperability with Microsoft’s flagship productivity suite.

Thu, 22 May 2008 22:11:10 -0000

Highlights and Sticky Notes:

The wookie here is the lack of native ODF support in older versions of MS Office, together with the earlier-announced intent to develop a new special API for other vendors to add native file suport via MS Office plug-ins. As part of its previous effort to backport OOXML support to earlier versions of Office and to port it to Office for the Mac, Microsoft engineers internally added OOXML support using the Office 2003 native file support to the Office 2003 native file support plug-in APIs, ripped it out of Office 2003 for Office 2007, wrapped it as a module with the same interface as the older APIs, then back and cross ported the module to the earlier versions and Office for the Mac. The new APIs for use by competitors must of necessity be integrated with the existing module. Anytime Microsoft needs to issue a bug fix for OOXML in the earlier versions, it would seem that the most efficient manner for Micriosoft to do so would be a patch for all versions that support OOXML. A patch that adds ODF support for the other Office versions would seem to be a fairly trivial task that could be rolled out with the patches that bring the older versions up to date with the final version of ISO/IEC OOXML In my view, the only conceivable reason for the new APIs is to limit the Office functionality available to competitors who write plug-ins for Office. posted by marbux
Another key point in the silver lining here is that Microsoft will add native support for ODF to Microsoft Office 2007 SP2 "and beyond". However support for ODF in previous versions of Microsoft Office will not be native but through the CleverAge Converter on SourceForge. It will in other words be XSLT-based translation of ODF to/from OOXML with the known issues with translation such as bad quality and performance. http://idippedut.dk/post/2008/05/Document-translation-sucks-(When-Rob-is-right2c-hes-right).aspx posted by jlundstocholm

Tags: microsoft msoffice 14 msoffice 2007 odf pdf xps

Posted by: marbux

Doug Mahugh : Office support for document format standards

Thu, 22 May 2008 20:12:49 -0000

Highlights and Sticky Notes:

Hi, Jesper. according to another article I found later, the new APIs (I assume it should be plural rather than singlular) will allow addition of formats other than ODF, so I apparently got that part wrong. On the Sharepoint example, I wasn't sufficiently clear and apologize. Assume you create a document in MS Office that invokes Sharepoint functionality, then you save it as ODF and ship it off to a co-worker using OOo. The OOo user wants to send it back to you for further processing. But if saving to ODF in Office wipes the Sharepoint metadata, you've got data loss on the outbound trip. The path you suggest would work at least in theory (I haven't heard any reports yet of the documentation on the Sharepoint APIs) if Sharepoint were used as an intermediary hub. But the Sharepoiint document may not be accessible to the co-worker, e.g., because of page security settings. I anticipate that there would be many cases where only one end of the trip has access to the hub, so there's a need to keep the path open that bypasses the hub and for it to be non-lossy. There is an article on BetaNews by Scott Fulton that interviews a couple of the Softies. They said that there will be lots of Office functionality that won't be able to be saved in ODF, that they're not planning a compatability mode that would block use of features that can't be saved to ODF, and that they're not planning to go beyond the features specified in ODF 1.1. So if they carry through on what they said, the outbound trip to ODF implementations will be lossy. I think the real problem with the Sharepoint specs and other documentation Microsoft is releasing is that it isn't in a standard where a technical committee could say yea or nay on whether it is suffiiciently specific and where the specs can be made vendor-neutral. In other words, that Micrsooft is in control of the specifiation rather than a standards body. Microsoft got away so far with creating a de facto standard for the line of business functionality that the OOXML spec says is one of the two major justifications for Microsoft having its own personal internatinal standard. But the OOXML spec doesn't specify the functionality offered to justify it. Same situation as with the justification based on the need for compatibility with legacy documents but no specification of the binary formats in OOXML. (IBTW, I'm not an ODF fan and I'm not coming from that direction. I have issues with standards that don't place everyone on an equal competitive footing.) posted by marbux
Hi, Jesper. according to another article I found later, the new APIs (I assume it should be plural rather than singlular) will allow addition of formats other than ODF, so I apparently got that part wrong. On the Sharepoint example, I wasn't sufficiently clear and apologize. Assume you create a document in MS Office that invokes Sharepoint functionality, then you save it as ODF and ship it off to a co-worker using OOo. The OOo user wants to send it back to you for further processing. But if saving to ODF in Office wipes the Sharepoint metadata, you've got data loss on the outbound trip. The path you suggest would work at least in theory (I haven't heard any reports yet of the documentation on the Sharepoint APIs) if Sharepoint were used as an intermediary hub. But the Sharepoiint document may not be accessible to the co-worker, e.g., because of page security settings. I anticipate that there would be many cases where only one end of the trip has access to the hub, so there's a need to keep the path open that bypasses the hub and for it to be non-lossy. There is an article on BetaNews by Scott Fulton that interviews a couple of the Softies. They said that there will be lots of Office functionality that won't be able to be saved in ODF, that they're not planning a compatability mode that would block use of features that can't be saved to ODF, and that they're not planning to go beyond the features specified in ODF 1.1. So if they carry through on what they said, the outbound trip to ODF implementations will be lossy. I think the real problem with the Sharepoint specs and other documentation Microsoft is releasing is that it isn't in a standard where a technical committee could say yea or nay on whether it is suffiiciently specific and where the specs can be made vendor-neutral. In other words, that Micrsooft is in control of the specifiation rather than a standards body. Microsoft got away so far with creating a de facto standard for the line of business functionality that the OOXML spec says is one of the two major justifications for Microsoft having its own personal internatinal standard. But the OOXML spec doesn't specify the functionality offered to justify it. Same situation as with the justification based on the need for compatibility with legacy documents but no specification of the binary formats in OOXML. (IBTW, I'm not an ODF fan and I'm not coming from that direction. I have issues with standards that don't place everyone on an equal competitive footing.) posted by marbux

This is a screen shot of a pre-release copy of SP2 (Service Pack 2) for the 2007 Microsoft Office System, showing the new document format standards that we'll be supporting starting with SP2.

The Third-party translators discussion of the forthcoming new API suggests that it is for ODF only, and thereby implicitly that it will not be a tool for accessing the full functionaolity of MS Word, i.e., that only the functionality specified in ODF 1.1 will be available. E.g., no control of Sharepoint functionality or manipulation of the Microsoft cloud through the API from OpenOffice.org via ODF. . posted by marbux
The Microsoft cloud depends heavily on OOXML, and that is likely not going to change. Are you saying that you'd prefer a plug-in mechanism in SharePoint as well? I believe the protocols used by SharePoint are included in the specs now provided. Won't that do (apart from the non-commercial usage of the specs) posted by jlundstocholm

Tags: interop microsoft odf strategy

Posted by: marbux

Gray Matter : Microsoft adds “Save as ODF” to Office 2007 Service Pack 2

Thu, 22 May 2008 19:51:41 -0000

Highlights and Sticky Notes:

There are really two central catalysts for these actions. One of these is the feedback we have received from the regulatory environment. There is a high degree of interest in our working with other software vendors to improve information exchange through the use of standardized technologies.

Because ODF side-stepped the compatibility question, we were left to solve (continue solving) that challenge elsewhere; the aversion to dealing with legacy content created a real problem for customers who want to transition to more open file formats.

In our early testing we are observing that every product implementing these standards has some level of variation from the written spec. If you've been around standards for a while, you'll know this is common, and requires dialog to establish best practices & patterns. This is our reason for joining the OASIS, AIIM and ISO committees,

Office 14 will update our support for IS29500. The timing for this might seem strange, but I do hope the rationale is clear. ODF 1.1 is a completed specification. The final version of IS29500 is not published today. While we do support a significant portion of IS29500 already, the BRM changes and other issues raised in public forums will inform us on how to best move forward with IS29500… and it gives me a little time to address the compatibility considerations that will be an important part of any file format related changes in Office.

Tags: interop microsoft odf strategy

Posted by: marbux

Brian Jones: Open XML Formats : More on yesterday’s ODF announcement

Thu, 22 May 2008 19:28:39 -0000

Tags: interop microsoft strategy

Posted by: marbux

EU Will Probe Microsoft Support For Open Source File Format

Thu, 22 May 2008 19:22:05 -0000

Tags: antitrust dg competion microsoft

Posted by: marbux

Forget file formats. The battle is Sharepoint | The Open Road - The Business and Politics of Open Source by Matt Asay - CNET Blogs

Thu, 22 May 2008 07:25:07 -0000

Highlights and Sticky Notes:

People are agog that Microsoft has announced support for Open Document Format (ODF), but I'm not sure why. This was a foregone conclusion once Microsoft figured out how to move lock-in above the file level to the content network.

In other words, to Sharepoint.

Microsoft has been hell-bent on getting enterprises to dump content into its proprietary Sharepoint repository, calling it the next Windows operating system. I call it the future of Microsoft lock-in.

Tags: microsoft oasis odf ooxml sharepoint

Posted by: garyedwards

OOXML OPS and the GPL: A disappointing surprise from the SFLC | Gray Matter

Tue, 08 Apr 2008 19:56:35 -0000

Highlights and Sticky Notes:

I view the spec as confusing, obtuse, error-ridden, x86-centric, incomplete, and redundant. Microsoft sat on the board of ODF for _years_ without offering any help on the minor items ODF didn't provide that they wanted. Now that governments start pressing for permanent standards on document storage, MS throws out this half-baked item and expects a reward for good behavior. Maybe somebody on the board of directors at our company likes it, but the technical folks having to add more work are less than happy about this beast.

If they had to go with XML, couldn't they at least have allowed standard XML with attributes and the like instead of x86 specific, binary incompatible, past-version deprecating, standard-avoiding, crash on normal XML.. ... mess... that they have offered for consumption? Oh.. but wait, I'm sure the BRM fixed that in the week given. I'm sure the pretty version will show up any day now.

Tags: gpl grey-matter iso microsoft ooxml ops

Posted by: garyedwards

The Stockholm Syndrom at ISO | ODF Editor Says ODF Loses If OOXML Does | Slashdot

Fri, 28 Mar 2008 18:51:08 -0000

Highlights and Sticky Notes:

ISO is bound to the business of "interoperability", and has very strict guidelines for interoperability requirements, that are themselves tied to international trade agreements and legal conventions. In this context, it is beyond surprising that ISO allows the "OASIS PAS" and "Ecma Fast Track" channels to remain open, with specification work remaining under the controlling influence of the vendors.

IMHO, the change in Patrick's position is entirely due to the realization that it is impossible to map between OOXML and ODF. I don't know this for sure, but when i read the German Standards Group (DIN) report on harmonization, authorized by the EU-IDABC and provided to ISO, i couldn't help but wonder how Patrick would react. The report definitively ends his OOXML ODF mapping dream.

Tags: durusau iso microsoft odf ooxml slashdot w3c

Posted by: garyedwards

Some thoughts on OOXML | Larsblog

Thu, 27 Mar 2008 19:42:06 -0000

Highlights and Sticky Notes:

What is to be done?

ISO has in a sense put itself in an awkward position here by already approving the rival OpenDocument format as an ISO standard. This makes it harder to reject OOXML, and at the same time makes it difficult to approve OOXML, since it competes with an existing ISO standard. Generally, I'm unhappy with how closely these two standards are tied to existing software. What I would really have liked to see was for OpenDocument and OOXML both to be dropped, and the two communities to sit down and work out a common agreed format that is not tied to any existing software. The Chinese UOF format, for example, might have served as the starting point for this. ODA has also been suggested. Unfortunately, this requires a political will that does not seem to be present, and so this seems unlikely for now.

Tags: approval iso microsoft msoffice odf ooxml sgml

Posted by: garyedwards

OOXML vs ODF: where next for interoperability? | Reg Developer

Sat, 22 Mar 2008 00:37:16 -0000

Highlights and Sticky Notes:

'A diversion from the real end game – the taking of the internet'

Gary Edwards of the Open Document Foundation has a fascinating post on the important of Microsoft Office compatibility to the success of the ISO-approved Open Document formats.

It is in places a rare voice of sanity:

People continue to insist that if only Microsoft would implement ODF natively in MSOffice, we could all hop on down the yellow brick road, hand in hand, singing kumbaya to beat the band. Sadly, life doesn’t work that way. Wish it did.
Sure, Microsoft could implement ODF - but only with the addition of application specific extensions to the current ODF specification … Sun has already made it clear at the OASIS ODF TC that they are not going to compromise (or degrade) the new and innovative features and implementation model of OpenOffice just to be compatible with the existing 550 million MSOffice desktops.

Tags: foundation iso microsoft odf ooxml w3c

Posted by: garyedwards