All Microsoft products will now be approved as standards.

All non-Microsoft software standards can now be repealed.

I totally agree with your comment. It is something I never actually considered as an option. Maybe because by default I believe Microsoft will want to go its own way rather than share the path.

Heck it would be so much easier if they did use ODF. On top of that they already have a pretty good MS Office to ODF converter. Its called Open Office. So even that would be covered.

As a side note the ODF (as published May 1 2005) is 706 pages long (minus 30 for index). That makes OOXML about 9 times bigger. Now given Rob’s comment on three different ways to show font color we can think there are three ways to do everything. That still makes OOXML 3 times bigger (9/3=3). Now unless DIS 29500 is published with font size 36, there has got to be something really really wrong about it don’t you think?

Pardon me for asking, but why do we have to bring up the remaining defects in OOXML? The standardization process should be based on the pledge of the initiator of that standard that it is good.
That is, by default any proposed standard should be considered bad/non standard worthy, and the initiator should be required to come up with evidence that proves its worthiness. And should that evidence be unconvincing, the standard should be turned down by ISO.

I had little success finding any Microsoft document bringing up any such evidence. Why is this out of the norm difference? Why aren’t we requiring such a document from the initiator ECMA/Microsoft?

Here is a forum post of mine, putting the same question:
http://www.noooxml.org/forum/t-48601#post-129997

This thing is coming to a vote; it’s going to be like a presidential election. Sure to be ‘Republican’ or ‘Democrat’ who wins, but no-one is sure which, right now.

“America has spoken. We are just not sure what she has said”. Where have I heard that before ?

And the policies … the ways forward for the technology industries over the next few years … are different.

Speak now. Get your vote counted.

All of my points were just restatements of classic MS replies to valid issues. I just got them out of the way before someone serious rolled them out.

The one valid belief that I have about the process is that the only way to implement any MS specific formats HAS to be a superset of ODF and other ISO or internationally recognized standards. The only parts they (the MS superset) should include will be application specific tags, mapping, decoding and schema, unless it is clearly new and previously undocumented functionality.

The stupidity of not extending ODF for common functions, or contributing to a BETTER vector graphic ML, or using a defined date standard is appalling.

A valid MS friendly format really should have been under 200 pages, simply by incorporating accepted, recognized methods and standards.

Sorry for dragging that red herring across the path.

http://dearmicrosoftofficeteam.blogspot.com/2008/03/dear-microsoft-office-2007-team-please_03.html

This could have been spell-checked, even in Word, by breaking it into chapters. But they didn’t bother.

The mismatch between functions and definitions could have been checked with very little effort. I have cross-checked technical documents of several hundred pages myself, in under a week. Was ECMA too stingy to hire a few experienced technical writers and editors? Or was Microsoft spending all the petty cash on stuffing the committees with “members” that appeared, voted and were never seen again?

Tsu Dho Nimh

Regarding your point #1, Maintenance. My advice is if they can’t fix it today what makes you think they’ll have the will and time to fix it tomorrow.

Regarding your point #3, posting on the web. The fast track would have been faster if they had submitted a 10 page proposal and then just post ed the rest someday on MS Live Search.

Regarding your comment on economics. Please take into consideration all those people and companies that will use the proposal if it is approved as a standard. Does their time cost nothing? If the proposal is broken so will the implementations based on it. This will cost others money to implement it and then MS some more to fix it and then again some more money to fix the implementations based on the no longer valid “standard”. As a user I prefer it be only MS ECMA that loses. After all it is MS’s fault it is so poorly written. Others have had proposal approved. Clearly it wasn’t cheap, but they got it right.

Shouldn’t the error be more like
2 standard deviations not 1 standard deviation. (2 sd would be approximately 95% confidence range)

that would be 1.5 % +/- 6 %

Am I crazy here?

Garick

I can’t believe you are obsessing about these issues. ECMA’s got it covered.

1. They’ll either be fixed in maintenance;

2. The features will be deprecated to an appendix (as a Word97 .doc);

3. The binary API documentation will be posted on the web, someplace MS Live Search can find them — eventually.

I believe every complaint you raise can be answered by some combination of 1, 2 or 3.

- – - – - – - – - – - – -
It’s essential you understand the economics of this issue. Failure to approve MS OOXML as proposed will waste all the resources devoted to it’s acceptance so far. It will literally cause the entire work to be rebuilt from scratch.

Given the economics, MS’s ECMA division will probably have to breakup this grand opus into many smaller works, addressing specific facets and subsume ODF specs as a partial fix.

How odious would that be!!

Geez Rob, ease up.

Not that this changes the sampling statistics, but it messes up coordination a bit, sorry.

This simple type specifies that its values shall be a 128-bit globally unique identifier (GUID) value.

It further states that:

This simple type’s contents must match the following regular expression pattern: \{[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12}\}.

and they give the example {A67AC88A-A164-4ADE-8889-8826CE44DE6E}”

First problem: they don’t give any guidance regarding how to interpret this ST_Guid string as a “128-bit” integer value. Presumably it is 32 hexadecimal digits, but the implementor should not need to guess, nor is the byte order indicated. [And elsewhere in the standard, GUID values are manipulated using integer arithmetic, e.g. in section 2.8.1 (Font Embedding) it requires you to "reverse the order of the bytes" of a GUID and "XOR the value" with something.]

Second problem: the GUID “shall” be a “globally unique identifier,” but what does it mean to be “globally unique?” Does the implementation have to require that the identifier is unique within the document, within all OOXML documents on the user’s hard disk, or all OOXML documents in the globe? No explanation is given anywhere, nor is any algorithm to generate GUIDs described.

According to Wikipedia, “GUID” is a Microsoft terminology for a specific space of 128-bit identifiers (and specific bit patterns are reserved for use in various Microsoft protocols), and is generated by specific algorithms (some of which apparently create serious privacy problems). Presumably, some version of Microsoft’s GUID “standard” is what is intended for ST_Guid, but as far as I can tell this is never explicitly indicated.

In short, OOXML needs to define what precisely is meant by a “GUID” and how they are to be generated.

Furthermore, ST_Guid is not used consistently throughout Ecma 376. In section 7.6.2.30 (Guid), it defines b:Guid element that “specifies the GUID of a source” and uses the same format as ST_Guid in the example, but is stored as the “ST_String255 simple type”. OOXML also defines a ST_Clsid (Class ID simple type, sec. 7.4.3.2), which stores a GUID with exactly the same format definition as ST_Guid—why not use ST_Guid for class IDs, then?

I searched the proposed BRM resolutions and couldn’t find anything on this issue. (I think. Rob, can you provide a link to a PDF of all the BRM resolutions? I’m not sure I’m searching the right thing for the BRM.)

One of the attributes is “locked”:

Specifies that the anchor location for this object shall not be modified at runtime when an application edits the contents of this document. [Guidance: An application might have automatic behaviors which reposition the anchor for a DrawingML object based on user interaction - for example, moving it from one page to another as needed. This element shall tell applications not to perform any such behaviors. end guidance]

As I understand it, this means that, once you set the “locked” attribute for an inline graphic, the application shall not provide anyway to unset it or even to delete the graphic, which doesn’t make much sense. This clause should be written more narrowly to make it clear that the application can changed the locked setting as a result of an explicit user indication, at least.

In the same anchor element, there is also a “relativeHeight” attribute:

Specifies the relative Z-ordering of all DrawingML objects in this document. Each floating DrawingML object shall have a Z-ordering value, which determines which object is displayed when any two objects intersect. Higher values shall indicate higher Z-order; lower values shall indicate lower Z-order.

Problem: It doesn’t specify what should be done if two objects have the same Z-ordering value, nor does it state that the Z-ordering values must be distinct.

I searched the proposed BRM resolutions, and neither of these seems to be addressed.

Three-bit color. One bit per color channel.

http://www.ecma-international.org/cgi-bin/counters/unicounter.pl?name=ECMA-376_part3pdf&deliver=http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip

note 2: errors not fixed in the +2200 pages of ECMA fixes

—-
Part 4: throughout

Errors in elements and attribute names are found all throughout normative text of Part 4.

Examples:

Part 4, Section 2.9.10 lvlPicBulletId (Picture Numbering Symbol Definition Reference) reads: “This element specifies a picture which shall be used as a numbering symbol for a given numbering level by referring to a picture numbering symbol definition’s numPictBullet element”

But the numPictBullet element is named “numPicBullet” in the clause 2.9.21

Part 4, Section 2.15.1.18 characterSpacingControl (Character-Level Whitespace Compression) reads: “The characterSpacingControl element has a val attribute value of ‘dontCompress’, which specifies that no character compression shall be applied “

But the dontCompress element is named “doNotCompress” in the schema annexed.

The section 2.15.1.10 names in six contiguous lines of the same page ( page 1118 ) the “Automatically Hyphenate Document Contents When Displayed” element with three different names:

“autoHypehenation” in line 18
“autoHypehnation” in line 20
“autoHyphenation” in line 14

The entire Part 4 should be reviewed to find and correct all the occurrences of elements and attribute names and it must be assured that they are given an unique name through out Part 4. The name must match the corresponding schema submitted as DIS 29500’s annexes.

ECMA should be banned during one year of submitting fast-track DIS, and should be warned to not submit such poor, copied and pasted specifications derived from an internal Microsoft product documentation.

——-
Part 4: throughout

Case mismatch in elements and attribute names are given all throughout Part 4. Examples:

Part 4, Section 2.3.1.33: “…If the beforeAutoSpacing attribute is also specified, then this attribute value is ignored”

In the schema annexed is referenced as “beforeAutospacing”

Part 4, Section 2.3.2.24: “If the csTheme attribute is also specified, then this attribute shall be ignored and that value shall be used instead.”.

In the schema annexed is referenced as “cstheme”

Part 4, 2.5.2.6 dataBinding (XML Mapping): “The custom XML data identifier, specified using the storeItemID attribute of the dataStoreItem element”

In the schema annexed is referenced as “datastoreItem”

All the occurrences of elements and attribute names in normative and informative text of Part 4 should be reviewed, and it must be assured that they match the corresponding schema submitted as DIS 29500’s annexes.

There exist open source validation tools ( saxon, libxml ) that can be used by Microsoft ( free of charge ).