Skip to main content

Home/ Document Wars/ Group items tagged XML

Rss Feed Group items tagged

Paul Merrell

Federal future cloudy for Microsoft Word -- Government Computer News - 0 views

  • “We have explained [to federal agencies] ways of moving from Microsoft Word to an i4i implementation of custom XML,” said Michael Vuple, i4i’s founder. “If agencies want custom XML, we are prepared, and we are working on a way for them to use our technology.” The company hasn’t been actively marketing that approach to government so far because it didn’t want to take advantage of the current “unfortunate situation,” he said. But with agencies likely to be asking the question, he said i4i will probably have to take a more proactive stance in the future.
Alex Brown

Doug Mahugh : Tracked Changes - 0 views

  • Much was made during the IS29500 standards process of the difference in the size of the ODF and Open XML specifications.  This is a good example of where that difference comes from: in this case, a concept glossed over in three vague sentences of the ODF spec gets 17 pages of documentation in the Open XML spec.
    • Alex Brown
       
      This is the nub; OOXML may be overweight, but ODF is severely undernourished as a spec.
  •  
    Alex, I know from your previous writings that you do not regard OOXML as completely specified. But your post might be so misinterpreted. In my view, neither ODF nor OOXML has yet reached the threshold of eligibility as an international standard, completely specifying "clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." ISO/IEC JTC 1 Directives, Annex I. . OOXML is ahead of ODF in some aspects of specificity, but the eligibility finish line remains beyond the horizon for both.
  • ...2 more comments...
  •  
    Paul, that's right - though so far the faulty things in OOXML turn out to be more round the edges as opposed to ODF's central lapses. Still, it's early days in the examination of OOXML so I'm reserving making any firm call on the comparative merits of the specs until I have read a lot (a lot) more. Is there an area of OOXML you'd say was particularly underbaked? I'm quite interested in the fact that neither of these beasts specify scripting languages ...
  •  
    Hi, Alex, Most seriously, there are no profiles and accompanying requirements to enable less featureful apps to round trip documents with more featureful apps, a la W3C Compound Document by Reference Framework. That's an enormous barrier to market entry and interoperability. That defect reacts synergistically with the dearth of semantic conformity requirements, with the incredible number of options including those 500+ identified extension points, and with a compatibility framework for extensions that while a good start leaves implementers far too much discretion in assigning and processing compatibility attributes. There are also major harmonization issues with other standards that get in the way of transformations, where Microsoft originally rolled its own rather than embracing existing open standards. I think it not insignificant that OOXML as a whole is available only under a RAND-Z pledge rather than being available for the entire world. The patent claims need to be identified and worked around or a different rights scheme needs Microsoft management's promulgation. This is a legal interoperability issue as opposed to technical, but an interoperability barrier nonetheless, an "unnecessary obstacle to international trade" in the sense of the Agreement on Technical Barriers to Trade. And absent a change by Microsoft in its rights regime, the work-arounds are technical. This is not to suggest that ODF lacks problems in regard to the way it implements standards incorporated by reference. The creation of unique OASIS namespaces rather than doing the needed harmonizing work with the relevant W3C WGs is a large ODF tumor in need of removal and reconstructive surgery. I'm not sure what is happening with the W3C consultation in that regard. I worked a good part of the time over several months comparing ODF and Ecma 376, evaluating their comparative suitability as document exchange formats. I gave up when it climbed well past 100 pages in length because the de
  •  
    1. Full-featured editors available that are capable of not generating application-specific extensions to the formats? 2. Interoperability of conforming implementations mandatory? 3. Interoperability between different IT systems either demonstrable or demonstrated? 4. Profiles developed and required for interoperability? 5. Methodology specified for interoperability between less and more featureful applications? 6. Specifies conformity requirements essential to achieve interoperability? 7. Interoperability conformity assessment procedures formally established and validated? 8. Document validation procedures validated? 9. Specifies an interoperability framework? 10. Application-specific extensions classified as non-conformant? 11. Preservation of metadata necessary to achieve interoperability mandatory? 12. XML namespaces for incorporated standards properly implemented? (ODF-only failure because Microsoft didn't incorporate any relevant standards.) 13. Optional feature interop breakpoints eliminated? 14. Scripting language fully specified for embedded scripts? 15. Hooks fully specified for use by embedded scripts? 16. Standard is vendor- and application-neutral? 17. Market requirement -- Capable of converging desktop, server, Web, and mobile device editors and viewers? (OOXML better equipped here, but its patent barrier blocks.)
  •  
    Didn't notice that my post before last was chopped at the end until after I had posted the list. Then Diigo stopped responding for a few minutes. Anyway, the list is short summation of my research on the comparative suitabilities of ODF 1.1 and Ecma 376 as document exchange formats, winnowed to the defects they have in common except as noted. The research was never completed because in the political climate of the time, the world wasn't ready to act on the defects. The criteria applied were as objective as I could make them; they were derived from competition law, JTC 1 Directives, and market requirements. I think the list is as good today in regard to IS 29500 as it was then to Ecma 376, although I have not taken an equally deep dive into 29500. You might find the list useful, albeit there is more than a bit of redundancy in it.
Jesper Lund Stocholm

Microsoft Office 2010 Engineering : Open XML: One Year In - 1 views

  • What is noteworthy about this investment is that we’re working closely with members of JTC 1 SC 34 ( the standards body responsible with Open XML maintenance ) to identify and resolve backward compatibility issues related to this new functionality.
    • Jesper Lund Stocholm
       
      I think it is worth noting, that quite a few of the independant experts of WG4 have argued against usage of ISO-dates in T.
Gary Edwards

LibreOffice 4.3 boosts document compatibility | InfoWorld - 0 views

  •  
    "Version 4.3 of LibreOffice, the free and open source productivity suite developed by the Document Foundation and derived from the OpenOffice.org project, was released today. Aside from the usual array of bug fixes and new features designed to make it more cross-compatible with Microsoft Office, version 4.3 has features that give files from legacy Macintosh productivity software a new lease on life. Take control! 30 essential OS X command-line tips Go beyond the graphical user interface and take full advantage of Mac OS X at the command line READ NOW Most of the improvements around file handling in 4.3 involve better support for various aspects of the Office Open XML (OOXML) format used by Microsoft for its productivity software. LibreOffice users have often complained of opening Word 2010 or Word 2013 documents and finding that the formatting had been mangled or features like annotations hadn't survive being resaved in LibreOffice. Version 4.3 preserves many more of the attributes used in OOXML documents, such as style attributes for text and images. Also new to this edition of LibreOffice is import support for document formats created by a slew of legacy Macintosh applications: BeagleWorks, ClarisWorks, Claris Resolve, GreatWorks, MacWorks, SuperPaint, and Wingz. Likewise, Microsoft Works spreadsheets and databases -- not just word processing documents -- can now also be imported into LibreOffice. Another change, which might not directly affect many users but hints at how the refactoring of LibreOffice's code is reaching many legacy issues, involves the lengths of paragraphs. Previously, paragraphs in a LibreOffice document couldn't exceed 65,000 characters due to a bug in the underlying OpenOffice.org code that had persisted for over a decade and remained unclosed. Other changes include comments that can now be "printed in the document margin, formatted in a better way, and imported and exported," according to the Document Foundation; better behaviors for sp
Gary Edwards

The Age of OOXML Computing - thanks a pant load Sun! - 0 views

  • Why does Microsoft want another standard, what's the rationale? There are at least 4 good reasons why: *ODF started out and was completed as an XML format, specifically supporting OpenOffice with a tight scope around that product. *It wasn't until 2005 that the spec was offered up as a general XML office document format and consequently renamed to ODF. *No opportunity existed for Microsoft to actually participate in this full process - given the original scope, the 6 months between the re-naming of the spec to ODF, and its subsequent approval by OASIS as a standard. *The scope of the ODF spec never included even the basic requirements that Microsoft required to support a fully open format, and nor did the OASIS technical committee want to include these requirements.
  •  
    Erwin's StarOffice Tango has an exhaustive response to this Microsoft Q&A. Correcting false statements by Microsoft
Gary Edwards

Plan B: The NO ViSTA Mandates, and the failure of ISO/IEC - 0 views

  • Plan B: The "NO ViSTA" Mandates:  the failure of Anti Trust Laws and International Trade Agreements to Stop The Great Monopolist, Microsoft A series of surprising government mandate announcements rolled out in the immediate aftermath of the ISO/IEC decision to fast track Ecma 376 otherwise known as Microsoft Office Open XML (MOOX).  The three articles commented on here are all from Information Week, who has done yeoman work concerning the OpenDocument - MOOX controversy that has so upset Microsoft.  Now the mighty monopolist can taste victory, with fast track approval of MOOX certain, and ISO/IEC in the bag.  Incredibly the company that escaped a Court ordered death sentence by purchasing what amounts to a presidential pardon.  They even avoided the stink of their own lobbyist and henchman Jack Abramoff, and his motley crew of Ralph Reed and Grover Nyquist operatives.  Now they are well on their way towards purchasing an International Standard.  So much for Plan A.  Time for Plan B, the "NO ViSTA" mandate.
  •  
    Okay.  I've combined my three comments into a single page.  Sadly Diigo does not offer spell checking.  My apologies to all.  Hoepfully this will be a better read.
Gary Edwards

ODF and OOXML must converge!! AFNOR, the French Standards Body, announces proposals for... - 0 views

  • AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.
  • Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years.   Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.
    • Gary Edwards
       
      Here's the meat of the French convergence proposal.
  •  
    French experts have determined that it is technically possible to converge ODF and MS-OOXML, into a single, revisable document format standard?

    The plan has four parts:

    "Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."

    "Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."

    "Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."

    Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."




    So there you go.  A solution that removes ODF and OOXML from the clam
Gary Edwards

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

  • In many cases, the mashups' data or information sources have incompatible formats so integration becomes a problem.
  •  
    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

The Microsoft Document Juggernaut: ECMA to Begin Drafting XPS as Alternative Standard t... - 0 views

  • "Be that as it may," Updegrove continues, "perpetuating one monopolistic market position after another seems wholly incompatible with the role of a global standards body, tasked with protecting the interests of all stakeholders. If OOXML, and now Microsoft XML Paper Specification, each sail through ECMA and are then adopted by ISO/IEC JTC1, then it may be time to wonder whether the time has come to declare 'game over' for open standards."
  •  
    More on Andy UpDegrove's "Game Over for open standards" comment.
Gary Edwards

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

  • Presentations made by Jim King of Adobe Systems
Gary Edwards

Once More unto the Breach: Office Open XML Conformance (A Lesson in Claiming Standards ... - 0 views

    • Gary Edwards
       
      Presentation fidelity and round tripping? Looks like someone has been attention to what happened in Massachusetts.
  • As far as I can tell in the Massachusetts poster-child case, ODF has simply come to mean whatever OpenOffice.org does
    • Gary Edwards
       
      Keep in mind orchmid that it is the OpenOffice code base that ODF is bound to. There are many instances of the OOo code base pushed by various vendors. Sun provides OpenOffice.org and StarOffice versions of the code base. Novell Open Office is the same code base. Same with Red Hat Office and IBM WorkPlace. Outside this common code base, ODF has near ZERO interoperability.
  •  
    unfortunately the MS argument that support for OOXML equals "conformance" is also the same argument used by OpenDocument supporters to prove multi vendor, multi platform, multi application support.

Gary Edwards

PlexNex: Achieving Openness - 0 views

  • "ECMA 376" is a set of file formats subject to ECMA and now to ISO. "Office 2007" is a set of file formats which extend "ECMA 376" file formats. Office 2007 file formats are undocumented per se. ECMA 376 are. ECMA 376 file formats are documented but only at a syntactic level. To realize the true meaning of every single attribute is to realize that the documentation is more like 600,000 pages, not 6,000. Of particular difficulty is to keep some kind of control over the virtually infinite combinations of such attributes. Quick analysis of the underlying schemas reveals that simple concepts such as text formatting is expressed in no less than 6 different and incompatible ways. This leads to thinking that the file formats were only designed to comply with existing legacy formats that themselves are the result of 15 years of inside/outside library aggregation (some of the libraries were bought from non-Microsoft vendors). In fact, the truth is, ask any reverse engineer third-party who worked with legacy formats, they'll tell you Microsoft essentially added angle brackets around the binary serialization in legacy formats. This makes for a very cool XML-based file format, not an international standard.
  •  
    Whoa, Stepen Rodriguez knocks this one out of the park.  What an impressive dissembling of MS OfficeOpenXML and it's poor sister subset, Ecma 376.  Incredible. 
Gary Edwards

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

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

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

    Over a year later,
Gary Edwards

OpenDocument Format community steadfast despite theatrics of now impotent 'Foundation' ... - 0 views

  • ODF was dead-on-arrival not because it's a better or worse choice than OOXML (I have no idea which is better, really) but because the nature of those with UNIX DNA never allows these kinds of "open" agreements to succeed. They all just splinter. Every time.
  •  
    The sad thing is that in early January of 2003, it was proposed that we start with a clean slate effort based on structural document generics instead of accepting the OpenOffice XML spec, and trying to strip out the application specific settings.  History will record that we accepted the OpenOffice XML spec, and were unable, after five years of effort (2002-2007) to clean things up.

    Perhaps ODF was doomed almost from the start.  The UNiX suggestion is interesting if not an arrow through the core.

Gary Edwards

Linux Foundation Legal : Behind Putting the OpenDocument Foundation to Bed (without its... - 0 views

  • CDF is one of the very many useful projects that W3C has been laboring on, but not one that you would have been likely to have heard much about. Until recently, that is, when Gary Edwards, Sam Hiser and Marbux, the management (and perhaps sole remaining members) of the OpenDocument Foundation decided that CDF was the answer to all of the problems that ODF was designed to address. This announcement gave rise to a flurry of press attention that Sam Hiser has collected here. As others (such as Rob Weir) have already documented, these articles gave the OpenDocument Foundation’s position far more attention than it deserved. The most astonishing piece was written by ZDNet’s Mary Jo Foley. Early on in her article she stated that, “the ODF camp might unravel before Microsoft’s rival Office Open XML (OOXML) comes up for final international standardization vote early next year.” All because Gary, Sam and Marbux have decided that ODF does not meet their needs. Astonishing indeed, given that there is no available evidence to support such a prediction.
  •  
    Uh?  The ODF failure in Massachusetts doesn't count as evidence that ODF was not designed to be compatible with existing MS documents or interoperable with existing MSOffice applications?

    And it's not just the da Vinci plug-in that failed to implement ODF in Massachusetts!  Nine months later Sun delivered their ODF plug-in for MSOffice to Massachusetts.  The next day, Massachusetts threw in the towel, officially recognizing MS-OOXML (and the MS-OOXML Compatibility Pack plug-in) as a standard format for the future.

    Worse, the Massachusetts recognition of MS-OOXML came just weeks before the September 2nd ISO vote on MS-OOXML.  Why not wait a few more weeks?  After all, Massachusetts had conducted a year long pilot study to implement ODF using ODF desktop office sutie alternatives to MSOffice.  Not only did the rip out and replace approach fail, but they were also unable to integrate OpenOffice ODF desktops into existing MSOffice bound workgroups.

    The year long pilot study was followed by another year long effort trying to implement ODF using the plug-in approach.  That too failed with Sun's ODF plug-in the final candidate to prove the difficulty of implementing ODF in situations where MSOffice workgroups dominate.

    California and the EU-IDABC were closely watching the events in Massachusetts, as was most every CIO in government and private enterprise.  Reasoning that if Massachusetts was unable to implement ODF, California CIO's totally refused IBM and Sun's effort to get a pilot study underway.

    Across the pond, in the aftermath of Massachusetts CIO Louis Guiterrez resignation on October 4th, 2006, the EU-IDABC set about developing their own file format, ODEF.  The Open Document Exchange Format splashed into the public discussion on February 28th, 2007 at the "Open Document Exchange Workshop" held in Berlin, Germany.

    Meanwhile, the Sun ODF plug-in is fl
Gary Edwards

ODF Split: Good Riddance, Good Grief, or Game Over? Michael Desmond Redmond Developer ... - 0 views

  •  
    Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~
  •  
    Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~
Gary Edwards

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

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

ODF 1.2 Metadata? You're Dreaming! Microsoft starts rolling out more OOXML translators... - 0 views

  • Sorry Shish, you're wrong about ODF 1.2 Try ODF 1.5 or ODF 2.0, maybe. The metadata requirements for ODF 1.2 actually did include two way lossless translation capability. Unfortunately these features did not survive the final cut, and were not included in the April 2007 submission. You might also want to check the February 23, 2007 metadata proposal from Florian Reuter. That also would have delivered the goods and perhaps put ODF that grand convergence category of usefulness across desktops, servers, devices and web systems currently the exclusive domains of MS-OOXML and CDF+. Florian had devised a means of using metadata to describe the presentation aspects of content and structural objects. Very revolutionary. And based on the simple notion that bold, font, margins etc. are simply metadata about content and style objects. Where the train came off the track had to do with the concept of an XML ID means of linking metadata to content. Not that there was anything wrong with this mechanism. It's actually quite clever. What went wrong was that Sun insisted that only those elements approved and supported by OpenOffice would be allowed to make use of XML ID metadata. For independent developers, this is a serious constraint. Because of this constraint, the metatdata sub committee started off with six elements supported by OOo that metadata could be appied to. IBM then came in and asked for eleven more elements having to do with charts and graphs. The OpenOffice crew decided they could support this, so in they went. Then an interesting question was posed, "How are independent developers supposed to submit elements for metadata consideration?"
Gary Edwards

Open XML trumps ODF in document format fight, consulting firm says - 0 views

  • The OpenDocument Format (ODF) remains "more of an anti-Microsoft political statement than an objective technology selection" by users, according to a report released Monday by analysts at Burton Group, who recommend that companies adopt Microsoft Corp.'s Office Open XML document format whether or not it is approved as an ISO standard next month.
Gary Edwards

Collaboration and Content Strategies Blog: Free Report on ODF/OOXML Available - 0 views

  • The overall document summary: Industry debate about the relative merits of OpenDocument Format (ODF) and Ecma 376 Office Open XML (OOXML) highlights the significance of the productivity application market shift from binary and proprietary file formats to vendor- and product-independent Extensible Markup Language (XML) models. The competitive stakes are huge, and the related political posturing is sometimes perplexing. In this overview, Research Directors Guy Creese and Peter O’Kelly introduce ODF, OOXML, and related World Wide Web Consortium (W3C) standards, and project their implications for future productivity applications.
« First ‹ Previous 81 - 100 of 198 Next › Last »
Showing 20 items per page