Rumours trickly out about the OpenXML contradiction issues

by Rick Jelliffe

(NOTE: Since this blog, Computerworld published Ecma's fulll Contradiction Response which includes summaries of the national bodies' substantive comments. Here is an updated table with positions as apparent from the Ecma responses. I count 7 rather than 8 actual claims of contradictions, but many of the national bodies recommend shifting OOXML into some SC34-based review.)


Here's the latest on the rumoured positions taken by the national standards bodies that are full participating members of ISO/IEC JTC1 (P Countries). We'll know more over the next few weeks as material comes online. I've summarized things in a following table as best as I can make them out, but (apart from Australia's comments which I have seen) I'm not too confident in my source, another website.

The responses have two aspects. First there are responses connected to the amount of time available to check for contradictions. Now this is really an ISO procedural matter, and, as I have mentioned before, in effect national bodies get much less than the 30 days to check for contradictions: really it is as little as a week. But it doesn't matter, because the national vote comes up anyway: as I've said before, the contradiction period is a coarse sieve for big issues. At least seven of the thirty national bodies from P Countries have made remarks concerning the time period. I expect JTC1's answer will be: if this is important, raise this at JTC1 committee.

So second are responses on contradiction proper. It seems that eight (update: 7) of the thirty P Countries have raised issues on contradiction. Another four have passed on issues without necessarily claiming contradiction (in some cases because their procedural comment is that they are not clear on what a contradiction entails.) This is a big number, but given the controversy it is not surprising, and getting the important issues discussed sooner rather than later is in everyone's interest.

While some of the technical claims are silly (such as the bitmask rubbish) and can be resolved fast, there is an interesting procedural problem: traditionally, when there is some market need for different technologies or approaches to address the same goal, they just get made different parts of the same standard, which lets ISO pretend there is only one standard but actually to allow internal competition under the same number. But that approach is hardly possible for fast-tracked standards, since they come in from different organizations.

Apparantly Ecma has prepared responses, which will be sent to JTC1. Clearly they need to make the case better why OOXML is different from ODF and why there is a market requirement for it (and perhaps why ODF will not be mature fast enough to be usable: fast-track is supposed to be used when there is some aspect of timing where the market requires something fast.) Assuming OOXML survives this round, Ecma only will need to convince one or two countries not to vote "no" and try to get enough of the others to vote "yes". (8/30 negative is the magic number for preventing a standard IIRC.) I suspect a name change for the proposed standard and some better word-smithing of the scope paragraphs would go a long way to resolve matters.

31 Comments

orlando
2007-03-02 09:38:01
tough one from Finland:


"The specification contains within it complete specifications of two different vector graphics languages (VML and DrawingML), a complete specification for the representation of mathematical equations (OOMML), a complete specification for a schema evolution language (Markup Compatability ML) and a complete bibibliographic citation language, in addition to others. We know from analogous standards produced by the W3C, such as SVG and MathML, that the development and review of even a single one of these sub specifications would require an expert group 2-3 years. But Ecma, in a process that did not receive much public visibility, produced a specification that includes all of these, and their review and approval cycle took less than one year."


( source: http://www.computerworld.com/pdfs/Ecma.pdf )

hAl
2007-03-02 14:29:33
I found a link to the full contradictons plus Ecma answer here:
http://ooxmlhoaxes.blogspot.com/
hAl
2007-03-02 14:43:42
never mind, I see it is the sme link as orlando mentioned.


As for that Finnish reaction. The advantage of a fastracked standard means that it does contains already in use technology. As MS Office has already been using OOXML and it's predessor formats since august 2000 (Office XP beta) it does not require the same two to three years scrutiny the Finnish reaction suggests. And VML is actually an old deprecated part of the standard. There is no need to scrutinise it as the only use is for existing documents where it is already in.


But the Finnish suggestion is an interesting point as ODF is creating a completly NEW formula's standard for ODF.
That is pretty complex to if not more complex then a vector standard.
If it takes an expert group to do two three years for creating that formula's standard and then adding it into the OASIS and ISO standard takes up to 12 months as well then it wil leave ISO ODF without formula's for two to three or even 4 years more to come ????

Rick Jelliffe
2007-03-02 15:43:17
Orlando, hAl: Thanks for the links, I'll go and read them after this response. On the face of it, the Finnish comment is rather strange, because of the reasons hAl mentions. The trouble is that OpenXML is documenting an existing mature product which has had some XML bindings for five years (e.g. the spreadsheet language); of course MS has had internal and external documentation (e.g. the RTF documentation), so the development is not a point. To compare it with a new language spec developed from scratch misses the point, I think; now certainly a thorough review would take more time, perhaps years, but that is the point of fast track, that the technical issues have been sorted out previously by the proposing body: so the review at ISO and national bodies is not the kind of review that contributes towards development, but merely the kind of review that ascertains what the strengths and weaknesses of the technology are and whether the spec is up to scratch in its housekeeping details (and, along the way, to find and pass back any corrections).


What is funny is that for years there has been a vocal group, such as Tim Bray from Sun, who have been saying that you should only standardize pre-existing technologies that are implemented and mature in the market place. No speculative technologies or light-bulb. And yet when Ecma does it, those voices are silent and you get comments like this Finnish one where it is actually a bad thing!

Josh Peters
2007-03-02 16:16:08
Why do you think the bitmask issue is rubbish? Bitmasks have little to no place in character-based interchange formats. It's two steps away from having a base64-encoded block of text in the document and calling it open (unless the base64-decoded block has an available specification ala XML Encryption then it's not open).


I think the rubbish came in when someone decided it was okay to take a lazier way out and mix implementation details with the specification.

Rick Jelliffe
2007-03-02 18:15:46
Josh: See my GrokDoc comment for technical details on bitmasks. Actually, I don't see that any national body raised the issue of bitmasks, but the allegations are still up on various anti-OpenXML websites, which to some extent shows that facts are regarded as unimportant detail and nitpicking in some quarters.


There are always rough edges on standards. And there are always legitimate differences of opinions that can never be resolved except by mutual respect and tolerance: some people like camel case, some people like hyphens and long names, some people like easily typable short strings, for example. Whether a standard reserves but does not define some names of keywords is another. I agree that generally bitmasks are ugly and better to avoid in the absense of terseness requirements, but that does not make them nonfunctional or inappropriate.


And yes, there is even a place for bin64 encoded data in XML documents.


Actually, for many years now I have argued that whenever there is a change in (nested) semantic domain, a change in notation may actually increase readability: it is better to have XPaths using non-XML syntax than to try to do them using elements and attributes. This is the "little language"/microformat idea. Using bitmask doesn't matter when it is an optional thing for legacy support, when there are filesize issues, when there is some visual reason or programming reason (i.e. the application of bit masks using logical operators) that makes it attractive, or when it is very rare, for example.


The lack of support for arbitrary notations in XSD also comes from the "all structure in elements" view. Contrast this with, say ISO DTTL (the Datatype library language being developed by ISO SC34 WG1 as a companion to Schematron and RELAX NG) which is intended specifically to help the parsing and validation of arbitrary notations in field values.

Rick Jelliffe
2007-03-02 20:22:57
Also, I think one process improvement at ISO that might be worthwhile would be to allow the appropriate Steering Committee to review the specification during the Fast Track procedure; this would provide extra expertise to help national bodies' own review process on contentious specifications. For example, in the case of OOXML and ODF, it would allow SC34 WG1 to review the specs and criticisms.


The difficulty is that ISO Steering Committee members (and the Secretariats) are often private individuals persuing projects in their expertise, which is why such a review should not be compulsory.

Bruce
2007-03-04 05:55:51
@Rick, on this:


"What is funny is that for years there has been a vocal group, such as Tim Bray from Sun, who have been saying that you should only standardize pre-existing technologies that are implemented and mature in the market place. No speculative technologies or light-bulb. And yet when Ecma does it, those voices are silent and you get comments like this Finnish one where it is actually a bad thing!"


I think your logic is sketchy here. The Finnish comment raises deep and reasonable concerns about overlap with existing international standards (SVG and MathML in particular). To say one should only standardize existing, proven, technologies would also be to say that one should not create new standards where alternatives already exist. Microsoft is of course free to do that, but I don't think ISO ought to be in the business of blessing it.


Full disclosure: I'm on the OASIS ODF TC, where we have a charter requirement to reuse existing standards where possible, rather than to invent new ones.

Rick Jelliffe
2007-03-04 06:19:06
Bruce: Four points.


First, SVG and MathML are not international standards. Just because one International Standard references an external technology it does not make that external technology an ISO standard by proxy.


Second, there is a difference in inventing a brand new markup language and in making an XML binding for an existing implementation or API.


Third, Some of the "new" languages in OpenXML are not new at all: notably the spreadsheet language and VML, which predate ODF. But the other "new" languages are bindings of existing functionality. The Finnish claim would be right if it were both language and semantics that had to be developed ab initio, but in OpenXML's case this is patently not the case!


Fourth, OpenXML does reuse a lot of external specs, such as ISO date formats and Dublin Core. What is your proof that MS did not look at existing formats and found them lacking? Why isn't that just FUD? (Now I am talking about the formats that were usable and ISO standardized three to six years ago when they started their moves to XML and more openness.)

Rick Jelliffe
2007-03-04 08:42:13
Update: Eric Lai has a really good article up at ComputerWorld Any objections? For Open XML standard, yes (still) But Microsoft's baby makes a few new friends in the ISO. He is one of the few computer journalists who seems to really follow the technical and procedural details. He only counts 6 against. (This is still so far from the 19 that the shills put out on the Web a month ago, or the 14 that Updegrove for example finds: they is doesn't make a distinction between comments related to OpenXML contradiction and process commments.)


The French national body has gone as far as posting an explaination of its procedures for voting. What is striking, and quite unusual to my eye, is the mention that stacking meetings with people of one position won't work: it is a consensus committee. This comes on top of the South African comment against excessive lobbeying. I have mentioned before that the standards processes are geared towards win-win rather than win-lose.


What is the difference? Well, in a win-lose system, if you find a flaw then that is a reason to abort the process. In a win-win system, when you find a flaw there is an attempt made to fix it; if there is a misunderstanding, that gets corrected; if there is a current fix, the thing is fixed; sometimes the answer may be "We will have to address that issue in a future version" which is an approach ODF takes; obviously fast-track standard based on existing deployed technologies have less scope for change (i.e. an comment on ISO PostScript that changed the scoping delimiter from {} to [] would be regarded as incoherent or vexating.)


It may be that some chunks of the standard could be removed. There are fifty pages detailing the built-in border illustrations, for example. These pages take no time to review (contra Finland) and provide good documentation, but the information in them is uninteresting: it is not the kind of thing that I would expect to see in ODF for example. But it is the kind of thing I expect to see in the OpenXML spec, because of its different purpose.

Segedunum
2007-03-06 15:04:40
What is funny is that for years there has been a vocal group, such as Tim Bray from Sun, who have been saying that you should only standardize pre-existing technologies that are implemented and mature in the market place.


Rick. Your credibility is sinking faster that the Titanic.


The stuff that is specified within OOXML refer to specifications with proprietary implementations that already exist within either Windows or MS Office. The fact that these are not ISO standards, or other reasonable standards from bodies such as W3C, that everyone can look and refer to means that questions are more than entitled to be asked. It also renders the standard utterly useless as a standard simply because you'll have to come up with your own shot-in-the-dark implementations of these things - needlessly duplicating work, time and effort and probably uncovering lots more bugs and security problems.


The notion that these technologies that are specified within the OOXML specification can be called pre-existing and mature is utterly laughable. You do realise those technologies and implementations are contained within proprietary pieces of software that have not been subject to significant discussion and peer review, such as SVG? SVG and various other W3C standards have multiple implementations to the point where an awful lot is known about any problems and pitfalls. Not so with the stuff specified within OOXML. It's entirely new and unknown.


SVG and MathML are being implemented by many people and software projects out there. They're well known and there are implementations of them that can be picked apart and discussed. The fact that you're calling totally unknown, new and repetitive specifications existing and mature simply because they have one implementation within a couple of proprietary pieces of software - where no one knows exactly what is going on - is just so stupid it isn't even funny.

Segedunum
2007-03-06 15:12:49
But the Finnish suggestion is an interesting point as ODF is creating a completly NEW formula's standard for ODF. That is pretty complex to if not more complex then a vector standard. If it takes an expert group to do two three years for creating that formula's standard


I can sum up your response in this sentence: "Yes, I know the Finnish object is valid and they have a good point, and no I don't know why Microsoft felt the need to come up with their own totally unproven and non-standardised specifications, so I'll say something about ODF that appears to even up the score."


It isn't particularly helpful, or mature. If you can point to an existing formula specification that ODF could adopt tomorrow, that has been through a standards body, has multiple implementations in different software and on different platforms that ODF could adopt tomorrow then I'm all ears. As it is, there isn't because it is what ODF is seeking to work on itself as an office format specification.


However, Microsoft are specifying things within OOXML that have absolutely nothing to do with defining an office application format where existing and implementable standards could have been re-used for the benefit of everyone. They haven't done that, and I've seen no explanation as to why - just excuses about SVG and MathML not really being standards and counter punches against ODF.

Segedunum
2007-03-06 15:41:39
First, SVG and MathML are not international standards. Just because one International Standard references an external technology it does not make that external technology an ISO standard by proxy.


Right. So that makes it OK just to ignore them? In looking into whether something should become an ISO format it is important to look at whether said format is reusing existing ISO standards and those from other standards bodies where they have many implementations and have been the subject of peer review as a result. What is specified within OOXML are not reused ISO standards, or even standards of any shape or form that have had any proven periods of review.


and in making an XML binding for an existing implementation or API.


OK. So if it's an XML binding then how on Earth am I supposed to reimplement OOXML (it is a standard spec, right?) without reimplementing the lower level implementation so that this binding actually means something and does anything useful?! Where is the standard that that lower level implementation uses so I can implement it myself?


Third, Some of the "new" languages in OpenXML are not new at all: notably the spreadsheet language and VML, which predate ODF.


You're splitting hairs there, and you are failing so miserably it isn't even funny. Your comment is meaningless first of all because they weren't even specified, let alone opened, until OOXML came along. ODF predates OOXML. However, this is not a 'who came first' game.


Fourth, OpenXML does reuse a lot of external specs, such as ISO date formats


I thought you said resusing existing standards and specs doesn't matter?


I don't know where you heard this, but it simply isn't true. By any stretch of the imagination, OOXML does not adhere to ISO 8601 and the Gregorian calendar. It still uses an extremely broken Excel definition of dates that should have been left out of the specification totally and handled within Excel itself. This would have allowed Excel to handle the behaviour in the previous broken proprietary binary format, where it should be handled, and then convert it into a new format where this broken behaviour does not occur. This straightforward way of handling things also calls into question Microsoft's extremely shaky backwards compatibility claims for OOXML.


That's just the tip of the iceberg though.

Rick Jelliffe
2007-03-06 21:53:17
Segedunum: My credit is sinking faster than the Titanic? Well, the best I can hope for is that there are some eccentric James Cameron-like adventurers who like to explore ancient wrecks in the interests of discovering the truth. The storms may rage on the surface of the ocean, but here underwater it is quite calm! An Octopus' Garden.


It seems there is a certain kind of person who is uninterested in facts; they are interested in "big picture" propositions, and facts are only interesting to them in as far as they prop up the big picture: if "nitpicking" reveals one "fact" to be erroneous represents it is no problem to them, because they then will just switch to the next wild allegation. I expect my reputation would indeed sink with such people, if I bother to actually check the "facts" or expect consistency.


For example, take dates. OpenXML clearly uses IS 8601: the only person who could claim is doesn't is someone who has never even bothered to look. Such people are noise. See section 2.5.2.7 Date in part 4. It uses the dateTime profile from W3C XML Schemas, which in turn utilizes IS 8601 date format.


OpenXML does have specialized support for *formatting* dates into localized or specialist date formats (such as "picture" based output formatting, and as the SmartTags dates used when saving a parallel data file to HTML) and for *inputting* dates using a chosen calendar (I have lived in two countries, Japan and Taiwan that used non-Gregorian dates; it is a necessity for office documents there) or in a formula language. That is nothing against IS 8601.


It also has a little expression language for dates to allow fields to be chosen and formatted based on dates. ISO8601 is clearly not appropriate there.


Perhaps by dates you are talking about s 3.17.4 which specifies a numeric value for dates and times. Numbers allows dates to be manipulated using stnadard mathematical operations. A number is hardly a non-standard or novel notation! There are two kinds of date numbers, those starting from 1900 and those from 1904; the 1900 ones actually start from Dec31 1899, because of a bug inherited from Lotus 1-2-3. Converters cope by subtracting a 1. I expect government profiles of OpenXML would mandate that this 1900 mode should not be used.


To say that OpenXML does not adhere to IS 8601 and the Gregorian calendar when it merely provides support for converting dates to numbers according to a formula with an obscure bug is to say that there should never be standards that can cope with bad legacy data, it seems to me. How on earth could MS claim it supported legacy documents if it does not also allow markup to warn that the data has come from a system with a legacy bug?


On the subject of SVG and MathML not being Internation Standards, there may be little difference in your mind between a W3C Recommendation (voted for by paying commercial organizations and various experts) and an ISO Standard (voted for by experts from many nations and vetted by people who are not just single-issue participants) but there are many practical and regulatory differences. ISO has opened itself up to allow more specs from boutique standards bodies, in response to their success and industry-acceptance, but this does not mean that they are equivalent, or that anyone needs to treat them as equivalent. Indeed, W3C has refused to take on board various ISO SC34 standards (e.g. trying to harmonise XSD with RELAX NG or adopting Schematron.) Anyway, I was directly answering a particular point by a reader, not disparaging them as specs.


You have a running theme of OpenXML being "unproven" (hence your strange comment when I pointed out that it is mature.) If the formula system used by the most popular and distibuted spreadsheet program in the world (whether we feel this is a good or bad or indifferent thing) is not "proven" or "mature", then what on earth is? You cannot say that software is not mature just because it has not come out of an Open Standards committee.


Your point on a "lower implementation" is confused IMHO. The standard is highly documented. There are 50 pages of illustrations of page borders for goodness sake. I am amazed at how the anti-OOXML people have switched from "The standard is too big!" to "The standard is too small!" This is just FUD, pure and simple. Vague claims. The conformance requirements for OpenXML are very similar to ODF: accept valid documents, follow the semantics that are relevant to your application, document whereever you stray from the semantics in the spec. The "extensibility" in XML is all about formats not being closed: if you need something, you can add it or represent it; in the case of ODF and OpenXML that means they can have media in non-standard types. It is the job of profiles to close off this kind of extensibility.


On your FUD about "Microsoft's completely shakey backwards compatability claims for OOXML" would you care to provide even one piece of evidence? It should be easy enough: find an old document, print it in an old application, then import it to Office 2007, save, re-open then print and compare. Then we can look at it and figure out whether this is a problem with OpenXML being unable to represent it (i.e. it is a format fault, where OpenXML misses its goal) or with Office 2007 being unable to convert it (i.e. it is an application fault), and then to judge what the best way forward to deal with the problem is (Fix now? Fix later?) I think people in standards groups are getting pretty cheesed off by this kind of FUD lobbeying: many of us have been in the business of examining standards for technical inconsistencies for decades and this kind of time-wasting mischief-making may be good for whipping up emotions but it does nothing for your cause. Give us facts, real problems in the specification, not goal-post-moving rants based on no actual evidence.

(All that being said, it would not surprise me if there were some corrections required for the fast-tracked specs even after they are standardized, because they have not benefited from the extra scrutiny of SC34 and (some of) the national bodies' experts. For example, schemas are often the end of the production process with standards deadlines, but they are a thing that SC34 WG1 in particular is interested in.)

marc
2007-03-07 20:03:08
my response to Rick comment http://www.oreillynet.com/xml/blog/2007/03/rumours_trickly_out_about_the.html#comment-518573
interleaved with <marc></marc>s tags :


<rick>
For example, take dates. OpenXML clearly uses IS[O] 8601: the only person who could claim is doesn't is someone who has never even bothered to look. Such people are noise. See section 2.5.2.7 Date in part 4
...
It uses the dateTime profile from W3C XML Schemas, which in turn utilizes IS 8601 date format.
</rick>


<marc>


" 2.5.2.7" is "WordprocessingML Reference Material . Custom Markup . Structured document tags [1] . date [2]" . It has nothing to do with the date XML representation in spreadsheet OOXML
markup; the date thing in discussion is about the spreadsheet format, remember?


and yes, the date structured document tag uses the ISO 8601 derived W3C XML dateTime data type, but for a *date picker* in text documents !



[1] "Within a WordprocessingML document, it is often necessary for specific documents to contain semantic information beyond the presentation information specified by this Office Open XML specification. For example, an invoice document may wish to specify that a particular sentence of text is a customer name, in order for that information to be easily extracted from the document without the need to parse the text using regular expression matching or similar. For those cases, multiple facilities are provided for the insertion and round24 tripping of customer defined semantics within a WordprocessingML document.


There are three distinct forms in which customer-defined semantics can be inserted into a WordprocessingML document, each with their own specific intended usage:


. Smart tags
. Custom XML markup
. Structured document tags (content controls)"


(source: "ECMA OOXML Part 3 - Premier" page 19 clause 2.6 http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip )

[2]
"This element specifies that the parent structured document tag shall be a date picker when displayed in the document."


(source: "ECMA OOXML Part 4 - Language Reference" page 544 subclause 2.5.2.7 http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip )
</marc>


<rick>
Perhaps by dates you are talking about s 3.17.4 which specifies a numeric value for dates and times. Numbers allows dates to be manipulated using stnadard mathematical operations. A number is hardly a non-standard or novel notation!
</rick>


<marc>
rick, at this point i will assume the OOXML format is yours... you are deffending it too much !! so ... do you lack the sense of autocritic? this is how SpreadsheetML stores dates ( and this subclause is the detonant for all the comments of folks like Segedunum and the ISO/IEC NBs ):


"3.17.4.1 Date Representation
Going forward in time, the date component of a serial value increases by 1 each day.
There are two different bases for serial values:
. In the 1900 date base system, the lower limit is January 1, 1900, which has serial value 1. The upper-limit is December 31, 9999, which has serial value 2,958,465.
. In the 1904 date base system, the lower limit is January 1, 1904, which has serial value 0. The upperlimit is December 31, 9999, which has serial value 2,957,003.


A serial value outside of the range for its date base system is ill-formed.
As to which date base system an implementation uses by default or whether it allows its users to switch between date base systems, is unspecified. See 3.17.6.7 for XML-related details. [Note: As the XML allows either date base system to be used, an implementation must be able to deal with both systems. end note]


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 (non-existent) date February 29 to have the serial value 60. end note] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (non-existent) date February 29 has a day-of-the-week that immediately
follows that of February 28, and immediately precedes that of March 1. [Example: ommited ]"


source: ( "ECMA OOXML Part 4 - Language Reference" page 2522 subclause 3.17.4.1 http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip )


Please ECMA ( or Microsoft, or Rick, whatever ): USE A STANDARD FOR DATE REPRESENTATION, not this 1900/1904 beast, we are in 2007, not in COBOL ages !!! may be Microsoft will have to put some developers to patch Office 12, but we are discussing an international standard, not simply a "published reference" that is comfortable to Microsoft present implementations of it.
</marc>


Rick Jelliffe
2007-03-07 20:28:10
Marc: I was responding to the statement "By any stretch of the imagination, OOXML does not adhere to ISO 8601 and the Gregorian calendar." I went through the entire spec and found that in fact, it always does, for places where full internationalized dates are appropriate.

The use of numeric forms for storing dates is obviously the result of a conscious trade-off of the load/parse time of dates versus the precalculation benefits of numbers. It might not be the format the we would choose if we had any expectation that the numbers would be entered by hand or read unmediated by a formatter, but for spreadsheets (and scientific data) it is not a high priority requirement; instead, size and load/parse time issues certainly are important.


I don't particularly see why MS couldn't also provide support for reading IS8601 notation values too, later, but I can see why saving dates as numbers here is warranted. I don't see that there is any "contradiction" issue involved, though. What is being stored are indexes not human-readable dates.


hAl
2007-03-08 06:39:11
don't particularly see why MS couldn't also provide support for reading IS8601 notation values too, later, but I can see why saving dates as numbers here is warranted.


It would have been wise for MS to include in their response to the ISO natinal bodies the intent of adding a subset of ISO dates as allowed storage format for dates in spreadsheet cells. Then implementations ccan choose between readability(?) and the extended timeframe and timezones of the ISO format on the one hand and the performance en storagesize of the numeric formats on the other hand.


2007-03-08 08:16:12
IMHO, you are with XML and interoperability or you are against it ( sounds familiar? ;-).


If you really believe that XML is the right language to store office documents, not only to be displayed but to be implemented and "consumed" by any software/programming language/operative system/vendor/culture, then you must drop all this bit-masks, date as numbers, cryptic tags and attributes names, pagesize lookup tables, MSDN "dependencies", 10+ pages of fancy border art work, performance worries, etc, and use XML data types and standards, rational human-readable tags and data types, etc. The "legacy and compatibility features" of the format should be second if not third class citizens in the standard.


And regarding the "performance penalty" argument, my opinion is:


i) you can't win all ! you choosed XML , then you must trade-off some performance with readability, interoperability, simplicity, etc.


ii) today, 10 years old childs have on his desktops ( just to play counterstrike and the like ) dual/quad/etc. cores CPUS with near 4GHZ speed and with 200GB+ hard drives. Are you really worried about speed issues?


( http://indigo.intel.com/compare_cpu/showchart.aspx?mmID=885491,884350,885492,884351,880346&familyID=1&culture=en-US )

Rick Jelliffe
2007-03-08 16:12:43
hAl: Maybe people should lobbey Ecma and your national bodies for it. It is no use complaining about a lack of openness in the Ecma stage, when we are in the middle of an open process at the ISO moment! Do something constructive people! I think the ISO fast track procedures are generally geared towards up-down votes, but the intent of the whole process is to get a good and useful range of standards. But be constructive: if you find a problem, suggest be constructive: if you find a problem, suggest an improvement or fix! And I am sure that MicroSoft knows that ISO standardization (as with Ecma standardization) will detect some rough edges that need improvement. It will cost them, but minor adjustment costs are part of the deal, and it gives them a marketing weapon to use as legislatures demand open standards more. Indeed, the strength of ISO standards in particular is that they bring an international audit to standards which can make the specs more useful: take the issue of URIs for example.


In XML, I and others pushed hard for the idea that the URIs in the system identifiers of entity declarations should allow the direct characters not delimnited versions: it is the task of the parser to convert them into strict URI mode. I see this as a corollary to the Native Language Markup idea that is behind XML 1.0's naming rules: you should be able to use the normal characters and symbols for names in your language. Now this idea fell between the cracks in subsequent specs, because the RFC for IRIs was delayed, and W3C got some standards people who were not happy with the idea of deliberately not using standards: the "humans will never read this directly" crowd perhaps. But at ISO, countries like Japan really are keen on IRIs and they will push hard to get them. (I completely support them: indeed, all ISO specs should be reviewed to make sure they allow IRIs where appropriate.)

Rick Jelliffe
2007-03-08 16:33:52
Anonymous: No. Optimality does not come from monoculture, but from a rich solution space with known properties that can be selected as appropriate.


Now in this space one certainly expect 80/20 leaders to arise: HTML for simple document interchange systems, ODF for medium complexity document interchange, OpenXML for high complexity documents, and native+PDF for archiving/fidelity.


The problem is that your argument is based on the idea that if OpenXML is adopted as an ISO standard, it will hold back ODF. That is entirely wrong, as far as I can see.


If we play our cards well, out of this process we will get a well, out of this process we will get a rich solution space, and OpenXML and ODF will have been improved by more open scrutiny both to fix problems and to get to know their strengths and weaknesses. Now regulators and legislators and purchasing departments are completely smart enough to find words that will favour ODF over OpenXML where appropriate. But that should be a decision made by them, not at the ISO level be a decision made by them, not at the ISO level.


You can be pro-ODF *and* pro-OpenXML, as far as thinking it is good to have them both as standards in the library of standards. Don't fall for the marketing FUD that says that if OpenXML is standardized, it will force legislators to allow it. All that standardization mean is that a spec meets a particular market requirement and is a certain technical form and quality; just because a standard exists does form and quality; just because a standard exists does not mean that it is always appropriate to use it. Indeed, the foundation of SGML is that it is impossible or futile to have one true path, IMHO! Horses for courses...the right tool for the job... courses...the right tool for the job...room to grow, etc.

Segedunum
2007-03-08 16:44:55
It seems there is a certain kind of person who is uninterested in facts; they are interested in "big picture" propositions, and facts are only interesting to them in as far as they prop up the big picture: if "nitpicking" reveals one "fact" to be erroneous represents it is no problem to them, because they then............


I don't believe the above comment is helping your cause. I don't believe it answers many of my queries and problems either, or those of people who've objected.


I'm not looking at big picture stuff at all. They are specific objections and queries that an awful lot of other people will come up with, and will come up with, as well. The fact that you're bizarrely claiming that we can somehow ignore the fact that a specification doesn't reuse well worn W3C and IETF standards, and simply wraps a load of proprietary, closed and unproven implementations is just daft. You're then wandering off to find some patchy parts where OOXML might adhere to certain standards and then cite that as proof that we can ignore the fact that OOXML simply wraps an awful lot of stuff that cannot be reproduced, certainly not easily and straightforwardly. That's not an answer.


For example, take dates. OpenXML clearly uses IS 8601:


Interesting sleight of hand. The accusation isn't that OOXML uses ISO 8601 in some third hand way, but that it adheres to it (I do believe I used that word). It simply doesn't.


the only person who could claim is doesn't is someone who has never even bothered to look. Such people are noise. See section 2.5.2.7 Date in part 4.


Section 2.5.2 is WordprocessingML structured document tags, and custom tag information. We're talking about a date picker here. That's not adherence.


Perhaps by dates you are talking about s 3.17.4 which specifies a numeric value for dates and times. Numbers allows dates to be manipulated using stnadard mathematical operations. A number is hardly a non-standard or novel notation! There are two kinds of date numbers, those starting from 1900 and those from 1904; the 1900 ones actually start from Dec31 1899


Yer. It does not adhere to ISO 8601. Thanks. You can argue that they're merely numbers as much as you like, but they are dates by any stretch of the imagination.


because of a bug inherited from Lotus 1-2-3.


Interesting that you talk of this coming about because of a bug in a non-Microsoft office suite, but it simply doesn't matter and shouldn't be in there. You take the old and broken way of doing things and convert it into a format that does things in the right way. If all OOXML is is a one-to-one reproduction of the old MS Office binary format, with all of the accumulated and now pointless fixes put into it for broken legacy applications (their application problems, not format ones), and then sprinkled with some magic XML dust, what's the point?


If the formula system used by the most popular and distibuted spreadsheet program in the world (whether we feel this is a good or bad or indifferent thing) is not "proven" or "mature", then what on earth is?


I'm not interested in how popular or distributed the spreadsheet application that uses this system is. The fact is, it is the only application that uses it, and no one can see how it is implemented. It has not been implemented by other applications or on other platforms (aside from some reverse engineering), and as such, has not been reviewed and is not necessarily reproduceable. For an ISO standard, that is important.


Aside from that, we've merely got parts of OOXML that wrap specific implementations within MS Office and Windows, so if those implementations can't be reproduced, OOXML is pretty much useless for everyone else.


Your point on a "lower implementation" is confused IMHO. The standard is highly documented. There are 50 pages of illustrations of page borders for goodness sake.


The standard is not highly documented - on anything underlying within Windows and MS Office that you actually need to implement it. Of course, this will be interpreted along the lines of your "The standard is too big!" to "The standard is too small!" comment, but then, I suppose that's the point. Stalling for the sake of it...


I'm glad you brought up the page borders thing, because it just shows how much pointless crap there is in there. We have a number of specific and defined page borders in there, for reasons which only one can guess. A lot of the stuff in there is only appropriate to a western slant, and is highly inappropriate for a proposed international standard. There's even a page border in there that looks like a row of breasts for goodness sake.


On the subject of SVG and MathML not being Internation Standards, there may be little difference in your mind between a W3C Recommendation (voted for by paying commercial organizations and various experts) and an ISO Standard


That wasn't the point. OOXML references various things which people are going to have to implement if they want to use OOXML at all away from Microsoft Office and Windows. Those things are not standards of any kind, let alone ISO ones, so OOXML is simply not reproduceable.


On your FUD about


I do wish people would learn what FUD actually means.


It should be easy enough: find an old document, print it in an old application, then import it to Office 2007, save, re-open then print and compare.


Whether it can be saved accurately in Office 2007 or not is Microsoft's problem, not anyone elses'. The simple fact is that OOXML is a new format that is not backwards compatible with the older binary Office format - all those legacy documents Microsoft refers to. All that has happened is that thousands of elements from the older format have been dumped into a newer, and incompatible, format (you can't open Office 2007 files directly in previous versions, so it isn't backwards compatible) for no apparent reason.


Microsoft could have got Office 2007 to open older Office documents, contributed to and improved ODF in ways they needed, and then saved the resulting documents in the new ODF format (or even one without said baggage). There is no explanation for OOXML being the way that it is for reasons of backwards compatibility. It's simply a falsehood that clearly doesn't stand up to scrutiny.


or with Office 2007 being unable to convert it (i.e. it is an application fault)


From an ISO standard point of view, no one is particularly interested in Office 2007 being able to convert it. People are interested in whether Office 2007 and a multitude of other pieces of software on various platforms can feasibly handle it in an equal manner. Bugs in Office 2007 are neither here nor there.


Do try and separate the format from any specific piece of software, OK?


I think people in standards groups are getting pretty cheesed off by this kind of FUD lobbeying: many of us have been in the business of examining standards for technical inconsistencies for decades and this kind of time-wasting mischief-making may be good for whipping up emotions but it does nothing for your cause.


You're just tailspinning there. The only emotions this seems to have whipped up are yours.


Give us facts, real problems in the specification, not goal-post-moving rants based on no actual evidence.


They are real problems in the specification, but you don't want to hear them. Apparently, W3C and IETF standard usage so that people can feasibly reproduce said ISO standard and format is not important, but a format relying on proprietary and single implementations that aren't defined anywhere somehow is. OOXML might refer to other standards, but it simply is not consistent in its usage and adherance to them. See the date problem.


Apparently, bitmasks are absolutely OK for use in an XML based format - for reasons which are not clear. If it's an XML based format one would assume that it should be accurately parseable on that basis, but apparently this, and extensibility, are just not important for reasons which escape me and a lot of others.


The list goes on.

Rick Jelliffe
2007-03-08 17:48:30
Segedunum: That OpenXML does things differently to ODF is a good thing, not a bad thing: different strategies and characteristics means that there are more-optimal solutions for different problems.


Having ISO OpenXML does not prevent anyone from using and saving as ISO ODF.


You say Apparently, W3C and IETF standard usage so that people can feasibly reproduce said ISO standard and format is not important, but a format relying on proprietary and single implementations that aren't defined anywhere somehow is. OOXML might refer to other standards, but it simply is not consistent in its usage and adherance to them. See the date problem.


Huh??? The mapping for their numbers to dates are clearly defined in the spec, not "nowhere". They are not binary. They are not proprietary. And as far as I can tell there are multiple implementations (e.g. am I wrong in thinking that Gnumeric, Monarch, and some others generate or accept it?) And the mapping to IS 8601 notation is trivial and clear.


If they saved dates as dates in US format, such as 1/3/2007, then it would indeed be not adhering to IS 8601. But even then, as long as IS8601 was one of the date formats allowed, indeed, the default, I would have no problem with it. The lack of localized dates, as I have mentioned beore, an issue I brought up with on the XML Schema Working Group, and XSDs lack of support for localization (i.e. locally optimal formats with clear mappings to standard international formats) was one reason for ISO to adopt Schematron and the DTTL technology at SC34 WG1.

As for the argument that speed does not matter, in general I agree, but that does not mean it never matters. The particular always overrides the general. In the case of office documents, we are talking about a few seconds difference, but this is multiplied by hundreds of millions of users. You are talking of billions or hundreds of billions of seconds of lost productivity. I think there is even a good case to be made that for office document formats, efficiency of loading/opening should be a prime requirement. (Remember that XML's goal of terseness being of minimal importance was not to encourage long names or to require all structure to be marked up using XML, but to rule out various minimization features from SGML.)


I don't want to be disrespectful, but it is not enough to just repeat the same list of buzzwords against any issue, regardless of fit, as you have done with dates. The format of bitmasks, dates saved as indexes, and the short tag names all come from the same engineering decision: a need to reduce the uncompressed file size. Now that is the technical issue that you perhaps should be persuing, because the effects are quite reasonable responses to the requirement. Show that the requirement is bad or inappropriate, or that we are not better off with ODFs (implicit) requirement which is that uncompressed file size is not so important.


The thing about standards is that you only need to adopt them where appropriate. Ultimately, attempts to make people use standards where they are not appropriate or mature will fail: the US Military CALS initiative in the 80s and early 90s is a really clear exanple that SGML people are only too familiar with. But in time, things sort out, and now we are in a world where CALS-ish solutions are feasible and natural.

Rick Jelliffe
2007-03-09 20:09:17
While we are on the subject of dates, the silliness of the "numbers are bad" argument can be seen when thinking about the purpose of markup and standard formats: you want a standard date format for two reasons: first so that computers can parse the text into its internal representation of a date, and second so a human could read and write it.


For computers, numbers are prefectly parseable and manipulatable.


For humans, the ability to read and write individual spreadsheet values is not a consideration: it is not like HTML where a large amount is edited by hand. It is a well-known pheonomenon (and I am speaking as someone who has designed and sold a text-based markup editor for XML markup through my company Topologi, so I think I know a little about how people do markup of complex XML) that *even when* people edit tables in text, because the two-dimensiona structure is so different from the linear markup, and because the elements for table cells are so far removed from their row and column headings, thy cannot proof in text, they have to go to a formatted or semi-formatted version. Now spreadsheets are a lot more complicated than tables. Humans won't be reading individual values.


Elevating a non-requrement to the level of a requirement is the sign of a bad schema. Ideed, as my material on metrics and XML governance emphasizes, it needs to be an aim of XML development to eliminate spurious requirements, because they cause unnecessary work.

omz
2007-03-10 10:19:21
rick said "Elevating a non-requirement to the level of a requirement is the sign of a bad schema."


Actually in the past it was elevated by ... yes, MS !


The truth now is that MS is scared: customers will loose *one* second in load/save times in Excel, so they won't buy the new Office 2007.


This fears and others were transladated to many OOXML design decisions.


In the Office 2003 XML effort, MS were trully thinking about leveraging XML and interoperability, i.e: look how are dates stored in 2003 spreadsheet XML:


<Cell><Data ss:Type="DateTime">1992-05-01T12:35:00</Data></Cell>


ISO 8601 !! [1] [2]


[1] "xs:date: Contains a date in the ISO 8601 [-]CCYY-MM-DD[Z|(+|-)hh:mm] format ... xs:datetime: Much like xs:date above, except that it adds time information, making the complete format [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm], where the T is a capital letter T used as a divider, and hh:mm:ss is hours, minutes, and seconds.


The optional negative at the start indicates if the year is before 0 AD, CC is the century, YY the year, MM the month, and DD the day. "
( Annex C.3.3 Datatypes of Lenz/McRae/St. Laurent "Office 2003 XML" O'Reilly 2004 Edition, http://www.oreilly.com/catalog/officexml/ )


[2] http://msdn2.microsoft.com/en-us/library/aa139987(office.10).aspx

Rick Jelliffe
2007-03-11 06:53:38
omz: I don't know whether they moved to pre-parsed indexes because of their experience with parsing speed or just because of the general shift in the 2007 schemas away from ODF-like abstraction and towards concerete complete data dumps.


Being "scared" is an odd comment. It is not a trivial thing, when considered in aggregate. Applications are benchmarked on load times because it is an important aspect.

Bruce
2007-03-12 03:50:33
@Rick:


"Fourth, OpenXML does reuse a lot of external specs, such as ISO date formats and Dublin Core."


You're cherry-picking here. I repeated Finland's concern about VML and OOML, and you come up with fairly trivial examples of reuse like whether MS uses "x:Title" of "dc:title." And interestingly, they only use DC to describe the document per se, and not in other metadata (see below on bibliographic data).


"What is your proof that MS did not look at existing formats and found them lacking? Why isn't that just FUD? (Now I am talking about the formats that were usable and ISO standardized three to six years ago when they started their moves to XML and more openness.)"


The burden is on MS to make the case that the world (and more particularly ISO) needs VML, OOML, etc. It's not my job to provide "proof" of decisions made behind closed doors, nor is it FUD to say (as Finland and others did) that this issue is important.


FWIW, I don't find it particularly troubling that MS included their own bibliographic source format (my area of expertise, and something the Finland comment mentions), mostly because there is no clear standard in this space. But I did present a list of suggested improvements to the ECMA TC (including reusing DC here), and as near as I can tell, they ignored all of them. I did get an email reply explaining their decisions, but AFAIK, neither the decision nor the deliberations are publicly available. I'm more troubled by that (the process behind the tendency toward NIH) than that they invented their own bibliographic format.

Rick Jelliffe
2007-03-12 17:48:08
Bruce: It makes no sense to look at the TV guide in the newspaper and complain that the listings *are* accurate. With OpenXML the intent is to document what MS Office actually generates, warts and stars and all. If SVG and DrawingML can be harmonized in the future, that is great; if governments mandate that SVG should be used for drawing, that is great too and best of luck; if governments mandate that new documents should be limited to only what ODF supports to help interoperability, that seems sensible to me; but it does not impact on what OpenXML should contain, because the purpose of OpenXML is *not* to fit in with the W3C or with OASIS or the feature sets of MS' competitors but to expose Office's formats.


Supporting Office's complete feature set was never a requirement for ODF, and there has never been any systematic review of ODF to cope. Nor of DrawningML versus SVG, for that matter. Patrick Durusau the ODF editor emailed me last week about his proposal to start off just such a mapping exercise, but that is future work, not even started. (There is more information, though, for example the sourceforge converter project has a list of features for which there were no workarounds for WordprocessingML.)


There are other users than governments, and other uses than lowest-common denominator (common subset) -style intereropability. Users needs a native format in which when a document is saved and re-opened, it will look the same; ODF cannot promise that. Businesses benefit from being able to access the details and to build systems using extended linking mechanism. I don't see why governments' particular needs are any more important than business uses.


The way people talk, blind interoperability between large office suites is the only consideration. But I want MS Office to save in a standard format, ODF is not ready, and that leaves OpenXML at the current time. (Saving to ODF is nice and important, but would we really have wanted MS to have embraced and extended ODF in order to get roundtrippability?)


MS has its own longstanding technical stream: the issue is how ISO can best bring this stream into the fold and support the part of the market that uses that format, not how we can find excuses to repulse MS or its users IHMO. (If I was king of the world and had written the OpenXML (or ODF) spec, I would do things very differently. But I am not.)


VML is in transition and VML only generated/accepted by Word for some kinds of decorations (text boxes, background images) whereas normally their DrawingML is used, btw.


(This is in part a repeat of another response to a different blog entry.)

Kevin Ollivier
2007-03-13 17:04:52

...but it does not impact on what OpenXML should contain, because the purpose of OpenXML is *not* to fit in with the W3C or with OASIS or the feature sets of MS' competitors but to expose Office's formats.


The way people talk, blind interoperability between large office suites is the only consideration. But I want MS Office to save in a standard format, ODF is not ready, and that leaves OpenXML at the current time. (Saving to ODF is nice and important, but would we really have wanted MS to have embraced and extended ODF in order to get roundtrippability?)


I've been lurking in this discussion, but one point I've never seen made clear is why OOXML should be a standard, and not just an open format. To clarify my point, Microsoft (with no input or help from anyone) can come up with open, thoroughly documented formats that make it possible to read and extract data to/from their files. Obviously, they've already done so, and as far as I understand, it can be used today by those that need it. So, in this case, what is the point of the community involvement? If they're going to fast track it and say the implementation is already mature and ready, what is actually gained by making OpenXML into a standard?


As a practical matter, the main purpose I see for having a standard is to get multiple vendors to agree to implement it. So when you make the point that people are "only" considering interoperability, it does beg the question, what is the point of creating standards if not to improve interoperability and consolidate data formats? You don't need to standardize in order to create an open format, nor to document it, so when you take away interoperability, what does the community at large benefit from having OpenXML as a standard?

Rick Jelliffe
2007-03-13 18:34:40
Kevin: You say the main purpose I see for having a standard is to get multiple vendors to agree to implement it.


I don't think that the main purpose of a standard is necessarily to aid the COTS and commercial worlds, except by side-effect. Indeed, SC34 standards traditionally are aimed at an entirely different set of users: integrators, inhouse developer, roll-your-own, open source developers and so on. The big developers have traditionally stayed away from SC34, because we fit into a different planet to them or at least their markets. XML technologies and the web infrastructure have made the Document Engineering aproach a lot more feasible and attractive, and the big players see the potential for a market; so they indeed will be interested in getting involved.


But my partcular reasons for supporting OpenXML to become a ISO standard are because it would help SC34's traditional constituency (integrators, inhouse developers, etc). For years, if you had to deal with a production environment with Office in it, your life was production environment with Office in it, you were effectively stuffed, or had to invest in even more in that platform to be able to get results. In other words, it is a mistake to think of this as if the large office suite purveyors were the only game in town: that is the way they want us to think, but a lot of people in the standards activities just don't see the world in terms of the raging dinosaurs battling. Indeed, what XML opens up is the chance to extract and product information in the most partial of implementations: the ability to do useful things with "incomplete" implementations is the big win, not a flaw. This is integratability rather than interchangability, perhaps: OpenXML has a lot of good features for integratability that ODF does not have (yet!) ISO standards need to provide a rich library of solutions, and the decision about which solutions should be favoured are political/economic/product-testing decisions that are simply not ISO's business. The other aspect is that the presence of ISO ODF, ISO HTML and ISO PDF actually make OpenXML more palletable: its ideosyncracies matter less because it does not have be the one true format. It can concentrate on doing what it claims to do, exposing Office's workings. Making it a standard, even through the fast-track process, exposes OpenXML to a level of review that is good for everyone.


I would prefer to have two kitchen sinks separately than one absolutely enormous double-sink, which is what the people who call for harmonization are in danger of getting.


The other thing is that you don't need to think of a standard as lasting for ever. In ten years time, when ODF is mature and
provably can handle everything that OpenXML can handle, it is not unlikely that ODF will be the dominant format, especially as governments endorse it and web and open source applications make it their default formats. OpenXML does not need to be a cause of panic or conspiracy theories.


Now I have an issue of fairness too. Public organizations have to proceed along their procedures without favouring one particular side. The law courts cannot say "we refuse hear your lawyer in this patent case because you are a convicted monopolist in Europe" for example. So when we at ISO and national body working group get a standard from Ecma of MS technology, we have to treat it on its technical merits looking at whether there is a market requirement (there clearly is). (In fact, ISO requires experts and national body representatives on committees to consider all stakeholders, not just their own private beliefs. The aim is not to block agreements on standardized technologies but to allow them.) So I think OpenXML meets all the criteria to allow it to proceed to the final national vote; at that stage, a lot more will be clear on its technical differences and the various problems that national bodies identify will have been resolved...an IBM guy has signalled that they will be arranging more lobbeying of national bodies (by diverting the pro-ODF people to being anti-OpenXML)and I expect we will see some sour grapes anti-ISO propaganda too. I guess this is the "why not?" arguement rather than the "why should it?" argument.

Kevin Ollivier
2007-03-15 10:05:21
In ten years time, when ODF is mature and provably can handle everything that OpenXML can handle, it is not unlikely that ODF will be the dominant format


These kinds of comments are what, honestly, leave me confused. You attempt to explain how OpenXML fits a unique need, and then, you say that the standard need not be forever and eventually ODF will handle everything OpenXML does. Huh? That sounds like you're saying that OpenXML is basically a stopgap until ODF can catch up. But why does a standards organization, which doesn't factor in political or economic reasons for having the format, care about a stopgap solution?

Rick Jelliffe
2007-03-15 18:11:46
Kevin: All ISO standards are reviewed every five years to see if they are still relevant and still meet a market requirement. If not, they can be retired. Some standards are stepping stones not destinations.


A standard is not like a law or scripture that stands forever. It is an agreement on a technical/industrial issue for which there is a market requirement of enough duration to justify the process.


Very often with SC34 standards, they lead to profiles and re-working that find widespread adoption. So SGML was really useful for its high-end market, but it morphed into XML for low end use. DSSSL was really useful for its high-end market, but it morphed into XSL for the low-end market. Standards are like a library of technical solutions, but they don't represent the end of innovation; instead they often result in a new round of innovation which may ultimately eclipse them.


I've quoted favourable a comment before (by Sam Hiser?) that OpenXML represents the past and ODF represents the future. But the big issue is what is needed and possible now. Fast-tracking is aimed at filling in gaps fast for the "now": standards with immediate market requirements, in the knowledge that the five year review comes up.