To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.
1More
The End of ODF & OpenXML - Hello ODEF! - 0 views
-
Gary Edwards on 07 Jun 07Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace both ODF and OpenOfficeXML. ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned. The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all: "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"..... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?" ....... "Under those conditions, is it even possible to implement OpenDocument?" ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668. This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day. In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications. The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick descriptio
19More
shared by Gary Edwards on 13 Jul 07
- Cached
Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 1 views
www.microsoft-watch.com/...obla_de_oba_da.html
odef odf officeopenxml ooxml opendocument vista-stack
![](/images/link.gif)
-
-
OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.
The binding model for OOXML is "Smart Documents", and it is proprietary!
Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.
Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.
Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.
I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.
Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.
One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.
This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and
-
-
Microsoft seeks to create sales pull along the vertical stack between the desktop and server.
-
The vertical stack is actually desktop - server - device - web based. The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.
Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement. One of the primary failings of ODF is that it is not able to be fully implemented in this converged space. OOXML on the other hand was created exactly for this purpose!
So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets. OOXML differs in that it is tightly bound to the Vista Stack.
So where is an Open Stack model to turn to?
Good question, and one that will come to haunt us for years to come. Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.
OOXML is unfi as a UFF becuase it is application - platform and vendor bound.
For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.
XHTML (XHTML CSS3 RDF) is looking very good. The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML . Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML ?
I think so. But we can't be sure until the da Vinci proves this conclusively.
One thign to keep in mind though. The internal plugins have already shown that it is possible to do multiple file formats. OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.
So why not try it with XHTML , or ODEF (the eXtended version of ODF en
-
-
Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.
-
This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be. ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.
The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice, does not fully support and implement the Conformance Clause.
The only foreign elements supported by OpenOffice are paragraphs and text spans. Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!
This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.
Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci. KOffice ODF and Googel Docs ODF are all different ODF implementations. Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.
It's also true that OOXML has optional implementation areas. With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.
With OOXML, the entire Vista Stack - Win32 dependency layer is "optional". No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies. This includes the legacy Win32 API dependencies (like VML, EMF, EMF ), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.
MSOffice 2007 i
-
- ...6 more annotations...
-
Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML.
-
True, but a tricky statement given that the proprietary OOXML implementation is "optional". It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".
In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.
Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!
It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.
So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat. For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true. For all practical concerns, that's enough. For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.
-
-
Microsoft got there first to protect Office.
-
No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport!
Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET.
The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place.
The Vista Stack looks like this:
..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub
..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End
The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents.
The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps.
The productivity gains that can be had through this migration to the E/S Hub are extraordinary.
A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service)
These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital". For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model. This will no doubt change with the emer
-
-
By adapting XML
-
The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!
In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems.
Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business.
Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.
Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value.
When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone!
The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level.
Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Doc
-
-
Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit.
-
Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.
-
Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.
What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.
Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
-
-
I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path.
-
Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.
The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality. Which, for the sake of brevity we can call the lead Win32 API dependencies.
One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.
Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration. As long as the complete Win32 API was available (Windows MSOffice VBA run times), this platform was great for workgroups. The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.
The Internet offers everyone a new way of integrating data, content and streaming media. Web applications are capable of loosly coupled serving and consuming of other application services. Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.
On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.
Into this SOA mash Microsoft will push with a sweeping integrated stack model. Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.
-
-
Great article series from eWeek. A must read. But it all comes down to interoperability across two stack models: The Microsoft Vista Stack, and an alternative Open Stack model that does not yet exist!
Incompatible formats become a nightmare for the kind of integration any kind of SOA implementation depends on, let alone the Web 2.0 AJAX MashUps this article focuses on.
I wonder why eWEEK didn't include the Joe Wilcox Micrsoft Watch Article, "Obla De OBA Da". Joe hit hard on the connection between OOXML and the Vista Stack. He missed the implications this will have on MS SOA solutions. Open Source SOA solutions will be locked out of the Vista Stack. And with 98% or more of existing desktop business processes bound to MSOffice, the transition of these business processes to the Vista Stack will no doubt have a dramatic impact on the marketplace. Before the year is out, we'll see Redmond let loose with a torrent of MS SOA solutions. The only reason they've held back is that they need to first have all the Vista Stack pieces in place.
I don't think Microsoft is being held back by OOXML approval at ISO either. ISO approval might have made a difference in Europe in 2006, but even there, the EU IDABC has dropped the ISO requirement. For sure ISO approval means nothing in the US, as California and Massachusetts have demonstrated.
All that matters to State CIO's is that they can migrate exisiting docuemnts and business processes to XML. The only question is, "Which XML? OOXML, ODF or XHTML+".
The high fidelity conversion ratio and non disruptive OOXML plugin for MSOffice has certainly provided OOXML with the edge in this process. <br
2More
Is It Game Over? - ODF Advocate Andy UpDegrove is Worried. Very Worried - 0 views
-
This seems to me to be a turning point for the creation of global standards. Microsoft was invited to be part of the original ODF Technical Committee in OASIS, and chose to stand aside. That committee tried to do its best to make the standard work well with Office, but was naturally limited in that endeavor by Microsoft's unwillingness to cooperate. This, of course, made it easier for Microsoft to later claim a need for OOXML to be adopted as a standard, in order to "better serve its customers." The refusal by an incumbent to participate in an open standards process is certainly its right, but it is hardly conduct that should be rewarded by a global standards body charged with watching out for the best interests of all.
-
Andy UpDegrove takes on the issue of Microsoft submitting their proprietary "XML alternative to PDF" proposal to Ecma for consideration as an international standard. MS XML-PDF will compliment ECMA 376 (OOXML - OfficeOpenXML) which is scheduled for ISO vote in September of 2007. Just a bit over 60 days from today.
Andy points out some interesting things; such as the "Charter" similarities between MS XML-PDF and MS OOXML submisssions to Ecma:
MS XML-PDF Scope: The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats. The aim is to enable the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems. The Technical Committee will also be responsible for the ongoing maintenance and evolution of the standard. Programme of Work: Produce a formal standard for an XML-based electronic paper format and XML-based page description language which is consistent with existing implementations of the format called the XML Paper Specification,…[in each case, emphasis added]
If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, wh
2More
Microsoft Partners with Atlassian & NewsGator - SharePoint Goes Web 2.0 - Flock - 0 views
-
4) Linking; Within Confluence, users can access SharePoint document facilities. By including SharePoint lists and content within Confluence, users can (in a single click) edit Microsoft Office documents.
-
Pay close attention here boys and girls because here it is. Wonder why Microsoft is wealing, dealing and ready to shell out billions for Web 20 collaboration software? It's to tie them into the MS Stack of MSOffice, IE, Exchange/SharePoint, MS LIve, MS Dynamics, MS SQL Server, etc.
Grand convergence is the convergence of desktop, server, device and web systems. It increasing looks like were going to have to live with the MS Stack and the Open Stack of grand convergence interoperability. One will be able to have perfect interop within it's walls, with all applications able to handle the same compound XML document. The other will be totally unable to implement an inteoperable version of MS-OOXML.
Members of the MS Stack will be able to access everything in the Open Stacks, but outside systems will have limited (crippled) access into the MS Stack. Embrace, Extend, Extinguish. Here we go again.
~ge~
12More
shared by Gary Edwards on 07 Apr 08
- Cached
XML-Empowered Documents Extend SOA's Connection to People and Processes | BriefingsDire... - 0 views
briefingsdirect.blogspot.com/...red-documents-extend-soas.html
cloud-computing collaborative-computing paas saas soa woa
![](/images/link.gif)
-
We're going to talk about dynamic documents. That is to say, documents that have form and structure and that are things end-users are very familiar with and have been using for generations, but with a twist. That's the ability to bring content and data, on a dynamic lifecycle basis, in and out of these documents in a managed way. That’s one area.The second area is service-oriented architecture (SOA), the means to automate and reuse assets across multiple application sets and data sets in a large complex organization.We're seeing these two areas come together. Structured documents and the lifecycle around structured authoring tools come together to provide an end-point for the assets and resources managed through an SOA, but also providing a two-way street, where the information and data that comes in through end-users can be reused back in the SOA to combine with other assets for business process benefits.
-
Thus far we’ve been talking about the notion of unstructured content as a target source to SOA-based applications, but you can also think about this from the perspective of the end application itself -- the document as the endpoint, providing a framework for bringing together structured data, transactional data, relational data, as well as unstructured content, into a single document that comes to life.Let me back up and give you a little context on this. You mentioned the various documents that line workers, for example, need to utilize and consume as the basis for their jobs. Documents have unique value. Documents are portable. You can download a document locally, attach it to an email, associate it with a workflow, and share it into a team room. Documents are persistent. They exist over a period of time, and they provide very rich context. They're how you bring together disparate pieces of information into a cohesive context that people can understand.
-
-
"various line of business applications and composite applications" is exactly where ODF failed in Massachusetts! Think of client/server, with many business processes bound to MSOffice on the client side. The big ODF vendors tried to convince Massachusetts to "rip out and replace" MSOffice. Which proved to be terribly disruptive and costly. These bound "client side" processes would have to be rewritten, and none of the ODF applications were the equivalent of MSOffice as a developers platform (even if the cost was something MASS was willing to pay for - which they were not!). MASS came up with an alternative idea to save ODF, the idea of cloning the OOXML plug-in for MSOffice to create an ODF plug-in. The problem was that MASS did not have an IT budget thanks to Microsoft's political mucking. So MASS CIO Louis Gutierrez turned to the big vendors askign them to support something they seriously opposed. An ODF plug-in would leave MSOffice in place.
-
- ...8 more annotations...
-
-
This paragraph says it all. The portable document is an essential frame for moving information thoughout the emerging client/ Web Stack /server information infrastructure model. The key is that the portable docuemnts are interactive and "live". The data and media streams bound to objects within the documents are attached to their original sources using XML connecting streams like XMLHTTPRequest or P2P Jabber XML routers. In 2003 we used Jabber to hot wire Comcast documents (docs, spreadsheet cells and presentations) to backend transactional blackboxes and web service rich data resources. The productivity gain from this approach is that end users are no longer required to verify and manage data. The "system" manages the data, freeing the end user to concentrate on the task of presentation, analysis and explanation.
-
-
-
What? The key to client/ Web Stack /server design (advanced SOA) is to have a desktop "editor" that writes highly strucutred XML docuemnts that are universally portable across a wide range of Web Stacks. The W3C provides CDF as a very advanced docuemnt container for the purpose of porting complex documents across a wide range of "editors", servers, and devices. (X)HTML 2.0 - CSS3, SVG, XForms and RDF are the core components of the open web future where complex documents and business processes will move to client/ Web Stack /server models. The problem is that there are NO desktop "editors" capable of producing CDF. ISO approval of MS-OOXML stamps MSOffice as a standards compliant "editor". The problem is that it is very difficult to convert MS-OOXML documents to CDF - XHTML-CDF-SVG-RDF!!! The MSOffice SDK does provide an easy to implement MS-OOXML <> XAML conversion component. XAML itself is part of the proprietary WPF set of technologies, joining Silverlight, Smart Tags, and WinForms as a complete MS-Web ready alternative to advanced W3C technolgoies: XHTML, CSS, SVG, XForms, and RDF. XAML "fixed/flow" replaces XHTML-CSS. Silverlight replaces SVG and SWF (Flash). Smart Tags is a porprietary alternative to RDF-RDFa. And WinForms is of course an alternative to XForms. The MS Web STack core s comprised of Exchange, SharePoint and MS SQL Server. The core is joined by Windows Server, MS Dynamics, and MS Live (among so many). ISO approval of MS-OOXML provides the MS Cloud with a standards compliant "editor" that currently ownes OVER 95% of the desktop marketshare when it comes to bound business processes. With ISO approval, an entire generation of client/server processes can now transition to client/ Web Stack /server models, where they can take full advantage of the advanced SOA model where portable XML documents move structured data and media through a highly distributed but end user controlled web model.
-
-
-
-
Uh oh. Does Mr. Sorofman understand the importance of MSOffice-OOXML-XAML-Smart Tags as an alternative to W3C RDF? This split in the Web will result in a nightmare for Google. Think of it as though Google owns the consumer side of the web, and Microsoft owns the business process side. Such is the importance of ISO approval of MS-OOXML! Google will be unable to match the search advantages of either RDF or Smart Tags. With Smart Tagged docuemnts though, Google won't even get the chance to compete. They will be locked out of the document processing chain that begins with MSOffice-OOXML and extends through a proprietary MS Web STack rich with XAML, Silverlight, WinForms and Smart Tag semantics! Although hindsight is 20-20, we can look back at 2006 in Massachusetts and see that the failure of ODF there is going to result in huge losses to Google and Oracle. Google will find themselves locked into a consumer web box, unable to branch out to business. Oracle will find themselves on the wrong side of a Microsoft dominated client/ Web Stack /server based transition of legacy client/server systems.
-
-
-
-
-
What we found at Comcast in 2002-2003 was many spreadsheet "templates" that the sales staff used to keep track of inventory, pricing, and client accounts. By P2P enabling the cells in these templates, we were able to connect in transactional database information in real time ( or web connect time :). Every template, whether it was a writer document,-form, spreadsheet template, or presentation deck was P2P Jabber wired at the object level wherever an external information source was invloved. Which seemed to be everywhere! The hard work is getting the XML connectors in place, setting up an information stream between the Web Stack (Apache Tomcat - MySQL-XUL Server), and the backend transational black boxes. With Comcast this was done through a 24 hour dump cycle with each black box dumping and uploading from the Web Stack. For sales, marketing and management, the Web Stack did the heavy business of serving up Jabber data and resolving order conflicts. The "system" took over the management and verification of data, releasing the sales force to concentrate on their primary task.
-
-
-
In Massachusetts, they were using eMail to shuttle spreadsheet templates around. This is about as brittle and unproductive a method as there is, but it was all they had. Rather than focusing on keeping their client side business processes operating, MASS might have been better off focusing on building a client/ Web-Stack /server model they could gradually transition these desktop bound processes to. Establish an open Web-Stack design, and work back towards the desktop client. Instead, MASS fell into the trap of trying to replace MSOffice on the desktop with ODF OpenOffice based alternatives, while simultaneously purchasing Exchange-SharePoint Web-Stack components! The MS Web-Stack is designed for MSOffice-OOXML business processes, not ODF!!!!!
-
2More
ODF Civil War: Bulll Run - Suggested Changes on the Metadata proposal - OASIS ODF - 0 views
-
From our perspective it would be better to aim for doing the job in ODF 1.2, even if that requires delay. We will oppose ODF 1.2 at ISO unless the interoperability warts are cleaned up. What the market requires is no longer in doubt. See the slides linked above and further presentations linked from this page, < http://ec.europa.eu/idabc/en/document/6474/5935>. Substantial progress toward those goals would seem to be mandatory to maintain Europe's preference for a harmonized set of file formats that uses ODF to provide the common functionality. Delaying commencement of such work enhances the likelihood that governments will tire of waiting for ODF to become interoperable with MS Office and simply go with MOOXML. We may not be able to force Microsoft to participate in the harmonization work, but we will be in a far better position if we have done everything we can in aid of that interoperability without Microsoft's assistance. As the situation stands, we have what is known in the U.S. as a "Mexican stand-off," where neither side has taken a solitary step toward what Europe has requested. We have decided to do that work via a fork of ODF; it is up to this TC whether it wishes to cooperate in that effort.
-
This is the famous marbux response to Sun regarding Sun's attempt to partially implement ODF 1.2 XML-RDF metadata. It's a treasure.
There is one problem with marbux's statement though. We had decided long ago not to fork ODF even if the five iX "interoperability enhancement" proposals were refused by the OASIS ODF TC. This assurance was provided to Massachusetts CIO Louis Gutierrez witht he the first ODF iX proposal submitted on July 12th, 2006. Louis ended up signing off on three iX proposals before his resignation October 4th, 2006.
The ODF iX enhancements were essential to saving ODF in Massachusetts. Without them, there was no way our da Vinci plug-in could convert existing MSOffice documents and processes to ODF with the needed round trip fidelity.
For nearly a year we tried to push through some semblance of the needed iX enhancements. We also tried to push through a much needed Interoperability Framework, which will be critical to any ISO approval of ODF 1.2.
Our critics are correct in that every iX effort was defeated, with Sun providing the primary opposition.
Still rather than fork ODF, we are simply going to move on.
On October 4th, 2006, all work on ODF da Vinci ended - not to be resumed unless and until we had the ODF iX enhancements we needed to crack the MSOffice bound workgroup-workflow business process barrier.
In April of 2007, with our OASIS membership officially shredded by OASIS management, bleeding from the List Enhancement Proposal doonybrook, and totally defeated with our hope - the metadata XML-RDF work, we threw in the towel.
Since then we've moved on to CDF, the W3C Compound Document format. Incredibly, CDF is able to do what ODF can not. With CDF we can solve the three primary problems confronting governments and MSOffice bound workgroups everywhere.
The challenge for these g
3More
Is HTML in a Race to the Bottom? A Large-Scale Survey of Open Web Formats - 0 views
-
The "race to the bottom" is a familiar phenomenon that occurs when multiple standards compete for acceptance. In this environment, the most lenient standard usually attracts the greatest support (acceptance, usage, and so on), leading to a competition among standards to be less stringent. This also tends to drive competing standards toward the minimum possible level of quality. One key prerequisite for a race to the bottom is an unregulated market because regulators mandate a minimum acceptable quality for standards and sanction those who don't comply.1,2 In examining current HTML standards, we've come to suspect that a race to the bottom could, in fact, be occurring because so many competing versions of HTML exist. At this time, some nine different versions of HTML (including its successor, XHTML) are supported as W3C standards, with the most up-to-date being XHTML 1.1. Although some versions are very old and lack some of the newer versions' capabilities, others are reasonably contemporaneous. In particular, HTML 4.01 and XHTML 1.0 both have "transitional" and "strict" versions. Clearly, the W3C's intent is to provide a pathway to move from HTML 4.01 to XHTML 1.1, and the transitional versions are steps on that path. It also aims to develop XHTML standards that support device independence (everything from desktops to cell phones), accessibility, and internationalization. As part of this effort, HTML 4.01's presentational elements (used to adjust the appearance of a page for older browsers that don't support style sheets) are eliminated in XHTML 1.1. Our concern is that Web site designers might decline to follow the newer versions' more stringent formatting requirements and will instead keep using transitional versions. To determine if this is likely, we surveyed the top 100,000 most popular Web sites to discover what versions of HTML are in widespread use.
-
-
The summary statement glosses over the value of a highly structured portable XML document. A value that goes far beyond the strict separation of content and presentation. The portable document model is the essential means by which information is exchanged over the Web. It is the key to Web interop. Up till now, Web docuemnts have been very limited. With the advent of XHTML-2, CSS-3, SVG, XForms and CDF (Compound Document Framework for putting these pieces together), the W3C has provisioned the Web with the means of publishing and exchanging highly interactive but very complex docuemnts. The Web documents of the future will be every bit as complex as the publishing industry needs. The transition of complex and data rich desktop office suite documents to the Web has been non existent up till now. With ISO approval of MSOffice-OOXML, Microsoft is now ready to transition billions of business process rich "office" documents to the Web. This transition is accomplished by a very clever conversion component included in the MSOffice SDK. MS Developers can easily convert OOXML documents to Web ready XAML documents, adn back again, without loss of presentation fidelity, or data. No matter what the complexity! The problem here is that while MSOffice-OOXML is now an ISO/IEC International Standard, XAML "fixed/flow" is a proprietary format useful only to the IE-8 browser, the MS Web Stack (Exchange, SharePoint, MS SQL, and Windows Server), and the emerging MS Cloud. Apache, J2EE, Mozilla Firefox, Adobe and Open Source Servers in general will not be able to render these complex, business process rich, office suite documents. MSOffice-OOXML itself is far to complicated and filled with MS application-platform-vendor specific dependencies to be usefully converted to Open Web XHTML-CSS, ePUB or CDF. XAML itself is only the tip of the iceberg. The Microsoft Web Stack also implements Silverlight, Smart Tags and other WPF - .NET
-
-
What makes the Internet so extraordinary is the interoperability of web ready data, content, media and the incredible sprawl of web applications servicing the volumes of information. The network of networks has become the information system connecting and converging all information systems. The Web is the universal platform of access, exchange and now, collaborative computing. This survey exammines the key issue of future interoperability; Web Document Formats.
2More
shared by Gary Edwards on 13 Mar 07
- Cached
Microsoft Watch - Business Applications - Convergence=Integration - 0 views
www.microsoft-watch.com/...convergence_integration.html
chains exchange hubs microsoft odf office ooxml opendocument openxml sharepoint xml
![](/images/link.gif)
-
Microsoft significantly increases cross-integration of features with the company's other software. Microsoft acquired most of the products making up its Dynamics product line, and what a motley crew. New products and versions bring the Dynamics line more into the Microsoft family, in part by convergence—or increased integration with the company's other software.
-
Thanks for the insightful commentary Joe. I see things a bit differently. Maybe my tin foil hat is wearing a bit tight these days, but i see MSOffice XML (MOOXML and the MOOXML binary InfoSet) as a very important aspect of how Microsoft integrates and leverages their desktop office monopoly power into server side and device systems. It is the combination of MOOXML and .NET that creates the integration mesh between desktop, server systems, and devices. Imagine every application or service participating in either a loosely coupled or carefully crafted information processing chain, being fluent in MOOXML, and able to process internal data structures and processing instructions unique to .NET. Enterprise systems and services from ORACLE, IBM and SAP will not have this same integration fluency. The design of ISO MOOXML is such that it would be impossible for <b>non Microsoft server and device systems</b> to match the quality and depth of integration with the 500 million desktops running MSOffice bound business processes. Given that MOOXML will probably succeed at getting ISO/IEC approval, removing the last "legal" barrier for this MOOXML Stack, were looking at a massive migration of MSOffice bound workgroup - workflow business processes to a new lockin point; The Exchange/SharePoint Hub. With the real estate industry, this migration to to E/S hosted applications only took six months to completely replace years of desktop productivity shrinkware dominance. The leap in productivity was spectacular. The downside of this migration is that the real estate industry is now tied into Microsoft at the critically important business process level. A binding that will perhaps last through the next fifteen years.
2More
shared by Gary Edwards on 24 Aug 07
- Cached
Slamming the door shut on MS OOXML - 0 views
lists.oasis-open.org/...msg00033.html
cdf interoperability iso odf odf-tc officeopenxml ooxml opendocument xml
![](/images/link.gif)
-
So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact. No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a de facto Sun Microsystems standard wearing the clothing of a de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one? Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.
-
Marbux on metadata and the language of universal interoperability: Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.
ODF (OpenDocument), formally known as Open Office XML, began it's standards life in the fall of 2002 when Sun submitted the OpenOffice file format to OASIS for consideration as a office suite XML fiel format standard. The work on ODF did not start off as a clean slate in that there were near 600 pages of application specific specification from day one of the standards work. The forces of universal interop have sought for years to separate ODF from the application specific features and implementation model of OpenOffice that began with those early specification volumes, and continues through the undue influence Sun continues to have over the ODF specification work.
Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.
Marbux is one of those Universal Interop soldiers who has dug in his heels, cried to the heavens that enough is enough, and demanded the necessary changes to ODF interoperability language.
This post he recently submitted to the OASIS ODF Metadata SC is a devastating rebuttal to the arguments of those who support the status quo of limited interoperability.
In prior posts, marbux argues that ISO directives demand without compromise universal interoperability. This demand is also shared by the World Trade Organization directives regarding international trade laws and agreements. Here he brings those arguments together with the technical issues for achieving universal interop.
It's a devastating argument.
2More
V1 committee gives thumbs down to Open XML doc spec - 0 views
-
Sun Microsystems Inc., largely considered an avowed opponent of Open XML because of its own development and support for the competing, ODF-based StarOffice suite, found itself in the unexpected position of stating its support for ratifying Open XML -- albeit after some changes in the proposal are made.
-
Quote: Sun Microsystems Inc., largely considered an avowed opponent of Open XML because of its own development and support for the competing, ODF-based StarOffice suite, found itself in the unexpected position of stating its support for ratifying Open XML -- albeit after some changes in the proposal are made. "We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents," Jon Bosak, a Sun representative to V1, wrote in an e-mail to other committee members over the weekend. "Sun voted No on Approval because it is our expert finding, based on the analysis so far accomplished in V1, that DIS 29500 as presently written is technically incapable of achieving those goals, not because we disagree with the goals or are opposed to an ISO Standard that would enable them." Sun "found itself in the unexpected position of stating its support for ratifying OOXML"? What???? This is the official position of Sun?
For the near five years that i have been a member of the OASIS ODF TC, Sun has opposed
2More
shared by Gary Edwards on 20 Mar 07
- Cached
Q&amp;A: Calif. CIO Steers Clear of Ideology on File Formats - 0 views
www.computerworld.com/...article.do
california iso microsoft mooxml msoffice odf ooxml opendocument openxml xml
![](/images/link.gif)
-
We’re trying to view it as a straight business decision. What are the costs associated with one approach over another? Does it serve all of our business needs? If it doesn’t serve a business need, how do we satisfy that business need? We’re trying to view this just as a plain-vanilla, nonpartisan, nonideological issue.
-
A mus tread. Carol Sliwa of ComputerWorld intervies Clark Kelso, California CIO. ODF is the main issue, with clark casting all his answers in the context of business decisions. Carol o fcourse is asking the best questions of any journalist alive.
Keep in mind that ComputerWorld and the Boston globe filed for the Freedom of Information Act to be invoked in Massachusetts. They got access to all the eMail, documnetation, and conferencing notes concerning ODF and Microsoft. Carol's interview with Louis Gutierrez last week was filled with the same hard questions Clark Kelso fielded so deftly.
The "committee" Clark Kelso has set up to look at these issues is headed by Bill Welty, the CIO of the California Air Resources Board. Bill is a long time opensource - Linux guy, but will be the firs tto admit that Microsoft is the only vendor providing a means of getting everything inot XML. And that's the heart of any SOA strategy, "First, get everything into XML".
With a 500 million MSOffice desktop bound business process headstart, Microsoft has the extreme advantage in this much needed migration to XML.
They now have their own proprietary application and platform bound version of XML; MOOXML (Microsoft OfficeOpenXML) heading for international standardization at ISO.
They now have their XML Hub in place; the Exchange4/SharePoint Hub. This is also an essential part of any SOA strategy. You've got to have an XML Hub where the XML information streams and service connection to legacy black box systems can be piped into, managed and resolved. The XML must also provide an end user interface to these information flows. One that converges and integrates information, documents, data, and workflows into an easy to manage and participate in interface. The E/S Hub excells at this because it covers the fundamentals of eMail, messaging, portal, calendar, scheduling, c
2More
BetaNews | Microsoft Will Support ODF If It Doesn't 'Restrict Choice Among Formats' - 0 views
-
None of this is to say that OpenDocument is perfect. Far from it. OpenDocument at present is crippled from an interoperability standpoint. I'm a member of the OASIS OpenDocument Technical Committee and I think the resistance of the big vendors to fixing the interoperability warts is simply outrageous, particularly because they are fairly trivial changes. But the advancement of software users' interests are not advanced by painting OOXML as other than deeply flawed. It is vendor-specific and far from "open." The lesser of the two evils is clearly OpenDocument, which is at least open even if not yet interoperable. The sooner folks can start discussing practical methods of convergence, the better. See e.g., http://ec.europa.eu/idabc/servlets/Doc?id=27956 That set of slides summarizing a conference of some 20 European national governments' IT types says a lot more about the future of office document formats than Mr. Asellus has to offer.
2More
Microsoft Will Support ODF! But Only If ISO Doesn't 'Restrict Choice Among Formats' - 0 views
-
By Marbux posted Jun 19, 2007 - 3:16 PM Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy." I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not. I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification.
-
Incredible comment by Marbux! With one swipe he takes out both Ecma 376 and ODF.
Microsoft has written a letter claiming that they will support ODF in MSOffice, but only if ISO approves Ecma 376 as a second office suite XML file format standard. ODF was approved by ISO nearly a year ago.
Criticizing Ecma 376 is easy. It was designed to meet the needs of a proprietary application, MSOffice, and, to meet the needs of the emerging MS Vista Stack of applications that spans desktop to server to device to web platforms. It's filled with MS platform dependencies that make it impossibly non interoperable with anything not fully compliant with Microsoft owned API's.
Criticizing ODF however is another matter entirely. Marbux points to the extremely poor ODF interoperability record. If MOOXML (not Ecma 376 - since that is a read only file format) is tied to vendor-application specific MSOffice, then ODF is similarly tied to the many vendor versions of OpenOffice/StarOffice.
The "many vendor" aspect of OpenOffice is somewhat of a scam. The interoperability that ODF shares across Novell Office, StarOffice, IBM WorkPlace, Red Office, and NeoOffice is entirely based on the fact that these iterations of OpenOffice are based on a single code base controlled 100% by Sun. Which is exactly the case with MSOffice. With this important exception - MOOXML (not Ecma 376) is interoperable across the entire Vista Stack!
The Vista Stack is comprised of Exchange/SharePoint, MS Live, MS Dynamics, MS SQL Server, MS Internet Server, MS Grove, MS Collaboration Server, and MS Active Directory. Behind these applications sits a an important foundation of shared assets: MOOXML, Smart Documents, XAML and .NET 3.0. All of which can be worked into third party, Stack dependent applications through the Visual Studio .NET IDE.
Here are some thoughts i wou
2More
Taking an incremental approach to SOA | Avoiding costly "rip out an dreplace" - 0 views
-
Current implementation issues One of the biggest hurdles to implementing a realistic SOA is understanding what the business units and end users are doing today. This understanding is critical to the success of any SOA project since the new services must match exactly what each business unit is doing today. Neglecting these business processes and replacing them with individual services will most likely lead to hundreds of non-used services and frustrated business units.
2More
shared by Gary Edwards on 15 Jun 07
- Cached
Between a rock and a hard place: ODF & CIO's - Where's the Love? - 0 views
www.consortiuminfo.org/...article.php
cio government microsoft oasis odf officeopenxml ooxml opendocument openxml
![](/images/link.gif)
-
So I'm disappointed. And not just on behalf of open documents, but on behalf of the CIOs of this country, who are now caught between a rock and a hard place, without a paddle to defend themselves with if they won't to do anything new, innovative and necessary, if a major vendor's ox might be gored in consequence. After the impressive lobbying assault mounted over the past six months against open document format legislation, I expect you won't be hearing of many state IT departments taking the baton back from their legislators. And who can blame them? If they tried, it wouldn't be likely to be anything as harmless as an open document format that would bite them in the butt.
-
Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled Microsoft trounces pro-ODF forces in state battles over open document formats.
Andy believes that it is the failure of state legislators to do their job that accounts for these failures. He provides three reasons for this being a a failure of legislative duty. The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors.
The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.
Andy puts it this way, "
And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats. You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe
2More
Indecision in Redmond as Web apps charge : Office 2.0 and Google Apps - 0 views
-
the fact is that Redmond could own this new space if it wanted to. All it would need to do is push interoperability and integration between lightweight Web versions of Office applications and its desktop fatware. Advanced features would be absent from the lightweight versions, but the company could ensure any Office doc would load on the Web -- whatever new desktop service packs and upgrades might appear -- and online document management could be integrated with Windows for offline access.
-
Great quote from Eric Knorr. He hits the nail on the head here, pointing out the problem Office 2.0 Web Apps and SaaS apps face: If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios. If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process. The only way to overcome that kind of a split is to take the entire process. Which is difficult for lightweight mashup happy web wonders to do.
Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft. As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life. At any time Microsoft can swoop in and take it all.
Today, the MSOffice OOXML file format displays perfectly in a browser. It's 100% web ready, but only the MS Stack of applications gets to play. Web wonders are not likely to recieve a Redmond invite now or ever.
Which brings us to the issue of the da Vinci plug-in for MSOffice. da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys. It can achieve the same high fidelity "round trip" conversion that OOXML is capable of. Maybe even better.
The problem for da Vinci isn't conversion fidlelity. Nor is it capturing business process important VBa scripts, macros, OLE, and security settings. da Vinci can do that just fine. The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!! For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF
2More
shared by Gary Edwards on 06 Feb 08
- Cached
The ODF Alliance puckers up and gets smacked with the great CSS question - Where is it?... - 0 views
www.oreillynet.com/...odf_alliance_now_loves_me.html
harmonization hypocrisy interop iso odf odf-alliance ooxml opendocument openxml
![](/images/link.gif)
-
Harmonisation It is interesting that the ODF Alliance quotes Tim Bray that the world doesn’t need another way to express basic typesetting features. If it is so important, why didn’t ODF just adopt W3C CSS or ISO DSSSL conventions? Why did they adopt the odd automatic styles mechanism which no other standard uses? Now I think the ODF formating conventions are fine, and automatic styles are a good idea. But there is more than one way to make an omlette, and a good solution space is good for users. My perspective is that harmonisation (which will take multiple forms: modularity, pluralism, base sets, extensions, mappings, round-trippability, feature-matching, convergence of component vocabularies, etc, not just the simplistic common use of a common syntax) will be best achieved by continued user pressure, both on MS and the ODF side, within a forum where neither side can stymie the legitimate needs of other.
-
MS-OOXML supporter Rick Jellife discusses the ODF Alliance response to Ecma's proposed disposition of ISO NB comments on OOXML. The Allaince response has recieved quite a bit of ink, wtih waves of ODF jihadists pointing to it as incontroverible evidence that they are right. Rick provides a lengthy response, most of which presents the ODF jihadis with some difficult issues they must now explain. More importantly though, RJ uncovers one of the more glaring examples proving that ODF is application specific to the core, and bound to OpenOffice. He points out that OpenOffice ODF could have chosen the W3C's highly portable and infinitely interoeprable CSS as the ODF presentation layer. This would have been a great reuse of existing standards. But that's not what happened! Instead of the widely used CSS, OpenOffice chose an incredibly application specific presentation model with the unique innovation of "automatic-styles". And with this choice came years of problematic zero interop as application after application try to exchange ODF documents with little success. Take for example KDE-KOffice. They've been a member of the OASIS ODF TC for near five years now, almost since the beginning. Yet it's impossible to exchange all but the most basic of documents with any of the OpenOffice derivaties (OpenOffice, StarOffice, Novell Office, and Lotus Symphony - OOo 1.1.4). If after five years of active particpation and cooperative efforts, KOffice is unable to exchange ODF docuemnts with OpenOffice, how is it that somehow Microsoft Office would be able to implement ODF without similar zero interop results? Isn't the purpose of standardized formats that end users of different applications could effectively exchange documents? The truth is that both ODF and OOXML are application specific formats. And you can't harmonize, merge, map, or translate between two application specific formats without also having harmonized the appli
1More
OOXML vs ODF: where next for interoperability? | Reg Developer - 0 views
-
'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.
2More
shared by Gary Edwards on 06 Mar 07
- Cached
Most Business Tech Pros Wary About Web 2.0 Tools In Business - Technology News by Infor... - 0 views
www.informationweek.com/...showArticle.jhtml
exchange iso microsoft msoffice oasis odf ooxml opendocument openxml sharepoint vista xml
![](/images/link.gif)
-
How should an IT team start thinking about an Enterprise 2.0 strategy? One way is to carve it into two main areas. The first is Web-based information sharing--think business versions of Wikipedia, MySpace, and Flickr. A sizable minority of companies are finding effective business uses for blogs, wikis, syndicated feeds, pervasive search, social networking, collaborative content portals like SharePoint, and mashups that use easier-to-integrate APIs and fast-response development techniques such as Ajax. One example: Wikis, which let multiple people access and edit a document online, are widely used at 6% of companies in our survey and used effectively by a few employees at 25% of companies. The second area is voice and messaging, where voice over IP, instant messaging, presence, videoconferencing, and unified communications can make it possible to connect people in more relevant ways. Unified communications entails the blending of voice calls, video, and messages, coupled with functionality like embedded click-to-call links in documents and contact lists and the ability to see if colleagues and partners are available to chat. It's widely used at 13% of companies surveyed and effectively by a few at 24%.
-
Great coverage from InformationWeek about the emerging Enterprise 2.0 arena. Author Michael Hoover does not get too deep into the Information Processing Chain, as exampled by the integrated Vista Stack of desktop, server, device,Internet systems and services. But he provides a more than adequate framework for evaluating chain components.
As the ODF - OOXML battle contiues to expand, engulfing swallowing and swamping near everythign in it's path, the day is not too far off when the battle will move to the center of Enterprise 2.0 considerations. It has to. XML Hubs are how these converging technologies are going to be gathered, integrated and configured to impact rapidly changing business processes. There has to be a universal transport in these systems that all applications can work, and nothig matches the highly portable and interactive document/data capabilities of ODF and OOXML. They alone own the desktop prodcutivity environment migration to XML. And it will be through XML - RDF/XML that the Hubs finally integrate the flow of information between desktops, servers, devices and Internet systems.
~ge~