Skip to main content

Home/ Document Wars/ Group items tagged chains

Rss Feed Group items tagged

Gary Edwards

Microsoft Closer on \'Office Open\' Blessing - 0 views

  • Opponents to OOXML, which include IBM (Quote) and the Open Document Foundation, have argued that Microsoft's specifications are unwieldy and that the standard application is redundant with the Open Document Format (ODF), which already exists. Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address different needs in the marketplace," the company wrote in an open letter published earlier this month.
  •  
    Internet News is reporting that Ecma has submitted to the ISO/IEC JTC1 their repsonsess to the 20 "fast track" for Ecma 376 (OOXML) objections.  Nothing but blue skies and steady breeze at their back for our friends at Redmond, according to Ecma's rubber stamper in chief, Jan van den Beld.

    Once again there is that ever present drum beat from Microsoft that ODF can't handle MSOffice and legacy MSOffice features - including but not mentioned the conversion to XML of those infamous billions of binary documents:
    "Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address diffe
Gary Edwards

Microsoft Watch - Business Applications - Convergence=Integration - 0 views

  • 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.
Gary Edwards

But can they implement ODF? South African Government Adopts ODF (and not OOXML) - 0 views

  • That said, it goes on to acknowledge that “there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects.
  •  
    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

Most Business Tech Pros Wary About Web 2.0 Tools In Business - Technology News by Infor... - 0 views

  • 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~

Gary Edwards

Does ODF Have a Future? - 0 views

  •  
    This section of the Slashdot discussion of the LinuxWorld "Game Over" article concerns itself with RTF and Microsoft. ACME 376 "decodes" and converts MS RTF to XML encoded RTF. The full da Vinci process follows this chain: imbr<>MS RTF<>ACME 376<>InfoSet = output target file format MS RTF is the internal structuring stage that all in-memory-binary-representation are sent through with any conversion. Including the conversion of imbr to OOXML The OOXML plugin process looks like this: imbr<>MS RTF<>OOXML The da Vinci ODF process looks like this: imbr<>MS RTF<>ACME<>InfoSet<>ODF The da Vinci CDF process outputs to CDF instead of ODFThe reason we need to output to something other than ODF is that the OASIS ODF TC has no interest in provisioning the ODF specification with much needed iX "interoperability eXtensions". the iX eXtensions were designed to accomodate the high fidelity "round trip" conversion of existing MS documents to ODF while establishing a high level of interoperability with existing MS applications and workgroup processes.
Gary Edwards

Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 0 views

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

Bloggers beware: You're liable to commit libel | CNET Tech news blog - - 0 views

  • To prove libel, which is the same thing as written defamation, the plaintiff has to prove that the blogger published a false statement of fact about the plaintiff that harmed the plaintiff's reputation. Let's break that down. "Published" means that at least one other person may have read the blog. That's right, just one. A "false statement of fact" is a statement about the plaintiff that is not true. Truth is the best defense against libel. An opinion is also a defense against libel. But, depending on the context, the difference between an opinion and a statement of fact can be remarkably gray. Context is a big deal in determining defamation. One thing to watch out for: simply inserting the words "in my opinion" in front of a statement of fact doesn't magically make it an opinion. Satire and hyperbole can also be defenses against libel, but again, very gray. Then there's the matter of "harming the plaintiff's reputation." It's one thing to say that a false statement harmed your reputation, but if you can't demonstrate damages, the suit may be effectively worthless. Damages would include, for example, losing X customers that represent Y income, suffering emotional distress and so on. Also, if your damages are minimal, you may have a hard time finding a lawyer to take the case. They're a greedy lot. (That's an opinion, not a statement of fact.) If the plaintiff is your average, everyday, run-of-the-mill person or company, then negligence is sufficient to prove libel. That means that a reasonable person would not have published the defamatory statement. If the plaintiff is a "public figure," however, then the plaintiff must prove actual malice--a higher burden of proof. That means that the blogger knew that the statement wasn't true or didn't care. Then there's the question of who's responsible for comments on a blog. Whoever publishes the Web site is responsible for content on the site. That includes comments. However, many bloggers have independent agreements to indemnify the site that publishes their blog. That may or may not include comments. Plaintiffs can certainly sue everybody in the chain and see what sticks, though they will likely go after those with the deepest pockets. You can avoid the entire question by turning comments off.
Gary Edwards

Open Stack: Game Time for OpenDocument - 0 views

  • IMHO, it all comes down to one question: > *... Is ODF able to handle everything EOOXML was designed for? Is there something you can do in EOOXML that can't be done with ODF? > Microsoft insists that the reason they developed EOOXML is that ODF is inadequate and unable to handle the advanced features of MSOffice, and, most importantly, the billions of binary legacy documents produced by the many versions of MSOffice still in production. > The answer to this question is that ODF can handle everything MSOffice can throw at it. > There are two ways of proving this. >
  •  
    The primary difference between ODF and MOOXML is that ODF was designed to be a universal file format.  MOOXML was designed to be an XML file format for MSOffice, the Win32 API, and the Vista Information Processing Chain API (.NET 3.0). 

    ODF is application and platform independent.  MOOXML is application and platform specific.  It's bound to the Windows - Vista platform. 

    Microsoft's Brian Jones recently got caugh tup in a argument with the heavily armed WMD ODF expert and combatant Sam Hiser (WMD=Words of Massive Destruction).  In their exchange, Brian got confused over this very important distinction between ODF and MOOXML.  ODF allows specific applications to place their configurations and requirements in a settings file that is separate from the content, presentation and metadata containers.  MOOXML on the other hand makes no distinction whatsoever between application specific (MSOffice only) configuration, settings, processsing instructions and systemm dependencies and the rest of the file format contents.  Application settings are bound to content, presentation, and schema containers.  So bound that Brian is seemingly unaware of what ODF has achieved.  Sam caught him by surprise, as did many others posting comments:

    Brian Jones on MOOXML support for older versions of MSOffice:  Coments by Sam the WMD Man are below.


1 - 8 of 8
Showing 20 items per page