Talk:OpenDocument/Archive 2

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.


Contents

NeoOffice/J

Somebody added NeoOffice/J to the list of applications supporting OpenDocument. I believe the latest NeoOffice/J is based on OOo 1.1.4 but that OOo 1.1.5 was the first to support OpenDocument. Could a Mac user confirm whether or not NeoOffice/J currently includes the support? I know they plan to release a new one based on OOo 2.0, so maybe they should be mentioned in a paragraph ala WordPerfect. IEdML 15:55, 7 October 2005 (UTC)

You're right, it's not supported yet, Patrick is working on it. I removed the reference. Webmink 17:36, 7 October 2005 (UTC)
I was the one who added that text; I didn't realize that NeoOffice was based on 1.1.4 instead of 1.1.5. Thanks for fixing that! --bdesham 19:22, 7 October 2005 (UTC)
I've (re-)added NeoOffice. As of 1.2 alpha it's based on 1.1.5 so supports reading OpenDocument. The alpha release is pretty stable but I've noted it's status in the list. Barefootguru 20:11, 6 December 2005 (UTC)

Applications

I added links in the "See also" section for two articles that I started:

The second one is definitely something new, but the first one to some extent redoes, in a different way, the section on applications in this article.

My intent with both of these was to document exactly which applications are seriously out there for people who want to use (or are required by government/corporate policies to use) OpenDocument. That's why I divided it into the different types of OpenDocument formats, and also separated word processors from other types of compatible applications. I didn't carry over the links to applications that aren't important enough to have Wikipedia articles. ;) Also the WordPerfect and Massachusetts discussion, while good, wouldn't fit into the "List" concept.

I don't think it would be a problem to keep this article unedited and also offer the List and the Comparison. But I do just want to put that out there, see what others think.

--IEdML 01:38, 9 October 2005 (UTC)

For what it's worth, I think this is a good idea. People are complaining about the length of the main article (which I don't find to be that much of a problem, but I'll grant them that it is long) and this would be a good way to move some sections out and make them more accessible. Also, I think there are many times when people out on the 'net would want to link to or otherwise reference a list of supported applications, and it's handier to have it in a separate article than to have to link to an anchor in a much longer main document. I would support removing the list of applications from the main article and replacing them with a link to the separate doc, if there was a consensus on it. -- Kadin2048 21:26, 8 December 2005 (UTC)

Cleaning up external links

The list of external links was waaaaay to long. I did some major cleaning up. Before anybody complains, you can access the complete mess, errr, the version with an overly long list of weblinks right here. :-) Please don't simply revert to an older version, but select the links that are really relevant for an encyclopedia. 84.59.76.34 14:09, 10 October 2005 (UTC)

The problem is that the article itself claims that there was a lot of discussion about this specific topic; the length of the list of reference is itself the relevant evidence that this is a true statement. And the material from the article is from many sources, not one source; by throwing away many of the references, you throw away the justification for the article. Too many Wikipedia articles have inadequate references; let's not "fix" it by throwing away references. A lengthy list of references is in my mind a good idea, anyway; Wikipedia is not paper, and is not supposed to be original research... articles to topics not known by all should often have lengthy references. I saw the original list of references, and it's not a mess... looked good to me! Comments by others? Also -- 84.59.76.34 -- can you give yourself an account? If you use a different IP address in the future it's hard to know if you're the "same" person or not. -- Dwheeler 02:34, 11 October 2005 (UTC)
Okay, I looked at the "cleaned up" version in more detail, and I believe it's worse not better. Sure, if you erase most information it's "simpler", but by that logic a blank page would be best of all. The article specifically references many articles that have been removed: the Boston Globe article, Steven J. Vaughan-Nichols's eWeek article of September 26, 2005, the Sep. 16th town meeting audio, and so on. Even worse, the whole article is a summary of information from these various sources; I feel it is intellectually dishonest to summarize material from other sources and then fail to reference them, especially since there is no technical reason for failing to credit them. I do agree that categorizing the references is an excellent idea, though. But only if it's right; the Carrera article isn't specifically about Massachusetts, for example, and "References" as a subheading is really weird (they are ALL references!). The massive information loss is a loss to Wikipedia, not a gain; many of the article statements are now unsupported, because the article justifying the statement has been quietly removed. I think it'd be better to restore the references, possibly with some additional (but correct!) categorization. Perhaps an explanatory note on WHY the list of Massachusetts references is included (in part to justify the claim of massive number of comments) would help. Sure, many Wikipedia articles have fewer references, but this is a problem to be solved, not an example to emulate. Many paper encyclopedias have fewer references, but they do that by ignoring current events and referencing big books with thousands of references inside them; for topics like this, there are no big books to reference, so we have to cobble together the information from multiple current sources ourselves. Unless I hear from many others who only want a short list (I suspect it's a minority opinion that having many references is a problem), I plan to restore the whole list, and then we can try to structure/categorize the references better. But I'd rather have a long list of uncategorized references, compared to a long list of unjustified assertions and summaries in the article. -- Dwheeler 14:23, 13 October 2005 (UTC)
You mean some of those articles were used as uncited sources? In that case, don't revert the External links! Let's identify them and separate them out into a Sources section. IEdML 15:02, 13 October 2005 (UTC)
Yes, of course many of the articles were used but not specifically cited. Wikipedia:Cite sources says that we must cite, but that it only must be noted at the end. Here's what it says, and I quote: "In addition to listing a reference at the end, you may also choose to embed a pointer to a particular reference within the article text." So specific citations within the text are only optional not mandatory. I also followed the recommendations there: "list the comprehensive reference information as a bulleted (*) list, one per reference work." Which is why there's a long bulleted list; it's what the guidelines suggest. -- Dwheeler 15:25, 17 October 2005 (UTC)
I don't accept the premise that lots of URLs proves OpenDocument is popular. There are more web pages than there are human beings on the planet Earth; it's the quality that counts, not the quantity. I'm also not convinced that proving that point would be compatible with NPOV. I would prefer identifying the URLs which add to readers' understanding of the format. The list doesn't necessarily have to be as short as it is now, but just in general Mr. IP did a lot better job categorizing and highlighting the important sources for more information. IEdML 15:02, 13 October 2005 (UTC)
Not trying to prove OpenDocument is popular. Trying to prove that Massachusetts' selection of OpenDocument provoked a widespread discussion; having many links DOES prove that point. And yes, MANY of the articles were used as sources without specifically noting which source was used where (but they WERE at least credited before). -- Dwheeler 17:28, 14 October 2005 (UTC)
Okay, discussion seems to have stopped or at least slowed down. Everyone seems to agree that more structure would be a good thing (me too!). The solution proposed by Mr. IP, removing almost all the references that were used and in many cases directly cited in the text, doesn't make sense to me though. What's particularly shocking to me are all the deleted references that were specifically cited in the text!! Here are some options:
  1. Modify the main body to cite their specific sources in all cases. In many cases specifically cited references have now have been removed; in other cases they weren't specifically cited but they were used, and the reference has been removed. This will make the text longer, obviously, where they aren't specifically cited already.
  2. Restore the references, so that at least the source material is properly credited. I believe this is the minimum that needs doing.
  3. Keep things as they are right now. But that means we have lots of unjustifiable text, since the supporting sources are now deleted. That goes against the Wikipedia policy to cite sources. Also, I don't know if it's illegal, but it seems unethical to use a source and fail to credit it. Obviously I think this is a bad idea.
  4. Self-censor the article by removing all information not justified by the remaining references, even though it's important. I think that's a terrible idea, and goes against the goal of capturing (important) human knowledge.
I suggest doing #2 right away, so we at least don't lose the citations, and then work towards #1. We can add some markings noting the ongoing process, and working to add the specific citations in those cases where they aren't cited already. This will take a while. To help those with an allergic reaction to long reference lists :-), categories should be used to break it down further (where we can). But this topic is not King Henry XIII; we cannot refer to just the top 3 academic studies on the topic, because it's too new to have such things. We have to use a variety of sources to fairly cover this topic, and that means having more (not fewer) references if we're to have a creditable article. Having lots of references hurts no one, but failing to cite sources makes the article unjustified. Since I'm redoing the references anyway, I'm going to switch it all to the recommended Wikipedia style as described in Wikipedia:Cite_sources/example_style and Wikipedia:Template_messages/Sources_of_articles (see also Wikipedia:Cite_sources). It sorts by author last name; if we're going to insert all the detailed citations in the text, then sorting by last name will make it much easier to find. -- Dwheeler 14:27, 17 October 2005 (UTC)
Well done. I support your suggestion, and will try and help out eventually. JesseW, the juggling janitor 08:23, 18 October 2005 (UTC)

Related legal information

I'm interested in contributing some discussion of legal issues related to OpenDocument adoption. But it is a topic that could mushroom as others contribute to it, raising laws in particular countries. So I'm looking for feedback on whether to start it on this page or to start a new linked page, and if the latter, where.

I planned to begin by summarizing the international Agreement on Government Procurement, the North American Free Trade Agreement, the U.S. E-SIGN Act, and the uniform state statute implementing E-SIGN.

The text might be framed only as it applies to OpenDocument, but I thought it might be more useful if it were designed as a work applicable to file formats and streaming media formats in general.

I'll try to check back at least every couple of days this week. Tnx. --Marbux —Preceding unsigned comment added by Marbux (talk • contribs) 05:22, 18 October 2005

Those all sound like they apply more broadly to open formats / open standards in general, rather than OpenDocument specifically. I would do that broadly, say as part of those more general articles, and then add a note (with link) from the OpenDocument article to it. That sounds like very interesting information and worthy of inclusion. I know that the international Agreement on Government Procurement's relationship needs to be documented, for sure. -- Dwheeler 06:26, 18 October 2005 (UTC)

JAR file??

What makes the *zip* file that OpenDocument's internal files are contained in a JAR file as opposed to a zip file? How is Java involved in any way? —Preceding unsigned comment added by 69.158.20.156 (talk • contribs) 13:56, 20 October 2005

Well here is the official definition of a jar directly from the file specification itself: JAR file is a file format based on the popular ZIP file format and is used for aggregating many files into one. A JAR file is essentially a zip file that contains an optional META-INF directory. And it turns out that the package format requires that the manifest file be located in META-INF. Pretty Simple. Note also that Mozilla uses 'jar' files, which are distinguishable from zip files only by extention. The case is even worse with mozilla's XPI files, which are jars, but have no way to distinguish themselves from zip files. Tacvek 20:52, 22 October 2005 (UTC)
Yes, it's a JAR file not just a zip file, because it has to conform to the JAR conventions for zip files. But there many people who know about zip files and not JAR files, so we need to explain the relationship between them. That's important, because tools for managing "zip" format is widespread, and this article needs to make it clear that such tools can be used on OpenDocument compressed files. —Preceding unsigned comment added by Dwheeler (talk • contribs) 17:25, 24 October 2005
Very true. That is important. Interesting to note that the Spec does not define it as a jar file, but as a zip file. It is most certainly a jar file, as it has a manifest (albeit not a java manifest) in META-INF, but it is odd that they do not call it a jar. Tacvek 16:48, 4 November 2005 (UTC)
It is NOT a jar-file cause first while the manifest is optional in jar's it is required in opendocuments. Second the manifest-schemas are totaly different ( http://www.oasis-open.org/committees/download.php/12570/OpenDocument-manifest-schema-v1.0-os.rng for the opendoc-case ) and as such the content of the manifest is totaly different ( compare it with e.g. http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html which contains classpath and other java-related things). This difference is wanted cause jar is related to Java while OpenDocument does not deal with languages or implementations at all (and specially not with SUN's Java cause the opendoc-specification is vendor-neutral while the jar-specification is controlled by SUN). So, it is essential to differ between both formats even if they are very similar (for now). Or would we say that xml is equal to (x)html just because both are looking very similar and can be parsed with the same tools?

Incorrect information in ==Format internals==

The section Format Internals contains quite a bit of incorect information. Most of it seems to be based on what OOo uses, but this is not actually part of the spec. I have included the relevent portions below.

An OpenDocument file is a JAR compressed archive containing a number of files and directories. This simple compression mechanism means that OpenDocument files are normally significantly smaller than equivalent Microsoft ".doc" or ".ppt" files. This smaller size is important for organizations who store a vast number of documents for long periods of time, and to organizations those who must exchange documents over low bandwidth connections. Once uncompressed, most data is contained in simple text-based XML files, so the data contents (once uncompressed) have the typical ease of modification and processing of XML files.

The problem is that there is no mention of the xml-only file format as is noted in section 2.1 of the spec:

The OpenDocument format supports the following two ways of document representation:

  • As a single XML document.
  • As a collection of several subdocuments within a package (see section 17), each of which stores part of the complete document. Each subdocument has a different document root and stores a particular aspect of the XML document. For example, one subdocument contains the style information and another subdocument contains the content of the document. All types of documents, for example, text and spreadsheet documents, use the same document and subdocuments definitions.
The zipped set of files and directories includes the following:
SNIP
* Other files
** mimetype
** layout-cache
* Directories
** META-INF/
** Thumbnails/
** Pictures/
** Configurations2/

Problems here include: layout-cache, which is not part of the spec and is probably OOo specific; Pictures/, which is just a convention as this name is not mandated by the spec; and /Configurations2, which is also not mentioned by the spec and is probabaly OOo specific.

===Pictures/===
Pictures/ is a folder containing all images in the document. They are refered to from
content.xml using a <draw:image> tag, similar to the HTML <img> tag:

 <draw:image   
     xlink:href="Pictures/10000000000005E80000049F21F631AB.tif"
     xlink:type="simple" xlink:show="embed"
     xlink:actuate="onLoad"/>

The layout information (width, anchor, etc) is provided by a <draw:frame> tag that contains
the <draw:image> tag.

Most images are kept in their original format (GIF, JPEG, PNG) but bitmap images are converted
to PNG for size considerations.

Here the problems are the fact that Pictures/ is juts a convention, not part of the spec, and that last senence is almost certainly [OOo]] specific. I see nothing in the spec that prevents plain Windows bitmaps, or xbm's. Tacvek 21:41, 22 October 2005 (UTC)

Miscellaneous

I added a couple of apps to the currently supported list, but forgot to log in first. DocMgr, the Google Desktop Search plugin. I'm holding back on adding Apache Cocoon because the project web site says Cocoon can serialize to OOo and Star Office formats, unclear whether its the old formats or OpenDocument. See 2.1 feature page. This would potentially be important because Cocoon is the major Apache project tool for piping data from one format to another. Does anyone know any of the Apache developers? Marbux 01:11, 24 October 2005 (UTC)

Here is problem. According to this Groklaw thread, the Japanese Ichitaro corporation has announced OpenDocument support for a word processor to be delivered in the summer of 2006 called Government 2006. But the referenced press release is in Japanese. I looked for Wikipedia guidance on how to handle such situations but found none. Anyone have a clue.
Also, I am hitting more and more apps like Cocoon that support the old OOo formats. That means in effect that OpenDocument is supported indirectly via OOo 2.0 translation of the old OOo format to ODF. Are such apps worthy of a secondary class of "supported" apps in the article? I think it is important information, but it would be misleading to include such apps in the current list absent cross links to a explanatory footnote or some such device. Feedback requested. Marbux 00:39, 1 November 2005 (UTC)
and include e.g. a list of HTML-browsers, PDF-Viewers, tex-Editors, etc. because you are able to use oo.org to save your opendocs into that formats?

Too darn long

I thought I was interested in the MS vs. OpenDoc issue, but after I got half way through Dwheeler's essay on the subject I realised actually it's just dull. Anyway, as a good 50% of the giant 100kb article is politics, I think the article should be split, a la Wikipedia:Summary style suggestions, into stuff actually about the format and a dedicated article for the boring wrangling. And like, some can we have pictures or something? I come over all goldfish at this much unadulterated paragraph. --zippedmartin 16:05, 26 November 2005 (UTC)

All encyclopedia entries are boring if you don't care about the topic. What would you suggest to "liven it up" while still being encyclopediac? I think this topic is interesting, because the fundamental question is: "Who will control information in the years to come?" and OpenDocument is part of that decision. If by "politics" you mean "a discussion on who controls what", of course the article discusses that, it's a primary issue for this topic. If you don't care about who controls all data worldwide, then this topic is uninteresting. The article could be split, though I think the reasons for splitting up articles aren't as true any more (all browsers can handle larger articles and the "edit subsection" makes them easy to edit, and my encyclopedia set has articles way longer than this on topics that have no current significance). A good picture would be great, though I'm not sure what a picture of a file format would be (that would be different from just including text inline). I'm looking forward to your contributed picture. —Preceding unsigned comment added by Dwheeler (talk • contribs) 22:57, 26 November 2005
Ah! But, I am interested, I just have too short an attention span a thesis for what's basically just another XML based file format. I know you and others are very interested in the topic and all the legal/moral/practical implications, but does it really have to be the 52nd biggest actual article on en.wikip? We're talking three times the size of XML, and bigger than IBM, Microsoft, and Sun Microsystems put together. Spliting off some of the self contained sections to dedicated articles and briefly summarising them here could only be an improvement. As for images, I guess there are various key individuals involved in designing the format? Maybe a pic of them striding down a disused runway wearing trenchcoats would be suitably inspiring. Or just some lists in coloured boxes and flowchart thingies. I know this is a wiki and I should be doing it myself, but as I skipped and only read the Format internals section, I don't really feel qualified... --zippedmartin 00:23, 27 November 2005 (UTC)
Microsoft just announced a new patent policy on MOOX, though the critical details (other than their short statement) have not been announced. I suspect there will be many changes to this article once that's been digested. I propose waiting until those changes happen, since they may be global. After that, if people prefer it split we should split, as long as we don't lose important information. I like your idea of including a picture, but I don't have a picture of the developers and I'm not sure what thingie would make sense. You don't want to see ANY drawing that I do freehand, trust me :-) -- Dwheeler 03:28, 28 November 2005 (UTC)

Help refactoring & disability rights

I would like to help edit this article with respect to issues of disability rights (and lack of sufficient support for people with disabilities in OpenDocument applications.) I am also willing to do general refactoring. How should I start? --ASW 16:08, 7 December 2005 (UTC)

Just passing though: couldn't the sections on disability be moved to another article, "Disability in Computing" or "Disability in Desktop Applications" or something? bodhidharma 20:08, 8 December 2005 (UTC)

OneNote

There was a listing in the Applications supporting OpenDocument section for a program called "Apple OneNote" which as far as I can tell, doesn't exist. The link from OneNote goes to Microsoft OneNote, and searching on Google for Apple OneNote didn't turn up any hints of a similar piece of software under the same name (that would be a pretty long shot anyway). Therefore I changed "Apple" to "Microsoft" in a minor edit a few minutes ago. However, there is still a problem -- I can't find any evidence that MS's OneNote supports ODF; absent of any evidence I think it should probably be removed from the list. From a personal standpoint I doubt greatly that it supports the format. -- Kadin2048 20:49, 8 December 2005 (UTC)

How to negotiate with municipal civic leadership. Boston City Council

How do you negotiate with municipal civic leadership?... Boston City Council refused to distribute Council Committees' public hearings notices in plain ASCII text along with the current MicroSoft Word .doc formatted email attachments. Boston City Council refused to put their public notices on their web site at http://cityofboston.gov/citycouncil

dsaklad@zurich.csail.mit.edu 12 December 2005 (UTC)

ODF Politics

The article is about ODF, ODF politics should be in a separate article. Look at other articles on other formats, they talk about the format itself, and not its politics. 220.233.48.200 16:19, 15 December 2005 (UTC)

This reads like Open Office advertising. I came here for information but it it mostly opinion. —Preceding unsigned comment added by 2006 131.107.0.106 (talk • contribs) 00:56, 5 April
In Support: I observed the same thing: article delves into MSformats and even gives a link which claims to document MSOffice formats, but the link does not give documentation on MSdoc and other MSoffice formats but on OpenXML which is not implemented. Please lock this article from riot and non-relevant changes!!! --d-axel 19:32, 27 January 2007 (UTC)

Entry splitted and creation of a new Category

I have created three new entries OpenDocument technical specifications, Applications supporting OpenDocument and Accessibility in OpenDocument, the Reference section is still very long and needs to be splitted between the new entries too. I have also created a new category Category:OpenDocument --Khalid hassani 19:19, 17 December 2005 (UTC)

openXML not finnished yet (but OpenDocument even less finished ?)

it just like to point something out that isnt covered at all in the article. (at least not enough in my opinion) and that is that the OpenXML format is by no means finnished. just the other day the official website was opened witch is a collaboration between lots of diffrent companys.. http://openxmldeveloper.org/archive/2006/03/18/OpenXmlDeveloperGroup.aspx i not think its that odd that microsoft dont want a bunch of deviate formats from a standard that isnt even finished.

Presumably that would go into the OpenXML article, not the OpenDocument article.

also i personaly think that something can be "open" even thogh its not compateble with gpl.. the article states that developers might have to add "microsoft" to thier licences witch they find unaceptable. i think thats just plain childish. this is not about microsoft trying to destroy competition, its about developers beeing childish and dont want to admit they might have used something that came from microsoft..

If a specification is GPL-incompatible, it isn't open, no matter how much people would like to believe otherwise, because most open source software is licensed using the GPL. Let's imagine that specification "X" was released and it said "this specification cannot be implemented by Microsoft" or "cannot be implemented using proprietary licenses" - would it be open? I would say "no". No double-standard - either EVERYONE can implement it, or it's not open. The most common definition of "open standards" (Bruce Perens') makes this very clear.

all and all i got the impresion that this article was quite biast in favor of open office. (i think even someware in the text there is a sentence in the lines of "users may consider using open office instead") id like to see this article beeing tagged for a neutrality check..

just my opinion :D sorry for the poor spelling :) —Preceding unsigned comment added by 83.250.234.68 (talk • contribs) 11:58, 25 March 2006

° It might be worth mentioning to that that the ODF specification is the one that is not finished really. As the ODF standard does not contain any standardised way to implement spreadsheet formulæ's it is possible for different software manifacturers to produce ISO complient standard file that are not interoperable. Also ODF lacks sufficient support for international languages suchs as arabic which are included in Open XML. The Open XML specifications (currently emca draft version 1.3) are more complete than ODF standards. --62.58.36.57 13:00, 18 July 2006 (UTC)

    • Formulæs are handled ( see http://www.openformula.org ) and applications like KFormula and OpenOffice.org Math are implementing that standard. Also even if there exists the openxml-page, there exists _no_ implementation. So, as long as no Office-suite supports it, it's just not finished cause it can't be used.
    • Your assertion that "The Open XML specifications (currently emca draft version 1.3) are more complete than ODF standards." is not even remotely true. ODF 1.0 is complete and published as of May 2005; OXML has not even released its FIRST VERSION, so nobody knows what even its 1.0 will really contain. If it's released at all; Java was originally an ECMA draft standard, and died in committee. And let's look at your technical claims. Open XML didn't add anything for spreadsheet formulæs until May 2006, and that was still an early draft. The 1.3 mandates things like a bug in year 1900 leap-year calculations. In contrast, the first draft of the formulæ spec for OpenDocument came out in Feb 2005, and OASIS accepted it in Feb 2006, so ODF has had a LONG lead start. ODF has all sorts of support for international languages, including Arabic. I think you're being misled because OpenDocument reuses other standards, instead of reinventing the wheel. For example, OpenDocument spends less than a page on displayed formulæs, because it simply says "use MathML" - OXML instead spends page after page reinventing (poorly) an incompatible format. OpenDocument reuses SVG; OXML instead creates their own incompatible vector format. ODF reuses right-to-left / left-to-right information, Unicode, and so on for international issues; the OXML looks like it's more complete, when instead they throw away the best work and have tried to rush their own implementation (which since they do it all at once, has many problems). And so on. Like all standards, ODF is getting improved and added to, but there's a formally-accepted standard based. For OXML, there isn't even a standard base. And remember, ODF 1.0 was FINISHED on May 2005, after many years of work; OXML standardization work didn't even START until December 2005. The OXML folks are trying to write a 6000-page standard, redoing everything from scratch, in one year. It is highly unlikely that 6000 pages of dense technical text will get thoroughly written and reviewed in one year. Remember, the ODF folks had the serious advantage of building on others' work; OXML does almost everything from scratch.
I disagree that ODF is finished. There is an enormous amount of interpretation needed if you would implement ODF. What is happening is that when the ODF standard is ambiguous or leaves a lot of room for interpretation people are referred to the way that OOo has implemented things. That is not a standard, that is just rubbish. The ODF standard is ment to be interoperable. That should be it's strenght. If you were to set two seperate groups of developers to create applications using the format I could guarantee that the formats would not be compatible (and not just on minor things). As interoperabitlity is the key issue for ODF (which is much less important for OOXML) the ODF specs should have been a lot more tight than they are. Without the current reference implementation of OOo it is frankly unusable. To interprete ODF I have to create a basic document in OOo and see how it looks like. That is just not very good. I know this is probalby simular in OOXML and MS Office but interoperability is not the main goal for that format as it's wide adaptation in MS Office already means it has a better reach than any other format. For OOXML it is important that the format is compatible with legacy Office documents and that the spec is open and there is no vendor lock-in issues.
Also I scanned trough the entire standard but I couldn't really find out much how ODF supports embedding of other (binary) formats and/or if there is any limitation on what you can embed in an ODF file. This seems completly implementation based stuff.