Skip to main content

Home/ OpenDocument/ Group items tagged presentation

Rss Feed Group items tagged

Gary Edwards

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

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

XML.com: Standard Data Vocabularies Unquestionably Harmful - 0 views

  • At the onset of XML four long years ago, I commenced a jeremiad against Standard Data Vocabularies (SDVs), to little effect. Almost immediately after the light bulb moment -- you mean, I can get all the cool benefits of web in HTML and create my own tags? I can call the price of my crullers &lt;PricePerCruller&gt;, right beside beside &lt;PricePerDonutHole&gt; in my menu? -- new users realized the problem: a browser knows how to display a heading marked as &lt;h1&gt; bigger and more prominently than a lowlier &lt;h3&gt;. Yet there are no standard display expectations or semantics for the XML tags which users themselves create. That there is no specific display for &lt;Cruller&gt; and, especially, not as distinct from &lt;DonutHole&gt; has been readily understood to demonstrate the separation of data structure expressed in XML from its display, which requires the application of styling to accomodate the fixed expectations of the browser. What has not been so readily accepted is that there should not be a standard expectation for how a data element, as identified by its markup, should be processed by programs doing something other than simple display.
    • Gary Edwards
       
      ODF and OOXML are contending to become the Standard Data Vocabulary for desktop office suite XML markup. Sun and Microsoft are proposing the standardization of OpenOffice and MSOffice custom defined XML tags for which there are no standard display expectations. The display expectations must therefore be very carefully described: i.e. the semantics of display fully provided.
      In this article Walter Perry is pointing out the dangers of SDV's being standardized for specific purposes without also having well thought out and fully specified display semantics. In ODF - OOXML speak, we would call display presentation, or layout, or "styles".
      The separation of content and presentation layer of each is woefully underspecified!
      Given that the presnetation layers of both ODF and OOXML is directly related to how OpenOffice and MSOffice layout engines work, the semantics of display become even more important. For MSOffice to implement an "interoperable" version of OpenOffice ODF, MSOffice must be able to mimic the OpenOffice layout engine methods. Methods which are of course quite differeent from the internal layout model of MSOffice. This differential results in a break down of conversion fidelity, And therein lies the core of the ODF interoeprability dilemma!
  • There have also emerged a few "horizontal" data vocabularies, intended for expressing business communication in more general terms. One of these is the eXtensible Business Reporting Language (XBRL), about which more below. Most recently, governments and governmental organizations have begun to suggest and eventually mandate particular SDVs for required filings, a development which expands what troubles me about these vocabularies by an order of magnitude.
  • ...5 more annotations...
    • Gary Edwards
       
      Exactly! When governments mandate a specific SDV, they also are mandating inherent concepts and methods unique to the provider of the SDV. In the case of ODF and OOXML, where the presentation layers are application specific and woefully underspecified, interoperability becomes an insurmountable challenge. Interop remains stubbornly application bound.
      Furthermore, there is no way to "harmonize" or "map" from one format to another without somehow resolving the application specific presentation differences.
    • Gary Edwards
       
      "in the nature of the SDV's themselves is the problem of misstatement, of misdirection of naive interpretation, and potential for fraud.
      Semantics matter! The presentation apsects of a document are just as important as the content.
    • Gary Edwards
       
      Walter: "I have argued for years that, on the basis of their mechanism for elaborating semantics, SDVs are inherently unreliable for the transmission or repository of information. They become geometrically less reliable when the types or roles of either the sources or consumers of that information increase, ending at a nightmarish worst case of a third-order diminution of the reliability of information. And what is the means by which SDVs convey meaning? By simple assertion against the expected semantic interpretations hard-coded into a process consuming the data in question.
      At this point in the article i'm hopign Walter has a solution. How do we demand, insist and then verify that SDV's have fully specifed the semantics, and not jus tpassed along the syntax?
      With ODF and OOXML, this is the core of the interoperability problem. Yet, there really is no way to separate the presentation layers from the uniquely different OpenOffice and MSOffice layout engine models.
    • Gary Edwards
       
      Interesting concept here: "the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it ........ it is these expert connections which SDV's are intended to sever.
      Not quite sure what to make of that statement? When an SDV is standardized by ISO, the expectation is that the connections between data and processes would be fully understood, and implementations consistent across the board.
      Sadly, ODF is ISO approved, but doesn't come close to meeting these expectations. ODF interop might as well be ZERO. And the only way to fix it is to go into the presentation layer of ODF, strip out all the application specific bindings, and fully specifiy the ssemantics of layout.
  • In short, the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it. It is precisely these expert connections which standard data vocabularies are intended to sever.
Gary Edwards

The ODF Alliance puckers up and gets smacked with the great CSS question - Where is it?... - 0 views

  • Harmonisation It is interesting that the ODF Alliance quotes Tim Bray that the world doesn’t need another way to express basic typesetting features. If it is so important, why didn’t ODF just adopt W3C CSS or ISO DSSSL conventions? Why did they adopt the odd automatic styles mechanism which no other standard uses? Now I think the ODF formating conventions are fine, and automatic styles are a good idea. But there is more than one way to make an omlette, and a good solution space is good for users. My perspective is that harmonisation (which will take multiple forms: modularity, pluralism, base sets, extensions, mappings, round-trippability, feature-matching, convergence of component vocabularies, etc, not just the simplistic common use of a common syntax) will be best achieved by continued user pressure, both on MS and the ODF side, within a forum where neither side can stymie the legitimate needs of other.
  •  
    MS-OOXML supporter Rick Jellife discusses the ODF Alliance response to Ecma's proposed disposition of ISO NB comments on OOXML. The Allaince response has recieved quite a bit of ink, wtih waves of ODF jihadists pointing to it as incontroverible evidence that they are right. Rick provides a lengthy response, most of which presents the ODF jihadis with some difficult issues they must now explain. More importantly though, RJ uncovers one of the more glaring examples proving that ODF is application specific to the core, and bound to OpenOffice. He points out that OpenOffice ODF could have chosen the W3C's highly portable and infinitely interoeprable CSS as the ODF presentation layer. This would have been a great reuse of existing standards. But that's not what happened! Instead of the widely used CSS, OpenOffice chose an incredibly application specific presentation model with the unique innovation of "automatic-styles". And with this choice came years of problematic zero interop as application after application try to exchange ODF documents with little success. Take for example KDE-KOffice. They've been a member of the OASIS ODF TC for near five years now, almost since the beginning. Yet it's impossible to exchange all but the most basic of documents with any of the OpenOffice derivaties (OpenOffice, StarOffice, Novell Office, and Lotus Symphony - OOo 1.1.4). If after five years of active particpation and cooperative efforts, KOffice is unable to exchange ODF docuemnts with OpenOffice, how is it that somehow Microsoft Office would be able to implement ODF without similar zero interop results? Isn't the purpose of standardized formats that end users of different applications could effectively exchange documents? The truth is that both ODF and OOXML are application specific formats. And you can't harmonize, merge, map, or translate between two application specific formats without also having harmonized the appli
Gary Edwards

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

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

Independent study advises IT planners to go OOXML | All about Microsoft | ZDNet.com - 0 views

  • “ODF represents laudable design and standards work. It’s a clean and useful design, but it’s appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn’t a requirement. Overall, ODF addresses only a subset of what most organizations do with productivity applications today.” The report continues: “ODF is insufficient for complex real-world enterprise requirements, and it is indirectly controlled by Sun Microsystems, despite also being an ISO standard. It’s possible that IBM, Novell, and other vendors may be able to put ODF on a more customer-oriented trajectory in the future and more completely integrate it with the W3C content model, but for now ODF should be seen as more of an anti-Microsoft political statement than an objective technology selection.”
    • Gary Edwards
       
      Mary Jo takes on the recently released Burton Group Report comparing OOXML and ODF. Peter O'Kelly, one of the Burton Group authors, once famously said, "ODF is a great format if you live in an alternative universe where MSOffice doesn't exist!" This observation speaks to the core problem facing ODF and those who seek to implement the ODF standard: ODF was not designed for the conversion of MSOffice documents. Nor was ODF designed to work with MSOffice applications. Another way of saying this is to state that ODF was not designed to be interoperable with MSOffice documents, applications and bound processes. The truth is that ODF was designed for OpenOffice/StarOffice. It is an application specific format. Both OOXML and ODF do a good job of separating content from presentation (style). The problem is that the presentation - layout layers of both ODF and OOXML remains bound to specific applications producing it. While the content layers are entirely portable and can be exchanged without information loss, the presentation layers can not. Microsoft makes no bones about the application specific design and purpose of OOXML. It's stated right in the Ecma 376 charter that OOXML was designed to be compatible with MSOffice and the billions of binary documents in MSOffice specific binary formats. The situation however is much more confusing with ODF. ODF is often promoted as being application, platform and vendor independent. After five years of development though, the OASIS ODF TC has been unable to strip ODF of it's OpenOffice/StarOffice specific aspects. ODF 1.0 - ISO 26300 had three areas that were under specified; meaning these areas were described in syntax only, and lacked the full semantics demanded by interoperable implementations. Only OpenOffice and StarOffice code base applications are able to exchange documents with an acceptable fidelity. The three under specified areas of ODF are: Lists (numbered), F
Gary Edwards

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

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

  •  
    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

The Case for Harmonization (that IBM will vote against anyway) « A Frantic Op... - 0 views

  • The Case for Harmonization (that IBM will vote against&nbsp;anyway) In my recent post, I discussed the case for harmonization, mainly due to trying to portray a more kindly, conciliatory face in the “standards krieg” that I was enjoying so much. I have been forced to take a different tack, in light of being hung out to dry by my more business-focused IBM comrades and the work that the enemy has done in sprucing up the spec. However, as my closest friends know, for me, there are no half-victories, so you can rest assured that I will not settle for this weak “harmonization” compromise. I set out my (and IBM’s) stall some time ago on this, and as those on the Open Document Foundation know, any attempt at harmonization shall be met with swift and final retribution.&nbsp; They were ejected from the odf-coven just days after their impudence. I have baited my trap, inviting this “harmonization” in my lair (the OASIS ODF TC) where I can bog them down in a morass of incompetence, bickering and politicking, so no new standard is ever ratified.&nbsp; I have already been practicing for this, as you can see, by the ODF 1.1 and 1.2 specs.
  •  
    This very funny satire builds on some harsh realities. The ODF chickens have come home to roost, and it isn't pretty. Very funny, yes. But not pretty for those who continue to believe that somehow ODF is a standard worthy of their support. The flip side of the coin is that using the same critieria of interoperability, OOXML is worthless. The sad truth is that both ODF and OOXML are applicaiton specific formats that will continue to defy and defeat all efforts at interoperability. Inparticular, it's the presentation layers of ODF and OOXML that remain bound to the layout engines and feature sets of their originating applications. Just as the presentation layers defy interoperability, they will also defeat harmonization. The only way to harmonize two application specific formats is to harmonize the originating applications. And Microsoft, Sun and IBM are not about to do that. The links in this satire are stunning!!! They shout loudly as to how Microsoft is going to respond to the ECIS anti trust allegations. So when you stop laughing, make certain you track down the links and read through the various OASIS ODF archive threads. IBM and Sun had their chance to fix ODF interoperability. Now it may be too late.
Gary Edwards

ConsortiumInfo.org - Standards to the People! (Updated Twice) - 0 views

  • I call on Ecma to withdraw OOXML from ISO and keep control of it themselves. We need it for legacy documents.
  •  
    Strange demands from Andy Updegrove: "I call on Ecma to withdraw OOXML from ISO and keep control of it themselves. We need it for legacy documents...." Why would anyone want Ecma to take back control of MSOffice-OOXML from ISO? The best circumstance would be for OASIS to turn OpenOffice-ODF over to the same ISO JTC-S1, where they can finally begin the difficult (if not impossible) harmonization process. Let me add on other thing; the place for ISO to begin harmonization is "presentation". We desperately need a standardized presentation model useful to MSOffice-OOXML, OpenOffice-ODF, XHTML and HTML. I suggest they start with CSS 3, and work back into ODF - OOXML. But that's just me :)
Gary Edwards

Jim King's PDF-XML presentations | Adobe - 0 views

  • Presentations made by Jim King of Adobe Systems
Gary Edwards

Is HTML in a Race to the Bottom? A Large-Scale Survey of Open Web Formats - 0 views

  • The "race to the bottom" is a familiar phenomenon that occurs when multiple standards compete for acceptance. In this environment, the most lenient standard usually attracts the greatest support (acceptance, usage, and so on), leading to a competition among standards to be less stringent. This also tends to drive competing standards toward the minimum possible level of quality. One key prerequisite for a race to the bottom is an unregulated market because regulators mandate a minimum acceptable quality for standards and sanction those who don't comply.1,2 In examining current HTML standards, we've come to suspect that a race to the bottom could, in fact, be occurring because so many competing versions of HTML exist. At this time, some nine different versions of HTML (including its successor, XHTML) are supported as W3C standards, with the most up-to-date being XHTML 1.1. Although some versions are very old and lack some of the newer versions' capabilities, others are reasonably contemporaneous. In particular, HTML 4.01 and XHTML 1.0 both have "transitional" and "strict" versions. Clearly, the W3C's intent is to provide a pathway to move from HTML 4.01 to XHTML 1.1, and the transitional versions are steps on that path. It also aims to develop XHTML standards that support device independence (everything from desktops to cell phones), accessibility, and internationalization. As part of this effort, HTML 4.01's presentational elements (used to adjust the appearance of a page for older browsers that don't support style sheets) are eliminated in XHTML 1.1. Our concern is that Web site designers might decline to follow the newer versions' more stringent formatting requirements and will instead keep using transitional versions. To determine if this is likely, we surveyed the top 100,000 most popular Web sites to discover what versions of HTML are in widespread use.
    • Gary Edwards
       
      The summary statement glosses over the value of a highly structured portable XML document. A value that goes far beyond the strict separation of content and presentation. The portable document model is the essential means by which information is exchanged over the Web. It is the key to Web interop. Up till now, Web docuemnts have been very limited. With the advent of XHTML-2, CSS-3, SVG, XForms and CDF (Compound Document Framework for putting these pieces together), the W3C has provisioned the Web with the means of publishing and exchanging highly interactive but very complex docuemnts. The Web documents of the future will be every bit as complex as the publishing industry needs. The transition of complex and data rich desktop office suite documents to the Web has been non existent up till now. With ISO approval of MSOffice-OOXML, Microsoft is now ready to transition billions of business process rich "office" documents to the Web. This transition is accomplished by a very clever conversion component included in the MSOffice SDK. MS Developers can easily convert OOXML documents to Web ready XAML documents, adn back again, without loss of presentation fidelity, or data. No matter what the complexity! The problem here is that while MSOffice-OOXML is now an ISO/IEC International Standard, XAML "fixed/flow" is a proprietary format useful only to the IE-8 browser, the MS Web Stack (Exchange, SharePoint, MS SQL, and Windows Server), and the emerging MS Cloud. Apache, J2EE, Mozilla Firefox, Adobe and Open Source Servers in general will not be able to render these complex, business process rich, office suite documents. MSOffice-OOXML itself is far to complicated and filled with MS application-platform-vendor specific dependencies to be usefully converted to Open Web XHTML-CSS, ePUB or CDF. XAML itself is only the tip of the iceberg. The Microsoft Web Stack also implements Silverlight, Smart Tags and other WPF - .NET
  •  
    What makes the Internet so extraordinary is the interoperability of web ready data, content, media and the incredible sprawl of web applications servicing the volumes of information. The network of networks has become the information system connecting and converging all information systems. The Web is the universal platform of access, exchange and now, collaborative computing. This survey exammines the key issue of future interoperability; Web Document Formats.
Gary Edwards

XML-Empowered Documents Extend SOA's Connection to People and Processes | BriefingsDire... - 0 views

  • 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
       
      "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
       
      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
       
      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
       
      OK. Nice summary!
    • Gary Edwards
       
      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
       
      Great idea Mr. Sorofman, but Microsoft owns the "editor" in this equation.
    • Gary Edwards
       
      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
       
      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
       
      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!!!!!
  •  
    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

Once More unto the Breach: The Best Presentation on Software Business and Open Source I... - 0 views

  •  
    hey, this really is the best presentation ever.  No audio recording, bu the slides are more than enough to put this presentation over the top.  Key issues are RedHat vs Oracle, and the value of "software" as Wall street sees things.  Extremly inofmraitve and well worht the trek through over 50 slides. 
Paul Merrell

Matusow's Blog : Open XML, ODF, PDF, and XPS in Office - 0 views

    • Paul Merrell
       
      Whoopee! Everyone gets to add vendor-specific extensions to standards like ODF to enable some quality of Sharepoint/Exchange/Outlook interop in their apps, just as soon as Microsoft gets around to offering adequate specfications. History teaches that may be a very long time, and of course the relevant Microsoft patent RAND terms apply, because the disclosures are made outside the context of a standard that requires otherwise. And of course the OASIS RF on RAND policy does not forbid new ODF features subject to RAND terms and the policy is silent on the subject of vendor-specific extensions. Methinks FOSS may have just lost its "open standard" ODF.
  • Office is NOT implementing ODF 1.0 from ISO. That spec is not representative of the marketplace today, it is not what is implemented in OpenOffice, it is not what IBM is using for Symphony, and it is not referenced in the Massachusetts ETRM policy.
    • Paul Merrell
       
      As I have been arguing, there are no full featured implementations in existence of the ISO/IEC:26300 OpenDocument standard and every government that has adopted the international standard as its own internal standard or procurement specification is subject to legal challenge because of the lack of implementations.
  • In my opinion, the continued interest in innovation presented by those solutions will speak much louder than the formats themselves.
    • Paul Merrell
       
      You can have standards and you can have innovation. But you can't have interop if you embrace and extend standards. The need for stable, fully-specified formats for document interchange purposes apparently is not part of Microsoft's plan. Scant wonder, neither ODF nor OOXML is designed for document interchange among competing vendors' apps. They are both standards designed to allow a single vendor to maintain dominant market share among implementors of those standards. Microsoft will soon diominate market share in both so-called "standards." The embrace of a standard is necessary to extend and extinguish it.
  • ...3 more annotations...
  • While this is a big deal announcement for the Office product team (check out Doug Mahugh's blog), my take on it is predictably focused on the longer-term interoperability factors.
  • the API that will allow ANY document format to register itself with Office and be set as the default will be made available as planned. Additionally, the work with DAISY and other specialized document formats will move forward as well.
    • Paul Merrell
       
      I was wrong. The API is for more than ODF plugo-ins.
  • The documentation of client/server protocols for Office-related technologies (such as SharePoint and Exchange/Outlook communications) will remain available to the public.
  •  
    "Clearly the Press Announcement today from Microsoft will bring about another wave of discourse on the future of document formats. " Jason Matusow presents the long-term view of the announcement's significance.
Paul Merrell

Detail Results ISO/IEC FDIS 24754 - 0 views

  • ISO International Organization for Standardization Document #: ISO/IEC FDIS 24754&nbsp; Title: Information technology -- Document description and processing languages -- Minimum requirements for specifying document rendering systems&nbsp; Scope: &nbsp; Keywords: IT applications in information, documentation and publishing&nbsp; Committee: ISO IEC JTC 1 SC 34 - Document description and processing languages&nbsp; SDO Approval Date: &nbsp; ANSI Approval Date: &nbsp; Date File Updated in Database May 13 2008 4:50PM&nbsp;
  •  
    "FDIS" stands for "final draft international standard," which puts this standard at the final voting stage. I suspect that this document will be frequently cited in the efforts to harmonize ODF and OOXML at the presentation layer. Unfortunately, it looks like you have to be a member of a national standardization body to come up with a copy.
Bernard (ben) Tremblay

Open Document | Online Community for the OpenDocument OASIS Standard - 0 views

  •  
    This is the official community gathering place and information resource for the OpenDocument Format (ODF) OASIS Standard (ISO/IEC 26300). Suitable for text, spreadsheets, charts, graphs, presentations, and databases, ODF frees documents from their applications-of-origin, enabling them to be exchanged, retrieved, and edited with any OpenDocument-compliant software or tool. This is a community-driven site, and the public is encouraged to contribute content.
Gary Edwards

(WO/1995/013585) COMPOUND DOCUMENT FRAMEWORK - 0 views

  • Summary of the Invention It is an. object of the present invention to provide a document processing system in which object-oriented frameworks are utilized to implement particular document processing techniques, including an object-oriented compound document system. These and other objects of the present invention are realized by a document framework which supports at the system level a variety of compound document processing functions. The framework provides system level support of collaboration, linking, eternal undo, and content based retrieval. These and other objects are carried out by system level support of document changes, annotation through model and linking, anchors, model hierarchies, enhanced copy and pasting, command objects, and a generic retrieval framework.
Gary Edwards

MIcrosot's latest kiss of death: ODF - 0 views

  •  
    Embrace. Extend. Extinguish. That's how Microsoft (Nasdaq: MSFT) killed Netscape many moons ago. Embrace this newfangled "Web browser" market with a new product. Extend the existing Web standards with proprietary technologies like ActiveX. Extinguish the competition by denying them access to those fancy new features. When it works, this is a great way to build and maintain wide, alligator-filled business moats. It seems to me that Mr. Softy is up to his old tricks again. The target this time is the OpenDocument standard, a free and open alternative to Microsoft's own Office formats for text documents, spreadsheets, presentations, and more.
Gary Edwards

There is no end, but addition: Alex Brown's weblog - 20 May: a day of anniversaries - 0 views

  • Unlike ODF and OOXML, however, I am beginning to believe the Directives have got to a state where they cannot be redeemed by evolution and amendment. It may be time to start again from scratch.
  •  
    Alex identifies the difficulties between ISO member nations and the officials at the ISO JTCS-34 responsible for MSOffice-OOXML and OpenOffice-ODF. The member nations really want MSOffice XML formats locked down at ISO. But they are short on both ideas and the authorization needed to make this work. Alex concludes that maybe it's time to start all over; from scratch. The Foundation developers working on the da Vinci plug-in for MSOffice concluded that it was far easier to target existing (X)HTML-CSS using the ePUB wrapper to get that higher level of interop everyone seeks. Waiting for ISO to sort things out is not a solution. But iunderstand Alex's position. Harmonizing ODF and OOXML is probably not possible. Leastways not without some major compromises at the applicaiton level by both OpenOffice and MSOffice. It would be far easier to demand that both OpenOffice and MSOffice support and implement the ePUB (X)HTML-CSS web ready format. The simple truth is that both OpenOffice-ODF and MSOffice-OOXML are application specfic XML formats suffering the same darkness: there is no standardization or sufficient documentation of the "presentation" - layout model. It is here that the highly portable CSS model is lightyears ahead of both.
Gary Edwards

EU's Kroes says further technology antitrust abuse cases pending UPDATE - Forbes.com - 0 views

  • The commission said that as part of its antitrust investigation into interoperability with Microsoft Office it will investigate whether the announced support of ODF in Office leads to better interoperability and allows consumers to process and exchange their documents with the software product of their choice. Kroes said on Tuesday that the commission keeps a close eye on interoperability and said the market should have the right balance of non-propriety and propriety standards. 'Standards are the foundation of interoperability'. 'Standards may, of course, be proprietary or non-proprietary. Much excellent technical development has been driven by non-proprietary standards - the internet is awash with acronyms for non-proprietary standards: HTTP, HTML and XML'.
  •  
    I wonder if the EU is aware that there is no such thing as ODF Interoperability? After more than five years of working side by side with Sun on the OASIS ODF TC, there is zero interop between KOffice ODF and OpenOffice ODF! How is it that Microsoft's joining the ODF TC somehow results in a level of application interop that has eluded and defied the efforts of two supposedly open source applications? The truth is that OpenOffice-ODF and MSOffice-OOXMl are both based on an XML encoding of the application specific binary dump. The content layers are easily exchanged with other applications, but presentation continues to defy any kind of interop. Especially what the EU expects. Check out the quotes: " The commission said that as part of its antitrust investigation into interoperability with Microsoft Office it will investigate whether the announced support of ODF in Office leads to better interoperability and allows consumers to process and exchange their documents with the software product of their choice. "Kroes said on Tuesday that the commission keeps a close eye on interoperability and said the market should have the right balance of non-propriety and propriety standards. 'Standards are the foundation of interoperability'. 'Standards may, of course, be proprietary or non-proprietary. Much excellent technical development has been driven by non-proprietary standards - the internet is awash with acronyms for non-proprietary standards: HTTP, HTML and XML'.
Jesper Lund Stocholm

Adobe - Release PDF for Industry Standardization FAQ - 0 views

  • ODF and OOXML are input formats designed for authoring documents. Those formats favor editing over preserving an exact final presentation. PDF is primarily used as an output document, designed for distribution and markup, and it favors exact final presentation over editing. PDF thus enables either of these authoring formats to be used to deliver a consistent and complete distribution of a document, keeping the exact appearance intended by the authors.
    • Jesper Lund Stocholm
       
      Adobe's own explanation of differences between PDF and "editable document formats"
1 - 20 of 61 Next › Last »
Showing 20 items per page