Re: [oiic-formation-discuss] Deliverable: odf-diff?

[marbux <marbux@gmail.com>]

On Sat, Jun 21, 2008 at 4:11 AM, Sander Marechal
<sander.marechal@tribal-im.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>