Talk:Office Open XML/Archive 3

message: "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." -- Reference? Podmok 19:23, 27 June 2007 (UTC)
replies: text: Below we find the same claim and as a reference: "Pan-European eGovernment Services Committee (2006-12-06). Conclusions and recommendations on Open Document Formats (see §3.3). IDABC Expert Group (European Union). Retrieved on 2006-02-13." However, first of all IDABC is an EU agency for eGovernment. Second no formal document/letter from Microsoft is referenced here. I would like to see an opinion from DG Competition. Podmok 13:15, 11 July 2007 (UTC)
replies: text:  You do not trust that if an EU agency states there is an assurance by MS that there actually is an assurance ? They would make it up ??? hAl 14:27, 11 July 2007 (UTC)

text:  See discussion above under references. IDABC confirmed that a) the document is NO official EU document b) they did not receive such letter. c) the paper says that the group (which is not the EU) knows what everyone knows. The statement that Microsoft informed the Commission is unsourced as the document does not express that-Arebenti 12:47, 12 July 2007 (UTC)
replies: text:  So it should actually be more accurate to state that an expert group working for the EU was assured by the publicly availalbe information of Micrsoft and Ecma information that the standard is free and can be used by anyone ??? hAl 14:59, 12 July 2007 (UTC)
replies: text:  No, in fact there is no knowledge about such a letter at IDABC. And the original reference posted did not support the claim made. In fact the information seems to be irrelevant. Arebenti 12:26, 8 August 2007 (UTC)
thread_title:  Reference is missing 

message: I like this one by Pieterh
"(Removed Dare Obasanjo's comments as he is not neutral and cannot claim to be "an outside observer"; he is employed by Microsoft. Quoting him into the article breaks the NPV.)"
Nearly all comments referenced in the article are made by non neutral parties. There are comments by other Microsoft employees like Brian Jones an Doug Mahugh or also not so neutral comments by Rob Weir, Sam Hiser, The ODF alliance and Groklaw. I suggest Pieter removes the rest of the article and leaves only a reference link to the Ecma format spec. hAl 15:23, 20 July 2007 (UTC)
replies: text: Dare's comment was completely misrepresented, and it is inappropriate to fill a section about the criticism to Microsoft with a comment from a Microsoft employee.  I had considered adding a balancing comment to Dare's comment, but this page is not meant to be a forum.  So I removed the comment entirely.  If you want to add it back, you should clearly mark it as "Microsoft's view" and not try to make it look like an independent viewpoint.  Pieter Hintjens 16:39, 20 July 2007 (UTC)
replies: text:  I'm not interested in readding it but I found your comment that you removed his because it wasn't neutral very amusing especially when looking at the complete lack of neutrality of comments in this particular article. hAl 18:23, 20 July 2007 (UTC)

text: Criticism sections on Wikipedia often have rebuttals, thus balancing the section out. Having said that, entire paragraphs of quotes isn't the best idea; instead, it should be summarised. -MarkKB 10:05, 25 July 2007 (UTC)
thread_title:  Funny edit 

message: Anonymous user 62.49.39.98 today added this link http://www.iosn.net/open-standards/organizations/ODFA%20UKAG%20Technical%20White%20Paper.pdf suggesting it as an up to date detailed and fairly neutral technical comparison of ODF vs OOXML
But actually I see a lot of issue with that whitepaper making it not nearly as neutral as stated. To name a few:
Firstly this document is indeed serieusly misrepresenting history history on OOXML suggesting ODF has a muc longer pedigree where both XML office formats started about 1999-2000. 
Secondly it is putting examples up from OOo and MS Office  which allthough using each format are not per se good implementations of each spec and also with OOo at least two years longer to implement an implementation of ODF. 
Thirdly allthough ODF is supposed to support SVG the examples in the white paper shows that pasted SVG in ODF (which is supposed to support SVG) is embedded as a seperate file which is probably also allowed in ODF but makes the whole reusing of SVG in the spec sort of redundant where the pasted SVG is actually converted to VML in MS Office 2007 and becomes a native part of the document. So even allthough ODF has native SVG support the ODF implementation forgets that whilst the OOXML implementation of MS Office is the one to recognise the SVG correctly and convert it to native VML. This example only shows why it is sucky to use a comparison in ready made implementations in stead of comparing to the actual spec and it would have better a lot more logical to paste a jpeg image into a document to compare both specs in a simular way.
Fourthly this document supports reuse of standards like SVG and MathML which is basicly a good thing but does not notice that these are not document standards but webstandards which for instance do not support the rest of the ODF specs tags for revisions, bookmarks, footnote or anything else that might combine into the markup. When revising a single digit of a math formula in an ODF doucment that would therefore require the entire math to be marked as a revision or (if possible) the math to be split up in multiple parts whereas in OOXML the OMML match languages can integrate other office open xml document markup. 
Fifthly this document suggests that using shorter tags in OOXML requires more tags ? However this is not substantiated. Also it seems the OOXML spec mainly uses short tags for those item that are uses most like the main namespaces w=wordprocessingml and command tags for line, rows, colums and cells and uses longer descriptive tags for less frequent items. Also OOXML tagging use shows the relation between certain parent and child elements actually making implementation easier rather than harder as this document suggests. 
Sixtly the document does mention the redundancy of data in the spreadsheet cell in ODF as an advantage because the formatted version of the data is easily retrieved. That is correct but also it requires any implementation to make certain that the data and it's formatted version are always synchronised. The ODF spec does not state how to deal with inconsistensies in the cells value and it's representation. Also it does not specify or whether a document should verify on opening that these are correct. An application not verifying this could potentially be at risk from hidden data in spreadsheet value item. Especially at risk when this that value for instance could contains (references to) script or embedded executable elements. 
Sevendly the document suggests that OOXML cannot handle ODF Office settings whilst ODF could handle OOXML compatiblity settings. However the author seems to be unaware that OOXML actually contains a feature that is called custom settings. By creating a namespace  and XML with your implemtations seetings you can add custom application settings to OOXML as well and even make them validate using a schema. Particularly bad in this white paer is that it suggest its wrongly perceived lack of compatibilty with ODf settings as a reason not to choose for OOXML. Very poor thinking as OOXML actually has built in extensibility even beyond it's custom setting that could also manage any compatibility issue with ODF. 
 
Eigthly this document suggest an inconsistency with ISO 216 (paper sizes). OOXML actually support non ISO paper formats which is as it should be because those iso formats are not covering all common office paper formats in use. ODF uses a flexible paper format allowing for even more variation of paperssize but also possibly requiring more implementation for validating whether a given paper size size is actually available and or how to handle near exact sizes. With ISO 216 not being the only papers in use in for Office documents inconsistensies seem normal.
Nine-tly The documents objects to OOXML referencing windows meta files and clipboard objects as they are propriety windows related formats. However these are only mentioned as optional enumeration values for embedded items. So these values can even be used on a linux platform to easily identify that the document contains embedded objects it cannot handle without having to open the embedded file. If an ODF file contains these windows related items (which it also can) it might have to verify the embedded filetype purely on it's extention or even open the embedded file. On the other hand the dismisses the references to java in ODF's java applets because the java standard is supposedly well documented. However it fails to mention that any implementation of native embedding of java applets actually requires a java virtual machine which for instance Microsoft isn't allowed to make themselves after it's legal issues with Sun (who were in part responsible for the addition of java appplets to the spec) making full implementations dependant on 3rd party Java VM licensing.
This document presents itself as an independant white paper and  suggests to look at technical merits as well as flaws but actually is a document looking for technical flaws in OOXML comparing those unfavorably to ODF whilst ingnoring flaws in ODF (for instance the lack of spreadsheet formula's !!). Also on the merit side it is generally only ODF merits that are mentioned. Even though it does also seems to contain what I would call valid technical issues with OOXML it is full of a load of suggestive and incorrect or at least very biased statements. The addition of such 'white paper' links  or for instance the grokdoc critisisms list does suggest that all mentioned critisism in those document are correct or at least undisputed. This however hardly seems the case but this article is filled with such links that produce percieved issues as facts and in general the sites publishing have an interest in negative information on ooxml and are unlikely to correct or remove any inconsistensies in their information. hAl 13:58, 27 July 2007 (UTC)
thread_title:  Reference bias example 

message: Regularly I see the six question link appearing in the article. 
This link focusses on six question on the ooxml standardisation.
I have sevral objections to that questions:
Firstly the question are suggestive in the way they are asked in a way to make it look that OOXML does not comply for the ISO fasttrack standardization. Especially by putting unsupported statements right in front of the questions
Secondly the questions suggest that all the question are actually relvant for iso standaridsation which they seem not 
Thirdly the site does not provide answer leaving only suggestion but no factual information that supports this suggestions and that for instance Ecma could react upon.
Fourthly the site does not ask any of the questions to the Opendocument spec which in most cases would get you a simular answers.
Wouter van de Vlugt also critisised the questions in his blog post
Just to take a little example I pick question 4 (which is actually three questions) and change them to apply on Opendocument.
*Does Opendocument allow proprietary extensions? 
YES
*Is Sun's implementation of OpenDocument faithful, i.e. without undocumented extensions? 
NO
* Are there safeguards in OpenDocument against such abusive behaviour?
NO
Weird that the free software foundation never asked this questions when Opendocument was at the table in ISO. hAl 10:01, 2 August 2007 (UTC)
replies: text: Interesting but irrelevant. Tu quoque is cheap. But when it's ISO approved its to late to object. Arebenti 13:10, 8 August 2007 (UTC)
replies: text:  It show that even with flaws a spec can be agreed upon to be an ISO standard. The spec can be further developed and improved. ODF that has obvious big holes in the spec is still busy improving the ODF spec. The same can apply to OOXML. There is no requirement in ISO that a spec has to be perfect. If obvious flaws are adressed in the ballot resolution meeting it does not require the spec to be perfect to be approved. hAl 15:48, 8 August 2007 (UTC)
thread_title:  6 questions or 6 innuendo's ? 

message: "Sun Microsystems, on the other hand, is on record as supporting OOXML becoming an ISO Standard.[45]" --  Here the article says that SUN Microsystems supported OOXML standardisation. That is misleading. According to the referenced text: "Sun voted No on Approval because it is our expert finding, based on the analysis so far accomplished in V1, that DIS 29500 as presently written is technically incapable of achieving those goals, not because we disagree with the goals or are opposed to an ISO Standard that would enable them."
Their position is "disapproval with comments". The difference is: as almost anyone else they are not in principle against OOXML becoming an ISO standard. They basically want OOXML to get fixed. In the current fast-track procedure there is really no way to improve the specification and Microsoft did not make any offers so far. Arebenti 14:28, 8 August 2007 (UTC)
replies: text: Arebendi, you're putting some words in people's mouths. The current entry does not say (as your title does) that Sun "approves" the format, but that Sun supports it becoming an ISO standard. You say this merely means "they are not in principle against OOXML becoming an ISO standard", but that's just not what their statement says -- it puts a positive, not a negative position: "we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes". Their approval is conditional on "specific changes already agreed upon by consensus in V1" being made to the text. Alexbrn 15:28, 8 August 2007 (UTC)
replies: text:  Arebenti, the fasttrack procedure does allow the standard to be significantly improved. After ballots with comments are all send in (at 2 september) Ecma can propose changes based on those comments. Then on the ballot resolution meeting  agreement can be made on those proposed changes and mayby even some others if those are important enough. Also Ecma could state commitment on more elaborate changes regardingthe comments made by the members to be resolved in in a future version which might be acceptable for some of the ISO members as well as it seems that for instance ODF is also still busy to complete their format specification more thna two years after it's standardization in OASIS. hAl 15:55, 8 August 2007 (UTC)
thread_title:  Sun Approval of the Format? 

message: I haven't kept up with this discussion and the numerous article changes, but I remember being genuinely confused by the name "Office Open XML", especially because OpenOffice.org used to be called just "Open Office" or "OpenOffice."  "OpenOffice.org" starts with a "distinguish" template pointing here, and I think this article should reciprocate.  I think confusion with "OpenDocument" is less likely.  —Fleminra 06:08, 14 August 2007 (UTC)
replies: text: If you see ambiguity you can re-add the tag but I do not see any problem with any ambiguity here which the tag is ment to be for. "Open Office" and "OpenOffice" lead directly to the correct article and so does "Open document" and "Opendocument". It seems more likely that you'll by accident end up in the openoffice.org when looking ofr this article than the other way around. hAl 12:51, 14 August 2007 (UTC)
replies: text:  These topics might be unambiguous to you because you happen to spend quite a bit of time working on this article.  But do you think the average grandmother would assume that "Office Open XML" and "Open Office" were two completely unrelated things? —Fleminra 20:53, 14 August 2007 (UTC)
replies: text:  Before someone objects to the re-addition of this template, here's the test I propose: write down "Open Office," "OpenOffice," "OpenOffice.org," "OpenDocument," "ODF," "Open XML," "Office Open XML," and "Microsoft Office" on separate little slips of paper and ask your grandmother to arrange them into two piles of "things that go together."  —Fleminra 21:15, 14 August 2007 (UTC)
replies: text:  You provide no valid example on ambiguity that warrant you distinguish tag. Your test is ridiculous. For ambiguity tagging it requires reasonable search criteria that would lead a visitor to the wrong article which you just do not provide. It looks like a pure openoffice and/or opendocument promotion link. I'll therefore remove it. 69.73.191.92 00:10, 15 August 2007 (UTC)
replies: text:  Type "open office" in the box to your left and click "search."  The first article in the results is "Office Open XML."  Anyway, when you remove this distinguish tag, don't forget to do the same for the OpenOffice.org article.  —Fleminra 04:19, 15 August 2007 (UTC)
thread_title:  "distinguish" template