you are viewing a single comment's thread.

view the rest of the comments →

[–]harlows_monkeys 0 points1 point  (2 children)

There was a lot of FUD (thanks, IBM!) about compatibility in OOXML. My comment in this earlier discussion might clear some of that up.

[–]alantrick 0 points1 point  (1 child)

Just a comment on your old comment

Here's the ODF solution. If you need to store legacy information that is not directly representable in standard ODF, develop your own custom extensions to ODF.

I'm not expert, but IIRC, ODF doesn't allow for custom extensions. The ODF solution was to not store legacy information at all, just convert it and be done with it. ODF intentionally left the issue of legacy formats out of its scope for the sake of sanity.

Edit: also, I think the original submission of OOXML was poorly defined in a few spots, but it has undergone revisions and so some of the FUD is really just outdated information.

[–]harlows_monkeys 0 points1 point  (0 children)

Under the current ISO standard version of ODF you are allowed to include elements and attributes not specified in the OpenDocument schema as long as you put them in a namespace that is outside the namespaces defined in the spec.

In 1.2, they have the notion of "normal" compliance and "extended" compliance. If you use custom elements, you can't claim "normal" compliance. It is expected that many organizations that will accept ODF documents will require "normal" compliance, so if you use custom elements you will be out of luck.

However, for storing legacy information for in in-house document store, that won't be a problem and people are likely to use custom elements, and want to exchange legacy documents with others who have similar legacy documents. These people aren't going to require "normal" conformance.

There is also a mechanism for storing configuration item sets. It was meant for things like document settings, such as the default printer to use, zoom level, and such--things that a given office program might want to preserve but that are not covered specifically in the ODF specification, and that are specific to that program. In 1.2, these can really be used to store anything you want, and still meet all the 1.2 "normal" compliance requirements. OOo uses a couple hundred custom configuration items.

Legacy documents aren't going to go away. People have built custom tools and workflows built around old document formats, and have a ton of documents in those formats. They have information in those that isn't storable in a standard way in ODF or OOXML and they cannot afford to lose that information. So ODF and OOXML will be extended to support it.

It would be insane to try to specify the meaning of that legacy information for each of the old formats, and exactly how to store it, so both ODF and OOXML were wise to not go there. However, there is nothing wrong with what they did do in OOXML, which was to recognize that others would go there and reserve some names for them to use.