Good on ya, Rick! Thanks for providing a picture perfect example of what a true standards advocate should represent.

Do you really need to know what a fullwidth character is to realize that specifying a global, international, universal and interoperable data format with clearly vendor-specific and presentational *bugs* like "autoSpaceLikeWord95" is not just wrong, but insane?

I think not. I also don't think either of the other bugs the Microsoft Office suite has to cater for (like Excel's faulty calendar) has any place in a global, international, universal and interoperable data format.

What Microsoft clearly has done is to serialize the binary Office documents into XML, then create an XSD schema based on it, tweaked the schema, added comments (or extracted comments available in the source code before turning it into a schema) and then published it as a "standard" specification. How Office treats documents and represents them internally is up to Microsoft; they can do it however they wish. But standardizing all of these bugs and awkward behaviours and with that demanding that all other vendors implement (often by reverse engineering how Office does it, because the OOXML spec is silent on the algorithms required to implement it) the exact same bugs is not a way to create standards.

If Microsoft has to cater for spaces in Word 95 documents, then they should do that internally in their conversion engine and let the output to OOXML be clean and interoperable. That's not what they have done and that's what most of the world is screaming and tearing out hairs about.

If you can sit with a smirk on your face and confidentally say "OOXML is elegantly designed with interoperable implementations as a primary goal" you have either not read the specification, not understood it, or you're lying. There's no different opinions to have about it: OOXML is ugly and it doesn't deserve to be an ISO standard. And even with all the constructive comments in the world thrown at it, it will still look ugly, because the only focus ECMA and Microsoft has it that it stays interoperable with Microsoft Office and nothing else. Period.

Asbjørn: Yes, you do need to know the details. How could it be otherwise? That we should give credence to people who don't know what they are talking about? That may work on Slashdot, but not for standards.

As a balding person myself, I have sympathy for your desire to prevent unnecessary hair loss, which is why it is important for people to reserve their hair-tearing on important issues.

However, what you perceive as smirking is merely astonishment at your argument: you are claiming how bad it is that MS "demand"s implementation of "all these bugs and awkward behaviours", but you use as an example something that has big warning labels "DO NOT IMPLEMENT" on it?

To properly judge the autoSpaceLikeWord95 issue, you would need expert understanding of Japanese typesetting, text processing and archiving issues: the zenkaku and hankaku characters, the kinsoku rules, whether the issue has caused practical archiving problems for Japanese (or rather, CJK) documents, and so on. Do you have that?

You mention that the MS engine should generate clean Open XML without this kind of wrinkle: however, by default that is what it does when you open an old file (as far as I can tell): however, if you opt to preserve the old compatability elements, for example because you have some kind of archiving or specialist need, all this element does is give an extra hint that may be useful in some marginal case for a real specialist to use. If someone is converting old data, and it suffered from strange formatting for its fullwidth characters, then the poor programmer has an extra help to figure out what to do.

Of course no algorithms for typesetting, line-breaking, hyphenation, etc are spelled out, because a standard for documents has to be application neutral, and those things belong to the engine. (The CJK kinsoku rules are an exception here, because they are standard.) ODF is exactly the same here.

Finally, if you can write If you can sit with a smirk on your face and confidentally say "OOXML is elegantly designed with interoperable implementations as a primary goal" you have either not read the specification, not understood it, or you're lying. then you obviously are living in some black hat/white hat world

I think the problem is that you need to understand that OOXML has very different design rational than ODF has. While the first paragraphs of the introductions to the two specs are quite similar, the second paragraphs clearly set out the differences. Your problem is not with these details, and certainly not with this particular detail, but with the scope; you should be refuting those goals rather than complaining that OOXML does not meet ODF's goals well. You should be proving that there is no requirement for exposing arcane information from legacy data to provide an adequate base-line format for archive-retrieval; or indeed that there is no need for standards in the area of base-line formats; or that the text processing industry's decades long call for MS to open up its formats was all misguided or has been superceded by ODF, if you want to make a case.

"Good on ya, Rick! Thanks for providing a picture perfect example of what a true standards advocate should represent.
M. David Peterson | August 28, 2007 03:44 AM "

I prefer other type of "advocacy" of true standars, not headstrong, obstinate or pational ones.

I believe that comments produced by people like Frank Farance, Patrick Durusau, Jon Bosak ( one of the XML creators! for god sake ) to keep the quality assurance of standardization and standards is the *true* way to go if you really care about this.

I'm shocked that people that *work* with XML ( like Rick ) defends implementations ( like OOXML in his actual form ) that will only hurt XML in the long term. Remember, XML is here now, but if we don't keep its original goals, the lifetime of XML ( and this blog too :-( ) could be more short than expected, or it will be used just for "tag" things, without another added value.

Long life to standards ! Long life to XML. And no more rushed things at ISO!. ISO NB's: please respect and honour your jobs. Don't let commercial "partners" get inside this organizations and divert the objectives of the NB: give to us good and usable technical material ( we don't want just internal documentacion of products disguised as DISs ).

Orlando: I too was one of XML's "creators" as a member of the then XML WG (as was Len), not to be confused with the XML ERB which is now known as the XML WG). I know and respect Jon and Patrick, despite their obstinate refusals to agree with me on every issue.

What "goals" of XML are you referring too?

I have read people using XML's "Goals" (given in the XML spec) to judge other technologies. But that is simply not their purpose. Their purpose was to guide XML's development effort, not to create a manifesto. For example, "Terseness is of minimal importance" served as the gatekeeper to remove SGML shortrefs, omittag and other minimization, and to get rid of large tracts of waffle.

Read the comments I submitted: you will see that they are very much concerned with standards quality issues. Indeed, IMHO much more so than just submitting ad hoc comments on individual issues without seeking the principles behind them, without trying to identify root causes, and without prioritizing issues so that the most pressing are dealt with first.

Microsoft is ready to adopt Opendocument as a format, first for the European Union and other government customers. Ecma-376 is specified and is 'there to stay'. ISO Standardization serves the sole and single purpose to weaken ODF.

The ECMA agreed (fast-track response) that Open XML is not a "clean" format but one with a certain history. A mapping of the old legacy formats. Doc will stay as the wordüprocessing standard format for some time. But isn't a tabula rasa with ODF better? Better for XML's sake, better for the future?

What is the gain when a semi-open format gets promoted as a replacement of an open ISO standard? Most of the problems, patent conditions and technical issues, are not subjective. But the problems of the format which hurt are the XML and anti-competitive market effects.

Ben: See para 2 of this blog on who else gains. "my industry, which is industrial publishing and markup, and we have been demanding it for a long time"

You write "But isn't a tabula rasa with ODF better? Better for XML's sake, better for the future?" as if you could make existing documents (which use features that ODF does not support) disappear in a puff of smoke.

What do you mean by "replacement"?

Which "patent conditions" are not clear enough for you?

Quoting Rick:
To properly judge the autoSpaceLikeWord95 issue, you would need expert understanding of Japanese typesetting, text processing and archiving issues: the zenkaku and hankaku characters, the kinsoku rules, whether the issue has caused practical archiving problems for Japanese (or rather, CJK) documents, and so on. Do you have that?

Assuming I have those qualifications, how would that help me form an opinion regarding autoSpaceLikeWord95, since the feature isn't documented in OOXML? Are you actually offering an argument for autoSpaceLikeWord95 on linguistic grounds, or are you simply stating that you won't accept the argument of anyone without a PhD in Japanese typesetting? Furthermore, are you suggesting that someone would need advanced linguistic and typesetting knowledge in order to implement OOXML?

If someone is converting old data, and it suffered from strange formatting for its fullwidth characters, then the poor programmer has an extra help to figure out what to do.

If the legacy data is converted to a format where that information is stored using well documented styling, why would he need those hints at all? For that matter, exactly what does one do with a behavioral or presentational hint when one doesn't know what it means?

Of course no algorithms for typesetting, line-breaking, hyphenation, etc are spelled out, because a standard for documents has to be application neutral, and those things belong to the engine.

That's not my observation for standards like CSS and HTML. The lack of definition in how to handle layout, parsing and other details has been disastrous for Web developers and hindered the development of Web apps in general. Just look at how much damage IE's initial implementation of the CSS box model has caused and imagine if CSS had never defined the box model at all, but left it as one of "those things belong to the engine".

ODF is exactly the same here.

How so? Shall we take your assertion on faith?

I think the problem is that you need to understand that OOXML has very different design rational than ODF has.

No, we understand Microsoft's rational perfectly.

Your problem is not with these details, and certainly not with this particular detail, but with the scope; you should be refuting those goals rather than complaining that OOXML does not meet ODF's goals well.

OOXML doesn't even provide the detail necessary to accomplish the stated goals, and I my opinion Microsoft has given no satisfactory answer as to why ODF can't be used to accomplish the same goals. You can argue that competition between standards is beneficial, but for whom? The developer who has to devote greater resources to support an additional standard? The users that have to deal with ensuring they have software for both standards so they can handle whatever files are sent to them? The IT department that has to buy additional equipment and media to store multiple copies of the data? Ah, but we both know that what's really going to happen is that when standards compete, only one wins, so there's little point in approving two in the first place. It would be a far better argument to say that OOXML DOESN'T compete with ODF. Unfortunately, that would cut the legs out of Microsoft's argument against supporting ODF...

Which "patent conditions" are not clear enough for you?

Supporting OOXML documents requires on to support technologies referenced but not defined inside the specification. However, my understanding is that the patent covenant only covers what is actually defined in the specification. Therefore, complete support for OOXML files, through the support of the referenced proprietary Microsoft technologies, would open one up to a patent lawsuit.

There were also concerns about potential lawsuits regarding from other vendors whose materials are referenced by the specification.

Well Rick, leopards don't change their spots.
I was at the Standards Australia forum on 8 August where you argued vehemently for a 'yes' vote on DIS29500. Don't try to suggest that 'no with comments' has been your position all along. That is simply untrue. You have been an OOXML fanboy all along. You've changed your position because you see that 'no with comments' is going to be the worldwide consensus. You are just trying to protect potential sources of income by pretending that you have always had an open mind about the value of OOXML. That is a gross misrepresentation of your position.

I agree with you, and with your logic. It is frustrating at times differentiating between those who hate the idea of Microsoft even suggesting a standard from those who have issues with the specs as they are currently written. As I have said elsewhere, I think Microsoft made a mistake early on in not listening to some of the comments before they charged ahead. I don't think it would have changed the votes considerably, but I think it would have made a much more reasonable set of No with Comments issues that could be resolved. Right now, I think there is too much of a sink or swim mentality where the sense is that Microsoft has to "trick" people into voting Yes with Comments because then they won't really have to deal with the issues. If more of the issues had been dealt with up front, I think that Microsoft could have been more comfortable with a mix of Yes, No and Abstain and worked the problems out to get to a standard. Now, they risk making so many enemies that they can't get the issues resolved at all. Which would be a shame, as a better OOXML spec would be a bonus for all of us, whether or not it was an ISO standard. As it currently stands, I'd advocate a No with Comments stand for any country, but I fear that the current push is for politics over technology, so that some countries will Abstain who should have voted No, and others will vote Yes when they should have insisted on the issues being resolved first. I guess time will tell, but I don't think Microsoft or Ecma have done themselves any favors by resisting earlier changes. As in most technology, change gets more expensive the further you push it down the line.

Droo: If you got the impression that I was endorsing a simple Yes vote at that meeting, that was not my intention nor my position and I don't know what gave you that impression. It is the disctinction between being in favour of Open XML becoming an ISO standard, and the particular vote that is appropriate for DIS 29500. The dumb press conflate ballots on the draft with a ballot on the technology. I think standards people tend to assume that people know the difference between a technology and a draft and this may cause confusion.

To be clear, I had previously told Standards Australia staff that I favoured a "No with Comments" vote, as my favoured route towards acceptance of the standard.

The process is this: we gather the problems and suggest fixes. If the problems for which there are no fixes are serious enough to block the standard, then the correct vote is "No" (IMHO there are no unfixable problems that are of this kind of seriousness); if there are problems that are serious enough to block the standard that can be fixed, the the correct vote is "No with Comments" (which is the route I am recommending); if there are technical problems but they are not so serious that they would prevent acceptance of the draft, then a "Yes with comments" vote is appropriate; if there is some positive national interest (i.e. people who don't want something and wouldn't use it ultimately don't count in the equation, unless they can make technical contributions in good faith), otherwise (and especially if there is not the technical expertise to understand the standard) then "Abstain".

I was not asked at the SA meeting to speak on the topic of which particular vote on the draft I recommended, and I specifically tried to avoid commenting on a particular vote in that 10 minute presentation. I tried to limit my comments in the 10 minute presentation to backgrounding (particularly SC34 and Australia's involvement and priorities) and how knowledge of precedent lets us resolve general technical/procedural issues (such as whether there can be multiple standards and so on); of course from the POV of someone who thinks it would be reasonable and beneficial to have Open XML as an ISO standard. But not as someone who thinks that this necessitates a simple "Yes" vote.

For example, during my presentation I specifically mentioned that Australia's position on SC34 standards in the 90s had been against complexity and towards simplicity: someone reported this as "Small is beautiful", though size is not completely related to complexity. Anyone with a brain would realize this is a principle that would impact the acceptability of DIS 29500 the draft as well as potentially Open XML the technology, and from the murmur in the audience, I believe the audience indeed had a full complement of brains. And it is something I carried through in my submission.

Furthermore, my view (based on reviewing dozens of standards) is that it is important to review technologies using explicit principles rather than ad hoc. When discussing this approach, at
http://www.oreillynet.com/xml/blog/2007/05/reasonable_principles_for_revi.html
note that Principle 1 raises an issue that would (IMHO) require a No with Comments vote. "No with Comments" where the comments are sensible has never been a problem for me, nor would it be for anyone who has participated at ISO (SC) meetings: it is the press and PR and newcomers who want to make it gladatorial. The thing is that it is the technical and editorial issues, their seriousness and their resolvability that determine the vote.

That I have no objection to "No with comments", see http://www.oreillynet.com/xml/blog/2007/07/10_corrections_to_open_xml.html

The day after the seminar, I wrote that I thought the IRI issue was strong enough to 'force' a conditional yes vote
http://www.oreillynet.com/xml/blog/2007/08/native_language_markup_issues.html
so my spots must have changed fast :-)

Or my comment on XML-DEV http://www.oxygenxml.com/archives/xml-dev/200708/msg00081.html
"Having a "No with comments" vote with good meaty comments is actually a really good thing, for getting a good standard."

In order to encourage "No with comments" votes for NBs that need it, I have even pursued the issue in SC34 circles of whether poor NBs can participate by teleconference (it seems they cannot) or use a proxy in the meetings (it seems they can.)
http://lists.dsdl.org/dsdl-discuss/2007-06/0009.html

I have also pursued the issue of splitting up the standard, which on the assumption that this would require a BRM and therefore a "No with Comments" vote:
http://lists.dsdl.org/dsdl-discuss/2007-04/0019.html

And I have not made a secret that I regularly email with one of the most prominent pro-ODF standards figures, discussing issues which assume a BRM and therefore some "No with Comments" votes. It is simply not something that I am or was antagonistic to.

Cheers
Rick Jelliffe

Ben: An guy very involved at a large company recently wrote to me privately that "At the highest level, though, I feel XXX has been incompetent, XXX has been sleazy, and XXX has been coy."

I leave it to the users to fill in XXX: hint, they are all large US multinationals :-)

I think engagement with ISO and this odd process has certainly been a challenge for MS, but if I may be Little Miss Sunshine for a few cliches, I think many in MS recognize this as an opportunity to engage with users more. MS has a sharp need both to address anti-trust considerations with hard action like this standard, and to re-engage with their lost system integrator market. Open XML looks like succeeding on both counts, for better or worse.

However, I know that at least some people in MS recognize that this is just the first step: that the judgment on the success of openness and engagement will come from how well MS' development process embraces the standards process. MS has always had a high priority on control of the API, and 25 years of groupthink does not always make for the best product. If the standards process can give them good feedback and an alternative and authoritative source of requirements and review, but without the danger of being captured by their opponents, then they win and we win.

On the issue of votes, I have mentioned before (in relation to ODF) that the problem with the fast-track process is that in some national bodies the decisions will be made by the JTC1-equivalent committee, not the SC34-equivalent committee. These are not people who are necessarily competent in Document Description and Processing Languages, and they can be expected to favour simple votes rather than "No with comments", which (while correct under the procedure) would be really unfortunate.

The other issue is that of "consensus": this is rarely the same as unanimity (though it seems that in Sweden it is, if the reports are correct), but each national body adopts different processes because each nation has different cultural values.

A big standard will have a lot of changes. If my 30 page standard had 10 changes in its final stages of national review, then DIS 29500 will have about 1000 changes at the same rate (assuming it has 3000 normative pages, which is probably too much). That is just the slog in getting a standard out the door, tedious work not a cause of panic.

Matthew: MS OPS is as follows (with my emphasis):

Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification (“Covered Implementation”), subject to the following. This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise. If you file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification, then this personal promise does not apply with respect to any Covered Implementation of the same Covered Specification made or used by you. To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification. “Covered Specifications” are listed below.

This promise is not an assurance either (i) that any of Microsoft’s issued patent claims covers a Covered Implementation or are enforceable or (ii) that a Covered Implementation would not infringe patents or other intellectual property rights of any third party. No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise.

So the big issue is what, in common industry legal usage, is a "required portion". For an example of that, we can see IBM's definition, which they give in a footnote to their license
"Required Portions" are those portions of a specification that must be implemented to comply with such specification. If the specification prescribes discretionary extensions, Required Portions include those portions of the discretionary extensions that must be implemented to comply with such discretionary extensions.
http://www-03.ibm.com/linux/opensource/isplist.shtml#def1

So where there is only one way to do something, even something optional, that becomes a required portion, even an external technology.

For other information on what a "required portion" could encompass:

W3C's draft mentioned it A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the required portions of the Recommendation. Existence of a non-infringing alternative shall be judged based on the state-of-the-art at the time the specification becomes a Recommendation. http://www.w3.org/TR/2001/WD-patent-policy-20010816/#def-essential
however the final W3C policy replaces "required portions" with "normative portions" which is much clearer but does not alter the impact IHMO.

MS's public comments on this are important too: VP Jason Matusow has written
What it all boils down to is an irrevocable, legally-binding promise that we will not sue anyone who builds an implementation of Open XML based upon the Microsoft patents necessary for that implementation.
http://blogs.msdn.com/jasonmatusow/archive/2007/06/29/open-xml-and-odf-what-do-you-want-to-encourage.aspx#3661829

and later brings out the difference between what the format needs and particular application functionality
I understand what you are saying about the programs that process and depend on it. Yes, we do have patents on the features/functions/UI etc. of MS Office - but that is separate from the file format. The folks at Novell, or anywhere else for that matter may build a partial or complete implementation of Ecma Open XML and be covered by the OSP.

Note also MS' Dave Welsh brings up case law for resolving ambiguity in this area (my emphasis): This clarity is particularly important in light of recent case law that places heightened obligations on SDOs to clearly define the difference between required and optional portions of their standards for licensing purposes. (See, e.g., Intel v. Via Technologies, 319 F.3d 1357 (Fed. Cir. 2003) (holding that, since ambiguity existed as to whether a particular protocol was included within a required portion of a standard and therefore subject to a reciprocal royalty-free licensing agreement, the ambiguity would be resolved against the drafter and, thus, there was no infringement by VIA Technologies for royalty-free use of the protocol in question http://blogs.msdn.com/dave_welsh/archive/2004/09/09/227600.aspx

Ecma has a requirement for RAND licensing of all patents that are "covered" by a standard, which seems a little vague, but much include necessary technologies if it has any meaning.

See also my blog "Material on Standards and IP"
http://www.oreillynet.com/xml/blog/2007/08/standards_and_ip.html
You should particularly read that ConsortiumInfo page (and ignore all its parroting gossip pages): it is very informative.

I have to agree with Rick. Anyone holding up XML as 'the way to get it done' wasn't there to do it. It was agonizing and left some substantial wounds. In my words, not Rick's, and I've said this often enough to earn some 'frenemies' among the 'luminaty,
we burgled ISO. A self-selected self-appointed self-governing group set out to fix perceived ills and recruited enough of the rest of the gang to get it done. In so doing, we created a wildly successful specification but we set a horrible example of
force and the use of the gong and klaxxon over reasonable and legitimate process.

We could do that because it was early in the web emergence and because the SGML community was very small and most of us knew each other by personal acquaintence or reputation. Eventually most of the leadership joined in and because of our size, we shared certain core values. Those values more than our talent made it a successful effort. Keep in mind, by gutting it we also knocked off parallel efforts that had been slowly coalescing hypermedia standards from dozens of earlier efforts. In effect, we scuttled some honest designs in favor of a mickey mouse language called HTML which today even Steven Pemberton says is a 'mess'. What we did manage to achieve was to bring in major companies to work together.

If the web has really made any difference, it was that. Working together is possible even if difficult and even if sometimes not in the best interests of the locals.

The anti-OOXML lobbies believe they are doing the right thing for the most part, and some are. Others are acting in knee-jerk fashion to fight The Big Bad as if they were Buffy's Scoobies. Some are cynically using them to advance their own BigCo agendas for increasing revenues. Microsoft has an agenda too. Because competitive procurements have been changed by political mandates, they have to create a standard or their own customers will be paying large switching costs.

1) If the lobbies would show some patience, the market would work out the differences here. I've explained this and won't repeat it.

2) If we keep using The Dopiness of Crowds to drive the agendas, we undo the best thing the web achieved: a push to standards processes under professional oversight.

3) XML set a terrible example because it was successful. I don't claim it was nefarious. It wasn't. It was desperate but ever since then, people applaud us the same way they applauded the main character in Clockwork Orange. This combination of voracious press and mythologized hero making is a dumb dumb way to create standards. Tipping points, wisdom of crowds are BS lads. Simply BS. This is what comes of stylizing history as if it were a one hour dramedy.

Two standards ARE better than one because neither will last and while their successors get ready, customers have a pretty good deal. Be sure what you are asking for has a benefit for them that they can immediately perceive. Massachusetts didn't back down because they were bribed. They backed down because they are self-interested, just as we were. We needed systems that were easier and web-fieldable. They need to keep their own processes affordable and still be able to procure competitively.

This bitter butter battle may result in some reforms of processes at ISO. If so, that will be the only good that comes of it.

Microsoft accused of buying Swedish votes
http://www.thelocal.se/8324/20070829/

Droo #2: You speak about my potential sources of income as if you know anything about the subject?

In fact, I don't have any expectation to get any more work from MS, directly or indirectly. I certainly hope there will be some pay-off for Open XML related conversion work: we are working on a validator for embedded custom XML at the moment, for example, but AFAIK that would be technology for our normal kind of customer (who tend to be military/publishing/government). If MS wanted to buy it, great; if IBM or Sun wanted to buy the equivalent code for validating foreign elements in ODF, then we would be more than happy to work on that too (the difficult part is making the XSLTs to convert from XSD to Schematron conversion, not the Xpaths into the OOXML or ODF.)

The thing is that IBM and MS and Sun and so don't care about factions: whether you are working on their project this week or a competitor's project next week is not an issue of concern for them; it is just business, and I don't have any fear that doing a job for company A last week will prevent company B from becoming a client next week, if they need me.

The small amount of paid work for MS had finished by the time of the SA meeting (there had been a late engagement on the Monday)--I made it clear to SA that I would be participating on behalf of Topologi not MS or Ecma etc--. MS have not mentioned any other engagements (I was doing training more or less on an emergency basis, and my deep lack of knowledge of MS products probably got in the way, though hopefully counterbalanced by XML knowledge) and we are not pursuing MS as we would for expected regular business. (However, we found them excellent and interesting to work for.)

TT: ZZZ

reading all the comments and the looong responses of Rick ( with 0% autocritic and totally defensive ) i would like to repeat my self:

I prefer other type of "advocacy" of true standars, not headstrong, obstinate or pational ones.

Greetings to everyone.

@len:

Clockwork Orange is interesting topic in itself: Burgess wrote it in part as a demonstration of the way that dialect (in this case, russian teenspeak) can infiltrate culture through repeated exposure. By the end of the book, ostensibly, you develop an affinity for the characters based on the shared dialect, to which you have become an insider, and so come to their defense; a scary proposition.

Language is viral, and in a similar fashion, XML is viral, and no standard is going to ruin it, or its supposed goals. But, there are large numbers of people who will defend it from supposed detractors simply based upon a common dialect. There are plenty of standards that just don't apply to me; I ignore them.

@piers:

Burgess got the part right that it is frequency and not amplitude that causes the infiltration of the signal. Somewhere on my personal blog I talk about semiotics uses by governments to persuade otherwise rational people to do things they wouldn't otherwise. In that blog and the responses to a commenter, I talk about frequency vs amplitude modulation. Better to speak often quietly than to yell loudly once or twice or at all. At some point in another forum, that would be a fun topic to thread on.

The sociologists called those dialects 'argot' when I was in school and it was a means to identify and document 'cliques'. In police work gangs are identified by 'scars, marks, tattoos' (SMT) and fields are now added to the databases for digital photos of gang graffitti. Plotting the migration and changes are another way to study the spatial and temporal dynamics.

The phrase that haunts me through all of this (and I don't have any skinny in this battle either) is the one spoken by Derek Jacobi in "I, Claudius" (a name we share):

'by dulling the blade of tyranny, I reconciled Rome to the monarchy'

and this time it appears the mob will get exactly that.

Orlando: You are very welcome to repeat yourself in your battle against obstinacy. And to be profess being shocked and at the same time warn of the dangers of passion. And to want people to care but not want them to be headstrong.

Too much of something is indeed a bad thing.

"I was in New Zealand on completely unrelated business and I was invited to speak at an Open Source meeting, but some of the attendees seemed to think I was there in MS’ employ."

Hi Rick. Are you sure this was the case. When I introduced you to the meeting and then in your talk your status was made very clear.

Cheers
Don

"how many self-assured people have raised “autoSpaceLikeWord95″ who have no idea what a fullwidth character is, for example?"

I imagine you could look up fullwidth characters in a specification. To use “autoSpaceLikeWord95″ Microsoft says I need a copy of Word95 and a ruler held against the computer monitor.

@rick

"What "goals" of XML are you referring too?"

1.1 Origin and Goals

[...]

The design goals for XML are:

1. XML shall be straightforwardly usable over the Internet.
2. XML shall support a wide variety of applications.
3. XML shall be compatible with SGML.
4. It shall be easy to write programs which process XML documents.
5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
6. XML documents should be human-legible and reasonably clear.
7. The XML design should be prepared quickly.
8. The design of XML shall be formal and concise.
9. XML documents shall be easy to create.
10. Terseness in XML markup is of minimal importance.

Extensible Markup Language (XML) 1.0 (Fourth Edition)
W3C Recommendation 16 August 2006, edited in place 29 September 2006
( http://www.w3.org/TR/2006/REC-xml-20060816/#sec-origin-goals )

Ruddiger: Yes :-) But measuring is the only way to figure out most typesetting details, and even then it is difficult.

For Word95, you would also need to install a Japanese version of Windows 95 (this was pre-Unicode when they had forked to seven different versions of Word around the world, depending on the script), with Japanese printers of that time (for the drivers), and with Japanese fonts from that time.

When I tested it in Word2007, I could not get any difference in line-breaking, trying with many combinations of fullwidth, kanji and latin letters, to see how line breaking and letter spacing were affected. I couldn't get any difference, so it seems that the effect is subtle or some rare characters (or fonts or printer drivers, etc) or that Word 2007 doesn't do anything with that information (hence the deprecation.) This would make sense if it were some outright bug in one version that they have buried a decade ago, with only this little flag as its tombstone.

It is wonderful that people are saying "OOXML should not be a standard because it does not give me enough information to reproduce an obscure Japanese bug from one version of Word 12 years ago that is clearly marked as something that shouldn't be reproduced." Laughable. No sense of proportion.

Orlando: You are just trolling, I think.

Those goals were the development goals of the XML specification, not rules about markup in general. To use them to justify or critique the markup in a document goes far beyond what they were intended for: to guide the profile of SGML for Web use.

@ruddiger
It would be useless to just measure spacing in word 95. Because then you would know the exception rendering.
But the exception of what ?
The spec does not describe default/standard rendering. That is all up to you.

hAl: And, in any case, a "fullwidth" character would be expected to occupy one ideographic space in size: anything other than mild kerning or line-fitting breaks the "fullwidth" semantic, one would think. The issue is most likely to be some kind of line-breaking foul-up at transitions between character classes (e.g. related to punctuation, but that is complete speculation, but we don't know. (And I suspect MS US doesn't know either: that this may be some legacy that they would need to look up the Japanese code for. But again, speculation. This is something that the Japanese National Body should decide on, not us.)

If "autoSpaceLikeWord95" or any of the other non-described binary flags that exist in OOXML are supposed to be implemented by any other entity in the universe except Microsoft, then can you please explain to me what in the name of all that is holy it is doing in a standard specification?

If people needs backward compatibility, they should get that from opening the binary Office documents in Microsoft Office 2007. When saving to OOXML, they should get everything preserved, but in the new, (and I'd like to believe) enhanced OOXML semantics. If OOXML can't preserve this semantic without adding non-described flags like "autoSpaceLikeWord95", it is a poorly written specification and it will hurt interoperability.

In fact, anything that isn't elevated to a high enough semantic level in the design of a format will hurt interoperability, because the exact functionality described will be (like in OOXML's case) tied to a specific implementation. Other implementations of the same functionality will differ, especially in OOXML's case where a lot of stuff is left to the implementor's imagination, and that will hurt interoperability. Either you elevate the semantics to not cater for the details (and then convert legacy documents to fit into the new semantics) or you describe the details, well, in details.

In OOXML, the details are specified, there has been no semantic elevation from the binary documents whatsoever, and the details are basically undescribed. Only Microsoft will be able to implement it correctly, because they are the only one who knows what these flags does.

Not to mention all the other parts of OOXML that uses plainly incorrect dato formats and calendars (this should be elevated and converted too, it has no place in a standard), depends on non-standard markup languages that also aren't specified (VML), etc. OOXML is so full of errors and is such a badly written (technically) specification that it's painful to read.

Will Australia be able to vote in the ISO process?
We have observer status according to
http://www.iso.ch/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeParticipationListPage.TechnicalCommitteeParticipationList?COMMID=4767

Flint: For this kind of vote, it is open to both P and O members I believe. There will be many votes. It is an excellent result for standards: the more people get involved in their local, international and industry standards bodies, and get governments to increase their status and scrutiny, the more that we the public have an alternate voice with the big boys.

People are also seeing how different procedures around the world reflect different cultures and lead to different outcomes. Is the current Australian one suitable for us? Well, last decade we had an actual dedicated committee, but when the action moved to the boutique standards bodies (W3C, OASIS) and when the TCP/IP family won over OSI, it dwindled. There is still a committee, but it is more connected with SC29 business than SC34 if I understand correctly.

People who are interested in joining an SC34-equivalent standards committee in Australia, please contact Alistair Tegart at SA. He has been interested in re-forming this committee for some time, and even approached me a while ago (I was delayed by health, business and ISO involvement, so I didn't pursue it then): however, a lot of this standards work is about things that may not interest people: font standards, topic maps, and schema languages are the main work items. If you are interested in ODF and OOXML work only, then best to join the OASIS and Ecma efforts.

However, if you have some need for a new standard in the area of Document Description and Processing Languages, that doesn't fit in with the directions of OASIS, W3C, IETF, or Ecma, etc, then pursuing it through your local standards body and ISO is a good avenue.

Now this is a collective voice, not an individual voice, so you cannot get too attached to what happens to individual comments: Standards Australia may completely throw out my suggestions, for example. But hopefully they are in the mix somewhere and will add some gravitation pull in the right direction.

@orlando:

The goals were a pretty good guide if the real goal was to get it out the door before a competitor does without regard to quality or specificity of follow-on efforts.

By the time XML was being specified, a smallish group had years to argue about the merits and demerits of XML all the way back to the days of GenCode (look it up). So this was a pruning exercise for the most part informed by some specific and some superstitious assumptions about 'straightforward usability'. Terseness, for example, was a counter to the "networks only works with small packages' that informed HTML design and which a) resulted in HTML as tag soup and global means to check for extensions and b) is only true in specific applications. Note that no successor to HTML after three quick evolutions has had that much impact. XHTML 5 is almost a distant pipe dream not that it can't be specified, but that it can't be fielded without cutting the browser away from 90% of the web (Google's estimate). So HTML is web kudzu now. Nothing else grows there.

Terseness is very much a concern for some applications. On the other hand, few acknowledged just how pervasive XML would become because a) graphics communities had fought SGML since it's inception then allied with the WYWSIWYG vendors and b) no one was honest about the practice even then of writing a DTD/Schema and calling it a standard. The 'wide variety of applications' was the clue. In effect, few understood the perniciousness of the standards game when played at Internet-scale.

We could have a long thread on the impacts of the various guidelines you list on the evolution and dissolution of different technologies and communities. The one most pernicious but useful for the ERB was 'shall be prepared quickly'. It enabled any prolonged technical debate to be cut off quickly in the rush to push the specification out the door. It enabled it to be small enough for Jon to throw it to the floor, a stunt but effective media-wise, ignoring what we all knew: the bulk of the work would be done in separate committees and organizations and would go on for years. Compared to SGML, the evolution of XML has actually taken a lot longer if when you say "XML", you mean all of the various systems, standards and specifications required to create a true interoperable framework of frameworks.

All XML achieved was loose data portability one step above a CSV file. Full stop. Everything else was done post-hoc.

OOXML/ODF are very different beasties in that they attempt to do for a family of specific applications the same thing in a single document. As soon as real interoperability is a goal (and it really wasn't for XML and never has been), the job is several orders of magnitude harder technically and a few thousand orders more difficult politically given what that does to a market (it flattens it).

So here we are in 2007 yearning for the good ol' days of ten years ago? That means standards now have the lifecycle of a pop hit on American radio.

Rick: You've misread the license. It does not say just "require portions". It says "required portions of the Covered Specification that are described in detail and not merely referenced in such Specification". Thus, if the specification references "autoSpaceLikeWord95" but does not describe it in detail, you don't get any related protection from patents. If OOXML refers to Windows Metafiles, but doesn't describe the format, guess what? No patent protection for you. How someone else defines the mere words "required portions" is irrelevant.

Furthermore, how are we protected from patent lawsuits by third parties WHO ARE DIRECTLY REFERENCED in the specification? For instance, I believe there is an element in OOXML for WordPerfect text alignment. Does Corel have an OOXML patent covenant? Did Microsoft license the necessary patents from Corel?

Matthew: I think your use of "directly referenced" would not accord with how a court would interpet it. The court cases, equity and public policy all go the same way on this one. Microsoft's multiple statements similarly would make it impossible for them to do anything.

Indeed, a MS representative at a standards meeting I attended said that MS was not, in fact, a litagious company (despite the sabre rattling). The idea was that they viewed their patents as defensive rather than offensive weapons.

Of course MS cannot grant protection on anyone else's patents. But the whole business has been based on reverse engineering each other's behavours since the beginning, and there have not been law suits over the reverse engineering has their?

I think you may be making the mistake that XML documents contain procedural markup; instead they contain (or can be presumed to be, except in rate cases) declarative markup. In other words, all the elements are hints and you can choose to interpet them how you like. The more you want your application to act like some other application, then you have to get into reverse engineering; markup languages give you the decision points to key behaviour and style changes off, if you choose to, but only the most basic overview of what the behaviour is. Looking for typesetting details will only disappoint; the standards don't operate at that level of detail.

The goal of separating document description from document processing is of course the SGML distinctive, courtesy Charles Goldfarb et al, which XML is the most recent version of.

I agree wholeheartedly with your position. You may be interested to know that Standard Norway today announced that it will vote "No with comments" - and also made it clear in a press release that this is actually the equivalent of a conditional approval according to the JTC1 directives:

9.8 Votes on Fast-track DISs
Note: Conditional approval should be submitted as a disapproval vote.

I strongly urge other national bodies to follow Norway's example.

Asbjørn: Yes, you do need to know the details. How could it be otherwise? That we should give credence to people who don't know what they are talking about? That may work on Slashdot, but not for standards.

The autoSpaceLikeWord95 issue (and it's not the only one) requires vendors to implement behaviour that is not documented, not even referenced, anywhere within the specification. It's not difficult to understand.

This becomes important, because these elements are for backwards compatibility purposes, and presumably quite a few old Microsoft Office documents will be converted using elements such as this. Without knowing how to handle this behaviour then those documents are only readable by Microsoft Office, which renders OOXML as an implementable format null and void.

You're not disproving him, and you're not helping your own argument (whatever it is), but it's the usual meaningless amble we get when anyone tries to defend how OOXML does things. We then rinse and repeat next time.

However, what you perceive as smirking is merely astonishment at your argument: you are claiming how bad it is that MS "demand"s implementation of "all these bugs and awkward behaviours", but you use as an example something that has big warning labels "DO NOT IMPLEMENT" on it?

Then why is it even in the specification? It should simply have a line put through it now, with DEPRECATED in red ink next to it. It doesn't, and there are no plans on the drawing board to take it out.

As indicated above, the problem with these elements comes when older Microsoft Office documents are converted to OOXML with these elements in place. OOXML is, afterall, a format for backwards compatibility purposes. How useful is it going to be if converted documents to OOXML cannot be universally read and manipulated?

I've talked about this before:

http://ponsaelius.blogspot.com/2007/05/openxml-as-iso-standard-what-exactly-is.html

I wrote:

The main, and only really, reason for being, that I've managed to pick up from Microsoft and various people, is that OpenXML exists for backwards compatibility reasons with, as they put it, the billions of Office documents already out there. Presumably, this is why sections such as this exist - for backwards compatibility reasons. Presumably, when older Microsoft Office documents are saved in the shiny new OpenXML format, elements such as this are used to preserve formatting. The only problem is that this behaviour is not specified.

We seem to be covering an awful lot of old ground, don't we?

however, if you opt to preserve the old compatability elements, for example because you have some kind of archiving or specialist need,

If you want to preserve formatting, and everyone will, then no other application other than Microsoft Office will be able to do anything with it. It rather renders the whole thing null and void.

all this element does is give an extra hint that may be useful in some marginal case for a real specialist to use.

How can anyone possibly know this, you included, if it isn't in the specification???!!

I think the problem is that you need to understand that OOXML has very different design rational than ODF has.

You keep coming up with this nugget as well, but as I'd explained above in my own take on things, this is absolutely irrelevant. Yes, Microsoft is perfectly entitled to document their formats in the way they see fit. However, the criteria for getting ISO status and getting to a situation where everyone can implement OOXML, handle it, and be happy, is an entirely different matter.

You should be proving that there is no requirement for exposing arcane information from legacy data to provide an adequate base-line format for archive-retrieval

Of course there is a requirement for such a thing - and that legacy data should be exposed to multiple software applications and vendors in an open format so they know what to do with it.

or that the text processing industry's decades long call for MS to open up its formats was all misguided or has been superceded by ODF, if you want to make a case.

Yet again, you're back to square one again. You're talking about Microsoft opening their formats when people are providing you with ample evidence that that is not the case - certainly not if you consider open to mean that other software vendors can do anything with said formats.

TT: ZZZ
Microsoft have even come out and admitted this one.

You might be choosing to fall asleep as to what is going on, but that didn't stop you from trying to tell us all that IBM and ODF's despicable supporters were trying to buy Malaysia - which there was no evidence at all for other than someone from Malaysia's standards body changing his tune on the matter, and that had nothing to do with alleged impropriety. It was simply a stark change in opinion. He didn't even name those allegedly involved.

A bit more background on why supposedly deprecated elements like these are a problem that I've written about before:

The real problem here is that incompatibilities, quirks, caveats and pitfalls in individual applications are simply being transferred from one format, the old binary doc format, to another with no appreciable benefit to anyone - least of all users. These pitfalls will continue to be inherited in successive versions of the document. The net effect is that anyone implementing OpenXML will have to deal with this inherited behaviour, despite Microsoft's disclaimer that applications should not use it. OpenXML, afterall, was invented for backwards compatibility reasons, remember?

Presumably, Microsoft finds this quite attractive, for obvious reasons.

Segedunum: You say "requires" but the standards says (emphasis added)

2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)
This element specifies that applications shall emulate the behavior of a previously existing word processing
application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a
document's content.
[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.

It is the opposite of required, it it deprecated! If a user wants to reverse engineer a product down to bug level, it gives the information needed to decide, but it doesn't go further than that.

When something is optional and deprecated, what sense of "required" are you using? If you want the standard to include detailed typesetting algorithms, you go beyond document description to application description.

Segedunum: What on earth are you talking about? Obviously not something in
http://www.oreillynet.com/xml/blog/2007/04/the_suspension_of_the_malaysia.html
where I say But if this represents a trend by standards bodies to get tough on personal attacks and so try to bring back a more professional and civil level of discourse, then that is great.

What is you evidence for this?
You might be choosing to fall asleep as to what is going on, but that didn't stop you from trying to tell us all that IBM and ODF's despicable supporters were trying to buy Malaysia - which there was no evidence at all for other than someone from Malaysia's standards body changing his tune on the matter, and hat had nothing to do with alleged impropriety. It was simply a stark change in opinion. He didn't even name those allegedly involved.

Steve: Thanks for your support. I appreciate it.

Don: I've re-read Matthew's list comments and amended the blog. Thanks for pointing that out. (I tried a few responses earlier, but managed to have the wrong end of the stick each time.)

And also, again, thanks to NZOSS for giving me the opportunity to talk. I had a really warm and enjoyable night.

Flint #2: Every different committee at each level of ISO has different P and O lists, depending on what each country has national interests and expertise in.

The list of SC34 countries, for example, is at
http://www.iso.org/iso/standards_development/technical_committees/list_of_iso_technical_committees/iso_technical_committee_participation.htm?commid=45374

which today (Sept 1, 2007) gives

Secretariat

* Canada ( SCC )

Participating Countries

* Brazil ( ABNT )
* Bulgaria ( BDS )
* China ( SAC )
* Colombia ( ICONTEC )
* Cyprus ( CYS )
* Czech Republic ( CNI )
* Côte-d'Ivoire ( CODINORM )
* Denmark ( DS )
* Egypt ( EOS )
* Finland ( SFS )
* France ( AFNOR )
* Germany ( DIN )
* India ( BIS )
* Italy ( UNI )
* Japan ( JISC )
* Kazakhstan ( KAZMEMST )
* Kenya ( KEBS )
* Korea, Republic of ( KATS )
* Lebanon ( LIBNOR )
* Malta ( MSA )
* Netherlands ( NEN )
* Norway ( SN )
* Pakistan ( PSQCA )
* Poland ( PKN )
* Romania ( ASRO )
* Sri Lanka ( SLSI )
* Sweden ( SIS )
* Switzerland ( SNV )
* Thailand ( TISI )
* Trinidad and Tobago ( TTBS )
* Turkey ( TSE )
* USA ( ANSI )
* United Kingdom ( BSI )
* Venezuela ( FONDONORMA )

Observing Countries

* Australia ( SA )
* Chile ( INN )
* Croatia ( HZN )
* Greece ( ELOT )
* Hong Kong, China ( ITCHKSAR )
* Hungary ( MSZT )
* Indonesia ( BSN )
* Ireland ( NSAI )
* Israel ( SII )
* Lithuania ( LST )
* Mexico ( DGN )
* Spain ( AENOR )
* Ukraine ( DSSU )

Now I am not sure which P and O lists apply: SC34 or JTC1. (I suspect it is JTC1 because New Zealand is not on this list, or the list may be out of date due to the upcoming change in Secretariat to Japan: things are happening fast.) But the difference between O and P members is roughly that there is a dual requirement for an absolute majority both of all members and also of P members. Which is why it is reasonable to expect that if enough nations tick the box marked that their vote would change if their comments could be resolved (as I suspect they will), that there will be a Ballot Resolution Meeting (i.e. after a further five months of scrutiny and discussion between National Bodies about each other's comments and possible approaches to solving them.)

Update: Norways vote is out, and it has some of the same general issues as me. They want a multipart standard, and they want to fix the scope rather than the title. They want extensibility rather than fixed lists.

(Click on the link at the bottom of this page.

There is only one I positively disagree with, and that is that the information model is unnecessarily complex. In fact, if the metrics I did last year still are anything to go on, Open XML is less complex than ODF. But opinions on whether to use elements or attributes typically are fashion statements: except if your data requires nested/structured properties, then you have to either use elements or invent an embedded notation. Property elements are nice for extensibility, because they can be marked up more: and application can add its own attributes to each property to say why or how it supported or mapped a property: this seems to be a useful thing to me (but I like Processing Instructions too, for the same kinds of reasons.)

It is the opposite of required, it it deprecated!

So what is it's purpose in there then?

If a user wants to reverse engineer a product down to bug level, it gives the information needed to decide, but it doesn't go further than that.

I've explained to you in pretty reasonable detail why it is required. An awful lot of old, Microsoft Office, documents converted to OOXML will contain tags that will render any non-Microsoft Office implementations null and void. I fail to see why on Earth the exact behaviour of these tags cannot be described anyway. OOXML, afterall, apparently exists for backwards compatibility purposes - so says Microsoft. What good is it if I don't have what I need in the specification to be backwards compatible, which is OOXML's reason for being?

On the other hand, Microsoft could simply delete these tags altogether and convert all documents into cleanly implementable OOXML - the way it should be done. Elements specific to the behaviour of a particular application have no place outside of the application itself.

Saying that it is deprecated is an exceedingly weak, pretty much non-existant, argument.

What is you evidence for this?

Read your own article, and in particular, read the article you quoted. I assume you do that. It was something made with particular reference to ODF - and no one else:

Malaysian standards body Sirim Bhd has “suspended the process for approving the Open Document Format (ODF)… as a Malaysian standard.”.........What was particularly interesting was the reason given: “Ariffin said some TC/G/4 members had taken to belittling other members who did not share their … views, both during committee meetings and in personal blogs.

I don't see any evidence for that anywhere, the people involved are not named, nor are these blogs referenced anywhere. Surely you can't be suggesting that this is all one way given what's happened in places like Sweden this past week?

From:

http://star-techcentral.com/tech/story.asp?file=/2007/4/4/technology/20070404125811&sec=technology

Standards body Sirim Bhd has stopped a feud between IBM Malaysia and Microsoft Malaysia over competing technologies in this country.

I don't see any evidence for this anywhere in the article, and indeed, the story thread wears out pretty quickly to this:

The OpenXML format would have been affected had the ODF supporters been successful in their bid.

As I explained at the time, I fail to see what this has to do with OpenXML. OpenXML simply appears out of the blue here.

The personal attacks and lack of ethics story thread then quickly turned into this:

First, a standard can only be mandatory when public health or safety is at stake, which is clearly not the case here, he said.

OK. So why was the process started in the first place in the manner that it was, and what has this got to do with a supposed lack of ethics?

Second, a mandatory standard would constitute an illicit non-tariff barrier against software products using other document formats, according to him.

This has suddenly appeared out of the blue, and in many ways, is similar to a great many statements Microsoft have made. Again, what has this got to do with a lack of ethics talked about earlier?

He said this would violate Malaysia's commitments to free trade under the World Trade Organisation.

Again, this is something else that has appeared out of the blue - and is quite simply false. Fair trade is about recognisable standards everyone can implement, and couldn't exist without them. But again, what has this got to do with the lack of ethics this article was supposed to be about?

You can't just quote one part of your own article and ignore the rest.

Anonymous: You are trolling.

I was quoting directly from the article. Paragraph 12.

I was responding to a strange comment that said I had claimed someone was "buying" something. When nothing was said.

On Sweden, no-one was bought, a mistake was made, corrected fast before harm occurred, reported to the correct authorities, who were satisifed. Unless some new info has come out this weekend, the story is a beat up, and predictable. Don't be manipulated. The vote cancellation was on an different procedural matter.

Anonymous: You are trolling.
It was actually me - I just hadn't filled in the name when I submitted.

It's the easiest thing in the world to write "You are trolling". I do not see a rebuttal anywhere, nor do I see anything that backs up what was claimed in that article - blog entries from various people involved and people who were there etc.

It is utterly baseless, and there is reason to question an awful lot about what was written - as I explained.

I was responding to a strange comment that said I had claimed someone was "buying" something. When nothing was said.

I can't really fathom what this means and what comment it relates to, but then, there's not much new there.

On Sweden, no-one was bought, a mistake was made, corrected fast before harm occurred, reported to the correct authorities, who were satisifed.

I'm afraid there is reason to doubt the 'official' version that has been doing the rounds (it may well have been the only way to invalidate an obviously untenable situation). They don't say who more than once, what that actually means and how this occurred. Microsoft have admitted some peculiar practices and it doesn't match up with peoples' reports who were there:

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9033701
http://ffii.se/pr/2007-08-27-se-ooxml-vote-en.html

Microsoft has admitted that their partners have been 'encouraged' to join these committees and vote accordingly. It's funny. I don't seen any reports of IBM or rabid ODF supporters being urged to pony up money and join these committees, and I don't see a sudden swing in NO votes towards OOXML anywhere to back that up.

"We had a situation where an employee sent a communication via e-mail that was inconsistent with our corporate policy," said Tom Robertson, general manager for interoperability and standards at Microsoft. "That communication had no impact on the final vote."

"It is critical to note that the addition of voting members at that time was completely within the rules of the national standards body," he wrote. "While there are many arguments to be had over the relative merits of this rule ... it is a rule nonetheless."

I don't see a "This story is completely untrue and fabricated" statement anywhere, do you? As for the filling of these committees at the last minute with new members, this comment I find particularly funny:

Robertson dismissed the criticism. Most standards bodies are filled with "an old guard" membership that needs rejuvenation, he said. He also likened Microsoft's recruitment efforts to a voter registration drive.

So, quite how you can claim that this is all meaningless I really can't fathom.

Unless some new info has come out this weekend, the story is a beat up, and predictable.

What does this mean, and specifically, what evidence do you have personally for making this claim?

Rick, why on earth would you inject something into a completely new standard specification that you already in its first incarnation deem deprecated? It's like if HTTP 1.0 included ten or more deprecated headers. What sense does that make? Yes, OOXML is designed to preserve backwards compatibility with the binary formats, but either these compatibility flags are important enough to have in the standard, or they're not.

If they are, all implementations needs to know how to handle them, but if they're not, they have no place in the specification at all. You seem to suggest the latter, so I would very much appreciate if you could answer the question that has now been asked you four times: Why are these compatibility flags in the specification at all?

I'm glad that you agree with Standard Norge's position and comments, though. The comments they have are both sound and correct, and I believe that if ECMA and Microsoft listened to them and implemented all of them, OOXML might actually become a good specification. But as it stands now, OOXML is a terrible specification that -- if it ever was implemented in anything but Microsoft Office -- would hurt interoperability much more than it would help it.

Asbjørn: I have always assumed that there would be a BRM or resolution process if there were any big problem, just as with any other ISO standard (though the details would be different.) I think this may be one reason why the hysteria about the Contradiction period "We only have 30 days to review this!" always seemed entirely ignorant or mischievous to me. We are looking at over a year of review.

And similarly, the current hysteria is no different. I expect that the issues in the draft will get looked at calmly and rationally discussed, and that the end result will be a much better standard. The process is geared to getting us from A to B, and jumping up and down at the start saying "We are at A, my God, we are not at B, the sky is falling" are useful for whipping up emotions and vitriol, but ultimately will prove futile.

If we back pedal on autoSpaceLikeWord95 and just say "It would be nice to have documentation" I concur. If we backpedal and say "Lets check to see whether it serves any useful purpose" I concur. If we say "Lets see what Japan says about it, work through the issue with their experts, and follow their lead" then I concur.

But saying "There is a deprecated element, through the standard out" is like the Queen in Lewis Carol: "Off with her head" as the only solution to any problem.

IMHO the greatest skill in standards is not technical knowledge and knowledge of precedent, though these are certainly vital: it is developing a sense of proportionality so that you treat the most serious problems as the most serious, and you don't get distracted by side issues.

In the case of OOXML, you have a mini-industry of full-time professional lobbyists whose entire day is spent trying to generate these side-issues.

Asbjørn: "Why on earth would you want to..."

That is a good question. One answer is that you might not know what people think is important, so you would put everything up to an international standardization process and let them the world tell you what is indeed important or not. Which is what is happening.

I know I am Mr Glass Half Full not Mr Glass Half Empty, but to freak out about things in an entry draft as if they were a published standard is a waste of emotions.

Well, if "autoSpaceLikeWord95" was the only problem with the specification, I could be on the same table as you. But since this element is only one in 16 similar flags ("autoSpaceLikeWord95", "footnoteLayoutLikeWW8", "lineWrapLikeWord6", "mwSmallCaps", "optimizeForBrowser", "shapeLayoutLikeWW8", "supressTopSpacingWP", "truncateFontHeightsLikeWP6", "useWord2002TableStyleRules", "useWord97LineBreakRules", "useWord97LineBreakRules", "wpJustification", "wpSpaceWidth", "sldSyncPr", "securityDescriptor", "revisionsPassword") that will hurt interoperability due to insufficient description and implementation details, I'm not.

On top of that, you have the different style labels defined in the specification, like "chicago", "ideographDigital", "ideographLegalTraditional", "koreanDigital2" and "koreanLegal" that are just named, but not described. What should an implementor do when he finds these references in an OOXML document?

Also, how is the "securityDescriptor" attribute supposed to be implemented interoperably? It has no defined semantics or data structure. It is impossible to know how to handle this without reverse engineering Microsoft Office 2007 documents using this attribute.

Do you think an international standard should contain wording like "For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [...] 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."?

Wouldn't it be more sane to just use the Gregorian calendar and preserve this backward compatibility through conversion filtering inside Microsoft Office instead? After all, the binary documents are still proprietary and closed source, so direct compatibility with those documents in other applications than Microsoft Office is a non-concern for the OOXML specification. Right?

And what about OOXML's tendency to break XML compatibilty due to the definition of "Basic String" that, when embedded in an XML document, includes non-XML characters that will break any conforming XML parser? And since OOXML obviously is based on XML, why is bitmask integers used to encode information instead of ordinary XML constructs like enumerated elements or attributes?

And why isn't OOXML using the XPS-defined PrintTicket format for print settings, and instead dependent on the legacy, binary DEVMODE structure? Talking about dependencies, why is OOXML dependent on the non-specified, non-standard VML, EMF and WMF formats? How can an international specification be dependent on formats that are proprietary and probably patent-encumbered?

And why is OOXML using its own date format (or several incompatible versions of it)? What's wrong with ISO-8601? Don't you agree that this backward compatibility consideration could be catered well enough for in a conversion filter? When you open up a pre-OOXML document in Office 2007, all dates are converted to an in-memory representation. What this representation is doesn't matter for anyone but Microsoft. When saved out to OOXML, this representation is converted to an ISO-8601 date. This guarantees interoperability and does not hurt backward compatibility in any way.

Lastly, an international standards specification should provide "a summary of good and best practice" based on consensus of expert opinion. Do you think OOXML in its current form does that? Do you feel that OOXML in its current form is ready for ISO or can you stretch yourself to agree, at least partly, that ECMA should have spent more time refining it, and with that removing all of the problems I've mentioned above, before submitting it to ISO?

Submitting such a problematic and erronous specification to ISO would have been easier to swallow if it was done in good faith and ECMA had spent enough time on it beforehand to fix some of these problems. But ECMA rushed through it. And then it got submitted to ISO with a Fast Track process, as if the specification was prime-time ready and without any problems whatsoever. And now, it is proven several times over that Microsoft has stuffed ballots and bought votes to "win" the standard process, as well as buying "P" status to several countries around the globe to increase their chance of "winning".

If it wasn't for this, I'd understand your position. But since this is where we are and what I've mentioned above are undeniable facts, I don't understand your defence of OOXML at all.

Common, we all know that this guy is the biggest MS fanboy. It's useless to get into and drivel and debate with someone who is clearly a shill for MS. It doesn't take a genius to figure out what MS trying to do.
Let us recap shall we? What are our options?
A) Office Open XML is a 7000+ pages standards designed so that nobody beside Microsoft can implement.
B) ODF standard is a clear, concise, open that's supported by Google, IBM, Sun.
Even a donkey can't get this wrong. So I ask why? Why do we allow Microsoft to push their patent ridden standard while we can use an existing, industry supported one? Oh that's right, we got paid by Microsoft.

Sept 4th...Australia abstains due to lack of consensus.

Alongside: Sweden, Hungary, Italy, Chile, Argentina, Finland, Netherlands, and Spain (just to name a few).

Sweden and Hungary abstain because their voting process was corrupted or influenced, so it was thrown out.

Dolby3: The Australian vote was the correct one: the non-technical Scitec committee was not competent to judge technical issues to evaluate the lack of consensus.

You say the "corrupt and influenced": what is your evidence for that? The Hungarian vote was called off because the invitation was sent by the wrong party, and the Swedish vote was called off because of a miscount, I thought. Both of these come down to time issues: the ISO deadline ran out before they could organize things properly.

There are often minor procedural problems like this. It seems they have been dealt with properly, from what I can see. Don't join in the hysteria...