OOXML as a standard.



  • Just wondering what you guys think about OOXML and weather it should be an ISO standard? 



  • Personally I never understood why Word's (also any program that does something similar) default format wasn't HTML, you can inline images into HTML, and there are more HTML readers than doc (or whatever format) readers. As for the other formats in the spec, it is nice to know that MS isn't going to legally crush anyone who uses the same technology (through whatever method). It'd be nice if it were an ISO standard, but as I understand the issue, there are really dumb parts of the spec, such as the infamous "ActLikeWord95" (paraphrasing, you get the just of it though).



  • @Lingerance said:

    Personally I never understood why Word's (also any program that does something
    similar) default format wasn't HTML

    Well, for instance, HTML isn't broken into pages. And besides, Word has too many features that HTML can't support.

    Back on topic, I guess it'd be better for MS to support [url=http://opendocument.xml.org/]some already existing standard[/url] already, instead of creating their own, but still, having a standard is better than not having one (yes, I'm a standards freak).



  • @Spectre said:

    Well, for instance, HTML isn't broken into pages. And besides, Word has too many features that HTML can't support.
    style="page-break-before: always", what features specifically?
    @Spectre said:
    Back on topic, I guess it'd be better for MS to support some already existing standard already, instead of creating their own, but still, having a standard is better than not having one (yes, I'm a standards freak).
    As I understand it, ODF lacks macro support, Microsoft would have to ask to change the format. As Sun is the predominant player in ODF (afaik) development Microsoft probably wanted to stay away from that format as Sun has previously been quite hostile to MS.



  • @Lingerance said:

    style="page-break-before: always", what features specifically?

    Hmm, didn't know HTML could have pages too. Anyway, I don't see support for page headers. And, some features that are in Word, but not in HTML that come to mind: miscellaneous font properties (custom underlining, animation,..), hyphenation, tabulation, vector graphics, macros (you said it!), style inheritance, and probably more (it's not like Word is feature deficient). Really, Word documents are "paper" documents, while HTML pages are for the Web, so I don't think saving the former as the latter, or editing the latter as the former is worth it (Word-generated HTML = ugh). (And CSS appeared later than Word 95.)

    Of course, the real WTFreason for MS not to make Word save HTML was that they didn't want an open format at all. Sigh.



  • @ZiggyFish said:

    Just wondering what you guys think about OOXML and weather it should be an ISO standard? 

     

    No. OOXML's specification is 6000+ pages, and basically boils down to "use all the XML you want, but for the important bits, you'll have to embed it as CDATA and in whatever proprietary binary format Microsoft Product <insert name here> uses". In other words, OOXML is a hideously overcomplicated and underspecified format that uses 6000 pages to try and hide the fact that it boils down to "embed your .doc|.xls|.ppt|.mdb as CDATA in an XML wrapper."

    It is also mutually inconsistent - there's about 3 different date format specifications. If you're writing a spreadsheet, you have to dump the dates in Excel mode, and OOXML requires you be bug-compatible with Excel, so there's all kinds of ugly stuff with leap years and epochs (Excel uses 2 different epochs, so it can be bug-compatible with Lotus 1-2-3). Word uses a different date format, and the rest of Office yet another. If M$ was truly trying to make an "Open" standard, they'd just say "Dates to be stored in ISO 8601", and then hack in some translators in Office 2007 to convert between its various buggy implementations.

    Style data in Word files must also be stored in binary-only format, and this format is not provided in the OOXML docs. To properly read/write OOXML files, you have to look up Word's binary formats, and those are NOT provided by Microsoft unless you shell out big $$$ for them. Same with bullets. Using just the OOXML spec, you can't determine what bullet types/style to use, as the docs just say "As specified by Word 97".

    An ISO specification should be complete and consistent. Using nothing but the spec, and any other ISO specs it refers to, you should be able to create a complete implementation of whatever it describes (ignoring patent licensing and whatnot. ISO specs are open, but the tech they describe may be encumbered). OOXML fails this on every possible level.

    I'm not saying ODF is any better. I'm just saying that OOXML is par-for-Microsoft-course. Buzzword compliant to make it sound impressive to ignorant politicos, and a legal morass making it impossible for anyone bug Microsoft to be able to actually implement it. 



  • My gut tells me the OOXML spec was meant to be an internal specification for the Office developers and MS just released it because of the various anti-trust lawsuits.  

    Should OOXML be an ISO standard? No, I don't think so.  Should there even be an ISO Standard for office suite applications? No, I don't thinks so either. 

    In the CAD realm, one of the standard formats is IGES but more often than not, the import into the destination requires significant rework to fix.  I often found it easier to just redo the geometry in the destination software.  IGES has been around since early 80's and it is still broken because we are constantly adding functionality. 

    Standards are seen as this great panacea for system interoperability and they would be if we required that they cannot be deviated from.  The unfortunate side-effect of doing that is we limit the adoption of newer functionality since we can't break "The Standard".  Standards are great for low-level mature features, but suck for anything remotely complicated or creative in nature.




  • @MarcB said:

    you have to look up Word's binary formats, and those are NOT provided by Microsoft unless you shell out big $$$ for them

    http://www.microsoft.com/interop/docs/officebinaryformats.mspx ;)



  • <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 2.3 (Linux)">
    <style type="text/css">
    <!--​
    	@page { margin: 2cm }
    	P { margin-bottom: 0.21cm }
    -->
    </style>
    

    @lpope187 said:

    Should there even be an ISO Standard for office suite applications? No, I don't thinks so either.

    So how do we exchange documents? and keep these documnts oppenable, moreover with an open standard, I can read a document years after support for that the format has disipated. I can create an application to read to the standard format.

    @lpope187 said:

    Standards are seen as this great panacea for system interoperability and they would be if we required that they cannot be deviated from. The unfortunate side-effect of doing that is we limit the adoption of newer functionality since we can't break "The Standard". Standards are great for low-level mature features, but suck for anything remotely complicated or creative in nature.

    I use to think this, but standards create a minum platform for which inovation can thive, moreover a program can implement the standard, but still create non-standard features.

    @Spectre: The standardisation of a patented, incomplete and vague standard actually hurts the IT industry, not only because the standard body has allowed such a thing, but also allows one company to control who implements it.

    @Lingerance: The ODF does support Macros, but doesn't specify what language these macros are in. But this i think is good, because, average document interchange(i.e legal documents, office records, and online documentation) doesn't need macro support (which solves the Word macro virus problem), but still allows you to create a macro language inside that format (which allows for better interopability with the operating system).

    @mfah: Although they have published the other documents relating to the incomplete spec(OOXML), they still have patents that hinder their implementation. So really you get to see there documentation (which make microsoft look like there are for opensource), but can't implement it (but really setting a trap for micrsoft to kill opensource(and we all know steve ballmer thoughts on opensource)).


    @MarcB: Your 100% correct.

    As for my thoughts on OOXML:

    I think that OOXML was produced to compete with ODF. And as Microsoft usually tries to lock people in, their've create a patented, incomplete and vague standard.



  • @Lingerance said:

    As I understand it, ODF lacks macro support, Microsoft would have to ask to change the format. As Sun is the predominant player in ODF (afaik) development Microsoft probably wanted to stay away from that format as Sun has previously been quite hostile to MS.
     

    Times up on my last post to edit, but I just came across this article. Which discusses the problems with OOXML's Macros.




  • @ZiggyFish said:

    As for my thoughts on OOXML:

    I think that OOXML was produced to compete with ODF. And as Microsoft usually tries to lock people in, their've create a patented, incomplete and vague standard.

     

    Agreed.  It strikes me as their classic "embrace and extend" strategy, only this time they're creating the standard that they plan to extend -- which makes much easier to extend. 



  • @bstorer said:

    @ZiggyFish said:

    As for my thoughts on OOXML:

    I think that OOXML was produced to compete with ODF. And as Microsoft usually tries to lock people in, their've create a patented, incomplete and vague standard.

     

    Agreed.  It strikes me as their classic "embrace and extend" strategy, only this time they're creating the standard that they plan to extend -- which makes much easier to extend. 

     

    Obviously not, it the classic "buy and conquer" strategy, but in this case it's reinvent, buy and conquer.



  • @mfah said:

    http://www.microsoft.com/interop/docs/officebinaryformats.mspx ;)
     

    Yes, but those are covered by their "Open Specification Promise", which is basically a load of garbage that says "we won't sue you unless whatever you build with this starts looking like competition for Office".

    If you can't take the specs and do what you want with them, it's not "open".

    Anyone implementing OOXML is entering a legal minefield where the mine density exceeds 100%.



  • I would think that anyone interested in what we think would be able to find the other threads on this site on this topic, but alas, most things from 2007 or earlier are no longer indexed.

    MarcB seems content to give the same rant each time and does not tire of it.

    BTW, I'm not trying to make fun of you, MarcB.  I'm actually glad you've made your point so clearly again, because of the aforementioned un-indexed-ness of the pre-2008 threads.



  • My main worry is MS's strong-arm tactics in getting OOXML accepted. As was widely reported a few months ago, the ISO Document Standard committee business ground to a halt due to the non-participation of all the members that upgraded their status simply in order to vote on the OOXML issue. Digging deeper, one finds that without exception, all of those members are dominated by MS "partners", most of whom again joined their respective commitees in the last few months.



  • @ZiggyFish said:

    @lpope187 said:

    Should there even be an ISO Standard for office suite applications? No, I don't thinks so either.

    So how do we exchange documents? and keep these documnts oppenable, moreover with an open standard, I can read a document years after support for that the format has disipated. I can create an application to read to the standard format.

    Easy, require both parties to have the same version of said program.  Actually, it depends on the level of collaboration and host of other variables.  The short version, if you need anything more complicated than email a document to party b and have them email back some comments, you're probably using the wrong tool anyways.  There are tons of collaboration tools out on the market today that can provide better data integrity, better security, be workflow/role managed and domain specific.  If there isn't a domain specific tool for the job, than roll you own might be in order.  Office applications were designed for personal productivity not enterprise / intercompany collaboration.  The truth is, office applications provide end-users too much control to effectively guarantee interoperability especially since the two recieving parties are most likely end-users and they aren't the most understanding when things don't work 100% of the time.  

    @ZiggyFish said:

    @lpope187 said:

    Standards are seen as this great panacea for system interoperability and they would be if we required that they cannot be deviated from. The unfortunate side-effect of doing that is we limit the adoption of newer functionality since we can't break "The Standard". Standards are great for low-level mature features, but suck for anything remotely complicated or creative in nature.

    I use to think this, but standards create a minum platform for which inovation can thive, moreover a program can implement the standard, but still create non-standard features.

    Standards provide a minimum spec for a feature set or interface, that's all.  In and of themselves standards do not promote innovation, innovation is driven by unfulfilled demand either for expanded functionality or reduced cost.  More often than not, significant innovation comes about by throwing out the standards and looking at the problem from an entirely new perspective. 

    Standards are very good for decoupled functions or mature business processes.  Examples would be networking protocols or invoicing transactions.  In a simple sense, networking just needs to pass a payload of data to another piece of software.  It really doesn't need to care or know about the contents of the payload. So you can define and implement a standard effectively because its impact is so limited.  Invoicing transactions on the other hand, have been scrutinized over the past 50 years and we've found the minimum set of data that needs to be passed.  EDI does this very well and conforming to the standard will work, but more often than not you need to deviate for whatever reason.  

    Not all processes or features exhibit these conditions.  I'm certainly not saying we shouldn't have any standards at all.  What I'm saying is that standards have baggage, so we need to be careful when we define, implement and continue to use them.




  • @ZiggyFish said:

    Just wondering what you guys think about OOXML and weather it should be an ISO standard? 
     

    Figured I'd tag this onto the convo - just got posted on Groklaw today.

    Basically it boils down to:

    1. Microsoft's "we won't sue" promise only covers FULLY compliant implementations of OOXML. If you forget to cross a T or dot an I somewhere in your code and don't implement something properly, Microsoft can sue you.
    2. OOXML is supposedly the official and final specification of Office 2007's file formats
    3. Office 2007 produces files which are not compliant with OOXML by default. '07's files are a derivative of OOXML, but they are NOT OOXML.
    4. Face it, anyone who's trying to create an OOXML parser is doing so to interoperate with Office and Office users.
    5. Since you're trying to comply with what Office '07 spits out, you cannot by definition comply with the OOXML specs, which leaves you in violation of Microsoft "we won't sue" promise.

Log in to reply