The Standards Blog

The Contradictory Nature of OOXML

Wednesday, January 17th, 2007 @ 02:57 PM EST
Contributed by: Andy Updegrove
Views: 49,639

OpenDocument and OOXML

Regular readers will be aware that OOXML, the Microsoft Office XML-based formats adopted by Ecma, are now in the adoption queue at ISO/IEC.  Ecma is a "Class A Liaison" partner with ISO/IEC, which permits it to use the same Fast Track process that national standards bodies use.  That process takes six months -  the same amount of time that the PAS process takes (the route used by OASIS to submit ODF to ISO/IEC) – but has two steps rather than one, although the practical result is much the same.

During the first one-month step, any member may submit "contradictions," which, loosely defined, means aspects in which a proposed standard conflicts with already adopted ISO/IEC standards and Directives.  Those contradictions must then be "resolved" (which does not necessarily mean eliminated), and these resolutions are then presented back to the members during the second stage to consider as part of the voting package.  During this second, five-month step, other objections, questions and comments can be offered by members. (For more detail on the rules relating to contradictions and what can be raised during this phase, see the excellent writeup at the OpenDocument Fellowship site.)

While the unprecedented size of OOXML (over 6,000 pages) has made performing a detailed review a daunting task, more and more contradictions are being found by those that are slogging their way through on this very tight timeframe.  Here is a sampling of those that people have brought to my attention:

Starting with the somewhat silly, OOXML does not conform to ISO 8601:2004 "Representation of Dates and Times."  Instead, OOXML section 3.17.4.1, "Date Representation," on page 3305, requires that implementations replicate a Microsoft bug that dictates that 1900 is a leap year, which in fact it isn't.  Similarly, in order to comply with OOXML, your product would be required to use the WEEKDAY() spreadsheet function, and therefore assign incorrect dates to some days of the week, and also miscalculate the number of days between certain dates.

 

More substantively in the contradiction department, OOXML does not follow ISO 639 "Codes for the Representation of Names and Languages."  That standard defines a list of codes that are maintained by a Registration Authority charged with keeping the list current as ethno-linguistic changes evolve.  Instead, section 2.18.52, "ST_LangCode (Two Digit Hexadecimal Language Code)" (page 2531) says that you must use a fixed list of numeric language codes rather than the already existing set that provide for interoperability among other standards-compliant products – a not unimportant factor in a text standard.

Updated 9-29-07: Peter Constable, the Project Editor of ISO 639-3, contacted me to say that the statement above is inaccurate, stating in part that OOXML, "happens also to allow for a set of integer identifiers defined by Microsoft, provided for backward compatibility with existing documents, but that does not contradict its usage of ISO 639," and requesting that I correct the record. I then checked with my original source, who responded as follows:
I'd direct Mr. Constable to DIS 29500, Part 4, Section 2.16.5.35 (page 1540). The definition of the "/z" field argument says "The text in this switch's field-argument is specifies the language ID used to generate the index as defined in the ST_LangCode (§2.18.52) simple type." If he further references 2.18.52 he will see that ST_LangCode in no way uses ISO 639 language codes. However, it should be noted that there are other sections in OOXML where ISO 639 codes are allowed, but as the above example demonstrates, there is at least one place where OOXML permits only the non-standard Microsoft codes, in contradiction of the existing ISO standard for language codes.

It therefore appears that my statement was both right and wrong on this point, and that OOXML is both compliant in some sections, but not compliant in at least one section. End Update

Similarly, 6.2.3.17 "Embedded Object Alternate Image Requests Types (page 5679) and section 6.4.3.1 "Clipboard Format Types" (page 5738) refer back to Windows Metafiles or Enhanced Metafiles – each of which are proprietary formats that have hard-coded dependencies on the Windows operating system itself.  OOXML should instead have referenced ISO/IEC 8632 "Computer Graphics Metafile" – a platform neutral standard.

Taking the external reference issue further, I'm told that parts of OOXML can't be implemented by your typical programmer at all without technical assistance from Microsoft, as they refer not only to proprietary Microsoft products, but to undocumented parts of them as well – which violates the General Principles of ISO/IEC Directives, Part 2.  Consider the following, from section 2.15.3.26 (page 2199):

2.15.3.26 footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.x/95/97) when determining the placement of the contents of footnotes relative to the page on which the footnote reference occurs. This emulation typically involves some and/or all of the footnote being inappropriately placed on the page following the footnote reference.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.

[Example: Consider a WordprocessingML document with a series of footnotes.

If this compatibility setting is turned on:

Then applications should mimic the behavior of Microsoft Word 6.x/95/97 when determining the placement of those footnotes on the displayed page, as needed. end example]

Other parts of OOXML refer to OLE, macros/scripts, encryption and DRM – none of which are fully described.  Nor has Microsoft stated whether necessary information will be supplied on a non-discriminatory basis to all (or at all).

And taking that concern a step further, consider the fact that OOXML also apparently violates section 2.14 of the ISO/IEC Directives, Part 1, in that not all of what it takes to implement OOXML appears to be covered by Microsoft's patent pledge, in two respects.

First, the pledge does not explicitly cover material that is referenced, but not included in the specification, and second, the Microsoft patent commitment does not cover optional features.   Sections of OOXML that are not fully described include those that require compliant implementations to mimic the behavior of Microsoft products, such as those products and capabilities referred to above (OLE, etc.)  Microsoft will need to clarify whether its patent commitment will in fact extend to these requirements.  Potentially, these concerns would involve large portions of OOXML, in contradiction of the ISO/IEC requirement that more than a bare-bones implementation must be permitted without fear of infringement.

All in all, as the waitress in the Monty Python vignette would doubtless have observed (if contradictions were rats), "Rather a lot, actually."  

As the February 5 deadline for report ing contradictions approaches, I expect that you'll be hearing of many more examples such as these.  Eventually, they will all become publicly available, along with the proposed resolutions.  Some, such as the patent pledge ambiguities, are clearly addressable by Microsoft if it wishes to address them.

Other contradictions would seem to be impossible to resolve given the nature of OOXML itself, the stated purpose of which is to describe a single vendor's product – bugs, rats and all.

Updated: Pamela Jones and her crew have set up two very impressive pages at Groklaw, in Wiki format. The first allows interested parties to find and log in contradictions and objections, while the second tracks the ISO/IEC process. Pamela's own detailed writeup can be found here.

For further blog entries on ODF, click here

subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff's)

Comments

Submitted by Anonymous on Tue, 12/13/2016 - 00:26

Permalink
A serious question: is there any practical point in finding and publicizing all of the bad things in OOXML?  (and there are some things, such as those you mentioned in this post, that any real standards organization would never have allowed)  What are you trying to accomplish?

Those that support OOXML do so for political reasons, not for technical reasons.  Those that support ODF do so mostly for political reasons, not technical reasons.  Thus, the technical merit of either spec is largely irrelevant,.

--- Swashbuckler


Here's a (hopefully) serious answer. It might even be right!

First, I take issue with your oversimplification that it's all politics and no technology. Obviously there is political motivation involved on both sides, but there are more important things to be considered.

ODF is a format which was developed to be a truly open standard that anyone could implement. When Massachusetts decided to go with ODF, the logic was simple; they wanted someone 100 years from now to be able to create a program (or whatever it'll be called then) from scratch that can open and display a document that had been archived. This is not a trivial issue.

Massive amounts of information (including census data, I believe) is literally rotting into oblivion. The old magnetic tapes are deteriorating, and no computer of any kind exists that can read those tapes, much less do anything with what's on there. Governments, particularly, deal in decades and centuries, not quarters and years. ODF is an attempt to avoid the mistakes of the past going forward.

OOXML, by all accounts I have read (which is a lot), is an attempt by Microsoft to legitimize its own proprietary format as an alternative standard. I cannot see ANY way that this mess could be the basis of a long-term open standard by which someone 100 years from now could create a program from scratch to open OOXML documents. The information presented here (and in other places) demonstrates that the specification as submitted could not be used to create a working program from scratch on any platform (even Microsoft Windows!), today or 100 years from now. It is widely regarded (and I believe correctly) that the sole purpose of trying to get OOXML established as an ISO standard is for short-term (as in the next few years) marketing purposes by Microsoft.

I will further submit that if your argument has no more depth than what you have said, then you, sir or madam, are a troll. Hie thee back under thy bridge!!!!!!!

Weeble

I think the problem I have, and likely Microsoft as well, is that there are literally Millions of existing documents with varying kinds of formatting that need to be converted to any long term storage format for the idea to even hold any water.  It doesn't really help if only new documents can be accurately represented by the format.  There are varying degrees of accuracy in conversion from legacy office format files to ODF, but in my experience, all but the most basic kinds of documents fail spectacularly in the process and need some kind of touch-up.  It gets even worse when you need to represent the document as it was originally created for legal or artistic reasons.

What I think Microsoft needs to do is restructure OOXML to provide for legacy formatting, but leaving a core sane format.  Some might argue that this format should be ODF, but I can already see everyone and their dog accusing Microsoft of "embrace, extend, extinguish" tactics if they did so.  They could even be sued on anti-trust grounds for doing so.

The fact that there are already millions of documents that need to be represented by an open format alone is enough to justify an ISO standard for such documents. 

You have to distinguish between a standard and an import filter for legacy formats. As only Microsoft has the original code, they are the only ones that can convert all the legacy documents into any new format. However, it is totally rediculous to include all (or even any of) these undocumented formats into this new format. Legacy formats must be converted, not preserved.

<i>You have to distinguish between a standard and an import filter for legacy formats.</i>

Exactly.

All the crap about bugs in previous versions of the applications should have been corrected as a part of the import process, not propagated for all time.


--- Swashbuckler

I would add that while a tool to convert legacy documents into a format for going forward is a good thing, since Microsoft is the only company who has the knowledge to do that (adequate knowledge is not in the spec), there's no need for it to be an ISO standard. How can something be a useful standard if only one company has the knowledge (proprietary, no less) to implement it?

P.S. I would be more persuadable if Microsoft released a basic, free (as in beer and as in speech), open-source, cross-platform capable (standard languages, not requiring MS programming tools) editing program for manipulating OOXML files, capable of accurately importing any and all of the formats referenced in the OOXML specification, allowing manual and/or automatic correction of import errors, and capable of accurately exporting a "clean" OOXML file.  Better yet, a "clean" OOXML or ODF file, demonstrating a true commitment to interoperability.  The program's source code would be appended to the ISO application as a working example of how to implement the proposed standard.

However, I cannot see that occurring under the present management of Microsoft.

The think you mentioned, millions of documents are there now in M$ way documents it is true. But it all make M$. It is their policy, and it is pretty bad

They made it bad and want you to pay for it every year.

If you have document in latex, pdf, ... You can see it and work on it today, like 10, 20 years before. If you have something in M$ oficcee version 3.1415 you are in trouble.

When I was in university, I remember one mathematician, who said ouch, I have to have Word 2.0, 3.0, 4.0, 5.0, and some more minor releases, if I want to read papers from my colleagues.

In 100 years you have to have aproximately 60-70 releases of various M$ office packages, if you want to read documents. If you write doc in latex, pdf, odf(hopefully|, you'll still need one software for reading it, as you do 100 years before.

I'm familiar with all of that, however that's not the real reason that people support ODF.

It's like the invasion of Iraq, the Bush administration claimed there were WMD, they wanted to free the Iraqi people, spread democracy, etc.  But the real reason they went in is because they wanted to get rid of Saddam.

Same kind of thing here.  Just because something has a benefit, doesn't mean it's a reason something was done.


--- Swashbuckler


Swashbuckler, I readily grant you that there are those who support ODF partially, or even primarily as an extension of  their dislike of Microsoft and would have no qualms about firing all of the senior management there or even dismantling the company if they had the power to do so. I have been a Microsoft watcher since the late '80's (not long after I got into PCs in the first place) and believe that if Microsoft were shut down today, the world of computing would be better off (except for the short-term mayhem).

And there are good reasons for taking that stance. From its earliest days, Microsoft (then Micro-soft) has built and maintained its business by cheating, stealing other people's ideas (has Microsoft REALLY been innovative other than in creating "Microsoft Bob"?), using its market power in an extremely predatory manner (established as fact in U.S. v. Microsoft), undermining competitors with false claims of products that showed up far late if at all (i.e., vaporware) as well as with subtle half-truths and lies commonly known as FUD, protecting the slop it calls software via vendor lock-in, and the list goes on and on.

Some do promote ODF/open source/FOSS/Linux/etc. partly or primarily because they detest Microsoft. However, from what I've seen (and I've seen a lot), most do so out of altruism, desiring to better their world, and from a desire to "build a better mousetrap". This is specifically so with ODF.

Please, sir, if Microsoft's desire to promote their proprietary OOXML format by seeking ISO certification based on a half-baked document that enables no one but themselves to implement it (because only they can fill in the blanks) is based on altruism, desiring to better their world and/or a desire to build a better mousetrap, where is the evidence of this?

All I have seen in your posts so far are half-truths, innuendo and ad hominem arguments. I challenge you to provide some fact-based arguments that ODF is being promoted primarily because of a vendetta against Microsoft (as opposed to the altruistic motives mentioned above) or else admit you are a troll AND GET YOURSELF  BACK UNDER YOUR BRIDGE!



Those who support ODF may do so for technical and/or political reasons.... but, in many cases, the political aspects of ODF support have to do with fighting for the technically better solution.

Whether your reasons for supporting ODF or OOXML are technical or political, there are a number of technical (and possibly also political) reasons for looking for the flaws in this proposed standard:

  • If improvements to OOXML are to be made, then they should be done before, not after it is accepted as a standard. It is far easier to modify a standard (especially major changes) before it is accepted than after.
  • If (as you seem to imply) you think that the problems with OOXML are so many and so serious that OOXML should never even be considered for a standard, then you can't just go to the ISO board and say "I hate it, and I think it should be rejected".
    You're going to get a far better listening  if you say "It has these M minor problems, these N serious problems, and these K probably insurmountable and structural problems, and I think that these flaws are so serious that OOXML should be completely rejected."
  • If you like OOXML, and you want it to be accepted, then you really want to know what the problems with it are now so that you can address them, rather than being blindsided by them 6 months down the road, when there's even less time to address these issues.
  • I agree with you that the main resons for supporting OOXML as an ISO standard (as opposed to just resigning yourself to it's existense) are political. In my rather brief view of it, it seems to me that OOXML may be a case of Microsoft just throwning XML around an inherited hash of sometimes ancient and undocumented binary blobs so that they can assign the tag 'XML' to it for marketing reasons. SImilarly, Microsoft's push to designate OOXML a 'standard' seems to be more for political than technical reasons.
    As many people have pointed out -- despite being a massive 6000 page document, the OOXML proposed standard doesn't actually have enough information for anybody (other than Microsoft) to implement it -- and what's value of a 'standard' that only one entity can implement?
  • On the other hand, many of the people who prefer ODF to OOXML prefer it because it actually works as a document interchange standard. People were working on ODF long before they thought of proposing it as a document interchange format standard.
  • The political aspects of supporting ODF as a standard mostly come from the fact that Microsoft has politicized the arena in the context of trying to get OOXML accepted as a competing (pseudo) standard. It is only in that  context that supporting the technologically superior interchange format may become a political statement.

I'm replying late to your questions (my apologies), and I think that those who have already replied have covered the ground pretty nicely.  Here are a few more thoughts around the edges.

First, the fact that ODF can (and actually has) been implemented in many products means that its a lot more likely that documents will stay available over time - in part because more developers will have motivations to support it than OOXML.  And many other good things will follow as well, such as choice, price and feature competition, and so on.  None of that will happen with OOXML, which is more like a more open (but not completely open) toolkit for a single product than a standard.

On another point, there's no question that the genesis, and much of the current support, for ODF was and is "political" in the commerical sense (if that's what you meant) in that the core came from Sun, and the standard is being pushed as hard as possible by vendors (most notably IBM and Sun) for commercial advantage.  But it's also true that ODF has a large and growing following of open source developers and customers, which are not motivated by politics, or at least by the same type of politics.

In that sense, you could anlogize loosely to Linux, which points back to UNIX - a commercial product.  Linux is, of course, beloved by open source developers and customers alike, while at the same time being pushed hard by commercial vendors for the traditional profit and competitive reasons.

  -  Andy

The politics I was referring to was being pro or anti Microsoft.

Some will support Microsoft in (nearly) anything they do because Microsoft did it and their fortunes depend upon Microsoft.  Some will oppose Microsoft in literally anything they do because they dislike Microsoft for any variety of reasons.

Do you believe that any company or open source project is going to chose to support or not support OOXML based on the technical merits of OOXML?  I don't.  If Microsoft hadn't put all the stupid requirements to replicate bugs from previous versions of Office into OOXML would that have affected the decision of any company or project?  I don't think so.  Thus, while the stupid stuff in OOXML is interesting, pointing it out seems to serve no practical purpose; it merely allows those that oppose OOXML to say "See, I told you!"

You can't even use this to really slam ECMA, as it has long been known as a rubberstamp "standards" organization.  I had some involvement in a couple of ECMA efforts ten years ago, and that was the case then and it's still the case today.


--- Swashbuckler

All the half (or less) documented garbage in the present OOXML standard is enough for it to shoot its own self in the foot.

OOXML is NOT a document format for going forward. Rather, it is a document format intended to reach back to the past and carry it along. That's a recipe for disaster, not for a standard. Such a format could only become more and more bloated as it has to support more and more emulated characteristics.

Maybe I'm dumb, but an office package that costs as much as Microsoft Office does should, when importing a document, be able to translate the document into its own terms rather than simply emulate characteristics of the old format. And when the document is saved in the new format, all of the characteristics should be in terms of the new format. It has been a surprise to me to learn that the older MS Office formats didn't do that. If they can't or won't do the work to translate a document's characteristics into those of the new format, the default should have been to save it back in its existing format.

Even if I *wasn't* of such a strong negative opinion about Microsoft, I'd still think this is a stupid way to run a railroad. Or a software company.

On the other hand, reading the contradictory statements is rather faster than reading the whole proposed standard. Having then published and or summarised elsewhere (than ISO) is good.

I, for one, do not have the time to read the standard, and do the research that will show me how much in deep trouble I could be if I moved my documents to OOXML. Note that it does not matter if I would actually consider doing it or not: it is obvious that this is a political fight, but even political fights can be won by public pressure (and, alas, note again that public pressure can win the "right" fight, or the wrong one).

ISO is, as any other organisation, a political beast, and will sometimes react to political rather than technical merits.

Submitted by Anonymous on Tue, 12/13/2016 - 00:26

Permalink
Wrong. OOXML is supported for commercial, not political, reasons, and ODF is supported by anyone who wants interchangeable and lasting documents, as it is technically good and the only standard.


Submitted by darkonc on Tue, 12/13/2016 - 00:26

Permalink
Microsoft's description of these 'blobs' seems to imply that they expect the implementor to effectively reverse-engineer Word/97 and other 'legacy' versions of MS Works, MS Word and other MS Office products. It's been a while since I read the EULAs for those products, but I'm betting that some (if not all) of them claim to prohibit such reverse engineering.  In venues that claim to legitimize shrink-wrap licenses, this means that -- even if Microsoft were to grant the necessary patent rights needed to implement those blobs, an implementor might find themself embroiled in a legal fight with Microsoft as to whether or not the information necessary to complete the information was gained legally.

In other words, if Microsoft doesn't fill in the blanks for these proprietary and/or legacy blobs, an implementor might find, in addition to the technical problems, not one -- but two -- legal hurdles should they ever succeed at implementing OOXML.        

Submitted by Anonymous on Tue, 12/13/2016 - 00:26

Permalink
OOXML seems a bit like EBCDIC (a single-vendor standard really intended for use with punch-cards), playing opposite ISO ODF XML being like ASCII (American Standard Code for ..., a vendor-neutral standard really intended for use with paper tape).

It's good that Microsoft have finally coughed up a description, it may well take 50 years to work its way out of the 'system', just as ASCII-based representations are slowly pushing EBCDIC-based representations out. Punch cards and paper tape are both long gone, but we still need some way of agreeing what the zeros and ones in our computers mean.

But there should be no need for ISO to bless a single-vendor standard.

Submitted by Anonymous on Tue, 12/13/2016 - 00:26

Permalink
&lt;p&gt;Andy,&lt;p&gt;<br>Just how does one find out who is the 'national standards body' is for any given country and equally important, how to contact them?&lt;p&gt;<br>Presumably for the US, the National Bureau of Standards {?} is the correct body. But then who to contact? Actually, I think they're now the National Institute of Standards and Technology. {www.nist.gov}&lt;p&gt;<br><br>

Submitted by Anonymous on Tue, 12/13/2016 - 00:26

Permalink
OpenDocumentFellowship has a document that defines what a standards "contradiction" is. That's important, because specifications aren't supposed to enter the fast track if there's a serious contradiction.

And this case, there are lots of massive, fatal contradictions that should immediately derail the "fast track" (and really, the whole specification). Let's look at the possible reasons for a contradiction:

  1. confusion of users: Users may be confused by the "term 'open'"; users might think it means that the specification represents some sort of industry consensus, or a specification that is widely implemented by many suppliers, or one with fully open IPR (e.g., so partial implementations and later versions are unencumbered). This is not true. For example, there doesn't seem to be a legal way for others to fully implement it (due copyright on material like graphics borders and EULAs forbidding reverse engineering for inadequately specified pieces). This specification does not meet many of the common definitions of the term "open standard". Users may also confuse the specification with OpenOffice.org, a product that implements OpenDocument instead.
  2. damage to ISO reputation: If it accepts this specification, ISO will be tarred as an organization that can be controlled by any single powerful company, instead of one that strives for broad industry consensus and protection of users' interests. Look at the precedent this sets - if ISO accepts this specification, it means that a rich company can overturn any existing standard (e.g., OpenDocument) simply by buying off a standards organization (ECMA) to accept whatever they write. ISO's key value is in its reputation for impartiality, and should not sully such a valuable reputation for such an obvious ploy.
  3. lack of consistency with existing standards: Obviously this isn't consistent with ISO/IEC 26300 (OpenDocument). Which was approved as an ISO standard in 2006, so it's clearly not obsolete. What's worse, it's completely inconsistent with other standards: MathML, SVG, XForms, and so on.
  4. duplication of existing standards: It duplicates OpenDocument. Completely. There's no "different market" for office documentation; it's all the same market. Indeed, the fact that people are working on bidirectional translators shows that they are the same thing. There's no need for yet another standard for the same thing, unless of course you're trying to ensure that a single vendor controls the format of all office documents.
  5. overlap with existing standards: I wish it were just "overlap". This is essentially a complete duplication of an existing standard, for the sole purpose of enriching a single company (at the expense of competition in the marketplace).

Another problem is that the specification, for all its pages, doesn't get to the meat of the specification. You can't really implement it without "secret sauce" information that only Microsoft has. It's a non-specification specification. It's only so long because they had to re-create incompatible specifications for functions that are open standards elsewhere (like MathML and SVG).

This specification is also grossly immature; even if were not a contradiction, it's not ready. It can't be otherwise:

  1. It was developed in a rush - 6000 pages in less than a year (!). In contrast, OpenDocument development began December 16, 2002 and was approved May 1, 2005. And OpenDocument development was much easier, because they reused standards (like SVG and MathML) wherever they could, instead of recreating things from scratch.
  2. Nearly all office application developers were not involved in the ECMA process (for development OR review), for good reasons. After all, nearly all office application suppliers had spent years working to develop a standard; there was no need to do it again (note that the ECMA process only started many months after OpenDocument had been completed). The ECMA process, by charter, was clearly unfair and tilted towards the whim of a single vendor. And technically, because the specification completely redoes from scratch many standards areas (like MathML and SVG), there are many good reasons to avoid implementing this specification.

There's no terrible harm to Microsoft if ISO rejects fast track status, or even the spec outright. Microsoft can implement the industry-developed international ISO standard (OpenDocument) any time it wants to. If there are problems with the standard, they can be addressed through normal standards processes. But allowing a single company to create its own incompatible, essentially proprietary standard will do great harm to the reputation of all standards bodies.

ISO says its goal is "one standard, one test, and one conformity assessment procedure accepted everywhere.” Do they mean it? Or is that a lie, just another empty claim that can be sold to the highest bidder? Is it possible for an industry to work together for many years to develop and implement a standard, and then as the standard begins to be adopted, for a single vendor to write its own incompatible specification and get ISO's endorsement?

We'll see if ISO can really stand for its principles. I hope, and have reason to believe, that ISO can, and reject the fast track request.

(I previously posted this on Groklaw.)


Submitted by Bill Poser on Tue, 12/13/2016 - 00:26

Permalink

The language codes on pp. 2531-2537 of the Open XML spec are said to consist of exactly two hexadecimal digits, yet they range from 1033 to 58380. These are not hexadecimal values and cannot be represented by two hex digits. Am I missing something, or has Microsoft screwed this up?

Submitted by Anonymous on Tue, 12/13/2016 - 00:26

Permalink
Under the fast track process it appears that there is a 1 month (calendar month?) review period, followed by a 5 month voting period. What does this mean in practice? Do the NSBs vote once only? Or can they vote with objections and then alter the vote if they wish? Do they vote at any time during the process or just at end beginning/end? Are the NSBs very political or is it worth trying to influence them by making direct contact? What sort of arguments are likely to be effective? Thanks, felix_the_mac, Groklaw

Submitted by Anonymous on Tue, 12/13/2016 - 00:26

Permalink

What is silly is that you are suggesting one would use a representational date format for use in spreadsheet. You better tell me that Opendocument uses an alternative date format for spreadsheet  or I'll cry.

Also it is pretty clear that the ODF spec allows for ambedding of any arbitrary  filetype whatasoever via xlinks for instance. That mean that you could in theory create an ODF document that consist entirly of an OOXML embeddend document.

The fact that OOXML has the possibility to do OLE embedded linking seems pretty simular.

Simular to ODF you could ignore any embedded objects if there is no support for the format present.

The only thing you can say is that OLE embedded links will be not be very crossplatform but it does not require any embedded format to be part of the format just as ODF does not have any possible embedded format in it's spec.

ODF specification

paragraph 9.3.5 Plugins

A plugin is a binary object that is plugged into a document to represent a media-type that usually is not handled natively by office application software.

Is that not the same that happens with OLE embedded objects. 

Mayby you should retitle the article the contradictory nature of both OOXML AND OpenDocument ?????