Talk:Office Open XML/Archive 2

Ecma standards category?

Is there a cat for Ecma standards? If not, there should be and this article should be in it. (c.f. Category:ISO standards.) - David Gerard 12:50, 24 January 2007 (UTC)

6000 pages?

the "criticism" section doesn't seem to mention nearly all of the serious criticisms I've read. It might just do to mention that the MS proposed standard is some 6000 pages long and contrast that to the alternatives. —The preceding unsigned comment was added by 88.153.14.76 (talk) 20:06, 24 January 2007 (UTC).

Have you looked at the two specs ??

The OOXML spec contains an enormous amount of implementation examples which make the spec a lot lot bigger. Also the ODF spec is missing a large fomula section for it spreadsheets and ther ODF spec relies reuires implementing a lot of other specs which you could add to the size of it's documentation as well.

If the OOXML specification was clear, concise, and simple, an enormous amount of implementation examples would not need to exist. -- [Beta] 20:35, 24 January 2007 (UTC)

Yes, and then it would be totally useless from Microsoft's (and many user's) perspective. They have been making office applications for well over a decade. They have volumes of legacy documentation files, files that users will want to convert to the new format. That means that the new format must do everything that the old one does exactly as it does it. They can't just drop a feature because it would create complexity or other such; they have to support everything exactly as it used to be. Otherwise they'd royally honk off their consumers. Which is something that propriatery developers care about. Korval 01:25, 25 January 2007 (UTC)

You aren't a software developer, are you? Implementing a standard correctly is helped immensely by being provided large numbers of examples and informative text alongside the normative. Consider how badly HTML and CSS have been implemented... the W3C doesn't provide much in the way of samples, nor do they provide a reference implementation (ie. a fully-functional web browser built on their own standards)... 10 years later we're still seeing implementation failures in almost every browser as a result. This is a bad situation that should not be repeated again for OpenOffice or OOXML. -/- Warren 18:42, 25 January 2007 (UTC)

I am, but maybe you didn't grasp my point. I didn't say to include no examples. A specification does not require an enormous amount of examples in the specification. These can be provided separately, much like a lot of the W3C examples are (see SVG test suite, etc) The CSS implementation problems you refer to are because it is an immensely complex design, and people are doing things they never considered at the time they came up with it. I'd also say 80% of the current "failures" in browsers are due to one implementation. I don't feel I need to say which. -- [Beta] 22:16, 25 January 2007 (UTC)

The OOXML spec is definitly very big and probably more complex because it has legacy issues attached to it and it would definitly be hard to implement all. If it were easy to build an entire Office suite like MS Office then any company would try of course. But then again I do not expect any new suites that implement ODF from scratch either because it size might be a lot smaller creating completly interoperable applications is extremly difficult especially if specs are smaller and contain less examples. hAl 20:19, 24 January 2007 (UTC)

The legacy bits in the specification are only a handful of bits, hardly the core of the text. Miguel.de.Icaza

Was the entry I added from Groklaw not good enough ("contradictions to the OOXML ISO adoption process") ? It contains the 6,000 pages complaint aswell as the others ;) -- [Beta] 20:27, 24 January 2007 (UTC)

Well, some people want things served up to them and don't want to follow the link. That's human nature. I abandoned an edit where I was copying some of the Groklaw points verbatim, as I wasn't sure if the Groklaw article's copyright license was sufficiently open to allow that. I thought about producing a précis of the Groklaw article, but decided against, as I have Real Work to do. I think putting the salient points into this article would be worthwhile. WLD^talk|edits 21:24, 24 January 2007 (UTC)

Rob Weir's (IBM) Review

I don't suggest that you give this any more credibility than any other contribution, but I have gone through this article and did some fact checking and general review for technical and procedural accuracy. My review and 15 specific suggestions are on my blog here [1]

I'd make the changes myself, but out of abundance of caution, I'll abstain.

24.91.251.200 03:29, 26 January 2007 (UTC) (Rob)

Just took a look, and there are some good suggestions there. I will try to go through the article with a fine-toothed comb later this weekend (although it has already come a long way), if this isn't undertaken beforehand. On a side note, I encourage you to register an account :) —bbatsell ¿? 03:44, 26 January 2007 (UTC)

I agree. Several good suggestion here. Espcially mayby since some of those suggested restoring some of my early changes mayby. :-) . I am not to sure about the groklaw page which is already referenced in the article mainly because Groklaw has eplixitly put in an effort to ask their readers to influence the ISO vote against OOXML which is the same as you are trying to do with IBM. The groklaw article does bring up some good points but it is not a review or a comparison which considers both positive and negative things in the spec. As effort to influece ISO voting I think just keeping the external reference to the articles is good enough. I would also suggest you identify yourself as working for IBM and or use a registered nick that states so as I suggested earlier on this page with Doug from MS. Do you have simular suggestions for the OpenDocument article ? hAl 07:48, 26 January 2007 (UTC)

You just asked him to identify himself as working for IBM, so why feel the need to edit his heading? -- [Beta] 12:30, 26 January 2007 (UTC)

Because he has no wiki user and therefore for sure no watchlist which informs him that a comment was made. hAl 12:43, 26 January 2007 (UTC)

OK. I have an ID now. I can do a review of the ODF page as well, but it seems to be more in flux, a rather high rate of change. Maybe better to do a technical review once it stops seeing 30 edits a day? Or what do you think? RCWeir 16:41, 26 January 2007 (UTC)

I think the same person contributing to both articles would be a very good thing. Whatever you add will be under a lot of scrutiny, but I'll repeat the advice I gave on the OpenDocument talk page:

So long as what is added conforms with Wikipedia policies and preferably meets Wikipedia guidelines as well, then there shouldn't be an issue. Key ones are the Neutral Point of View (policy), reliable citations (guideline) and things like the Manual of Style (guideline). In addition, whatever is added should be relevant to the subject of the article. The article itself should be neutral, and if discussion/controversy merits it, then it would be a good idea to link to a separate article about the "Controversy concerning X", rather than cluttering up the "X article" itself. Its also worth reflecting and taking the long view - will what's being added be interesting or relevant in 10 or even 100years time? We are writing an encyclopædia here - it's not a blog or discussion site - see What Wikipedia is not (policy) - especially the sections Wikipedia is not a soapbox and Wikipedia is not a publisher of original thought.

Which was not aimed at you especially, but more at people adding intemperate accusations and pushing particular points of view. One of Wikipedias guidelines is to be bold, so if you are not too worried about having a bit of a rollercoaster ride to start off with, just start now. WLD^talk|edits 17:33, 26 January 2007 (UTC)

I'd say go for it Rob, if it weren't for your newly registered account, and the page being protected, therefore you wont be able to edit for the next day or two (There's a four day account age limit atm). -- [Beta] 23:18, 26 January 2007 (UTC)

Mmmm, I don't encourage that myself. Rob took exactly the correct approach here in analyzing the article but not editing himself; the same approach should be taken at any ODF-related article. Editing either directly would be seen as a conflict of interest. —bbatsell ¿? 23:23, 26 January 2007 (UTC)

Your going to get the best edits from people that have a strong interest in the topic, no single edit is golden, i'm sure many people will be watching what they do with interest and deal with any problems. My POV, why turn your back on what could be dam good editing. Charles Esson 23:42, 26 January 2007 (UTC)

I'm not saying it shouldn't receive edits from people interested in the topic, only from people who have a conflict of interest. They are two entirely different concepts. You can read Wikipedia's guidelines regarding conflict of interest at the link I provided above. As I said, I encourage Rob to provide similar reviews that will prove helpful to the articles as well as to participate in discussion on the relevant talk pages, but not to edit articles related to OOXML or IBM (or ODF) directly. —bbatsell ¿? 00:08, 27 January 2007 (UTC)

Suggestion

Link to Comparison of OpenDocument and Microsoft Office Open XML formats, in see other and keep it out of this article. Charles Esson 00:26, 27 January 2007 (UTC)

Mentaka edits

Look like some user called Mentaka has reverted the Office Open XML and the OpenDocument article back several days showing them as as minor edit's. hAl 16:34, 27 January 2007 (UTC)

Just coming in to note that. I have reverted, as the user does not appear to have a constructive history and I can't determine any sort of reasoning for it. If there is, please discuss here first. Thanks! —bbatsell ¿? 20:55, 27 January 2007 (UTC)

The amount of reverts (of reverts) is getting me confused :) I have left a warning on Mentaka's user page, and I hope OOXML can stay at this version for future edits. -- [Beta] 22:20, 27 January 2007 (UTC)

Comments to Mentaka

I reverted then came to here to make a note; so Bbatsell could easily be reverting my revert (checked the history my revert didn't make it).

1. You do not revert pages with the comment minor edit.
2. Ok as a standard OOXML sucks, this is not the place to argue the case against OOXML, in the see other section there is a link to a page that compares the competing standards argue your case there. Put wikipedia first.
3. The version before Mentaka did the revert was a lot closer to having a NPOV.

Charles Esson 21:13, 27 January 2007 (UTC)

Standardization

I'm trying to get this section to a point where it at least answers the questions on my mind.

I think "A liaison from the ISO/IEC from JTC 1/SC 34 helped during the standardization process with the technical committee of Ecma to prepare Office Open XML submission to ISO/IEC [citation needed]." should go, it really adds nothing.

As Ecma is a category A liaison this is unlikely as Ecma knows what it is doing.

The "fast track" process is given here. Does anybody know at what stage within the process it is at, has it been accepted by a working group, if so what is the current one month vote about. These are questions I am asking and I think wikipedia should answer. I think answer these qestions and the section will be up to date. Charles Esson 04:47, 28 January 2007 (UTC)

Editors writing about "fast track" procedures at ISO might like to be aware that there is a general use of the term and two specific kinds: usually called "Fast Track" and "PAS".Rick Jelliffe 06:41, 28 January 2007 (UTC)

Thanks Rick. According to this Ecma was already qualified as a PAS submitter, in fact it is a category A liaison, some stuff on PAS.

The PAS process is described here (= one month administrative time + four months for an ISP ballot or six months for an IS ballot), so we are in administration time. Charles Esson 07:38, 28 January 2007 (UTC)

Thanks for leading me up the garden path Rick. Charles Esson 19:49, 1 February 2007 (UTC)

HAL we should use the words from the Ecma press release when describing the formation of TC45, it is unfair on Ecma and unfair on wikepedia to try and turn it into something else. Follow the link and you will see what I am getting at. In my original edit I left off "submitted by Microsoft" which is in the press release, that in itself was probable unfair, the changes you made go a bit far I think and misrepresent the press release.Charles Esson 07:07, 30 January 2007 (UTC)

You can't use the words that Ecma used to describe TC45 without appearing you have a POV to push (the reason I toned it down in my original version) so I have changed the words to make it clear that the description is that used in a Ecma press release. Charles Esson 09:31, 30 January 2007 (UTC)

I found an article that claims that the request for fast track has failed, but it may be incorrect. "The request for fast-track was discussed by ISO and its national mirror committees on February 6th, and the request was rejected. So Microsoft's application will now follow the usual, more detailed process. [2]"

This article seems quite confused. The thing is in the fast-track process already. ISO has received 19 or 20 comments; it seems that at least several of them are about ISO process (the 30 day period) rather than OOXML per se. ISO is sending them to ECMA for comments before looking at them or releasing them. Even Andy Updgrrove says What I've been told by someone that has seen some, but not all, of the responses is that the most favorable comment may say that the process should just move straight into the next phase, so that everything can be addressed at once. Some comments will be brief, flagging one or two things, while some will be more substantial. We should find out the full story on, or shortly after, February 28, unless a delay is announced.[3]Rick Jelliffe 06:21, 14 February 2007 (UTC)

The other thing to note is that the whole standards process is based around trying to get win-win, achieving win-lose can be a struggle. For example, if a national body raises a potential technical contradiction and Ecma then satisfactorily resolves it, for example by showing it is based on flawed tehnical information or by improving the draft standard or language, then the national body will not have that flaw as a reason to vote against OOXML at the end of the 5 (i.e. 6) month review. Rick Jelliffe 06:21, 14 February 2007 (UTC)

I think the original article was indeed confused. However, it appears that the 20 responses are now available. [4] "14 of 20 responses were clearly negative, two indicated divisions of opinion, three were inconclusive or neutral, and one offered no objections." So in the final wash-up, the original article may indeed have got the wrong story, but it looks as though despite that it may nevertheless have reached the correct conclusion. In respect of the Microsoft notion of having two standards, several bodies make specific points, the German & Japanese perhap sum it up best: "The German NB prefers to have a harmonized Standard over having two Standards serving basically the same user requirements." Japan: "[OOXML] seems to be competing and incompatible with [ODF]." Japan appears to be proposing that the two standards be harmonized. It also has IPR concerns. —The preceding unsigned comment was added by 202.20.20.129 (talk) 05:56, 1 March 2007 (UTC).

I don't think it is the corect characterization of the comments at all. Eric Lai of ComputerWorld only counts 6, for example, not 14. (I have a longer comment in the section on Critism section too long below.) Like I said, people just have to get this model that ISO is about win-lose out of their minds when looking at the process: ISO isn't a forum for competition by proxy or regulation by proxy or anti-trust by proxy or marketing by proxy. Rick Jelliffe 00:22, 8 March 2007 (UTC)

Standardization 2

The recent changes describing the procedure at ISO is wrong. See ISO Directives Part 1 [[5]] notably Annex F and the diagram on page 59. The current text if the meeting does agree a text, any required changes are applied by the editor and OOXML is passed for publication as an ISO standard. should be replaced by something like if the meeting does agree on changes, any required changes are applied by the editor who creates a Final Draft International Specification; this is voted on again after a period of several months. The whole process of fast-tracking a standard at ISO takes a minimum of 13 months, where there are draft issues to be resolved. We have already seen this emotional traffic based on there only being "30 days" to review, and the current text seems to incorrectly suggest that there is 5 months of review, whereas there is a full year. Rick Jelliffe 20:56, 8 May 2007 (UTC) On the related issue of what to expect at the ballot resolution: note that MS has already mentioned [[6]] that it expects that there might be extra explanations or parts removed, as also mooted in the Ecma response document (in the initial review). I have some blog entries that may be of interest to people trying to get a handle on the process: the process is like a conversation rather than a court [[7]], and a more detailed explanation of the ISO procedures [[8]] Rick Jelliffe 20:56, 8 May 2007 (UTC)

Hi Rick -- the latest version of the JTC 1 directives (5th Ed, version 3.0 of 2007-02) states (clause 13.9) that "If, after the deliberations of this ballot resolution group, the requirements of 9.6 are met, the Project Editor shall prepare the amended DIS (or DAM) and send it to the SC Secretariat who shall forward it to the ITTF for publication as an IS." I read this as saying there would be no FDIS stage, and that the BRM would effectively be the last voted-on input into the process. Alexbrn 15:48, 9 May 2007 (UTC)

Thanks Alex, actually you are right. I have been using the old version of the directives, which confusingly was also labelled 5th edition version 3 but had a different date. Many apologies for that, I thought I was using the update. The current article text is not incorrect, just not accurate, in that it still misses that the ballot resolution period adds up to three months before the final vote if we consider that the ballot resolution meeting may take a week (and then a few more months while the final text is prepared.) So rather than nations having four separate stabs (administrative review, draft ballot, ballot resolution discussions, final draft vote) the final vote or consensus now occurs at the end of the ballot resolution meeting. And rather than the final vote being a vote on the finalized text, as under the old procedings, the vote is on the text as it will be (after the editor has incorporated his instructions.) So the vote is faster (8 months) but the total time until publication does not seem to be changed much (I count about 12 months rather than 13 months under the old system.) 8 months is certainly less time for reviewing than 13 months. (However the new Directives seem to put some issues of form out of scope until the first revision. It would be better if the Directives had some more positive statements about the kinds of issues that were in-scope for review.)

So perhaps text like "After a further two-and-a-half month period, at the end of the five-month ballot period..." would be better. (Someone should double check this!) Rick Jelliffe 16:50, 15 May 2007 (UTC)

Rick hi - my understanding is that it is an open question whether the BRM should follow hard on the heels of the ballot closing, or whether there should be some weeks/months of breathing space (which seems more reasonable to me, personally). I believe this will be up to the SC 34 secretariat. What about "At the end of the five-month ballot period, and after an opportunity for all participants in the process to consider the material amassed during it, ..." ?

I certainly agree that the Directives would benefit from 'positive statements about the kinds of issues that were in-scope for review'. You might be interested to see the UK BSI panel's Wiki (read access to the public) which contains the guidance our technical panel has been given on scope. However I expect that, in common with many NBs, the final UK position as a whole will be informed by more than just technical/textual considerations, as a common view is that the ballot is actually the means for NBs to move towards closure on matters which were not resolved at the end of the review process. Alexbrn 05:49, 16 May 2007 (UTC)

Miscellaneous comments from Rick Jelliffe

In the section "Criticism", should it be mentioned that Andy Updegrove is more than an "Attorney and open standards advocate"? He also is a lawyer representing OASIS, the standards organization behind ODF in his day job. The page [9] says he "leads the consortium and standard setting practice group" of Gesmer Updegrove. The same page gives OASIS as a client. I suggest something like "OASIS Attorney and open standards advocate". Opinion from a disinterested attorney is legal advice; opinion from the attorney from a rival is something else, I would have thought. Can someone point me to whether there are Wikipedia guidelines about this aspect of links or citations? Rick Jelliffe 13:25, 28 January 2007 (UTC)

Wikipedia:Verifiability is the key policy concerning sourcing/referencing/citing. Wikipedia:Citing sources is its how-to guideline. But Wikipedia:Neutral point of view is the policy that is most relevant to the the conflicting points of view that I am aware of that you are dealing with at the moment (other than WP:COI, of course). You know me better as "Anonymous" but here I am WAS 4.250 18:04, 28 January 2007 (UTC)

I'm the editor that added that "Attorney and open standards advocate" phrase, because that's the characterisation I got from reading his biography on his web site. The fact that he's OASIS's lawyer lends an interesting undertone to his blog posting. No wonder he's pushing hard to discredit Microsoft and OOXML... he gets paid to support the competition! -/- Warren 03:07, 29 January 2007 (UTC)

Actually we don't know if he really "gets paid to support the competition". Updegrove is a member in many bodies. Arebenti 20:37, 13 August 2007 (UTC)

I have added a talk item to the Wikipedia Citations discussion page on Accusations and Allegations. Basically, I think that all sentences with phrases like "It has been alleged that..." or "X has been accused of..." should be corrected with mention of who the accuser is and their relevant affiliations. I haven't found any good explicit guidelines so far in the links kindly provided above, though I may have missed it. Rick Jelliffe 17:57, 29 January 2007 (UTC)

Is Wikipedia:Neutral_point_of_view#Attributing_and_substantiating_biased_statements what you are looking for? WAS 4.250 20:48, 29 January 2007 (UTC)

Very funny, who pays Mr. Jeliffe "Microsoft is kindly sponsoring me for total three days in late Jan, early Feb 2007 to edit articles relating to ISO, OOXML, ODF and standards." Podmok 13:24, 11 July 2007 (UTC)

Arbitary section break for ease of editing (1)

I would like to add a section "Conformance with the Ecma and proposed ISO Standards". This section would summarize the conformance requirements from the Ecma and proposed ISO standard. It would clarify that "full implementation" is not a requirement for Ecma or ISO Conformance and provide references to the Conformance sections in the specs.It would also clarify the issue of whether "full implementation" was a requirement for conformance to the standard (i.e. whether an implementation that does not fully implement everything that Application A implements, it is still conformant) and point out that formal conformance with the standard does not in any way guarantee interoperability. For example, a word processor is not required to implement the spreadsheet parts; a word processor is not required to implement any parts outside the standard; and the word processor can decide which elements in the standard it will implement or not; all this and still be conformant. It would mention that formal compliance is largely in terms of a schema. It would mention the XSD and RELAX NG schemas. This would also balance the article, which has little about the actual compliance requirements of the standard, which is the kind of thing that a legal contract with a system integrator would require, for example. I would like to put an almost identical section for ODF. Standards have very clear conformance sections, and groups who mandate a standard may find that formal compliance provides more or less than they are expecting. (Disclosure: I converted the XSD schemas to RELAX NG for use in the proposed ISO OOXML standard. Another member of the ISO/IEC JTC1 SC34 WG1, Murata Makoto, generated the NVRL schemas. We did this because RELAX NG and NVRL are both parts of the ISO DSDL multipart schema standard, which is what the WG1 committee encourages SC34 standards to use. ISO DSDL is the main technical alternative to the W3C XSD schema language that Microsoft and IBM base their current XML systems on. This is the kind of thing that working group membership entails, making sure that incoming and proposed standards fit in with the WG's technical direction. For example, ISO Schematron was previously specified with a DTD, and when it was standardized I made a RELAX NG schema for it. ODF also uses a RELAX NG schema. RELAX NG is a schema language that was fast-tracked from OASIS in WG1.) Rick Jelliffe 14:16, 28 January 2007 (UTC)

I seemed to have got myself banned from the ISO site, after downloading many documents I started getting blank returns, their software must have assumed I was performing a DOS attack, hopefully I will get aged and I can start researching it again. What you request above is a can of worms; open it and the article has to look at this to give a NPOV. My POV, the issue is not the standard but the motivation of the people behind the standard and that is something that can't be covered in this article either.

I just reread the Criticism section and I withdraw the above comment, I think Rick is right this POV needs to be presented.Charles Esson 09:59, 29 January 2007 (UTC)

Your obviously close to the process, I had to read many documents to work out what was going on, did I get it right?

Charles Esson 20:04, 28 January 2007 (UTC)

Rick, please, feel free to edit and add material that you feel will help better describe the subject and help improve the overall informative value of the encyclopedia. We have a guideline for that: Wikipedia:Be bold in updating pages. :-) I think a very clear case can be made for your being an expert on the subject... now that the media hoopla has died down, we can focus on improving both this article and OpenDocument, which definitely under-represent the topics. As long as the contributions are verifiable and are an expression of fact, not opinion, then it will be quite welcome. Charles is right in asserting that we need to be careful about balance in presenting points of view, but getting the details of the requirements for Ecma and ISO conformance into the article will necessarily come before that. -/- Warren 03:26, 29 January 2007 (UTC)

After reading bbatsell comments under my comment above that was pretty much the same as your comment I went and read the conflict of interest stuff bbatsell linked to and concluded Rick is in a difficult position. I can tell you now I am not looking forward to reading either standard; I would prefer to see experts from both sides working towards a sensible article with onlookers telling them when they have stepped over the mark. It took ages to work out what was going on in the standards section, for example why is Ecma not on the list of registered PAS submitters? Found that in a 2002 report. Is ecma still the only class A initiator was what I was trying to find out when ISO stopped serving me documents.Charles Esson 08:06, 29 January 2007 (UTC)

Rick ... I have added a criticism of OOXML that goes right to the very purpose of why OOXML was proposed by Microsoft as a standard. Basically, the primary stated purpose of OOXML is already supported by ODF. I believe I have provided fair references, and there is a link to some demo software that proves the essential point. I have previously brought this topic up on your blog. —The preceding unsigned comment was added by 202.1.119.216 (talk) 11:22, 29 January 2007 (UTC).

Well, may I suggest that there should a complete ban on material on what OOXML is not, and only material on what it is? Allowing comments on what it is not just allows any kind of unsubstantiated or biased claim or rival-company smear; it generates very little light but a lot of heat. I have not looked at the changes, but certainly the daVinci software, which produces non-standard ODF from Office APIs is utterly off-topic in this regard. So I suggest a different article be used or made, in which details of what OOXML is not and its criticisms and the FUD campaign can be fairly aired and discussed. There are objective, referencable facts based on the text of the standard, the ISO procedures, actual historical milestones, etc.: these are the kind of things I'd expect to see in a neutral description. Rick Jelliffe 16:59, 29 January 2007 (UTC)

I agree 100% with this that should all be in the OOXML/ODF article, this should be a clean straight down the line article on OOXML, there is enough material in OOXML to make it too big.Charles Esson 20:43, 29 January 2007 (UTC)

Rick, please don't talk like that. You sound exactly like a bunch of people we had to block for bias. Concentrate on adding properly sourced data rather than trying to delete stuff from this page and things will go far better for all concerned. Others can delete/move as needed; you need to not be the one to do that. Adding good stuff is hard, we need you for that. Deleting/moving is easy - consider it delegated. WAS 4.250 20:56, 29 January 2007 (UTC)

Rick, a significant over-reaction there. All of the text I inserted is referenced, and there is an actual software demonstration of the main point, so it is hardly lacking in objectivity. In fact it is hard to imagine anything more objective than a solid demonstration, and a demonstration amounts to a lot more than a mere claim, and it certainly cannot be characterized in any way as "unsubstantiated". What is it in any way non-standard about the ODF 1.0 that daVinci can be set to produce? Further, I cannot see how a questioning of the whole stated purpose for the ECMA submission of OOXML is in any way off-topic for an article on OOXML, especially since that very purpose is in fact also quoted at the head of the article. Finally, please notice that daVinci represents a testable claim that ODF 1.0 and ODF 1.2 formats can both fully support Microsoft's legacy formats, yet Microsoft's original say-so that ODF cannot support its legacy formats is a wholly unsupported assertion on their part with no proof at all offered in evidence. —The preceding unsigned comment was added by 202.1.119.216 (talk) 12:58, 30 January 2007 (UTC).

Arbitary section break for ease of editing (2)

In the section on the Groklaw criticism, it says that an ISO terms "A contradiction is where two standard conflict." In my opinion it is a lot stronger than that, but there is little precedent. The OOXML proceedings will provide more precedent. I suggest "A contradiction is where two standard conflict irreconcilably." Furthermore, the word "alleged" should be used of the Groklaw material. What contradiction means is still being debated by ISO people, let alone whether particular things raise to that level. Rick Jelliffe 17:29, 29 January 2007 (UTC)

Could you provide a ref for the statement ( I have seen it somewhere but I have forgotten where, might have been your blog), better still perhaps the section on standards needs a little more on the PAS process, could you write something with references, I will add it if it has a NPOV and adds to the user experience. I would like to know what this administration period is about; why does the FOSS community believe they can shoot is down now? On my reading of appendixM I can't see that.Charles Esson 20:43, 29 January 2007 (UTC)

I've got a blog article on the subject at XML.COM [10] which references various cases; but obviously it is not something I can add. "Contradict" and "conflict" cannot mean simple "overlap" because there are so many standards that currently overlap. But it is not clear whether "conflict" means exactly the same thing as "contradict". It will be interesting where ISO goes on this. The Chinese vs IEEE squabble has not been resolved yet, ISO has basically told both sides to go away for a year; this would otherwise have provided more precedent than the little we have at the moment.

For an example of where two standards address the same subject, read up this Wikipedia page [11] which describes an ANSI standard used by just two countries, and the corresponding (or contradicting, if you will) ISO standard ISO 216 used by every other country. Note in particular that there are not two ISO standards, only one. The ANSI standard is not an ISO standard. —The preceding unsigned comment was added by 202.1.119.216 (talk) 11:09, 7 February 2007 (UTC).

Sorry Rick, but your opinion "A contradiction is where two standard conflict irreconcilably" is not the ISO definition. [12] The original "A contradiction is where two standard conflict" is far more accurate. The concept of a "standard" simply doesn't mean "this way OR that way or any way that suits you". There are a record number of responses (from 19 countries, no less, apparently mostly contradictions) to see it that way [13] in direct opposition to your opinion (which, curiously, I note, happens to align with Microsoft's).

Sorry anonymous person, but I voiced my opinion last year during the ISO SC34 meetings; if MS has come around to my view on one thing, it makes no difference to me. Actually MS' position, as far as I understand, is different to mine; I think they take the view that standards contradict where they could not both be used at the same time, like duplicate allocation of the same radio frequency (reportedly, this is the argument that swayed ANSI, but I have absolutely no faith in reports from anyone other than people who are there or from primary documents); my view is that it is specific textual contradiction not mere usage conflicts. (So duplicate allocation would not be contradiction unless there was a clear statement in the standard that no other use of that frequency was allowed, for example.) Whatever contradiction is, it is certainly not the kitchen sink "anything that could cause confusion"!—The preceding unsigned comment was added by Rick Jelliffe (talk • contribs) 06:55, 14 February 2007.

For more discussion on the self-defeating nature of having two standards for the same thing, read here. [14] "The purpose of OpenDocument, as I have always understood it, has been that it will enable me to use the office suite I want to use, while still being able to share documents with people who use other office suites, including Microsoft Office. Unfortunately, someone at Microsoft decided not to participate in the development of OpenDocument. The company has thus created a self-fulfilling, paranoid prophecy of their enemies being out to "get them" with this "inferior" document standard. Had Microsoft contributed to OpenDocument, they could have helped to ensure its compatibility with the billions of aging Office documents sitting on hard drives everywhere. I seriously doubt they could have helped to make it perfect - that is likely impossible, even with OOXML. They certainly could have helped improve ODF. Instead, they rejected ODF, and threw millions of dollars into developing an alternative format, apparently thinking like George Bush, that they would be greeted with cheers and ticker-tape parades. Microsoft's only arguments for choice have been about choosing which versions of Windows and Office you want to use. Their only use of standards is to adopt so they can adapt to lock customers into their solutions. And now, instead of contributing to the biggest interoperability push the world has ever seen, they want to force you to keep converting between document formats. How backwards is that?" As is observed here, having two standards defeats the whole purpose of having a standard at all. There won't be two document format ISO standards, it makes no sense at all. —The preceding unsigned comment was added by 202.20.20.129 (talk) 01:56, 21 February 2007 (UTC).

The trouble is that the goals, subjects and timing of ODF and OpenXML are significantly different. On timing, OpenXML is complete and fully implemented now; ODF still has large chunks undefined or in the pipeline (ODF 1.2, formulas, etc). On subjects, OpenXML includes advanced material on cross-linking to allow entity indirection, two-way field transclusion to embedded XML, interleaved arbitrary structure and external parallel structures; ODF has no equivalent AFAIK (These kind of features are of especial interest to SC34 people, because they clearly address the same kind of concerns that informed IS 10744 HyTime, for example; these kinds of extended forms of document construction are essential to many kinds of large_scale industrial publishing, but ODF has not even started on any of these issues yet, AFAIK.) On goals, the goals of OpenXML are clearly based on rigorously documenting an existing format warts and all, while ODF starts with a proprietary formats feature list and then progressively adds bits.

I think the above sentence leaves out some relevant information. I don't think OOXML is necessarily rigourously documenting an existent proprietary standard and making it open - hence the arguments over the flags that say "use behaviour like an old proprietary application" without documenting what that behaviour is. MS Office format is definitely proprietary, and although you can say that the Staroffice document format (.sxw) was/is proprietary, ODF is not, and in the transformation process, significant changes occured - see Section 4 in this essay http://www.dwheeler.com/essays/opendocument-open.html, which uses information from this thread which starts with the following message: http://www.oasis-open.org/archives/office/200702/msg00025.html. WLD^talk|edits 08:58, 8 March 2007 (UTC)

There are lots of us in industrial publishing who really want to force MS to have a *complete* documented XML specication for their native format: ODF is just a sideshow there, it leaves open so many questions and issues at the current time. (But it is getting better!) Take the issue of border decorations: OpenXML has fifty pages on them! If MS were going through the ODF process and the OASIS committee　said "we will only put into the ODF standard the borders that more than 4 vendors support", say. This is the kind of approach that OASIS CALS Table Interchange took. This is good for interoperability, because if everyone will support　the standard borders only, but where does MS document the other borders and how does it (or another vendor) add extra borders for users. The trouble with unified standards is they either become kitchen sinks where anything is allowed which reduces the chances of multiple complete implementations, or they become common-subset standards where any unique or special or historical features are lost off the standards map. The real issue here is that people saying "we want ISO ODF" are in fact saying "we don't care if large chunks of what MS Office saves is in extra-standard formats" given that ISO ODF cannot cope with so many things at the moment. Rick Jelliffe 00:51, 8 March 2007 (UTC)

Indeed, backwards compatibility is no feature of a document standard but of an application. MS Office is free to load older documents, here the backwards compatibility has to be implemented. But file formats are not "memory dumps", they are for document exchange. A file format has also nothing to do with what MS Office imports or features it supports as an application. Podmok 13:31, 11 July 2007 (UTC)

Furthermore, the material concerning the current ISO process and the Groklaw material should be clearly marked as contemporary and subject to change. I have seen other pages that do this. How do you do it?Rick Jelliffe 17:29, 29 January 2007 (UTC)

It's a contemporary issue; present both sides of the argument; think of the user that wants to get an overview of what is going on; this is not the place to try and win or lose. I think you have to be careful, if you make POV edits it will be over the net in no time, if you do NPOV edits you will get praised by people who care about wikipedia; well you will get praised by me anyway ( I know it's worth nothing), sorting through the documents is hard work. Charles Esson 20:43, 29 January 2007 (UTC)

Is Wikipedia:As of what you are looking for? WAS 4.250 20:59, 29 January 2007 (UTC)

Arbitary section break for ease of editing (3)

The paragraph Office Open XML has been the subject of considerable controversy in the computing industry, with criticism of the document format coming from members of the free software movement (who favor OpenDocument), as well as some of Microsoft's competitors. might give readers the impression that members of the open software movement necessarily favour OpenDocument or that no members of the open software movement see benefit in OOXML. In particular, see Miguel_de_Icaza's blog[15] today. Furthermore, the controversy is really about the ISO standardization, it seems to me. Perhaps Office Open XML and its standardization through Ecma and ISO has been the subject of considerable controversy in the computing industry. Criticism of the document format has come from some members of the free software movement (those who favour ODF as the sole standard), as well as some of Microsoft's competitors. Rick Jelliffe 203.111.164.74 06:59, 1 February 2007 (UTC) Rick Jelliffe

The opposition to fast tracking Microsoft's submission is coming from a lot more quarters than just Microsoft's opposition and the free software movement. Standards bodies of 19 countries also seem to have something to say on this topic. [16] [17] In addition there are government bills being proposed. [18] The count is growing, apparently. [19] Massachusetts, Texas and Minnesota, and now California and Wisconsin also.

At the moment we just don't know what the 19 standards bodies said! They sent are "comments" which may or may not raise contradictions. For example, I see that Australia is listed, yet I have talked to the guy at Standards Australia who sent the comments (Alistair Teggart) and he told me their comments were along the lines of "We have received the following comments, but are not in a position to know whether they are contradictions or not." In other words, they did not raise a contradiction, just passed on issues. ISO is not releasing the comments until Ecma responds, I am told. Rick Jelliffe 05:33, 9 February 2007 (UTC)

That is a fair enough observation. Indeed, we just don't know what the 19 standards bodies said! OTOH, the whole of OOXML is a "contradiction" on the very face of it ... it purports to do exactly what an existing ISO standard already demonstrably does. Anyway, apparently the correct count is 20. [20] We know that India was upset. [21] We know that Great Britain [22] and Malaysia were anti. According to the math [23] there is a strong chance OOXML could fail as an ISO standard. There certainly won't be two ISO standards for XML storage format of office documents, and right now it doesn't look as though OOXML has a prayer of supplanting ODF as the ISO standard, IMO. It is interesting to note also speculation [24] that the hard questions are being asked: "I've heard through the webvine that there were some interesting remarks in the German and Canadian contradiction vote. Remarks to the effect that Microsoft should explain exactly why they didn't use ISO 26300 (ODF) as the basis of their XML file format effort; making the necessary eXtensions if needed, and submitting those issues to the OASIS ODF TC. You know, the "X" in XML problem Microsoft has yet to explain.". Still, at this time, it is all pure speculation, but in the light of what the Sun and daVinci plugins show, very interesting speculation. Microsoft has a lot of 'splainin' to do, it would seem. —The preceding unsigned comment was added by 202.1.119.216 (talk) 11:54, 9 February 2007 (UTC).

As far as attitudes towards ODF go in Australia, there is at least one National body that has a strong interest. [25] [26] [27] —The preceding unsigned comment was added by 202.1.119.216 (talk) 12:12, 9 February 2007 (UTC).

"National Body" refers to a national standards body, in Australia's case it is Standards Australia. The National Archives are not a "national body" in that sense. They are also interested in OOXML, by the way. The idea that OOXML is intended to "surplant ODF" goes against what that MS or ECMA has said about it. See Jean Paoli Working with Ecma to standardize the Open XML file formats means that the new international standard will be fully documented in great detail to make it an extremely stable file format. This stability delivers two main advantages: It enables broad adoption, guaranteeing future-proof archiving for billions of documents and millions of public and private-sector customers worldwide, and it enables partners to develop a wide set of tools and platforms that foster interoperability across office productivity applications and with line-of-business systems. [28] I don't see MS or Ecma pushing OOXML for other than archiving and system-integration, the things Paoli mentions. As far as there being a strong chance that OOXML standardization will fail, that is complete speculation.Rick Jelliffe 06:37, 14 February 2007 (UTC)

It seems the Australian submission was (momentarily) leaked. I don't think it is good news for Microsoft, or it would still be readable. [29] Seriously, Rick, people are aware of what is up here. "Observing that the approval of a first standard could preclude the success of any later, better standard has a compelling sound. The back story that's missing from that otherwise appealing logic is that Microsoft could have opted to join the ODF technical committee at OASIS many years ago, and then worked towards creating a standard that would have worked for all purposes, for all vendors, and for all end users. It made a strategic gamble at that time to stand aside, and hope that ODF would, like many other standards efforts, fail to gain traction in the marketplace. That has proven to be a bad bet". Also, here [30] : The idiocy of all this is that it is totally unnecessary. ODF is a vendor neutral file format, not a competitor to Microsoft. Microsoft were welcome to be involved with the standard from a very early stage. They chose not to. They are invited to be so now. They are choosing not to. Microsoft, like anyone else, is perfectly welcome to include the format in the "Save" and "Load" options of their file menu for no IP costs. They choose not to, and it is not as though they do not have the resources to achieve that. They claim that their version of the standard is required to examine legacy Microsoft documents. I have yet to meet someone who was not a Microsoft advocate buy that. The more that Microsoft try to spin about ODF, the more desperate they sound. —The preceding unsigned comment was added by 202.1.119.216 (talk) 12:49, 16 February 2007 (UTC).

Another reference to the Australian submission can be found here: [31] Hmmmm. "Standards Australia sent to the American National Standards Institute a letter, which was posted to the Web and authenticated by internetnews.com, that raised substantive issues about the proposed standard." Substantive issues. Thought so. Here also: [32] Australia (two page response): "Australia proposes that this document be referred back for discussion within SC 34 before it goes to [Fast Track Ballot], given the many significant issues that need to be clarified."

Here is are links to the objections of ISO country standard groups: http://www.groklaw.net/article.php?story=2007030308154032 http://www.groklaw.net/pdf/ECMA-AnsObj.pdf http://www.consortiuminfo.org/standardsblog/article.php?story=2007022819130536 http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=government&articleId=9012092&taxonomyId=13&intsrc=kc_top —The preceding unsigned comment was added by 74.112.116.206 (talk) 09:01, 6 March 2007 (UTC).

These links are on multiple other comments on this page. Very assiduous. Why has no one linked to Eric Lai's article on ComputerWorld which gives an entirely different view on the numbers? See the link in the Criticism too long section below. Also a comment from me in the Standardization section above.Rick Jelliffe 00:58, 8 March 2007 (UTC)

Arbitary section break for ease of editing (4)

What are the guidelines for when a new article can be added or a page split up? In particular, I'd like to suggest articles on Open Packaging Convention (which is the XML-in-ZIP format, not mentioned in the current article at all under that name) as well as articles each of the individual markup languages citing basic technical details. 203.111.164.74 08:50, 2 February 2007 (UTC) Rick Jelliffe

Go ahead and give it a try. Create sourced articles that link to related Wikipedia articles and indicate to readers who don't know the subject why the subject of the article is important. After content is created it can be moved or combined as needed. Referencing something you wrote yourself on a subject you are a recognized expert on is tricky to do without creating problems. The talk page is a good place for that kind of thing. WAS 4.250 20:20, 2 February 2007 (UTC)

The current text says, in the Criticism section "The fact that ECMA (and by inference Microsoft) have refused to address the valid objections raised, but instead merely rebutted them, is seen by some as a significant gamble on ECMA/Microsoft's part which increases the chances that the format will eventually be rejected" This is spurious assertion ("the fact that"), distinction without a difference ("refuse to address" versus "rebuttal"), unreferenced allegation ("is seen by some" instead of "is seen by one stakeholder"), perjorative ("gamble") and speculative ("increases the chances"). Plus its ground is confused, because the national ballot will be made on the Final Draft International Standard which will be prepared after any issues arising from the 5-month review period are resolved, which may indeed include altering the OpenXML specification in some ways. (I do not find ConsortiumInfo calm or remotely reliable, when dealing with ISO procedures and National Body issues.) I recommend deleting the sentence. A suitable replacement might be "At the end of the five-month review period, participating national standards bodies have the chance to raise these issues in a ballot, which are resolved when creating the Final Draft Internation Standard, which national bodies the vote again on; issues may be resolved by altering the text, withdrawing the draft, or by providing explanatory comments to the national body. It is expected that the same issues will be raised and dealt with at more length at the end of the five-month ballot." Rick Jelliffe 04:55, 20 March 2007 (UTC)

Thanks for adding that. I read today however on the web someone saying "there is only five months before the final decision" which is reading more into the text than I meant. Sigh... I suggest adding another sentence "National bodies then have four to six months to review the Final Draft International Standard before their ultimate vote, which is usually a formality by that stage." Rick Jelliffe 15:35, 4 April 2007 (UTC)

Licensing

Had a go at tidying up licensing.

1. There was a history, tried to change the wording to reflect the history.
2. Cited the initial concerns.
3. As with anything in the FOSS community there was a mixed reception to the covenant not to sue and this mixed reception can be seen with even a casual search of the Internet; does no good for anyone to have wikipedia pretend otherwise.
4. Brian Jones may be a nice guy but I don't think anyone will use his blog entry in deciding a legal position.
5. Added a note that covenant is part of ISO submission.Charles Esson

Hal in my view the problem with the section was that it was a collection of unconnected facts inserted by people pushing different points of view. I think you just started it all over again. I have tried to run what you added into the paragraph. Regards Charles Esson 20:47, 31 January 2007 (UTC)

Might I suggest that, while there is a vague "covenant not to sue" from Microsoft in respect of the OOXML standard in and of itself, this article should point out that there is no such covenant offered for proprietary Microsoft sub-formats and protocols (such as WMF and ActiveX) that the OOXML standard invokes.

The covenant not to sue is not vague; MS has clarified the IP considerations as part of the ISO process. The standard does not "invoke", it allows any kind of binary data, just like ODF. That it reserves names for common data formats from that platform does not force anyone to use or accept such data to be conforming.[33] Rick Jelliffe 05:58, 14 February 2007 (UTC)

The OOXML standard does indeed call up all sorts of MS proprietary sub-formats (for which Microsoft has offered no 'covenant not to sue'). It almost seems as though Microsoft go out of their way to require MS proprietary sub-formats where an open one would do ... for example, no support of SVG (an open W3C format) graphics but do require MS proprietary WMF instead. [34] [35] Bob Sutor [36] notes Also, since they have avoided using industry standards like SVG and MathML, you’ll have to reimplement Microsoft’s flavor of many things. This type of observation is all over the net, [37] surely you couldn't have missed it Rick? Not much of an expert, are you? BTW, Microsoft seem to want to make it necessary to use their proprietary sub-formats in order to be interoperable, then get that mandated in a standard, then sue everyone who tries to interoperate for not respecting Microsoft's IP. [38] —The preceding unsigned comment was added by 202.1.119.216 (talk) 06:23, 18 February 2007 (UTC).

Err, a million parrots or sock puppets repeating something does not actually make it correct. Conformance to Open XML is defined in its conformance section. There is no "calling up" of WMF in the sense of adding a conformance requirement. 203.111.164.74 11:44, 24 April 2007 (UTC)

It is very easy to draw up an appropriate patent license which leaves no questions open. In fact you don't need any license to 'conform' a specification. And a "promise" is no legal applicable document. Podmok 13:46, 11 July 2007 (UTC)

This is very much a "la la I'm not listening" response. There is an official objection that "normative" parts of the OOXML specification are not covered by the "covenant not to sue". Microsoft/ECMA very much have utterly failed to respond to that criticism, and it is always swept under the carpet every time it is mentioned.

See my comment on "normative references" in the Normative References section. Those things are clearly not normative parts and I would be surprised if the objection is put again at the time of the draft ballot. If you have some other point, for example that there exist data formats with supposed IP rights under US law and that MS' licensing wrt Open XML does not cover every other format in existence, then make that claim: but confusing it with incorrect statements about non-existent "normative" references just clouds what is a worthwhile issue to examine. The "normative reference" claim seems to have been FUD put up at the Groklaw site, as part of their inappropriate "never mind the quality, feel the width" approach to objections, then written up by we-now-know-who and sent to Kenya, who do not seem to have been particularly critical of their sources. Rick Jelliffe 21:12, 8 May 2007 (UTC)

I'm thinking of putting a reference to the concerns over licensing back in. Certainly Japan standards body thinks there is a concern, if not over OOXML itself, then at least over the Microsoft proprietary sub-formats that OOXML references repeatedly. [39]

Japan had a specific question about IP, namely they wanted a clarification over the status of derivative works, such as profiles or subsets or schema mashups. The Emca response is that the license or covenant not to sue does cover derivatives. Note that as an official response to ISO, this certainly has good standing in court actions. Please don't misquote the Japanese question or the Ecma response. Note that Japan's clarification request comes in the context of its stated expectation that the DIS (Draft Internation Standard, i.e. OpenXML perhaps after it has been revised to cope with comments from this round) will receive broad international support.

Microsoft themselves however state that the license or covenant not to sue does NOT cover sub-formats that are "merely referenced" by the OOXML specification. The Kenyan objection KE13 specifically points out that certain required parts of the specification ("normative" is the word they explicitly use) fall into this "not covered by the promise" category. The ECMA response brushes over this, and essentially ignores the point made. —The preceding unsigned comment was added by 202.1.119.216 (talk) 10:31, 30 April 2007 (UTC).

See my comment on the meaning of "normative reference" in the Normative References section.Rick Jelliffe 21:12, 8 May 2007 (UTC)

Licensing 2

In the current licensing section, I think the following text should be removed. "However the issue raised by Kenya identified as [KE13] in that ECMA response document [2] is that the various mentions of the Microsoft proprietary sub-formats which are "merely referenced" by OOXML are described by the Kenyan objection as "normative". In standards terminology, "normative" means "considered to be a prescriptive part of the standard". [3]" A simple reading of Ecma 376 shows that there is in fact no normative reference, nor that WMF is prescriptive or essential. WMF is included as a "possible enumeration" and it is misleading if not bizarre to claim it as a "normative reference." In any case, there is a criticism section where this would belong, if it were not daft. Rick Jelliffe 21:20, 8 May 2007 (UTC)

Removal of "daVinci" criticism

I've removed

• Although Microsoft assert that ISO/IEC 26300 (ODF)[40] does not fully support their legacy formats, and give this as the purpose for OOXML[41], the daVinci plugin for Microsoft Office claims otherwise.[42] [43][44]

for the following reasons (NB: currently there is only ODF 1.0 and ODF 1.2 does not exist):

• Download Page for daVinci and InfoSet beta software tells us:

That version was optimized for perfect interoperability with an ODF 1.0 ready application, OpenOffice.org. Tuning da Vinci ODF 1.0 for perfect interop with OpenOffice came at the expense of perfect fidelity with the billions of binary MSOffice documents in circulation. (...) We knew that da Vinci could deliver both perfect fidelity with legacy billions of binaries, and, perfect interop with OpenOffice; but only through the use of ODF 1.2 metadata RDF/XML advances expected to be adopted during 2007 in the OpenDocument v. 1.2 standard. We expect this ultimate "perfect fidelity / perfect interop" da Vinci ODF 1.2 version to be released when OASIS, OpenOffice, and other ODF ready applications add support for ODF v. 1.2. (emphasize mine)

• On OpenDocument as the perfect Microsoft Office file format (linked from daVinci download page) Gary Edwards tells us:

The da Vinci plugin is conformant with version 1.2 of the ODF specification still working it's way through the OASIS ODF sub-committees and is dependent on features of the draft specification that may conceivably change.

• On Office Feature Mis-Match Sam Hiser tells us:

(Please keep in mind that da Vinci files that are generated/originated in ODF cannot be viewed in the current OpenOffice.org v2.0 [which is compliant with ODF spec v1.0] because da Vinci is designed to work with ODF specification v1.2, which is due to be represented in a version of OpenOffice.org later this year.) (emphasize mine)

So it is not possible to preserve Word documents with full fidelity in ODF 1.0 as stated by Microsoft.

Existhigh 23:46, 29 January 2007 (UTC)

The conclusion "So it is not possible to preserve Word documents with full fidelity in ODF 1.0 as stated by Microsoft" is wrong. As you state, http://opendocument.foundation.googlepages.com/home Download Page for daVinci and InfoSet beta software] tells us:

That version was optimized for perfect interoperability with an ODF 1.0 ready application, OpenOffice.org. Tuning da Vinci ODF 1.0 for perfect interop with OpenOffice came at the expense of perfect fidelity with the billions of binary MSOffice documents in circulation.

It says that with the daVinci plugin, you can have either perfect conformance with OpenOffice.org's implementation of ODF version 1.0, or you can have perfect interoperability with Microsoft legacy documents, but not both together. Microsoft's purpose would have been met by the latter option as opposed to the former.

Further support of this analysis is found here: [45] where it says: With this download da Vinci produces ACME 376 XML and demonstrates perfect conversion fidelity with the legacy billions of binary documents. And it can do this with ODF 1.0 and ODF 1.2.

Microsoft's (and Existhigh's) conclusion is therefore demonstrated to be wrong. It IS possible to preserve Word documents with full fidelity in ODF 1.0. The daVinci plugin demonstrates this.

But even if it were correct, Microsoft could very easily have suggested to the ODF committee whatever Microsoft felt was needed in ODF. Microsoft refrained from saying anything, then later complained about so-called deficiencies it did not highlight when invited to do so. Refer here: [46] "ODF can handle everything and anything Microsoft Office can throw at it. Including the legacy billions of binary documents, years of MSOffice bound business processes, and even tricky low level reaching add-ons represented by assistive technologies."

"Microsoft refused to participate in the OASIS ODF development process, even though they have been an official member of the OASIS group since it's inception. As an "observer" MS has had full access to all discussions, meeting minutes, proposals, documents and white papers. It was their decision not to participate."

"Now they claim that ODF is unable to handle the advanced feature set of MSOffice and the full conversion fidelity of those billions of binary documents to XML. This claim stands as the justification for their not participating in the ODF development process. And, more importantly, as the justification for ISO/IEC to adopt a second XML file format that does exactly what ISO 26300 (ODF) is designed to do."

Contrary to what Existhigh claims above, ODF version 1.1 is approved, and ODF version 1.2 is still in approval stages, but it does nevertheless exist. Refer to the somewhat out-of-date page here: [47]

1. OpenDocument 1.1 was approved by OASIS on October 19, 2006. It includes additional features to address accessibility concerns.[5]
2. OpenDocument 1.2 is currently being written by the ODF TC. ... Originally OpenDocument 1.2 was expected by October 2007.[6] However, upon learning that many of its activities will be completed far before then (e.g., the formula subcommittee expects to complete in December 2006), the group has agreed to develop a newer accelerated schedule.[7]

Given the misinterpretation and the mistaken conclusion by user Extinguish (shown by my highlight in bold above), I propose restoration of the original text as a valid questioning of the whole purpose of EOOXML. - unsigned

While getting a user name is not necessary for editing, it is very useful in cases of editing disputes to gain credibility. Please get an account. They're free ya know. WAS 4.250 16:10, 30 January 2007 (UTC)

It is not possible to preserve Word documents with full fidelity in ODF 1.0. It is possible to preserve Word documents with full fidelity in a proprietary format (ACME 376 XML) which might or might not be compatible with future ODF 1.2. daVinci only supports Winword, i.e. cannot convert Excel or Powerpoint files. Applications conforming to ISO ODF 1.0 cannot open ACME 376 XML files, that is only Winword/daVinci can open those files.

It is possible to preserve Word documents with full fidelity in ODF 1.0, in ODF 1.2 and in ACME 376 XML. The plugin that achieves the first two are not yet released, but they have been shown to official bodies. A version of daVinci which produces ACME 376 XML deliberately named because there is no formal standard (yet) that conforms ... is offered to demonstrate the capabilities of the plugin. Refer here: [48] which says the following:

The first is that the daVinci conversion engine is both awesome, and flexible. With this download da Vinci produces ACME 376 XML and demonstrates perfect conversion fidelity with the legacy billions of binary documents. Yes, da Vinci defies gravity itself. And it can do this with ODF 1.0 and ODF 1.2.  ; The ACME 376 Compatibility Kit proves that Microsoft is not the only entity capable of writing a native and entirely transparent to the user file format level conversion add on. da Vinci is a great testament to the MSOffice add-on development environment.  ; The ACME 376 Compatibility kit also proves that da Vinci is versatile. This configuration produces ACME 376. The mainline da Vinci produces ODF 1.0 and ODF 1.2 (only 1.2 will be released). If we wanted, da Vinci could be used to convert to Chinese UOF, Oracle XML or Romanian XML.  ; Most importantly, the ACME 376 Compatibility Kit proves that the Microsoft Ecma 376 Compatibility Kit is not the only XML plugin effort able to provide perfect fidelity with the billions of binary documents that so essential to the world's desktop bound business processes. Perfect file conversion fidelity without disruption, re training, or costly re-engineering of critical day to day business processes is beyond important. That's why it's at the heart of the da Vinci promise.

The ACME 376 version of daVinci is offered as public proof of the power of the plugin. The plugin has, however, been demonstrated to government bodies as proof of the ODF formats. ODF is well capable of storing anything in Microsoft legacy binary formats, and it has been so since ODF 1.0, and the daVinci plugin has the ability to demonstrate this fact. refer here for backup: [49]Microsoft has long claimed that only their proprietary Office Open XML could convert those billions of binaries to XML without loss of fidelity (data loss, or "lossiness"). They claimed that ODF was inadequate and unable to handle the rich feature set of Microsoft Office. This is a strange claim in that the "X" in XML stands for eXtensible. Since XML formats are eXtensible, of course ODF can handle anything Microsoft Office or those billions of binary documents have to throw at it. Existhigh, you repeatedly fall for the trap of assuming what Microsoft says is true. Please remember, when Microsoft claim "that only their proprietary Office Open XML could convert those billions of binaries to XML without loss of fidelity" ... that this is a totally unsupported claim, with no evidence whatsoever presented at any time ever to back it up.

OpenDocument 1.1 is only approved by OASIS not by ISO. OpenDocument 1.2 is not approved and does not exist as a standard. Existhigh 22:12, 30 January 2007 (UTC)

OOXML is only approved by ECMA not by ISO. OOXML directly contradicts (in the ISO sense of the word) what ISO 26300:2006 can already provide, and so is unlikely ever to be an ISO standard.

I must say I have some doubt about these claims. Perfect fidelity claims can only be guaranteed if they can convert the files back to the exact copies of original files. However I doubt they can show that ability as they seem to convert only one way. hAl 16:47, 30 January 2007 (UTC)

The claim is testable, as a demonstration is offered. Perfect fidelity with legacy formats is also a claim of OOXML, so I don't see any valid reason to doubt that the same thing (using the same data in memory and the same API) can be achieved for ODF. After all, what is the real difference between legacy binary <-> OOXML and legacy binary <-> ODF anyway? Why is it difficult (especially in the face of an offered objective demonstration) to credit that Microsoft's unsupported claim that "ODF cannot support legacy binary formats" is in fact a mistaken claim? —The preceding unsigned comment was added by 202.1.119.216 (talk) 20:27, 30 January 2007 (UTC).

what is the real difference between /legacy binary <-> OOXML/ and /legacy binary <-> ODF/

There are huge differences (overall document structure, vocabulary, ... ) between OOXML and ODF. For details see the specs Existhigh 22:12, 30 January 2007 (UTC)

There is a difference in the overall document structure, vocabulary, ... but in repect of the capability of the formats to store document information, ODF is the more capable, not OOXML.

I downloaded the software and it didn't install on my system; this makes it difficult to verify as an "existence proof". Rick Jelliffe 23:35, 30 January 2007 (UTC)

The Sun plugin for Word 2003 is now available for download at no cost, perhaps you can try that instead.[50] "This initial plug-in application will support the conversion of text documents (.doc/.odt) only and full support of spreadsheet and presentation documents will be available in the final version, expected in April." With these plugins becoming available offering industry-standards support (ie ODF) for MS Office and seamless operation with other existing IT infrastructure and business processes, it is hard to see any purpose at all for OOXML. —The preceding unsigned comment was added by 202.20.20.129 (talk) 23:28, 25 February 2007 (UTC).

For people who dispute that ODF can fully support Microsoft's legacy formats, and will not accept the daVinci plugin as a demonstration that in fact it can, perhaps they might accept the Sun Microsystems plugin as that demonstration instead? [51] [52] "The early access version of the OpenDocument Format (ODF) plug-in, available as a free download, will allow seamless two-way conversion of Microsoft Office documents to ODF. " "“Organizations can now consider switching to ISO/IEC 26300 OpenDocument Format while protecting employees needing assistive devices only supported by legacy Microsoft software,” said Rich Green, executive vice president, Software at Sun Microsystems. “ODF is important because it ensures documents will still be readable long into the future while allowing a wide choice of proprietary and open source software choices to work with the documents.” " See also [53] [54]

Both the Davinci plugin and the Sun plugin seem to use the binary format of MS Office as a basis for conversion using old open source conversion software taken from for instance OpenOffice or KOffice versions that supported the old binary .DOC files. Allthough these give pretty good results they seem to be actually not OOXML converters but really .DOC converters that use MS Office for the conversion of the OOXML to .DOC. However it is unlikely that both converters have resolved the imperfections that existed before in those .DOC to openoffice conversions. Likely .doc files that were though to open in OpenOffice will be though to open in these converters to. hAl 15:49, 9 February 2007 (UTC)

Not quite. Both the daVinci plugin and the Sun plugin are file "open and save" plugins. They convert between the representation of a document in Office's memory and a file format on disk, formatted as much as possible in ODF. Any bits of the document in memory that are obscure and unknown (due to Microsoft not revealing the formats) are saved as binary blobs of "metadata" in the ODF file format on disk. On re-loading that document into memory, the obscured bits saved as metadata are restored into memory, so the whole document is 100% intact through the round trip. In this respect, they achieve EXACTLY the same as OOXML itself achieves. They are "parallel" to OOXML. So in that sense, yes, they are not OOXML <-> ODF converters like the CleverAge plugin is. Instead, they are OOXML replacements. They can both be set as the default file format in place of OOXML, and in that sense are better than the CleverAge plugin. Note also that if you load an OOXML document into memory, and then save it back to disk as an ODF document using the Sun or daVinci plugins, you have in effect achieved OOXML -> ODF conversion.

Well effectivly it is virtaully the same. What it actually means it that allthough full conversion is suggested in reality not all functionality is converted to regular ODF and cannot be interpreted by any program. So the stated claim in the article that it can support every feature in OOXML seems not really correct.

Also the binary formats of MS Office not unknown. You can just ask for them here: http://support.microsoft.com/kb/840817. hAl 08:19, 10 February 2007 (UTC)

The whole complaint the legacy Microsoft binary formats is exactly that they are Microsoft secrets. Anyone who has documents saved in Microsoft formats is beholden to Microsoft to be able to access their own data. Using ODF instead, via either the Sun plugin or the daVinci plugin, gives you a great deal more interoperability with products from other vendors running on either Microsoft platforms or on other platforms. You still have 100% interoperability with your own files while running on Windows using Office. You don't get 100% interoperability with the other products, but far better than anything Microsoft offers. Using ODF instead of OOXML, you gain all that interoperability, and you gain interoperability for your own files across different versions of Office, and at what cost? No cost. If you use Office now, then still using Office but saving to ODF instead is 100% seamless to your current practices (as claimed) and you gain a great deal of openness and interoperability for no cost. In addition, if there is improvement in the deciphering of Microsoft's deliberately obscure formats, then newer versions of the ODF plugins will be able to progressively improve the conversions to ODF, still with no loss of fidelity as the file is used in Office, but over time gradually improving the interoperability through better versions of the plugin, so that there is less and less obscured metadata in your files. Finally, using the daVinci or Sun plugins, you can have all your new files as ODF, convert any of your old files to ODF if you need to archive them for long-term storage, and you have no need at all for any files saved in OOXML. You are no longer as dependent on Microsoft, and you have a good chance of being able to read your archived files far into the future (when there might be no Windows platform available). —The preceding unsigned comment was added by 202.1.119.216 (talk) 08:45, 10 February 2007 (UTC).

This is all about ODF and unnamed binary formats. The article is about OOXML. Rick Jelliffe 05:48, 14 February 2007 (UTC)

adoption

I think language in adoption can be toned down, and adoption updated.

1. "Only Microsoft" is unneeded emotive language. A reader should be able to work it out for themselves.
2. Removed "reacting to harsh criticism" does it really add anything?
3. Changed corel ref to corel press release.
4. Add note on Novell support.
5. Removed OpenOffice.org supports WordProcessingML 2003, the predecessor of the Office Open XML word processing format.
6. Gnumeric, removed "first program in final version". ( what does it add). I can't verify what is written is correct, ref is out of date as site has changed and I can't find alternative ref. Format is not mentioned in manual. It is mentioned that support for open office version 12 is well on the way, how is this related to version 13 which I believe is the version that supports Office open XML. Hopefully having to work to a standard will slow down the rate at which microsoft change their file format.
7. Put a request on Gnumeric mailing list for reference; words there are my guess after reading what I could find.
8. Altered Panergy entry to use the same words used in "File format and structure" section. Made clear transfer is by RTF. Tidy up Panergy ref a little.
9. Altered to list and put in alpa order as more to come.
10. Added two more items.

I am excluding items that use docm as this seems to go past docx and include Microsoft propiority extensions ( Correct me if I am wrong).

Charles Esson 11:41, 31 January 2007 (UTC)

Actually, both docx and docm files are both conforming Office Open XML files, as far as I can see. Microsoft marketing material never puts it like this, presumably to forestall attacks and to promote the creamy goodness of OpenXML. Open XML is an OPC container and some schemas, and there can be any kind of other file in there. "Proprietary extension" is not really the right term, unless you term JPEG as an extension too: containers are designed to contain things. The difference between docx and docm is that Microsoft applications will disable macros in .docx files, a matter of safety not standards conformance. Rick Jelliffe 19:29, 4 April 2007 (UTC)

Renaming to "Office Open XML"

Okay... there seems to be enough support for renaming this article to "Office Open XML" that I think we should do it. I'll do the rename two days from now if there are no objections posted here that give clear rationale for keeping the name as-is. -/- Warren 22:33, 30 January 2007 (UTC)

.... aaaand I guess someone just went ahead and did it. -/- Warren 21:18, 31 January 2007 (UTC)

reference broken

I noticed reference 19 is giving an error. I don't know how to fix it, that's why I'm posting this 213.219.154.194 13:58, 31 January 2007 (UTC)

I added the link, it still works for me; can someone else see it it works for them. Charles Esson 21:00, 31 January 2007 (UTC)

Works for me, too. WLD^talk|edits 08:31, 1 February 2007 (UTC)

Thanks, I tried from work also and it works there. Charles Esson 08:38, 1 February 2007 (UTC)

Criticism

Warren I thCriticismought the article was better with the criticism all in one section; it's not like the article is that long that it is about to split. Further it did make a good introduction to the criticism sections which suffers a little from multiple edits from different points of views. I suppose the question is the criticism a main issue. I was quite happy with the boundary issues and was about to start reading the standard, the actual description ( the content) of the standard is pretty light weight. 6000 pages, thats 12 reams if you try and print it out, it has to contain something. Charles Esson 04:49, 3 February 2007 (UTC)

As a general rule, it is considered better for NPOV if criticism is not separated into a separate article or subsection but is as integrated as possible. It is typical for articles in the process of development to have these less than optimum qualities, but it is not what we are aiming for. WAS 4.250 05:04, 3 February 2007 (UTC)

Have a look at WP:LEAD to get a sentence of what an article's lead section should contain. -/- Warren 06:39, 3 February 2007 (UTC)

Yes I see your point, it has to be able to stand alone. How about it gets reduced to: "Office Open XML has been the subject of considerable controversy in the computing industry." and joined to the previous paragraph, and then expand in the Criticism; I just think as it stands it sounds like a petty jab. Charles Esson 07:43, 3 February 2007 (UTC)

I've written a lot of lead sections in my time, including having one that was featured verbatim in Article of the Day, and I very strongly disagree. You can't just infer that some people are critical of a subject, without stating who exactly those people are. This is a requirement per our WP:NPOV policy, and as such is not up for discussion. The sentence as it stands identifies which groups are involved in the criticism, right up front, and that is the correct way to go about things. -/- Warren 18:20, 3 February 2007 (UTC)

I think the critisism on OOXML is which was moved to the lead section was not very relevant especially the reference. Also It is not very consistent compared with a simular article. Another point is that at least of the critisism is added to influence political descisions. I think it is fair enough to keep the seperate critisism section allthough frankly some of the issues mentioned it it are of very questional level but that is up to the people who critisise I guess. Also the critisism seem to be very much the target of edits which for which the seperate section is also more appropriate. hAl 18:44, 3 February 2007 (UTC)

None of what you're saying here is in accordance with real, actual Wikipedia policies and guidelines on neutral, accurate representation of a subject. I've told you this on your talk page, and I'll tell you again here: Read WP:LEAD, WP:SUMMARY, and WP:NPOV, in their entirety, before removing this text from the lead again. -/- Warren 23:16, 3 February 2007 (UTC)

Sourced criticism of Office Open XML from respected experts belongs in the intro (before the table of contents). WAS 4.250 02:02, 4 February 2007 (UTC)

kneale my edits where not attempts at vandalism but considered changes that I didn't consider that controversial., to go through the edits one at a time; feel free to revert back, but I would be interested in reasoning. Sorry I didn't log in.

• Removed "(which is actually only the period for the review of contradictions and not for the review of the entire spec as that period is 6 months)"; the 6 months is a ballot period not a review period, it is wrong.

Hal has reverted, left a note on his user page with reference, up to him to revert back or tell me I'm wrong; i'm not doing it again.

• "following an Excel workaround for spreadsheets imported from Lotus 1-2-3" sounds like an excuse; it isn't, Microsoft tried to make their product compatible with the dominant player at the time, change wording to reflect this.
• Full stop at end of "Lack of support"; may not be proper sentence but it is the end of the point.
• Change section headings to bold so that it is clear there are two groups.
• Change what was the section summary to include the name of the Microsoft competitors, if you need a reference it is mentioned in several articles, run the sentence together better, but now that it is back in the lead I am not willing to touch it. The sentence I came up with was "Office Open XML has been the subject of considerable controversy in the computing industry, with criticism of the document format coming from members of the free software movement, some independent software vendors and Microsoft's competitors Sun Microsystems and IBM, most of whom favor OpenDocument." I still think it would make a good introduction to the section.
• added requested ref for 6000 page comment.
• Could not find ref for cross platform support, I think "no other vendor can implement" is similar so changed to that and referenced.

Regards Charles Esson 07:35, 3 February 2007 (UTC)

Criticism 2

I would like to take all the following out; it just a collection of stuff and I don't think it will ever by well structured. I'm going to do the edit feel free to undo it but please turn it into something other than a pissing match. Charles Esson 11:54, 3 February 2007 (UTC)

Removed stuff that was put back; no need to have it here for easy access.Charles Esson 18:40, 3 February 2007 (UTC)

Criticism 3

If we are going to have it then lets do it properly, as it was it was all over the place. Warren and Hal please sort out the lead and please keep me out of it. Regards

The page numbers have to go; if it survives I will go through and work out which part they are in add that and remove the page number. Charles Esson 23:02, 3 February 2007 (UTC)

Criticism 4

I would ask that the reference to independent software vendors, and possibly others, be left in as those objecting to OOXML. There are many of us (I provided a reference as I thought that might help, but it was objected to) who are absolutely not part of the free software movement and not competitors of Microsoft's (my company is a long time Microsoft partner as well as a long time IBM business partner). This sentence as reverted to implies that only those who believe in free software or are direct competitors object to OOXML. That is completely uintrue. Would it help to provide other references? BenLanghinrichs 01:35, 4 February 2007 (UTC)—The preceding unsigned comment was added by BenLanghinrichs (talk • contribs) 01:34, 4 February 2007 (UTC).

I think the state of play is: Myself, Hal and Warrens have different views but we are trying real hard to get a good article and that is good. We have random visits from 86.84.111.211 who wants to push a particular line, he deleted your insert. My suggestion is as follows, put it in and make it as robust as possible with references. I think a fair summary is, I want the article to flow and be honest, Hal wants the crits to be realistic, and warrens wants the lead to be a valid. Charles Esson 02:30, 4 February 2007 (UTC)

: Sounds good to me. I'll round up some references and make the change when they are ready. Thanks! Also, thanks for the efforts to make everything work smoothly. It is hard to make a somewhat contraversial topic fair, easy to read and comprehensive, all at the same time. BenLanghinrichs 02:46, 4 February 2007 (UTC)

Looked at it some more, it has only been removed in the lead; warrens and Hal are having a serious debate over what that should look like. It's still in the crit section, if you could add additional refs in the crit section I think it would be good. What we all have to remember is wikipedia is not the place to win or lose. It's a place to record what is going on.Charles Esson 02:51, 4 February 2007 (UTC)

Looked at the ref and I can see what 86.84.111.211 was getting at; something in a mainstream publication would be good.Charles Esson 11:05, 4 February 2007 (UTC)

Criticism 5

To help NPOV, I suggest adding a paragraph like the following to the criticism section: "Much of the criticism of Ecma 376 has been collected or collated at the website Grokdoc. The wiki discussion page includes debate and dispute on those criticisms." —The preceding unsigned comment was added by Rick Jelliffe (talk • contribs) 19:59, 4 April 2007 (UTC).

Crticism 6

The text "despite the fact that many element attributes are defined as bitmasks" makes it appear that this is a well-known fact, whereas it is just an assertion. And it is wrong: as far as I can see there are only a couple of cases where bit masks are used (and the reason why bit masks are deemed bad, because they are not extensible, is wrong anyway because you can just add extra attributes in XML; and the other reason given that processing software cannot handle bitmasks is bizarre in the extreme.) I recommend replace "fact" with "claim". Rick Jelliffe 00:32, 14 June 2007 (UTC)

I recommend adopting the convention used by ISO where "notation" is used as the name for little languages. "format" is confusing because it is also used for styled documents. So "The notation incorrectly treats 1900" instead of "The format incorrectly treats 1900". Rick Jelliffe 00:32, 14 June 2007 (UTC)

On the general subject of criticisms, there is not an adequate disclaimer that stating the criticisms does not mean that they are correct. An innocent reader might look at the criticisms and think that they had the same truth value as the general text, rather than bein a report. I recommend replacing "Voiced criticisms include:" with "Voiced criticisms include the following claims:" Or put all the list items in italics. Rick Jelliffe 00:32, 14 June 2007 (UTC)

I see that a new Sam Hiser article has been added to the criticism section references, with the claim that this is a well-written article. However, it does things like claim that Open XML is flawed because Ecma has not submitted a reference implementation to ISO. However, ISO rules *ban* reference implementations: the standard's text should not have any competitor that can cause ambiguity AFAIK. Hiser's article misleads, whether intentionally or not I do not know. I am not necessarily asking that this link be removed, but to comment on its quality and the likelihood that it encourages ignorance and unwarranted confusion rather than dispells it. Rick Jelliffe 00:42, 14 June 2007 (UTC)

One might make similar statements about your own comments. The article makes a very clear argument for an important point of view, and presents its position very clearly. You are free to critique it, and others to critique your own points and references, but the bottom line is that important statements and positions from both sides have a place in Wikipedia, both in the article and as external links. Dovi 05:36, 14 June 2007 (UTC)

Criticism Section Too Long

I would have to say that the criticism section is terribly imbalanced compared to the rest of the article. It may very well contain more text than the actual information conerning the OpenXML standard. Unless people make a concerted effort to rewrite the criticism section in non-bullet form and with greater brevity, I will remove it or commence wholesale edits myself.

I agree on content being light on; that is the next job. Unfortunately I have to do a bit of research to deal with that. The relative word count is easy to determine with any good editor, feel free to work it out and report. There seems to be very little balanced material ( either way ) on the subject so I have to go back to the standard to work out what is going on. I think it should be divided into two sections, one that deals with the file structure the other with the standard, it is never easy to work out what is going on from a standard.Charles Esson 02:27, 5 February 2007 (UTC)

This article is not up to Wikipedia standards and has simply become a place to vent concerns over the recent cash for comment saga. --Rcandelori 01:21, 5 February 2007 (UTC).

I don't see any mention of the cash for comment saga in the main article, and that miss representation concerns me, it makes me wonder what your edits will look like, time will tell. This however is wikipedia, if you feel you can do a better job go for it; however, remember, no edits are golden, cash or not. I would prefer to see someone help me with the content. If your going to edit the criticism section don't try and pretend there is none, as clearly that is not a balanced representation of the facts.

Or to put it in blunt terms a deletion will be undeleted, a better set of words will survive. There are several people interested in this article with a wide range of views and I am sure they all would be delighted if someone else could contribute in a constructive way.

In summary, the solution to the problem is to get the content up to the point were the crit is not an issue, please help. Regards Charles Esson 02:27, 5 February 2007 (UTC)

My major concern is that this article uses bullet points far too liberally. This is not encyclopaedic, and further, use of bullets draws attention away from the main text of the article (i.e., the essential tenets of the OpenXML format). This is particularly exemplified in the criticism section. Anyhow, I have other work commitments at the moment but I will commence rewriting this article to fit Wikipedia Style guidelines in the next few days. --Rcandelori 03:33, 5 February 2007 (UTC)

Perhaps I'm misunderstanding you, but being in a bullet form is not a valid reason to delete. WAS 4.250 04:57, 5 February 2007 (UTC)

Looking forward to seeing what you come up with. If your going to have a go at the Criticism section please rewrite it so it flows, do it properly, make it balanced and remember it is supposed to summarize the criticism. To pretend there is none or that it is all unjustified is not balanced . It's a very rewarding exercise trying to see thing from alternate points of view.

For bonus points, why are Microsoft going to the trouble, and why do people care? The answer doesn't belong in the criticism section and I can't see how you would deal with this very important point in a balanced why that would survive in wikipedia.

Also have a look at WAS comment further up page re desire to get rid of the section in the end anyway.

Regards Charles Esson 11:33, 5 February 2007 (UTC)

The problem with the criticism section is that there is just too much of it. This not the arena to delve into scientific degrees of accuracy concerning the wide and varied criticism from all parts of the industry. My plan would be to cull less notable criticism - although, my elementary understanding of the XML standard makes this difficult. I would encourage those well-versed in this particular subject matter to examine the criticism in detail and cut bullets that are unnecessary. From there onward, I can rewrite the section in proper and organised paragraphs of prose. --Rcandelori 13:36, 6 February 2007 (UTC)

The Groklaw site on various criticisms of OOXML also has a discussion page in which the technical details are disputed. If the Wikipedia article mentions the criticism, where is the forum for mentioning responses and rebuttals. If there is no place for them, there is no NPOV to this section. Is it best to add a sentence to the end? What would the best NPOV form for such a sentence be: I am concerned too that the page should not give in to the myth that there are only two camps with opposing views. (For example, a person might think OOXML should not become a standard while still recognizing it is ridiculous to claim that OOXML's use of "i" to mean italic contradicts some other standard. So I don't like sentences like "OOXML proponents say ..." or "ODF supporter say ..." because it assumes that technical criticisms are subservient to pseudo-tribal affiliation.) Rick Jelliffe 05:45, 9 February 2007 (UTC)

I note that the criticism section has a link "Dark Corners.." to a Slashdot article that immediately links to an article by IBM's Rob Weir "How to hire Guillaume Portes". The criticism section also has a link ""How to hire Guillaume Portes Redux" that links to a followup article by IBM's Rob Weir, which also summarizes the Slashdot comments. Since they are links to start and the end of the same thread, why are they both needed? The "Dark Corners" link looks redundant. Rick Jelliffe 04:23, 13 February 2007 (UTC)

I don't understand why any wikipedia page needs a section named 'criticisms'. Anyone would be hard pressed to find it in another encyclopedia. A central tenant of wikipedia is its npov policy, because previously uninformed readers should be allowed to form their own opinions. Criticisms are extremely subjective, and many are just based on speculation (especially in this article). For contrast an article on Nazi Germany wouldn't have a criticism section, rather it would contain facts of major atrocities and let the reader decide for themselves. If people think that their must be a criticism section in this article at the very least it should be greatly toned down. Ether that or we can make a praises section that goes on about how great some people think open XML is (maybe from Microsoft?)to go along with the criticism.—Preceding unsigned comment added by 210.49.179.39 (talk • contribs)

Actually, most encyclopedias will describe objections by critics. A trite example would be to look "intelligent design" up in a modern version of Britannica (and probably any other encyclopedia). If a subject is contested, it is important to describe that. Being NPOV doesn't mean we shouldn't document criticism which others voiced and is citeable--it means that we shouldn't take a side in the debate. You'll see an extensive criticism section at OpenDocument#Criticism. I think that, aside from a few stray edits, the sections of both articles are fairly neutral and well-referenced. --Karnesky 14:04, 7 March 2007 (UTC)

I like your answer. However it seems that mentioning a whole bunch of criticisms and not having a large section on praise is taking a side. Opinions like "The 6000 page specification is too long to evaluate in the 30-day contradiction (only) review and the five-month ballot period" are subjective and purely speculation, far from what an encyclopedia is meant to contain. They are type of trivia that slants the article. 210.49.179.39 15:41, 7 March 2007 (UTC)

Feel free to add examples of praise for the format, as long as they're referenced. The complaint about the document being too long for a short window for review is not one that is being raised by WP contributors. It was raised publicly by critics of the format and was an objection raised by Australia, Czech Republic, Finland, India, Kenya, Norway, Sweden and the United Kingdom on the ISO committee. Ecma responded to it (though not necessarily to the satisfaction of the objectors). Far from being subjective speculation, the fact this criticism was made is both notable and verifiable. --Karnesky 16:17, 7 March 2007 (UTC)

I had coffee with Alistair Teggart of Standards Australia who wrote their response to ISO at the time he sent it. It is a mistake to necessarily attribute comments on the difficulty of evaluating something large to being criticism of the format: they are comments on the process. The complaint is not that the document is too long, but the time period is too short, IYSWIM. Indeed, a running theme of many of the comments is that the fast track processes are unsatisfactory, because they　bypass SC34 and its expert group WG1 (disclosure I am on that working group): this effects ODFas well as OpenXML btw. On the issue of the wording that 14 are "clearly negative" in the Standardization section, that is stated by a potentially biased source (the lawyer for OASIS) but not quoted with an attribution that would warn the reader of potential spin. A better reference would be Eric Lai of ComputerWorld only counts 6 comments claiming contradictions[55](My count [56] is 7). I suggest that the article should reference Eric Lai, and say "six to forteen" instead of "14" because he is an independent source. Furthermore, it is a mistake in terms of ISO process to think of this as a necessarily a vote that will prevent standardization: instead it is an opportunity for issues to be raised early to inform subsequent debate and voting, and for making　corrections. It just shows the openness of the ISO process. —The preceding unsigned comment was added by Rick Jelliffe (talk • contribs) 00:05, 8 March 2007 (UTC).

As usual in Wikipedia compare the criticism article against MS with criticism article about others... --Lastwebpage 16:50, 10 April 2007 (UTC)

copyright

I think the main section will fly better with diagrams explaining things.

1. Does anyone know if we can take images out of the standard.
2. Until I know for sure I will use GPL icons but does anyone know if we can use microsoft icons to create images.

Charles Esson 10:57, 5 February 2007 (UTC)

The Ecma site says Ecma Standards and Technical Reports are made available to all interested persons or organizations, free of charge and copyright, in printed form and, as files in Acrobat ® PDF format.[57] That seems to suggest that you can cut and quote. Rick Jelliffe 06:03, 13 February 2007 (UTC)

Finishing licensing

Has any one read the Baker & Mckenzie report, I agree with Hal it needs to be there to balance previous sentence I think we really need something to justify it, sort of just hangs.Charles Esson 11:41, 5 February 2007 (UTC)

Crit 5

The Open XML standard has been the subject of wide and varied controversy in the computing industry, particularly from members of the free software movement, independent software vendors,[24] industry analysts[25] and Microsoft's competitors Sun Microsystems and IBM, most of whom favor the OpenDocument format,

which is notably present in the freely available OpenOffice.org application suite.

• Interesting, but this is about OOXML and we can link to a open document article.

The essential premise behind this criticism, apart from several technical issues, is that Microsoft has standardised its proprietary format in order to prevent the widespread adoption of the Open Document format, which could threaten the dominance of Microsoft's own Office suite.

• I think it goes deeper than that, like the several technical issues this is just the story. I would put it like this ( but it doesn't belong in the article).

• At some point in the next 100 years mankind will move from paper to electronic books. It won't happen until a common reliable standard is available for the storage of the material. The OOXML standard is so bad it is going to slow that process down considerable. Microsoft could speed the process up by adopting something the industry agreed on but they haven't.

Furthermore, commentators have argued that while competitors will likely implement compatibility of the new standard in their own applications, Microsoft has not released any plans to similarly support the OpenDocument format.[26]

As the world's largest software company,

• why the free plug for microsoft, do we put after IBM (the worlds largest computer company) or after SUN ( the worlds largest Unix supplier), all points to be made in other articles.

Microsoft believes that its royalty-free format will end persistent incompatibility problems in working environments with diverse software applications due to its underlying foundation of strong industry standards such as XML and ZIP.[27]

• And this is just a bunch of marketing crap, it not even what is said in the reference.

• Come on lets try for a decent article. Charles Esson 20:47, 6 February 2007 (UTC)

converters should be left in...

I think a list of links to various converters should be left in the article. It will be a huge demand for these converters as people start receiving .docx as attachments to emails. People won't know how to open them or what to do... —The preceding unsigned comment was added by 193.217.78.97 (talk) 12:21, 11 February 2007 (UTC).

"Freely available" and "freely implementable"?

The article states that OOXML is an "Open Standard" according to the EU definition of that term, which involves being freely available and implementable. Do we have a cite anywhere to justify this statement, or to be able to make an NPOV statement that someone has asserted this? (For example, a quote from either Microsoft or the EU itself.)

There is an EU definition of Open Standards and its not compatible with OOXML. I quote from the Gierek Europarl report: "50. Recalls the definition of open standards adopted by the Commission pursuant to which (i) the standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties; (ii) the standard has been published and the standard specification document is available either freely or at a nominal charge; (iii) the intellectual property − i.e. patents possibly present − of (parts of) the standard is made irrevocably available on a royalty-free basis;", the Microsoft patent policy for OOXML is insufficient here and the claim of the opposite (reference 24) is misleading.Podmok 13:23, 11 July 2007 (UTC)

The "parts of" that you quote is infact only a patent grant over the required parts of OOXML that are defined in detail. Specifically Microsoft only grant patent use over "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."

Can we really say that the OOXML qualifies as an "Open Standard" by being "freely available" and "freely implementable" given that, according to its critics (see for example, the sources cited in [58]), it includes the use of binary blobs, the format of which is not documented in the spec, and that it seems to be unclear that the license grant covers these technologies, as they are not documented in the spec?

There is no such thing a a binary blob in OOXML. It doesn't exist !!! There is only limited references to embedded external formatstypes. As in ODF in OOXML you can embed any foreign object which can be binaries. And of course the licence cannot grant rights to embedded file formats as there is no restriction on what can be embedded. Also ODF does not grant such rights. Therefore a non-argument. hAl 12:42, 13 February 2007 (UTC)

Of course there are binary blobs in OOXML documents.

Microsoft's OOXML specification calls up all sorts of Microsoft proprietary sub-formats (such as VBA for example). Oh, and as far as being an "Open Standard" by being "freely available" and "freely implementable" goes ... it looks like Microsoft is shaping up to sue anyone who dares to even attempt interoperability with Microsoft's proprietary stuff. [59] [60] We must all 'respect those IP rights' after all. [61] —The preceding unsigned comment was added by 202.1.119.216 (talk) 10:32, 19 February 2007 (UTC).

Complete bullshit. External parts are not part of the spec. You can just as easy add VBA objects to ODF as to OOXML whether as binary or as non-binary. hAl 12:50, 19 February 2007 (UTC)

So you agree, there are binary blobs in OOXML documents. I suppose it doesn't really matter in the final wash-up since the lock-in is probably about to be broken anyway. [62] [63]

No I do not agree. Embedded binaries are part of both ODF and OOXML. They are not part of either formats specifications and don't form a binary blob. If you want to call embedded files binary blob's that is fine but then any file containing a jpeg or png file has a binary blob. Then the wikipedia logo on this page is a binary blob. Even ODF has 5 or 6 ways to embed binary object into its files. But you sound like the type that would not wat to see that... hAl 14:53, 27 February 2007 (UTC)

On the other hand reliable sources are available that shows that these binary formats are in fact documented in freely available specifications, and/or that the license grant includes the implementation of the technologies that they use, it would be useful to have this information in the article. -- The Anome 12:00, 13 February 2007 (UTC)~

There seems no need for documentation as there is no binary blob. hAl 12:42, 13 February 2007 (UTC)

Except of course for the binary blobs in the OOXML documents.

Embedded binaries are part of both ODF and OOXML. they are not part of either formats specifications hAl 14:53, 27 February 2007 (UTC)

So what about the Visual Basic macros in Office 2007? Are you saying either that:

• this is a false assertion by MS' critics, and that Office 2007 does not generate binary blobs in its OOXML documents? or that:

It is a false assertion yes. MS Office can add foreign binary elements to OOXML. Those objects are not part of OOXML but embedded. Currently MS Office does use at least partly embedded binary file elements for embedding vba macro's in OOXML files.

• VB macros are a "foreign object" that is not part of the Excel document?

They are part of the Excel document but not native OOXML. Simular to ODF files macro's that are also not defined in the ODF specs.

• VB macros are not intended to be interoperable or implementable by others?

Not thru current OOXML standardization (yet).

• Excel files generated by Office 2007 are not OOXML documents?

They are OOXML with Microsoft macro's embedded in them. In theory you can also have ODF files with MS propriety macro's in them allthough no such implementation exists yet. You could even add your own personal macro script language in OOXML or ODF files if you wanted to but it is unlikely any application would implement them.

• OOXML does not capture the entire content of the Excel document?

OOXML allows for foreign objects so it does capture the whole Excel document.

• or something else?

I think you summarized the options nicely but interpreted them a bit strangely.

-- The Anome 13:26, 13 February 2007 (UTC)

answers added where appropriate. Summary: Excel with macro's is saved in MS Office as OOXML spreadsheet with embedded macro objects. hAl 14:00, 13 February 2007 (UTC)

So, you're saying that the OOXML file contains the embedded binary macro objects (the "binary blob"), which are part of the document, but that they are neither standardized nor part of OOXML, so they don't count as part of the file for the purposes of standardization. Presumably, then, according to the definition above, an OOXML file can have any format at all, provided it is a wrapper around a binary file containing the real file semantics. For example, given your definition, I presume that an otherwise content-free OOXML wrapper for an Office 97 .doc file, and the file would be (a) valid OOXML, and (b) capture the entire content of a Word document (albeit as a "foreign binary" element in a "not yet standardized" format), and therefore be a possible "open standard" representation of that Word document? -- The Anome 14:49, 13 February 2007 (UTC)

Yes, that is correct OOXML can be used as a wrapper around an arbitrary format. This is however not unique as you can do this with ODF as well. both formats have not set any bounderies on what you can embed within the fileformat. In theory you could make put an entire office application in an office document file using OOXML or ODF. You should understand that any embedded external formats

A) can be ingnored by office implementations or

B) can be openend using a third party application (like a mediaplayer)

C) can be opened by the office application itself (like most regular picure formats and like macro's that the office application supports).

The handling of embedded formats is implementation specific allthough most implementations will directly support common picture formats as like jpeg. hAl 15:24, 13 February 2007 (UTC)

"The Office Open XML file is a ZIP package containing the individual files that form the basis of the document. As well as XML files the ZIP package can also include embedded (binary) files in formats such as PNG, BMP, AVI or PDF .

Since this is a complete break with the previous binary based Microsoft Office file formats, and is completely new, it isn't entirely clear what the extent of Microsoft's backwards compatibility claims[3] for OOXML are. It cannot be backwards compatible with existing Microsoft Office documents, by virtue of it being a completely new format, and it isn't backwards compatible with versions of Microsoft Office prior to 2007 without the Microsoft Office Compatibility Pack [4]."

It is backwards compatible it that you can convert from doc to docx and vice versa without losing anything.

You can do precisely that with ODF format as well using a true plugin such as Sun's plugin or the daVinci plugin [64]. The real "elephant in the room" [65] question then becomes, since you can save doc to odt (ODF) and vice versa without losing anything, and ODF is an agreed international standard, what valid purpose is served by OOXML? —The preceding unsigned comment was added by 202.20.20.129 (talk) 02:06, 27 February 2007 (UTC).

The davinci/sun plugins save binary data from MS Office memory in binary objects in the ODF files. When converting them back they store the binary item's back MS Office memory. You might call that compatibility but it obviously leaves a certain amount of data untouched and impossible for any application to use. hAl 14:58, 27 February 2007 (UTC)

Yes, that is (sort of) true ... at least the bit about there being a certain small percentage of the data that is still obscure. But then again, observe that the ODF produced by the davinci/sun plugins is a lot less obscure than the legacy binary MS Office formats, and also a lot less is obscure than in the OOXML format. Also, it is perfectly 100% backwards compatible in the sense that Microsoft use the term ... it is 100% compatible with Microsoft Office at all versions (back to '97). So when you say "leaves a certain amount of data untouched and impossible for any application to use" you are mistaken ... the truth is more like the davinci/sun plugins "leaves a certain small amount of data undeciphered and not yet possible for any non-MS Office application to use". All versions of MS Office can use it fine by also installing the davinci/sun plugins. So, in summary, using the (final versions of) the sun/davinci plugins will solve backward compatibility with 100% fidelity, and it will largely solve interoperability with other applications and other platforms, and "future proof" documnets and be vendor independant, whereas using OOXML will provide only partially the first of those features (backward compatibility) and none of the others. Hence there is no purpose that OOXML serves (other than Microsoft purposes) which is not better served by ODF.

I may have been a little over-optimistic here. It seems that while daVinci works for Office 2003 and XP and versions back to '97, and it did work for pre-release versions of Office 2007 and Vista, Microsoft threw in a dirty trick at the last minute to prevent it working properly now. [66] [67] Syll might be OK by April 2007 though. —The preceding unsigned comment was added by 202.1.119.216 (talk) 00:07, 3 March 2007 (UTC).

The fragility of API-based document systems is one of the prime reasons why markup-based systems are desirable. It is possible to make APIs that are as robust as a markup-based system that are as robust as a markup-based system, by adopting a properties based style (such as LISPs　putprop getprop, or SAXs properties) but XML-handling systems are usually written with the expectation that the document schema will change, or are written in the "push" style where the document drives the program execution. You adopt markup because you want to escape API fragility, not embrace it! Rick Jelliffe 23:36, 7 March 2007 (UTC)

An evaluation of EU's definition of Open Standards has not been performed in any detail and there are no citations. Removed section as it's not backed by citations. 202.135.231.49 04:07, 10 August 2007 (UTC) 202.135.231.49

Removed section again, please do not restore. Stating that patent grants have been given over the "standard format" is misleading, what is meant is that patents have been granted over the "required features" of OOXML. The reader interpretation of an Open Standards definition from 2004 applied to OOXML is without formal approval by the EU and should not be stated as fact without citation. Removing again. 202.160.118.227 11:59, 10 August 2007 (UTC)

Remove section again, please do not restore. The section incorrectly stated that non-required features of OOXML were extensions and therefore it was impossible to cover them, when infact many defined features of OOXML are not deemed as "required" and therefore although standardised in OOXML aren't given patent protection. Also, to repeat, the reader interpretation of an Open Standards definition from 2004 applied to OOXML is without formal approval by the EU and should not be stated as fact without citation. Removing again. 202.160.118.227 21:49, 10 August 2007 (UTC)

Microsofts OSP does not state it that is covers only features that are required. That is your words. It actually states that it covers "Microsoft patent claims nescesary to implement only required portions of the covered specifcation that are described in detail and not merely referenced in such specification". So if you require a portion of Covered Spec to for your implementation of the spec the promise is upheld unless it is merely referenced and therefore not an actual part of the specification. By your own refrasing / interpretation of the OSP you suggest something that is not correct. hAl 16:35, 13 August 2007 (UTC)

Actually talking about Microsoft's OSP was not my words, that was your incorrect inference. What OOXML itself states is that patents have been granted over "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.". 202.135.231.49 22:29, 14 August 2007 (UTC)

Trivia

"The TC45 committee is co-chaired by two Microsoft employees" - There is no reason to think that having two Microsoft employees made a difference, so unless this is meant to suggest something, it's just trivia and Microsoft's reference should be with the other companies. 211.28.194.140 04:37, 9 March 2007 (UTC)

Chairing a committee is different than merely serving on a committee. Mr. J. Paoli and Mrs. I. Valet-Harper (both MS) are the only chairmen. It isn't uncommon or trivia to point out who leads a committee. --Karnesky 04:55, 9 March 2007 (UTC)

Licensing does not inlcude other formats.

Several try to add info to the licensing section that are about referencing other formats. This is not relevant to licensing of OOXML itself and should not be in there. There is no requirement for implementing external formats even when you want to fully implement OOXML.

If you can suggest something that this licensing does not allow you to do with external formats which for example is allowed by ODF licensing then it could be relevant. At the moment however I do not see anything that suggest OOXML is more restrictive for adding external formats then ODF.

The fact that MS Office can embedd more formats because they might have patentrichts on those would also apply if MS Office uses ODF as they can embed exactly the same formats in ODF as well. That is an implementation issue and not a format issue. hAl 09:33, 16 March 2007 (UTC)

hAl - the most recent text you reverted says absolutely nothing about ODF viz:

Microsoft state that their "Open Specification Promise" does not "apply to things that are merely referenced in the specification" [68]. Hence any technology that is 'merely referenced' in the OOXML specification should not be used in a document that is intended to be interchangeable with non-Microsoft applications unless that technology is open, or the non-Microsoft application is licensed to use that technology. It is not simple for an end-user, intending interoperability, to determine just which document features may be affected by this.

Of course Microsoft could embed formats that are protected by US (and other countries) intellectual property laws into ODF, and Microsoft would be completely free to do so. The issue is that OOXML incorporates non-free technologies by reference, so although OOXML is arguably freely implementable, the practical effect of this is diminished as Microsoft can use non-free technologies in OOXML compliant documents. Someone implementing the OOXML specification then cannot interoperate fully with Microsoft produced documents unless they also licence the technologies included by reference. I think it can be argued that an open and freely implementable document format intended for interoperability should not use 'technologies' that require a licence. I think you have missed the point slightly, so I'll add the above text back into the article. Note that you should not revert it until after 16:18 (Wikipedia time) today, otherwise you will fall foul of the Wikipedia:Three-revert rule, and I'm sure you do not wish to do that. Regards, WLD^talk|edits 10:16, 16 March 2007 (UTC)

You state: "Someone implementing the OOXML specification then cannot interoperate fully with Microsoft produced documents unless they also licence the technologies included by reference." This however is fully independant of which format is being used. That would apply to MS using ODF as well. Again you do not prove any relevance to the actual format. I still have not heard how the stated lisensing clause limits the format compared to any other format. hAl 12:44, 16 March 2007 (UTC)

I didn't say it limited it. It is an attribute of the use, and would apply if Microsoft, or anyone else used 'non-free' technologies in the document format. The same point does apply to ODF, and is worth pointing out, as there is an unfortunate assumption that a document that complies with OOXML (or ODF) which are allegedly 'free and open specifications', will therefore only require 'free and open' technologies to successfully read, interpret and write new documents. This is patently not true, and needs to be made clear. WLD^talk|edits 13:24, 16 March 2007 (UTC)

You state: "I think it can be argued that an open and freely implementable document format intended for interoperability should not use 'technologies' that require a licence". It is nice of you to think that but it is not based on anything. In both ODF and OOXML you can embed any technology you want. That is purely implementation dependant. hAl 12:44, 16 March 2007 (UTC)

So are you saying that "an open and freely implementable document format intended for interoperability" can require licensing? I don't understand the point you are trying to make. WLD^talk|edits 13:24, 16 March 2007 (UTC)

Of course it can. In fact these office files are made and optimised for embedding third party formats. ODF for instance even has 6 or 7 methods of foreign objects embedding to provide for non ODF objects in the file. Office files are only interoperable as far as the implementations are interoperable. If OOo includes mpeg video files in files and Koffice only supports xvid's then the resulting files are not fully interoperable. As MS Office probably support more native format then most other Office suites it is unlikely that other office suites can fully interprete those formats when they are embedded no matter what format the Office file is created in. 16:07, 16 March 2007 (UTC)

I think you are missing the point. If we look as Ecma's response to the national body comments (available here: [69]), specifically in the issues raised by Kenya, labelled as [KE13], Ecma's response seems particularly weak.

Annex N of the JTC 1 Directives applies to International Standards developed by JTC 1 subcommittee, using the five-stage process, and not to documents submitted through Fast Track. As such, this comment is not relevant to the OpenXML submission.

The issues raised are apparently substantive, viz (spelling errors and typographical mistakes are in the original):

The Ecma Office Open XML specification makes normative references to several technologies which are not described by existing International Standards, nor have they been developed by an Approved RS Originator Organization (ARO) as defined in Appendix N7 of the JTC1 Directives. Examples include:

• RTF -- a proprietary document format from Microsoft
• MHTML -- a proposed standard, but not yet approved in IETF
• "earlier versions of WordProcessingML" -- a proprietary format of Microsoft used in Office 2003
• Bitmap, EMF, and WMF -- proprietary image formats of Microsoft
• Requirements to emulate the behavior of legacy word processor applications, such as Word 95, or WordPerfect 5.

For none of the above specifications RER's and access to the actual RSs have been provided together with the ISO/IEC DIS 29500. In addition the 'Licensing conditions that Microsoft offers for Office Open XML' (see JTC001-N-8455-3) explicitly exclude all items merely referenced from the licensing commitment.

To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft controlled atents 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.

Normative references to an application's behavior, absent any fixed, written expression of that behavior in the form of a publicly available specification cannot be permissible.

In other cases, references are made to specifications without indicating versions or publication dates. For example, for the "sqlType" attribute in Section 3.10.1.3 of the SpreadsheetML reference, the specification merely says, "The following are data types supported by ODBC. For a more information, see the ODBC specification." Without more information it is impossible to identify the exact specification referenced or what IP terms are available with it

The penultimate two paragraphs make the point, and are backed up by the examples given just before. You may believe the issues raised by Kenya to be incorrect, but they certainly show a national body that believes that the OOXML specification clearly includes references to technology not covered by Microsoft's promise, and which are necessary to the implementation. —The preceding unsigned comment was added by West London Dweller (talk • contribs) 18:48, 16 March 2007 (UTC).

Forgot to sign, the bot got there before me. WLD^talk|edits 18:49, 16 March 2007 (UTC)

The disputed text included: "It is not simple for an end-user, intending interoperability, to determine just which document features may be affected by this." What has this got to do with OOXML licensing ? Is there any indication that an enduser understands format licensing ? Is this different for people using other formats than OOXML ? hAl 12:55, 16 March 2007 (UTC)

So are you saying that not knowing the legal status of the document format you are using has no effect on interoperability? All the people that got stung by GIF might have something to say about that. WLD^talk|edits 13:24, 16 March 2007 (UTC)

You state: "the practical effect of this is diminished as Microsoft can use non-free technologies in OOXML compliant documents". So what ???? Everybody can use non-free technologies in OOMXL. Not just Microsoft. This has no bearing on the licensing. Actually Micrsoft can also use all of it's non-free technologies in OpenDocument. And also so can others. Can you please explain how this would make OOXML any different from any arbitry format used by any arbitrary implementor ??? hAl 12:59, 16 March 2007 (UTC)

It doesn't make things different, and this is not a pro- or anti- OOXML or pro- or anti- ODF point: it is a point about being aware about what a licence does or does not cover. Anybody can use a non-free technology encapsulated in either or both of OOXML or ODF. The practical effect of that is to make interoperability more complicated, requiring licencing. WLD^talk|edits 13:24, 16 March 2007 (UTC)

You think it applies equally to ODF and OOXML ??? So why aren'tyou adding to the Opendocument article in it's licensing section after the referral of Sun's covenant the following line: "formats which are not needed to fully implement ODF, but may still be embedded in ODF, are not patent claim free." This is as true for ODF as it is for OOXML. somehow people keep trying to add it only to the OOXML article though. hAl 15:59, 16 March 2007 (UTC)

...and hAl, you are in breach of Wikipedia:Three-revert rule. It's there for a reason. Please don't ignore it. WLD^talk|edits 13:24, 16 March 2007 (UTC)

alternativly I objectified the text. Now it actually states what this clause means namely that Micrsoft does not grant patent rights on on formats not needed to implement OOXML fully. hAl 13:54, 16 March 2007 (UTC)

That is hardly objective. It may or may not be required to "implement OOXML fully" (and only according to Microsoft), but what is actually needed if OOXML is to become a standard is to to ascertain if something is or is not required in order to enable full interoperation. —The preceding unsigned comment was added by 202.1.119.216 (talk) 07:27, 5 May 2007 (UTC).

"Full interoperation" is simply not the test, and it will never fly at ISO. There are four or five parties involved in office suites. But there are tens of thousands of developers involved in data conversion, generating or extracting information from files, who only use well-defined *portions* of the document technology: full interoperability in the sense that every Open XML processor will be able to accept and use all parts of every possible Open XML document has never been a criterion; indeed, it is not for ODF either. I honestly don't know why people waste their time on this: the X in XML means eXtensibility: ISO likes extensisbility, and extensibility opens the door to the client not being able to handle something sent. Furthermore, conformance to Ecma 376 is not defined in terms of full ability to process, but rather just the ability to read and write according to the schema (and the default semantics, where appropriate.) Rick Jelliffe 20:14, 8 May 2007 (UTC)

Microsoft Office XML heritage

Older revisions of this article referred to the XML formats supported in Microsoft Office 2003, but there is no such mention now, except for the Microsoft Covenant Regarding Office 2003 XML Reference Schemas link in the References section (this link now redirects to an OOXML page at microsoft.com). It seems to me that those older formats are worth documenting (here or elsewhere) — they're actually quite easy to generate, even without involving any MS software (e.g. for report-generation via XSLT). The nomenclature is still a bit confused to me.. Microsoft Word#File formats indicates that the XML format used in Word 2003 was called WordprocessingML, which now redirects here — but the 2003 XML format is different from the OOXML format. Was this article's old revision correct to say that "WordprocessingML" ambiguously refers to two incompatible XML dialects? —Fleminra 21:54, 16 March 2007 (UTC)

References to the preceding MS Office 2003 XML formats used to be in the article. (I put some in myself) but were removed in later revisions. hAl 09:53, 17 March 2007 (UTC)

I didn't look through every revision of every relevant article, and read every discussion, but it looks like WordprocessingML used to be a useful article, and it was decided to merge that into Microsoft Office Open XML, and then when Microsoft Office Open XML became Ecma Office Open XML, folks decided that the 2003 stuff was not relevant? Well, I've started User:Flemingr/Microsoft Office 2003 XML formats. I think it has useful information that is not presently covered elsewhere. Unless there are objections (that may have been stated somewhere but I haven't read), I'll move this into the main namespace. —Fleminra 00:22, 19 March 2007 (UTC)

File Format

Following are some suggested changes to the section on file formats.Rick Jelliffe 14:46, 4 April 2007 (UTC)

Introduction

The introduction does not even mention OPC and it launches into a polemic that belongs in the criticism section. I suggest it should be in a section "Open Packaging Conventions"

"Office Open XML uses Open Packaging Conventions (OPC), which provide a profile of the common ZIP format. As well as XML data and document files the ZIP package can also include other text and binary files in formats such as PNG, BMP, AVI, PDF, [[RTF] or even ODF. OPC also defines some naming conventions and an indirection method to allow position-indepence of binary and XML files in the ZIP archive."

"OPC files can be opened using common ZIP utilities. Open source libraries in .NET and Java are available for using OPC. OPC is specified in Part 2 of Ecma 376 (131 pages) but is not dependent on other parts of Office Open XML. OPC specifies the details of the ZIP format because ZIP has not actually been specified by any international standard previously, but has widespread community and developer acceptance."

"Microsoft offers a Microsoft Office Compatibility Pack without which Office 2000 and Office 2003 cannot import or export OPC-based Office Open XML files." "Note that some software applications may also offer as an export option to forego the use of OPC and instead to generate single, large XML files with binary files encoded as hexadecimal or "bin64" strings, but still using the Office Open XML vocabulary." Rick Jelliffe 14:46, 4 April 2007 (UTC)

Thanks for creating the new page on OPC. I have copied and improved some of the material over there. Is it OK if I removed my comments or draft suggestions from this comment page after they have been suggested, in order to have this page as a record of disputed material and issues-in-progress? It is already so big, and the rollback preserves old entries? 124.189.122.186 06:01, 5 April 2007 (UTC)

The current second paragraph "since this is a complete break with the previous binary based Microsoft Office file formats, and is completely new, it isn't entirely clear what the extent of Microsoft's backwards compatibility claims.." is just dumb, to me: by its nature a new file format will not be syntactically compatible, and any compatability must be in terms of information rather than bits. This is a kind of straw man argument, because it seems to be based on the idea that Microsoft or anyone has ever claimed that old applications will be able to load or produce the new format without add-ons. Claims disputing the extent of backwards compatability should be in the criticisms section and provided with a reference and removed otherwise. I recommend removing (or moving) this paragraph. 124.189.122.186 06:01, 5 April 2007 (UTC)

Totally agree. Badly worded, and clearly doesn't belong in the "File Format and Structure" section. Since there is (imo) better-worded objections already in the Criticism section, I've removed the paragraph entirely. BradC 16:26, 27 April 2007 (UTC)

Container Structure

In the first paragraph, replace "A basic Office Open XML file" with "Office Open XML files conform to OPC and different applications have characteristic directory structures and file names. An OPC-aware application will use the relationships files rather than directory names and file names to locate individual files. A basic Office Open XML file" .Rick Jelliffe 15:06, 4 April 2007 (UTC)

Add as second paragraph "In OPC terminology, a file is a part. A part also has accompanying metadata, in particular MIME metadata. Note: OPC fulfills some of the same compound document functions as the obsolete Apple Bento format; Bento was developed into a format known as OpenDoc which should not be confused with Office Open XML, Office Document Format, or Open Office."Rick Jelliffe 15:06, 4 April 2007 (UTC)

The list item with the heading word/document.xml prepend a heading "Typical structures". Then add other items

xl/workbook
  This is the main workbook for a spreadsheet
xl/worksheet/sheet1.xml
  This is the typical location for individual for individual worksheets 
ppt/presentation.xml Rick Jelliffe 15:06, 4 April 2007 (UTC)

Add a reference for OPC tutorial http://openxmldeveloper.org/articles/OPC_parts.aspx Rick Jelliffe 15:06, 4 April 2007 (UTC)

Document Markup Languages

The current page has material on OPC and politics but basically no technical information about the XML. Append the following paragraph after the list of languages:

"In terms of its schema, Office Open XML can be characterized as being highly generic, highly systematic and with an emphasis on reducing load time and parsing speed. For speed, it uses very short element names for common elements and spreadsheets save dates as index numbers (starting from 1899 or from 1904). For systematicness and genericity, it typically uses separate child elements for data and metadata (element names ending in Pr for properties) rather than using multiple attributes, which allows structured properties. It does not use mixed content but uses elements to put a series of text runs (element name r) into paragraphs (element name p). The result is terse and highly nested (in contrast to HTML for example, which is fairly flat and designed for humans to write in text editors and is more or less congenial for humans to read.)

Compatibility

The text currently confuses uses "backwards-compatibility" but there are several different concepts: I) a format capable of being read or written by Application X syntactically, II) a format capable of representing all the all the information that Application X uses for its documents, and III) a format capable of conveying more information to an (old) application than it can make use of, but still work with graceful degradation. So there will be a different answer for each software. For Office 2007, it is yes, yes, yes. For previous versions of Office over the last decade is it yes, yes, yes (with the compatability kit.) For previous versions of Office, it is no, yes (or, at least, 99,9%), and yes. When a new version of office has some features that an old version of Office does not have, just adding the compatability kit would not make that feature magically appear. The point is that that Open XML has been designed to be usable as the default save format for all the versions of Office for the last decade, though that does not make all versions of Office equal in their capabilities.

In the interest of teasing out what backwards-compatibility actually means, perhaps we should just remove the second paragraph of the File Format and Structure section and replace it with something less alarmist and more exact: "This new, XML-based file format is the default save format for Microsoft Office 2007 for Windows. Versions of Office from Office 2000 onwards require a (free) Microsoft Office Compatibility Pack [4] to be installed before they can read or write the files.[3] There is no support for Open XML in versions of Office or its component programs before Office 2000; legacy file formats must be used on these older applications. Portions of documents that relate to features specific to more recent versions of Office may not survive round-tripping with older versions of Office. When opening certain legacy files, Office 2007 prompts the user whether to retain hints concerning the original formats or whether to convert the document to vanilla Open XML. As with ODF, when transferring documents between different applications there may be slight differences in line- and page-breaking because different applications use different algorithms, metrics and settings." 121.210.129.91 05:00, 9 May 2007 (UTC)

OpenOffice.org link

I've undone User:HAl's recent revert of User:SteveSims's edit, which HAI summarized "(Reverting vandalism (and reporting it))". I can find no reported vandalism, but there is this rather stern entry by HAI on SteveSims' talk page.

This misunderstanding can be easily clarified. When a user searches WP for "Open Office" (a very common misspelling of the product's formal name "OpenOffice.org"), they get this result, with many redirects to the Office Open XML page. The OpenOffice.org article doesn't presently appear until the 13th entry in that search result.

It's therefore a good idea to have a disambiguation (or see-also) link to OpenOffice.org at the top of the page, and SteveSims' edit was evidently not vandalism. Thanks, Clicketyclack 10:56, 20 April 2007 (UTC)

Mayby I was a bit hasty as I did not see any disambiguaty but I would still not see any need for the disambiguation as typing "open office" and using "Go" in stead of search leads you directly to OpenOffice.org.

I find it also not very appropriate as the article is regularly editted by people supporting ODF and OpenOffice and add links to show their preference for odf. hAl 11:58, 20 April 2007 (UTC)

People make mistakes all the time. Hopefully, with more experience on Wikipedia you will learn to detect illegitimate edits better; it can be tough at times. Even those of us who have been on Wikipedia for a long time have made our fair share of mistakes, so don't sweat it!

Here are some great links that will teach you more about Wikipedia's policies:

Wikipedia:Policy

Wikipedia:Help

Wikipedia:Spam, to distinguish spam from vandalism

The community looks forward to your future contributions! SteveSims 21:40, 20 April 2007 (UTC)

Seriously though don't sweat it! :) SteveSims 01:38, 22 April 2007 (UTC)

• I've removed the link pointing to OO.o, since people who come to this article can't come here by accident. If you type "open offce" in the search box in the left side, you are redirected to OO.o wiki and not the link posted higher up. Going by the same logic, if this points to OO.o then OO.o page should have a "Open Office redirects here, if you were looking for Office Open XML see Office Open XML". Cloud02 14:26, 4 May 2007 (UTC)

Did you even read the above? The concern is that, when you press the search button, OO XML related pages are more numerous and have higher precedence. This hasn't changed. --Karnesky 14:49, 4 May 2007 (UTC)

Normative reference

The only thing normative about the windows metafiles references is that it is a filetype value in OOXML. So as a possible value it is normative part of the spec. However the metafiles themselves are not used in a normative way. The metafiles definition has no influence on the spec whether they are known or not. A normative reference for instance is that the OOXML spec uses the unicode standard. That means that the unicode standard is 'setting the norm' for the standard. Therefore it is required to be a known and open/licensed spec as you cannot implement the spec without using unicode. Also things like examples are in general not normative as they rely on the normative part of the spec.

I reverted the comment on the normative issue in the licensing referring to the Kenyan (or should we say IBM written [70]) response. hAl 09:20, 30 April 2007 (UTC)

I put it back again. The "normative issues" referenced in the Kenyan objections relate to many more points than just WMF files. In this very discussion section above we see that the list of items is at least as follows: "The issues raised are apparently substantive, viz (spelling errors and typographical mistakes are in the original): The Ecma Office Open XML specification makes normative references to several technologies which are not described by existing International Standards, nor have they been developed by an Approved RS Originator Organization (ARO) as defined in Appendix N7 of the JTC1 Directives. Examples include: RTF -- a proprietary document format from Microsoft ; MHTML -- a proposed standard, but not yet approved in IETF ; "earlier versions of WordProcessingML" -- a proprietary format of Microsoft used in Office 2003 ; Bitmap, EMF, and WMF -- proprietary image formats of Microsoft ; Requirements to emulate the behavior of legacy word processor applications, such as Word 95, or WordPerfect 5. " Those are just examples, not an exhaustive list. Implementations of these formats would be required for any program wishing to exchange files with files generated in Office 2007.—The preceding unsigned comment was added by 202.20.20.129 (talk) 23:43, 30 April 2007 (UTC).

Which of those formats is normative to OOXML ? None. They all exist outside OOXML and if those formats change it does not affect any OOXML document itself. Changes in normative specs lead to changes in the format. Changes in embedded formats don't because they aren't normative. If unicode or the ISO 639 languages codes change then that can lead to document changes. Those are normative references. hAl 06:15, 1 May 2007 (UTC)

Au contraire, the formats are all normative for interoperability. If Office 2007 saves a file with one of those sub-formats, then an OOXML-compliant application on another platform must implement that format in order to be able to faithfully open the document. If OOXML-compliant applications on other platforms implement only that which is inside OOXML, then they will be only able to exchange documents with Office 2007 in one direction ... going towards Office 2007. If there is only a one-way cross-platform interoperability, then there is no need for OOXML to be an ISO standard. Either the formats are normative for the standard to be accepted as an ISO standard, or the OOXML standard is not a standard at all. Where OpenDocument (ODF, ISO 26300) calls up "things outside the spec", it is things like SVG for example, which is itself open and cross-platform interoperable, or other things which are required to maintain interoperability. Where OOXML calls up things outside the spec, it is for Microsoft proprietary things, for the express purpose of destroying interoperability. In addition, please note that the text that is included is neutral, in that it states that in Kenya's opinion the formats are normative (and it gives a reference), but I note there is still no reference to any official statement from Microsoft or ECM that the formats are not normative.—The preceding unsigned comment was added by 202.1.119.216 (talk) 09:38, 2 May 2007 (UTC).

You say If Office 2007 saves a file with one of those sub-formats, then an OOXML-compliant application on another platform must implement that format in order to be able to faithfully open the document. This a non-argument for conving us that this are normative references as the same is also true for any of the non-referenced formats which can also be embedded and the same applies to ODF that can also use those same subformats or any other format. ODF can embed any closed format you want.

Exactly why is this a non-argument? If you save a document from Office 2007 with any sort of complexity to it, then the supposed-OOXML file produced will contain Microsoft proprietary sub-formats. Therefore, in order for OOXML to be a "standard" via which a number of competing products can interoperate, the competing products must also implement those same sub-formats. Ergo, the sub-formats are normative. The "adoption" section of this article mentions eight products that are supposed to implement OOXML. If those products expect to exchange data with documents originated in Office 2007, then they will have to include the Microsoft-proprietary sub-formats that are "merely referenced" in the OOXML specification. That is undeniable, so the sub-formats are normative.

No they aren't because every existing format in the world can be embedded. That does not make all of them normative. hAl 15:37, 2 May 2007 (UTC)

And as to your statement that says please note that the text that is included is neutral, in that it states that in Kenya's opinion the formats are normative. I guess you mean IBM's opinion because they seem to have written the response you are referring to ? http://blogs.msdn.com/brian_jones/archive/2007/04/20/a-few-updates-on-the-openxml-formats.aspx#2266485 . What ever is in there seems far from neutral !!!! hAl 11:51, 2 May 2007 (UTC)

This point (ie who wrote the objection) is irrelevant to the objection itself. Regardless of who wrote the objection, the language in this Wikipedia article is neutral about it. The language states only that an objection has been officially raised that there are normative and not-disclosed proprietary sub-formats required by the OOXML specification in order to use it sensibly as a standard document format. If you cannot use OOXML as a document interchange format (say between the applications listed in the "adoption" section), then what exactly is the reason for submitting OOXML to a standards body in the first place?

Oh, BTW, where is any official reference (from Microsoft or form ECMA) that the sub-formats are not normative? I would have thought someone could have come up with such an official statement to that effect by now? Perhaps that claim in this article, to whit: "This means that several formats which are are said by Microsoft to be not needed to fully implement OOXML" is the not-neutral statement? It sure would seem that way, since no-one seems yet to be able to find a reference where this was officially stated.

Where is there a stament that they are normative ? The only statement as such is that written by IBM. hAl 15:37, 2 May 2007 (UTC)

You are (probably intentionally) entirely missing the point. A standard, especially an International Standard, is meant to enable inter-operation between different products, different organisations, and different countries. See here [71] (third paragraph). Microsoft has submitted a specification for OOXML to the ISO JTC for consideration as an international standard. It is entirely appropriate for the JTC to consider how well the proposal enables inter-operation ... in fact that is probably a fair and succinct definition of the purpose of the JTC. If there are any provisions in a proposed standard that would prevent or hinder inter-operation, then that is a perfectly valid reason for rejecting the proposal as an international standard. Microsoft themselves say that certain "enabling technologies" that the OOXML proposed standard invokes are not covered by the standard are are not a part of the "covenant not to sue". The JTC needs to examine if those references in OOXML are required features in order to enable inter-operation (in this case, it means full inter-operation with the type of thing as listed in the "adoption" section of the article) ... in other words, the JTC needs to evaluate if OOXML has any actual value as a standard. The Kenyan objection raises a valid concern that parts of the OOXML specification, that seem to be required for full inter-operation, are explicitly not licensed for use by parties other than Microsoft. The language that has been included in the licensing section merely points this out. It is irrelevant from where the objection was originally raised, it nevertheless does seem to be a perfectly valid objection. —The preceding unsigned comment was added by 202.20.20.129 (talk) 23:49, 2 May 2007 (UTC).

Hear, Hear. WLD^talk|edits 07:43, 3 May 2007 (UTC)

I don't think you see the point. If so then please explain to me how this differs from ODF licensing which is already an ISO standard. In both standards I can include Windows Meta Files or any other format which means the that the implementing application must be able to read that for full interoperability. Why do you state that Microsoft needs to license their WMF format to OOXML. If they did you would be adding critique that MS was disadvantaging ODF because implmenters need additional MS licensing for including it's format in ODF.

Also you still really do not have a grasp what normative means. You still do not understand why XML-schema's, unicode or ISO 639 are normative reference as for example unicode is descriptive for the OOXML file format and and an embedded format isn't. If the referenced parts of XML-schema's, unicode or ISO 639 change then that changes the OOXML format because they are normative. If embedded format like jpeg or wmf format change it does not alter the OOXML format because they are not normative for OOXML. It is just that simple. hAl 12:53, 3 May 2007 (UTC)

I know perfectly well what normative means. [72] It would appear that you don't. In the context of standards, normative means "considered to be a prescriptive part of the standard". Standard means (more or less) "a specification for interoperability". Therefore, a "normative reference" in the specification of a proposed standard would be in effect "any part of the proposed standard required for interoperability". You claim that If embedded format like jpeg or wmf format change it does not alter the OOXML format because they are not normative for OOXML. This is a self-serving, self-referencing, circular logic claim if ever I heard one. The requirement is simple ... if we have a standard for office documents, then we must have a defined way to inter-operate with those documents ... otherwise there is simply no point to having the standard. Everything that is required to represent the content of the document must be fully disclosed and licensed to everybody (worldwide) to be allowed to follow that description ... so that their documents can then interoperate with each other. That is the purpose of having a "document standard" ... so that everyone following the standard can work fully with everyone else's documents. In the OpenDocument specification, where it calls up other sub-specifications, those are also open and able to be implemented by anyone. The best example is perhaps WMF/SVG. Where OOXML calls up WMF (which is a non-licensed Microsoft proprietary format) for scalable (vector) graphics that might be included in a document, the OpenDocument specification instead calls up SVG (which is an open and freely implementable W3C standard) for scalable (vector) graphics that might be included in a document. [73] That is the primary difference, and that is why OpenDocument is wholly acceptable as an ISO standard, and OOXML is simply not. —The preceding unsigned comment was added by 202.1.119.216 (talk) 14:01, 3 May 2007 (UTC).

You are comparing apples with pears. SVG is prescriptive in ODF as ODF uses elements from SVG in its format. You can add directly certain SVG code to ODF. On the other hand there isn't a single describing element part of WMF also described or used in OOXML which is in fact the same as for jpeg or any other media format. The fact that you do not understand the difference between the use of SVG in ODF and WMF in OOXML is exactly why you do not understand what is normative and what is not 08:46, 4 May 2007 (UTC).

You aren't still on about this fallacy of yours, are you? Even Microsoft understands the point about open standards and interoperability better than you ... well at least they did in 2003 anyway. [74] [75] Give it up, for heavens sake! —The preceding unsigned comment was added by 202.1.119.216 (talk) 07:21, 5 May 2007 (UTC).

"Normative" is a technical term used at ISO in contrast with "informative". See the Directives part 2 [[76]], which is the "standard for standards" and the book that tells editors the editorial policy for standards. Standards have normative and informative parts (different to optional and required) and normative and informative references. The status of every section or paragraph has to be clearly marked (e.g. with (Informative) ). Normative references appear in a section of the standard titled "Normative Reference". Section 6.2.2 defines Normative References as a reference made so that the referenced document becomes indispensible for the operation of the standard, and may not include material that is cited only informatively or which is not publicly available. ECMA 376 indeed has a section called Normative References in the expected place, around page 5, for each part:

• Part 1: the ISO standard vocabulary and the ISO 10646 standard (which Unicode elaborates on).
• Part 2: 8601 time, 9594-8 public key (x.509 certificates), ISO 10646
• Part 3: (all informative)
• Part 4: no normative references section
• Part 5: the ISO standard vocabulary and the ISO 10646 standard (which Unicode elaborates on). Rick Jelliffe 19:37, 8 May 2007 (UTC)

So the claim that Ecma 376 normatively references those other standards is formally incorrect. Next we turn to the possibility that there is reference made in the text for which there should be a normative reference. This occurs sometimes: indeed, in the ISO standard that I edit, ISO Schematron, there is currently an issue tabled that there is a missing normative reference (concerning URLs or Xpaths or Namespaces I forget). When we look in Ecma 376 at s6.4.1.3 on clipboard types, which is where the WMF reference occurs, we see the words "The following are possible enumerations for this type" which clearly takes WMF outside the realm of being required, and more than that, of being "indispensible" (which is the test, not optionality). So unless there are other references to WMF, I can see no justification for saying that there is a "normative reference". Whoever made that comment is either ignorant of ISO Directives or of the Ecma 376 text, or they are trying to hijack the technical term "normative" to mean something else. But in the Kenyan response to ISO, normative is clearly being used in a technical sense, though wrong in fact.Rick Jelliffe 19:37, 8 May 2007 (UTC)

So Kenya (1) may be correct, and there is a missing normative reference; or (2) may be incorrect and the reference is not missing, and WMF is not normative. In your (expert) opinion, Kenya is incorrect in this instance. The question in my mind is what does Microsoft mean by "The following are possible enumerations for this type"? Do they mean "The following are [all] possible enumerations for this type" i.e. other formats are forbidden, or "The following are [some] possible enumerations for this type", allowing other, non explicitly listed formats. I would assume the latter, but being a standard I would hope for clarification as the phrase is currently ambiguous (lawyers thrive on ambiguity) and could have radically different interpretations. WLD^talk|edits 20:04, 8 May 2007 (UTC)

No it doesn't mean "all possible" enumerations. That is plain English and not at all ambiguous. If an editor wanted to list exhaustively all possible enumerations they would simple say "these are the allowed values" and there would be a enumerated type in the schema. That Kenya may be correct is "may" in the sense that there "may" be a Loch Ness Monster rather than in the sense that it is credible. It should be noted, that the remedy for this kind of thing (if it were real) would not be to stop Open XML through ISO, it would be merely to remove the sentence or mark it as informative. So I don't know why anti-Open XML people would waste their time on such trivia, which may seem plausible to people who have never read many standards but will be absolutely unconvincing to people to who have reviewed multiple ISO standards. This kind of claim will just frustrate reviewers and reduces the credibility of the people making a big deal out of something trivial; furthermore it actually hinders the anti-Open XML cause, because the substance of the issue relates to the limits of interoperability and implementability in general not to normative references, AFAICS. 121.210.129.91 05:18, 9 May 2007 (UTC)

Sorry - what is 'plain English' to you is not necessarily plain English to others, which is why writing standards is hard. I'm more familiar with the language used in RFCs rather than ISO standards. If Kenya's view is wrong, that should come out in the process, which is what review is all about, surely. Anyway, Kenya's objection exists, and is well documented, so in my view it is valid to include in the article. If a rebuttal exists that we can reference (and I'm not sure we can reference the article's talk page!), then that too can be included. WLD^talk|edits 08:40, 9 May 2007 (UTC)

In what version of English does "possible" mean "indispensible"? ...they are exact opposites! Black means white? Ecma speaks of "possible" values; ISO Directives speak of "indispensible" references! (The use of phrases like Open XML "calls up" WMF as used above is misleading, because it makes an unreasonable transition from "calls up" meaning "mentions" to "calls up" meaning "requires".) It is not an NPOV to claim that "possible" means "indispensible". I have mentioned before that this would be better put in the criticism section, if it has to go anywhere. Rick Jelliffe 05:33, 10 May 2007 (UTC)

I replied yesterday, but the Internet connection I was using dropped out, and in Real Life I'm 'somewhat busy' (<--spot the British understatement). Anyway, in the version of English I use, it is possible to say: "The possible verdicts are guilty or not guilty"; or "The possible choices are Soup of the Day, Prawn Cocktail, or House Pâté"; or "The following additional cost activities supplied by the hotel are possible: horse-riding; kayaking; mountain-biking; and abseiling". In each case, the meaning is clear: only the enumerated options are allowable/available. Perhaps your version of English differs - which underlines the difficulty in developing international standards. Writing unambiguous language is hard. Perhaps you see my point now? WLD^talk|edits 08:36, 11 May 2007 (UTC)

"The following are possible enumerations for this type" is a completely different sentence to "The possible verdicts are guitly and not guilty" (it would have to say "are *the* possible enumerations"). It is different to the second sentence: it would have to be "Here is a possible list of entre's you could order: Soup of the Day, Prawn Cocktail or House Pâté." Your last example is closer to the mark, and I can see that it there might be scope for confusion there in general writing, but it is totally unidiomatic for formal technical documents: the whole rationale is that when they require something or limit something they clearly state it, typically using should/must or active verbs: if a spec uses "possible enumeration" it is intended to signify a distinction from the plain "enumeration"...not "The following is the enumeration of the values for this type". 203.111.164.74 06:16, 14 May 2007 (UTC)

Also if one of the other type values is ageneric type like "picture" the type value is most likely used to distinguish regular embedded picture formats from wmf picture formats. This is not so weird as WMF is a very particular type of format not containing all picture info but a format relying on windows API calls to create an image. WMF will in general be implemented using the windows GDI API and other picture formats can be implemented using either internal application support or external viewers. Only large scale office applications will support a lot of picture formats internally in document rendering. hAl 08:16, 9 May 2007 (UTC)

The other aspect of this is that the WMF comes up in the context of clipboard formats. Clipboard formats are external artifacts, and it is the rationale of Open XML that it describes what Office saves; the rationale of limiting the formats saved to a minimal few to allow data interchange should be ODF's (err, is it actually?) because the "interoperability" that Open XML offers is the interoperability of completely exposing what it does not the interoperability of N->1 conversion. Different rationale, different trade-offs, different uses, hence different standards. So what is needed (by Open XML and by ODF) are *profiles*: validatable subsets that only have some core that is interchangeable. But these profiles don't come from ISO or from vendors, they come from user bodies (e.g. OASIS CALS Exchange Tables); there is no guarantee in any standard that is extensible that all documents will be "open", because it is not the job of an extensible standard to do that...it is the job of *profiles*. HagermanBot is quite rude, but he wants standards to do more than they can. —The preceding unsigned comment was added by Rick Jelliffe (talk • contribs) 19:50, 8 May 2007 (UTC).

There may be an idea that merely mentioning something implies a normative reference. But that is not the case. For example, in ISO Schematron there is a list of reserved names "XSLT", "XSLT2", "EXSLT" and "XSLT1.1" which are used but not further defined; in fact, there is no such technology as XSLT 1.1, but that did not stop the draft being approved. Just mentioning a possible value does not constitute a "normative reference", just a reservation of a name.Rick Jelliffe 20:00, 8 May 2007 (UTC)

Merge of PPTX and XLSX

I think these should be merged into this article as DOCX is forwarded here. —The preceding unsigned comment was added by Masterpjz9 (talk • contribs) 14:25, 1 May 2007 (UTC).

There is nothing in them to merge into this article. Just set a redirect. hAl 15:35, 1 May 2007 (UTC)

As there was nothing to merge, i redirected as said Cloud02 14:08, 4 May 2007 (UTC)

Reference?

"Microsoft has assured the European Union that the Office Open XML standard meets the European Union definitions of an Open Standard, meaning the specification is freely available and implementable by anyone." -- Any reference for that? Podmok 16:03, 13 May 2007 (UTC)

Yes, mayby you'd beter read the article first. hAl 13:59, 14 May 2007 (UTC)

Now, there is a reference but the information cannot be found in that source. I recommend to delete the unsubstatiated phrase but I am willing to ask the European Commission Podmok 14:00, 11 July 2007 (UTC)

I was curious about the same and the European Commission IDABC, Held answered upon my request using 1049/2001 document access rights:

"In regard to your request, I would like to clarify first that the Commission is not responsible for the content of Wikepedia articles or any links on this website. Concerning the documents you are referring to, there seems to be a mix-up between two different documents. The so-called TAC recommendations are available on the IDABC website under http://ec.europa.eu/idabc/en/document/2592/5588. You also can find industry reactions on the recommendations on our website: http://ec.europa.eu/idabc/en/document/3439/5585#recommendations TAC stands for "Telematics between Administrations Committee". The TAC was the Management Committee of the IDABC predecessor programme IDA II and does not exist anymore. The recommendations are from 2004 and have been superseded by the PEGSCO recommendations on ODF that are available at: http://ec.europa.eu/idabc/servlets/Doc?id=26971 These recommendations represent the consensus of the current IDABC Management Committee PEGSCO(Pan-European eGovernment Services Committee). The PEGSCO consists of Member State representatives that have been nominated by the responsible Ministry of their country. ... As well TAC as PEGSCO recommmendations are NOT official Commission documents, they simply represent the opinions of the IDA II/IDABC Management Committees. Statements by the leading providers and standardising organisations on the usability of both specifications are published in many instances on the net. For example the convenants to not to sue: Microsoft: http://www.microsoft.com/interop/osp/default.mspx Sun: http://www.oasis-open.org/committees/office/ipr.php IDABC has not received any specific documents from the providers in this respect."

My recommendation is therefore to delete the unsourced statement unless new evidence is provided. Arebenti 12:41, 12 July 2007 (UTC)

photo of the ooxml spec

There is a photo of a printed copy of the spec at http://blog.janik.cz/archives/2007/05/19/T20_32_07/ . Maybe this should be on the page. --87.127.117.246 17:48, 22 May 2007 (UTC)

Or maybe not. ;-) Well, at least to me, that looks like a photo suitable for a tabloid because "it looks amazingly long!" However, there are many long specs, and they're usually quite long. Are we supposed to take photos of bookcases with detailed specifications in other articles in the future? I don't think that's a road Wikipedia needs to take myself. Besides, I could not find any licensing info from the original holder, and that's essential to know for Wikipedia uses. -- Northgrove 09:14, 28 May 2007 (UTC)

Encryption method(s) used?

OK, Office 2007 just recommended me to save an Excel spreadsheet as OOXML due to "stronger encryption", instead of as an old, encrypted .xls spreadsheet. Any ideas of the details here? Neither the words "encryption" nor "security" is in this article so I'm not sure that info has been added here yet. -- Northgrove 09:12, 28 May 2007 (UTC)

Namespaces and languages

The section Document Markup Languages is wrong. There is no such thing as "Form Template" and "DataDiagrammingML" in Open XML. This can be ascertained by searching through Part 4 of the ISO draft. Also the text is a bit weak on the connection between product and language. And it doesn't correspond to the namespaces/schema structures, which would freak out anyone who then tries to look at the spec. Better text would be:

"Office Open XML is a container format with several specialized XML-based document markup languages, corresponding to individual applications within the Microsoft Office product line. Open XML defines multiple vocabularies (using 27 namespaces and 89 schema modules.) The primary languages are:

• WordprocessingML
• SpreadsheetML
• PresentationML

Utility languages include

• DrawingML
• VML (Obsolescent, used in WordprocessingML)
• Bibliography
• Math

Other vocabularies include

• CustomXml
• Charts
• Diagrams

and shims for incorparating DrawningML in each of the primary languages. "

For a reference, I have a diagram on my [blog] Rick Jelliffe 00:08, 14 June 2007 (UTC)

Footnotes versus "External Links", neutrality

There are different elements to an article: WP requires attribution, which is usually and best provided in the form of footnotes.

Then there is the end of an encyclopedia article, which often provides selected lists for "Further Reading", which in WP is often provided in "External links" (when such material is available online).

But what shall we do when an external article has relevant value in both senses: As a prime source for attribution of an important POV mentioned in the article, and also as an important overall essay for "Further Reading"? Does the fact that an article happens to be appropriately mentioned in a footnote mean that it cannot be listed as further reading? Or if it is appropriately listed as further reading, that it cannot be cited in a footnote?

That an article cannot appear (if and when appropriate) both within the relevant footnote and as a link to further reading is pedantic and silly. To remove such a link seems to have some credence disguised as a supposed move to counter linkspam (i.e. twice in an article = linkspam). But this case is not linkspam.

The matter is made even more complex when one or the either is deleted twice by an editor who, to put it simply, doesn't like the POV being expressed in that article. Case in point, User:HAl has twice deleted Sam Hiser's article on OOXML versus ODF with the stated rationale that the link may appear in one place but not the other. Why not?

As a footnote, there are quite a few online sources articles that should be mentioned regarding the POV that OOXML isn't "really" open. Sam Hiser's is one of the most important of these, and should and must be there, but others should of course be added to that footnote. As as for the "Criticism" in the external links, it is one of the most appropriate readings there too, and more appropriate than some of the other suggestions there.

Waiting for a reasonable explanation. Dovi 18:15, 24 June 2007 (UTC)

No response and no objections from others, so I've put it back in. Dovi 09:50, 26 June 2007 (UTC)

I've removed this again, and agree with User:HAl that we don't need the double citation. I find the argument that this article is somehow "important" (whatever that means in this context) unpersuasive as a reason why we need a double citation. And I certainly don't think the article should be cited without making Sam Hiser's full pro-ODF affiliation clear. Alexbrn 19:39, 26 June 2007 (UTC)

So make it clear. That's what WP is all about.

It is clear in the existing citation. Alexbrn 20:09, 26 June 2007 (UTC)

There is no double citation. It is an important article, but that is not the point. The point is that it serves two purposes simultaneously in a perfectly legitimite way. Removing it from "External links" where people interested in further reading can easily find it, based on the dubious idea that people will notice it in a footnote, is an ingenious way to censor the link. I for one am not persuaded.

Fair enough - that's your opinion, but I propose waiting for some more people to give their opinion before re-instating this again. Alexbrn 20:09, 26 June 2007 (UTC)

Quote from an edit summary:

It is not appropriate to have campaigning organisations (N.B. reference to "our side" on the site) listed here.)

Why in the world not? A Wikipedia article is meant to fairly express all POVs, and to point the reader to important essays and information about each POV. Is it really impossible to list an important critique of OOXML under "External links" about "Criticism"? Because the author represents a "campaigning organization"? By that token, perhaps links to essays by Microsoft employees should be disallowed... Dovi 19:47, 26 June 2007 (UTC)

WP is meant to embody a neutral POV, and treat verifiable facts. Clearly there's a judgement call involved in assessing links but in the link you're referring to above my judgement (and that of one other WP user) was that the linked-to site espoused a purely non-neutral position based purely on opinion, not fact. And of course these criteria apply if the author is an MS employee, or whatever! Alexbrn 20:09, 26 June 2007 (UTC)

You write:

WP is meant to embody a neutral POV, and treat verifiable facts.

Wikipedia represents the various opinions that exist, as long as they are verifiable. It strives to represent them fairly. That is what NPOV means, not (as you would have it) that opinions are not included.

Dovi - A verifiable opinion is commonly called a 'fact'. If you mean that we just need to be able to verify the opinion exists then this is clearly nonsense: in that case any old rubbishy opinion that existed on the web could be said to be okay for inclusion. Cited opinions should come from reliable sources. As I wrote above (which you have ignored) "clearly there's a judgement call involved" -- and since Wikipedia is a community it's the judgement of that community which will ultimately prevail. Alexbrn 15:43, 28 June 2007 (UTC)

Let us examine the logic here:

• There is a very widespread opinion that "Open Office XML" is not truly and "open" standard.
• Hiser's article is a highly prominent and accessible (i.e. readable) expression of this opinion.
• There is an opinion (shared by yourself and one other Wikipedia editor) that Hiser's article represents "opinion" and not fact.

Dovi - We've got our wires crossed here about what I was referring to. To clarify, my comment about 'a purely non-neutral position based purely on opinion' was referring the the scriptumlibre site you mentioned, not Sam Hiser's article. I think Sam Hiser's article should be cited; but it doesn't need to be cited twice. Anybody would think from the fuss you're making that I'd removed the link to his article. I haven't; I removed the duplicated link following the lead of another contributor! Alexbrn 15:43, 28 June 2007 (UTC)

Your conclusion: Hiser's article is not relevant in a list for "further reading" on criticism of OOXML. In simpler terms: Because you don't like the article and you consider it inaccurate -- espoused a purely non-neutral position based purely on opinion -- you delete it.

That is POV editing to the extreme. The bottom line here is that the question of whether OOXML is truly an "open" standard is at the heart of the debate about it. You and the other Microsoft-biased editor (just take a look at his contributions), rather that trying to show neutrality by going out of your ways to openly present the opposing POV, openly try to erase the heart of the debate from the article.

Frankly, on such a hot tech issue, I am quite surprised that Wikipedians have allowed biased editors to create such a biased article on OOXML. This link is only one small example. Dovi 19:51, 27 June 2007 (UTC)

Dovi - I think your switch to an ad hominen attack, and your comments about my erasing the heart of the debate are rather silly. However - if you take the trouble to look back at my edits to this article you'll see it was in fact my edit which correctly summarised the Hiser article in the first place! I've also contributed much detailed factual information to the article about the standards process, and provided a number of links behind which lie a huge range of opinions. Not everything is a conspiracy, you know ... Alexbrn 15:43, 28 June 2007 (UTC)

Your good contributions to the article are of course welcome. I also agree that "since Wikipedia is a community it's the judgement of that community which will ultimately prevail." That is certainly the case, and I have no doubt that an article as controversial as this one will undergo major changes and shifts in the coming months. I don't plan to be much involved with them (this was enough for me now...) because this is not really my field of interest, but it has certainly hightened my curiosity. Today a spent a lot of time skimming three months of e-mail correspondence between members of V1 (the US committee on ratifying OOXML for ISO fast-track). My conclusion after all this reading is the the Wikipedia article here is living in a totally different universe that that of the experts debating the standard. It highly strengthened my already strong intuition that this article puts OOXML in a far more positive light than its reality.

Nevertheless, if that is the case, I'm sure there are plenty of serious contributors who are more fully involved in the field than myself, and who will eventually jump in during the coming months and change things.

As to the issue of NPOV, we have a disagreement in principle: I do truly believe that you are mistrepresenting the NPOV policy when you make judgements about facts in a case, where those facts themselves are the subject of a major worldwide dispute. Do you think a highly visible article (Hiser's) is opinionated and not based on facts? Then if you have a reliable, stable source claiming such you can cite it. But the judgement is not yours, as an editor, to make. In such a case, the expectation is to report the opinions without passing judgement on them. To pass such judgement is called "original research." Dovi 18:47, 28 June 2007 (UTC)

At the moment there a campaign by opponents of Office Open XML to block the standardisation proces in ISO. The article should be neutral in that aspect but clearly isn't. I see an article that is fairly biased against OOXML and contains mostly opinion links from OOXML opponents, a group mostly containing anti-MS and OSS supporters which clearly dominate wikepedia opinion on this matter. If the article were to be NPOV than at least half of it could be removed. As to Sam Hiser article. Sam Hiser is the guy that recently compared Microsoft behaviour to the Germans bombarding Dresden in WWII, so truly a person that should set the norm on point of view. You call this an important article but actually the article mostly recites information already in already referenced Rob Weir and Groklaw pages. It is therefore mostly a list of already older claims made by others. Furthermore you put focus on Sam Hisers opinion in the article on the openness of OOXML but his claims never properly refute those of the already referenced claims by actual legal specialists like Larry Rosenberg and the legal firm Baker and Mackenzie. Also I have not seen a single claim of what exact things you could not implement with OOXML licensing but you what you can implement with the 'more open' opendocument format licensing. The information is not substantiated in that way. If OOXML truly was not open why not show the world how comparably open ODF is in the relevant comparison article on wikipedia. I really look forward to such information especially if supported by an expert legal analysis. You considered Hisers article a valuable article. I consider it mostly opiniated garbage by someone with a narrowminded and very biased viewpoint. Still I did not removed it because obviously somebody found that opinion relevant to the ooxml article. (Not untill someone started adding it twice to the article that is.) hAl 14:25, 11 July 2007 (UTC)