In the USA write to ANSI: http://www.ansi.org/ Email: info@ansi.org Sorry I do not have a direct contact.

Here is a list of all National Standard Bodies and contact information, http://www.noooxml.org/delegations

Hope that helps

The relation ship files within an OOXML file should contain all of of its relationships with other internal and external fileparts.

I am not sure why you claim that it contains implicit relationships that you are unable to find using the .rels files.

If you read in all of the relationship files of an OOXML file (which could easily be as little as 1% of the file) you should have an accurate map of all the file-elements and their relationships.

Look maybe ODF is not perfect, but it is developed by consensus and developable and that is what Open Standards are about. Not one company pushing its own agenda. And to top it off, many including IBM’s Bob Sutor on several occasion have invited MS to join in on the development of ODF so the global community can benefit. But no MS is only interested in M$

First of all, I am talking about implicit relationships. .rels are irrelevant for building the tree whenever there are implicit relationships since by definition an implicit relationship is not an explicit relationship.

We are left with what you call “the actual XML data files have more information than the combination of ODF’s manifest files and XML data files with less duplication of information.”

The last part of your sentence is just some random and bogus rant against ODF. Anytime someone brings a flaw in OOXML, there is always some jerk taking the opportunity to come around with ODF, as if it made the flaw in OOXML less a flaw.

Really poor logic. We are talking about OOXML here, in case you did not know.

Now for the first part of the sentence. You mean all the information is there. Well, that’s something you have to prove first of all. Since OOXML files are created by Microsoft Office and that Microsoft does not give the source code of this program, I have no idea how you can claim that ALL the data you need is in the file. What is the evidence? Can you name a reference non-Microsoft implementation?

That leaves us with the main issue, which is the fact that with implicit relationships you don’t know where to look for the dependencies because it’s completely random. Any part can depend on another part by any tag the designer of the file wanted to make it work. In case you don’t understand what I mean, by any tag I mean anything other than r:id or r:embed (tags used for explicit relationships).

Complete bullshit.
The combination of .rels files and the actual XML data files have more information than the combination of ODF’s manifest files and XML data files with less duplication of information.

In OOXML you can verify for each part where it is referenced without opening the possibly large data parts by simply opening the very small .rels files in the package.

Also .rels files can be used to fully understand the entire relationships between all the files in a package. In ODF you need to parse the entire package for that.

1) OPC is just a way to describe relationships between parts. It’s kind of metadata if you will. As such, it has nothing to do with the parts themselves. So your reference to maths and other things is irrelevant.

2) OPC is an inferior specification. It includes evil “implicit relationships”, a mechanism by which a part depends on another without making it explicit by way of relationship parts (entries in the ZIP files ending with .rels). The consequence is that it is impossible for a application to determiniscally build a tree of dependencies among parts. For instance, if you are willing to delete a part, there is no way to know if this is going to corrupt the entire file.

Of course OPC is a mess unless you are Microsoft. Obviously, those who own the source code of Microsoft Office have a trivial mean to know which implicit part relates to which other part : they just have to look at the source code. This excludes everybody else from doing the same reliably and determiniscally. ECMA 376 does not address this (ECMA 376 Part 1, fundamentals, only addresses EXPLICIT relationships, not implicit relationships).

The consequence is that the number of Office 2007 documents that will be manipulated by third parties will continue to be corrupted as much as binary files. For the exact same reason by the way.

This kind of fundamental issue was raised in my article OOXML is defective by design.

Well, I’ll admit it’s not easy with the current editions of both, Viral, but at the same time you’re ignoring something very important.

K-Office has been, for the past year, working on moving from the current release to one that works in KDE 4.0 and KDE 4.1 due mid year. Implementing ODF in full has taken a back seat to that effort (rightly or wrongly) in the current version of K-Office until the new one appears in the spring.

The new version will fully implement ODF and at that time full fidelity between OpenOffice and K-Office will be a piece of cake. It already is in alpha test.

So, whatever your problems with the article please don’t demonstrate your ignorance too much by ignoring what is happening in the real world. Particularly when it doesn’t fit your arguments.

ttfn

John

It’s all such a farce. Let’s call a spade a spade and be done with it. Really, this is the most cutting argument against making Office XML an ISO standard. When only one American software corporation can implement the standard to its fullest extent, how can anyone call it an international open standard at all?

http://slashdot.org/article.pl?sid=08/02/12/2239224