Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Microsoft IT Technology

Microsoft Deprecating Some OOXML Functionality 138

christian.einfeldt writes "According to open standards advocate Russell Ossendryver, Microsoft will be deprecating certain functionality in its Microsoft Office Open XML specification. Ossendryver says the move is an attempt to quiet critics of the specification in the run up to the crucial February ISO vote. The Microsoft-led industry standards group formally offering OOXML confirms in a 21 December 2007 announcement that issues related to the 'leap year bug', VML, compatibility settings such as 'AutoSpaceLikeWord95' and others will be 'extracted from the main specification and relocated to an independent annex in DIS 29500 for deprecated functionality.'"
This discussion has been archived. No new comments can be posted.

Microsoft Deprecating Some OOXML Functionality

Comments Filter:
  • by mr_mischief ( 456295 ) on Friday December 28, 2007 @10:37PM (#21845720) Journal
    If MS deprecates it but makes support for the deprecated features the default option in their software, they'll still be contributing to people spewing incompatible files that don't render correctly in software following the standards. It'd be better to just rip out the parts that shouldn't be there and resubmit the standard. Having to recognize and either support or report lack of support for a maze of twisty little semi-standard features for sake of backwards compatibility is not going to help the situation much,
    • by MightyYar ( 622222 ) on Friday December 28, 2007 @10:42PM (#21845750)
      I disagree. If you add up all of the letters in the words "de facto" and then multiply that by the number of times the phrase "de facto standard" is written, you can see that getting certified as true standard will save massive amounts of disk space, paper, and toner.
  • Smoke and Mirrors (Score:5, Insightful)

    by ozmanjusri ( 601766 ) <.aussie_bob. .at. .hotmail.com.> on Friday December 28, 2007 @10:40PM (#21845738) Journal
    The result of Microsoft's manipulation should be ISO banning MSOOXML from participating in the standards process.

    It's abundantly clear now that the format is critically flawed and cannot be implemented by anyone, not even the Office team themselves.

    ECMA 376 is a bomb disguised as a standard. It redefines functions and components just to retain ties to the undocumented legacy formats. Therefore a number of things that should be fixed by now, thanks to better engineering, and existing ISO standards, are left not only unfixed, but even perpetuated by ECMA376.
    The fact that Microsoft continues to push this fake "standard" shows how little they care about their customers and how much their business is predicated on lockin.
  • About right. (Score:3, Interesting)

    by Stumbles ( 602007 ) on Friday December 28, 2007 @10:42PM (#21845752)
    Sounds consistent with the way Microsoft works. Promise the moon and deliver a crater. It was their intention all along. Propose something that smacks everyones senses with a bat, then back off with something that sound more reasonable, even though it is not.
  • by filbranden ( 1168407 ) on Friday December 28, 2007 @11:00PM (#21845834)

    In another move to spread more FUD, now they're trying to hide the UGLY part of the specification. But, what use is hiding it? They claim the deprecated features will be used only for the migration of old binary formats, and that they should not be used by new documents... But considering that the whole point of this document format standardization effort is to be able to open any document in 20 or 30 years time, and if the old binary format documents will be converted using deprecated features, that just means that any software implementing the standard will have to support the deprecated features anyway...

    Although they keep manipulating, manipulating, and manipulating more, I still think their format stinks, they're only using it to spread FUD over other formats, and I really hope they can't pull this stunt.

    • by Anonymous Coward on Friday December 28, 2007 @11:28PM (#21845914)
      And VML is used in Office 2007... see this openmalaysia blog post [openmalaysiablog.com]. Marking things as deprecated just means that it's discouraged, and it doesn't mean that there's a modern replacement (like how in HTML FONT was deprecated and it's replacement was CSS functionality). VML is still a necessary part of OOXML, so marking it as deprecated doesn't actually help developers. What would help them is if DrawingML could be used in all the places that VML can be. Infact, as the CNS (Microsoft's covenant not to sue) specifically excludes patent coverage over non-required features this means that we may now be lacking patent coverage over VML. Can anyone from Microsoft comment on this? (the Microsoft OSP might grant coverage if that "Necessary Claims" means normative, as they claim)
    • But considering that the whole point of this document format standardization effort is to be able to open any document in 20 or 30 years time, and if the old binary format documents will be converted using deprecated features, that just means that any software implementing the standard will have to support the deprecated features anyway...

      ... though Office is currently the only major implementation of OOXML, so the only reason Microsoft is deprecating the features instead of removing them is to save the developers time and the end-users the "hassle" of downloading and installing an update.

    • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Saturday December 29, 2007 @02:42AM (#21846682) Homepage Journal

      They claim the deprecated features will be used only for the migration of old binary formats, and that they should not be used by new documents...

      Someone help me out here, for real. I think I'm missing something. What is the point of those ridiculous "backward compatibility" tags? Word's never been good enough for pixel-perfect rendering. For example, printing the same document on different printers hasn't ever been likely to give the same output. So, what on earth is the justification for maintaining a "renderLikeWord95" tag when that was never well-defined to begin with?

      If the <foo> attribute originally meant "centered, bold, double-spaced", then just make the importer translate it to something like "<textblock align="center" weight="bold" height="200%"> text goes here </textblock>". Forget bug compatibility. That's a dying horse and needs killed now before we end up with something like the loose HTML parsing nightmare that browser designed are stuck with. Who cares how the document originally displayed on the original machine? MS never did before today.

      Don't hide those tags - delete them. There is no rational explanation other than lock-in for having them, and as long as they're around, the IT world will know this is a joke.

      • Actually, I've looked into the way that Microsoft Windows does printing. It's a bit more complicated than this, but basically you open a DC (device context), paint onto the DC and then submit to the printer driver. After this it's up to the printer driver to print correctly, not for the app to try to get around driver deficiencies.

        Thus, if there is a specific way that rendering works in Word '95 that is different to Word 2007, correct it while painting it to the DC. If the printer driver doesn't work, then
        • by jbengt ( 874751 )

          Say for instance the 1900 leap year bug. How would you get around that?

          Don't transform given dates, use those given (as opposed to those calculated). If there's any computation that crosses that bug, such as day-of-the-week before 1900 or number of days between dates on opposite sides of 1900, recompute it with the correct result. Add a comment that the original document included such and such calculation with the incorrect result.

          Just because there's a mistake in the original implementation doesn't

        • by jhol13 ( 1087781 )

          Say for instance the 1900 leap year bug. [...] do what MS are doing: use the tag to denote the issue.
          But this is NOT what Microsoft is doing! There is no tag. Every OOXML spreadsheet is assumed to calculate wrong. BTW you cannot have dates before 1900. This is, to me, totally unacceptable.

          Same goes with CEILING, etc. There is no tag "calculate CEILING mathematically (in)correctly", the definition of CEILING is to calculate incorrectly.
          • Whoa. /me went to investigate this further, and by golly you're right!

            According to Rob Weir [robweir.com], under Section 3.17.41 of SpreadsheetML Reference Material, page 3305 of the OOXML specification, "Date Representation" says:

            For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [Note: That is, serial value 59 corresponds to February 28, and serial value 61 corresponds to March 1, the next day, allowing the (nonexistent) date February 29 to have the seri

            • by Froqen ( 36822 )
              You don't get it, HTTP 1.0 has to work with people speaking HTTP 0.9, HTTP 1.1 has to work with people speaking HTTP 1.0.

              Backwards compatability is everything, warts and all. OpenXml is effectively a new version of the office file formats designed to be well documented and generically implementable such that it can be a standard. Imagine using a new firefox that could ONLY render perfect valid latest standards HTML, would you bother using it with the vast majority of the Web not working?

              If you disagree with
    • Why include 'deprecated features' in a new standard anyway? Why not just remove them altogether?
      • by Allador ( 537449 )
        Because its not a new standard.

        It's a codification and documentation of an existing de-facto standard.

        They didnt design a brand-new blue sky format. They codified their existing one, warts and all.

  • by Anonymous Coward on Friday December 28, 2007 @11:11PM (#21845860)
    I'd just like to remind everyone that OOXML is a superb standard.

    -- Miguel
  • by larpon ( 974081 )
    the AutoSpaceMonaLisasGapBetweenHerTeethButOnlyWhenShesSmilingLikeWord95BBQ compability?
  • by Anonymous Coward
    > settings such as 'AutoSpaceLikeWord95' and others will be extracted

    Lets just hope they keep the 'WaveYourArmsInTheAirLikeYouJustDontCare' setting.
    • I'm more interested in the PartyLikeIt's1999 setting... they seem hell bent on keeping that one around as long as possible.
  • I've done quite a bit of reading, and listening on the topic of OOXML, and I have come to the conclusion that there is no good (at least of the technical kind) in OOXML. Yet, people seem convinced that Microsoft is a "good" company. And a good company wouldn't actively push something that was obviously without any good for the industry... so I must be missing something. I generally just think that it is for the purpose of profit and control, but every now and then I like to give opposing views a chance - si
    • Just like people who buy their phone and internet from the biggest company they know.
      As far as they are concerned, they are getting the best deal and there arent any compeditors.

      They simply dont know any better.
    • Catch 22, remember? Milo, msft, what's the difference?
    • I think what you mean is that you've done a lot of reading and listening to those that have a political or financial stake in the outcome of the OOXML standardization.

      Has it ever occured to you that listening to people like Rob Weir or Andy Updegrove might only give you part of the story?
      • by Xtifr ( 1323 )

        I think what you mean is that you've done a lot of reading and listening to those that have a political or financial stake in the outcome of the OOXML standardization.

        Yeah, that's pretty much what he said.

        Has it ever occured to you that listening to people like Rob Weir or Andy Updegrove might only give you part of the story?

        I think that's why he asked for the other side of the story. And yet, all he gets is a snarky response suggesting that he's only listening to one side of the story. He said, "I like to give opposing views a chance - since I may be the one wrong." As someone who feels the same way, I'd love to hear some arguments from the other side. But when a direct request for arguments from the other side is met with a sarcastic, "you're only listening to one side", one gets th

        • You're focused on this as a "new" standard. It's not. It's basically documenting an existing defacto standard (MS's binary format), albeit in a new way. OOXML is little more than Microsoft's binary formats, documented and expressed in XML. This allows billions of existing documents to be converted to an open format without the need of (possibly lossy) translation.

          If you posit that people are going to continue to use MS Office, and if you posit that new software will continue to be built that needs to wo
          • by Xtifr ( 1323 )
            I'm sorry, but "in a new way" means its not an existing standard, de-facto or otherwise. It doesn't matter if it maps to similar structures--png and gif both map to bits on a screen, but they're very different standards. And this is completely different from the .doc standard, even if it's structurally similar internally (an implementation detail that you and I will never see).

            And no, this doesn't document their de-facto standards. In fact, they've just deprecated the backwards-compatibility section beca
            • Members of the Gnumeric team beg to differ. They state rather matter of factly that the documentation of OOXML has helped them immensely with their legacy binary compatibility.

              As for deprecation. You might want to pay a little closer attention. Those elements were deprecated in the first version. Seriously. The only difference here is that ECMA is extracting the deprecated elements to their own annex and are putting big red flashy neon signs on it saying "don't implement this stuff, we meant it, it's g
            • by Allador ( 537449 )
              I'm not the one you were responding to, but I think a couple points need addressing here.

              If I have a binary .doc file and a complete copy of the OOXML spec, I've got nothing.

              Sure you do. Open it in the current version of the product and save it as the current version of the format. Now you have full access.

              MS didnt document the 2-major-generations-old format, they documented the current format.

              What advantage to anyone (except MS) is there in adding another?

              Everyone benefits. A previously undocumented format is now documented. Thats a good thing.

              Is there something OOXML can do that ODF can't?

              Document the format used by the vast, vast majority of office-productivity software users on the planet

    • The office suite with 90% marketshare is moving to a documented, text-based format. And you can see NO technical good in it at all?

      Perfect example about how the zealotry surrounding this issue has blinded people into utter stupidity.
      • by Xtifr ( 1323 )

        The office suite with 90% marketshare is moving to a documented, text-based format. And you can see NO technical good in it at all?

        That's not the issue here. I've argued myself that this is a surprisingly good thing in the past. The question here, though, is not, why is it good that MS is moving to a somewhat more open (or at least less opaque) format. The question is, why should this format be given ISO's blessing?

        MS made the decision to move to XML years ago. That's over and done with. I'm a little surprised and pleased that they carried through with it, but it's still in the past. The result looks ugly and maldesigned in my o

      • by AJWM ( 19027 )
        The office suite with 90% marketshare is moving to a documented, text-based format. And you can see NO technical good in it at all?

        What in the world would lead you to believe that Microsoft Office will ever generate a document, except perhaps for the most trivial, that actually conforms to the spec they're pushing as MSOOXML? When has Microsoft software ever conformed to published specs, even those published by Microsoft (let alone some quasi third party)?

        Oh, and it isn't all text-based, there's some bina
        • by Allador ( 537449 )

          What in the world would lead you to believe that Microsoft Office will ever generate a document, except perhaps for the most trivial, that actually conforms to the spec they're pushing as MSOOXML?

          Why do you think they haven't? Have you created files, opened them up and looked at them, and compared them to the spec? I've opened them up, took a look at how nice it was that this was finally in a textual format, but have never compared to spec.

          Oh, and it isn't all text-based, there's some binary crud in there too, as hex, neatly wrapped in appropriate equivalents to tags.

          You mean like embedded images? Or other embedded binary objects? How would you prefer they store those? The base64-encoded (or whatever) stuff inside these documents are not the smoking gun you think they are.

    • by Allador ( 537449 )
      The technical good in OOXML is that its a codification of something that's incredibly widely used, but has never been codified before.

      If you go with the assumption that MS isnt going to throw away their existing products and write a new ODF reader/editor/writer, at least not in the short term, then this seems perfectly reasonable.

      Given that assumption, there are only two choices. To codify the de-facto standard that is ms office, or not.

      I think its fair to say that to do so is unqualifiedly the better choi
  • by erroneus ( 253617 ) on Friday December 28, 2007 @11:36PM (#21845936) Homepage
    Just like with Vista, they just drop features until it's "releasable."

    Here's the obvious problem:

    They will claim a feature is deprecated, or not part of the spec, but their software will continue using it. Meanwhile, other programs that try to read and write OOXML format following the "official" spec, will result in the documents created or edited by other programs not being fully compatible with MS Word. This will be seen by the user community as a deficiency in the alternative software and no as a problem with Microsoft's software.

    We have seen this before and we continue to see it. People think that because a web site works with MSIE and doesn't work with Firefox that there's a problem with Firefox... Microsoft continues to damage the competition in this way and will persist in the same. I hope that the voters in the ISO decisions are aware of this potential problem.
    • If microsoft if really serious about getting this in a standard, we need legal documents saying their software will remove the features, then the features removed from the standard, not getting them removed from the standard.
  • 'AutoSpaceLikeWord95' and others will be 'extracted from the main specification and relocated to an independent annex in DIS 29500 for deprecated functionality.'

    ...that, that so called deprecated functionality will be "re-introduced" in an update to enhance the user experience and security at some later date. When this happens, part of hell will break lose and we'll be back here at Slashdot debating this and that.

  • I'll take the grammar Nazi hit..."deprecating"? One usually deprecates oneself in every use I've ever read. While the use might be technically correct it certainly isn't current usage. I'd think "minimizes" or "plays to lowest common denominator" might be a whole lot more understandable.

    From m-w.com

    "Entry Word:
    deprecate
    Function:
    verb

    Text: 1 to express scornfully one's low opinion of -- see decry 1 2 to hold an unfavorable opinion of -- see disapp
    • 'Deprecate' has a precise, relevant meaning when talking about specifications. It basically is a polite way to put all people who depend on a specification (or implementation thereof) that a certain feature is slated to be removed at an arbitrary time in the future. This is done so that developers, integrators, etc., can migrate away from the deprecated features before they are removed, allowing a smooth transition.
    • Re: (Score:3, Insightful)

      by mrchaotica ( 681592 ) *

      "Deprecate" is also technology jargon that means "to mark as obsolete." How you could be a Slashdot reader and not be familiar with that usage, I cannot understand.

      • "Deprecate" is also technology jargon that means "to mark as obsolete."

        I'm not the first one to observe this, but ... how can you obsolete an element of a standard when it has never been part of the standard?

        • how can you obsolete an element of a standard when it has never been part of the standard?

          MS Office [11] is the standard. OOXML is just the cliffnotes.

      • ""Deprecate" is also technology jargon that means "to mark as obsolete." How you could be a Slashdot reader and not be familiar with that usage, I cannot understand."

        In twenty plus years of IT I have never, ever heard deprecate used in relation to IT. Of course, I'm an admin/server guy so I'm pretty focused on care and feeding of the servers and users. As far as standards go I only nibble on the periphery. I guess maybe I could pull my head out the literary works where I'm used to seeing the word and exp
  • by IGnatius T Foobar ( 4328 ) on Saturday December 29, 2007 @12:10AM (#21846068) Homepage Journal
    It is highly doubtful that the "deprecated functionality" will be removed from Microsoft Office. Therefore if they get the revised OOXML passed as a standard, anyone who uses Microsoft Office based on its claim to be OOXML will have been the victim of a bait-and-switch tactic.

    But I suspect that was the goal all along. Orgs that just wanted to use Microsoft Office in the first place would be able to say "see, this is open" and keep doing what they were doing.

    Well, at least it's somewhat documented, making it somewhat easier than .doc/ppt/xls for the free world to reverse engineer.
  • Sneaky? (Score:5, Insightful)

    by PhotoGuy ( 189467 ) on Saturday December 29, 2007 @12:18AM (#21846104) Homepage
    This seems sneaky to me. Remove controvesial stuff from the standard, but put it in an Annex, that MS will implement and people will rely upon left and right, so it will become a de-facto microsoft embrace-and-extend standard.

    I really try to fight the kneejerk anti-microsoft sentiment around here, but lordy, all of their moves seem so calculated and evil. It's not just single actions, it's a pattern of actions. Humans are great at recognizing patterns. And even with good moves and bad moves, one can generally see a positive attitude behind Google, for example (some may disagree, but I think the general consensus is that they're not dastardly.) But with MS, every move seems like a piece of a puzzle showing a nasty, calculated, aggressive, anti-competitive entity. Everything seems consistent with that. The way the US rolled over on everything for political reasons is shameful. Hopefully the EU will right some of those wrongs, at least in part of the world.

    I guess to try and find the bright side, one could say "at least it's documented" (without an exorbitant fee and crazy restrictions, like SMB et al.)
    • Re: (Score:3, Insightful)

      by DerekLyons ( 302214 )

      Humans are great at recognizing patterns.

      Whether or not the pattern so recognized actually exists.
      • by Znork ( 31774 )
        Which is why you need scientific experiments to verify that you're not imagining things.

        In the case of Microsoft there have been several courts engaged in the legal equivalent, establishing that those patterns do exist.
  • But, of course! What else could they deprecate?

  • by jafoc ( 1151405 ) on Saturday December 29, 2007 @03:35AM (#21846868) Homepage
    IMO there's nothing wrong with the decision to deprecate some of the most revulsive misfeatures of OOXML, but there's the very real problem that this could lead some people (in particular in the national standardization bodies that will have the opportunity in March to change their vote about OOXML) to think that these relatively minor changes somehow make OOXML suitable for acceptance as a "standard".

    If you agree that this is a real risk, and you're willing to help with doing something about it, please join us at OpenISO.org [openiso.org] and help put together a "problem report" document about OOXML that explains the main issues clearly.

    • Re: (Score:3, Insightful)

      by Anonymous Coward
      I won't join your site, but I have a problem with the Introduction and its restatement later in the Goals section. Feel free to quote, copy, take credit for, or in any other way use, disuse, or fail to use, the following as it is now in the public domain.

      Introduction
      The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and
      platforms, fostering interoperability across office productivity applications and line-of-business systems, as well
      as to support and strength

      • Thanks a lot for posting this contribution. I'm feeding it into the process for producing the "problem report" document.
  • Nice to see that the comments thread on OOXML is shrinking as the debate matures. Of course that means that the usual trolls are either bored or on holidays but I think that we may collectively be starting to better understand what's going on.

    I attended the UNSW Cyberlaw centre forum on OOXML http://www.cyberlawcentre.org/2007/ooxml/ [cyberlawcentre.org] as an interested observer and I liked what I saw. Smart people engaged in a positive discussion. Yes, the viewpoints were polar, but the words were civil and a real exchange

  • The format is, in effect, still in development and there is already an independent annex dedicated to deprecated functionality. How exactly is it possible for a decent format to have deprecated features even before it exists?
  • Well, While we're at it, why not deprecate the whole shit and get the problem solved for good?
  • In a moment now he will start worrying about precious fluids.
  • Deprecating the functions doesn't mean that MS isn't going to be using them -- it just means that they don't want anybody else to use them. It's also possible that, by removing those functions to other sections, they're removing what little patent protection developers might have for implementing that functionality.... That's because MS's patent protection only clearly applies to features that are well-documented in the definition documents.

    So: The results of this deprecation could be (in the worst case):

To thine own self be true. (If not that, at least make some money.)

Working...