[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?
On Sat, Jun 21, 2008 at 4:11 AM, Sander Marechal <email@example.com> wrote: > marbux wrote: >> >> But I don't see that as highly relevant to ODF app <> ODF app interop >> before app dependencies are removed from the ODF spec in a core profile. > > As I've written previously, IMHO the two sources of interop problems are > bugs in the spec and bugs in the implementations. This is squarely aimed > at fixing bugs in the implementation. O.K. > > It would help ODF application and tool developers > to get better conformance and interop. We'd be able to check if two > applications produce the same document (given the same data). We could > integrate it into an application's automated regression test suite. > Etcetera. At least with elements attributes, just about every conformance is already tested by validation against the schema after all foreign elements are removed. The only thing remaining that doesn't have a test is the small bits of the conformance section relating to the processing of foreign elements and attributes in specific situations. That and the fact that there are no interop conformance requirements are why I raised the issue of timing in what you want. I.e., do we build tools for the existing spec or the repaired version. I'm not against what you want but I don't see the need for it before the spec is fixed unless the goal is application-level interop hacks rather than a tool based on conformance requirements. To the extent that interop is hacked at the application level before app-neutral interop conformance requirements are established, we just introduce more app dependencies on the under-specified parts of the spec and developer incentives for those parts staying under-specified. So I see creating the interop conformance requirements as a high priority item. Like I said, my question goes to the timing of what you want rather than to opposition to what you want. I see an issue of prioritization in the relevant deliverables. Do we develop the tool you want for a badly broken spec or for the repaired version? There is no way to repair the under-specification without breaking compatibility with apps' present coding. The same would be true with the tool you want if we create it before the spec is repaired. Were it up to me, ODF 1.2 would be put on hold until we get the chunks inherited from earlier versions fixed and then see what has to be done to add the new features in ODF 1.2. An ODF designed for interop will be profoundly different from the present spec. Both the spec and the apps have to change. The longer we put it off, the bigger the mess gets that has to be cleaned up. -- Universal Interoperability Council <http:www.universal-interop-council.org>