Skip to main content

Home/ OpenDocument/ Group items tagged Microsoft

Rss Feed Group items tagged

Paul Merrell

BetaNews | Microsoft's Matusow and Mahugh on Office's move to open format support - 0 views

  • DOUG MAHUGH, program manager for ISO 29500-based products, Microsoft: One thing to be very clear about here is this: When we say, "support for ODF in [Office] SP2," we intend to write very compliant ODF documents when you save a document. However, it's not a given that everything you can do in the Office UI is savable under ODF. As you're alluding to, there are things -- SmartArt, conditional formatting, things like that -- that we have in Office and that are popular features, where there is no way to save those in ODF, currently.The way we're approaching that, I can share a little bit with you: We're not throttling the UI, as you describe, where certain things are disabled. Rather, at the time you save, we're telling you, "Hey, you're saving in this other format; some information in this document may be lost." That sort of thing. And let me tell you why we made the decision to do it in that particular way: There are situations where some of that functionality may be very useful to the user, even though it can't be serialized out to the format that they're saving in.
    • Paul Merrell
       
      One might suppose that the new API discussed on the following page will similarly not allow developers to set a compatability mode in Office apps. Note that the existing APIs do allow that, so one might suspect that disabling the ability to set a compatibility mode is one of the reasons for the new API.
  • The engineering decisions that were made in the original creation of ODF represent the engineering pathway and the innovations that were happening in the OpenOffice space. The engineering decisions and development pathway for Open XML represents that which was happening in [Microsoft] Office, and the feature sets are not in parity. In fact, there's a superset of features within the Microsoft Office set, but there are certainly features that are exclusive to OpenOffice that do not get covered in Microsoft Office.
  • We really hope to see ODF move to JTC 1 / SC 34 maintenance
Gary Edwards

The better Office alternative: SoftMaker Office bests OpenOffice.org ( - Soft... - 1 views

shared by Gary Edwards on 30 Jun 09 - Cached
  • Frankly, from Microsoft's perspective, the danger may have been overstated. Though the free open source crowd talks a good fight, the truth is that they keep missing the real target. Instead of investing in new features that nobody will use, the team behind OpenOffice should take a page from the SoftMaker playbook and focus on interoperability first. Until OpenOffice works out its import/export filter issues, it'll never be taken seriously as a Microsoft alternative. More troubling (for Microsoft) is the challenge from the SoftMaker camp. These folks have gotten the file-format compatibility issue licked, and this gives them the freedom to focus on building out their product's already respectable feature set. I wouldn't be surprised if SoftMaker got gobbled up by a major enterprise player in the near, thus creating a viable third way for IT shops seeking to kick the Redmond habit.
    • Gary Edwards
       
      This quote is an excerpt from the article :)
  •  
    Finally! Someone who gets it. For an office suite to be considered as an alternative to MSOffice, it must be designed with multiple levels of compatibility. It's not just that the "feature sets" that must be comparable. The guts of the suite must be compatible at both the file format level, and the environment level. Randall put's it this way; "It's the ecosystem stupid". The reason ODF failed in Massachusetts is that neither OpenOffice nor OpenOffice ODF are designed to be compatible with legacy and existing MSOffice applications, binary formats, and, the MSOffice productivity environment. Instead, OOo and OOo-ODF are designed to be competitively comparable. As an alternative to MSOffice, OpenOffice and OpenOffice ODF cannot fit into existing MSOffice workgroups and producitivity environments. Because it s was not designed to be compatible, OOo demands that the environment be replaced, rebuilt and re-engineered. Making OOo and OOo-ODF costly and disruptive to critical day-to-day business processes. The lesson of Massachusetts is simple; compatibility matters. Conversion of workgroup/workflow documents from the MSOffice productivity environment to OpenOffice ODF will break those documents at two levels: fidelity and embedded "ecosystem" logic. Fidelity is what most end-users point to since that's the aspect of the document conversion they can see. However, it's what they can't see that is the show stopper. The hidden side of workgroup/workflow documents is embedded logic that includes scripts, macros, formulas, OLE, data bindings, security settings, application specific settings, and productivity environment settings. Breaks these aspects of the document, and you stop important business processes bound to the MSOffice productivity environment. There is no such thing as an OpenOffice productivity environment designed to be a compatible alternative to the MSOffice productivity environment. Another lesson from Massach
Gary Edwards

ConsortiumInfo.org - New Comment Draft of Mass. ETRM Includes OOXML - 0 views

  • this new draft includes Microsoft's OOXML formats as an acceptable "open format." 
  •  
    Game Over?  Probably.  I've been expecting Massachusetts to publicly revise the ODF mandate to include OOXML ever since Louis Gutierrez resigned in early October of 2006.  That was as clear a signal that ODF had failed in Massachusetts as anyone needed.

    The only surprise is that it took the new CIO, Beth Pepoli so long to make the announcement that OOXML would be recognized as an officially recognized open XML file format going forward.

    Andy UpDegrove of course does his best to downplay the significance of this announcement.  But how can this not be the deathnell for ODF? 

    The failure of ODF in Massachusetts has resulted in a world wide recognition that it is impossible to implement ODF. 

    This is exactly what happened to ODF mandate legislature in California.  The CIO's in California uniformly rejected both ODF legislation and Sun's hapless effort to set up an ODF Pilot Study based on what had happened in Massachusetts.  If Mass couldn't implement ODF, than they saw no reason for them to try.

    And it does come down to "implementation". 

    Most people think the implementation of ODF is as easy as downloading OepnOffice and converting your legacy docuemnts to ODF as they are used.  Simply fix the artifacts of conversion in process, and never look back.  OOo is free.  So what's not to like?

    Well, the problem is that the world has fifteen plus years of building business processes, line of business integrated applications and other client/server integration on top of the MSOffice application suite.  These business processes are bound hard to MSOffice.

    So the barrier for OpenOffice and ODF is twofold.  Any implementation of ODF must overcome both the binary documents conversion barrier, and, the MSOffice bound business process barrier.

    The cost and disruption of a <font
Gary Edwards

Choice - 0 views

  • With ISO/IEC having standardized Open Document Format (ODF) 1.0 and considering standardizing Ecma Office Open XML (Open XML), there is a lot of public discussion about document formats and whether the world should begin to focus on only one format or continue to see multiple formats developed and used over time. Microsoft believes that users should be able to choose among formats and pick the one that best meets their needs. We also believe in encouraging the continued evolution of computing and data formats. And we support the ratification of Open XML in ISO/IEC. There are several reasons for these views:
  •  
    This the infamous Microsoft letter that many have misconstrued as an announcement of support for OpenDocument.  Only in a Microsoft universe can the statement, "We're not going to attack ODF" be taken as Micrsoft support for ODF.
Gary Edwards

Commercializing Interoperability -- gary_edwards's comment on "Linux leaders plot count... - 0 views

  • Is Microsoft commercializing "interoperability"? Is interoperability through privileged access to the interop API's now a strategic asset to be traded with partners in crime?
  •  
    The first post in the ZDNet series discussing the many deals Microsoft is cutting with prominent LiNUX vendors.  My point is that interoperability plays a prominent role in each of these deals, and, the deals also involve partners supporting Microsoft directed interop between OpenOfficeXML and OpenDocument.  Coincidence? 

    I think not!

Gary Edwards

EC on Microsoft Interoperability Declaration: Is It April Fools' Day Already? | John Pa... - 0 views

  • “We have heard high-profile commitments from Microsoft a half-dozen times over the past two years, but have yet to see any lasting change in Microsoft’s behavior in the marketplace,” ECIS Legal Counsel and Spokesman Thomas Vinje said in a statement.
  •  
    Thomas Vinge, the counsel for the ECIS, comments on Microsoft's most recent restatement of their enduring commitment to interoperability and transparency.
Gary Edwards

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

  • 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?
  •  
    Tim Bray suggests using namespaces to brdige the comatibility gap between ODF and OOXML.
  •  
    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 Case for Harmonization (that IBM will vote against anyway) « A Frantic Op... - 0 views

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

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

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

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

OOXML vs ODF: where next for interoperability? | Reg Developer - 0 views

  • 'A diversion from the real end game – the taking of the internet' Gary Edwards of the Open Document Foundation has a fascinating post on the important of Microsoft Office compatibility to the success of the ISO-approved Open Document formats. It is in places a rare voice of sanity: People continue to insist that if only Microsoft would implement ODF natively in MSOffice, we could all hop on down the yellow brick road, hand in hand, singing kumbaya to beat the band. Sadly, life doesn’t work that way. Wish it did. Sure, Microsoft could implement ODF - but only with the addition of application specific extensions to the current ODF specification … Sun has already made it clear at the OASIS ODF TC that they are not going to compromise (or degrade) the new and innovative features and implementation model of OpenOffice just to be compatible with the existing 550 million MSOffice desktops.
Gary Edwards

Antitrust: The EU Case Against Microsoft | Investingation, Court Proceedings, Decisions... - 0 views

  • The web-pages referred to below provide information about the European Commission’s March 2004 Microsoft Decision, the Court of First Instance proceedings relating to that Decision, and its ongoing implementation.
Gary Edwards

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

  • Plan B: The "NO ViSTA" Mandates:&nbsp; 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).&nbsp; 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.&nbsp; Now the mighty monopolist can taste victory, with fast track approval of MOOX certain, and ISO/IEC in the bag.&nbsp; Incredibly the company that escaped a Court ordered death sentence by purchasing what amounts to a presidential pardon.&nbsp; They even avoided the stink of their own lobbyist and henchman Jack Abramoff, and his motley crew of Ralph Reed and Grover Nyquist operatives.&nbsp; Now they are well on their way towards purchasing an International Standard.&nbsp; So much for Plan A.&nbsp; 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

MSFT: Let's Do VHS Versus Betamax All Over - 0 views

  • “You want the customers to vote with their wallets,” Hilf said.”The most healthy market environment is where there is competition.”
  •  
    Another great commentary from Walt Hucks.  This time his target is the over the top self serving statements from Microsoft about consumers wanting "competition" between standards.  I was a loser in the BetaMAX wars.  At least SONY had an edge in those wars of claiming a somewhat, although leglible, advantge in video fidleity.  Microsoft OOXML has no such advantage over ODF.  None whatsoever.

    Walt once again exposes Microsoft as the company you can count on to treat customers as mindless idiots.    Given the choice, customers would choose ODF over OOXML hands down, time after tiem, every time.  But they are not given "the choice".  Mcirosoft spends a lot of spin cycles complaining and whining about IBM and others not providing native support for OOXML.  Incredibly, they do this while announcing loudly that they have no intention of ever supporting ODF nativiely in their own applications?  What's u with that?  Leveraging the monopoly.  That's what.

Gary Edwards

ODF versus OOXML: Don't forget about HTML! - O'Reilly XML Blog - 1 views

  • But Lie is right, I think, to be alarmed by the prospect that if OOXMLfails MS will revert away from open formats. I don’t see them adopting ODF as the default format for general sale. for a start, current ODF simply does not have matching capabilities. This issue of fit is strong enough that we don’t even need to get to the issue of control. We have this nice little window now where MS is inclined to open up its formats, something that the document processing community has been pleading for for years. The ODF sideshow runs the risk of screwing this up; I’ve said it before, but I say it again: being pro-ODF does not mean you have have to be anti-OOXML. ODF has not been designed to be a satisfactory dump format for MS Office; OOXMLhas not been designed to be a suitable format for Sun’s Star Office or Open Office or IBM’s products. HTML is the format of choice for interchange of simple documents; ODF will evolve to be the format of choice for more complicated documents; OOXML is the format of choice for full-fidelity dumps from MS Office; PDF is the format of choice for non-editable page-faithful documents; all of them are good candidates for standardization, all have overlap but are worthwhile to have as cards in the deck of standards. But systems for custom markup trumps all.
  •  
    Famed Microsoft WikiPedia editor Rick Jellife takes on the HTML-CSS proposal put forth by Opera Browser CTO Håkon Wium Lie's in his recent CNET column.

    Rick claims that the Opera proposal is "solid in its ultimate premise .... that inspite of .. all the talk about ODF and OOXML, it is important not to lose track of HTML's potential and actual suitability for much document interchange.

    Good discussion except that MS Rick can't help himself when it comes to the tired moral equivocation argument that the world can and should accept and use two ISO/IEC desktop productivity environment file format standards, ODF and OOXML.  Once again he puts forward the claim that ODF is OPenOffice specific and OOXML is MSOffice specific - each having it's place and value as an international standard.

    Are we standardizing applications here?  I thought it was about creating a universal XML file format that all application can use::  One file format  for OpenOffice, MSOffice, KOffice, Writer, WordPerfect Office, Novell Office, GNOME Office, and even the Flash-Apollo based " Virtual Ubiquity " from Rick Treitman.

    ODF does need to provide the marketplace with at least three profiles; desktop productivity environments, server side portal publication-content-archive management systems, and devices.  This would greatly improve interoperability as ODF documents transition across desktops, servers, devices and Internet information domains.  It would also help the implementation of ODF by SOA, SaaS and Web 2.0 systems.

    But having two file formats that irreconcilably incompatible servicing the exact same market categories?  Doesn't make sense.  And can only end in massive end user confusion where the application with dominant marketshare end up crushing any and all competitive alternative
Gary Edwards

Hunting down those who dare help Microsoft | Florian Reuter's Weblog - 0 views

  • New OpenOffice.org target.Many of you probaly know the “WONT FIX” target in the OpenOffice.org issue tracker.What about introducing a new target: “HELPS MICROSOFT”.But why do we need this? These days many people --- especially from the file formats camps --- are extremely sensitive of anything related to compatiblity 'cause they believe it helps Microsoft.So lets give the ODF warriors an opportinity to clearly communicate with the users. Give them the “HELPS MICROSOFT” target to publicly exposing the issuer of the bug and the people working on it.
  •  
    Another good one from that all around funny guy and document processing expert extraordinaire, Florian Reuter.  This one is way too funny.  I hope the lord of the garage gestapo doesn't take him up on this.
Gary Edwards

Can IBM save OpenOffice.org from itself? - 0 views

  • OpenOffice.org's biggest foe may be Microsoft Office, but critics say the open-source organization has, from its inception, also been one of its application suite's own worst enemies -- a victim of a development culture that differs radically from the open-source norm. Observers now wonder if IBM's entry into OpenOffice.org can make the necessary changes.
    • Gary Edwards
       
      good article from Eric Lai of ComputerWorld. Written on the eve of the infamous Barcelona OpenOffice.org developers conference, Eric argues that OOo isn't a real open source community. Instead, OOo is a owned and operated by Sun.
      One of the more important control points Sun insists on is that of commit rights and project managers. Only Sun employees have these rights and can hold these important positions..
      The more important point is made by Marbux (below: ODF is an application specific format designed exactly for OpenOffice. While other applications might partially implement ODF, interoperability and successful ODF document exchange require the OOo code base!
      From Marbux: This is the only article I've found to date where IBM (Heintzman) flat out says IBM wants changes in OOo licensing, more in line with the Eclipse and Apache licenses. See pg. 2. Significant because it feeds the meme that IBM's own ODF-based development goal is proprietary closed source built on the OOo code base, e.g., Symphony, et cet.
      And that has huge signficance once you realize that ODF is not the real standard; the OOo code base is the real ODF standard. Look around the world and you see that ODF adoption decisions by governments are all in reality decisions to go with StarOffice, OOo, or OOo clones. I haven't, for example, seen a single instance where a government decided to ride with KOffice. Why would they, with the interop issues between KOffice and OOo? The fact that OOo's code base is the real ODF standard will figure strongly in the comments. Couple it with Sun's iron-fisted control of the OOo code base, and you have vendor lock-in with a Microsoft partner.
      But with 70 developers committed in China, where developers salaries are inexpensive, IBM will soon be in a position to threaten to fork the OOo code base using proprietary extensions. Is that their real tactic to force changes in licensing and gov
Gary Edwards

Report: Companies Use Word Out of Habit, Not Necessity > Comments by ge - 0 views

  •  
    I doubt that MSOffice ODF will make a difference. ODF was not designed to be compatible with MSOffice, and conversion from native binary to ODF will result in a serious loss of fidelity and business process markup. If the many ODF pilots are an indication, the real killer is that application specific processing logic will be lost on conversion even if it is Microsoft doing the conversion to ODF. This logic is expressed as scripts, macros, OLE, data binding, media binding, add-on specifics, and security settings. These components are vital to existing business processes. Besides, Microsoft will support ISO 26300, which is not compatible with the many aspects of ODF 1.2 currently implemented by most ODF applications. The most difficult barrier to entry is that of MSOffice bound business processes so vital to workgroups and day-to-day business systems. Maybe the report is right in saying that day-to-day business routines become habit, but not understanding the true nature of these barriers is certain to cloud our way forward. We need to dig deeper, as demonstrated by the many ODF pilot studies.
Paul Merrell

Doug Mahugh : ODF Implementation Notes for Office 2007 SP2 - 0 views

  • Microsoft has today published our first set of document-format implementation notes, for the ODF implementation in Office 2007 SP2. These notes, which are available on the DII web site, provide detailed information about the design decisions that went into our implementation of ODF 1.1.
  • Doug, The list of elements and attributes "not supported in core Word/Excel/PowerPoint 2007" is quite long. Can you tell us what will happen, when Office 2007 encouters an unsupported element. Will it simply be ignored? When roundtripping - will it be deleted or preserved?
  • Doug, The list of elements and attributes "not supported in core Word/Excel/PowerPoint 2007" is quite long. Can you tell us what will happen, when Office 2007 encouters an unsupported element. Will it simply be ignored? When roundtripping - will it be deleted or preserved?
  • ...1 more annotation...
  • Jesper, On load, Office 2007 SP2 will simply ignore the unsupported elements and attributes in ODF files. &nbsp;We do not attempt to round trip unsupported elements and attributes, they will be removed from the ODF file if you resave it using Office 2007 SP2. &nbsp;This is consistent with our implementation principles and our desire to provide predictable behavior. &nbsp; We considered trying to roundtrip elements and attributes that we do not understand or support, but we found if we did this that we could not be sure the resulting files were internally consistent and conformant ODF files. &nbsp; As an aside, there are some cases where we write elements or attributes on save that we do not support on load, for the sake of better interoperability with other applications that use ODF. &nbsp; Those cases are described in the implementer notes as well.
  •  
    Jesper Lund Stocholm asks a right-on-the-mark question. Peter Amstein answers for Microsoft. What do you expect when a specification ends its conformance section with the statement, "There are no rules regarding the elements and attributes that actually have to be supported by conforming applications, except that applications should not use foreign elements and attributes for features defined in the OpenDocument schema?"
Jesper Lund Stocholm

The Forrester Blog For Information & Knowledge Management Professionals - 0 views

  • Wow. Microsoft opened up today, taking a nearly 180-degree turn to announce its intent to support ODF, PDF, and XPS. Overall, this is a great, positive move. While unexpected, it's not surprising. Microsoft has been moving towards more open standards, like with its recent DAISY XML initiative. But it's also a no-brainer. Sticking exclusively with its competing Open XML was divisive, complicating IT's efforts to leverage the benefits that open source XML provides.
  •  
    Reading this I suddenly thought of the phrase "Internet tidal wave" from Bill Gates in the late 90's . I know the rest of the world don't give a damn about the document format war (as much as we do), but the move from Microsoft here is actually quite substantial.
« First ‹ Previous 61 - 80 of 252 Next › Last »
Showing 20 items per page