Skip to main content

Home/ OpenDocument/ Group items tagged ISO

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

OOXML in Norway: The haywire process | Geir Isene : Straight talk on IT - 0 views

blogs.freecode.no/isene

interoperability iso odf officeopenxml ooxml opendocument

shared by Gary Edwards on 28 Aug 07 - Cached
  • I had read the essay by Jon Bosak (SUN Microsystems) on why SUN voted as it did in the US. He lays out a very different strategy. His view is that the battle is lost to completely reject OOXML as an ISO standard. ISO can only reject it with comments, and that is equivalent to giving Microsoft a todo-list on how to fix the draft so as to get it approved. Microsoft has sufficient manpower to easily tackle that. Most of us had missed what Mr. Bosak saw: OOXML promises interoperability with earlier closed binary formats (the Word Doc, older Excel file formats etc.). But it doesn’t deliver. How on earth could someone be able to convert old binary files to the new format without having the specification of the old formats and a mapping to OOXML. If you are to translate some text from Chinese to English, it doesn’t much help to only know English.
    • Gary Edwards
      Gary Edwards on 28 Aug 07
       
      A "Yes with comments" is a yes for the ISO approval of MS-OOMXL. If ISO approves MS-OOXML, it won't matter what Bosak's "comments" strategy is. Microsoft and the Vista Stack will be off to the races. The full disclosure of the MS binary document secret blueprint won't matter much at that point.
  • “Ah c’mon Bosak, you are chickening out, we must stop this dead in the track”
    • Gary Edwards
      Gary Edwards on 28 Aug 07
       
      There you go Geir!

      Sun and Bosak have held the door open for MS-OOXML since 2002, when Sun blocked an effort to write the ODF Charter to include as a priority, "compatibility with existing file formats". This of course would include the billions of legacy MS binary documents.

      The thing is that those who work in the conversion-translation field will tell you that it is currently impossible to pipe converted legacy binary documents and OOXMl docs for that matter into ODF. Just as Microsoft claims, ODF in it's current state is insufficient and unable to handle the rich feature set of the MSOffice developers platform.

      The problem could of course be easily fixed by the inclusion in ODF of five structural generics. In the past year, there have been no less than five iX "interoperability enhancement" proposals submitted to the OASIS ODF TC for discussion and consideration. As uber universal interop expert Florian Reuter points out in his blog, these iX proposals did not fare so well.

      What Florian doesn't point out is that it was Sun who opposed any and all efforts to improve compatibility with existing Microsoft binary and OOXML documents. Just as they have done for nearly five years now.

      Sort of puts the Sun-Bosak support for ISO approval of MS-OOXML in a different light. ~ge~
  • Gary Edwards on 28 Aug 07
     
    see the sticky notes on this one
Gary Edwards

Microsoft Will Support ODF! But Only If ISO Doesn't 'Restrict Choice Among Formats' - 0 views

www.betanews.com/...1181922127

ecma-376 iso microsoft odf officeopenxml ooxml opendocument xml

shared by Gary Edwards on 19 Jun 07 - Cached
  • 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.
  • Gary Edwards on 19 Jun 07
     
    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
Gary Edwards

An Antic Disposition: Cracks in the Foundation - IBM takes over ODF - 0 views

www.robweir.com/...cracks-in-foundation.html

foundation ibm odf odf-civil-war opendocument weir

shared by Gary Edwards on 24 Oct 07 - Cached
  • You must admire their tenacity. Gary Edwards and the pseudonymous "Marbux". The mythology of Silicon Valley is filled with stories of two guys and a garage founding great enterprises. And here we have two guys, and through blogs, interviews, and constant attendance at conferences, they have become some of the most-heard voices on ODF. Maybe it is partly due to the power of the name? The "OpenDocument Foundation" sounds so official. Although it has no official role in the ODF standard, this name opens doors. The ODF Alliance , the ODF Fellowship, the OASIS ODF TC, ODF Adoption TC (and many other groups without "ODF" in their name) have done far more to promote and improve ODF, yet the OpenDocument Foundation, Inc. seems to score the panel invites. Not bad for two guys without a garage.
  • Gary Edwards on 24 Oct 07
     
    An eMail went out today, October 24th, 2007, nominating IBM's Rob "Show me your garage!" Weir to be the new Co Chairman of OASIS ODF TC.  So it's looks like it's true; IBM is moving to take over ODF and OpenOffice.

    Not that that's bad.  In the long run this is perhaps the best thing that ever happened to ODF and OpenOffice.  There is no way IBM's Lotus Notes business plan for ODF-OOo could be any worse than Sun's plan has turned out to be. 

    ~ge~

  • Gary Edwards on 28 Oct 07
     
    So, South Africa was watching closely the failed effort in Massachusetts to implement ODF?  And now they are determined to make it work? Good thing they left themselves a "pragmatic" out; "there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects."

    Massachusetts spent a full year on an ODF implementation Pilot Study only to come to the inescapable conclusion that they couldn't implement ODF without a high fidelity "round trip" capable ODF plug-in for MSOffice.  In May of 2006, Pilot Study in hand, Massachusetts issued their now infamous RFi, "the Request for Information" concerning the feasibility of an ODF plug-in clone of the MS-OOXML Compatibility Pack plug-in for MSOffice applications. At the time there was much gnashing of teeth and grinding of knuckles in the ODf Community, but the facts were clear. The lead dog hauling the ODf legislative mandate sleigh could not make it without ODf interoperability with MSOffice. Meaning, the rip out and replace of MSOffice was no longer an option. For Massachusetts to successfully implement ODf, there had to be a high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications. Although ODf was not designed to meet these requirements, the challenge could not have been any more clear. Changes in ODf would have to be made. So what happened?

    Over a year later,
Gary Edwards

Does ODF 1.2 Metadata Solve the Interop Problem? - Microsoft starts rolling out more O... - 0 views

talkback.zdnet.com/5208-12558-0.html

afnor cdf iso maryjo merger metadata odf ooxml opendocument talkback zdnet

shared by Gary Edwards on 11 Dec 07 - No Cached
  • Sorry Shish, you're wrong about ODF 1.2 Try ODF 1.5 or ODF 2.0, maybe. The metadata requirements for ODF 1.2 actually did include two way lossless translation capability. Unfortunately these features did not survive the final cut, and were not included in the April 2007 submission. You might also want to check the February 23, 2007 metadata proposal from Florian Reuter. That also would have delivered the goods and perhaps put ODF that grand convergence category of usefulness across desktops, servers, devices and web systems currently the exclusive domains of MS-OOXML and CDF+. Florian had devised a means of using metadata to describe the presentation aspects of content and structural objects. Very revolutionary. And based on the simple notion that bold, font, margins etc. are simply metadata about content and style objects. Where the train came off the track had to do with the concept of an XML ID means of linking metadata to content. Not that there was anything wrong with this mechanism. It's actually quite clever. What went wrong was that Sun insisted that only those elements approved and supported by OpenOffice would be allowed to make use of XML ID metadata. For independent developers, this is a serious constraint. Because of this constraint, the metatdata sub committee started off with six elements supported by OOo that metadata could be appied to. IBM then came in and asked for eleven more elements having to do with charts and graphs. The OpenOffice crew decided they could support this, so in they went. Then an interesting question was posed, "How are independent developers supposed to submit elements for metadata consideration?"
  • Gary Edwards on 11 Dec 07
     
    A Second response to Mary Jo's, "Microsoft starts rolling out more OOXML translators" is also posted here. The title is "Standardization by Corporation". Shish-Ka-Bob makes the assertion the ODF 1.2 metadata model will enable lossless two way conversion between MSOffice and ODF. While it's true that that intent was a key component of the original July of 2006 Metadata Requirements, the proposal was eventually stripped from the final submission made in April of 2007. I try to explain to Shish how that came about. The second post here, "Standardization by Corporation", is a follow on to statements made to Shish. The statements have to do with the events at ISO, and what i think will eventually happen. IMHO, ISO will follow either the AFNOR or Brittish proposals to merge ODF and OOXML. To do this they will remove entirely the coproarate vendor influence of Ecma and OASIS, and perfect the merger entirely at ISO. My post just happened to coincide with ISO Governor Mark Bryan's "Standardization by Corporations" letter. A derpressing but nevertheless very true concern. In fact, the OpenDocument Foundation was created specifically to address our concerns about the undue influence big application vendors were exerting on ODF following the April 30th, 2005 approval of ODF 1.0 (which went on to become ISO 26300). ~ge~
Gary Edwards

Microsoft Loses, Spins Open XML Vote - 0 views

www.eweek.com/...0,1759,2178917,00.asp

shared by Gary Edwards on 04 Sep 07 - Cached
  • "The large number of reported 'no' votes [15] and 'abstentions' [9] demonstrates the depth of concern around the world over OOXML's interoperability and openness. The 'no's' included some of the fastest-growing economies in the world and major industrialized countries, in stark contrast to ODF, which was approved unanimously [31-0] by ISO in 2006. ODF remains the document format of choice for governments, as it is now being considered for use by countries in every major region of the globe. Microsoft has every right to seek the ISO label for OOXML, but, as the ballot results show, it has a long way to go before it earns it and can be considered a truly open, interoperable document format," said Marcich.
    • Gary Edwards
      Gary Edwards on 04 Sep 07
       
      Let's all hope Marino isn't called on to back up these statements! ODF has zero interoperability. Conformance is entirely optional and in direct violation of ISO Conformance Directives.

      In May of 2006, the ISO JTC1 requested of the ISO Directive Counsel an exception for ODF. The request was refused. ODF remains in violation.
Gary Edwards

Harmonization Wars : Is it jetlag? | Brian Jones: Open XML- Open Document Formats - 0 views

blogs.msdn.com/...is-it-jetlag.aspx

harmonization jones odf ooxml opendocument openxml weir

shared by Gary Edwards on 01 Feb 08 - Cached
  • if you actually read the Ecma response, you'll see that TC45's position is actually quite the opposite. Harmonization is not as simple as just adding a few tags here and there. It's going to be a lot of hard work, and the German Standard Body (DIN) is already working on the first step, which is to identify the differences. This isn't something to take lightly. Here is Ecma's full response to this issue (emphasis added): There are currently several XML-based document formats in use, each designed to address a different set of goals or requirements. These include ISO/IEC IS 26300 (ODF), China's UOF, and ECMA-376 (DIS 29500 – Open XML). All these formats have numerous implementations in multiple tools and multiple platforms (Linux, Windows, Mac OS, hand-held devices). The Ecma Response Document from the Fast Track 30-Day contradiction phase for DIS29500 addressed the question of harmonization by explaining the differences between the ODF and Open XML formats as follows:
  • Gary Edwards on 01 Feb 08
     
    Brian Jones responds to Rob Weir's very strange demand that he be put in charge of any harmonization effort involving ODF and OOXML.
    In his response, Brian points to the Ecma official statement in support of harmonization provided in February of 2007. The harmonization response was directed at ISO National Body members objecting to the proposed fast tracking of OOXML.
    In late February -early March of 2007, the EU held an "interoeprability Workshop" in Berlin, Germany.The session was attended by IBM, Sun and Microsoft, as well as Ecma and OASIS.
    The EU took a very hard line position on "harmonization", embracing a position put forward by the French ISO NB group known as AFNOR. The WorkShop was followed by the EU establishment of DIN Workgroup NIA-01-34, headed by the Fraunhoffer Fokus Institute.
    The DIN WG sent out invites to all the major players, with Microsoft and Novell accepting the invitation to particpate in the harmonizatioon effort. IBM and Sun refused the invitation.
    Recently DIN invited the OASIS ODF Technical Committee to join the harmonization effort. The OASIS TC responded by asking Novell developer (and DIN participant) Florian Reuter to act as liaison to DIN. ODF grand puba Rob Weir himself put forward this request.
    Here's the thread: http://www.oasis-open.org/archives/office/200801/msg00040.html
    Now it looks like the grand puba is backtracking! Rob Weir wants to put himself in charge of harmonization. And we all know where that would lead.
    Harmonization will be difficult. It might even be impossible. As indicated by the Ecma statement Brian copiies in his post.
    The dynamics of harmonization are fairly simple to understand; you can't harmonize two application specific formats without also harmonizing the applications. This problem is further complicated by the fact that the presentation layers (styles) of both ODF
Gary Edwards

Open Stack: ISO Does The Unthinkable. How ISO approval of MSOffice-OOXML will break th... - 0 views

openstack.blogspot.com/...ment-as-perfect-microsoft.html

css davinci interoperability msoffice odf ooxml xaml xhtml

shared by Gary Edwards on 22 Apr 08 - Cached
  • In August of 2007 we dropped ODF as the da Vinci target conversion format, and moved to the W3C's Compound Document Format (CDF) with an ePUB wrapper.The reason for this move is that we could not establish a reasonable degree of interoperability with OpenOffice ODF unless Sun supported the five generic eXtensions to ODF needed to hit the high fidelity conversion the da Vinci process is capable of.Since da Vinci is a clone of the MSOffice OOXML compatibility Kit, we use the same internal conversion process where imbr (in-memory-binary-representation) is converted to another format: imbr <> OOXML or, imbr <> RTF.While it's entirely compliant to eXtend ODF, without Sun's changes to OpenOffice ODF the application-platform-vendor independent interoperability end users expect would be meaningless.The problem as we see it is this; it is impossible to do a high fidelity conversion between two application specific XML formats. It is however quite possible to do a conversion between an application specific format and a generic (application-platform-vendor independent) format.
  • Gary Edwards on 22 Apr 08
     
    A summary of my views on ISO approval of MSOffice-OOXML and the impact it will have on the futrue of the open web.
  • Gary Edwards on 22 Apr 08
     
    In response to a recent question posted to a rather old OpenStack blog, i posted this summary of my views on ISO approval of MSOffice-OOXML and the impact it will have on the futrue of the open web.
Gary Edwards

FAA May Ditch Microsoft's Windows Vista And Office For Google And Linux Combo - Technol... - 0 views

www.informationweek.com/...showArticle.jhtml

iso microsoft odf ooxml xml

shared by Gary Edwards on 13 Mar 07 - Cached
  • Bowen's compatibility concerns, combined with the potential cost of upgrading the FAA's 45,000 workers to Microsoft's next-generation desktop environment, could make the moratorium permanent. "We're considering the cost to deploy [Windows Vista] in our organization. But when you consider the incompatibilities, and the fact that we haven't seen much in the way of documented business value, we felt that we needed to do a lot more study," said Bowen. Because of Google Apps' sudden entry into the desktop productivity market
  • Gary Edwards on 13 Mar 07
     
    The FAA issues their "NO ViSTA" mandate, hinting that it might be permanent if they can come up with MSOffice alternatives.  They are looking at Google Apps!

    Okay, so plan B does have legs.  The recent failure of ISO/IEC to stand up to the recidivist reprobate from Redmond is having repercussions.  Who would have ever thought ISO would fold so quickly without ceremony?  One day there are 20 out of 30 JTCS1 national bodies (NB's) objecting to Micrsoft's proprietary XML proposal, the MOOX Ecma 376 specfication, and the next ISO is approving without comment the placing of MOOX into the ISO fast track where approval is near certain.  With fast track, the technical objections and contradictions are assumed to be the provence of Ecma, and not the JTCS1 experts group.

    Apparently the USA Federal Government divisions had a plan B contingency for just such a case.  And why not?  Microsoft was able to purchase a presidential pardon for their illegal anti trust violations.  If they can do that, what's to stop them from purchasing an International Standard?  Piece of cake!

    But Google Apps?  And i say that as one who uses Google Docs every day.

    The problem of migrating away from MSOffice and MOOX to ODF or some other "open" XML portable file format is that there are two barriers one must cross.

    The first barrier is that of converting the billions of MS binary docuemnts into ODF XML. 

    The second is that of replacing the MSOffice bound business processes that drive critical day to day business operabions. 

    Google Apps is fine for documents that benefit from collaborative computing activities.  But there is no way one can migrate MSOffice bound business processes - the workgroup-worflow documents to Google Apps.  For one thing Google Apps is unable to facillitate important issues like XForms.  Nor can they round trip an ODF document with the needed fidelity a
Gary Edwards

Any objections? For Open XML standard, yes (still) - 0 views

www.computerworld.com/...article.do

ecma ecmaresponse iso

shared by Gary Edwards on 06 Mar 07 - Cached
  • Gary Edwards on 06 Mar 07
     
    This brief summary of the ODF <>OOXML controversy covers the recent response by Ecma to the ISO/IEC JTC 1 National Body members who filed objections to placing Ecma 376 on an ISO fast track approval process.    This article has the actual ECMA Response PDF!  A document that is well worth reading and studying.

    Essentially Ecma has told ISO to take a hike! 

    In responding to the different objections, Ecma chose to explain their position without once offering to fix or remedy he many problems and issues that so concern the 20 different NB's filing objections.  Not once!  No compromise whatsoever, only the preachy attitude that the objecting NB's simply don't understand the wonders of Ecma 376 or what a ISO "contraditction" means.

    Take a Hike!  Up Yours!  Screw you and the horse you rode in on too! 

    Pick your metaphor, it's all the same. 

Gary Edwards

Novell adds fuel to the fire in OOXML feud - News - Builder AU - 0 views

www.builderau.com.au/...0,339028227,339284338,00.htm

shared by Gary Edwards on 11 Dec 07 - Cached
  • Microsoft has created its own proprietary document format, Office Open XML (OOXML), as a rival to the community-developed OpenDocument Format (ODF). OOXML is used in Microsoft's latest applications suite, Office 2007. Despite some efforts by the two camps, ODF and OOXML are, for the most part, not interoperable, meaning documents that are created in one format cannot be successfully read by applications based on the other format. According to Novell's vice president of developer platforms, Miguel de Icaza, the situation won't change in the foreseeable future. Want to know more? For all the latest news, analysis and opinion on open source, click here "There's no end in sight to the ongoing disputes between the two camps," said de Icaza, speaking at XML 2007, a Microsoft-sponsored event, on Tuesday. "In 2006, there was lots of FUD [fear, uncertainty and doubt] about the problems behind OOXML and it went downhill from there," Icaza said. "Neither group is willing to make the big changes required for real compatibility," de Icaza added.
    • Gary Edwards
      Gary Edwards on 11 Dec 07
       
      What efforts are you talking about? The last time any effort was made to accomodate interoperability was in 2003 with the establishment of the ODF "Compatibilty clause" (Section 1.5). "Despite some efforts by the two camps, ODF and OOXML are, for the most part, not interoperable, meaning documents that are created in one format cannot be successfully read by applications based on the other format......" Section 1.5 authorizes the use of "foreign elements" and "alien attributes". These techniques were specifically written into ODF for handling unknown characteristics of existing MSOffice documents (binary and/or xml) on conversion to ODF. Since the Section 1.5 addition in 2003, every other suggestion to improve interop between ODF and MSOffice documents has been rejected by the OASIS ODF TC and Sub Committees. There are three problems with Section 1.5. The first is that there is only so much that can be done with foreign elements and alien attributes. There are still remaining compatibility issues relating to the basic structures of lists, tables, fields, sections and page dymnamics. The OpenDocument Foundaiton spent over a year trying to get approval for five generic elements relating to these structures, without success. As i said, there has not been a single successful comatibility - interoperability effort since 2003, although many have been proposed. The second reason for the failure of Section 1.5 is that OpenOffice only partially implements the "Compatibility Clause". OOo only recognizes "foreign elements and alien attributes" with text spans and paragraphs. The third reason is that "compatibility" is optional in ODF. The clause does not have any teeth. Applications can implement only those aspects of the spec they feel like implementing, and still be in total "compliance". This creates serious interop problem not only for MSOffice plug-in comverted documents, but also renders as
Gary Edwards

The Merging of SOA and Web 2.0: 2 - 0 views

www.eweek.com/...0,1895,2158559,00.asp

2.0 ajax mashup odf ooxml soa web

shared by Gary Edwards on 15 Jul 07 - Cached
  • In many cases, the mashups' data or information sources have incompatible formats so integration becomes a problem.
  • Gary Edwards on 15 Jul 07
     
    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
Gary Edwards

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

shared by Gary Edwards on 13 Jul 07 - Cached
  • 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.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      Okay, now Joe has the Micrsoft SOA bull by the horns.  Why doesn't he wrestle the monster down?
  • Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      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.

  • Gary Edwards on 15 Jul 07
     
    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
Gary Edwards

Open Malaysia: Rick Jelliffe - myths debunked? - 0 views

www.openmalaysiablog.com/...rick_jelliffe_m.html

shared by Gary Edwards on 17 Jun 07 - Cached
  • Additionally, ODF was not ratified with SVG, MathML, XLink, Zip and other W3C standards all together at the same time. Instead the prior W3C standards were already well established and approved in their own right and in their own time with the relevant experts of their specific domains vetting it. MSOOXML also incorporates proposed "standards" which failed in the marketplace and now is offered a "backdoor" to standardisation process by piggy backing this nebulous specification. (See VML vs SVG, and MathML vs Microsoft Office MathML) So there is a myth being built that ODF and its constituent parts are just as large as MSOOXML, and therefore MSOOXML is OK. I for one would rather MSOOXML be even larger; to cater for unknown tags like "lineWrapLikeWord6" or a Macro specification. However what troubles me is that the special relationship between Ecma and ISO should be abused with the fast tracking of this large specification.
  • Gary Edwards on 17 Jun 07
     
    Yoon Kit brings up an interesting point about the ISO consideration of MSOOXML (Ecma 376);  ISO approval of MSOOXML would backdoor a good many MS proprietary technologies that compete directly with W3C XML standards.

    YK gives the example of MS VML, which competes with the W3C SVG standard used by ODF.  He could have also cited that legacy versions of MSOffice (98-2003) make use of VML as the default graphic format, while MSOffice 2003 9with XML plugin) and MSOffice 2007 (by default) implements DrawingML as the replacement for VML. 

    So, would ISO approval of Ecma 376 backdoor VML and DrawingML in as "standards"?  Or MSOffice MathML?   One has to wonder since they are essential to MSOOXML.

Gary Edwards

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

shared by Gary Edwards on 06 Feb 08 - Cached
  • 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.
  • Gary Edwards on 06 Feb 08
     
    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
Gary Edwards

Brian Jones: Open XML Formats : Mapping documents in the binary format (.doc; .xls; .pp... - 0 views

blogs.msdn.com/...pt-to-the-open-xml-format.aspx

burtongroup cdf css ibm iso microsoft odf okelly ooxml opendocument openxml sun w3c xhtml

shared by Gary Edwards on 20 Jan 08 - Cached
  • The second issue we had feedback on was an interest in the mapping from the binary formats into the Open XML formats. The thought here was that the most effective way to help people with this was to create an open source translation project to allow binary documents (.doc; .xls; .ppt) to be translated into Open XML. So we proposed the creation of a new open source project that would map a document written using the legacy binary formats to the Open XML formats. TC45 liked this suggestion, and here was the TC45 response to the national body comments: We believe that Interoperability between applications conforming to DIS 29500 is established at the Office Open XML-to- Office Open XML file construct level only.
    • Gary Edwards
      Gary Edwards on 20 Jan 08
       
      And here i was betting that the blueprints to the secret binaries would be released the weekend before the September 2nd, 2007 ISO vote on OOXML! Looks like Microsoft saved the move for when they really had to use it; jus tweeks before the February ISO Ballot Resolution Meetings set to resolve the Sept 2nd issues. The truth is that years of reverse engineering have depleted the value of keeping the binary blueprints secret. It's true that interoperability with MSOffice in the past was near entirely dependent on understanding the secret binaries. Today however, with the rapid emergence of the Exchange/SharePoint juggernaught, interop with MSOffice is no longer the core issue. Now we have to compete with E/S, and it is the E/S interfaces, protocols and document API's and dependencies tha tmust be reverse engineered. The E/S juggernaught is now surging to 70% or more of the market. These near monopoly levels of market penetration is game changing. One must reverse engineer or license the .NET libraries to crack the interop problem. And this time it's not just MSOffice. Today one must crack into the MS Stack whose core is tha tof MSOffice <> E/S. So why not release the secret binary blueprints? If that's the cost of getting the application, platform and vendor specific OOXML through ISO, then it's a small price to pay for your own international standard.
  • Gary Edwards on 20 Jan 08
     
    Well well well. We knew that IBM had access to the secret binary blueprints back in 2006. Now we know that Sun ALSO had access!
    And why is this important? In June of 2006, Massachusetts CIO Louis Gutierrez asked the OpenDocument Foundation's da Vinci Group to work with IBM on developing the da Vinci ODF plug-in clone of Microsoft's OOXML Compatibility Pack plug-in. When we met with IBM they were insistent that the only way OASIS ODF could establish sufficient compatibility with MSOffice and the billions of binary documents would be to have the secret blueprints open.
    Even after we explained to IBM that da Vinci uses the same internal conversion process that the OOXML plug-in used to convert binaries, IBM continued to insist that opening up the secret binaries was a primary objective of the OASIS ODF community.
    For sure this was important to IBM and Sun, but the secret binaries were of no use to us. da Vinci didn't need them. What da Vinci needed instead was a subset of ODF designed for the conversion of those billions of binary documents! A need opposed by Sun.
    Sun of course would spend the next year developing their own ODF plug-in for MSOffice. But here's the thing: it turns out that Sun had complete access to the secret binary blueprints dating back to 2006!!!!!!
    So even though IBM and Sun have had access to the blueprints since 2006, they have been unable to provide effective conversions to ODF!
    This validates a point the da Vinci group has been trying to make since June of 2006: the problem of perfecting a high fidelity conversion between the billions of binaries and ODF has nothing to do with access to the secret binary blueprints. The real issue is that ODF was NOT designed for the conversion of those binary documents.
    It is true that one could eXtend ODF to achieve the needed compatibility. But one has to be very careful before taking this ro
Gary Edwards

Harmonizing ODF and OOXML: The DIN - ISO "Harmonization" Project - 0 views

www.fokus.fraunhofer.de/...DIN-E.pdf

din harmonization iso odf ooxml

shared by Gary Edwards on 27 Jan 08 - No Cached
  • Gary Edwards on 27 Jan 08
     
    Contact: Gerd Schürmann Fraunhofer Institute FOKUS Tel +49 (0)30 3463 7213 gerd.schuermann@fokus.fraunhofer.de Berlin
  • Gary Edwards on 27 Jan 08
     
    At a recent meeting in Berlin, The DIN Fraunhoffer Institute pushed forward with the EU project to harmonize ODF and OOXML. Microsoft and Novell attended the harmonization effort. Sun and IBM did not. This in spite of invitations and pleas to cooperate coming into Sun and IBM from government officials across the European continent. We've long insisted that inside the OASIS ODF Technical Committee walls there have been years of discussions concerning ODF compatibility with the billions of MS binary documents, and ODF interoperability with MSOffice. Sun in particular has been very clear that they will not compromise OpenOffice application innovations to improve interoperability with MSOffice and MSOffice documents. The infamous List Enhancement Proposal donnybrook that dominated OASIS ODF discussions from November 20th, 2006, to the final vote in April of 2007, actually begins with a statement from Sun arguing that application innovation is far more important than market demands for interoperability. The discussions starts here: Suggested ODF1.2 items The first of many responses declaring Sun's position that innovation trumps interop, and that if anyone needs to change their application it should be Microsoft: see here DIN will submit a "harmonization" report with recommendations to ISO JTC1. I wonder if IBM and Sun will continue to insist on government mandated "rip out and replace" solutions based on their ODF applications when ISO and the EU have set a course for "harmonization"?
Gary Edwards

OOXML and ISO: The Process Challenge - A Predictable Path | Matusow's Blog - 0 views

blogs.msdn.com/...llenge-a-predictable-path.aspx

iso jtc-1 ooxml open-standards

shared by Gary Edwards on 08 Apr 08 - Cached
  • Where can we expect challenges?
  • Gary Edwards on 08 Apr 08
     
    Scott B responds to Matusow blathering with a list of ISO changes that should be made given the OOXML fiasco, but won't.
Gary Edwards

OOXML: MSOffice Open XML - Where The Rubber Meets The Road | Matusow's Blog - 0 views

blogs.msdn.com/...the-rubber-meets-the-road.aspx

iso matusow msoffice ooxml open-standards

shared by Gary Edwards on 08 Apr 08 - Cached
  • There can be no doubt that OOXML, as a standard, has severe flaws. &nbsp; It is incomplete, platform specific, application specific, full of contradictions, fails to adhere to existing standards, untestable, and presents a moving target for any IT worker. &nbsp;There is not an organization in existence, including Microsoft, that promises to actually implement the full standard. &nbsp;Much of this is due to the fact the final version doesn't actually exist on paper yet, but a large fraction is also do to the patchwork nature of the product. The reason governments and companies wanted a 'office apps' standard in the first place was to release an avalanche of data from aging applications. &nbsp;OOXML shows every appearance of being created to prevent this escape, not enable it. &nbsp; The immaturity of the standard means that it remains a gamble to see if older documents will remain readable or not. &nbsp;The lack of testing means there is no way to determine what docs actually adhere to it or not. &nbsp;The ignoring of existing standards guarantees compatibility problems. &nbsp;All of these factors are handy for the owner of the biggest share of existing documents, as it forces users to continue to use only _their_ application or risk danger from every other quarter.
  • Gary Edwards on 08 Apr 08
     
    Perhaps the single best comment i've ever read concerning OOXML and the value of standards. Very concise and too the point. Thanks you Scott B!
  • Gary Edwards on 08 Apr 08
     
    ISO NB's approved MS-OOXML not because it meets ISO Interoperability Requirements. It doesn't. OOXML doesn't even come close. They approved OOXML because it's the best deal they can get given the MSOffice predicament their governments are caught in. Governments got the binary blueprints they have been insisting on, but didn't get the mapping of those binaries to OOXML. Governemnts also took control of OOXML, with Patrick Durusau and the JTC-1 now in copmplete control of the specifications future. Sadly though, Durusau and company will not be able to make the interop changes they know are required by ISO and related World Trade Agreements. The OOXML charter prevents any changes that would degrade in any way compatibility with MSOffice! This charter lock was on full display in the Microsoft - Ecma response to Geneva BRM comment resolutions, with Microsoft refusing to address any comments that would alter compliance with MSOffice. Durusau has always believed that a one to one mapping between OOXML and ODF is possible. Just prior to the Geneva BRM though, the EU DIN Workgroup released their preliminary report on harmonization, which they found to be a next to impossible task given the applicaiton specific nature of both ODF and OOXML. The DIN Report no doubt left the mapping-harmonization crowd (lead by Durusau) with few choices other than to take control of OOXML and figure out the binary to OOXML mappings for themselves, wih the hope that somewhere down the road OpenOffice will provide OOXML documents. Meaning, governments are not looking at open standards for XML documents as much as they are looking to crack the economic hammer lock Microsoft has on the desktop.
Gary Edwards

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

shared by Gary Edwards on 07 Apr 08 - Cached
  • 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.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      "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...
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      OK. Nice summary!
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      Great idea Mr. Sorofman, but Microsoft owns the "editor" in this equation.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      Another good summary statement. Convergence however is very much tied to interoperability across the emerging client/ Web-Stack /server model that represents advanced SOA, SaaS, Web 2.0 and emerging Cloud Computing models.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      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.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      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!!!!!
  • Gary Edwards on 07 Apr 08
     
    Dana Gardner transcript of podcast interview with JustSystems and Phil Wainwright. Covers the convergence of the portable XML document model with SOA. It's about time someone out there got it. You know the portable XML document has arrived when analyst finally get it.
Gary Edwards

Microsoft OOXML standardization bid: The clock is ticking | All about Microsoft | ZDNet... - 0 views

blogs.zdnet.com/microsoft

approval iso mary-jo odf ooxml

shared by Gary Edwards on 29 Mar 08 - Cached
  • The battle over OOXML standarization is all about money and marketshare. Microsoft wants OOXML to qualify as an “open standard” so that the company can continue to sell Office into governments that see ISO as the gold standard bearer. Many of the companies&nbsp; that have fought publicly against OOXML gaining ISO standardization approval are hoping that failure of OOXML to get the ISO nod will give them a chance to gain more marketshare in a world where Office still runs on more than 90 percent of Windows desktops.
‹ Previous 21 - 40 of 153 Next › Last »
Showing 20▼ items per page