OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oiic-formation-discuss] Profiles: suggested use-cases

On Sun, Jun 22, 2008 at 7:14 AM, Dave Pawson <dave.pawson@gmail.com> wrote:
> 2008/6/22 marbux <marbux@gmail.com>:
>> Dave, do you see any way of working out of the ODF interop mess
>> without going beyond the current ODF spec, filling in the holes and
>> specifying the application behavior necessary to achieve the interop?
> Yes. Working with the spec.
> 1. Rigorously determine the untestable parts of the spec.
>   Report back to the main TC asking for a fix.
> 2. From the testable items, provide the test definitions.
> The testing of ODF remains incomplete pending
>  resolution (clarity perhaps) from the main TC.
>> I'm not sure I understand your point here.
> I want to stay within the ODF standard.
> (For the first iteration)

The problems I see there:

1. The work to transform the old OpenOffice XML specs to app-neutral
formats never really got very far on the ODF TC. It's in the Charter
but not in the spec. There really isn't much in the spec that isn't
designed specifically for OOo..

2. The longer we wait to do the app-neutrality work, the more locked
in everyone gets to the StarOffice way of doing things. That deals
just about everyone but the folks using the OOo code base out of the
market. E.g., no way on God's Green Earth that Microsoft or Corel will
be able to round-trip documents with OOo without data loss if OOo
isn't rewritten. A spec has to be application-neutral before it can be
implemented by other legacy apps in a round-trip way.  .

3. I see no practical way out of that mess without an interop
framework and working out from a core profile to supersetting
profiles. If we hand the TC a list that says please fix all these bugs
without a roadmap for the app-neutrality work, the bug fixes might get
done and implemented by ODF v. 1.5 but we'd still have the
app-neutrality work to do. In my mind, the app-neutrality work and the
bug fixing have to proceed concurrently in do-able increments. .We
also need to deal along the way with the bugs that keep less and more
featureful apps from round-tripping documents.

I'm certainly willing to listen, particularly with your particular
expertise, but I'm not understanding how your approach meshes with
mine. I'd like to see at least an app-neutral core minimum
requirements profile in ODF v. 1.2 along with the conformance
requirements necessary to achieve round trip interop using that  and
any more featureful profile that could be done and implemented with
ODF v. 1.2.

Can our appoaches be meshed?.

Universal Interoperability Council

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]