Skip to main content

Home/ OpenDocument/ Group items tagged semantics

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

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

www.xml.com/...perry.html

odf ooxml presentation semantics xml

shared by Gary Edwards on 21 Jan 08 - Cached
  • 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 <PricePerCruller>, right beside beside <PricePerDonutHole> in my menu? -- new users realized the problem: a browser knows how to display a heading marked as <h1> bigger and more prominently than a lowlier <h3>. Yet there are no standard display expectations or semantics for the XML tags which users themselves create. That there is no specific display for <Cruller> and, especially, not as distinct from <DonutHole> 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
      Gary Edwards on 21 Jan 08
       
      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
      Gary Edwards on 21 Jan 08
       
      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
      Gary Edwards on 21 Jan 08
       
      "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
      Gary Edwards on 21 Jan 08
       
      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
      Gary Edwards on 21 Jan 08
       
      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

Microsoft, Google Search and the Future of the Open Web - Google Docs - 0 views

docs.google.com/Edit

webkit microsoft google search Cloud-Computing monopoly

shared by Gary Edwards on 03 Feb 09 - Cached
  • Gary Edwards on 03 Feb 09
     
    The InformationWeek series of articles outlining the challenges Microsoft faces does not cover the recent anti-trust actions by the EU - DG Competition group. Even so, the series does paint a pretty gloomy scenario. Especially if you're a Microsoft shareholder. No doubt the IW guys are shorting Microsoft. All in all, this series is an accurate assessment except for one thing; they don't credit the strength of Microsoft's monopoly position and their ability to leverage the desktop monopoly into a full fledged "business" Web monopoly. MOSS (Microsoft Office - SharePoint Server) system is kicking ass, and the world is worried that browsers like Opera are not getting a fair shake on the desktop. Microsoft is a platform player, and you can't fight that at the application level. Connecting the desktop platform to backend relational and transaction servers defines the 1995 monopoly. Connecting the desktop platform to the Web platform will define the next big monopoly play. The EU has got to get off the application layer and out of the open standards vendor consortia if they are to stop this juggernaut. The reason they need to get out of the standards consortia and write/demand their own "advanced recommendations" - like WebKit, is the cleverness of Microsoft's "duality" approach. The target has to be that of restoring competition at the high end of collaborative Web computing, where Microsoft's proprietary WPF-.NET technologies rule. Any format, protocol, or interface used to connect platforms, applications or services must be open and available to all - including the reverse engineering rights. So far the EU has left me less than hopeful. I do however believe that WebKit can get the job done. It would be nice if the EU could at the least slow the beast of Redmond down. ~ge~
  • Gary Edwards on 03 Feb 09
     
    Response to the InformationWeek article "Remaking Microsoft: Get Out of Web Search!". Covers "The Myth of Google Enterprise Search", and the refusal of Google to implement or recognize W3C Semantic Web technologies. This refusal protects Google's proprietary search and categorization algorithms, but it opens the door wide for Microsoft Office editors to totally exploit the end-user semantic interface opportunities. If Microsoft can pull this off, they will take "search" to the Enterprise and beyond into every high end discipline using MSOffice to edit Web ready documents (private and public use). Also a bit about WebKit as the most disruptive technology Microsoft has faced since the advent of the Web.
Gary Edwards

» Web inventor Tim Berners-Lee Unplugged: Semantic Web better than APIs for d... - 0 views

blogs.zdnet.com/Berlind

shared by Gary Edwards on 09 Jun 07 - Cached
  • the general idea is for there to be a layer of data on the Internet that he calls the “data bus” and the way the data bus works is not too different from how we’ve heard Microsoft’s WinFS filesystem described where connectivity between related data items is organic rather than synthesized. For example, whereas today, a mashup developer may have to call upon two APIs to show where a specific Starbucks is on a map, the Semantic Web approach might involve little more than a simple query of that data bus using a query technology called SparQL.
  • Gary Edwards on 09 Jun 07
     
    Great explanation of the Semantic Web, RDF, SparQL versus big vendor Web API's
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

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

Independent study advises IT planners to go OOXML - 0 views

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

anti-trust browser-wars gates msoffice netscape ooxml w3c

shared by Gary Edwards on 20 Jan 08 - Cached
  • From: Bill Gates Sent: Saturday, December 5 1998 To: Bob Muglia, Jon DeVann, Steven Sinofsky Subject : Office rendering "One thing we have got to change in our strategy - allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows. I would be glad to explain at a greater length. Likewise this love of DAV in Office/Exchange is a huge problem. I would also like to make sure people understand this as well." Tuesday, August 28, 2007
  • 3.2.2.2. A pox on both your houses! gary.edwards - 01/22/08 Hi Robert, What you've posted are examples of MSOffice ”compatibility settings” used to establish backwards compatibility with older documents, and, for the conversion of alien file formats (such as various versions of WordPerfect .wpd). These compatibility settings are unspecified in that we know the syntax but have no idea of the semantics. And without the semantic description there is no way other developers can understand implementation. This of course guarantees an unacceptable breakdown of interoperability. But i would be hesitant to make my stand of rejecting OOXML based on this issue. It turns out that there are upwards of 150 unspecified compatibility settings used by OpenOffice/StarOffice. These settings are not specified in ODF, but will nevertheless show up in OpenOffice ODF documents – similarly defying interoperability efforts! Since the compatibility settings are not specified or even mentioned in the ODF 1.0 – ISO 26300 specification, we have to go to the OOo source code to discover where this stuff comes from. Check out lines 169-211. Here you will find interesting settings such as, “UseFormerLineSpacing, UseFormerObjectPositioning, and UseFormerTextWrapping”. So what's going on here?
Gary Edwards

Independent study advises IT planners to go OOXML | A pos on both your houses! - 0 views

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

application-specific cdf ge odf ooxml pox

shared by Gary Edwards on 25 Jan 08 - Cached
  • What you've posted are examples of MSOffice ”compatibility settings” used to establish backwards compatibility with older documents, and, for the conversion of alien file formats (such as various versions of WordPerfect .wpd). These compatibility settings are unspecified in that we know the syntax but have no idea of the semantics. And without the semantic description there is no way other developers can understand implementation. This of course guarantees an unacceptable breakdown of interoperability. But i would be hesitant to make my stand of rejecting OOXML based on this issue. It turns out that there are upwards of 150 unspecified compatibility settings used by OpenOffice/StarOffice. These settings are not specified in ODF, but will nevertheless show up in OpenOffice ODF documents – similarly defying interoperability efforts! Since the compatibility settings are not specified or even mentioned in the ODF 1.0 – ISO 26300 specification, we have to go to the OOo source code to discover where this stuff comes from. Check out lines 169-211. Here you will find interesting settings such as, “UseFormerLineSpacing, UseFormerObjectPositioning, and UseFormerTextWrapping”.
Gary Edwards

ODF Editor Says ODF Loses If OOXML Does | Slashdot - 0 views

tech.slashdot.org/comments.pl

durusau iso odf ooxml

shared by Gary Edwards on 27 Mar 08 - Cached
  • IMHO, the change in Patrick's position is entirely due to the realization that it is impossible to map between OOXML and ODF. I don't know this for sure, but when i read the German Standards Group (DIN) report on harmonization, authorized by the EU-IDABC and provided to ISO, i couldn't help but wonder how Patrick would react. The report definitively ends his OOXML ODF mapping dream.Many wonder why mapping is impossible. I had more than a few discussions with Patrick on this. His point was that a schema is a schema. As long as the syntax and semantics are fully documented, no problemo. My point is that both ODF and OOXML are application specific; and, both are woefully lacking in "semantic" documentation. Add to this problem that both ODF and OOXML lack an interoperability framework with any semblance of compliance teeth, and the whole mapping issue becomes an impossible solution. Especially if interop is the goal.
  • Gary Edwards on 27 Mar 08
     
    ge comments about Patrick Durusau and his surprising change of position in support of ISO approval of OOXML
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

Harmonizing ODF and OOXML using NameSpaces | Tim Bray's Thought Experiment - 0 views

www.tbray.org/...Office-XML

bray florian-reuter namespaces odf ooxml opendocument openxml

shared by Gary Edwards on 09 Feb 08 - Cached
  • First, what if Microsoft really is doing the right thing? Second, how can we avoid having two incompatible file formats? [Update: There’s been a lot of reaction to this piece, and I addressed some of those points here.]
  • On the technology side, the two formats are really more alike than they are different. But, there are differences: O12X’s design center, Microsoft has said repeatedly, is capturing the exact semantics of the billions of existing Microsoft Office documents. ODF’s design center is general-purpose reusability, and leveraging existing standards like SVG and MathML and so on.
  • The capabilities of ODF and O12X are essentially identical for all this basic stuff. So why in the flaming hell does the world need two incompatible formats to express it? The answer, obviously, is, “it doesn’t”.
  • ...1 more annotation...
  • The ideal outcome would be a common shared office-XML dialect for the basics—and it should be ODF (or a subset), since that’s been designed and debugged—then another extended vocabulary to support Microsoft features , whether they’re cool new whizzy features or mouldy old legacy features (XML Namespaces are designed to support exactly this kind of thing). That way, if you stayed with the basic stuff you’d never need to worry about software lock-in; the difference between portable and proprietary would be crystal-clear. And, for the basic stuff that everybody uses, there’d be only one set of tags. This outcome is technically feasible. Who could possibly be against it?
  • Gary Edwards on 09 Feb 08
     
    Tim Bray suggests using namespaces to brdige the comatibility gap between ODF and OOXML.
  • Gary Edwards on 09 Feb 08
     
    This log is connected to a recent post from Florian Reuter, XML Namespaces are designed to support exactly this kind of thing ...
Gary Edwards

The Harmonization Myth: ISO Approval of Open XML Will Hurt Interoperability - 0 views

blog.hvorom.dk/...ill-Hurt-Interoperability.aspx

din fraunhofer harmonization iso odf ooxml opendocument openxml

shared by Gary Edwards on 31 Jan 08 - Cached
  • This myth is rather silly if you think about it. Here is why… When people talk about interoperability and Open XML they do so primarily in the context of ODF. The story goes something like this: 1. Open XML is not interoperable with ODF 2. Open XML should be interoperable with ODF because ODF is already an ISO standard! 3. Hence: Open XML is no good, because it is not interoperable with ODF and therefore Open XML should not be an ISO standard!!!
    • Gary Edwards
      Gary Edwards on 31 Jan 08
       
      Forget ISO approval of OOXML. I would rather see ISO enforce the current directive that ODF be brought into compliance with existing ISO Interoperability requirements. Then and only then should ISO then consider OOXML.
      The reason for this approach? If ODF wiere compliant with existing ISO Interop Requirements, there would probably be some hope of harmonizing ODF and OOXML. Until ODF is stripped of it's application specific settings, and fully documented, we can hardly beging the process of figuring out harmonization.
      ODF 1.0 has four gapping holes that must be tended to before ISO proceeds any furhter with either ODF or OOXML. The holes are that ODF numbered lists, formulas and the presentation layer (styles) are woefully underspecified. The fourth problem is that ODF is seriously lacking an interoperability framework.
      These ODF problems can of course be traced back to the fact that ODF is application specific and bound to the "semantics and capabilities" of OpenOffice. That creates all kinds of problems. OOXML on the other hand is even worse. OOXML is application, platform and vendor specific!!!! If ODF were brought up to snuff, we could reasonably start work on harmonization. Thereby eliminating the need to standardize two file formats for the same purposes. Until ODF is fixed, what's the world to do?
      ~ge~
Gary Edwards

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

blogs.zdnet.com/microsoft

burtongorup cdf css garyedwards maryjo odf okelly ooxml w3c xhtml

shared by Gary Edwards on 20 Jan 08 - Cached
  • “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
      Gary Edwards on 20 Jan 08
       
      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

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

Thinking XML: Schema annotation for bottom-up semantic transparency - 0 views

www-128.ibm.com/...x-think32.html

data dictionaries imported:del.icio.us odf schematron wordnet

shared by Gary Edwards on 06 Mar 07 - Cached
  • Gary Edwards on 06 Mar 07
     
    Schematron, Data Dictionaries, Schema Abstracts:::: Oche makes the case for WordNet style unique definitions that might be very useful to verticle industry schemas - defined "shared" business processes. also pertains to verticle implementation of ODF. P
  • Gary Edwards on 06 Mar 07
     
    Schematron, Data Dictionaries, Schema Abstracts:::: Oche makes the case for WordNet style unique definitions that might be very useful to verticle industry schemas - defined "shared" business processes. also pertains to verticle implementation of ODF. P
  • Gary Edwards on 06 Mar 07
     
    Schematron, Data Dictionaries, Schema Abstracts:::: Oche makes the case for WordNet style unique definitions that might be very useful to verticle industry schemas - defined "shared" business processes. also pertains to verticle implementation of ODF. P
Paul Merrell

untitled - 0 views

www.dpawson.co.uk/...090612.html

ODF specificity quality testability

shared by Paul Merrell on 18 Jun 09 - Cached
  • Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work
  • Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work That is the way quality specifications are written. For example, ISO/IEC's JTC 1 Directives (link to PDF) requires that international standards designed for interoperability "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." With that clarity, conformance is testable and can provide confidence of interoperability. A suite of tests may be developed and applied to an implementation to determine which tests pass, which fail, and hence arrive at an objective pronouncement on conformance of an implementation against the entirety of the specification.
  • In a quality specification, it should be feasible to select a normative paragraph, identify a conformance test for it, and make a clear statement that this test proves that an implementation meets (or fails to meet) that requirement. Call it a test plan: define the tests (test specification), define the expected set of results, and define what constitutes a "pass" of each test that establishes conformance. The plan then provides the matrix of test spec against requirement. Simple.
  • ...4 more annotations...
  • Rob Weir of IBM chaired (apology for the misuse of that last word) the formation list and then simply announced what the charter would be rather than seeking consensus among the list participants. As part of this process before that charter was produced and while I still naively believed that consensus was a goal, I sat down with ODF 1.1 and did a paragraph-by-paragraph review for testability. The numbers were quite revealing. I completely reviewed only the first four major sections and found very few clear requirements. The majority were mere statements with no normative language used to identify what was required or optional. Implementors would have to make their own interpretation.
  • It's ironic that the chair viewed as good news the fact that there were far fewer testable paragraphs than he had predicted. But his prediction of 10,000 test cases is probably far closer to how many testable paragraphs there should be; my counts were actually bad news.
  • All of the above leads to the interesting question of just how the chair expects to accomplish much that is useful in regard to ODF conformance testing before the specification is amended to tighten up the language and add clear requirements. The syntax conformity is already handled by validation against the schema, but the semantics are woefully under-specified.
  • Summary: ODF 1.1 isn't verifiable as a specification. From a fairly cursory review of the latest draft, ODF 1.2 will follow the same path. With OASIS now being more demanding regarding conformance requirements on every specification and with ISO/IEC taking a closer interest in liaison with the ODF TC, I find it hard to see how the ODF TC co-chairs can maintain this view toward verification.
1 - 16 of 16
Showing 20▼ items per page